#bzr 2008-04-07
<lifeless> nick125: there is an 'integrating with bzr' wiki page btw
<beuno> nick125, http://bazaar-vcs.org/Integrating_with_Bazaar
 * nick125 is reading
<nick125> Does bazaar have some way to push via HTTP with something like a CGI script?
<nick125> That's one of the main things that I liked about mercurial (one of the things I didn't like about mercurial was the random data corruption that would occur when you would use two different mercurial versions)
<mwhudson_> nick125: there is some support for smart behaviour over http, yes
<mwhudson_> i'm not sure how useful it is yet
<lifeless> nick125: bzr+http
<nick125> *looks*
<nick125> lifeless: Do you happen to have a link?
<lifeless> its in the docs
<lifeless> on an http url bzr 1.4 will autodetect bzr+http if its available
 * nick125 looks at the big "THIS IS EXPERIMENTAL AND INSECURE" notice
<nick125> hmm
<spiv> That notice is gone in bzr.dev.
<lifeless> spiv: call ?
<mwhudson_> spiv: i hope that means its secure now :)
<lifeless> poolie is organising office stuff; I have offered to be the teddy bear de jour
<spiv> lifeless: sure
<nick125> What other ways exist to push with bzr without SSH?
<lifeless> bzr+http
<lifeless> ftp
<lifeless> wedbav
<lifeless> any vfs
<bob2> ssh/sftp seem to be the most mature and simplest, tho
<lifeless> oh yeah, sftp too :P
<lifeless> but sftp kinda needs ssh :)
 * nick125 is kind of leary about giving random people SSH access to his server
<LeoNerd> You can create sftp-only accounts
<LeoNerd> You set the shell to something special. sftp doesn't actually use a shell anyway, it's a different subsystem of ssh
<nick125> LeoNerd: So I can set the shell to /bin/false (or something like that), and sftp would still work?
<LeoNerd> Um.. possibly. I don't know the details, I just know it's possible
<jdong> nick125: I think that's roughly correct. OpenSSH's sftp subsystem in recent versions can even set up a chroot to restrict where they may navigate to
<jdong> nick125: on my secured shells recently, I've been utilizing Apparmor profiles to provide restricted access. this can also be an acceptable option
<lifeless> nick125: you can even use a virtual SFTP server e.g. the conch one or I think paramiko has one too
<nick125> hmmm
 * nick125 sets up bazaar and paramiko
<poolie> hello
<poolie> welcome nick125
<nick125> hiya poolie
<nick125> So, paramiko is a sftp server that doesn't require users to have shell access?
<nick125> blah
<nick125> I'm trying to figure out how to get a centralized repository that people will push and pull from...I don't think I want to do a shared repository, since I have a bunch of devs that want to work offline.
<Odd_Bloke> nick125: A shared repository is just a performance and storage enhancement, it doesn't affect your workflow.
<nick125> Unless I'm misunderstanding the concept of shared repositories (it sounds to me that a shared repository keeps the history on the server)
<lifeless> nick125: shared repositories simply allow multiple branches to use a single shared history db
<lifeless> nick125: does not affect offline/branches/etc
<nick125> Ahh.
<nick125> The documentation makes it sound like that it stores the entire history on the server and only leaves a local copy.
<lifeless> which docs in particular ?
<nick125> the centralized workflow one
<nick125> I probably misread it.
<lifeless> (what you describe is what lightweight checkouts do)
<lifeless> an orthogonal feature
 * nick125 hates having to come up with names for projects
<ubotu> New bug: #213172 in bzr ""bzr status" output problems" [Undecided,New] https://launchpad.net/bugs/213172
<ubotu> New bug: #213182 in bzr "TestLockDir.test_35_wait_lock_changing is timing-dependent" [Undecided,New] https://launchpad.net/bugs/213182
<ubotu> New bug: #213184 in bzr "'conflicting tags' could be more helpful" [Undecided,New] https://launchpad.net/bugs/213184
<ubotu> New bug: #213185 in bzr "tag conflicts do not change exit code" [Undecided,New] https://launchpad.net/bugs/213185
<ubotu> New bug: #213186 in bzr-gtk "gannotate broken with bzr.dev" [Undecided,New] https://launchpad.net/bugs/213186
 * mwhudson wtfs
<mwhudson> reality check please:
<mwhudson> am i right that it's pretty strange that "cd a; bzr merge ../b" gives conflicts in different files to "cd b; bzr merge ../a" ?
<mwhudson> (with --lca)
<mwhudson> though the conflicts are different with merge3 too
<mwhudson> (some of the conflicts look totally bogus too)
<Odd_Bloke> LCA has an edge case which it doesn't deal with, but I can't remember what it is...
<poolie> mwhudson: unless there are working tree changes it does sound strange
<mwhudson> i guess i'll just send abentley a mail, given that this is an issue with two launchpad branches
<poolie> i don't think it's guaranteed that they're symmetrical
<lifeless> poolie: it should be; we walk back to a single lca
<mwhudson> i guess i'll send the mail to the internal list then :)
<abentley> Odd_Bloke: The edge case is that it fails to detect a conflict when one side deletes lines and the other side changes them to something else.
<abentley> mwhudson: Please do.
<bitmonk> hi, so like, i installed bzr and bzr-svn packages in ubuntu, but am having trouble branching an svn repo. the documentation is rather light in the bzr-svn wiki, any pointers?
<abentley> I can tell you, it's been frustrating over the years to get reports of strange merge behavior with Launchpad branches, and not be able to do anything about it.
<mwhudson> (there is some criss-cross merging around)
<mwhudson> abentley: i'm sure
<bob2> bitmonk: "bzr branch svn_url blah" - do you get an error?
<bitmonk> bzr: ERROR: Not a branch: svn+https://svn.plone.org/svn/archetypes/Archetypes/trunk
<bitmonk> same for https://
<mwhudson> hm
<bitmonk> indeed.. i haven't had it working for a while, but got it working from source a couple times on my mac or something..
<bitmonk> i have had it working, so i have a rough memory of what works..
<lifeless> abentley: just think, now you can dig all those reports up and analyse them :)
 * mwhudson finds himself wondering if there is a way of restricting 'bzr viz' to revisions touching a particular file
<abentley> lifeless: yay!
<abentley> lifeless: Have you had seen bug 212908 ?
<ubotu> Launchpad bug 212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Triaged] https://launchpad.net/bugs/212908
<spiv> mwhudson: that would be lovely feature
<spiv> mwhudson: I don't think it exists yet, sadly.
<abentley> Since VersionedFiles can provide a Graph, it shouldn't be hard now.
<abentley> Because viz is now using Graphs.
<lifeless> abentley: are your two statements to me related?
<abentley> lifeless: No.
<lifeless> abentley: I've seen that bug, I presume you had a plugin or something to trigger it?
<bob2> bitmonk: does 'bzr plugins' show svn listed?
<abentley> Reconfigure triggers it.
<lifeless> oh, ok.
<abentley> At least in my new patch, it does.
<abentley> But we have also occasionally seen reports of the same error in the wild.
<lifeless> I can guess at the cause; its really a LBYL avoidance optimisation
<abentley> So this may be the cause of them.
<mwhudson> oh, i think the different merge results with --merge3 were because of unknown files or something
<bitmonk> bob2: yessir
<lifeless> abentley: rather than checking keys exist in packs, we copy them when we are asked too. By design multiple packs can have the same key.
<abentley> This isn't a key-level problem-- it's a file-level problem.
<bob2> bitmonk: hm, dunno then - try asking on the mailing list, I guess
<abentley> It comes from trying to create a file in a pack that already has a file with the same name.
<lifeless> abentley: thats a key level problem
<lifeless> abentley: the name is the checksum of the .pack
<bitmonk> bob2: will do, no hurry i s'pose
 * mwhudson sends a mail
<lifeless> abentley: it means we've copied the exact same data in twice.
<abentley> Are you saying the filename of a pack is its key?
<lifeless> (or got a md5 collision)
<mwhudson> fortunately, it's not actually a real problem for me, the bogus seeming conflicts are trivial
<abentley> No, I think you're forgetting that fetch with no argument ids doesn't copy contents, it copies files.
<abentley> So if the source file has foo.pack, the target file has foo.pack, regardless of the keys inside it.
<abentley> I mean source repo, target repo.
<lifeless> abentley: one sec, talking with poolie
<abentley> So it's all about what the names of files in a repo are, not what their contents are.
<abentley> (Now of course, we would *hope* that the repository is not corrupt, but that's not actually relevant...)
<lifeless> InterPackRepos.fetch does not copy files
<lifeless> when revision_id is None, it does self.source.all_revision_ids()
<lifeless> why are you saying we copy files ?
<lifeless> line 2726 of repository.py in bzr.dev
<bob2> bitmonk: does http:// work?
<bitmonk> good question, trying
<abentley> I have line 2758
<abentley> ubotu: paste
<ubotu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
<abentley> http://paste.ubuntu-nl.org/62385/
<abentley> lifeless: ^^
<lifeless> abentley: that is consistent with my analysis
<lifeless> abentley: packers copy contents not files
<lifeless> abentley: when revision_id is None, revision_ids becomes the source's all_revision_ids() set
<lifeless> abentley: but like I said, we don't try to eliminate duplicate revisions because that is costly and unneeded.
<abentley> My apologies if I misunderstood.
<lifeless> abentley: this is simply an expected md5 collision: we are copying the same content to a repository that has that content laid out the same way in a .pack. The right thing to do is to complete bug #
<abentley> It looked as though it was copying the source's all_packs(), not their contents.
<abentley> Bug # ?
<AfC> There is no bug number. That's part of the bug :)
<lifeless> I can see the confusion :)
<lifeless> I'm looking it up
<lifeless> lp is slow
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/165293
<ubotu> Launchpad bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed]
<lifeless> fetch with no revision_id parameter should be extremely rare - limited to upgrade in fact
<lifeless> why does reconfigure use it ?
<abentley> lifeless: It is deleting a repository.
<abentley> So it fetches all the contents into a new repository.
<lifeless> right
<lifeless> as a backup ?
<lifeless> and is it doing it twice for some reason ?
<lifeless> (we can't filter on all_revision_ids() here, because if you need _all_ data you need signatures for absent revisions, inventories with no revisions etc.)
<abentley> Because the new repository is going to be used for the branch from now on-- e.g. a heavyweight checkout being converted into a lightweight one, or a standalone tree being converted into a sharing tree.
<lifeless> so when you say new repository, do you mean 'existing other repository' ?
<abentley> yes.
<lifeless> ok
<abentley> So the test cases set up two repositories with identical content.
<abentley> And then reconfigure itself does the fetch()
<lifeless> fixing the md5 collision handling to not error on collisions with identical content will fix this bug
<lifeless> but reconfigure in this case will be overly slow
<abentley> If you fix it or in general?
<lifeless> the cause  of the error is a situation we expect to encounter, but rarely
<lifeless> and is not an error when it happens, we just currently group it with actual errors.
<lifeless> however, copying a *lot* of data that we do have will be slow
<lifeless> pack repos allow keys to be duplicated in different .pack files because that allows better concurrency when two people write to a repository at the same time
<lifeless> testing a workaround for you
<lifeless> abentley: try this: http://paste.ubuntu-nl.org/62387/
<abentley> lifeless: that fixes my test case.
<abentley> Reconfigure tests pass too, with my workaround removed.
<lifeless> abentley: cool
<lifeless> OperationalError: ('(OperationalError) database is locked', <bound method Root.index of <bundlebuggy.controllers.Root object at 0x8ed078c>>) u'SELECT mergerequest.id AS mergerequest_id, mergerequest.date AS mergerequest_date, mergerequest.summary AS mergerequest_summary, mergerequest.branch_location AS mergerequest_branch_location, mergerequest.head_revision AS mergerequest_head_revision, mergerequest.text_type AS mergerequest_text_type, 
<lifeless> *sorry*
<lifeless> I had no idea it was that long; I imagine IRC truncated it but still
<poolie>  /kick lifeless :)
<lifeless> spiv: whats up with  http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E?
<lifeless> poolie: http://bundlebuggy.aaronbentley.com/request/%3C1207267732.5960.150.camel@lifeless-64%3E
<bitmonk> bob2: still no love with http:// :/
<lifeless> spiv: u have a review
<spiv> lifeless: thanks
<spiv> lifeless: so you just think s/list/tuple/ in that?
<lifeless> If that passes tests yes.
 * spiv nods
<lifeless> you'll need to change the code obviously as you can't mutate the tuple once you make it
<lifeless> so list(thing)
<lifeless> ...
<lifeless> new = tuple(correct_options0
<lifeless> spiv: calling it orig_options is confusing too; so perhaps options = list(self....)
<spiv> Ok, makes sense.
 * spiv finds out if tests pass
<poolie> spiv it looks like you should merge http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E
<spiv> poolie: yeah, it's on my radar.  lifeless just pinged me about that earlier :)
<jamesh> hi fog
<fog> hi james
<luisbg> how do I unlock a branch?
<spiv> "bzr break-lock"
<luisbg> it seams to be in the host
<luisbg> Unable to obtain lock lp--1228238676:///lock
<luisbg> held by luisbg@bazaar.launchpad.net on host vostok [process #25367]
<luisbg> :(
<james_w> luisbg: hi
<luisbg> hey james_w
<james_w> you want to run "bzr break-lock sftp://whatever"
<luisbg> ok
<luisbg> let me see
<james_w> unfortunately with launchpad you may need to run this a few times.
<luisbg> a lot
<luisbg> still stuff locking it
<luisbg> done and pushed after like 10 runs
<luisbg> :)
<luisbg> thanks!!
<james_w> no problem.
<dato> what was the command providing --custom revision format?
<dato> the thingie that is recommended instead of $Expansion$
<ignas> how do i get a branch for some specific revision using bzrlib?
<ignas> without making a checkout preferably
<ignas> i want to pass the result as "other" to branch.missing_revisions
<pickscrape> Hi, I've encountered a bug in bzr+svn that I think I can fix myself. Could anyone point me at any docs on bzr+svn hacking?
<pickscrape> (i.e. which tree to work against, where/how to email a merge request/patch etc)
<bob2> the bzr svn page on the wiki at least has some of that information
<pickscrape> It links to three branches (trunk, 0.4 and 0.3), doesn't say which to use to hack on, shows how to run the unit tests, and where to raise bugs
<ignas> emm, why is revision_tree method of a tree
<ignas> "not implemented" but not marked as such in the docs
<ignas> it always raises an error (at least that's what code says)
<ignas> but has an elaborate docstring
<ignas> that leads one to think that the method does somethingh
 * ignas had this idea that using bzrlib would make listing of all the new changes since some revision easier than using bzr from the command line...
<spiv> ignas: there will be a subclass that implements th\at
<spiv> ignas: although most classes don't tend to be constructed directly, you usually get them by calling methods on repository/branch/etc.
<ignas> yeah, that's what i tried doing
<ignas> tree.revision_tree("revision-I-want")
<bartzitz> hello, i have a central repository (remote server), and i need to run a hook (shell script) on that server after each commit. how do i do this?
<ignas> so - how do I list all the changes in a branch since some revision?
 * ignas looked at show_log and it is a little bit complicated
<bartzitz> ignas: bzr log -r<revno>..
<bartzitz> ignas: -v will show modified files as well
<ignas> i need it not including the revno
<ignas> which is why i tried using bzrlib to do that
<bartzitz> ignas: maybe i haven't got what are you trying to do?
<ignas> i need a list of all the changes since some tag (only new revisions) listed on a web page
<ignas> at the moment i am using popen to run "bzr missing"
<ignas> but that requires making a checkout from the tag
<ignas> which makes the operation kind of slow
<bartzitz> ignas: bzr log -r tag:<your tag>..
<ignas> includes the revision that was tagged as well
<bartzitz> ignas: hmm, no ideas for now
<bartzitz> ignas: do you know how to set up a hook on a remote shared repo?
<ignas> nope
<ignas> why would i want to do that?
<bartzitz> ignas: i need it :)
<ignas> oh ;)
<bartzitz> ignas: just asking
<ignas> is there an easy way to perform actions on bzr log messages using bzrlib?
<ignas> i want all the log messages since some revision
<ignas> in some data structure
<ignas> and the only thing i could find that does something like that was show_log function, but it's way too complicated for what I want
<ignas> and outputs stuff into stdout from what I can see, instead of giving me a list
<dato> ignas: I think revision objects have a .message attribute
<ignas> ok, how do i get all the revision messages since some revision?
<ignas> or does revision_history() return them ordered ?
<james_w> ignas: yes, revision_history is ordered
<ignas> and how do i get a revision object from a revision_id?
<pickscrape> Is there a way to resume a bzr checkout operation that has died?
<spiv> ignas: repo.get_revision
<spiv> ignas: where 'repo' is a Repository, e.g. from Repository.open('path/to/repo'), or from branch.repository.
<pickscrape> Anyone know how to resume a failed checkout operation?
<james_w> pickscrape: "bzr pull" may be able to do it, I think it depends when it failed.
<pickscrape> Bingo. :) I had to specify the URL of the svn repository again, but it appears to be working fine.
<pickscrape> Thanks for that.
<pickscrape> My bzr-svn fix appears to have worked too. Anyone know where I should email the bundle containing the fix to?
<jelmer> pickscrape: please send it to me (jelmer@samba.org)
<pickscrape> Will do.
<pickscrape> jelmer: should the patch be against 0.4 or trunk?
<jelmer> pickscrape: 0.4 please
<jelmer> pickscrape: just "bzr send" should Do The Right Thing[tm] if you have bzr >= 1.3
<pickscrape> I guessed right then :)
<pickscrape> Just making sure my name etc is configured right for the commit.
<ignas> where can I find example of how to change 1 file and commit it to a branch using bzrlib without having a checkout
<ignas> if that's possible
<ignas> oh and tagging, yes, tagging
<james_w> I don't think you can do it without a checkout
<james_w> at least not easily.
<ignas> where can i read about the hard way?
<james_w> I doubt you can I'm afraid
<ignas> because i am already doing it with bzr co + shell script
<james_w> I'd have no real idea how to do it, I'd just know that you probably have to write a CommitBuilder, or perhaps somesort of Tree.
<ignas> i can see the CommitBuilder object
<ignas> but where do i find the information on how to use it
<james_w> I don't know I'm afraid.
<ignas> all my attempts at googling for this stuff end up in unrelated mailing list posts or bug reports ...
<jelmer> ignas: It should be possible by obtaining a CommitBuilder from the branch you would like to commit to
<jelmer> ignas: and then calling the methods on the object that is returned to you
<ignas> yeah, have that
<ignas> the methods are not very obvious
<ignas> i think "cb.new_inventory" is what i need
<ignas> but i am not really sure
<jelmer> ignas: Basically the idea is you call record_entry_contents() for each entry in the inventory
<jelmer> ignas: (even the unchanged ones)
<jelmer> ignas: then, call modified_file_text() / modified_link() / modified_directory() for each entry that was modified
<jelmer> ignas: then commit(message)
<ignas> modified_file_text is a method of what?
<jelmer> commitbuilder
<ignas> hmm, can't see it
<ignas> python prompt is giving me attribute not found on it
<jelmer> ignas: Ah, looks like that's been removed
<ignas> i see
<ignas> is there some place i can read about it? or did no one ever tried doing that before?
<ignas> how do you do such things in tests? or do you just modify the tree that you have checked out?
<jelmer> ignas: Please ignore me, it looks like modified_*() has been removed
<jelmer> ignas: Ah, you have to pass in a tree to record_entry that commitbuilder will get the text from
<jelmer> ignas: or something that has a get_file_text() method
<jelmer> ignas: lifeless and I wrote CommitBuilder a couple of years back, afaik there is no documentation (yet)
<ignas> :D
<ignas> not like you had time ;)
<jelmer> (-:
<ignas> so i should get a basis_tree, use some bzr magic to modify versions.txt.in in there, iterate through it's inventory and pass all the entries to CommitBuilder.record_entry_contents, passing that new tree as the tree parameter?
<jelmer> ignas: yep
<pickscrape> jelmer: Patch sent.
<ignas> jelmer: thanks, i'll try ;)
<jelmer> pickscrape: Any chance you can also add an entry to NEWS and a test in tests/test_svk.py ?
<pickscrape> Oh, sure.
<pickscrape> <bzr-newbie>Should I uncommit my change then, do the additional changes and then recommit?</bzr-newbie>
<jelmer> pickscrape: no, you should be able to just commit on top of your current commit
<pickscrape> OK. Figured you might prefer a 'cleaner' history, but I can do that.
<pickscrape> Was the method used appropriate or are there cleaner ways of doing it?
<jelmer> pickscrape: I mainly care about the cleanless of the mainline history. No matter how many revisions you commit, there will only be one merge commit on mainline for your changes.
<pickscrape> Ah, I get you.
<jelmer> pickscrape: In other words, "bzr log" will show one merge commit and your commits indented below that
<jelmer> pickscrape: The change itself looked fine
<pickscrape> jelmer: I'm having trouble with the test. it's written, but when I try to run it I get "NameError: global name 'parse_svk_features' is not defined"
<pickscrape> jelmer: Muppet alert (ignore me).
<ignas> jelmer: i have managed to retrieve the content of the file, but how do I change it?
<ignas> i have the branch, the tree, and the entry
<ignas> or must I create a new entry instead?
<jelmer> ignas: When you call record_entry_contents set ie.revision to None
<jelmer> (see the docstring of record_entry_contents())
<ignas> hmm, still not sure about it, i mean - it seems that record_entry_contents takes the new content using tree.get_file(ie.file_id)
<ignas> my question is - how do I put the new content into the tree
<ubotu> New bug: #213425 in bzr "push over sftp crashed" [Undecided,New] https://launchpad.net/bugs/213425
<pickscrape> jelmer: Further patch with NEWS entry and unit test added.
<jelmer> ignas: You have to override get_file() somehow
<ignas> oh
<Peng> The bug from that bug is running as root? :X
<jelmer> pickscrape: Thanks, merged :-)
<pickscrape> Sweet. :)
<ignas> jelmer: hmm if I try record_entry_contents on the entry i get a "file already under version control" error
<ignas> because the file path is the same
<ignas> and it tries to add the entry to the new_inventory
<ignas> i kind of assumed that when you record the root entry all the sub entries get added recursivelly, but it seems that the assumption was wrong too
<Peng> bzrlib/osutils.py is lazy-importing functions. Isn't that a no-no?
<abentley> Peng: no, that's usually okay.
<abentley> Functions are usually called, not used like variables.
<abentley> The first time you call a lazily-loaded function, the real function is substituted.
<abentley> If you happened to pass the function as an argument, that would be more of an issue.
<lamalex> Hey, if I've got a working tree with changes that aren't in the main branch, will bzr pull overwrite what I've got?
<jelmer> ignas: and you're adding it with the same file id?
<ignas> no, i god an error about the id being in the inventory already
<ignas> so  i tried changing the id
<asabil> lamalex: no, if there are any conflicts they will be reported
<Peng> jelmer: I've got another bzr-svn traceback for you. :) http://paste.pocoo.org/show/38420/
<Peng> jelmer: Latest bzr-svn 0.4 and bzr.dev as of 5 minutes ago.
<jelmer> Peng: the 0.4 branch is b0rked at the moment
<Peng> jelmer: "bzr svn-import http://svn.pyyaml.org/". Trying to branch an individual, err, branch also fails around the same place.
<Peng> jelmer: Heh, ok.
<Peng> jelmer: Was it borked on the 1st?
<jelmer> Peng: yep, has been broken for a couple of days
<Peng> jelmer: Nice. Ok.
<jelmer> Peng: I added a warning message a couple of hours ok
<jelmer> s/ok/ago/
<Peng> The "experimental" warning?
<jelmer> yep
<Peng> But that's always been there. :P
<jelmer> I occasionally add or remove it
<Peng> So, should I downgrade? What to?
<jelmer> Peng: for stability, use a release
<Peng> Bah, what's the fun of that.
<Peng> Can I at least use the bzr branches of the releases? :)
<jelmer> bzr pull --overwrite tag:bzr-svn-0.4.9 :-)
<jelmer> s/tag/-rtag
<Peng> s/pull --overwrite/revert/
<Peng> :)
<Peng> Way boring though.
<Peng> Hmmm.
<Peng> Lightweight checkout++.
<panosl> Hello. Trying to push a branch to a ssh repository: `bzr push bzr+ssh://myuser@myserver:6114/path/to/repo` returns an error: bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n"
<panosl> googling doesn't bring anything up
<james_w> panosl: what's the version of bzr on the remote end?
<ligemeget> Hi all, when I try 'bzr merge' in the relevant folder (to update from the main branch) I get an error which says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<ligemeget> What does that mean?
<panosl> 0.11 (ubuntu server), and my end is 1.2 (leopard)
<james_w> ligemeget: you are using a checkout of a branch over http, which you are not allowed to write to.
<jelmer> panosl: This is the bug that's fixed by bzr 1.3.1
<james_w> ligemeget: do you know if you did a lightweight checkout?
<ligemeget> james_w: Yes I did
<ligemeget> to save time - I didn't need any history
<james_w> jelmer: is it? I thought that was over http.
<panosl> Only updating my end?
<panosl> I can't update the server software
<james_w> ligemeget: ok, you probably want the switch command
<ligemeget> james_w: 'bzr switch'?
<jelmer> james_w: Oh, ok. I thought it was meant to fix errors like this as well
<jelmer> panosl: Looks like I'm wrong
<james_w> ligemeget: bzr switch bzr+ssh://ligemeget@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
<james_w> (assuming your lp username matches your IRC nick)
<james_w> jelmer: it looks like the remote end doesn't understand the request.
<james_w> panosl: I think you need to upgrade the version on the remote end, I'm not positive though.
<ligemeget> Warning: Permanently added 'bazaar.launchpad.net,91.189.94.254' (RSA) to the list of known hosts.
<ligemeget> Permission denied (publickey).
<ligemeget> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<james_w> ligemeget: have you given launchpad your ssh public key?
<ligemeget> james_w, ehh... I'm not sure..
<ligemeget> yes, my profile https://launchpad.net/~lhademmor lists an SSH key
<james_w> ah, did you replace your username in the command I gave you?
<gioele> hi
<ligemeget> yes
<james_w> ligemeget: ok, does "ssh lhademmor@bazaar.launchpad.net" work?
<james_w> hi gioele
<ligemeget> james_w: no. Permission denied (publickey).
<gioele> how short is the bzr release cycle? launchpad shows a 1.5 branch and a 1.4rc release
<james_w> ligemeget: ok, is your ssh key at ~/.ssh/id_rsa or ~/.ssh/id_dsa or something else?
<james_w> gioele: one month
<james_w> 1.4rc isn't released yet, I think it's just someone planning ahead.
<ligemeget> apparently none of those two. I have no idea where it is
<james_w> ligemeget: it's probably named something else in ~/.ssh
<james_w> if you can find it I can tell you how to make ssh use it automatically.
<gioele> ligemeget: ~/.ssh/identity?
<dato> ligemeget: what happens if you run ssh-add?
<ligemeget> dato: nothing
<ligemeget> There is only ~/.ssh/known_hosts in there
<dato> ligemeget: and how did you obtain the fingerprint you placed in your launchpad page?
<ligemeget> dato, I can't remember actually - it must be a long time ago
<dato> well, how about generating a new key then?
<gioele> is there a way to rebuild the bzr documentation? the online docs are scarce and outdated
<ligemeget> dato, fine. How do I do that?
<dato> gioele: they... are? I thought they were rebuilt nightly or something (http://doc.bazaar-vcs.org)
<james_w> ligemeget: ssh-keygen
<dato> ligemeget: /win 24
<dato> er, no :)
<ligemeget> james_w: "Enter file in which to save the key (/home/mp/.ssh/id_rsa):" - what do I enter?
<james_w> just hit Enter, if you use the default everything will fall in to place.
<ligemeget> passphrase?
<ligemeget> (should I enter one or not)
<james_w> yes, you should really.
<gioele> dato: I mean the API: http://starship.python.net/crew/mwh/bzrlibapi/
<ligemeget> james_w, okay I've generated a key. What do I do now?
<gioele> My week of hacking has been a pain, so few functions are documented
<dato> gioele: ah, sorry. dunno who's responsible for that, sorry.
<gioele> and the few documented functions do not document the type of the input parameters and of the return values
<james_w> gioele: I think it's mwhudson_ who created those.
<james_w> ligemeget: you need to tell launchpad about it.
<james_w> ligemeget: https://launchpad.net/~lhademmor/+editsshkeys
<ligemeget> james_w, done
<ligemeget> Still can't merge though..
<james_w> ligemeget: you did the switch?
<ligemeget> yep
<ligemeget> it said something about switching to branch ssh+bzr or something
<james_w> bzr+ssh:// hopefully.
<james_w> can you "bzr update"?
<james_w> ligemeget: ah, hang on, which branch are you trying to merge?
<james_w> this may be a bug, if the URL in the error message is the branch that you are merging from then it is a bug.
<james_w> if not then it is the problem that I thought.
<ligemeget> james_w, well I was trying to update ubuntu-doc (the Ubuntu Documentation) as a whole (hardy branch I think)
<james_w> ligemeget: what was the command you ran originally?
<ligemeget> james_w, 'bzr merge'
<ligemeget> (from the relevant directory of course)
<james_w> ok, can you tell me what the branches listed at the bottom of "bzr info" are?
<james_w> or, what saved branch it told you it was using.
<ligemeget> bzr info gives 'Location:
<ligemeget>   light checkout root: .
<ligemeget>    checkout of branch: bzr+ssh://lhademmor@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/'
<ligemeget> The same as in the errormessage except that ~ has become %7E
<james_w> ok, what was the branch you were a checkout of before, do you know?
<james_w> I fear I may have lead you up the garden path as I didn't think through what was causing the error.
<ligemeget> ...I'm not sure I understand that last question
<james_w> what was the URL you used originally when you ran "bzr checkout"?
<ligemeget> I never ran bzr checkout
<ligemeget> or what
<ligemeget> wait
<ligemeget> https://code.launchpad.net/ubuntu-doc <-- the hardy one listed on this page
<lamont> hrm... what was the magic test to see if bzrtools is non-b0rked?
<james_w> lamont: you mean upgrades on hardy?
<lamont> I mean on the dapper/edgy backports I just built
 * lamont found 'bzr shelve' :)
<james_w> ah, ok
<james_w> "bzr selftest bzrtools" is pretty good too.
<phanatic> jelmer: ping
<jelmer> phanatic: pong
<phanatic> jelmer: may i pm you?
<jelmer> phanatic: sure, always :-)
<phanatic> jelmer: did you get my lines?
<jelmer> sorry was busy with some other stuff
#bzr 2008-04-08
<poolie> hi
<jml> hi
<spiv> Oh wow, libcurl doesn't understand select.
<spiv> It thinks if a socket is in the exceptfds that it should raise an error.
<spiv> A generic "(55, 'select/poll returned error')"
<mwhudson> hello
<spiv> Hmm, and it treats poll similarly.
<poolie> hm that kind of sucks
<poolie> spiv, i'll call you in 12 minutes if that suits
<spiv> Sure.
<spiv> (I'm wondering why I'm seeing that error failing bzrlib.tests.test_bzrdir.ChrootedTests.test_open_containing all of a sudden)
<poolie> mwhudson: mark just asked about loggerhead, have you been able to work on it recently?
<lifeless> poolie: ping
<poolie> oing
<lifeless> I replied to a number of reviews; in particular the one with get_scope etc in it would like a reply back from you at your earliest convenience
<poolie> scared him off...
<poolie> ok
<spiv> Gar, it's timing related.
<poolie> spiv: can we postpone for a bit?
<spiv> poolie: sure
<poolie> someone just called me
 * spiv is chasing this spurious pycurl error
<mwhudson> poolie: no, not really :/
<lifeless> spiv: error?
<mwhudson> poolie: i did some work about 5 weeks ago i guess, but i kind of got stuck on how to do navigation well
<mwhudson> and then i got swamped by code import work
<spiv> lifeless: http://rafb.net/p/KgSYEC45.html, no changes from bzr.dev
<spiv> lifeless: something to do with how libcurl handles the 501 that SimpleHTTPServer generates when no do_POST method is defined.
<spiv> lifeless: if I do things like step through with the debugger, the error doesn't necessarily happen.
<spiv> lifeless: so at this point I'm guessing a bug in libcurl.  I'd just like to know more so I can file a useful bug report and find a reliable workaround.  (returning a 404 rather than 501, perhaps)
<spiv> I upgraded to hardy on the weekend, so maybe there's a behaviour difference vs. gutsy ehre.
<lifeless> hmm
<lifeless> I'm on hardy; never seen that
<spiv> Yeah.  There's something fishy.
<spiv> lifeless: fwiw, here's the relevant strace snippet: http://rafb.net/p/rjF7pW86.html .  Straight after that it starts reading .py source files to generate the traceback for the exception that was raised.
<lifeless> I don't see a socket error there
<spiv> Indeed.
<spiv> Just a closed connection.
<kgoetz> hi all. i was wondering if bzr could be set to pipe help into the system pager to stop it scrolling
<kgoetz> also, is it posable to merge branches with no shared history?
<bob2> what's your goal in the second question?  to e.g. create a tree with ./liba and ./libb where they were in the past two seperate branches?
<kgoetz> two seperate versioned directories called 'perlscripts', started on seperatee systems with mostly seperate files. i was hoping to merge them and keep the revision history
<bob2> I believe 'bzr join' will do that (maybe with some history-preserving mass mvs before hand) but not sure how supported that is
<kgoetz> thanks,i'll have a look at it. the history isnt to important, just 'nice to have'
<kgoetz> mmm. looks like bzr join wont do it. never mind. thanks for the help :)
<bob2> hm,it won't?
<kgoetz> by my reading they have to have been split from the same tree at some point
<bob2> I think the bit about branch is a bit confusing
<bob2> and just means that you branched something into a subdir
<poolie> kgoetz: there's no builtin option for it but it would be useful
<kgoetz> poolie: pity theres no option, i'd certainly find it handy :) is it worth doing a wishlist bug?
<poolie> kgoetz: just check first there is not already one
<kgoetz> poolie: sure :)
<bob2> hm, of the above, what does bzr join not do?  seemed to let me join two independent branches and then move the files into the one dir
<lifeless> kgoetz: merge --force will do it for you
<lifeless> poolie: ^ no special option needed :)
<lifeless> s/special/new
<kgoetz> whats the 'merge base revision'?
<lifeless> kgoetz: merge -r 0..-1 otherbranch
<kgoetz> neat.
<poolie> lifeless, kgoetz: oh i meant for paging help
<kgoetz> the dangers of askin multiple questions ;)
 * kgoetz checks bts for a pages bug
<lifeless> kgoetz: any reason '| less' isn't good enough ?
<kgoetz> lifeless: only that i'm looking at lots of help at the moment, so |less ing a lot is tedious
<lifeless> I tend to shift-up
<lifeless> to read stuff that scrolls
<kgoetz> i tend to use screen, where shift-up doesnt work
<lifeless> does for me :P
<lifeless> tho if I switch windows I need to use the screen paging facility
<kgoetz> arent you a lucky boy :p
<lifeless> ctrl-a [ pgup :)
 * kgoetz doesnt find that less anoying (but good to know for sure)
<mehemiah> hey, how does one change the format of a repo?
<spiv> bzr upgrade
<mehemiah> thanks, i couldn't find that  on any of the pages that concerned formats
<mehemiah> the online documentation and documentation needs to be improved emencly, Looks like I finally got an excuse to join this project.
 * mehemiah creates a launchpad account
<poolie> mehemiah: welcome
<poolie> why not send mail to bazaar@lists.ubuntu.com pointing out some improvements
<mehemiah> that works
<poolie> lifeless: hey
<poolie> i guess the thing about lock warnings or tests being "sufficient" or not is that, um, it seems like trying to prove a negative
<poolie> i can tell you for sure it will still be possible to get warnings with all the tests passing
<ubotu> New bug: #213718 in bzr "bzr could put help into pager" [Undecided,New] https://launchpad.net/bugs/213718
<lifeless> poolie: Phone perhaps
<bratsche> I'm getting crashers with 1.3.1rc1 (in Hardy) when I'm trying to commit to a server using 0.90.  It gives me a big stack trace followed by: AssertionError: 840 != 841
<bratsche> Where 840 is my current revno.
<bratsche> Does anyone know if that's a known issue?
<bratsche> It only seems to affect bzr+ssh:// transport.  When I switch sftp:// it is fixed.
<jelmer> bratsche: I've seen it before, but not quite sure what causes it
<mehemiah> so then it's a hash check error?
<lifeless> bratsche: I believe that is a fixed bug in newer bzr's, you should upgrade the server.
<bratsche> lifeless: Cool, thanks.  I'll pester Ubuntu people to update before Hardy comes out.
<lifeless> bratsche: what server is it ?
<bratsche> lifeless: 0.90 which I think is maybe the version shipped in Feisty.
<lifeless> I meant what machine ;) if its Ubuntu related I may be able to poke someone
<lifeless> there is a repository with builds of 1.3 etc for feisty or whatever Ubuntu version they are running
<bratsche> lifeless: No, it's a server at the company I work at.  We're still using 0.90 until all the engineers have upgraded.
<lifeless> ah
<lifeless> you do know you can upgrade the server earlier than the clients ?
<bratsche> Uhh.. I did not.
<bratsche> It doesn't really matter that much to me now, I changed all my scripts to use sftp:// transport instead of bzr+ssh:// now.
<jamesh> bratsche: you can also use the BZR_REMOTE_PATH environment variable to run a different bzr executable on the remote end
<jamesh> e.g. BZR_REMOTE_PATH=/path/to/bzr bzr push bzr+ssh://server/...
<bratsche> Thanks james
<bratsche> h
<lifeless> bratsche: generally you should run the latest bzr server version, all clients can use any version
<lifeless> bratsche: we add new network verbs rather than changing the meaning of old ones
<bratsche> lifeless: Cool, good to know.
<bratsche> lifeless: Thanks a lot!
<lifeless> bratsche: we will probably do some bulk removal of old slow methods at some stage; we'll advertise that very clearly when we do :)
<lifeless> another method bytes the dust of deprecation
<bratsche> We'll probably never be -that- far behind you.  I think everyone at work pretty much upgrades their Ubuntu as the new releases come out.  Some of us upgrade to the betas a little sooner than some of the others. :)
<lifeless> :P
<jamesh> bratsche: you don't have the bzr PPA in your apt sources? :)
<bratsche> Dude I don't even know what "the bzr PPA" is! :)
<jamesh> bratsche: https://launchpad.net/~bzr/+archive
<jml> hi
<jml> I have a feature request that I'd like to sanity check.
<jml> after pulling, I'd like to be able to:
<jml> - figure out what I just pulled (log & diff)
<jml> - 'undo' the pull
<jml> is that sensible? is it possible?
<Toksyuryel> doesn't it already support that?
<jml> in that case, I'm requesting instructions, not features :)
 * TFKyle sees a use for the former, normally just remembers where he last was and uses bzr visualize/bzr log though
<TFKyle> (though, it does show what files have changed already when pulling iirc)
<Toksyuryel> I imagine you'd do it the same way you do local commits
<jml> TFKyle: I use version control so I don't *have* to remember things.
<spiv> jml: "bzr pull -v" is part of the answer
<mwhudson> i think the problem is know what the branch tip was before you pulled
<Toksyuryel> diff the revsion numbers from before and after the pull, and uncommit the pull revno if you don't like it
<TFKyle> could use tags liberally :D
<mwhudson> knowING
<mwhudson> the rest is easy enough
<spiv> jml: that gives you logs
<jml> spiv: that's certainly better than nothing.
<jml> Toksyuryel: how do you figure out the revno from before the pull though?
<spiv> jml: and you can easily figure out from that what the revnos to use for diff or "bzr pull -r OLD_REVNO"
<Toksyuryel> jml: log
<jml> spiv: that approach certainly requires the least amount of foresight.
<jml> Toksyuryel: you'll have to be more specific.
<Toksyuryel> jml: just use log the same way you use it for local commits
<jml> Toksyuryel: you mean look until I find a revision that I recognise as being from before the pull?
<Toksyuryel> the commit for the pull should be clearly labeled, unless you're Doing It Wrong
<spiv> jml: add a "pull=pull -v" alias to your bazaar.conf?
 * jml is Doing It Wrong apparently
<TFKyle> Toksyuryel: afaik pull doesn't require commits, just merge
<Toksyuryel> TFKyle: isn't undoing it the same function though?
<jml> spiv: right, that lowers the foresight factor even more.
<spiv> jml: what foresight is still required?
<Toksyuryel> as I recall any change gets logged and compressed in the store, which would include snapshots of before and after merges
<jml> spiv: none. :)
<TFKyle> Toksyuryel: merges yes, but I don't think pull operations
<spiv> jml: ah :)
<TFKyle> (could be wrong though, just they aren't mentioned in bzr log/etc.)
<Toksyuryel> TFKyle: then that should be a feature to be added, as it would help streamline things a great deal
<Toksyuryel> I always thought pull was handled like a merge
<TFKyle> (though, for the undo part you might actually want to use merge/commit)
 * Toksyuryel afk to watch a movie
<spiv> Toksyuryel: pull is basically "update my local mirror of a remote branch"
<Toksyuryel> spiv: ohhh, I see
<Toksyuryel> that makes sense then
<spiv> Much like push in the other direction :)
<spiv> Toksyuryel: enjoy the movie
 * Toksyuryel afk for reals now
<ubotu> New bug: #213769 in bzr "KnitCorrupt thrown when doing diff" [Undecided,New] https://launchpad.net/bugs/213769
<ubotu> New bug: #213771 in bzr ""not updating child fraction" filling up log file" [Undecided,New] https://launchpad.net/bugs/213771
<ubotu> New bug: #213792 in bzr "status display of pending merges is slower than merge" [High,Confirmed] https://launchpad.net/bugs/213792
<sssslang> hi, i'm a little confused. could someone tell me how to make revno like x.x instead of x? i wanna use x.x to tag little changes in my programs.
<Toksyuryel> spiv: thanks, I did ^^
<Toksyuryel> sssslang: revnos are just for tracking commits, you can use the "tag" function for actual releases or really anything you want
<Toksyuryel> the dotted format of revnos is used for tracking merges, so it would be confusing to also use it to mean "minor commit" (which is usually redunant, since most commits are minor)
<spiv> Toksyuryel: :)
<Toksyuryel> spiv: I watched "Into The Wild". It was an interesting take on the book. I thought the ending was too gruesome though :(
<Toksyuryel> but overall, worth watching
<sssslang> Toksyuryel: thanks. so you mean i should always use bzr ci wheather the changes are major or minor, and tag the former with bzr tag?
<Toksyuryel> sssslang: revnos aren't version numbers, it'd helpful not to think of them as if they were
<spiv> Toksyuryel: Ah, I've heard of that.  Thanks for the review!
<Toksyuryel> since most commits are minor, it'd be better to tag the major ones (though generally a descriptive commit message works just as well)
<Toksyuryel> spiv: you're welcome^^
<sssslang> Toksyuryel: i see. thank you.
<Toksyuryel> should read the book too, if you haven't. the movie kinda glosses over some of the details, and takes a few liberties with the story.
<Toksyuryel> why is the bzr website rss feed useless =/ I just wanted to track news, not every single little change to the website itself >.<
<ubotu> New bug: #213851 in bzr "bzr push error" [Undecided,New] https://launchpad.net/bugs/213851
<Peng> That error is getting popular.
<Kamping_Kaiser> grab yourself some karma ;)
<asabil> hi all
<asabil> is it technically feasible to come up with a repository/branch format that allows internal branches ?
<asabil> in a similar manner to git ?
<james_w> asabil: yes, it is.
<james_w> there is some debate about the best way of doing that, but it is possible.
<asabil> ok thanks
<asabil> do you allow me to quote this on a mailing list ?
<james_w> yeah, go ahead.
<asabil> thanks
<asabil> it seems to be one of the most wanted features among GNOME developpers
<Peng> jelmer: Is it dangerous to use the same svn-cache with 0.4.9 and the 0.4 branch?
<jelmer> Peng: yes
<Peng> Great.
<jelmer> the 0.4 branch may put garbage in there
<Peng> If it did screw it up, will it be obviously broken (instant traceback), or could weird subtle things happen?
<Peng> How much of a pain would it be to just delete the whole cache, even for largish repos?
<jelmer> deleting the cache shouldn't be much of a problem with >= 0.4.9
<jelmer> weird subtle things could happen
<Peng> Fun stuff.
<Peng> Well, I needed to garbage-collect it anyway...
<Peng> Whee, 0.4.9 tracebacked too; it just too longer.
<jelmer> please file a bug :-)
<Peng> Errrr, ok.
<ubotu> New bug: #213946 in bzr-loom "After local branch of loom I receive unusable loom" [Undecided,New] https://launchpad.net/bugs/213946
<Peng> Bug 213953
<ubotu> Launchpad bug 213953 in bzr-svn "NoSuchRevision while importing http://svn.pyyaml.org" [Undecided,New] https://launchpad.net/bugs/213953
<Peng> :)
<ubotu> New bug: #213953 in bzr-svn "NoSuchRevision while importing http://svn.pyyaml.org" [Undecided,New] https://launchpad.net/bugs/213953
<Peng> Helpful, ubotu...
<mw-home> simple bzr question.  is it true to say that generally, the working copy is the repository?
<mw-home> If so, how do I back up my repository?
<radix> mw-home: no. the repository is in .bzr/repository :-)
<radix> mw-home: generally, the way to back up bzr stuff is to push a branch somewhere.
<mw-home> radix: thanks.  Maybe I should schedule a daily cron job to push out my repo to another server.  Is that really the recommended way to back up>?
<radix> mw-home: I recommend it :)
<mw-home> is it possible to compare the status of one branch vs another?
<mw-home> before I do bzr push, I want to know what WOULD happen.
<radix> mw-home: I'm guessing at what you want, but it may be "bzr missing"
<radix> It tells you which revisions your branch has that the other doesn't, and vice versa
<mw-home> radix: yeah, bzr missing looks right.  thanks!
<jelmer> Peng: funnily enough, this bug is fixed in the 0.4 branch
<Peng> jelmer: Hah.
<mw-home> I'm having a hard time understanding branch in bzr vs branching in subversion.  in svn, many branches exist inside the same repo.  in bzr, it seems like each branch is a separate repo.
<Peng> mw-home: Yeah.
<mw-home> so, in bzr, do people merge and destroy branches in the same way?
<Peng> mw-home: Err.
<Peng> mw-home: Ok?
<Peng> mw-home: You can merge between branches (unlike svn, it actually works, but that makes cherrypicking difficult), and you can delete any rbanch you want..
<mw-home> i think i just need to keep using bzr and over time hopefully it will become intuitive.
<Peng> :)
<Peng> Well, it's supposed to be intuitive from the start...
<Peng> Have you been reading the docs?
<mw-home> yeah, been reading.  i like the different workflows.  very good.
<mw-home> very nice pictures too.
<awilkins> mw-home: You can branch with a shared repo, consumes less disk space and is a lot faster for big repos
<mw-home> awilkins: thanks.
<mw-home> bzr vimdiff won't play nice with -c 876.
<abentley> mw-home: Only certain commands support -c, and vimdiff is a plugin that was written long before it.  However, diff --using vimdiff ought to work with -c.
<mw-home> abentley: I tried bzr diff --using vimdiff. Got an error: $ bzr diff -c 512 --using vimdiff ../__init__.py
<mw-home> === modified file 'bazman/bazman/__init__.py'
<mw-home> Vim: Warning: Output is not to a terminal
<abentley> mw-home: Do you have the diffutils plugin installed?
<mw-home> abentley: i don't think so.
<mw-home> diffutils isn't listed on the plugins page.
<abentley> Ah, it's because I actually use gvimdiff.
<mw-home> abentley: you use --using gvimdiff?
<abentley> yes.
<mw-home> ok, --using gvimdiff works fine.  Thanks!
<abentley> No problem.
<abentley> I guess interactive console differs don't play nice with --using.  Non-interactive ones like colordiff work fine.
<mw-home> what is colordiff?
<mw-home> never mind
<Vantage> hi, does bzr support bzr switch for heavyweight checkouts or is it still just for lightweight checkouts?
<jsled> I'm in a locally-repeatable siutation where `bzr push bzr+ssh:[â¦]` seems to terminate with return code 0 after a few (~20) seconds on the server, but does nothing on the client for many minutes, when it eventually times out.
<jsled> This leave an open lock on the server side, and no actual push being accomplished.
<jsled> How to go about debugging?  How to get the '-v' passed to `bzr server` when its invoked on the server side?
<james_w> jsled: do "bzr -Dhpss push bzr+ssh://" and read ~/.bzr.log afterwards, that may provide some clues
<james_w> also ssh to the server and read ~/.bzr.log there as well
<james_w> (by read I mean read the end).
<jsled> The server's ~/.bzr.log is where I'm seeing the timing and "return code 0".
<james_w> ah, there's no other message?
<jsled> There are some other lines about loading plugins, arguments and encoding.
<jsled> they look innocuous, but I can pastebin if you like.
<james_w> yes please, there might be something.
<jsled> http://pastebin.ca/977410
<james_w> yeah, that's really helpful isn't it.
<james_w> does -Dhpss on the client tell you anything?
<jsled> That's from running it as `bzr -Dhpss push` (with a previously-remembered path); the client side is still sitting there.
<james_w> ah, -Dhpss only affects the client.
<jsled> No; no extra detail ("-Dhpss"?   How should I expand/read that?  Is it a acronym or mnemonic or?)
<james_w> what may work is to use BZR_REMOTE_PATH to change the arguments it is invoked with
<james_w> however that may just fall over and tell you it can't find "bzr -Dhpss" or something.
<jsled> If I do something like `BZR_REMOTE_PATH=/usr/bin/bzr serve -v`, then it ends up running {/usr/bin/bzr serve -v serve --inet [â¦]} on the server, which fails.
<jsled> Er.  Something like... `BZR_REMOTE_PATH="/usr/bin/bzr serve -v" bzr break-locks`
<james_w> what about "BZR_REMOTE_PATH=/usr/bin/bzr -Dhpss"?
<jsled> "return code 0" after 18.386 seconds. :(
<jsled> And a client just sittin'.
 * jsled tries BZR_REMOTE_PATH="strace bzr"...
<james_w> :-)
<mwhudson> yikes
<jsled> The last things I see are a series (~4) of read(0, "[â¦]"..., ...) = 16384.  then a "read(0, ", and nothing else.
<jsled> On the server side, 0 is stdin (IIRC?)... so it's maybe waiting on reading pushed data from the client side?
<james_w> you don't have anything like a ssh proxy in the middle do you?
<jsled> Not that I'm aware of.  There is a 15-25% packet loss near the server, but a separate interactive SSH to the same box is fine.
<jsled> I thought it might be the EscapeChar, but I updated ~/.ssh/config for that host without change.
<jsled> Hmm.  When using bzr+ssh over a vpn rather than public internet, it looks like it's working.
<Stavros> hello
<Stavros> i have set up a read-only repo and want other people to send me their patches with bzr send
<Stavros> what is the best way for them to send me them on a per-feature basis?
<Stavros> obviously i'd think that one big send with a few commits for various features wouldn't work, since i want to pick and choose, correct?
<beuno> Stavros, that sounds a bit of a workflow problem rather than a setup problem
<Stavros> hmm
<beuno> how can you restrict users to specific features?
<Stavros> not users, programmers
<Stavros> i want to screen all new features before committing them in the main repo
<beuno> unless, of course, you have a branch per feature, which might be a bit messy depending on what the project looks like
<Stavros> hmm, yes
<beuno> Stavros, well, you have PQM that might help
<beuno> and bundlebuggy, which might be a bit too hard to setup
<Stavros> it's not a big project, so i want to avoid setting up complicated stuff if i can :/
<Stavros> it's really mostly a matter of "how do i get someone to send me three features separately"
<beuno> Stavros, ask them to  :)
<beuno> make them setup feature branches
<Stavros> ah, feature branches
<beuno> work on a feature in each branch
<Stavros> and then do "bzr send" from each one?
<beuno> yeap
<Stavros> good good, that's what i was thinking
<beuno> keep a main one updated to compare to
<Stavros> and how do i commit these patches when i decide to?
<Stavros> yes
<beuno> Stavros, bzr merge file.patch
<lamalex> Can I undo a bzr merge of a patch?
<beuno> lamalex, you can revert to a previous commit with either bzr uncommit, to erase that it ever happened
<Stavros> oh, thanks
<beuno> or you can do bzr revert -r X
<beuno> to revert to a specific revision
<beuno> and commit that, which will leave a history of what happened
<Stavros> is pqm hard to set up?
<beuno> Stavros, AFAIK, yes  :)
<Stavros> ah :/
<Stavros> is there a working example of it anywhere?
<Stavros> or a description of what it is exactly?
<beuno> Stavros, lemme look
<Stavros> or both? :P
<beuno> Stavros, all I can fine is: http://bazaar-vcs.org/IanClatworthy/CoreDeveloperHandbook?#an-overview-of-pqm and https://launchpad.net/pqm
<lifeless> beuno: pqm is not relevant here
<Stavros> lifeless: where?
<lifeless> Stavros: I suggest 1 branch per feature; if you have features that depend on each other, use looms
<lifeless> pqm is for enforcing merge policies
<Stavros> lifeless: oh, that's what i'll do, i was just asking about pqm out of curiosity... what are looms?
<beuno> lifeless, right, I understood this later on in the conversation
<lifeless> you want to screen features yourself, so pqm is unrelated
<lifeless> Stavros: https://launchpad.net/bzr-loom
<Stavros> oh hmm, thanks
<beuno> right, bundlebuggy might be more appropriate for that, but I think it doesn't fall under the "easy to setup" category either
<Stavros> eh, how hard can it be :P
<Stavros> oh
<Stavros> quite hard, it seems :p
<Stavros> it's ok, i'll do this by hand then, it's just one person anyway
<Stavros> pqm looks nice for automated testing etc
<Stavros> really handy
<lifeless> abentley: ping
<lifeless> abentley: I'm changing knit annotation
<abentley> lifeless: on a call
<lifeless> abentley: ok; I'll just dump here and you can comment when you have a chance
<lifeless> Basically I'm adding a iter_annotations to access annotation across multiple things; this seems in line with other changes
<lifeless> The top level questions are: do you think this is a good thing to do, and what should the signature/api be. I think that annotations are more likely to be order-sensitive than regular file texts.
<lifeless> so I'm planning on iter_annotations(iterable of keys) -> iterable of the annotations in the order of the key iterator
<lifeless> the alternative I was considering was
<lifeless> iter_annotations(iterable of keys) -> iterable of (key,  annotation) in any order - allowing memory/speed tuning within the memory
<lifeless> a third alternative is to just keep the annotate a single text interface
<lifeless> opinions solicited
<lifeless> an orthogonal question is whether each individual annotation should be a list or an iterator
<lifeless> for now I'm intending an iterator because annotate_iter seems to be the preferred api
<lifeless> oh, and I think the final thing is whether to yield None, or to raise RevisionNotPresent for absent keys
<lifeless> given the ability to hand iterators around, I feel like yielding None
<abentley> I think None is usually a better answer for bulk operations.
<abentley> I don't see a great need for iterating many files at a time.
<abentley> Or even many versions of the same file.
<lifeless> so the easier thing to do then is just to deprecate one of annotate/annotate_iter
<lifeless> which would you rather keep? (I'm asking you because you've used annotate more than anyone I think)
<abentley> I think annotate.  Realistically, the first thing I do with annotate_iter is listify it.
<lifeless> ok
<lifeless> one annotate_iter deprecation coming right up
<abentley> Since annotate is currently a slow operation, it would be nice to have an interface that provided incremental updates.  But that's something for another time, I expect.
<lifeless> abentley: done; testing
<lifeless> abentley: I'm nearly at the end of trimming the api; yay
<abentley> Cool.
<lifeless> 6 patches sent to BB yesterday I think
<abentley> Yeah, the pending queue is back up to 36
<abentley> After we'd gotten it down to 25.
<lifeless> mark hammonds document is kinda unweildy to review
<Stavros> is there a way to get bzr to output the patch file it would send with "bzr send"? (mail client problems)
<beuno> Stavros, bzr send -o file.patch
<Stavros> oh, thanks!
<Stavros> i can't believe i missed that
<lifeless> or -o-
<Stavros> is that for stdout?
<lifeless> yes
<Stavros> ah, thanks
<lifeless> you can also use diff -r submit: to see the patch without a bundle at all
<Stavros> hmm, i have a patchfile but "bzr merge file.patch" won't do anything
<Stavros> well, it does say "Nothing to do."
<lifeless> is it a bundle (was it made with send ?))
<Stavros> yes
<lifeless> then its probably a branch you've already merged :P
<Stavros> oh wait
<Stavros> the mail client prepended spaces to each line :/
<Stavros> but now it tells me "revision 'blah' not present in 'inventory'"
#bzr 2008-04-09
<lifeless> I think thats a possible occurence when you cherrypick with a reference branch that has more data than the actual branch you are merging too
<lifeless> what command did you use to create the bundle ?
<Stavros> just bzr send --mail-to=bla . remote-branch
<lifeless> bbiab sorry
<Stavros> np
<jelmer> Stavros: the branch against which it will generate the bundle is the first argument
<Stavros> oh :/
<jelmer> so you probably want to swap the arguments
<jelmer> the second argument defaults to "."
<Stavros> ah, this was the command: bzr send -r 269 -o file.patch .
<Stavros> so the "." needs to be the branch url?
<Stavros> ah, that worked, thanks
<Stavros> this "bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]" is a bit confusing, i took "public branch" to mean the remote branch
<abentley> jelmer: Actually, the second argument doesn't default to anything.  If you don't supply it, no source_branch appears in your merge directive.
<ubotu> New bug: #214298 in bzr "'bzr pull' internal error parsing for an int in bzr 1.3" [Undecided,New] https://launchpad.net/bugs/214298
<Stavros> hmm okay, i've merged the changes, which were apparently done while the branches diverged... what do i do now?
<Stavros> are the changes only in the working copy, or do they appear as a commit in the repo?
<Stavros> bah, i don't understand this bundle thing...
<Stavros> now there are "pending merges" in my repo
<bob2> backing up a bit, did you commit after merging?
<Stavros> well, i edited the changes because the branches had diverged, so i redid what i had done in the intermediate commits
<Stavros> and i haven't committed yet, no
<Stavros> i thought bzr's merge would take care of the diverging, though...
<bob2> a merge isn't recorded until it is commited
<Stavros> aha
<Stavros> so how do i commit it to make sure the developer and his commit message is preserved?
<bob2> well, the working copy records that there are pending merges, but it's not recorded in the branch
<Stavros> aha
<Stavros> so if i wanted to get rid of it i'd just revert?
<bob2> when you merge from someone ele, you create a new commit, saying "merged blah blah" and that commit will incorporate the merged work
<Stavros> aha
<Stavros> so now i need to actually commit that?
<Stavros> and what happens now that i edited the working copy?
<jelmer> abentley: ah, ok
<bob2> well, I dunno what you've done since - but you only want to commit the merge itself + any fixups needed
<Stavros> i just changed a few lines in those files, and they reappeared unchanged, since the revision was old
<bob2> if you want to go back to where you were before any of this, bzr revert --forget-merges will get you back to the last commited state
<Stavros> aha
<Stavros> so if i commit now it should commit the correct, changed thing?
<bob2> I've lost track of what you've done, sorry, but if the only changes you've done were "bzr merge someurl ; vi blah blah" then commiting now is what you want
<Stavros> well, let me explain
<Stavros> a dev made a change to a file, and i did too, at the same time
<bob2> but I've got to head, so sorry and good luck :)
<Stavros> oh
<Stavros> thanks :)
<Stavros> i have to go too, come to think of it
<Stavros> thanks for your help
<lifeless> bob2: --forget-merges is different to what you describe
<lifeless> Stavros: I have a suggestion for you
<lifeless> Stavros: forget bundles for a bit; just work with regular branches on your local disk
<Stavros> i have
<lifeless> Stavros: bundles don't alter the workflow, all they do is provide a different transport
<Stavros> i can't do what i want without bundles, sadly :/
<Stavros> yes, i just expect this transport to work like branches, and it looks like it doesn't
<Stavros> because branches would have merged the changes correctly
<lifeless> once you get bzr's workflow without bundles, bundles drop in transparently
<lifeless> Stavros: if you can put up a script showing what you did we can help you understand what is going on
<Stavros> hm, let me try to summarize
<Stavros> person A makes a change, person B pulls and makes a change, person A makes another change and person B sends his change to A
<Stavros> now, person A does bzr merge and the merged file has lost that last change from A
<lifeless> this is very hand wavy
<lifeless> I can't tell if you are missing key steps like 'push' 'commit' etc
<Stavros> hmm
<Stavros> what do you want me to write exactly? the commands?
<lifeless> that would be ideal
<Stavros> (i don't know the exact commands of the other person, though)
<Stavros> ok, sec
<Stavros> let me get a pastebin
<Stavros> how about this? http://dpaste.com/43838/
<lifeless> right
<lifeless> 'pull' means 'become the contents of $URL
<lifeless> if you pull and both you and someone else have done work, you get an error
<Stavros> even if the branches have diverged? shouldn't it warn?
<Stavros> yes
<lifeless> if you force it, you lose your work
<Stavros> i didn't force it, though
<Stavros> just pulled
<lifeless> in general you should use *merge* to integrate other peoples work
<Stavros> aha
<lifeless> and pull when maintaining a mirror of another branch
<Stavros> but merge does the same, it just doesn't commit
<lifeless> merge does *not* do the same
<Stavros> it did :p
<Stavros> let me try it again
<lifeless> merge integrates two branches into an intermediate state in your working tree
<Stavros> yes
<lifeless> the subsequent commit will record the combined work
<Stavros> no argument there
<Stavros> i'm saying that the merging didn't work correctly
<Stavros> because it still gives me the other person's changes
<lifeless> well you didn't have 'merge' in that transcript
<Stavros> instead of both of the changes merged
<Stavros> yes, i did it now
<Stavros> replace the last "pull" with "merge"
<lifeless> so, in the absence of knowing what B did, I have to assume they overwrote your changes
<lifeless> so bzr is seeing: change 1, change 2, change 3(reverses 2), change 4
<lifeless> all in a series
<lifeless> however, we can debug this
<lifeless> 'bzr log'
<lifeless> will show you the history
<lifeless> invluding all the actions taken by B (not at command level, but as outcomes)
<Stavros> yes, that doesn't show the last one, because i merged and didn't commit yet
<lifeless> bzr log -v will show a summary of the action changes
<lifeless> so commit ;)
<Stavros> ah, sec
<lifeless> bzr diff -r X..Y will show the changes between X and Y
<lifeless> bzr diff -c Y will show the change committed in Y
<Stavros> ok, done
<lifeless> we can use this to figure out where the change from line 12 went
<Stavros> actually, it was more like "i made changes in lines 30-40, the other person made a change to line 1 (with the old lines 30-40), and now bzr replaced my change with his lines"
<Stavros> so it just reverted to the old ones
<lifeless> thats what you are seeing
<Stavros> yes
<lifeless> and bzr can tell us when it happened
<Stavros> ah
<Stavros> bzr log doesn't show much more, it just shows what i said
<Stavros> old lines being added
<lifeless> so use bzr diff
<Stavros> err, i mean diff, sorry
<lifeless> it shows the old lines being reinstated during his commit ?
<Stavros> yes
<lifeless> was his commit a merge ?
<Stavros> let me check log
<lifeless> anyhow, basically what you have here is person B reverting your change in some manner, and bzr faithfully bringing the reversion back to you
<Stavros> it doesn't say, it just says "committed", but i don't think it was a merge, there wasn't anything he could have merged
<Stavros> yes, exactly
<Stavros> but what's puzzling is that bzr should be smart enough to undo that, shouldn't it?
<lifeless> no, its not meant to undo it
<Stavros> if we both diverged from a single graph node, shouldn't it merge both our changes?
<lifeless> if he incorporated your change
<lifeless> hang on
<Stavros> ok
<lifeless> if he incorporated your change into his tree
<lifeless> and decides its wrong
<lifeless> so puts it back
<Stavros> oh, i don't think he did...
<Stavros> ah
<lifeless> and then you merge from him
<Stavros> maybe he mixed something up in the working copy...
<Stavros> i see what you're saying
<lifeless> bzr is *meant* to put it back in your tree
<Stavros> yes
<lifeless> this isn't a *failure to merge*
<lifeless> this is *merging a reversion*
<Stavros> yes, but this assumes that he consciously reverted it
<lifeless> and you can tell its that because in his commit you can see the reversion
<Stavros> aha
<lifeless> this could be a mistake - new toolchain etc
<lifeless> or it could be deliberate
<lifeless> bzr can't tell you that sorry :P
<Stavros> it's probably a mistake, because it's two lines
<Stavros> hmm
<Stavros> it's odd though, it's not an easy mistake to make, is it
<lifeless> merge; revert FILENAME; commit
<lifeless> that will do it
<Stavros> yes, that's a conscious revert
<lifeless> merge; revert; commit
<lifeless> that won't do it
<lifeless> because 'revert PATH' preserves pending merges.
<Stavros> ah
<lifeless> whereas 'revert' clears the pending merge list
<lifeless> (bzr help revert)
<Stavros> hmm yes
<Stavros> or perhaps he forced a commit after pulling and bzr warning him the branches had diverged
<lifeless> so in particular, 'bzr revert .' after a merge will discard all the content of the merge while preserving the fact of the merge
<Stavros> but hmm, wouldn't it incorporate the merge in the working copy when pulling?
<Stavros> aha
<Stavros> well, i'll just do this by hand then, it's not a big deal
<Stavros> thanks a lot for your help!
<lifeless> so; you shouldn't need to do anything by hand :P.
<lifeless> in particular to get your changes back now:
<lifeless> bzr merge . -r X..Y
<Stavros> wait, what does that do?
<lifeless> where X is the commit before Y and Y is the commit where you put those two lines in
<Stavros> oh wow
<Stavros> let me do that
<lifeless> will merge from your own history the change he discarded
<Stavros> if that works, it will be very very cool
<Stavros> actually wth, those commits where a while ago
<Stavros> how did he manage that? damn
<Stavros> apparently those changes were done in two different revisions
<Stavros> hey, what do you know, that DID work!
<Stavros> that's great!
<lifeless> Stavros: :)
<spiv> poolie: I attached that branch to that bug
<lifeless> another one sent :)
<poolie> hello
<lifeless> spiv: call ?
<lifeless> spiv: I want to talk about the repository get stream smart method
<jml> hello every body!
<jml> I was just talking to a friend who is playing around with Launchpad on his Windows box that's living inside a corporate firewall.
<jml> we hit https://bugs.edge.launchpad.net/bzr/+bug/190209 -- xmlrpc doesn't respect $http_proxy
<ubotu> Launchpad bug 190209 in bzr "launchpad plugin xmlrpc does not use $http_proxy (branching lp: uris does not use system http proxy)" [Medium,Confirmed]
<jml> but, I was thinking, I bet he doesn't have any environment variable with proxy settings
<jml> on account of being on Windows
<jml> which led me to wonder, what *should* we do for proxy settings on Windows?
<poolie> i think there should be a per-location configuration variable
<markh> fyi, its possible to fetch the IE proxy settings.  UUIC, firefox stores its own - I assume in the profile directory
<lifeless> markh: hi
<poolie> hello markh
<lifeless> markh: your strategy document; I have a comment to make - I think it would be better to say 'we are going to do X, Y and Z. We chose this because: ... historical exposition and status of things'
<poolie> are you (still) in china?
<poolie> lifeless: re the knit index, i'd be inclined not to expose it
<jml> markh: I think I'd like Bazaar to do that.
<markh> poolie: Hi - I'm leaving on Saturday
<jml> but the first iteration should be variables in the config file.
<abentley> What should I do about xml8?  Ian sorta reviewed it, but said he wasn't sure he should cast a binding vote.
<lifeless> markh: right now, when I read it to review it comes across as a very informative document, but you have to get to the end always
<markh> lifeless: you mean explicitly make decisions?
<abentley> (due to his inexperience with that code)
<lifeless> abentley: I have one more major thing I feel very urgent to do - killing knit joins
<lifeless> abentley: then I'll do a review of the code in detail for you
<lifeless> markh: yes!
<lifeless> markh: open questions are things for the list; decisions are things for the tree.
<abentley> lifeless: okay, thanks.
<lifeless> markh: if the decision can't be taken yet, thats fine- it can still go in the tree.
<lifeless> markh: but if it *can be taken*, we should take it. We *can* change our mind later.
<markh> lifeless: yes, I agree, thanks.  In the initial drafts I didn't want to come across as having pre-conceived decisions without relevant consultation.  I agree I should re-edit it to reflect the fact it does seem to have consensus.
<lifeless> markh: I appreciate your tact; however I encourage you to lead where you know the territory
<markh> its was more a "new kid on the block" thing :)  I'll do that in the future as I get known better
<markh> thanks though!
<poolie> lifeless++
<markh> so re IE proxies, the next pywin32 build should be able to do everything IE can wrt proxies, including auto-detect, and proxies specified on a per-url basis (or per-zone, or whatever it is that IE does).  That should be out in a few weeks (or maybe even days!)
<poolie> nice
<markh> simply by calling 2 functions exposed by winhttp.dll, but that's ok
<markh> so I guess doing it now with ctypes would be fairly easy
<abentley> Odd_Bloke: Are you planning to update your patch for check?
<lifeless> lunch
<Verterok> moin
<poolie> hello
<Verterok> hi poolie
<Verterok> a quick question, bzr still supports non-dirstate branches?
<poolie> ppa documentation patch sent to pqm
<poolie> Verterok: do you mean older formats?
<poolie> yes, older formats are still supported
<poolie> back to about 0.1
<Verterok> I suppose so
<Verterok> poolie: thanks, I asked because to improve bzr-eclipse decorations I wrote a dirstate reader in Java :)
<poolie> oh i see
<lifeless> some emacs dude did this too
<poolie> well, that should cover almost all users
<lifeless> I think we should change dirstate every release now
 * poolie starts releasing 1.3.1
<Verterok> lifeless: I get the idea from there
<Verterok> oh, great!
<lifeless> because it is totally unsupported to do that
<poolie> well, now
<poolie> i think people can rely on us not changing the format without changing the format string
<lifeless> they can
<Verterok> lifeless: it's just a temp workaround, until the xml-thing get's finished
<lifeless> but we should be able to rely on people not reading our gizzards
<Verterok> lifeless: I agree, actually the this java "dirstate reader" only support format 3, and check this, if it's not format 3, it fallback to 'bzr inventory'
<lifeless> Verterok: why have the reader at all if inventory is sufficient?
<Verterok> in a small tree the it is ~15x times faster
<lifeless> Verterok: I think that the time would have been better spent fixing bzrlib.builtins.cmd_inventory to be 15 times faster
<Verterok> I'm sure that most of the time is used in the startup of 'bzr inventory'
<Verterok> lifeless: sure, I could try to improve inventory
<Verterok> but I really don't know how to/where start :-P
<lifeless> bzr --lsprof-file=foo.cachegrind inventory
<Verterok> lifeless: thanks
<lifeless> poolie: abentley: spiv: I have sent an RFC about fetch/join etc to the list
<lifeless> would be obligated if you could eyeball
<poolie> my Make is a bit rusty...
<poolie> thanks for your detailed comments on my page designs :-P
<poolie> :)
<jamesh> spiv: I sent an updated post_change_branch_tip hook patch that merges Ian's work with mine
<abentley> jamesh: Why isn't branch one of the ChangeBranchTipParams?  It seems funny to have a tuple where one of the items is just a bag of data anyway.
<jamesh> abentley: because that's what Ian's branch had?
<lifeless> poolie: well, its pretty much what we've all been saying for months, so I didn't see anything to disagree with or suggest something different
<abentley> jamesh: Well, he's not around, and you're the one submitting the code...
<jamesh> abentley: I've got no problem making the change you suggested
<jamesh> abentley: and Ian's branch never actually called the hooks so I doubt he was depending on it :)
<abentley> I'll just see what else is out there.
<poolie> lifeless: ok, i'm glad you agree
<poolie> or indeed more than agree
<lifeless> abentley: thanks
<lifeless> abentley: replied
<abentley> jamesh: Yes, if you could make that change, I'd appreciate it.
<poolie> oh interesting, 'make check' seems to fail at the moment because of something broken in hardy's libraries
<poolie> hm
<abentley> lifeless: So the data stream would be tagged to indicate whether the texts were annotated/unannotated?
<poolie> could people please run
<poolie> python -Werror -c 'import xml.etree.cElementTree'
<poolie> and tell me if it works?
<poolie> lifeless: ^^
<Verterok> poolie: works fine in OS X 10.4 (ppc), python-2.5
<poolie> thanks
<lifeless> abentley: yes, the data stream is self delimiting in that respect (see knit.get_data_stream)
<lifeless> poolie: can you ls  ls /usr/lib/python2.5/site-packages/_xmlplus/
<lifeless> there is a bug in lp about this, which I have already commented on being not bzr's fault
<Verterok> poolie: but it crash on python-2.4 (Linux)
<poolie> oh great
<poolie> thanks
<lifeless> poolie: ls -R on that dir
<lifeless> I think you'll find that the tree is empty
<poolie> yes for me too it has subdirectories but no files
<abentley> lifeless: Yeah, I know how it works now, just weren't sure whether you were changing it.
<lifeless> so this is a borked package upgrade leaving an optional thing around which is going to barf
<poolie> and oddly enough dpkg -S doesn't know anything about it
<lifeless> abentley: I'll be tweaking
<lifeless> poolie: yes, because its gone as far as ts concerned
<lifeless> abentley: but I'll keep that property
<poolie> thanks
<jamesh> abentley: sent an updated bundle
<abentley> jamesh: Thanks.
<lifeless> spiv: so, I think its time to do Weave.get_data_stream/insert_data_stream
<lifeless> spiv: I'm thinking the simplest approach is just to extract all the texts as full-texts
<lifeless> and during insertion generate full-texts and insert
<poolie> yes it's bug 212917, i'll redirect it
<ubotu> Launchpad bug 212917 in python2.5 ""make check" got an internal error" [Undecided,New] https://launchpad.net/bugs/212917
<spiv> lifeless: from the relatively little I know about weaves, that sounds reasonable to me.
<abentley> lifeless: do we even care enough about weave to update them?  Maybe the weave <-> weave fetcher should be using a private version of join?
 * Verterok goes to the bed, while macports builds kdelibs3+kcachegrind
<Verterok> g'night all
<lifeless> abentley: weave -> knit
<lifeless> abentley: while we want to support that we either need join, or we need data stream support for weaves.
<lifeless> the latter seems cleaner
<abentley> lifeless: Oh.  Well, it wouldn't be computationally expensive to generate the deltas, but it might not be worth the time, so I'm okay with making weave suck more.
<mae^> could someone help me. i'm getting a memory error for pretty much all commands: http://pastie.caboo.se/177690
<lifeless> abentley: I've sent mail just now as it happens
<mae^> however, I was able to make a branch and it seems to work ok
<beuno> mae^, you seem to be using an old version of bzr. I'd recommend you upgrade, there have been many performance enhancements since
<lifeless> mae^: that version of bzr corrupted dirstate files from time to time
<lifeless> mae^: the C extensions handle that corruption with the symptoms you are reporting
<mae^> ah, good to know. i shall upgrade. many thanks
<lifeless> mae^: you'll need to: a) upgrade to a bzr version like 1.0, or 1.3.1 (something newer :))
<lifeless> mae^: and b) you probably need to recreate that tree - bzr branch to a new directory will work, but the .bzr/checkout/dirstate file may still give you grief
<mae^> gee, didn't know its been that long
<lifeless> there are notes in launchpad about this, or you can ask here and someone should be able to step you through getting a pristine dirstate/not accessing the tree.
<beuno> mae^, bzr does a new release every month or so, so it might of not been that long  :)
<lifeless> 5 months
<mae^> so is this something bzr can fix or check beyond upgrading the binaries?
<lifeless> upgrading the binaries will avoid creating the problem again
<mae^> and the current repo?
<lifeless> you probable did a 'bzr mv' that hit the bug in 0.91
<lifeless> 14:20 < lifeless> mae^: and b) you probably need to recreate that tree - bzr branch to a new directory will work, but the .bzr/checkout/dirstate file may still give you grief
<jdong> the bzr 1.3 stack is built in gutsy-backports now, just in case the PPA isn't up to sync yet
<jdong> of course by that I mean 1.3.1
<mae^> ok, well I'll upgrade and see where that gets me
<poolie> (out for a bit, back soon)
<mae^> upgrade + branch'd .bzr dir did it
<mae^> lifeless: thx
 * poolie merging "make dist" patch
<lech> on the CLI, is "baz" the same thing as "bzr" or did I grab the wrong thing?
<AfC> lech: Nothing to do with each other.
<poolie> you need bzr instead
<lech> aka bazaar-ng?
<AfC> lech: yes
<lech> alright, thanks
<AfC> poolie: Maybe it's time to get rid of http://bazaar-vcs.org/Baz1x
<AfC> "you are welcome to use" is not really the right message anymore :)
<AfC> and having anything besides a loud "baz is not bzr" on that page probably isn't helping.
<poolie> lech: what platform are you on, and how did you get that installed?
<poolie> afc, good point
<lech> poolie, debian on a headless box
<lech> apt-cache displayed bazaar in my search results so I figured that was it
<poolie> with 'install bazaar'?
<AfC> (I am recently made aware of this because when I asked what version of bzr a person had a few hours ago as they were adding build support for their distro to my project, they responded "1.4.2" and I was like "WTF?")
<poolie> right
<lech> poolie, yes
<lech> I suspect though bzr requires bazaar to be installed though, no?
<poolie> lech, afc, there's a bug open about it; dysfunctional debian process (imao) is making it slow to fix
<poolie> no
<AfC> poolie: yeah
<AfC> it's hard to get rid of obsolete software.
<lech> poolie, you mean it showing up in the update tree?
<poolie> i mean at minimum it should not be called 'bazaar' anymore
<AfC> hah... you guys should do a 1.4.3 revision of baz... containing bzr :)
<AfC> [Ok, I'll shut up now]
<poolie> there is still some value in having it
<AfC> Yeah. You really don't need http://bazaar-vcs.org/Baz1x/Downloads at all. It's diluting your brand.
<poolie> for people who have very specific needs, such as using it to convert to bzr
<lech> instead of removing it, why not simply update it and use it as an alias? :)
<poolie> that's the plan
<AfC> lech: it is completely different software
<AfC> lech: the only thing that it has in common is that both are revision control tools.
<lech> AfC, according to the URL it displays in the package tree, it's the same thing
<lech> at least, it points to bazaar (bzr) pages
<lech> in aptitude at least
<AfC> Like I said, massive branding problem
<lech> ahh, alright
<lech> well, thanks for helping clean things up in that respect for me
<james_w> poolie: it's not Debian being dysfunctional really, it's baz failing to build.
<lech> fetching a project moves it to the current directory I happen to be in, correct?
<lech> s/moves/puts
<poolie> james_w: i think it's a bit bizarre that failing to build means it remains available
<AfC> lech: that's right
<AfC> poolie: Seriously though, I don't think you guys hosting debs of baz is helping very much
<james_w> poolie: the argument is that the old version built fine, so you might as well let people use it.
<james_w> poolie: the problem is that we can't rename the package, as you need to build it to do that.
<poolie> i can appreciate the argument but i don't think it's a good tradeoff in this case
<lech> ok, first use of bzr with my first error
<AfC> lech: back up: do you have a recent (ie >= 1.3) version of Bazaar installed?
<lech> Bazaar (bzr) 0.11.0
<AfC> Jesus
<lech> I am guessing that might be a no?
<poolie> it's about 18 months old
<poolie> for us that's a long time :)
<lech> wow, yeah... what the hell
<lech> I even did a full package update before this
<AfC> lech: these guys are moving _very_ fast, at roughly one release per month. That makes it at least 15 versions old
<poolie> if you're on the last stable debian release that may be the problem
<lech> I'm on sarge for this box
<AfC> lech: let me guess. You're using Debian. You'll need to point your sources at the packages published by the Bazaar hackers (several are [or once were] Debian packagers)
<poolie> james_w probably knows the best source for it...
<lech> I have backports, but apparently it appears it snagged from one of the stable mirrors
<james_w> do we still build .debs for Debian?
<poolie> I do not
<poolie> I would kind of like to though
<lech> deb-ppc please
<lech> :D
<AfC> There's a 1.3 on the backports page you guys link to  http://backports.org/debian/pool/main/b/bzr/
<poolie> i probably should build them separately and put them onto bazaar-vcs
<poolie> oh
<poolie> ppc may be hard
<james_w> lech: the backport was only for etch I'm afraid.
<poolie> that looks good
<poolie> s390 even :)
<lech> damn
<AfC> lech: Bazaar builds very quickly and easily from source, so if you get stuck you can always just build it manually.
<poolie> but not ppc afaics
<poolie> i meant ppc may be hard for me to build myself only because i use an i386 machine
<poolie> but as afc says, just installing from source may be easier
<lech> I think at this rate I might just be better off downloading individual files off the branch I'm staring at in my browser
<poolie> i wonder why there is no ppc theer?
<poolie> lech, get a source tarball from /Download and try that?
<lech> I'm afraid I don't know how to build from source unless you think you can talk me through it
<poolie> sure
<lech> point me to the tarball
<AfC> Eeek! http://bazaar-vcs.org/InstallationFaq talks about bzr-0.8
<poolie> https://launchpad.net/bzr/1.3/1.3/+download/bzr-1.3.tar.gz
<lech> let me back root out to a working temp directory
<AfC> [I mean, no it doesn't have to be absolutely current, but relatively recent would probably be a good idea :)]
<poolie> the example that mentions it is not really a good idea anyhow
<poolie> just symlinking the script will still work but has several shortcomings
<poolie> lech: how did you go
<poolie> AfC: thanks for finding it
<lech> sec
<poolie> abentley: bb having trouble again, "temporarily unable to service"
 * AfC heads out
<lech> poolie, ok untarred and ready to go
<lech> worst thing that can happen is this won't work :)
<poolie> lech: i have a meeting in a minute, suggest you follow the README and InstallationFaq and let me know if you have trouble
<poolie> indeed
<poolie> should be just
<poolie> sudo python setup.py install
<poolie> andyou're done
<poolie> i'll still be here  so do ask if you get stuck
<poolie> or others may help
<lech> launching python setup.py install then
<lech> Bazaar (bzr) 1.3
<poolie> yay
<lech> although, I did see a ton of warnings fly by in screen
<lech> lets see if it properly snags what I need
<lech> we has transfer
<poolie> great
<poolie> what are you pulling btw?
<lech> http://www.intertwingly.net/code/venus/
<lech> niice, the server just died on me
<lech> ok, so it seems to have died a fraction of the way through the process. how do I "finish" that job? just do "bzr pull" ?
<lech> ok, can't even do that
 * lech hoses the directory and tries again
<AfC> lech: fwiw that server didn't answer me when I tried it
<lech> AfC, I just now noticed that there are tgz/zip links for the package which I missed earlier
<AfC> Well, now you have Bazaar, and can start using it for any work you're doing. It's really rather smart.
<lech> indeed
<lech> thanks for the help guys, I'll pop in when I need it again :)
 * lech tips his hat
<doko> poolie: does /usr/lib/python2.5/site-packages/_xmlplus still exists on your system? are there files in this dir?
<poolie> doko: it exists but it is empty
<poolie> correction. it contains two empty dirs
<doko> hmm, strange. I assume your system was upgraded from gutsy?
<poolie> yes
<poolie> maybe from feisty
<poolie> via gutsy
<doko> ok, will try to reproduce this
<Winterstream> I've been looking for a command that will allow me to view a previous revision of a file, but I haven't found anything yet.
<Winterstream> How can I do this?
<luks> bzr cat -r
<Winterstream> ah, thanks luks
<yacc> How do I tell bzr log to show only revisions commited after say  2008-03-20?
<bob2> bzr help revisionspec -> date
<ignas> is bzr calculating test coverage on their codebase?
<AfC> define "calculating" and "coverage"
<bob2> someone should strap z3c.coverage into bzr selftest
<ignas> AfC: something like: http://schooltool.pov.lt/coverage/
<ignas> every once in a while
<ignas> just to see if you are testing your code ;) or just think that you are...
<LarstiQ> ignas: there is a --coverage option
<ignas> are there restults published anywhere?
<LarstiQ> no idea
 * dato waves to LarstiQ 
<LarstiQ> ignas: I'm not familiar with the output it generates either.
<LarstiQ> hey dato :)
<ignas> emm, how do i run bzr tests?
<bob2> bzr selftest
<speakman> What's the current and fastest repo format?
<speakman> (but still safe...)
<ignas> bob2: and i pass --coverage to that?
<bob2> pack-0.92 is the current default (if anything is faster it'd be the s3kr1t dev formats)
<speakman> ok, nothing's stable yet?
<bob2> ignas: dunno where LarstiQ meant you to use --coverage, afaict selftest doesn't take that option and in fact crashes if you try to use it :)
<ignas> it seems that there is no such option ...
<bob2> the dev ones are not, hence their name ;p
<LarstiQ> bob2: bzr --coverage coverage_dir status
<bob2> oh, a global option, awesome
<LarstiQ> bob2: I only figured that out ten minutes ago after looking at NEWS and then `bzr help global-options` ;)
<ignas> oh
<ignas> I ran McCabe complexity analysis on the code and was very interested in how much one function is tested ;)
<ignas> according to the internets 50 is "beyond testability and pretty much unmaintainable" and bzr has a 98 ;)
<james_w> ignas: which function?
<ignas> bzr/bzrlib/workingtree_4.py - InterDirStateTree.iter_changes
<ignas> it has 5 tests i think ;)
<ignas> james_w: how do you like it? ;)
<james_w> ignas: yeah, that's nice
<ignas> james_w: http://ignas.pov.lt/bzr_coverage/reports/bzrlib.workingtree_4.html
<ignas> it's covered quite well though
<ignas> so someone could refactor it into something maintainable ;)
<skam123> hi there
<skam123> i try to us the bzr->bugzilla integration but the offical documentation is not that comprehensive to me
<skam123> is someone using this integration?
<james_w> skam123: I think I know how it works, what are you trying to do?
<skam123> james_w: our developers woulr appreciate if the --fixes switch would set a given bug on commit to fixed
<skam123> right now bugzilla is running stand alone, bazaar rep is somewhere on the server-fs. users are committing using ssh+bzr, there is no bzr server running
<james_w> skam123: ah, the integration won't do that for you I'm afraid, it just marks the fact that it is fixed in bzr.
<skam123> ah. ok
<james_w> a script could them close bugs for you if you like, but at the moment bzr has no facility for doing that.
<james_w> I think it's too much to make bzr do all that, but it would be great to have some example scripts or something for people to set up.
<skam123> hm
<skam123> has anybody tried some tool like http://www.mkgnu.net/?q=scmbug
<aantn> hello
<aantn> There seems to be a bug in bzr
<aantn> it causes problems if filenames have characters like Ã© in them
<hmeland_> aantn: Which bzr version are you using?
<aantn> 1 sec
<aantn> b0le is the one with the problem
<aantn> (hello)
<aantn> It's on my branch
<aantn> b0le: which version of bzr are you using?
<b0le> 1.1.0
<b0le> upgrading to 1.3 at the moment, will try again after that...
<luks> what kind of problems does it cause?
<b0le> https://bugs.launchpad.net/bzr/+bug/63324 - similar to this
<ubotu> Launchpad bug 63324 in bzr "exceptions.UnicodeEncodeError: 'ascii' codec can't encode character" [Medium,Confirmed]
<luks> b0le: can you be more specific? ideally paste the traceback?
<b0le> luks: unfortunately I didn't keep the output, and have just updated to 1.3, and am trying again (though it seems to take quite a while...)
<spiv> b0le: or perhaps like https://bugs.edge.launchpad.net/bzr/+bug/135320 ?
<ubotu> Launchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New]
<b0le> "With LANG=en_AU.UTF-8 this works for me."
<b0le> however, "bzr grep" fails, even with LANG... (after I have sucessfully "bzr co"-ed the repo with the above env variable)
<b0le> "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 29: ordinal not in range(128)" is pretty close to what the error was (just different byte and position)
<b0le> luks: spiv: aantn: http://pastebin.ca/978294
<luks> "encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: None"
<luks> I'm not sure what exactly that encoding is, but I'd bet it's something similar to ascii
<luks> and so doesn't support characters like Ã©
<dato> luks: that's the formal name for C/ASCII
<luks> ah
<aantn> is there something I can change on my branch so that it'll use the proper encoding?
<aantn> I can always change the filenames, if I must
<b0le> exporting LANG fixed it last time - so is that a problem with my setup?
<luks> aantn: no, it's a problem on the client side
<luks> the only way you can fix it is to restrict yourself to ascii
<aantn> luks: that's not terrible
<aantn> I only use the Ã© in one or two places
<luks> bzr doesn't know to encode characters like Ã© if the client system tells it to use ASCII
<b0le> luks: do you know why LANG=... fixes "bzr co", but "bzr grep" still fails
<spiv> Or change the client system's locale something other than ASCII (e.g. by setting LANG=en_US.UTF-8)
<luks> b0le: bzr grep is a plugin, and probably not tested on non-ascii characters
<spiv> b0le: yeah, that's probably a bug in the grep plugin.  File a bug on the plugin.
<luks> if it does have a bug tracker, it would be worth filing a bug report
<b0le> luks: spiv: aantn: thanks for the help :)
<spiv> (If there's no plugin, try mailing the bazaar mailing list I guess)
<spiv> Er,
<spiv> If there's no *bugtracker*, I mean :)
<aantn> b0le: I think I'll just change the Ã© to an e
<SheikPunk> how to ignore files by extension
<SheikPunk> ignore for example .log files
<luks> bzr ignore '*.log' ?
<SheikPunk> luks: i go try
<SheikPunk> luks: and all directory?
<SheikPunk> bzr ignore 'logs/*'
<luks> bzr ignore b/ should be enough
<luks> er
<luks> bzr ignore logs/
<luks> :)
<luks> dunno why I typed 'b' there
<SheikPunk> luks: thanks...
<ubotu> New bug: #214619 in bzr "exceptions.KeyError when branching from 1.1 server via bzr+ssh" [Undecided,New] https://launchpad.net/bugs/214619
<fbond> Hi, I'm using the loom plugin.  When I make changes to a thread and then move up-thread, the new changes to the lower thread are applied as new commits on the higher thread, but what I really want is to rebase the higher thread on top of the new commits on the lower thread.  Anyone follow me?
<fbond> What is the best way to do this?
<james_w> fbond: you may be able to do it with the rebase plugin.
<james_w> I'm interested in why you are using the loom plugin if you want to do this though.
<james_w> rebasing a thread will probably stop you from moving up thread from the one you rebase.
<fbond> Well, I want the loom plugin to act more like quilt, I guess.
<fbond> james_w: perhaps I should not be using loom, but should instead just branch and rebase?
<fbond> i.e. create feature branches...
<james_w> that would be the better solution currently.
<james_w> it may be possible to make a quilt mode for loom at some point.
<james_w> can I ask why you don't just use quilt on top of bzr?
<james_w> I'm unsure of what the tradeoffs here.
<fbond> Hmm... I don't really love quilt...
<fbond> I actually just used shelve for a while.
<fbond> But shelve is un-fun in that it doesn't deal with adds, moves, etc...
<fbond> quilt would be roughly the same in that respsect...
<james_w> yeah, shelves not viable for all this.
<james_w> true.
<fbond> The ideal situation would be an extension of loom that rebases when I do up-thread, I think.
<fbond> Maybe bzr up-thread --rebase
<fbond> Or bzr rebase --replace, to replace a section of history with another section...
<james_w> yeah, it's not ideal because it means that the threads above no longer share history with those below
<fbond> Well, they all have to be rebased...
<james_w> and lack of history means merging can't be as good.
<fbond> So maybe, then, `bzr rebase-threads' to rebase all threads above the current one.
<asabil> fbond: bzr-interactive may help
<asabil> it containes a record-patch
<asabil> that records the patch in patches/
<asabil> and can be managed using quilt
<asabil> it is barebone though
<fbond> james_w: https://bugs.launchpad.net/bzr-loom/+bug/214657
<ubotu> Launchpad bug 214657 in bzr-loom "Should support rebasing threads" [Undecided,New]
<ubotu> New bug: #214657 in bzr-loom "Should support rebasing threads" [Undecided,New] https://launchpad.net/bugs/214657
<brink_> I'd like to migrate a Sourceforge Subversion project to either bzr or git.   I was hoping to get some advice.  Sourceforge doesn't support anything but Subversion and SVN.   I'm considering Launchpad, but I'm not that familiar with it.    I'm also not entirely sure how to get everyone on board for a switch to distributed development.   It seems to me the project really needs support for distributed development, but I'm not s
<NfNitLoop> brink_: you got cut off at "I'm not s..."
<NfNitLoop> brink_: The nice thing is that you don't necessarily have to get everyone on board.
<NfNitLoop> You can use bzr-svn with an ongoing svn project.
<NfNitLoop> and sync changes between the two repositories.
<brink_> The ending is ...I'm not sure how to explain it to a generally skeptical audience unfamiliar with the concept.
<NfNitLoop> You can just create your own bzr branch, register it with Launchpad...
<NfNitLoop> and keep them in sync.
<NfNitLoop> then people can choose to use svn or bzr.
<NfNitLoop> (I think Launchpad even has an option to keep a branch in sync automatically, but IIRC you have to contact them and set it up that way.)
<brink_> I actually tried using Launchpad as an experiment.   The import status has been "Testing" for more than a week.   But as I said, I'm not that familiar with Lauchpad, so maybe I'm doing something wrong.
<james_w> brink_: can you give a pointer to where you tried?
<jdong> brink_: the launchpad importer thing hasn't inspired my confidence either
<jdong> brink_: I'd personally also suggest using bzr-svn to mirror Subversion projects into bzr
<brink_> Here's the link:  https://code.launchpad.net/sphinx4/trunk
<NfNitLoop> you may have to babysit your first import though, so that it doesn't kill your box.  Stupid memory leaks.  >.<
<brink_> Is bzr-svn more useful than the Launchpad mirror?
<brink_> Can bzr-svn be merged back?
<james_w> brink_: yeah, you can merge back when using bzr-svn.
<jelmer> 'evening awilkins
<awilkins> Hello there jelmer
<aelkner__> can someone help me with a problem i'm having with bzr?
<aelkner__> is anyone here?
<beuno> aelkner__, sure
<aelkner__> i think i got the lastest version when i did my updates on my linux box
<aelkner__> but now bzr co is giving me the following failure
<aelkner__> bzr: ERROR: Invalid http response for http://staging.schooltool.org/bzr2/schooltool/schooltool.lyceum.journal/.bzr/repository/packs/71f1ff934019ef067e17e22956a982c2.pack: Expected a boundary (TXyz-fP5Lqw3jFjqmB=L) line, got ''
<james_w> hi beuno
<aelkner__> bzr --version:
<aelkner__> Bazaar (bzr) 1.3.1rc1
<aelkner__>   Python interpreter: /usr/bin/python 2.5.1.final.0
<aelkner__>   Python standard library: /usr/lib/python2.5
<aelkner__>   bzrlib: /usr/lib/python2.5/site-packages/bzrlib
<aelkner__>   Bazaar configuration: /home/aelkner/.bazaar
<aelkner__>   Bazaar log file: /home/aelkner/.bzr.log
<beuno> hey james_w :)\
<aelkner__> does that help?
<beuno> aelkner__, could you paste your .bzr.log into a pastebin of some sort (ie, not the channel)
<aelkner__> buone: how do i get to the pastebin for #bzr?
<james_w> aelkner__: is there a proxy in the way?
<beuno> aelkner__, I usually usehttp://paste.ubuntu-nl.org/
<aelkner__> janes_w: i don't know if there's a proxy in the way
<beuno> aelkner__, it would seem like a setup problem (http server, proxy, etc) instead of a bzr error
<james_w> this error has been reported a few times, and every time there is a proxy in the way.
<james_w> there's a bug report
<aelkner__> ignas: do you know of a proxy on the host side?
<ignas> you got the error both with launchpad and on schooltool.org
<ignas> so if there is a proxy - it's either on both websites, or at your place it seems
<beuno> LP doesn't have a proxy, that's for sure
<aelkner__> how would i check for a proxy?
<aelkner__> is there a command that i can run from my machine?
<beuno> aelkner__, I'm not sure we'll be able to help you with detecting a proxy
<ignas> emm, so what should i recommend to people who are behind a proxy and want to bzr get the development branch?
<james_w> you can use ssh
<ignas> you mean developers can
<james_w> though there may be people with port 22 firewalled, and a transparent http proxy that does this.
<james_w> ignas: nope, anyone can download a branch over ssh from launchpad.
<ignas> what about users that want to see the latest and greatest?
<james_w> at least I assume that works for mirrored branches as well.
<ignas> so lp:~ignas/some-branch is not something that will reliably work?
<ignas> it is a bit insane that if they want to make a read only checkout of my code they have to have a user on launchpad
<ignas> or not be using a proxy
<james_w> not be using a broken proxy
<james_w> the bug report in question was looked at by squid developer and he said the bug there is fixed in the latest versions.
<ignas> i see
<laga> hello!
<laga> i've just updated my bzr tree and resolved some conflicts. however, i still get messages like "Conflict adding file mythbuntu_common/dictionaries.py.BASE.  Moved existing file to mythbuntu_common/dictionaries.py.BASE.moved.". none of these files exist. what can i do to resolve this?
<james_w> laga: that's pretty odd.
<laga> james_w: yeah. :) i use  bzr 1.3.1rc1 on ubuntu hardy
<james_w> laga: I think this may happen if someone accidentally commits the files spat out in a previous conflict/
<james_w> not sure why they don't exist though.
<laga> yeah, i think so too.
<laga> i tried to bzr remove them, but it just said 'mythbuntu_common/dictionaries.py.BASE does not exist.'
<james_w> does "bzr resolve 'mythbuntu_common/dictionaries.py.BASE'" work?
<laga> james_w: yeah, it does. thanks! :)
<laga> i should remember that, it's pretty obvious once you see it
<muszek_> hi... a newbie question: I (user muszek) have created a repo.  another user on the same machine (tomekg) made a checkout and bind'ed his repo to mine.  Now when he tries to commit, he gets a "permission denied" error.  I figure it's about "regular unix file permissions"... how should I handle this?
<james_w> laga: once you have resolved all the conflicts and committed we should make sure that you haven't got anything in your branch that will cause problems later, so please ping me.
<james_w> muszek_: yes, it sounds like file permissions would be the issue.
<laga> james_w: ok.
<laga> james_w: ping.
<james_w> the common way to solve this would be to make your file owned by the a group that you are both a member of, and then make all directories g+s.
<james_w> laga: :-)
<laga> ;)
<james_w> so, can you pastebin me the output of "bzr inventory" and "bzr log -r -1 -v" please?
<muszek_> james_w: but how should it be done properly?  first thing that comes to my mind is to chmod everything so that owner&group can write and add tomekg to my group... but that doesn't seem to elegant...
<muszek_> s/to/too
<james_w> muszek_: yes, that's the correct way, except you should use a different group and add you both too it
<laga> james_w: here we go: http://www.pastebin.ca/978671
<james_w> and as well as making files and directories writeable, make all directories g+s, i.e. set the group sticky bit.
<james_w> laga: ok, that all looks ok to me, I don't know where those problems came from.
<muszek_> james_w: do you know about any article on the topic? (I'm affraid I'll be doing something wrong, especially when messing with .bzr directory)
<james_w> muszek_: nope sorry
<laga> james_w: PEBKAC, most likely. thanks for your time.
<james_w> laga: I don't think it was. No problem anyway
<james_w> muszek_: groupadd "newgroup"
<james_w> adduser muszek newgroup
<james_w> adduser  newgroup
<james_w> oops,
<james_w> adduser  tomekgnewgroup
<james_w> adduser tomekg newgroup
<james_w> that's better
<james_w> chown muszek:newgroup -R branch
<james_w> chmod g+w -R branch
<james_w> find branch -type d -exec chmod g+s '{}' \;
<james_w> I think that's right
<muszek_> james_w: thanks (I'll handle it, I have some "find..." one liner from the times we were doing it over ftp
<abentley> spiv: Why doesn't RemoteBzrDir implement set_make_working_trees?
<nixternal> OK, somehow my docs repo got mucked and now I have this error:
<nixternal> bzr: ERROR: No repository present: "file:///home/nixternal/work/ubuntu/docs/repos/kubuntu-hardy/"
<nixternal> right after i did a bzr revert this happened
<abentley> nixternal: What does it say when you run "bzr info"?
<nixternal> same error
<abentley> Is kubuntu-hardy a repository, or a branch within a repository?
<nixternal> a repo
<abentley> What do you get from ls ï»¿/home/nixternal/work/ubuntu/docs/repos/.bzr ?
<nixternal> backup.bzr  branch  branch-format  branch-lock  checkout  README  repository.backup
<abentley> Did you recently try to upgrade your repository?
 * nixternal looks
<nixternal> bah, looks like I did a bzr upgrade and not a bzr up
<abentley> Okay, so either repository.backup or backup.bzr should provide a working repository.
<abentley> Let's start by renaming repository.backup to repository.
<nixternal> done
<nixternal> booyah! that worked
<abentley> Try bzr info ï»¿/home/nixternal/work/ubuntu/docs/repos
<nixternal> lookin' good :)
<abentley> Good.  What format is it currently in?
<nixternal> dirstate-with-subtree
<abentley> That is an experimental format.  Converting it into a supported format is somewhat roundabout.
<nixternal> I am a bzr dummy...I can get away with utilizing svn syntax to get by
<abentley> Is the trunk branch in a public location?
<nixternal> https://code.launchpad.net/ubuntu-doc/+branches
<nixternal> I just have a tad bit more work in this repo and then it is done with due to us moving to intrepid branches
<abentley> Well, ubuntu-intrepid is in the right format.  So when you switch to it, I'd recommend using a new shared repository.
<nixternal> roger that, thanks for the tip
<abentley> np.
<Vantage> hi, I'm doing some performance testing on bzr against a converted CVS repo and for some reason the performance of bzr 1.3 seems to be much worse than the last time I tested (pre-1.0)
<Vantage> in a lightweight checkout a diff between to revisions is taking almost 20 seconds (on a local machine)
<Vantage> heavyweight checkout takes about 4 seconds for the same diff
<Vantage> and cvs across a network is under 1 second...
<beuno> Vantage, many of the peformance issues are being currently worked on, but if you could send in more information to the mailing list, it might help as a use case to test against
<Vantage> beuno: ok, is there anything specific in this regard that's alreay known?  Like I said, I had been playing with previous versions of bzr (0.18 and one of the 0.9s) and don't recall it being this slow before
<beuno> Vantage, most of them are knonw, yes. We moved to a different storage format that enables to scale much better, but it regressed in some areas
<lifeless> Vantage: what bzr versioned are you using today?
<beuno> so a lot of work is being done to improve even what we had before  :)
<Vantage> lifeless: 1.3
<lifeless> abentley: bb is down
<lifeless> Vantage: 1.4 is significantly faster at log
<Vantage> bzr log also takes about 4 seconds or so for lightweight or heavyweight
<Vantage> lifeless: is 1.4 out?
<Vantage> lifeless: what about diffs?
<abentley> lifeless: Starting up...
<lifeless> Vantage: for diff; I'm working on the issues with diff, but understand that comparing 'single file diff' with 'tree wide diff' will always be biased to the single file implementation of a vcs
<Vantage> lifeless: even if you request it for a single file?  e.g. bzr diff -r2..1 index.html ?
<abentley> lifeless: working now.
<nixternal> just noticed 'bzr revert' doesn't work...could that upgrade have mucked that up as well abentley?
<Vantage> lifeless: of course, even given that, at 20 seconds it's not really usable ;)
<nixternal> abentley: I meant 'bzr add'
<abentley> nixternal: I suppose it's possible.  What version of bzr are you running?
<nixternal> 1.3.1-rc1
<nixternal> bzr: ERROR: exceptions.AssertionError:
<lifeless> abentley: looks like many of the email votes from last night haven't been noticed ?
<abentley> lifeless: I ran them through manually this morning.  They should have been.
<lifeless> abentley: http://bundlebuggy.aaronbentley.com/request/<1207701408.9506.118.camel@lifeless-64>
<lifeless> abentley: I'm hoping I can land all my patches as one merge
<lifeless> abentley: :P
<abentley> God, I hate the way firefox mangles urls.
<lifeless> Vantage: say you have a tree with a root directory of 20,000 files.
<abentley> nixternal: Please provide the whole error message via pastebin.
<abentley> ubotu: paste
<ubotu> New bug: #214777 in bzr-gtk "gcommit: unsupported operand type(s) for /: 'float' and 'NoneType'" [Undecided,New] https://launchpad.net/bugs/214777
<ubotu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
<nixternal> abentley: http://paste.ubuntu-nl.org/62682/
<lifeless> Vantage: a vcs that stores separate revision numbers, and one file on disk for each of the 20K files can diff a single file with less work than a vcs that has to indirect through the list of all revisions for the two revisions to figure out internal keys for the 20K files
<abentley> lifeless: Can you look at nixternal's bug?
<lifeless> Vantage: that said, 20 seconds sounds like a bug to me.
<Vantage> lifeless: any way to get more information on what's taking so long in the process?  debug flag or something like that?
<lifeless> Vantage: are you using bzr+ssh? if so -Dhpss. you can use -Dtransport
<lifeless> too
<lifeless> and you can get lsprof information as well with --lsprof-file=foo.cachegrind
<lifeless> abentley: sure, I can peek
<lifeless> nixternal: hi
<Vantage> lifeless: this is just on the local file system
<nixternal> howdy lifeless
<lifeless> Vantage: 20 seconds on local file system? you said lightweight checkout...
<lifeless> Vantage: lightweight checkout of what branch
<lifeless> nixternal: you're just running 'bzr add' ?
<Vantage> lifeless: yeah, and the shared repo is on the same filesystem
<Vantage> lifeless: HEAD
<nixternal> lifeless: 'bzr add' or 'bzr add foo/bar/foobar.xml'
<lifeless> Vantage: what format is the shared repo ?
<lifeless> nixternal: so it looks like the file is already added
<nixternal> but it isn't
<lifeless> nixternal: but we're not detecting this correctly; can we try starting fresh - make a new branch from the current one's last commit
<Vantage> lifeless: it's a converted cvs repo using cvsps-import
<ubotu> New bug: #214784 in bzr-gtk "Gcommit fails with unknown error: float division" [Undecided,New] https://launchpad.net/bugs/214784
<lifeless> Vantage: that doesn't tell me what format :P. 'bzr info' will
<Vantage> lifeless: basically I converted the cvs repo, then checked out a heavyweight copy of head and a lightweight copy of head to another directory
<Vantage> lifeless: i'll get that
<Vantage> lifeless: Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<nixternal> lifeless: if I branch that, I will be waiting about 3 hours for it to finish
<abentley> lifeless: Got your vote in.
<lifeless> nixternal: why would it take three hours ?
<lifeless> Vantage: does it say anything about the repository?
<nixternal> if you mean 'bzr branch lp://foo@bar/blah/blah/blah'
<lifeless> nixternal: no, I said your current tree's last revision
<nixternal> how do I go about doing that?
<lifeless> bzr branch . ../foo
<Vantage> lifeless: Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<Vantage> Location:
<Vantage>   light checkout root: .
<Vantage>    checkout of branch: /home/user/revision_control/shared_repos/bzr_shared/bzr/test/branches/HEAD
<Vantage>     shared repository: /home/user/revision_control/shared_repos/bzr_shared/bzr/test
<nixternal> transferring now
<abentley> nixternal: by the way ï»¿ï»¿/home/nixternal/work/ubuntu/docs/repos does not look like a repository.  It looks like a standalone tree.
<lifeless> Vantage: garh. I feel an urge to delete a swathe of info patches; older versions may have been ugly, but they gave what I needed
<lifeless> Vantage: what does bzr info /home/user/revision_control/shared_repos/bzr_shared/bzr/test/branches/HEAD tell you?
<abentley> lifeless: bzr info -v will tell you the repository format.
<lifeless> abentley: its bizarre that you'd need that as its no more expensive to get than what we already do without -v
<lifeless> and the lightweight checkout format can accurately tell you -
<Vantage> lifeless: here's the format section from bzr info -v
<Vantage> lifeless: Format:
<Vantage>        control: Meta directory format 1
<Vantage>   working tree: Working tree format 4
<Vantage>         branch: Branch format 6
<Vantage>     repository: Packs containing knits without subtree support
<lifeless> Vantage: ok thanks
<lifeless> Vantage: how many files are in your project
<Vantage> lifeless: and that came from within the lightweight checkout
<lifeless> Vantage: and how many lines are in /home/user/revision_control/shared_repos/bzr_shared/bzr/test/.bzr/repository/pack-names
<nixternal> lifeless: branch completed (glad I know that trick now)
<abentley> lifeless: it's not about being un-expensive, it's about being un-verbose.
<Vantage> lifeless: this module that i'm testing has about 3000
<lifeless> abentley: in the format: (...) we could filter that to only show ones plausible for the repository; thats what I'm talking about
<lifeless> abentley: we show that by default
<nixternal> and bzr add works :)
<lifeless> nixternal: ok, if the project is open please file a bug on the problem with add; if you can remember doing anything else like mvs/renames/deletes in the other copy
<lifeless> nixternal: a copy of .bzr/checkout/dirstate for the broken copy would be useful
<nixternal> roger that
<nixternal> thanks again!
<lifeless> nixternal: and the paths it was having trouble with
<abentley> lifeless: So then you get people saying: "I told bzr to create dirstate-tags checkout and it created a pack-0.92 one instead.  WTF?"
<Vantage> lifeless: the file has 31 lines in it
<lifeless> abentley: it doesn't change what bzr did
<abentley> No, it only makes it look like it did the wrong thing.
<lifeless> abentley: but if they say that it may be highlighting that use of a shared repository should give a ui hint that it did
<lifeless> abentley: e.g. 'checked out XXX into foo/bar of shared repository /path/to/repo/'
<lifeless> Vantage: you might try doing 'bzr pack' and see if that alters the performance you are seeing for 'diff -r x..y foo.html'
<lifeless> abentley: is the a bb page which shows the review requests I sent in that have not been approved (either by not being reviewed, or by being bounced) ?
<lifeless> s/the/their/
<abentley> bounced?
<lifeless> resubmit
<abentley> Not at present.
<lifeless> I'm trying to figure out if there are any threads in my stack that are not ready to merge
<lifeless> it would be cute to be able to do 'bzr missing' against a virtual branch that shows bb requests that are approved as merged
<ubotu> New bug: #214800 in bzr "bzr diff on removed file fails" [Undecided,New] https://launchpad.net/bugs/214800
<Vantage> lifeless: pack seems to have gotten it down to 5 seconds
<abentley> lifeless: My listing shows your http://bundlebuggy.aaronbentley.com/request/%3C1207695099.9506.109.camel@lifeless-64%3E as unapproved.
<lifeless> abentley: do you think it can go ?
<abentley> I had the same qualms as John.  Have you checked whether it's a performance regression?
<lifeless> not at the very large scale; I can say that iter_rev_trees didn't use the inventory cach eanyway
<lifeless> the cache was only used during fetch; disabling it make the inventory knit get read three times; that patch brings that down to 2 times, and the patch to eliminate join() that I'm working on will bring it back down to one.
<abentley> It looks as though it was also used in commit.  Is that wrong?
<lifeless> certainly for packs
<lifeless> replying to johns mail
<abentley> I think it's not used by commit.  It's just the way the diff hunks line up that's confusing.
<lifeless> basically though I'm happy for knit based formats to get somewhat slower; they are holding pack formats back from stacking and fast build tree etc
<lifeless> Vantage: thanks for that data point; I think we will have to find this performance issue in index lookups sooner rather than later
<Vantage> lifeless: no problem.  Thanks for the help.  5 seconds is still a little slow, but considerably better than 20
<lifeless> Vantage: how long is 'bzr ls -r X' where X is the revision you used to diff ?
<lifeless> Vantage: also, you might try getting the revids and doing 'bzr diff -r revid:A..revid:B' and see if that is any faster
<lifeless> Vantage: this will help figure out where the time is going
<Vantage> lifeless: as in number of files?
<lifeless> Vantage: not sure what you mean
<Vantage> lifeless: "how long is 'bzr ls -r X'"  -  How long is the number of files?
<Vantage> lifeless: I was using revno for the diff
<lifeless> what is the time taken by 'bzr ls -r X'
<lifeless> Vantage: yes, I figured you where, if you try revids you may find its faster
<Vantage> lifeless: ah... real    0m3.822s
<Vantage> user    0m2.548s
<Vantage> sys     0m0.164s
<lifeless> Vantage: try 'time bzr ls -r X > /dev/null'
<abentley> lifeless: bb:approve
<lifeless> abentley: where there any other pending in this arc of work?
<Vantage> lifeless: real    0m3.097s
<Vantage> user    0m2.476s
<Vantage> sys     0m0.156s
<Vantage> lifeless: where do you get the revids?
<lifeless> Vantage: so that says that of the 5 seconds to diff, 3 is figuring out the revno to revid mapping
<lifeless> Vantage: log --show-ids
<lifeless> oh, getting the inventory out is part of the 3 seconds as well
<abentley> lifeless: I don't believe so.
<lifeless> abentley: sweeet, I'll land the entire set
<abentley> I gotta say it's irritating to see all yours sail through while mine tend to be blocked or ignored.
<lifeless> hmm
<Vantage> lifeless: what's the syntax for using revid and what's the format of the id?  I tried it, but I don't think I did it correctly
<lifeless> revid:XXXXXXX
<Vantage> lifeless: the revision-id is cvs-blah-date-what looks like a hash
<lifeless> Vantage: yah, its opaque data, not a structured format
<Vantage> lifeless: ah, got it.  i was getting "paths are not versioned because I was in the wrong directory... argh...
<Vantage> lifeless: real    0m5.269s
<Vantage> user    0m4.928s
<Vantage> sys     0m0.196s
<lifeless> hmm ok
<Vantage> so still 5 seconds
<lifeless> Could be we are still mapping
<lifeless> if the tree can be published, I'd be happy to have you file a bug and investigate
<abentley> Which version of Bazaar?
<Vantage> lifeless: unfortunately, I can't do that...
<lifeless> abentley: 1.3 I believe
<Vantage> abentley: 1.3
<lifeless> Vantage: thats a shame. I'm sure we will fix the performance issue eventually; but you know - reproducible cases are easier to work on.
<abentley> handling of revision specs is much faster in bzr.dev
<Vantage> lifeless: agreed, of course, it's not my call ;)
<lifeless> abentley: I have a solid share of ignored ones - some sit around for months
<lifeless> -> food bbs
<lifeless> abentley: I'm going to read your stacking policy stuff today and give the feedback you asked for
<abentley> lifeless: Cool.
<abentley> lifeless: I really wanted your response to the "Playing with stacked branches" message
<lifeless> abentley: yes, thats the one I have starred to read
<lifeless> I've felt a little time pressure on the api work;
<lifeless> 4 or 5 more methods and we're at the point of being able to migrate across,
#bzr 2008-04-10
<awilkins> [PUPPETS]Gonzo: Are you awake, Guillermo?
<poolie> hello
<lifeless> hi
<spiv> abentley: because there's no bzrdir_implementations test for it, I guess.
<abentley> spiv: I misspoke, RemoteRepository, not RemoteBzrDir
<abentley> It looked very much like you had decided that it should not be implemented.
<abentley> If I'm mistaken, I'll gladly implement it.
<spiv> abentley: hmm
<spiv> abentley: well, currently the smart protocol doesn't have any verbs to talk about working trees
<spiv> abentley: so it might have been intentional.
<abentley> We need it to properly implement clone_on_transport, so I can do the VFS fallback thing for now.
<spiv> abentley: ideally, I would like for it to be the case that a push over the smart protocol would cause the server to update a working tree on the remote side if there's one there.
<lifeless> spiv: I think thats a problem because of conflicts
<spiv> lifeless: yeah, it's definitely not a trivial problem
<spiv> lifeless: I also don't think it's a particularly important problem.
<spiv> lifeless: so don't worry, there's not too much risk of me doing anything about it anytime soon :)
<abentley> spiv: Not creating working trees remotely is handled in other ways, so there's no need to disable set_make_workingtrees
<spiv> abentley: incidently, there's no direct repository_implementations test for set_make_working_trees.  It probably gets exercised by test_clone_shared_no_tree, depending on if test bails out early or not... if you want to add a simple direct test for set_make_working_trees (and make_working_trees), that would be good.
<spiv> abentley: sounds reasonable to me
<abentley> Okay, I'm happy to do that, and it will make my repository acquisition policy patch nicer.
<abentley> lifeless: I'm wondering whether we should be adding a scenario to the bzrdir implementation tests: bzrdir with non-default repo, tree and branch.
<abentley> I had a test for clone_on_transport that was creating a repo in the default format, not the bzrdir format.
<abentley> I'm manually forcing that test to run with "knit".
<lifeless> abentley: so a scenario which runs all the bzrdir tests hoping to catch things that make outputs be default rather than the source format ?
<abentley> Right.
<poolie> lifeless: considering the two recent bugs with tzdata and python-xml
<poolie> both could not be reproduced with upgrades, but were likely caused by them
<spiv> abentley: so you're going to remove the special casing for Remote* in that patch, then?
<abentley> spiv: Yes.
<poolie> i wonder if some better database could keep track of every package they ever published
<poolie> </random>
<spiv> abentley: ok, good.  I don't need to complain about your use of "from remote import ..." then ;)
<lifeless> abentley: I think that has some value
<abentley> spiv: Why do I always do that?
<lifeless> poolie: yes, there are such things :P
<lifeless> poolie: archive, my conflict finder, etc
<lifeless> yay mass api changes landed
<ubotu> New bug: #214878 in bzr "Crash when trying to push to a remote directory (FTP)" [Undecided,New] https://launchpad.net/bugs/214878
<mwhudson> hm, i guess now would be a good time to fix how loggerhead does annotate
<mwhudson> (it calls annotate_iter currently)
<mwhudson> so many things to do
<markh> lifeless: did you get a chance to look at the new rev of that doc?
<lifeless> markh: yes, I approved on bb
<markh> it addresses the concerns you had re the tone?
<lamont> are bzr 1.3.1 bits (release) packaged anywhere?
<lifeless> hardy
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.4 bug day today! - help us report, triage, fix and review...
<poolie> and gutsy-backports i believe
<lifeless> so
<lifeless> I have a task for someone
<lifeless> try freeze on bzr
<poolie> oh, python freeze, to turn it into a binary?
<poolie> lifeless: quick call?
<lifeless> yes
<lifeless> sure
<ubotu> New bug: #214894 in bzr "AssertionError when pushing to remote bzr+ssh repository (len(history) != revno)" [Undecided,New] https://launchpad.net/bugs/214894
<lifeless> fbond: ping
<poolie> commenting on bug 209281 patch
<ubotu> Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,Invalid] https://launchpad.net/bugs/209281
 * poolie looking at "plugins in arch-indep directory"
<fbond> lifeless: hi
<lifeless> fbond: re looms and rebasing
<lifeless> fbond: why do you want to break collaboration?
<poolie> ok, already merged
<fbond> lifeless: well, I wasn't collaborating at the time :)
<fbond> lifeless: frankly, quilt isn't a collaboration tool, so if I'm using looms as a better quilt, I don't care much about collaboration.
<lifeless> fbond: right, I realise quilt isn't a collaboration tool... one of things about looms that make it a better quilt is the collaboration aspects :P
 * poolie reads command-not-found core
<lifeless> poolie: perhaps a #bzr-bug-day channel?
<fbond> lifeless: Okay, my understanding of the impact of rebasing is probably limited.
<lifeless> fbond: that said, I'd like to understand why you want to rebase rather than have the changes merged up (we can put equivalent automation in both approaches)
<poolie> maybe
<poolie> is this too noisy?
<lifeless> poolie: its low signal
<poolie> i'm trying not to overlap with spiv
<fbond> What I want to do with looms is to manage a set of possibly dependent changesets and then pull them off, one at a time, as a single changeset that I can then merge, push, pull, etc.
<lifeless> poolie: well, as a journal I don't know that it will scale. I suggest gobby if you want to avoid overlap and scale with people doing this
<fbond> What I don't like about the current behavior is that I end up getting changes mixed into higher threads that are really specific to a lower thread.
<lifeless> fbond: so merges don't preclude that, in fact they allow you to handle more merge cases.
<fbond> lifeless: It's certainly possible that I'm overlooking a feature that will do what I want.
<lifeless> fbond: I don't understand what you mean by mixed in
<lifeless> fbond: rebasing would have as much code commingling
<fbond> Hmm.  I really want a single commit per thread.
<lifeless> and quilt has as much too; when you work as a stack.
<lifeless> fbond: there is at any point in time a cherrypick merge that will drag out a single thread with nothing from other threads.
<lifeless> fbond: 'bzr merge someloom -r thread:threadbelow..thead:feature'
<fbond> lifeless: Okay, I think I see how that would work.
<poolie> merging make-dist and command-not-found core..
<lifeless> fbond: if you happen to take threads from bottom to top, then cherrypicking is equivalent to just merging/pulling individual threads
<lifeless> fbond: the bottom thread is typically the trunk
<poolie> spiv: can you do the tweaks and submit your _get_line patch?
<spiv> Yeah.
<fbond> What I'm really after is to have a set of mutable commits, each of which represents a specific feature or fix.  I'd like them to remain mutable until I decide that feature/fix is complete, at which point I want to roll that commit into a "final" commit that I apply to trunk.
<jamesh> if anyone wants to approve and merge the post_change_branch_tip hook patch, it'd be appreciated :)
<poolie> jamesh, it's near the top of my list
<fbond> lifeless: It sounds like cherry-picking the "final" commits would do that.
<poolie> how much hope this gives you i can't say :)
<jamesh> thanks
<lifeless> fbond: so, there are two basic ways to mutate a commit; you can either commit a change on top of it, or you can remove it from history and commit it fresh
<lifeless> fbond: the former allows other developers (and yourself in dependent commits) too adjust to your mutations
<fbond> lifeless: right, in the end I want a single commit with a single log message, though.
<fbond> So I guess I cherry pick the commits that make up that single commit and then `bzr revert --forget-merges'?
<lifeless> fbond: the latter looks to the vcs system as two people doing slightly different things, except when special logic (rebase) is applied to avoid massive conflicts.
<fbond> lifeless: yeah, I follow you.
<fbond> lifeless: But I wouldn't be sharing my loom with others.
<lifeless> fbond: the problem with rebase is that other people have to know exactly when you rebased to reproduce it exactly, but by the very nature of rebase they cannot know this.
<fbond> lifeless: The loom would be a temporary tool for me to manipulate commits.
<lifeless> fbond: doing a --forget-merges will in fact do what you want yes.
<fbond> lifeless: yes, it would, at the cost of having to cherry pick multiple commits instead of rolling off a single commit...
<lifeless> fbond: well you're not grabbing multiple commits; by forgettings merges you get a single commit
<fbond> lifeless: I'm tempted in that case to bzr down-thread; bzr uncommit; [make changes]; bzr commit; bzr up-thread
<lifeless> fbond: if you do that, bzr will still give you a merge :P
<fbond> lifeless: yes, forgetting merges ends up with the same result, but I have to manually track which commits actually "belong" with that thread, and which are (sort of) incidental commits that result from merging mutations to lower threads.
<fbond> lifeless: Am I making sense?
<lifeless> fbond: no, because the recipe I gave you before lets bzr track that for you
<fbond> lifeless: let me re-read that
<fbond> lifeless: bzr must be smarter than I was thinking; let me make sure I understand:
<lifeless> fbond: anyhow, meta discussion - I would like looms to work well for you and will happily make changes *that don't preclude its use a collaboration tool* to do that.
<fbond> lifeless: The cherry pick would merge those "incidental" commits, but --forget-merges would drop them and I'd be left with a diff that represents my intent.  Right?
<lifeless> right
<fbond> lifeless: Okay, I can be happy with that.
<fbond> lifeless: I have a tendency to want history to represent my intent, rather than representing what I actually did.
<lifeless> if you'd like to write up some docs for the HOWTO that describe what you want and why
<lifeless> I'd be delighted to try and make this clear to other folk with the same penchant.
<fbond> lifeless: Yeah, I think that would be a good idea.  I feel that this work-flow must not be that uncommon.
<fbond> lifeless: I'll write something up.
<lifeless> thanks!
<fbond> lifeless: and thank you, too.
<fbond> lifeless: I'd like to try this out a bit before writing anything, so it'll probably be a few days.
<fbond> lifeless: Where should I submit a document, the wiki, or elsewhere?
<lifeless> the bug report about this would be good
<lifeless> https://bugs.edge.launchpad.net/bzr-loom/+bug/214657
<ubotu> Launchpad bug 214657 in bzr-loom "Should support rebasing threads" [Undecided,New]
<fbond> lifeless: okay, you got it
<poolie> lifeless: so that description actually corresponds to MissingFeature i think (like 'you should install paramiko')
<lifeless> poolie: ECONTEXT
<poolie> and UnavailableFeature means an unavoidable platform problem?
<poolie> re the warning about windows diff apps
<lifeless> we currently differentiate between skipped, unavailable, known failure
 * TFKyle wonders why people would use bzr in cygwin, just for symlink support?
<poolie> i will try to update the doc to reality
<lifeless> well they might be using cygwin anyway
<fbond> TFKyle: Some people like shell wildcard expansion to work (and other shell features, too).
<TFKyle> fbond: hmm, couldn't they still just use a normal windows Python+bzr on there?
<fbond> TFKyle: Oh, dunno, don't use any of the above.
<abentley> spiv: Other methods, when invoked on formats that don't support them, raise UpgradeRequired.  Would that be suitable for you?
<spiv> abentley: Hmm, the message on UpgradeRequired says "branch" rather than "repository", but apart from that it seems ok.
<abentley> Okay, class RepositoryUpgradeRequired(UgradeRequired)
<spiv> I don't understand why that's better than NotImplementedError, though.
<abentley> spiv: It's better because the semantics are unambiguous.
<spiv> I'm also not sure that it's tasteful to have set_make_working_tree succeed if the new_value happens to match what the repository is hard-coded to do, and raise otherwise.
<abentley> We use NotImplementedError for things that *must* be implemented, like Tree.get_file.
<spiv> It seems like that will lead to callers getting surprised later rather than sooner.
<abentley> Okay, I can raise it all the time.
<spiv> Well, we also use it for leave_lock_in_place
<spiv> (for instance)
<abentley> So if Tree.get_file raises NotImplementedError, that means "implementor was drunk", but if Repository.set_make_working_trees raises NotImplementedError, that means "implementor made a rational choice not to implement it"?
<spiv> Well, it means "this object doesn't implement that"
<spiv> How you assign blame from there seems to be out-of-scope ;)
<spiv> I don't mind we decide that we should have distinct exceptions for those cases, but we don't seem to at the moment.
<spiv> (Otherwise I'd expect us to already have a RepositoryUpgradeRequired defined...)
<abentley> Test suites need to distinguish between these cases.
<spiv> Anyway, I don't feel strongly about how this should be done.
<spiv> So if it does make your testing easier, please do add the exception!
<spiv> I see that Robert on the list shares my impression about the meaning of NotImplementedError
<spiv> So clearly there's a HACKING guideline waiting to be written, one way or the other :)
<lifeless> abentley: *optional* methods use NotImplementedError today, and the test suite looks for that.
<lifeless> abentley: get_file is not an optional method
<abentley> It sounded like you were saying "iff a method is optional, it raises NotImplementedError if not implemented"
<lifeless> abentley: yes, I misread your line beginning 'So if'
<lifeless> abentley: your line was correct
<lifeless> in this particular case I don't think RepositoryUpgradeRequired is appropriate, because we might in future have repositories that don't support this method
<lifeless> (see the discussion about 'repositories are not semantic')
<abentley> So get_file raises it, and therefore we don't have clear semantics for NotImplementedError.
<lifeless> we do have clear semantics: that method isn't available on that object
<abentley> You said it meant the method was optional.
<abentley> We don't have clear semantics about whether the method is optional.
<lifeless> No, I said on optional methods we use NotImplementedError when it has not been implemented.
<lifeless> NotImplementedError always means 'not implemented'
<abentley> Fine.  The semantics we have are not rich enough for me.
<lifeless> ok
<lifeless> what problem is it causing
<abentley> I'm getting test failures.
<lifeless> as in, is it a testing problem or a client code problem
<abentley> I have code that exercises set_make_working_trees, and it fails if NotImplementedError is raised.
<abentley> I don't want it to be unimplemented except on very old formats.
<abentley> Because clone_on_transport is supposed to create an exact copy, and it can't do that if it can't set that setting.
<lifeless> abentley: given the current API your code should catch NotImplementedError
<lifeless> abentley: we do this elsewhere in the test suite when testing optional methods.
<lifeless> abentley: will that do the job for you ?
<abentley> No.  Then I don't have a test that it's implemented on RemoteRepository.
<lifeless> interface tests are not the right place for such a test
<lifeless> bzrlib/tests/test_remote.py is where such a test should live.
<lifeless> such a test can test that the method doesn't raise and let the interface tests test the precise behaviour
<abentley> You know what, screw this.  Spiv approved my plan.  I'm going to submit it to PQM.  If you think it should be changed, change it.
<lifeless> where did that come from
<abentley> That comes from your word games and from acting like your opinion is the only valid one.  Last I checked, poolie was in charge of this project, not you.
<lifeless> *blink*
<lifeless> I didn't know I was playing word games; and I don't see what 'whose in charge' has to do with this - our code gateway is geared around getting enough approval from mature devs, not any one person oking or not oking each patch
<lifeless> but you're obviously upset, and I'm feeling got at with the word games ad hominen
<abentley> lifeless: "who's in charge" has to do with flatly stating that X is wrong and Y is right, despite the fact that other people clearly feel otherwise.
<abentley> lifeless: "Word games" has to do with our argument about whether NotImplementedError had rich enough semantics for our use case.
<abentley> Submitting to PQM has to do with the fact that I have a tweak vote from a mature dev and no vetoes.
<johnny> n
<lifeless> abentley: I have replied to your playing with stacked branches mail as promised. basically I agree with everything you raised.
<lifeless> abentley: In the prior conversation I was making statements about what is present in the code base, I don't think opinion has anything to do with that. I wasn't trying to argue with you about N.I.E., I was trying to work through it to grok the issue you had.
<lifeless> and of couse sending to PQM is fine; as you say - you have enough votes and no vetos. I was purely suprised by the sudden vitriol.
<abentley> From my perspective, your patches are sailing past, while the things I try to do are blocked or delayed, primarily by you.  There has been some tension building.
<lifeless> oh
<lifeless> I know three I've caused grief of arious sorts on
<lifeless> the rich-root format meta-topic
<lifeless> (mind you, I have patches I haven't sent in because they made you unhappy; I think that that one is quite mutual)
<lifeless> the fast-build-tree using Storage
<lifeless> and Storage
<lifeless> we had a long discussion about Storage, and I ended up ok with the goal, but not beinging another concept without cleaning up what we had first, because we have been building a very long tail of uncleaned up things
<abentley> And MPRepo
<lifeless> s/beinging/bringing/
<lifeless> that one I thought john was working on
<abentley> MPRepo was the one I did around Xmas, before trying again with Storage.
<lifeless> yes, using multiparent diffs
<abentley> Also, the other weekend when you suddenly said reconcile should change SHA1s.  That derailed my plans to implement pack1.4 that weekend.
<lifeless> abentley: well, I was offering that to avoid 'pull' in general doing magic. I certainly didn't intend it to derail you.
<lifeless> I've reviewed TransportConfig
<lifeless> :tweak on it, just could be cleared in the class docstring
<abentley> Well, it did, because rewriting SHA1s was was I was trying to avoid.
<abentley> And there would have been no point to doing pack1.4.
<lifeless> the problem is we have stuffed sha1s today. I'd like to say all existing upgraded rich-root/subtrees repositories are just broken, but that seems overly harsh to our users.
<lifeless> anyhow; this is a good point for my day to end
<abentley> But what are those sha1's good for anyway?  We already have sha1s of all the repository contents, so we can do file integrity checks.
<lifeless> we can't detect bit errors or deliberate corruption in the inventory without them.
<abentley> We can't detect deliberate corruption anyway-- they can just rewrite the revision.
<lifeless> I'm off. I do *not* want to be a blocker for stuff you are doing; OTOH I am not going to avoid commenting when I think there is something we can improve on, or which we need to do differently.
<lifeless> if you want to talk later about the tension; try and defuse it or find something I can do differently that will be less disruptive for you, I'd be happy to do that when I'm not about to halt() from low blood sugar
<abentley> lifeless: I am still willing to try.  Lately I have felt like we had lost the ability to work together, which saddens me, because you've been part of my open-source contributions from the very beginning.
<mwhudson> how do i unloomify a branch?
<spiv> mwhudson: you fix https://bugs.edge.launchpad.net/bzr-loom/+bug/203285 :(
<ubotu> Launchpad bug 203285 in bzr-loom "unable to "de-loom" a branch" [Medium,Triaged]
<mwhudson> spiv: oh great
<spiv> Or more helpfully, you pull the relevant revision into a non-loom branch, and then replace the loom with that branch.
<jml> mwhudson: what I do is: move to the top thread, bzr init a new branch, pull in the loom
<jml> mwhudson: maybe that's over complex
<abentley> You can also do bzr export-loom to export all threads as branches.
<jamesh> bundlebuggy seems to have died
<jml> abentley: I'm trying to think of a use case for a branch to say "refuse to stack on me"
<abentley> jamesh: Should be back.
<jml> abentley: I can't think of one that's interesting.
<abentley> jml: If a branch has been stacked on, then it must not be deleted.
<abentley> But if anyone can stack on anyone else's branch, then deleting a branch might break someone.
<jml> abentley: so, I guess if someone has published a branch that they know will be deleted in future...
<abentley> Yes, or else if they just don't want to worry about whether it's safe to delete their branch.
<jml> abentley: maybe it's better to do it the other way around. explicitly say that a branch is ok for stacking
<abentley> jml: We may want to take that approach.  But it implies that no existing branches would be stackable.
<abentley> stack-onable
<jml> abentley: but if there's a simple way to say 'this branch is now ok to be used as a base for stacking', then I think that's ok.
<abentley> Well, it might not be too bad to add that to existing formats.
<jml> abentley: I just can't see myself saying "don't stack on this branch".
<abentley> Generally we would take the approach of creating a new format.
<jml> I was being blissfully ignorant of the implementation :)
<abentley> jml: lucky you.
<jml> it's a user's prerogative :)
<abentley> But if we create a new format, then users with old clients will be affected...
<jml> oh wait, free software
 * jml submits a patch or something.
<abentley> So you can see that the knock-on effect is pretty severe.
<jml> *nod*
<abentley> I think I could live with adding an "allow-stacking" flag to current formats.
<abentley> Though of course it will be required for the actually stacked branches.
<jml> yeah
<jml> abentley: more broadly, if I have a branch that I don't want people to stack on, I'll make that clear-ish in its name (e.g. mumak.net/experimental/some-branch)
<jml> lifeless: does addCleanup have tests?
 * mwhudson works himself into further confusion with looms
<spiv> jml: I don't see any in test_selftest
<spiv> jml: which is where they ought to be
<jml> spiv: grep didn't illuminate anything.
<spiv> Probably not, then.
<mwhudson> if i type 'bzr down-thread' and then decide i didn't want to do that, what should i do?
<jml> bzr switch, I think
<jml> I might be horribly wrong though
<mwhudson> i think it's too late for this loom
<AfC> What's the current "best" repository format to use with bzr-svn?
<AfC> Reason I'm asking is that I am attempting to update my bzr-svn created GTK checkout, but I realized that when it was created (circa bzr 1.3 and bzr-svn 0.4.7) it was in a knits repo. `bzr update` failed (!),
<AfC> ï»¿so I've tried doing the incremental pull trick into a new repo of format --rich-root-packs
<AfC> It is taking 32 minutes per 250 revisions, local disk! This is somewhat astonishing, so I figure I must be doing something horribly wrong.
<AfC> [There is a vcs discussion on a GNOME list this week, and I wanted to be able to report hosting of a few branches]
<spiv> rich-root-pack is the best repository format.
<spiv> Converting between repository formats can be pretty slow, it's not a code path we've done a lot of optimisation on.
<spiv> Especially if it's between formats with different inventory serialisation, that tends to be very slow.
<AfC> spiv: thanks.
<AfC> spiv: do you think it would be faster to import from Subversion directly rather than trying to convert between repository formats?
<AfC> [re]import; the last one took nine days but this time I have it running on a server in `screen` so it ought to be a bit faster :)
<AfC> spiv: (not expecting you to "know"; just curious what your gut feel would be)
<spiv> AfC: Hmm, tough call :)
<spiv> AfC: With bzr-svn 0.4.9, I'd expect re-importing from scratch to at least be competitive.  I wouldn't want to take a bet about which will be faster, though :)
<spiv> poolie: finally sent that _get_line patch to PQm
<lifeless> abentley: I am willing to try too; perhaps tomorrow, but lets try
<lifeless> jml: don't think so; blame poolie :P
<lifeless> mwhudson: down-thread is ~= switch, so you can just switch again; or do up-thread
<mwhudson> lifeless: i got conflicts on down-thread and more when i up-thread-ed again
<lifeless> mwhudson: so to get conflicts on down-thread you must have had outstanding uncommitted changes
<lifeless> mwhudson: these get preserved (deliberately)
 * mwhudson off
<mwhudson> er
<mwhudson> lifeless: yes, i wanted to commit them to a lower thread
<lifeless> if you don't resolve conflicts before switching again, you are in for a world of pain; I think switch and X-thread should refuse to operate while there are unresolved conflicts
<lifeless> oop, thing has finished, bye again :P
<mwhudson> lifeless: ok, but that means there's no "oh crap, i didn't mean to type that" option
 * mwhudson is gone too
<lifeless> mwhudson: propose a better answer then :P
<spiv> Yeah, in an ideal world "bzr down-thread; *oops, conflicts, I don't want to do that!*; bzr up-thread" would be a no-op.
<spiv> I don't want to be the poor guy that implements it, though ;)
<spiv> (Assuming in this case that there's nothing outstanding in the lower thread to merge back up)
<spiv> (Although I occasionally wonder if a "bzr up-thread --dont-merge" option would be a good idea)
<poolie> spiv: well done
<poolie> spiv: thanks for all the reviews and merges!
<nexus10> hi - anyone know where I might find news of nautilus integration for bzr? or konqueror, if that's available?
<spiv> nexus10: the bzr-gtk plugin has a nautilus-integration component
<nexus10> spiv: yeah, but I couldn't get it working, and from a recent irc chat log it seems others have the same problem
<spiv> nexus10: see the README file that comes with bzr-gtk for details of how to get it going
<nexus10> spiv: I've tried, failed -- better try again then :-)
<spiv> nexus10: Hmm, it worked ok for me last time I tried.  I think it needs a fairly new Nautilus and python-nautilus bindings.  I use Hardy, and that seems new enough.
<spiv> (I'm also using the current development branch of bzr-gtk rather than a release.  I don't know if that makes much difference)
<spiv> nexus10: there's a bzr-gtk mailing list, btw
<spiv> nexus10: if you're stuck, that would be a good place to ask for help
<nexus10> spiv: thanks, I'm on Gentoo so I'll make sure nautilus is the latest stable, and try on the bzr-gtk ml if probs
<nexus10> spiv: do you know if there's any integration with konqueror? Found one quote that suggested there is one, but can't find it...
<spiv> nexus10: I don't know, sorry
<spiv> nexus10: there's a "qbzr", I think
<spiv> nexus10: that may be related
<nexus10> spiv: thanks, np -- yeah, qbzr is quite useful
<spiv> I just posted a fix for #213425
<spiv> Reviews and testing of that patch are welcome
<spiv> Happy bug day!
 * spiv gets some dinner
<poolie> thanks spiv
<poolie> bon apetite
<poolie> good night
<jelmer> spiv: thanks for the bug report, should be fixed now
<quicksilver> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2Cbzr&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2003-10-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
<quicksilver> (graph of number of people installing debian packages of VCS systems)
<quicksilver> bzr trailing behind but moving the right way. About to overtake darcs.
<jelmer> nice graphs :-)
<jelmer> does ubuntu have anything like that?
<jelmer> wow, bzr-svn seems to've lost 30 users by being uninstallable in sid for a week or so
<AfC> bzr: ERROR: [Errno 12] Can't create tunnel: Cannot allocate memory
<AfC> (with bzr-svn; but the next incremental pull succeeded)
<AfC> spiv: BTW pulling with bzr-svn direct outpaces pulling from a Knit repo by 24 minutes to 32 minutes
<ubotu> New bug: #215059 in bzr "Cannot push if login is an e-mail address" [Undecided,New] https://launchpad.net/bugs/215059
<ubotu> New bug: #215063 in bzr "v1.3 fails badly when patch being applied twice" [Undecided,New] https://launchpad.net/bugs/215063
<nir_> I'm getting this error "bzr: warning: unknown encoding . Continuing with ascii encoding." on Mac OS X 10.5 with bzr 1.3
<nir_> my locale settings are: "LC_CTYPE="UTF-8""
<nir_> Set by default on 10.5
<spiv> AfC: thanks for letting me know which one won the race :)
<AfC> spiv: I think "won" might be overstating it a bit. It's only at 4800 of >15,000. {sigh}. And I keep getting
<AfC> bzr: ERROR: [Errno 12] Can't create tunnel: Cannot allocate memory
<AfC> Hard to know what is to blame there, but that sort of thing is bad form.
<nir_> Adding export LANG=en_US.UTF-8 to .profile fixed this error :-)
<ubotu> New bug: #215127 in bzr-push-and-update "Error running update on remote path containing a space" [Undecided,New] https://launchpad.net/bugs/215127
<edreamleo> Hello all
<edreamleo> I just wanted to say 'thank you' for an absolutely superb tool.
<edreamleo> bzr has improved Leo's development effort in ways I never dreamed possible.
<edreamleo> More details at: http://groups.google.com/group/leo-editor/browse_thread/thread/4a0a72ad45d14fe0
<spiv> edreamleo: Thanks!
<james_w> edreamleo: that's great.
<edreamleo> The sound bite: bzr does for archiving what Python did for programming :-)
<edreamleo> That is, nothing is dangerous anymore, except possibly not making branches...
<aantn> hello
<aantn> bazaar.launchpad.net can't handle files with nonlatin characters
<aantn> e.g. http://bazaar.launchpad.net/~aantny/screenlets/universal-applets/files/aantny%40gmail.com-20080406154451-ihk6pxnwyxhwdurl?file_id=share-20070820102741-g2qhjaw8auklwqnv-30
<b0ef> ehlo
<b0ef> if you merge a branch and it creates some directory and you get a conflict and you then try to revert, it don't want to remove the directory and you have to manually remove it
<b0ef> what gives?
<abentley> b0ef: People have this strange tendency to complain when we delete their files, even if that's what revert technically should do.  So we try to accomodate them.
<b0ef> abentley: right, but why is there no bzr revert --force?
<abentley> because force is very vague?
<abentley> we have --no-backups.
<b0ef> right, so that will do what I want?
<abentley> Dunno.  If it doesn't, I'll be happy to fix it.
<b0ef> abentley: right, I'll get back to you, then;)
<ubotu> New bug: #215253 in bzr "bzr qannotate should allow to navigate from a diff to a revision" [Undecided,New] https://launchpad.net/bugs/215253
<b0ef> abentley: nope, doesn't work
<b0ef> abentley: I have to manually delete the directory
<b0ef> abentley: even with --no-backup
<abentley> Okay.  Please file a bug, and I'll take care of it.
<b0ef> abentley: aiight, thanks
<b0ef> abentley: seems 54172 pretty much describes it
<b0ef> abentley: still alive?
<ubotu> New bug: #215256 in qbzr "bzr qannotate: implement "search" and "search next"" [Undecided,New] https://launchpad.net/bugs/215256
<abentley> Yes.
<ubotu> New bug: #215258 in qbzr "qbzr: provide extensive help" [Undecided,New] https://launchpad.net/bugs/215258
<blazer> hello folks!
<blazer> up until recently, we've been using bazaar succesfully in our game project, now we have a problem though... bzr push against as central "smart server" results in long waiting time with alot of data being received from the server >50MB.. is this normal?
<beuno> blazer, what version of bzr are you using locally and on the server?
<abentley> blazer: Bazaar periodically auto-packs the repository to enhance performance.
<blazer> we're using 1.3 on both client and server
<abentley> If your *next* push is fast, it was probably auto-pack.
<blazer> aah
<beuno> abentley, couldn't we somehow report to the user that autopack is happening?  There seems to be quite a few users dropping in here because of it
<blazer> it will transfer the whole repository then?
<abentley> blazer: Not necessarily the whole repository, but it could be a significant portion of it.
<blazer> is there any documentation available on this behaviour? I might as well indulge in *something* interesting while waiting ^^
<cory> I'm confused what's being transferred in that case.
<abentley> beuno: Sure, and it's already been suggested.
<abentley> But no one has actually done it.  Which is a pity.  It would make a very small patch.
<beuno> abentley, do you know if there is a bug open for it?
<abentley> beuno: No, I don't.
<blazer> apparently the server stopped sending at about 70MB of data and now the client is sending... I guess this is a good thing? ;)
<abentley> cory: pack-format repositories create a new pack file on every commit.
<abentley> Retrieving those files one-by-one would be teremendously slow.
<cory> abentley: Well, I've run into the same thing, and found that if I did the pack locally on the server and then went about my normal operations on the client, I didn't notice any long waits.  Is the client unnecessarily getting involved in the re-pack?
<abentley> So bazaar combines pack files when there are too many.  It does basically log scaling, so that 1 pack has 1 revision, the next has 10, the next has 100, etc.
<abentley> cory: In some cases, perhaps.  With shared repositories, etc, the local repository may not have all the revisions in the remote repository.
<abentley> But because of the log scaling, long auto-packs are rare anyhow.
<cory> abentley: The local repository may not have all the revisions...what's the implication of that here?  Doesn't that mean that the server should always do its own packing independently of the client?
<abentley> The implication is that it is sometimes necessary to download revisions from the server in order to perform the auto-pack.
<abentley> SFTP servers and FTP server are not smart enough to perform an auto-pack.
<cory> Appreciate your patients.  I'm just curious and trying to understand.  I've since simplified things, but at one point I had a gigantic shared repo, and it seemed to repack more often than I expected, which often ran me out of RAM on the client.
<cory> patience, gah
<jelmer> it does seem to autopack awfully often
<jelmer> once for every 10 revisions pushed or something
<cory> Certainly understandable in the non-smart-server cases, sure.
<abentley> cory: For the smart server, it would make loads of sense to auto-pack on the server.
<cory> abentley: Ok, I was assuming that here.  Things make sense again, thanks.
<abentley> You know how it is-- first make it work, then make it right, then make it fast.
<abentley> server-side autopacking definitely a valuable optimization, but we're still getting into the "make it fast" stage.
<beuno> abentley, I'll take a look at it to see if I understand what needs to be done, and open a bug for it if there isn't one already. Do you have the time/patience to help me with some bits if I get stuck?
<abentley> beuno: Sure
<beuno> abentley, :)
<moquist> poolie: I just switched my .bash* and .vim files to be in a subdir, like you suggested. Much better idea. :)
<beuno> abentley, I've got another thing I'd like to work on. It seems to me many new users tend to forget to do "bzr whoami" before starting to use bzr. I was thinking it might be a good idea to tell the user if they've not set it, the first time they run any bzr command, that they should. Do you think that's something reasonable?
<lifeless> the smart server should autopach already
<abentley> beuno: I'm mix about it, but I'd probably come down on your side.
<abentley> lifeless: Oh, cool.
<beuno> blazer, bug #215323  :)
<ubotu> Launchpad bug 215323 in bzr "The use should be notified that auto-packing is taking place" [Low,Confirmed] https://launchpad.net/bugs/215323
<lifeless> uhm
<beuno> lifeless, any opinions ^?
<lifeless> if we fallback to self._real_repository too early that would prevent the smart server doing it though.
<lifeless> beuno: autopacking is potentially slow; at least on sftp you get a progress bar when it kicks in
<beuno> lifeless, cool, I'll work on it then. How about the notifying users *once* they don't have a "whoami" set?
<lifeless> abentley: good morning; I haven't had coffee or food yet fwiw
<beuno> I tend to forget myself when installing bzr from scratch, and end up committing a revisions gibberish author info
<abentley> lifeless: morning
<lifeless> you know, I htink packs on the smart server will autopack over the wire with the current code
<lifeless> ouch
<lifeless> beuno: one way would be to require an explicit setting always
<beuno> maybe just add a "Committing to /foo/bar as Author <email>"
<abentley> beuno: There's potentially a lotta output on an initial commit.  It's easy to miss.
<beuno> lifeless, you mean change it so that bzr requires you to set it before committing by default?  I actually don't dislike that...  (if it's what you meant)
<ubotu> New bug: #215323 in bzr "The use should be notified that auto-packing is taking place" [Low,Confirmed] https://launchpad.net/bugs/215323
<beuno> abentley, right, it might help further down the road for people who use different emails for different projects, so you know for sure with what you are committing (I use different info for work then for open source)
<lifeless> beuno: yes, I did
<lifeless> and I'm out of caffeine until shops open in a couple o fhours :(
<beuno> lifeless, cool. I like that even more  (thought it would be too intrusive to propose).  I'll file a bug and work on that one too  :)
<beuno> lifeless, sugar is a pretty good replacement for caffeine
<awmcclain> I'm getting a traceback when using bzr annotate. :'(
<lifeless> awmcclain: :(
<awmcclain> lifeless: :''''''''(
<lifeless> awmcclain: works for me
<lifeless> awmcclain: './bzr annotate %' in my editor, current tree
<abentley> annotate also works for me.
<abentley> It would help if you pasted the traceback.
<lifeless> abentley: whats the current bundle format? I'm looking to see if I can make this new datastream integrate bundles too/or reuse bundles
<awmcclain> http://dpaste.com/44228/
<awmcclain> Sorry I didnt'get to taht sooner. :)
<blazer> now the server seems to be autopacking again during a merge command.. why are we punished with this slowness on the day of the deadline? ^^
<abentley> lifeless: Current format is 4
<lifeless> whats 9 ?
<abentley> 0.9 ~= 3
<lifeless> blazer: if you are doing a great number of merges of new revisions, you'll could potentially be crossing the log borders more than once; that said, bzr autopacks *all* the time and it's not a problem
<lifeless> abentley: ah, ok.
<lifeless> blazer: look in ~/.bzr.log
<lifeless> blazer: that will have some info
<blazer> lifeless: on the server or client? the server one doesn't seem to contain much info
<lifeless> client
<blazer> where would the logfile reside on a windows installation?
<lifeless> bzr --version will tell you
<lifeless> awmcclain: you have bzr 1.2; its known to work in 1.4.x
<lifeless> awmcclain: are you able to upgrade to 1.3.1 or bzr.dev?
<lifeless> abentley: bb is responding very slowly/not at all
<awmcclain> Ahh... I didn't know that we were at 1.4!
<blazer> hmm.. I have alot of "not updating child fraction" in the logfile.. should I be worried about this? what is a child fraction?
<lifeless> I'm tempted to say its irrational
<lifeless> but really, its just an overly verbose debug line
<blazer> I see..
<blazer> I'll have to dig into the sourcecode someday when I have time :)
<jelmer> lifeless: shouldn't it be a warning? I find it usually appears when there are progress bars that don;t make sense
<lifeless> abentley: can I ask you some random things about v4 bundles as a shortcut to chasing code pointers?
<abentley> Okay.
<lifeless> in add_fulltext_record, is parents the fully qualified names?
<lifeless> e.g. (('file', filed, revision), ...)
<abentley> Sorry, dunno.
<lifeless> ok
<lifeless> I think its probably just the string revids
<lifeless> add_fulltext_record seems to be used for revisions and signatures only
<ubotu> New bug: #215350 in bzr-gtk "Viz revision menu "view changes" broken" [Undecided,New] https://launchpad.net/bugs/215350
<abentley> lifeless: Yes, that would make sense.
<abentley> The MPDiff format does snapshots as regular mpdiffs with 0 parents.
<lifeless> abentley: so here is what I'm thinking; I don't know if it makes sense to do today or not
<lifeless> (time is short)
<lifeless> I'm generating a new stream for versioned files to eliminate join;
<lifeless> a single record needs to be able to emit multiple items (for weaves); it needs to handle at least four record types - compressed knit delta, compressed knit ft, plain ft, weave.
<lifeless> it seems a very small step to use fully qualified keys (type, id, revision) and allow mpdiff records too
<abentley> it needs to preserve those record types on the wire?
<lifeless> the initial code I need to write to elimiate join() doesn't have to specify serialization, only the object interface
<lifeless> thats a good question; I don't really want to impose large recoding overheads that aren't needed
<lifeless> its possible that we might make the wire protocol require a subset
<lifeless> so the plain ft is there to avoid a gzip,ungzip cycle on deannotation/annotation
<abentley> Well, mpdiff does generate some overhead, though it's optimized for knit.  multiparent entries are recompressed, for example.
<abentley> i.e. knit deltas for revisions with multiple parents have comparison against their other parents done.
<lifeless> the weave is there so that if a server is sending from a weave repo it can just dump the weave (or a filtered list if someone cares to write one) into the stream as-is, which is much cheaper than the N extractions + N diffs otherwise needed
<lifeless> abentley: mpdiff is optimised for size right?
<lifeless> abentley: so I'm thinking of this as a lower layer than the different tradeoffs made by mpdiff vs knit vs annotated-knit vs weave
<abentley> Right.
<lifeless> I'll be quite happy to get rid of join; anything beyond that in code reuse or flexibility is a bonus
<abentley> So mpdiff support at this layer would be about harmonizing the bundle and repo interfaces?
<lifeless> bundle repo and versionedfile
<abentley> it certainly sounds feasible to me.
<lifeless> if we could in principle create a v5 bundle serialiser that can use the same stream as I've made (even tho I'm not doing the network implementation today, that will be in the near future)
<lifeless> ok, I'll write up a document describing what I think will work, I'd value you saying 'this appears to do what bundle serialisation needs' (even though I will be checking against the v4 serialiser code)
<abentley> lifeless: I think converting from v4 would be trivial.  Am I missing something?
<lifeless> I don't think you're missing anything
<abentley> I'm not parsing "ï»¿if we could in principle create a v5 bundle serialiser...".
<lifeless> but I've not done much with bundle internals, and I'd rather have a safety net
<lifeless> oh
<lifeless> reprhasing
<lifeless> "is the concrete stream I come up with compatible with the needs of bundles"
<abentley> It sounds like yes.  It wouldn't be hard to extend bundle format 4 to support different record types.
<abentley> The one thing is weaves.
<abentley> Because bundles do expect each record to correspond to one version, right now.
<lifeless> so I'm thinking the programming interface to read a stream will be iterator of iterators
<lifeless> unified keyspace
<abentley> Could you give me the example for a weave record vs a knit record?
<abentley> Would you get all the fulltexts out of the weave?  Is that what you mean by iterator of iterators?
<lifeless> actually; scrub my last two lines
<lifeless> I am explaining awfully.
<lifeless> I'll be backin a second as well, nature calleth.
<lifeless> I'm thinking of the stream as a sequence of records; each record can yield one or more repository entries (e.g. ('revision', revid))
<abentley> So would a knit record represent a single repository entry?
<lifeless> yes
<lifeless> the reason for this two layered structure is to handle knit and pack repos nearly optimally in the knit->knit and pack->pack case by avoiding double-handling on the client and server
<lifeless> a stream from a knit repository would be one stream record per knit versioned file, with the contents of that versioned file that are needed included
<lifeless> a stream from a pack repository would be one stream record, with all the jumbled-up texts inventories etc included
<abentley> So the record would logically provide a set of unified-keyspace keys, though the byte representation could be optimized.
<lifeless> yes
<lifeless> one way of doing this would be to have a key prefix in the record
<lifeless> not sure if this is a good idea
<lifeless> but it would look like prefix=('text', FILEID), ....
<lifeless> allowing VersionedFile's current keyspace to just be appended
<lifeless> to get the unique keys
<abentley> lifeless: It sounds almost like a normal bundle could be a record.
<lifeless> abentley: yes, I think that that would work well
<luntain> q
<lifeless> or it could be a series of records - the byte representation doesn't need to change either way
<lifeless> its just whatever we think best in terms of programmatic access at this point
<lifeless> the key question is, does this sound nice?
<lifeless> is there anything 'ewww' about it, or suggestions to improve?
<abentley> Well, I go a bit eew at having multiple keys per record, but I can't think of anything better.
<lifeless> (sorry to be monopolising your time with this, but you're the only other folk around to tease this out with)
<abentley> Unless we make an exception for weaves and recode them.
<lifeless> we could at a programmatic level just yield many fulltexts from a weave
<lifeless> at a physical level though it would really be nice to be able to just drop the blob into the stream
<lifeless> also - performance wise, multiple keys per record with a record key prefix helps knit insertions
<lifeless> hmm, thats a bit false
<abentley> The thing is, current bundles use two pack records for each logical record; one for metadata, one for the bytes.
<lifeless> it makes it easier in some ways to add many things to a target knit without having a cache of knits
<lifeless> abentley: I think that that serialisation would work very well for weaves; in the metadata the list of keys to be extracted; in the bytes the raw weave
<abentley> How would you represent this for knits?  AIUI, the index contains data not represented elsewhere.
<lifeless> there is a current knit stream, let me dig up its contents
<lifeless> the knit data stream has a list of (version_id, options, read_length, parents)
<lifeless> and then sum(read_length) bytes after all of that
<lifeless> so it gets to do a single readv() from disk to output the stream
<lifeless> and likewise on insertion, it can often do a single write()
<lifeless> this is the other thing I would like to preserve, because thats pretty good for performance
<lifeless> mapping one of these current knit streams into a single record lets me do that without loss of generality
<abentley> I think it loses the ability to do random access, though.
<lifeless> we don't do random access today AFAIK
<lifeless> not on streams
<guilhemb> Hello, is bzr+ssh:// recommended over sftp:// ? Any reasons?
<lifeless> do we on bundles ?
<abentley> True.
<lifeless> guilhemb: hi, bzr+ssh runs a bzr process at the other end, so it can do more
<chadmiller> I thought I remember a bug specific to ssh+bzr protocol in the past six weeks or so.  I may be wrong.
<guilhemb> lifeless: mmm what more, for example?
<lifeless> sending mail
<lifeless> avoiding some (significant) network traffic
<guilhemb> lifeless: thank you
<abentley> lifeless: It's true that we don't at present, but I was thinking once stacking works, we would be able to do bundles as stacked repos and merge directives as stacked branches.
<lifeless> abentley: yes, we've talked about that before :). Hmm, what would be needed to add random IO to this
<abentley> Well, nothing would be needed for the format.
<abentley> You'd just need to use lots of single-entry records.
<lifeless> I think in principal you'd parse the stream once to build an index and then use the index
<lifeless> this wouldn't imply single or multiple-entry records
<lifeless> we could buffer the whole bundle if we wanted tho on pathological bundles this would really blow memory wise
<abentley> Well, let's say I've got a stream of an entire repository in a single record.  How would I get out one revision?
<abentley> We could also persist an index, to avoid the initial read.
<lifeless> parse the stream once, lets handwave about how we get code reuse, but say that instead of a get_stream on this, we have a 'get_repository' that indexes and then provides VersionedFiles indices for it
<abentley> Depending on size, we might even stick it at the beginning.
<lifeless> for each record, we just need back the index entries it contains
<lifeless> this could be one, or it could be N
<abentley> I mean an index of the stream.
<lifeless> a VersionedFile index needs to be able to answer 'versions()', 'get_parent_map()'
<lifeless> yup
<abentley> So we would know exactly where to seek if we want ('revision', 'foo-bar-asdf')
<lifeless> yes
<lifeless> building the index would do that
<lifeless> we'd have a KnitDataAccess implementation for the whole stream
<lifeless> (or roughly that)
<lifeless> this is what packs do today
<abentley> Okay, but still, how do you seek to a single knit delta when it's inside a massive pack record?
<lifeless> the index provides the readv() that is needed
<lifeless> and there is a data access object which does the readv and strips out any serialisation metadata that needs to be removed
<lifeless> the data access object is stateless
<lifeless> it just knows that e.g. stuff in a .pack has a pack record prefix to strip
<abentley> It just seems pretty gross.  The VersionedFileIndex would have to know way too much about the pack serialization format.
<lifeless> or that stuff in a .knit has no surrounding metadata
<lifeless> abentley: hmm, can I point you at the current code?
<abentley> okay.
<lifeless> bzrlib.knit._KnitAccess and bzrlib.knit._PackAccess
<lifeless> oh, and ._StreamAccess too
<lifeless> these provide the abstraction so that the index doesn't know anything about the serialisation format
<abentley> These are exactly what made me spit the dummy and start a new repository format with none of this legacy stuff.
<lifeless> oh :(
<abentley> brb
<abentley> lifeless: I'm not sure we're in sync here.
<lifeless> ok
<abentley> We are still talking about the case where there is one record with a bunch of entries in it?
<lifeless> yes
<abentley> So in order to do random access, you have to seek into the position in the container that corresponds with the position in the stream that holds the actual bytes?
<lifeless> lets consider two cases
<lifeless> a weave
<lifeless> and a record with many things from the same 'knit'
<lifeless> in the former case, we have to seek in the container and read the entire weave bytes
<lifeless> in the latter case, we only need a small number of bytes
<lifeless> but the 'bzrlib.pack' container API won't let us read less than a full record at its physical layer.
<lifeless> So we'd want to make sure, for performance, that we fix that
<lifeless> one way would be to improve that api - to have a way to say 'read bytes X..Y from within the container record starting at byte Z of this container
<lifeless> another would be to make sure that we always have a bzrlib.pack container record just for the smallest read we may want to do
<abentley> lifeless: We could also achieve it with the current API by chunking up the stream.
<lifeless> abentley: jinx :)
<lifeless> or did you mean chunking at arbitrary points like every 512K or something
<abentley> No, I mean more or less what you did.
<lifeless> I think its useful to be able to read part of a containers record
<lifeless> but perhaps not worth adding
<lifeless> one way we can achieve small chunks is nested pack containers
<lifeless> still, this is down to serialisation now, and in the first instance what I need is the in-memory python code
<lifeless> so I'll write up a developer doc now, and try and include these issues
<abentley> Sure.
<lifeless> brekkie time, back soon
<abentley> So to get back to your main question, I think that bundles could use this format.
<abentley> They would probably ignore the fact that multiple entries were allowed per record.
<abentley> It's a bit overkill for them, and for the other uses.
<abentley> But for weave, it seems necessary.
<lifeless> cool
<lifeless> is that sha field in mpdiffs that of the reconstructed text?
<abentley> I'm on the phone.
<lifeless> okies
<awilkins> DAmmit, why isn't REALLY USEFUL STUFF like "bzr modified" mentioned in the help index....
<jdong> awilkins: WTF! I didn't know that even existed!
<awilkins> It's great... you can just go bzr modified | xargs dostuff
<jdong> awilkins: defintiely, except the only problem is that it outputs paths respective to the root of the branch
<jdong> <wishlist>it'd be nice of bzr st and friends to display paths relative to `pwd`</wishlist>
<awilkins> I hadn't noticed that .... but I tend to do that stuff in the roor
<awilkins> s/roor/root
<jdong> awilkins: yeah, if there existed `bzr root` I would be happy too
<awilkins> Peh, it has a "hidden = true"
<awilkins> Should be "danguseful = true"
<awilkins> Doesn't even show if you pass --long to help ; but --long says "help on all commands", not "help on commands except really useful stuff we don't want you to see to retain our mystique as UBER DOODS"... :-P
<abentley> awilkins: bzr help hidden-commands
<awilkins> abentley: I hate to be pedantic, but (AFAICT) that topic is hidden by default, so how are you supposed to know it's there without picking through the source?
<awilkins> Ok, I'm lying, it's in the topics list
<abentley> liar
 * awilkins cuts out his tongue and pickles it in a jar
<nick125> o.O
<abentley> awilkins: Boutiuqe, not-maintained, achievable-by-other-means functionality is typically hidden.
<abentley> If you can use xargs, surely you can use grep.
<abentley> There should be a status --modified also.
<abentley> There isn't at present, but there should be.
<awilkins> Is find-merge-base in the category of "achievable by other means" ?
<abentley> yes.
<abentley> bzr revision-info -r ancestor:
<awilkins> Aha
<abentley> Also, it is in the category of boutique.
<awilkins> Define boutique in the context of bzr code
<abentley> Operations that an end user should never need.
<awilkins> Does boutique imply achievable-by-other-means or was your list above a set (not a list of synonyms?)
<abentley> A set
<lifeless> awilkins: 'bzr root' exists
<awilkins> I found find-merge-base and revision-info to be useful enough to patch them into the BazaarClient library that bzr-eclipse is using (bot for use in bzr-eclipse, but so I could use the features in my current Eclipse plugin project.
<jdong> lifeless: well it must've only appeared there after your announcement 30 seconds ago :D
 * jdong questions his own sanity
<awilkins> Now, I was less experienced with bzr at the time... they may well be achieveable through other means.
<awilkins> bzr root isn't even in the hidden list ....
<abentley> I don't think there's anything you can get out of revision info that you can't get out of log.
<bob2> it is in the normal bzr help commands list
<awilkins> abentley: True, but it's nice to have the convenience of not having to parse it out.
<awilkins> abentley: I respect the Pythonic "do it one way" thing though
 * awilkins attending to food brb
<bob2> wasn;t there a "bzr help allcommands" or something
<abentley> awilkins: More commands is more intimidating to users, so where possible, we prefer to expose functionality as options to existing commands.
<awilkins> Meh, I keep typing bz rviz]
<awilkins> It does weird things with the bz utility
<lifeless> :P
<awilkins> Mmmm, faggots, mushy peaa, mashed spud and onion gravy
<radix> don't smoke awilkins
<radix> but definitely eat mushy pea and mashed spuds
<radix> with onion gravy
<awilkins> Not fags
<awilkins> faggots
<awilkins> "british meatball" - they usually include offal such as liver
<radix> oh. well, I also don't recommend eating sticks
<radix> whoah. that's one I haven't heard before :)
<awilkins> Definitely comfort food.
<awilkins> Especially "Mr Brains" brand faggots
<ubotu> New bug: #215426 in bzr "MemoryError - recv for HTTP through Proxy" [Undecided,New] https://launchpad.net/bugs/215426
#bzr 2008-04-11
 * ToyKeeper wonders if there is a way to make sftp://host/path resolve to host:path instead of host:/path
<ToyKeeper> (so, a single slash after host would be relative to $HOME, and two slashes relative to root)
<abentley> ToyKeeper: You can get that effect with sftp://~/
<abentley> i.e. sftp://host/~/
<ToyKeeper> Ah, I only tried that with bzr+ssh, which didn't work.
<ToyKeeper> As sftp, it's fine.  I wonder if the other host is just too old to support that syntax.
<lifeless> bzr+ssh doesn't support ~ yet
<poolie> hello all
<lifeless> hi
<ToyKeeper> I don't recall the last time I wanted to specify a repo path from root instead of ~ ...  good to know it's not there yet.  :)
<spiv> Good morning.
<onox> good night
<mwhudson> hello spiv
<awmcclain> "bzr: ERROR: Transport error: Server refuses to fullfil the request" is a bzr error, correct?
<awmcclain> (I'm just trying to do a sanity check on this script I'm writing)
<poolie> awmcclain: yes
<poolie> hello kiko
<poolie> abentley: hi, how about a brief call?
<abentley> poolie: sure.
<abentley> skype?
<poolie> sure, it'll just take a few minutes to start that machine
<kiko> hey poolie
<spiv> poolie: Ok, I've sent that to PQM.
<spiv> poolie: (James and Ian's Branch.set_last_revision_info hook)
<lifeless> spiv: do we both actually reading less than full records from streams at all?
<lifeless> spiv: I'm writing up the new streams api proposal in detail, and wondering whether to do the read() callable thing, or just slap bytes around
<spiv> lifeless: I'm not sure.  I remember doing some of the work to make that possible, I don't recall how far it got.
<lifeless> just saying 'here are the bytes' seems easier to me; once we have the interface in widespread use we could version it again. What do you think?
<spiv> I'm fine with what's easy.
<lifeless> ok
<spiv> Hmm, there's a few fully-approved things lingering on BB.
<lifeless> I don't want to merge the inventory thing
<lifeless> aaron raised important concerns about it in London
<lifeless> that aren't addressed; for all that Ian has approved it.
<lifeless> (so its not been sitting there due to lazy robert; its deliberate)
<spiv> lifeless: you also have " Fix the test HTTPServer to be isolated from chdir calls made while it is running"
<lifeless> that bounced with a spurious conflict I think
<lifeless> NEWS update or something. Be good to merge that.
<lifeless> abentley: btw, I sent a loom:Merge thing to the list yesterday; as the only other active loom dev would you like to approve/resubmit it?
<spiv> (I don't actually see your inventory thing in the list)
<lifeless> sorry, http://bundlebuggy.aaronbentley.com/request/<1199746830.1954.76.camel@lifeless-64>
<lifeless> its resubmit
<lifeless> but doing the things it lists isn't enough, is what I meant
<lifeless> the problems are more conceptual than code
<spiv> lifeless: well, I'm not too worried about the details of resubmit items, given the number of approved and conditionally approved items...
<lifeless> sure, my memory was glitchy
<spiv> That's why we have BB :)
<lifeless> ok
<lifeless> draft written, sending as MERGE hopeing for comments
<abentley> Oh, I think I know a significant factor in the BB lockups-- the automatic merge detection seems to be triggering them.
<lifeless> ah
<abentley> It's a fairly long process, possibly it can be sped up.
<lifeless> which reminds me
<abentley> Or maybe I can reduce the period it takes out locks.
<lifeless> I really need to track down the slow index lookups bug
<lifeless> abentley: could you calculate the things you need to analyse, release lock, do the work, reacquire and insert results ?
<abentley> That would be unspeakably awesome.
<abentley> lifeless: Hard to say.  The framework has hidden the fact that any locks are being acquired.
<lifeless> yes, they tend to do that.
<lifeless> I've become quite allergic to that behaviour as the years have gone by
<abentley> In terms of the process, yes, I don't need to hit the database until I've calculated what's new.
<abentley> about stacking: one case that worries me is when the owner of the stacked-on branch doesn't realize that it's stacked-on.
<abentley> And deletes it, thinking it won't break anyone else.
<lifeless> right
<abentley> Even though the person who stacked on it made an explicit choice.
<lifeless> This is why I punted on auto stacking initially, because then users are always explicitly accepting that risk. Obviously thats not viable for Just Works long term though.
<lifeless> But I don't see any good way of telling people
<abentley> So you're okay with it, if the user explicitly chose to stack?
<lifeless> I don't see a way out
<lifeless> I have minor nightmares about what happened in arch
<abentley> Make it a social problem?
<abentley> It's rude to stack on someone who hasn't invited it?
<lifeless> yeah
<lifeless> bundles are a good example of a form of stacking that works quite well
<abentley> Right.
<lifeless> I think it would be ok for me to branch from you, but stack on bzr.dev. For instance.
<lifeless> by ok, I mean 'pretty safe'
<abentley> The policy stuff I'm working on would allow me to *recommend* that if you upload stuff to my site, you should stack on my copy of bzr.dev.
<lifeless> thats nice
<abentley> I'm leaving out auto-stacking on the local host.
<abentley> Unless the user configures it.
<abentley> But no local stacking by default, since it proved controversial.
<abentley> So I think we don't need a way for branches to declare that they can't be stacked on.  Which means we don't need a new format for stacked-on branches.
<lifeless> abentley: yup.
<lifeless> (beyond it working of course :P)
<abentley> Speaking of formats that don't work, if you decide supporting weaves is too painful, I'm definitely amenable to ditching them at this point.
<lifeless> have a read of the doc
<lifeless> I think it will be easy to work with
<lifeless> and not leak abstractions everywhere
<abentley> One thing I notice is that you provide a way to ensure that the stream can reconstruct a fulltext.
<lifeless> the thing for inventories do you mean?
<abentley> Yes, for inventories.  Bundles don't do that-- they get the compression parent fulltext from the target repo, convert it to the right format, and apply the delta to it.
<lifeless> generally these streams will do the same. there is a case where that does not work though for fetch
<lifeless> if you look at the model1To2Helper
<lifeless> instead of copying inventories it does iter_rev_trees
<lifeless> tweaks the content, and serialises
<abentley> Did you have more to say?
<lifeless> oh sorry; email distraction. damn thing.
<lifeless> so a line delta of an xml6 inventory is not safe to apply to an xml7 inventory, etc.
<lifeless> thats why the inventory option exists, because one needs to be able to construct the inventories to do iter_rev_trees in the model changing helper
<abentley> But an xml7 inventory can be converted into an xml6 inventory.
<abentley> And the delta can be applied to that.
<lifeless> so read in the inventory, parse, downgrade, serialise, then apply the delta
<lifeless> ?
<abentley> Right.
<abentley> You can do it however you want.  Just thought I'd mention the option.
<lifeless> as long as we have deterministic serialisers that will work, but it feels like there is an element of risk we can avoid
<lifeless> If you don't have a strong opinion I'd rather avoid having to have the text storage layer adapt back through the parsed data like that
<abentley> Sure.  It looks fine to me.
<abentley> (Aside from the fact that it doesn't fix bug #2:-)
<lifeless> *blink*
<abentley> BB thinks you promised that this patch would fix bug #2.  Perhaps the bug regex is too forgiving.
<lifeless> ah
<lifeless> I went to https://bugs.edge.launchpad.net/bzr/+bug/2
<beuno> lifeless, just for the record, I feel bad my command not found code ended up getting into the core with both you and abentley being against it  :(
<beuno> s/bad/not satisfied
<beuno> so I'm open to go a different direction, if we can find one that makes everyone happier  :)
<lifeless> beuno: that was a confusing message - not that my vote was 'approve'
<lifeless> *note*
<lifeless> beuno: The core code without a included database I am entirely happy with.
<beuno> lifeless, yes, I saw the approve, I was referring to both of you being against it, even though I split it into two, so we could discuss the remaining part separately
<abentley> beuno: If I felt strongly, I'd have vetoed.  I just don't like the feature very much.
<abentley> So changing approach wouldn't help.
<abentley> But please don't take it personally.
<lifeless> beuno: thats why I'm saying my comment was confusing. The core I'm happy with. The remaining part I'm not.
<lifeless> and as abentley sayss, if we felt stringly we can veto
<beuno> alright, feel less bad about it being piped through with "because poolie said so"  :p
<lifeless> I wrote that two days ago
<lifeless> and thought it included the database at the time I wrote it
<lifeless> then I realised it didn't, but didn't clear the comment field when I changed the vote to approve.
<lifeless> lifeless, here for your confusion.
<beuno> aaah, right, ok ok
<beuno> I can continue the remaining steps as a plugin and try and find consensus along the way
<beuno> ah, I can't reject my own stuff on BB
<spiv> beuno: huh, that's odd.  Oh, because you don't have voting rights on BB in general?
<beuno> spiv, yup yup
<beuno> but I though I could reject my own stuff
<beuno> jelmer, BB still hates me  :)    my patches get approved automatically (one vote), but I can't vote on other patches
<lifeless> hmm, this isn't quite right
<lifeless> the delta closure stuff fits the api, but the api doesn't make it clear how to serialise
<lifeless> shrug; I think it will be more clear in the wash.
<lifeless> actually, no - the key thing is that we're going to want to be able to ask for a full text
 * lifeless goes back to api design for a bit
<poolie> spiv: reading your #213425 fix
<spiv> poolie: ah cool.  I'm just heading off for lunch
<abentley> lifeless: I didn't realize 'till now that was a stale message.  I'll look, but I very much doubt BB caused the delay.
<spiv> Hmm, the set_last_revision_info hook failed to merge.
<Talden> What the recommended CVS to Bazaar path (HEAD, branches and tags)?  I know the cvs2svn does 'the right thing' as I've been through that process... Is the task of getting subvsersion changesets into bazaar straightforward? svn2bzr from a subversion dump dies on even the most trivial dumps I've tried.
<mwhudson> there are versions of svn2bzr around that work, i don't know the details though
<mwhudson> there is also cvsps-import, don't know if that does branches/tags though
<AfC> spiv: that Subversion import is _still_ running. Seems to be going a bit faster, though [I have the shell script loop printing the date each cycle of 100 revisions].
<Talden> cvs2svn is amazingly good at ironing out those CVS inconsistencies.
<AfC> ï»¿It almost seems to imply that accessing newer revisions in an upstream Subversion repo is faster than older ones. {shrug}. It is such a travesty that the pain inflicted by this reflects poorly on Bazaar.
<mwhudson> Talden: there is also bzr-svn of course
<AfC> Talden: you're probably better off to go from CVS to Bazaar direct. The less intermediaries the better.
<Talden> I had a look at there were mentions of svn 1.5 and patching python bindings... I'd rather not have to learn all about python to use the tool.
<spiv> jamesh: your set_last_revision_info branch is failing: http://rafb.net/p/p2S39x21.html
<spiv> jamesh: I'm looking into it now
<Talden> the cvs2svn tool is adding git conversion, hopefully bazaar shouldn't be any harder.
<Talden> It will be interesting to see what happens with repo size... CVS 2.1GB -> Subversion 1.6GB... hopefully Bazaars is a little tighter.  If it's not we'll probably be forced to say bye-bye to a lot of the history to make it more manageable.
<jamesh> spiv: hmm.  I wonder if the conversion code should use _write_last_revision_info()?
<spiv> jamesh: yeah, I was just starting to think the same thing
<spiv> jamesh: after all, we don't really want the hook to fire in this case anyway
<jamesh> spiv: and we don't quite have a valid branch at that point either.
<spiv> Right.
<spiv> So giving that branch object to a hook would definitely be a bad idea.
<spiv> Using _write_last_revision_info fixes the test.  I'll run the full suite and if it passes, I'll resubmit.
<spiv> I suspect this is the only problem.
<jamesh> well, it might be a valid branch by the time the hook is called if it didn't throw an exception earlier :)
<spiv> Heh :)
<jamesh> actually, it hasn't even written the branch/format at that stage
<spiv> Right, so giving a branch 6 object that's pointing to a branch 5 on disk is asking for trouble.
<spiv> Besides, the last_revision_info isn't being changed, so firing the hook is definitely the wrong thing to do.
<spiv> jamesh: tests all pass locally, I'll resend to PQM with that one-line change.
<jamesh> spiv: thanks
<poolie> spiv: paramiko fix looks good
<poolie> i'm going to start doing 1.4 now
<abentley> Okay, Bundle Buggy should never drop mail now.
<abentley> Even if hung when the mail comes in (it will just build up until processed).
<spiv> abentley: nice!
<jamesh> do you know why it dies occasionally yet?
<poolie> is it just me or do we get a lot of lock warnings from the tests now?
<lifeless> thats what prompted me to do my patch
<poolie> is it still awaiting review?
<spiv> We do get a lot of warnings, yeah.
<poolie> it looks like there were a lot more than before
<lifeless> abentley: it was in my browsers POST cache
<lifeless> abentley: I hit retry and it went in; I erroneously blamed BB for the queing
<siretart> hi folks
<siretart> can someone look what going wrong here: http://paste.ubuntu-nl.org/62805/? is this a known bug, or did I manage to fuck up my branch on launchpad?
<siretart> UserWarning: file group LockableFiles(<bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/%7Esiretart/aspectc%2B%2B/debian/.bzr/repository/>) was not explicitly unlocked
<ubotu> New bug: #215522 in bzr "bazaar internal error on FTP push" [Undecided,New] https://launchpad.net/bugs/215522
<poolie> siretart: hi
<siretart> hi poolie
<poolie> i'll check it out
<siretart> I'm trying to imort that into a an rich-pack-root shared repository, using bzr 1.3
<siretart> seems to be related to that, becuase local branching does work, though
<poolie> ah ok
<poolie> this rings a bell
<poolie> siretart: i think abentley will be around in a few hours and i think he is working on a bug related to this
<poolie> sorry but i really need to finish up and leave here
<poolie> if you search lp for "revision not present" you may find the bug
<poolie> siretart: in your local repo would you please run
<poolie> cat .bzr/repository/format
<siretart> poolie: Bazaar pack repository format 1 (needs bzr 0.92)
<poolie> ok
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/215533
<ubotu> Launchpad bug 215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New]
<siretart> poolie: wow. Thanks for filing the bug. Subscribing myself now
<poolie> i suggest you should either upgrade the branch on launchpad
<poolie> or upgrade locally and push up
<poolie> assuming you are able to write to this branch
<poolie> you should just make sure you have a backup first to be sure
<siretart> :)
<poolie> sorry for the interruption
<poolie> when it's upgraded it should be much faster though
<siretart> with 'pushing up', you mean rsyncing it over sftp? (does rsync support sftp at all?)
<poolie> over sftp or bzr+ssh
<ubotu> New bug: #215533 in bzr "Revision not present error pulling from knit to rich-pack-root repository" [Undecided,New] https://launchpad.net/bugs/215533
<poolie> oh obviously you can write to it
<poolie> ppas building now...
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc1 up for testing now
<poolie> good night
<spiv> poolie: hooray!
<AfC> Still importing...
<AfC> Hm. Here's a stupid question. Anyone know if you can get an svn "dump" of a subversion repository with other than local filesystem access to it? Its gotta be faster to rsync that blob down locally and then pull revisions out of it directly. 9 minutes per 100 revisions is crazy.
<mwhudson> svnsync
<mwhudson> i doubt it's very fast though
<AfC> Whoof. Bug report, I think: If bzr-svn is in the middle of a pull, and you try and branch from that repository, bzr breaks complaining index file blah .iix not found. Shouldn't the otherwise accursed locks be preventing this?
<j^> hi, why does .bzr/branch/branch.conf have push_location but parent_location instead of pull_location?
<poco> hi
<poco> any idea on how to tunnel a bzr+ssh on windows? (windows->gateway->ssh-server)
<AfC> Hm. I now have a pack that is 177.9 MB big
<clarby> hi, is it possible to do a partial push? like, i commit A and B, but I only want to push B.
<andrea-bs> clarby: are A and B two files or two revisions?
<clarby> andrea-bs: ah, sorry, they are files (directories)
<andrea-bs> clarby: you can revert the changes made to A, push and recommit A
<clarby> ah, too much hassle .. I can just finish what I'm not done with yet and push it all
<ubotu> New bug: #215674 in bzr-gtk "uncommit needs an option for saving commit messages" [Undecided,New] https://launchpad.net/bugs/215674
<ubotu> New bug: #130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<ubotu> New bug: #215732 in bzr "bzr-buildpackage --native had an internal error" [Undecided,New] https://launchpad.net/bugs/215732
<awilkins> Ok, I just had a massive all-nighter hackathon on my current horrible++ project (involving bzr). Someone give me something to do for the next 20 minutes that isn't hacking horrible Java code :-)
<bob2> haha
<awilkins> THen I can POETS
<mw-home> is there a bzr-svn to go with bzr 1.4?
<awilkins> jelmer: ping
<dato> mw-home: no, according to jelmer in the mailing list
<mw-home> dato: ouch!  I need to rollback to bzr 1.3 then.
<jelmer> mw-home: it's not 1.4 that's out yet btw, it's just the rc
<_MMA_> I don't know if this is a Launchpad or Bazaar question. Is there a way to keep specific files synced between branches?
<jdahlin> Hi, are there any web based frontends for bzr similar to what is used on http://git.kernel.org ?
<jdahlin> basically just a list of project / description / owner / last change
<_MMA_> "Automatically" synced that is.
<johnny> jdahlin, so you don't consider bzr-webserve or loggerhead to be similiar?
<johnny> :)
<jdahlin> johnny: can I get such a view from them?
<johnny> similiar is a very broad term for web viewers :)
<jdahlin> oh, no, not similar enough!
<johnny> you'd have to customize the code
<johnny> patches are accepted i'm sure tho
<jdahlin> eg, I have to do it myself!
<johnny> what do you find lacking?
<johnny> well some things are prolly more on the upstream developer todo than others
<jdahlin> a "list of project / description / owner / last change" and being able to track on a per user basis
<johnny> track on per user i'm sure is coming
<johnny> sorry.. i'm not sure of the details 100%
<johnny> i'm doing the same thing you are prolly :)
<jelmer> jdahlin: I think webserve has such a thing, but I'm nto entirely sure
<ubotu> New bug: #215797 in bzr "regression in annotate on mysql tree" [Undecided,New] https://launchpad.net/bugs/215797
<rocky> don't suppose there are gutsy packages for latest bzr-svn (0.4.9) and bzr 1.3.1 floating around?
<_MMA_> rocky: They might have been backported.
<rocky> ppa has bzr 1.4rc1 and bzr-svn 0.4.6 ... which are incompatible with one another
<jelmer> rocky: I've just removed bzr-svn-0.4.6
<rocky> jelmer: that... doesn't help ;)
<clarby> Hmm, every other time I try to push a commit it just halts. I log into the server I'm pushing to , run break-lock, and it re-push and it works. consistently. Anyone else get this?
<jelmer> rocky: at least it shouldn't complain about incompatible versions anymore..
<clarby> (and my cpu goes to 100% when it halts/hangs)
<rocky> hrm, can't seem to access packages.ubuntu.com
<jelmer> rocky: there's no bzr-svn compatible with bzr 1.4
<rocky> didn
<rocky> *didn't suspect there was
<rocky> mostly i'm just interested in using the latest bzr-svn
<rocky> whatever bzr comes with that is fine
<jelmer> debian sid and ubuntu hardy have the latest
<rocky> don't suppose the src pkg for ubuntu hardy would just recompile on gutsy?
<jelmer> I think that should work, not aware of anything that may break it
<clarby> Does anyone know if you're supposed to send recipients into send_mail() in chunks, or if the MTA chunks them up? (roughly 550 email addresses).
<rocky> jelmer: needs a newer version of python-central it seems
<rocky> ok, looks like i'm good
<rocky> jelmer: don't suppose you have a "getting started with bzr-svn" link for people who need DVCS, never used bzr, but have to deal with a company's svn repo? :)
<jelmer> rocky: there's no specific documentation for bzr-svn other than the FAQ
<jelmer> rocky: bzr-svn makes svn branches feel like regular bzr branches
<rocky> so "bzr branch http://mysvnurl.com/something/trunk" should work just fine?
<jelmer> rocky: yep
<rocky> i'm getting a 401 error even tho svn has cached the credentials for my site
<rocky> in other words, svn ls http://mysvnurl.com/something/trunk   works fine
<rocky> but branch on the same url does not
<jdahlin> jelmer: do you know of a site that uses bzr-webserve, I couldn't trivally find an example
<jelmer> and you're using svn+http://... as the url?
<rocky> no i'm not, lol
<rocky> that's what i asked you above =P
<jelmer> rocky: well, the svn+ stuff is a workaround for a bug in bzr itself
<rocky> gotcha
<jelmer> rocky: it's only necessary if you use authentication
<rocky> i jus couldn't find any docs telling me that i need to prepend svn+ to the url any place
<rocky> ah
<jelmer> jdahlin: no, not aware of any; sorry
<jelmer> jdahlin: bzr-webserve is derived from hgweb
<jelmer> jdahlin: http://code.bitlbee.org/hgweb/ contains an hgweb instance using bzr branches
<jelmer> I think the layout has changed since then though
<jdahlin> jelmer: perfect
<javierder> ping jelmer
<keescook> hi!  I haven't been able to find docs for something I think should be simple to do -- I want to have some kind of hook to run syntax checks before I do a commit for my tree.  where should I be looking?
<exarkun> I can't create tags because my branch format is too old or something.  "bzr upgrade --dirstate-tags", as suggested in the error message which is reported, doesn't fix the problem.
<beuno> exarkun, what does bzr info output?
<exarkun> this http://rafb.net/p/POS2mv85.html
<beuno> exarkun, and what version of bzr are you using?
<ubotu> New bug: #215872 in bzr-gtk "gtk.branchview.linegraph.linegraph() expets tuple but some functions still pass string" [Undecided,New] https://launchpad.net/bugs/215872
<exarkun> I tried with 1.0.0.candidate.1 on one machine and 1.3 on another with the same results
<mtaylor> anybody around with zen on bzr-cvsps-import
<beuno> exarkun, I really don't know, I don't use tags at all  :(
<beuno> maybe a plain "bzr upgrade && bzr reconcile"?
<beuno> (this is me guessing though)
<exarkun> hmm, bzr reconcile
<beuno> exarkun, that's just to fix some problems that might arise on upgrade
<jkakar> It would be cool to have a 'pull' revision identifier that would behave somewhat like last, but based on the pull history.
<jkakar> For example, pull:1 would be the same as last:1.  pull:2 would be the revision before the last pull, and so on.
<beuno> jkakar, feel free to open a bug requesting it  :)
<beuno> you mean "after"?
<beuno> I'm on revno 10
<beuno> bzr pull:1 would pull in revno 11
<beuno> ?
<jkakar> This would make reviewing changes easier.  You could pull a branch, review some changes and make comments.  Then, when comments are addressed do 'bzr pull && bzr diff -r pull:2' to see the changes made since your review.
<jkakar> beuno: Not quite.  pull:N would be a history of revisions at the time bzr pull was called.
<beuno> jkakar, hm, seems a bit more tricky, as you'd have to know what set of revisions you last pulled
<jkakar> beuno: Right, I suspect that's the hard part.  Make bzr pull store a revision history somewhere.
<beuno> jkakar, IMHO, having what revisions you pulled would be a step closer
<beuno> or even how many revisions got pulled/merged in
<beuno> "now at revno X" doesn't really say much to me
<jkakar> beuno: Well, I first thought I wanted exactly what you suggest, but that still means I need to remember an ID to do what I want.
<jkakar> beuno: A better UI is to offer a symbol that I can use consistently.
<bialix> mtaylor: hi, I did several conversion with bzr-cvsps-import and it worked for me.
<beuno> jkakar, right, it's a step closer and seems easier though  :)
<mtaylor> bialix: have you done any of those with rich-root-pack?
<bialix> no, why for?
<beuno> jkakar, I might give showing what revisions you pulled a try, so if you open a bug for that one I might give it a try
<mtaylor> bialix: when trying to push to a rich-root-pack repo, or trying to upgrade, we're getting this:
<beuno> the other one seems a bit over my head
<mtaylor> bzr: ERROR: Revision {('cvs-1:mtaylor-20070503013257-q7msvneefnm8ft54',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x2aaab1ff6050>".
<bialix> mtaylor: upgrade to rich-root-pack is currently broken
<jkakar> beuno: Cool, will do! :)
<mtaylor> bialix: for cvs based things? or in general?
<bialix> I promote importance of corresponding bug report to Critical
<bialix> in general
<mtaylor> upgrade to rich-root-pack being broken should be Critical...
<beuno> jkakar, you can file them as separate bugs, maybe someone else can pick the other one up
<awilkins> Bug is aleady raised to critical
<bialix> mtaylor: sorry for my english. I already promoted it.
<mtaylor> good
<mtaylor> :)
<mtaylor> bialix: does that explain why pushing from a cvs-imported branch to a RRP repo would also break with the same error?
<bialix> Aaron said that new format pack-1.4 should land soon, that's why this bug is not fixed still, IIUC
<mtaylor> um, all the various incompatible formats is starting to get un managable
<mtaylor> I'm trying to move an organization to bzr, and the formats and their inability to interoperate properly is causing various amounts of bitching... fwiw of course
<bialix> mtaylor: I think some common codepaths from non-rich-root to rich-root is just broken and this is affect and cvs-import too.
<mtaylor> ok
<mtaylor> bialix: cool. thanks!
<awilkins> crazy format diversity problem ++
<bialix> currently rich-root needed only for bzr-svn
<mtaylor> but packs are the good-and-efficient thing, no?
<awilkins> Yes, packs ++
<awilkins> rich-root ++ also because good interop with SVN is a key adoption feature
<bialix> packs is very carefully tested and widely used
<mtaylor> bialix: by "packs", do you mean "--pack-0.92"
<jkakar> beuno: Bug #215903 filed. :)
<ubotu> Launchpad bug 215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Undecided,New] https://launchpad.net/bugs/215903
<bialix> so if you don't need bzr-svn interaction it's better to not using rich-roots
<bialix> IMO, of course
<beuno> jkakar, confirmed and assigned to me  ;)
<bialix> mtaylor: yes.
<mtaylor> see, this is the thing though... I even hang out in here alot, and I obviously can't figure out what format I should be using
<jkakar> beuno: Awesome, thanks!
<bialix> mtaylor: better to use default format. pack-0.92 is default
<awilkins> I use rich-root-pack all the time because I have a lot of branches in svn
<bialix> yes, of course
<mtaylor> from an i'm-an-idiot standpoint, pack-0.92 sounds much less stable than rich-root-pack
<mtaylor> something about that 0.92 in the name
<bialix> that's why I called them simply packs
<bialix> 0.92 is version number when they was landed to bzr
<awilkins> Hmph. With pack-1.4 coming up, "pack" as a format alias would be dicey
<awilkins> Are packs optimised for speed or size?
<beuno> awilkins, both  :)
<bialix> for size and speed. but some operations is still too slow with packs
<awilkins> I've seen some papers where compressions formats got some serious performance boosts by sacrificing some size.
<bialix> I'm still use knits for some cases
<bialix> awilkins: there is plans about adding local cache for speeding things up. but still not.
<ubotu> New bug: #215903 in bzr "'bzr pull' should report number of new revisions retrieved" [Wishlist,Confirmed] https://launchpad.net/bugs/215903
<bialix> currently some operations much faster with packs, but others with knits
<jdahlin> mwhudson: thanks for doing the stoqlib/stoqdrivers import and applying the pydoctor patch!
<mwhudson> no worries
<mwhudson> sorry for taking quite so long on the patch, it completely slipped under my radar
<jdahlin> no worries
<jdahlin> :-0
<jdahlin> :-)
<fbond> lifeless: ping
<ubotu> New bug: #78765 in bzr-gtk "Allow diff between two selected revisions in bzr viz" [Wishlist,Confirmed] https://launchpad.net/bugs/78765
<ubotu> New bug: #215996 in bzr-gtk "Select revision dialog doesn't show "sub" revisions" [Undecided,New] https://launchpad.net/bugs/215996
#bzr 2008-04-12
<awmcclain> What's the environment variable that controls which editor bzr uses to write a commit message?
<bob2> EDITOR
<jdobrien> looks like BZR_EDITOR
<lifeless> both
<lifeless> BZR_EDITOR will override EDITOR
<abadger1999> Is there some way to mark a branch as dead with bzr?
<abadger1999> I know I can rm -rf the branch but not everyone has access to the server so I was wondering if there's a way to do that from within bzr.
<ubotu> New bug: #216157 in bzr "push to empty repository causes error" [Undecided,New] https://launchpad.net/bugs/216157
<lifeless> abentley: any idea about this:
<lifeless>   File "./start-bundlebuggy", line 26, in <module>
<lifeless>     from bundlebuggy.controllers import Root
<lifeless>   File "/home/robertc/bundlebuggy/bundlebuggy/controllers.py", line 41, in <module>
<lifeless>   File "/home/robertc/bundlebuggy/bundlebuggy/model.py", line 163, in <module>
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/entity.py", line 651, in __init__
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/statements.py", line 48, in process_mutators
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/statements.py", line 35, in process
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/relationships.py", line 916, in handler
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/relationships.py", line 366, in attach
<lifeless>   File "/usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/properties.py", line 119, in attach
<lifeless> AttributeError: merge
<lifeless> it seems to be this:
<lifeless> http://elixir.ematia.de/trac/browser/elixir/trunk/elixir/properties.py
<lifeless> line 119 does delattr
<lifeless> -> rel.attach(entity, name)
<lifeless>   /usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/relationships.py(366)attach()
<lifeless> -> super(Relationship, self).attach(entity, name)
<lifeless> > /usr/local/lib/python2.5/site-packages/Elixir-0.5.1-py2.5.egg/elixir/properties.py(119)attach()
<lifeless> -> delattr(entity, name)
<lifeless> (Pdb) entity
<lifeless> <class 'bundlebuggy.model.MergeRequest'>
<lifeless> (Pdb) entity.merge
<lifeless> <unbound method MergeRequest.merge>
<lifeless> (Pdb) delattr(entity, 'merge')
<lifeless> *** AttributeError: merge
<lifeless> but entity here is a class not an instance
<bialix> hi, anybody for core guys around? when bzr.dev will start 1.5 development?
<dato> bialix: should be started already as far as I know: it always starts after the rc1 release...
<bialix> dato: I can't find dedicated branch for 1.4 that's why I'm asking. Probably poolie did not finish or publish it yet\
<dato> possibly
<bialix> I don't wanna start 1.5 myself because I have not enough information
<bialix> err, I hope nobody kill me for my bad english
<pygi> hey folks!
<bob2> howdy
<Bambi_BOFH> hi all. a question about the announce list. the domain i view my options on (and i access the list via) is lists.ubuntu.com, but my subscription is for lists.canonical.com. its also seems to be on a different mailman server then the ubuntu lists. is this intentional?
<dato> Bambi_BOFH: afaik lists.ubuntu.com and lists.canonical.com are the same server
<Bambi_BOFH> dato: that explains a bit i guess.
<Bambi_BOFH> interestingly, bzr is listed in https://lists.ubuntu.com/mailman/admin , which i woudl have thought only had one mailmans instance listed
<scode> If I want to maintain a continuous mirror of an upstream CVS repository of non-trivial size/complexity (pkgsrc, freebsd, that kinda stuff), would anyone say there is a suitable software for doing this in a reliable manner at this time? The purpose is to keep a mirror that is branchable in a distributed fashion.
<scode> cvs2svn/cvs2git + fastimport seems to be recommended, but it seems mostly for one-time conversions.
<scode> I know about tailor but have had bad luck with it generally. is there a rock-solid solution that people are using?
<james_w> the one used by launchpad isn't *rock* solid, but they use it to do incremental imports of some pretty large stuff.
<james_w> I can't remember the name though unfortunately, #launchpad might be able to help
<scode> Thanks!
<ubotu> New bug: #216330 in bzr "Bzr crashes when executing log command over smart server protocol" [Undecided,New] https://launchpad.net/bugs/216330
<[1]ian> Hi all.  I am using Bazaar 1.3 for windows and got the error message bzr: ERROR: Generic path error: 'd62egvgtpqqy0o38y0r4.fetch': Failure: unable to
<[1]ian>  rename to '../packs/7f3c802bce73af94369ea3e20c4755dd.pack')
<[1]ian> when I tried to push to a server.  Does anyone know what may have caused this?
<jelmer> what protocol are you using to push?
<[1]ian> ssh, in the form of sftp
<jelmer> odd - it's trying to do a simple file rename on the remote server but failing
<jelmer> what os is the remote server and what ssh server are you running?
<[1]ian> server is running redhat linux with openssh and my client laptop is running parmiko ssh to get authication.conf to work
<herson> how i can send package of slackware for download in bazaar website?
<herson> i build the package for slackware
<Pengwn> where do i find the code for serve ?
<Pengwn> it's not anywhere in ~/lib/python/bzrlib/
<dato> Pengwn: start by cmd_serve() in builtins.py
<herson> someone?
<herson> someone here is administrator of bazaar?
<Pengwn> data thanks.
<Pengwn> sorry data=dato
<dato> happens all the time ;)
<jelmer> herson: Just link it from the download page on the bazaar-vcs.org homepage
<jelmer> herson: it's a wiki
<herson> jelmer: i can put in there?
<jelmer> herson: yep
<herson> jelmer: tanks
<Pengwn> wow I need to learn python sytax :-)
<Pengwn> what's a def run .
<Pengwn> is that part of class cmd_serve ?
<Pengwn> I don't think ctags support python ?
<dato> it does
<Pengwn> oh ok.
<Pengwn> how to a go to a defn is it not [ in vim
<Pengwn> or is ctags -R not enought to recg python?
<dato> Pengwn: try ctrl-5
<Pengwn> hey when did this feature out :-)
<Pengwn> or is it only for python?
<dato> no, it's just vim
<Pengwn> ok actually ctrl-] also working .
<Pengwn> thanks Dato. will remember that.:)
<Pengwn> wow damn limited support for python. ok think will have to do it the hard way or will try eclipse .
<herson> jelmer: i can put my packagens in bazaar launchpad?
<jelmer> herson: I think so
<herson> jelmer: how? you know?
<jelmer> If you're a member of the bzr team you should be able to upload
<jelmer> if you're not yet a member, probably best to email Martin about it
<herson> jelmer: but, Â Which team works to keep a package of a system?
<jelmer> herson: how do you mean?
<herson> jelmer: I have to create a new slackware team for developers to send and maintain the packages?
<herson> poolie: hey mean, you be here?
<matid> Hello there!
<matid> Just a quick question - does bzr support nested repos? I'd like to create a 'projects repository with separate repos within it. Is it going to work reasonably?
 * beuno points matid at LarstiQ 
<matid> I'm trying to achieve something like creating an svn repository with svn:externals pointing to other repos.
<matid> LarstiQ: Hello, are you there?
<LarstiQ> matid: yes
<LarstiQ> ah
 * LarstiQ promptly hides again
<dato> *g*
<matid> :D
<LarstiQ> matid: give me a couple of minutes to eat a bit and such
<matid> LarstiQ: Sure, no problem.
<ubotu> New bug: #216424 in bzr "bzr-svn crashes with conflict error" [Undecided,New] https://launchpad.net/bugs/216424
<LarstiQ> matid: so, nested trees are not done, but what is available is at https://code.launchpad.net/~larstiq/bzr/nested-trees
<matid> LarstiQ: Cool, thanks.
<matid> LarstiQ: Do you possibly have any experience working with bzr-svn?
<LarstiQ> matid: yes, I do.
<matid> LarstiQ: Which version of bzr-svn would you recommend? I got 0.4.9 working with bzr 1.3.1 but it failed to push changes back via svn+ssh
<matid> Now I'm trying to do the same with trunk version of bzr-svn and bzr 1.4rc1 but it gives me segmentation faults on push.
<LarstiQ> matid: Personally I'm now using 0.4.9 with 1.3 and 1.4rc1
<LarstiQ> matid: but the method of access is http with apache2, not svn+ssh
<matid> LarstiQ: Will try this way.
<LarstiQ> matid: are you intending to use bzr-svn with the repository you just mentioned, or are the questions unrelated?
<matid> LarstiQ: You mean nested repos stuff? No.
<matid> LarstiQ: Trying to pull the same repository via svn+https gives me bus error.
 * LarstiQ blinks
<matid> LarstiQ: http://pastie.caboo.se/179726
<matid> LarstiQ: And that's what I got when I tried to push with svn+ssh: http://pastie.caboo.se/179729
<mathrick> hiya
<matid> mathrick: Hello
<mathrick> matid: :)
<mathrick> is there a real reason there's a difference between bzr pull and bzr up on a checkout?
<mathrick> it appears to be rather spurious to me
<mathrick> ie. I'd expect bzr pull without any parameters to perform an update
 * fullermd wouldn't...
<mathrick> fullermd: is there a reasonable scenario where you'd want to perform both a pull and up on a checkout and have them do different things?
<fullermd> Of course.  A checkout is just a working tree on a branch.  update updates the working tree, pull updates the branch.
<jelmer> matid: seems like you hit a python-subversion bug
<matid> jelmer: Argh... I'm trying to get it working since morning.
<matid> jelmer: What is the recommended set up as of now? I'm running trunk 1.6 subversion with bzr 1.3.1 and 0.4.9 bzr-svn.
<matid> jelmer: On Mac OS X, fyi,
<jelmer> matid: I wouldn't recommend 1.6 at the moment but rather 1.5
<matid> jelmer: http://svn.collab.net/repos/svn/branches/1.5.x/ or http://svn.collab.net/repos/svn/tags/1.5.0-beta1/ ?
<jelmer> matid: The crash over https is definitely a subversion bug. I'll see if I can reproduce it here and fix it.
<mathrick> humm, 1.5.x hit a release finally?
<mathrick> jelmer: I *think* I had the same thing some time ago
<mathrick> but I can't remember what the problem was
<jelmer> mathrick: It can't occur with 1.4 since it doesn't even have that function
<mathrick> ah
<jelmer> matid: the other bug I'm not sure
<jelmer> matid: Can you run this in a python interpreter:
<jelmer> import svn.core; print svn.core.SubversionException(1,"blah").args
<matid> (1, 'blah')
<jelmer> matid: thanks
<jelmer> matid: Can you try pushing over svn+ssh again but set the BZR_PDB=1 environment variable? That should put you into a python debugger
<jelmer> once you're in the debugger can you run "print err" and "print err.args" ?
<matid> jelmer: Sure.
<matid> http://pastie.caboo.se/pastes
<matid> Sh**
<matid> jelmer: print err.args outputs ()
<jelmer> and type(err) ?
<matid> <class 'svn.core.SubversionException'>
<jelmer> err.file and err.line?
<matid> 'subversion/libsvn_ra_svn/internal_auth.c':114
<jelmer> and perhaps err.apr_err ?
<matid> 210007
<matid> jelmer: I can try compiling 1.5.x instead of 1.6 to see if it works.
<jelmer> matid: Once sec, I've got a patch coming up to deal with this issue for svn+ssh
<matid> jelmer: Cool.
<jelmer> matid: http://samba.org/~jelmer/bzr/bzr-svn-svn1.5exceptionargs.diff
<matid> jelmer: Applied, testing atm.
<matid> jelmer: http://pastie.caboo.se/pastes
<matid> jelmer: Seems like there's a similar problem in a different file.
<jelmer> hmm, looks like I need to patch all places where SubversionException is being caught
<jelmer> it may be more worthwile to fix this upstream since this is a regression from 1.4
<matid> jelmer: I'll try 1.5 in the meantime, what do you think?
<jelmer> matid: 1.5 probably has the same issue
<jelmer> I'm discussing it with the svn folks at the moment
<matid> jelmer: How about https? Should it work with 1.5 and its bindings?
<jelmer> matid: I think you'll find the segfault is there as well
<matid> jelmer: We'll see, I'm going to try it out.
<matid> jelmer: Yeah, it's the same. push with svn+ssh gives me the same error as in 1.6 and switch to svn+https fails with bus error.
<matid> jelmer: Any news?
<jelmer> matid: working on two patches in parallel to fix those issues
<matid> jelmer: Cool, thanks in advance.
<matid> jelmer: Are you going to publish a patch or simply add it to trunk of bzr-svn?
<matid> jelmer: I've got to be going soon, that's why I'm asking,.
<jelmer> matid: I'm working on getting it fixed in svn
<matid> jelmer: Ah, right.
<jelmer> matid: The patch is just a workaround around svn breaking
<jelmer> matid: one of the other svn devs made a patch that should fix it properly
<jelmer> matid: see http://paste.lisp.org/display/59044#1
<Slant> How do I do per-repository post-commit hooks in bzr?
<Slant> That is, I don't want my post-commit hook to apply to *all* my repos.
<jelmer> matid: That patch should fix pushing over svn+ssh for you
<matid> jelmer: Is it 1.6 only?
<jelmer> matid: both 1.5 and 1.6
<matid> jelmer: Cool.
<jelmer> Slant: Usually we add a configuration setting and let the post commit hook look at that
<jelmer> Slant: this is a python-based hook?
<Slant> jelmer: I just want to run a shell script after a commit.
<matid> jelmer: Seems like it really fixed the issue....
<matid> jelmer: But another one appeared - http://pastie.caboo.se/179770 :)
<jelmer> matid: can you change that line to (self, message, apr_err) ?
<matid> jelmer: Sure.
<Slant> Is there a method in place already for having bzr run a script after a commit?
<matid> jelmer: That's what I got after fixing that line: http://pastie.caboo.se/179771
<matid> jelmer: What do you think?
<jelmer> matid: thanks
 * jelmer looks up what 210007 means
<jelmer> SVN_ERR_RA_SVN_NO_MECHANISMS,
<jelmer> matid: this is over svn+ssh:// or over svn://
<jelmer> ?
<matid> svn+ssh
<jelmer> hmm, that's kinda strange
<jelmer> it shouldn't be doing any auth stuff itself if you're tunneling over ssh
<matid> Yeah...
<jelmer> using svn 1.5 manually with svn+ssh works ok?
<matid> jelmer: Oh, right.
<matid> jelmer: It stopped to work :)
<matid> svn: Commit failed (details follow):
<matid> svn: Cannot negotiate authentication mechanism
<jelmer> matid: wow, that's odd - this works fine with svn 1.4 ?
<matid> jelmer: Yeah, it worked without any problems.
<jelmer> http://www.nabble.com/Crazy-svn%2Bssh-commit-regression-in-trunk-and-1.5-td15349239.html looks relevant
<jelmer> matid: in other words, configuring with --without-sasl may fix it
<matid> jelmer: Yeah, I've seen it. I'm in the middle of applying it as we speak.
<Pretto> hi there, i will love if anyone could give me a direction on how to upload project code in lauchpad to use bzr
<beuno> Pretto, is your project already versioned with bzr?
<Pretto> beuno, no, well i think no
<beuno> Pretto, this might help: https://help.launchpad.net/BzrHowto
<Pretto> beuno, thank you so much
<beuno> Pretto, your welcome, and feel free to drop by with more questions  :)
<Pretto> beuno, ok... i think i will have a lot of them
<matid> jelmer: Cool, works great now.
<matid> jelmer: I'm looking forward to the svn folks fixing svn+https anyway ;)
<matid> jelmer: Thanks for your help and see you!
<jelmer> matid: see r30564 in subversion trunk
<Pretto> beuno, i did it.. thank you
<beuno> Pretto, congrats! :)
<awmcclain> Where's the changelog for 1.4r1? I'm getting a zr: ERROR: Cannot lock LockDir(http://bamboo.fluther.com/repos/pandasite/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<awmcclain> Or, could that be related to the client being at 1.2?
<awmcclain> Oh, wait, no, in this use can client and server are running 1.4 (since they're on the same machine)
<awmcclain> s/can/case
<jelmer> awmcclain: I think you get that error if you try to push over http
<awmcclain> Let me get the commnad that failed it...
<awmcclain> ah
<awmcclain> ok
<awmcclain> after i do a lightweight checkout
<awmcclain> over http
<awmcclain> i'm doing a bzr mv
<awmcclain> locally
<awmcclain> Why would a local mv need to lock the remote server?
<jelmer> awmcclain: And you're committing that move, I assume?
<awmcclain> No
<awmcclain> jelmer: bzr mv /usr/local/src/panda-deploy/releases/20080412223856/panda/* /usr/local/src/panda-deploy/releases/20080412223856
<jelmer> Oh, ok. That's weird then. So the "bzr mv" command is actually the one that raises the error?
<awmcclain> bzr: ERROR: Cannot lock LockDir(http://bamboo.fluther.com/repos/pandasite/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<awmcclain> Yes
<awmcclain> Correct
<jelmer> hmm, that indeed shouldn't happen
<jelmer> Any chance you can file a bug about this?
<awmcclain> FTR this worked in 1.2
<ubotu> New bug: #216533 in bzr "ERROR: Revision ... not present in ... trying to branch libsndfile repository" [Undecided,New] https://launchpad.net/bugs/216533
#bzr 2008-04-13
<awmcclain> Done.
<jelmer> awmcclain: thanks :-)
<ubotu> New bug: #216542 in bzr "unable to do merge on windows" [Undecided,New] https://launchpad.net/bugs/216542
<ubotu> New bug: #216541 in bzr "bzr mv dies when using a checkout over http://" [Undecided,New] https://launchpad.net/bugs/216541
<Linnk> Hey guys, I'm using Bazaar on Ubuntu 7.10. I'm trying to use the gui (Olive) to view a diff of a file, but the diff window simply shows up blank
<jelmer> Linnk: how are you using it exactly?
<Linnk> I click the file I want to see a diff for and click the Diff button in the toolbar
<Linnk> I figured that I would then be asked which versions to diff, but apparently not
<jelmer> Linnk: I think that just checks what changes there are in the working tree
<jelmer> so on a fresh checkout it's correct the window is empty
<Linnk> ah yeah, that explains why it suddenly works now that I've changed some files
<Linnk> so I'll have to use the terminal for diff's between revisions?
<jelmer> Linnk: You can use "bzr viz" to find a revision to show the diff for
<Linnk> jelmer: Ok, thanks a lot :)
<antoranz> Guys! How do I change the "remembered location" of a branch so I don't have to specify it on every "bzr merge" call?
<jelmer> awmcclain: use --remember
<jelmer> s/awmcclain/antoranz/
<jelmer> antoranz: or edit .bzr/branch/branch.conf
<antoranz> what does bzr bind do?
<antoranz> jelmer: what you said worked. Thanks
<bob2> binds a local branch to a remote one
<bob2> making it a checkout (ie commits go to both immediately)
<antoranz> ok
<ubotu> New bug: #216586 in bzr "annotate removed-revision feature" [Undecided,New] https://launchpad.net/bugs/216586
<awmcclain> I'm really at a loss here... I cannot get the bzr-email plugin to work for the life of me. No log entries, nothing. I'm flummoxed.
<jelmer> awmcclain: What did you do to set it up?
<awmcclain> jelmer: I've installed the plugin into my site packages. I've verified that it shows up until the bzr commands
<awmcclain> ...
<awmcclain> and
<awmcclain> I've set the post_commit_to config variable in the branch.conf, and in ~/.bazaar/.bazaar.conf
<jelmer> awmcclain: it shows up in "bzr plugins" you mean?
<awmcclain> correct
<awmcclain> i can also do bzr help email
<jelmer> what os are you on?
<awmcclain> ubuntu gutsy
<awmcclain> it iddn't work in 1.2, and still doesn't work on 1.4r1
<awmcclain> what should my config file look like, do you know?
<awmcclain> i have
<awmcclain> [DEFAULT]
<awmcclain> post_commit_to          = admin@fluther.com
<jelmer> yeah, that should be sufficient I think
<jelmer> running bzr commit doesn't trigger it?
<ubotu> New bug: #181534 in bzr-svn "Discards credentials specified in URL" [Medium,Fix committed] https://launchpad.net/bugs/181534
<schmichael> if i have bzr 1.3 installed what repo format should i use?
<schmichael> it seems to default to pack
<bob2> the default, unless you have some special requirement (e.g. working with branches from svn)
<schmichael> bob2: thanks!
<ubotu> New bug: #216614 in bzr "should not immediately abort of .bzr/format can't be opened" [Undecided,New] https://launchpad.net/bugs/216614
<AfC> there is an annotation cache, right?
<AfC> does it get corrupted? if so, how do you force it to be regenerated?
<spiv> AfC: not (yet) for pack formats.
<matid> jelmer: Hi there. Any news on the issue with svn+https and bzr?
<awmcclain> jelmer: No, running bzr commit doesn't trigger it. At all.
<awmcclain> Are there any hidden log files I should check?
<spiv> awmcclain: ~/.bzr.log, maybe try "bzr -Dhooks commit ..." too.
<awmcclain> hrm
<awmcclain> the -D switch is complaining
<awmcclain> oh oh,never mind
<awmcclain> A ha! Ok. It seems like the email only works if I commit ON the machine, not through SSH
<awmcclain> Why would it not work over bzr+ssh://? Is there a different way to configure the post_commit_to?
<pygi> morning
<wildfire> is their a bzr equivalent of 'git add -i' (it allows you to select particular hunks of a file to add)
<oleavr> wildfire: check out the interactive plugin at http://bazaar-vcs.org/BzrPlugins
<asabil> wildfire: git add is different from bzr add
<asabil> the interactive plugin adds a -i to commit
<asabil> thanks for the advertisement oleavr :D
<oleavr> asabil: "uncle software, coming to a store near you" ;D
<asabil> lol
<bob2> shelve kinda does the opposite
 * asabil needs to implement bzr revert -i when he gets free time and motivation
<wildfire> oleavr, and I just copy the *.py into ~/.bazaar/plugins/ and it'll work?
<oleavr> wildfire: copy the directory in there, yes
<asabil> wildfire: cd ~/.bazaar/plugins
<asabil> bzr branch lp:bzr-interactive interactive
<asabil> wildfire: you will need to have a subfolder inside plugins
<wildfire> asabil, thanks - that branch command seemed to do the trick
<asabil> great
<asabil> let me know if there is any problem with it
<wildfire> asabil, *** Bazaar has encountered an internal error.
<wildfire> wildfire@muspell:/etc/bind$ sudo bzr record-patch
<wildfire> bzr: ERROR: bzrlib.patches.MalformedHunkHeader: Malformed hunk header.  Does not match format.
<wildfire> 'Binary files postfix/virtual.db\t2008-04-04 01:58:00 +0000 and postfix/virtual.db\t2008-04-10 09:06:09 +0000 differ\n'
<asabil> can you paste the traceback somewhere please
<wildfire> asabil, http://pastebin.com/m15c6399a
<wildfire> hmm, when recording the changes I have to give it a patch-name
<asabil> never tried with bzr 1.0.0 actually
<asabil> and record-patch is a different thing than commit -i
<asabil> both bzr commit -i and record-patch are working here
<asabil> using bzr 1.3.1
<asabil> they also worked with 1.1 and 1.2 iirc
<matthewlmcclure> does bazaar support  perforce foreign branches?
<bob2> as in actual perforce branches, or something like them?
<asabil> matthewlmcclure: you can try bzr-fastimport, but never tested it myself
<matthewlmcclure> an actual perforce branch
<asabil> wildfire: ?? can you upgrade bzr ?
<matthewlmcclure> asabil: i saw that, but i'm unclear how to provide input to bzr-fastimport
<asabil> matthewlmcclure: http://bazaar-vcs.org/BzrFastImport/FrontEnds
<matthewlmcclure> one of the wiki pages recommends git-p4, but it looks like that tool is hardcoded to git
<dato> if git-p4 outputs in git-fast-import format, bzr-fastimport should do (or attempt to) do something useful with it
<asabil> right
<dato> but I think that'll be for importing only, not to work with them as foreign branches (like bzr-svn does with subversion's)
<asabil> dato: seems like git-p4 runs git commands
<dato> aha
<asabil> proc = subprocess.Popen(["git", "rev-parse", branch], ...
<asabil> matthewlmcclure: git-p4 can be a good starting point for hacking a bzr-p4
<matthewlmcclure> asabil: that's what i thought; thanks for confirming
<asabil> matthewlmcclure: but as dato said, fastimport is only about importing
<asabil> I don't know if that's enough for you
<matthewlmcclure> right, i'd really prefer two-way foreign branch support
<asabil> someone needs to step up and implement it then
<matthewlmcclure> i'm looking for an interesting project to hack on, so i may give it a shot
<asabil> great :)
<wildfire> asabil, I'm not sure what version of ubuntu this machine is running
<wildfire> asabil, and this is a server
<asabil> :/
<wildfire> asabil, so an upgrade needs to be co-ordinated amongst a larger set of people than just me
<asabil> I understand
<asabil> but isn't it for your own usage ?
<asabil> I mean, why would you need to install bzr on the server ?
<asabil> wildfire: you don't really need bzr on the server
<wildfire> we do if we manage /etc with it
<asabil> wait wait
<asabil> you seem to have called record patch on a binary file
<asabil> that's a bug in bzr-interactive I guess
<asabil> let me try to fix
<matid> Hi there.
<matid> A quick question - what does bzr up do on an unbound branch?
<asabil> updates the working tree
<asabil> this is useful when you push to a server
<asabil> you can run update on the server to update the working tree
<matid> So it's only useful if someone pushes code to my branch, right?
<asabil> yep
<asabil> for unbound branches of course
<matid> Yeah, I know.
<matid> And would bzr pull on an unbound branch be any different from bzr up on a checkout or a bound branch?
<matid> (svn convert here, still failing to grasp all the differences ;))
<asabil> it may be different if you pull from a different url
<asabil> and a pull may not work if the branches have diverged
<asabil> (in which case you need to merge)
<matid> You may need to merge with bzr up too, right?
<asabil> didn't use bzr up extensively, but I think it will merge automatically
<asabil> it would work as in svn
<asabil> if you see what I mean
<matid> OK, thanks.
<matid> I kinda get it now ;)
<asabil> whereas bzr pull fails even when there are no conflicts
<asabil> it fails simply because the code has diverged and requires a merge
<matid> Ahh... So up would be like pull + merge in case pull fails.
<asabil> something like that
<asabil> *I think*
<matid> asabil: Thanks a lot.
<asabil> you're welcome
<dwt> Guys, can somebody help me with this? I'm trying to update a repository to a specific tag, but I don't get how to do this. What seems obvious to me (bzr up -r tagname) doesn't seem to be the way to do this
<dwt> And I'm lost finding this in the docs - though it has to be something easy. :/
<asabil> dwt: can you give more details ?
<asabil> is it a checkout or a branch ?
<dwt> I'm a bit new, I think its a branch, i.e. it has full history
<dwt> If thats what you meant.
<asabil> and what do you mean to update to a specific tag ?
<asabil> yes that's what I meant :)
<dwt> :-)
<asabil> so you branched from somewhere
<dwt> Jes.
<asabil> and you want to rollback to a specific tag ?
<dwt> Well, I am playing around with bzr-svn and have a checkout of the 0.4 branch
<dwt> yes!
<asabil> bzr help revert
<asabil> :)
<dwt> ahhhh
<asabil> or you can crate a new branch from that one
<asabil> (that's generally better)
<dwt> So the best way would be to move this directory aside
<asabil> bzr branch -r tag:mytag . ../branch-mytag
<dwt> branch from it, and only get revision up to the tag from the revision
<asabil> yep
<dwt> Why exactly is that better? I mean, I don't want to start developing on this checkout just yet
<dwt> (and probably never)
<asabil> so that you don't need to checkout again too many revisions
<asabil> if you want to go ahead
<asabil> if you see what I mean
<dwt> So revert really removes the revisions from the repository?
<dwt> uh, thats nastsy.
<asabil> from your local branch
<dwt> Is there not a simpler way to just go back in the history to a specific time?
<dwt> While still retaining all the revisions in the repository?
<asabil> actually I am not sure if revisions are removed from the branch
 * dwt is currently reading the revert docs
<dwt> I'l look this up a bit and come back to tell what I found.
<asabil> oki
<dwt> Thansk anyway for the help so far. :)
<dwt> asabil: Well, the documentation in in bzr help revert is not completely clear on this, but <http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#undoing-mistakes> says that it only throws away local commits.
<dwt> I'm not sure what I should make of this
<dwt> anyway for my usecase revert seems like the right thing for me
<asabil> k
<radix> revert only modifies your working tree
<radix> so it won't delete revisions
<dwt> so also local commits are not deleted?
<dwt> thanks for the clarification radix!
<radix> sure thing
<dwt> ok, thanks and cu!
<rocky> anyone know if there is an equivalent to tag_svn_revision for bzr in setup.cfg (ala python setuptools) ?
<cr3> if I have a remote machine from which I need code updated from a bzr repository, but the machine only has incoming traffic and no outgoing traffic, can I update the remote machine from my local machine using push or somesuch?
<cr3> when I actually did try push, I get the error that the remote machine does not have a .bzr directory, which kinda makes sense because it's not a repository
<cr3> I wonder if I need the bzr-push-and-update plugin, but I think there's a way to make this work somehow
<matid> jelmer: Hi there!
<matid> jelmer: I've got a question regarding bzr-svn, got a minute?
<jelmer> matid: sure
<jelmer> matid: I posted a patch to the subversion development list that fixes the https issue, btw
<matid> jelmer: Oh, cool.
<matid> jelmer: Thanks a lot.
<matid> jelmer: The question is - what is a preferred way of dealing with diverged branches in svn?
<jelmer> matid: There is no preferred way; it's up to you, what do you like best?
<jelmer> matid: You can merge and push, but that may potentially change your existing revision history in svn
<jelmer> matid: Some people prefer rebasing before pushing
<matid> jelmer: Let's say, I branch some code, work with it, but in the meantime someone updates svn. I did bzr pull but I asked me to merge. And so did I, but after a push a strange commit appeared in svn.
<matid> jelmer: It was a duplicate of the commit that was done in between my branch and the push.
<matid> jelmer: And to be honest with you I don't even know how subversion will cope with it. If it's diff based then it should simply ignore it.
<matid> jelmer: So I was supposed to rebase, right?
<matid> jelmer: Oh, in fact it reverted the changes, it's not the same.
<matid> jelmer: Eh, it's the same after all. I don't get it...
<jelmer> matid: "bzr push" will push the current mainline in your bzr branch
<matid> jelmer: Let's say with got a situation like this:
<ubotu> New bug: #216924 in bzr "Push failed using (bzr push lp:). On windows machine" [Undecided,New] https://launchpad.net/bugs/216924
<jelmer> matid: That may involve changing the current mainline in Subversion
<matid> jelmer: I branch the svn code at revision 154. Now another person submits revision 155 and 156 to svn, whereas I make one commit in my bzr branch.
<matid> jelmer: Now what I did was a bzr merge followed by bzr commit and bzr push.
<matid> jelmer: Which resulted in a new svn revision containing duplicated 155, 156 and my bzr changes.
<matid> jelmer: Is this expected behaviour?
<jelmer> matid: Yes, because that's what's in your local bzr mainline
<jelmer> matid: If you want to push something on top of what's in svn, use rebase
<matid> jelmer: Is there a change what I just did (bzr merge and push) broke something?
<matid> jelmer: Or is it just an innocent duplication?
<jelmer> matid: It still contains the same data as is in your local bzr branch
<matid> jelmer: But well, if I did a merge before I pushed it should also contain all the changes that were made in svn in the meantime, right?
<jelmer> matid: yes
<matid> jelmer: Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?
<matid> jelmer: I'm not really used to this kind of behaviour :)
<jelmer> you'll notice the same revisions are in the svn branch as are output by "bzr log --line"
<jelmer> matid: Not sure I understand what you mean by "Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?"
<matid> Hmm...
<matid> jelmer: It seems like bzr log --line shows some differences between svn and bzr.
<jelmer> can you be more specific?
<matid> jelmer: I mean, there's one extra commit in svn between the moment I branched the code and the moment I pushed it.
<matid> jelmer: This is a commit that I merged in bzr by using `bzr merge`
<jelmer> matid: and it's still there if you use "svn log" on the full branch url?
<matid> jelmer: Eee... It disappeared... How come?
<jelmer> matid: it's not part of the mainline
<matid> jelmer: You can't delete changesets in plain svn, or can you?
<jelmer> matid: it's part of the right hand side history. You'll see if you run "bzr log" on the remote svn branch it'll show up indented
<jelmer> matid: Nope, it's still part of the repository, just not part of the mainline history of that branch
<matid> jelmer: Guess I've never stumbled upon this kind of thing in svn...
<matid> jelmer: Which means that both solutions (rebase and merge&push) are going to result in the same code state in svn.
<matid> jelmer: Yet push will rearrange the revision history.
<jelmer> matid: After rebase, you still have to push
<matid> jelmer: Yeah, it's not going to change anything in svn though. Just append new changesets, right?
<jelmer> matid: yep
<matid> jelmer: I guess I'll use rebase then.
<matid> jelmer: I mean for me it makes no difference, but other people are not going to frown upon some strange things going on in svn :)
<jelmer> matid: :-)
<matid> jelmer: It's kinda strange since it looks like I committed changes someone else made earlier.
<jelmer> matid: It matches the behaviour of merge, commit and push for native bzr branches
<jelmer> and that's what bzr-svn tries to do
<matid> jelmer: To me it looks like I'm trying to make others' changesets look like mine :D
<jelmer> matid: the same thing will happen if you use svn merge with a subversion branch
<matid> jelmer: Hm... It's just that in svn I used to do it the other way round.
<matid> jelmer: Work on a branch, then merge changes into trunk and commit there.
<matid> jelmer: I think this would also be possible if I simply kept one clean checkout of svn trunk and merge other bzr branches into it, right?
<lifeless> abentley: ping
<lifeless> morning y'all
<abentley> lifeless: pong
<lifeless> I'm trying to get BB up and running again on squid-cache.org
<lifeless> I'm a little confused by your response to the bug I filed
<jelmer> matid: yes - but if you do that, each merged bzr branch will only show up as a single commit in svn
<jelmer> matid: (since a bzr merge puts only one revision on mainline)
<abentley> I understood you were running TG 1.02 and SQLAlchemy 0.4.4.  Is that right?
<lifeless> did you mean that if I downgrade sqlalchemy somehow, it will fix the error, or that 1.0.4.3 is a hard dependency now
<matid> jelmer: That's what I'd do in svn, but it seems like using rebase is a better solution.
<jelmer> matid: yeah, rebase makes snese in this case
<lifeless> abentley: yes, thats what freebsd ships
<matid> jelmer: Cool. Is there any case in which bzr-like merge and push will prove superior to rebase?
<abentley> lifeless: for revno 249 and later, 1.0.4.x is a hard dependency.
<jelmer> matid: It will probably give better results combining two branches
<jelmer> matid: Rebase simply does diff + patch for each of the revisions you have that aren't in upstream
<lifeless> abentley: you wouldn't happen to know if loggerhead is compatible with 1.0.4.x  ?
<abentley> At least, in my experience, TG 1.0.2 did not work properly with SQLAlchemy 0.4
<matid> jelmer: OK. Which means that in case of not-so-complicated merges it should work the same.
<abentley> lifeless: Sorry, I don't know that.
<lifeless> thats ok, wishful thinking :P
<lifeless> I find myself thinking unpleasant thoughts towards the turbogears maintainers
<lifeless> the dependency tree seems unpleasant
<abentley> I'm quite disheartened about the whole thing.
<abentley> Especially that SQLAlchemy managed to ship two releases which had blatent bugs that my measly test suite caught.
<lifeless> tests FTW
<lifeless> mwhudson: ping
<mwhudson> lifeless: hi
<abentley> This was stupid stuff where they failed to import a symbol they used.
<lifeless> !!!
<lifeless> thats apalling
<abentley> you've got that right.
<lifeless> I do want to talk about the tension that bubbled out on thursday; however sunday morning I woke up with a head cold
<jelmer> matid: yeah
<lifeless> I'd rather be at my best when debugging important things
<lifeless> abentley: welcome back
<abentley> thanks.  Last thing I saw was "ï»¿I'd rather be at my best when debugging important things"
<lifeless> abentley: that was the last thing I wrote
<abentley> Cool.
<lifeless> aarrgghh
<lifeless> abentley: you'll love this. I'm trying to update the turbogears package for freebsd
<lifeless> 1.0.4.3 wants turbojson 1.1.2
<lifeless> there is no egg for 1.1.2
<abentley> That's nutsy
<lifeless> http://files.turbogears.org/eggs/ is where the package is looking
<abentley> 1.1.2 is available on PyPI, though.  It doesn't fall pack to that?
<abentley> s/pack/back
<lifeless> no
<abentley> Strange.  I thought it did.
<lifeless> easyinstall may
<abentley> Oh.
<abentley> Yes, that's what I was talking about.
<lifeless> I'm really not sure what to do at this point
<threeve> I'm trying to get bzr-svn going on Windows using Python 2.5(.2).  I have svn 1.4.6 installed, an have installed bzr 1.3 and bzr-svn 0.4.9 using the binary installers, and installed the updated svn 1.4.6 python bindings.  `bzr version` now crashes for me.  Have I missed something I need to install?
<wildfire> lifeless, i think going back to linux is the answer ;-)
<lifeless> wildfire: this machine has never been linux :(
<lifeless> squid-cache.org
<jelmer> threeve: How did you install svn 1.4.6 ?
<threeve> jelmer: windows binary installer from Tigris, iirc.
<cr3> interesting coincidence, I'm installing squid as we speak
<wildfire> lifeless, ahh, right. well that's nothing a chroot couldn't solve if you get really stumped
<lifeless> wildfire: but even if I did that, this points out a generic problem for folk that are not on development editions of linux
<jelmer> threeve: You can't use a stock subversion 1.4. You need either the one with the patches linked from the bzr-svn wiki page or Subversion 1.5.
<wildfire> lifeless, i don't think developers will ever be 'generic folk' personally. Most people never miss the 'new'
<lifeless> wildfire: EPARSE ?
<threeve> jelmer: Okay, I thought that might be the case but I thought maybe only the patched bindings were necessary.  Building a new Subversion now.  Thanks
<lifeless> cr3: :P
<wildfire> lifeless, most people are not neophiliac's like you and I and most other developers. People who are not on development editions will never, generally, run into the issue since "shiny" isn't what they care about - they are 'generic folk'.
<wildfire>  Therefore the problems of generic folk and development folk are not normally intertwingled.
<jelmer> wildfire: I think more people care about "shiny" than just a couple of developers :-)
<lifeless> wildfire: for this discussion, I'm wearing the hat of generic folk
<lifeless> wildfire: I don't want a shiny bb, I want a working bb.
<lifeless> wildfire: dependency issues between components used by bb have forced bb to require versions that are not available on freebsd; either by being too old, or once fixed, by being too new.
<wildfire> lifeless, with my (slight-tipsy) sysadmin hat on, I'd suggest the best thing would be a specific python chroot devoted to have the right dependancies for tg, sqlalchemy and bb all installed at the specific versions
<wildfire> s/to have/to having/
<wildfire> once they OS has the appropriate ones you can always migrate it back out of the chroot
<lifeless> wildfire: I don't want to sysadmin this service :P. So I'm simply punting the problem to the -noc team there
<Pretto> hi all
<mwhudson> this is strange, right:
<mwhudson> mwh@grond:debian-packaging$ cat .bzr/branch/last-revision
<mwhudson> 2 ted@canonical.com-20080401051631-3zsnbir02j3c0ihp
<mwhudson> mwh@grond:debian-packaging$ bzr revision-history | wc -l
<mwhudson> 30
<mwhudson> ?
<jelmer> mwhudson: yeah, that's very weird
<lifeless> the cached revcount would appear to be wrong
<mwhudson> sure looks like it
<mwhudson> i can try and grab ted and ask what he did i guess
<mwhudson> (it's this branch)
<mwhudson> https://code.edge.launchpad.net/~ted-gould/gnome-power/debian-packaging
<lifeless> abentley: so the api I proposed in my new stream doco doesn't work
<abentley> I guess we're all a bunch of boobs, then.
<lifeless> abentley: I think it will work better if rather than returning the bytes, I return a factory object that can return as_knit, as_fulltext, etc.
<lifeless> I mean, it works ok in the common case
<lifeless> but isn't able to handle the iter_rev_trees thing. I tink that the small change above will.
<lifeless> so I'm doing a hallway test :P
<lifeless> breakfast
<abentley> I don't get it.  Isn't this just for fetch?
<lifeless> its for fetch including the case of plain -> rich roots
<lifeless> I have a call in ~8 minutes with thumper and an errand to run first, back to chat after that
<igc> morning
<jelmer> Hi Ian!
<igc> hi jelmer - I'm back from holidays
<igc> fiji was awesome
<jelmer> :-)
#bzr 2009-04-06
<lifeless> jelmer: what is 'discovering revisions' in a bzr-svn branch operation
<lifeless> jelmer: after the tip of the output branch is set
<jfroy> jelmer: hey, push is still broken :/
<jfroy> pushing to an existing branch emits "Created new branch." no matter what
<jfroy> And --remember seems to be ineffective
<jfroy> Filed: https://bugs.launchpad.net/bzr-svn/+bug/355914
<ubottu> Launchpad bug 355914 in bzr-svn "bzr push always reports that it created a new branch and --remember is ineffective" [Undecided,New]
<igc> morning
<lifeless> hi igc
<lifeless> jml: python commit - 71208 ;)
<lifeless> small steps
<igc> hi lifeless, jml
<jml> igc: hello
<kingos> hi, I have a possible bug, and I am wondering if anyone wants to help me :)
<lifeless> probably, but just ask
<kingos> it seems to be similar to a lot of other bugs, especially #295611
<kingos> I try and do a bzr upgrade --1.9, and it fails with that NoSuchRevision exception.
<kingos> I am using bzr-1.13
<lifeless> what does 'bzr info -v' report?
<kingos> bzr info -v
<kingos> Format:
<kingos>        control: Meta directory format 1
<kingos>         branch: Branch format 5
<kingos>     repository: Packs containing knits without subtree support
<lifeless> does 'bzr check' succeed?
<kingos> um.
<kingos> not sure.
<AfC> Good answer
<kingos> We could be here for a while.
<kingos> 31219 revisions.
<kingos> running
<kingos> I *thought* I ran it before and it didn't return any errors.
<kingos> I imagine this could take a few hours
<kingos> Should I come back when it is finished?
<jfroy> jelmer: push reports that there are no revisions to pull now :p
<lifeless> kingos: please
<lifeless> kingos: you're welcome to remain here in the interim of course :)
<ivan> I'm trying to clone http://bzr.notengoamigos.org/emacs/trunk/ but bzr ate all my memory
<ivan> It hasn't written a single byte into the pack file yet
<ivan> anything I can do besides more memory?
<ivan> using 506MB RSS
<lifeless> ivan: emacs is very big; we're bringing in a bunch of changes of the next couple of releases that will help a lot
<ivan> cool, I will relax until then
<AfC> "bzr ate my memory" ... that's better than "the dog ate my homework"
<AfC> ivan: no idea if this will help, but something I had to do when converting things like GTK from svn to bzr was to work in smaller chunks
<AfC> (this was due to Subversion's server crashing, not Bazaar's problem)
<AfC> by doing
<AfC> $ bzr init .
<AfC> $ bzr pull -r 100 URL
<AfC> $ bzr pull -r 200 URL
<AfC> and so on. Yes, I used a loop and expr :)
<lifeless> ivan: the bulk of that 500MB is probably index handling, that branch is in our default format which is quite memory hungry
<lifeless> igc: so, more bbc today
<AfC> [interestingly, Subversion is horrible at accessing historical revisions; it took over 30 minutes for svn to dig out 100 revisions at first. This dropped to 9 minutes at the end. Unreal]
<AfC> lifeless: (maybe we should politely encourage someone there to upgrade it?)
<ivan> i've crashed svn servers pulling history
<ivan> well, just one :)
<ivan> AfC: seems to be working great, thanks
<igc> lifeless: absolutely - on it now
<igc> lifeless: next review will be for the intertree stuff
<lifeless> igc: what are you waiting on me for
<lifeless> spiv: ping; want to work together today?
<igc> lifeless: nothing yet. I'm hoping you or poolie are chasing that legal issue though
<lifeless> poolie is still on leave
<igc> lifeless: back tomorrow then?
<igc> I had assumed it was today
<igc> lifeless: looks like poolie is back Wed
<lifeless> yes
<kingos> 10% through
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> 10:40 < lifeless> spiv: ping; want to work together today?
<lifeless> also, do I remember correctly that my set_config_option patch was approved by you?
<spiv> lifeless: yes, and BB should remember that for you too ;)
<spiv> lifeless: I think I'd rather work by myself today.
<lifeless> spiv: cool
<lifeless> spiv: you're working on the critical bug yeah?
<spiv> Yeah.
<lifeless> if you need any assistance shout out
<lifeless> I think you'll need to patch the code that does seen_parents = ...
<lifeless> to determine that [some] parents are unavailable and now try to read them etc
<lifeless> spiv: and I agree, 1.13.2 is a good idea
 * spiv ndos
<spiv> nods, even
 * igc food
<kingos> lifeless: bzr check fails
<kingos> bzr: ERROR: exceptions.KeyError:
<kingos> that sounds bad
<lifeless> kingos: well it means the problem is not related to upgrade
<lifeless> is this a bzr-svn converted branch?
<jelmer> lifeless: "discovering revisions" after setting the branch tip means it's determining the revids to use for tags
<jelmer> lifeless: the InterBranch.pull() branch I submitted pretty much eliminates that
<lifeless> ok
<fullermd> Hm.
<fullermd> So, assume I have two branches with shared history, but one has gone way off in its own direction since they diverged.
<fullermd> If, in the "older" one, I do a merge --uncommitted, is it going to pull all those revs into its repository before it does its thing in the WT?
<fullermd> (and/or the same Q with cherrypicks)
<lifeless> no
<lifeless> or
<lifeless> maybe
<fullermd> Hm.  'k.
<fullermd> 'cuz I've got this branch that should have (and does have) a completely linear history.  It also has
<fullermd> Branch history:
<fullermd> Repository:
<fullermd>        502 revisions
<fullermd>         28 revisions
<fullermd> Was trying to figure out how they got crammed in there...
<lifeless> probably that
<fullermd> I have done one or the other of --uncommitted and cherrypicks into it, so...
<lifeless> they won't propogate on push.pull
<fullermd> Or indeed commit (this being a checkout)
<fullermd> Which is slightly weird.  It suggests that would be another difference in what happens where between light/heavy checkouts   :|
<lifeless> igc: would a phone call about the format names help?
<igc> lifeless: not at this point - I'm about to have lunch and I'm deep in other stuff
<igc> lifeless: I'd also like to hear from others beyond you and I
 * fullermd prefers serial numbering.
<lifeless> jelmer: ping
 * igc lunch
<kingos> lifeless: no, not bzr-svn
<kingos> has been around a long long time.
<kingos> has had everything done to it at various points in time
<kingos> eg. uncommit
<kingos> etc.
<lifeless> kingos: please file a bug, I'll generate a little script to get details about whats going on
<kingos> urgh ok
<kingos> lost the output
<lifeless> it may be in ~/.bzr.log
<Peng_> igc: FWIW, I don't like 1.15-development, but development-1.15 seems okay to me. But I'm still happy with development6.
<AfC> Is there a way to stop bzr from adding [merge] when it's giving single line summaries (log, missing, etc) of revisions that just happen to be merges?
<AfC> It's quite annoying. If I wanted that text in the commit message I would have added it.
<igc> AfC: not currently. It there to tell users that there's interesting stuff under that revision
<kingos> hmmm. bzr check seems to have gotten further than last time.
<igc> I guess we could suppress it if you've given -n0 though
<igc> AfC: And the text isn't in the commit message (it's just shown before it)
<AfC> igc: come on, mate. You know what I mean.
<AfC> igc: incidentally, this is the second time I've seen you mention this "-n0" thing. What is that? I don't see it on the help of `bzr missing`
<igc> AfC: missing doesn't support it yet - it has --include-merges though (which is the same thing)
<Talden> It would be good to suppress it if we're going to show those revisions anyway.  That is, if we've asked for the next depth of revisions we don't show [merge].  I also wonder, given that --line is supposed to be quite terse, that another indicator than [merge] (7 characters) might be used.
<igc> AfC: see bzr help log
<AfC> Ah
<AfC> Well, that's fine and nice for `log`. Not much use for the other commands.
<AfC> Anyway, if we could have a global config option to stop bzr adding decorations that we didn't ask for, that'd be great.
<thumper> if I want to merge in a branch but only to a specified revno, can I just go "bzr merge ../other-branch -r 1234" ?
<spiv> thumper: yes
<thumper> spiv: ta
<Talden> Don't you want it to be a range of revisions - or it's a cherry pick I thought
 * Talden is a bzr noob - you have been warned...
<Talden> Ahh no a range of a single rev is cherry pick...
<spiv> Talden: if you give a single revision rather than a range to merge it'll assume you want all the revisions upto and including the specified revision.
<spiv> It's only if you specify a range that you can get a cherrypick.  (And even then, if you choose a range that is forwards and connected/overlapping your current ancestry then bzr will treat it as a regular merge rather than a cherrypick)
<kingos> lifeless: bug filed as #356028
<kingos> lifeless?
<lifeless> kingos: thanks, I'll put together a small script over the next day or two and get you to run it
<kingos> lifeless: thanks.
<kingos> lifeless: what are the implications of this? is our repo busted? or will we be able to fix it?
<lifeless> clearly something is wrong
<lifeless> the nature of that we have yet to ascertain
<kingos> of course. I just thought you may have some ideas what the implications could be
<lifeless> its probably that any missing content is in someones source branch
<kingos> pretty scary! :)
<lifeless> and once we identify it they - e.g. - tibra.com.au - can do a custom push to fix it up
<lifeless> I also need to ascertain *why* you have any glitching occuring
<lifeless> bzr is fairly cautious about copying your history around
<lifeless> as a just in case, don't delete any old branches you have hanging around, or old repos
<kingos> ok
<lifeless> but normal use on an ongoing basis should be fine
<lifeless> 'someemail@blah.com20080728
<kingos> so much for privacy ... left an email address in :(
<lifeless> edit it now, I doubt google will have found it
<lifeless> there's also a tonne of spaces
<lifeless> so I doubt spammers will pickup on it
<lifeless> anyhow, the key its erroring on is roughly when/where something went wrong
<kingos> how do I edit it ... can't see an edit button
<kingos> foudn it
<kingos> thanks for your help lifeless
<lifeless> np. I'm treating this as serious, but we're juggling time to get 1.14 out, which is why you're not getting the script *today*
<lifeless> we have a couple of important RC bugs
<lifeless> spiv: speaking of which...
<lifeless> how goes it?
<vila> hi all
<lifeless> igc: I'm about to call it a day
<igc> lifeless: ok, I'm off to the hospital tomorrow at 9am for most the day btw
<lifeless> igc: good luck
<igc> lifeless: thanks
<igc> lifeless: I'm make a bit more progress on integrating bbc tonight but a review of the gc patch would be great tomorrow say
<igc> s/I'm/I'll/
<lifeless> other than the licence question I think its landable
<igc> vila: can I ask you to tweak (and land into bzr.dev) the InterCHKRevisionTree code as lifeless and jam requested in their reviews?
<Peng_> igc: "lifelessjamcompress" is a weird name. Why would you compress jam, and why would you need a different compress for jam that is alive? :D
<pygi> jelmer, is bzr git supposed to do clones?
<pygi> like this: bzr branch git://github.com/bla/bla.git ?
<pygi> every time I try that I get random number at "Compressing objects" step...
<herzi> alright, my ex-girlfriend wants to write her thesis and I though bazaar would be a good DVCS system for her windows + latex workflow
<herzi> any recommendations on a gui for her?
<AfC> herzi: you mean a Microsoft Windows GUI, I assume
<AfC> herzi: (and not X Windows)
<AfC> herzi: there is http://bazaar-vcs.org/TortoiseBzr
<AfC> I have no idea if it's {complete, usable, nice to use, etc}.
<Talden> Honestly... not really but it is getting better.
 * AfC vaguely wonders what it is that Microsoft people DO do to work with bzr
<AfC> of course,
 * AfC vaguely wonders what it is that Microsoft people DO do to do work
<jpds> lifeless: Do you have an opinion on bug #354843 ?
<ubottu> Launchpad bug 354843 in bzr "Bzr should be smart about who owns ~/.bzr.log" [Undecided,New] https://launchpad.net/bugs/354843
<AfC> herzi: (sorry I couldn't be more help)
<lifeless> jpds: not really, certainly it would be better to tell the user what is wrong
<Talden> AfC - commandline... the odd qbzr command... I'm happy enough at the prompt - getting adoption at work though would require a good GUI or shell integration at the least and probably IDE integration for full buy-in.  We have scaling issues first though that brisbane-core looks like it might resolve.
<AfC> Talden: perhaps we should suggest Sven investigate QBzr on Windows, then
<Talden> AIUI it takes the commandline to invoke the various qbzr dialogs.  Some at my workplace seem to have some sort of allergic reaction when commandline use is mentioned (certainly there's a lot of red-faced frothing at the mouth).
<jpds> lifeless: Yes, my thoughts exactly.
 * Talden wanders off to bed here in NZ.
<jelmer> lifeless: pong
<james_w> jpds: the immediate issue is that the warning is from an external library, and the library also provides no sensible way to determine if it just gave that error so you could add some explanatory text afterwards
<Lo-lan-do> Hi all
<Lo-lan-do> jelmer: Can one install bzrtools from sid on lenny with the bzr backport?
<jelmer> Lo-lan-do: hi
<jelmer> Lo-lan-do: I think so
<jelmer> at least the versions match, I haven't tested the particular combination
<Lo-lan-do> Blargh
<Lo-lan-do>   bzrtools: Depends: python-central (>= 0.6.11) but 0.6.8 is installed.
<jelmer> Lo-lan-do: Is there anything particular from bzrtools you need?
<jelmer> Lo-lan-do: shelve and clean-tree were moved into bzr core from bzrtools
<Lo-lan-do> Let's remove it then, see if anybody complains :-)
<Bluehorn> james_w: Hi James. Aren't you the guy who created package-import.ubuntu.com?
<james_w> Bluehorn: yup
<Bluehorn> james_w: I am trying to get a package of mine imported into bzr, and bzr dsc-import does not cut it for me.
<Bluehorn> james_w: Is the code for package-import somewhere available?
<james_w> it just uses dsc-import under the hood
<Bluehorn> Because I like the package-import setup - having a distinct upstream branch etc.
<Bluehorn> hmm, okay. how do you get the seperation into package-upstream and package-{hoary/warty/you-name-it}?
<Bluehorn> james_w: BTW: Great work. Actually having bzr repos for most ubuntu packages makes it interesting to use bzr for me - so that the exchange Ubuntu<->Debian can go faster.
<james_w> ah
<james_w> I just create the upstream branch by hand afterwards actually
<Bluehorn> Manually, for all packages? Or do you have a script for that?
<james_w> yeah, it's part of the driver script
<james_w> once you have done dsc-import it's easy to find the tip of the upstream branch via it's tag, and this can be branched/pulled out
<Bluehorn> james_w: May I ask if the driver script is available somewhere?  ;-)
<james_w> it's not currently
<Bluehorn> james_w: Would save me some time, I already tried to change dsc-import to support an upstream branch (and to use a shared repo), but I did not dig through the bzr python api fast enough.
<luks> package-import.ubuntu.com seems to have messed up unicode for maintainer names
<james_w> luks: do you have an example?
<Bluehorn> james_w: okay, thank you anyway.
<Bluehorn> james_w: I'll try to reproduce the "pull out upstream" functionality.
<luks> http://package-import.ubuntu.com/libd/libdiscid/hardy/changes
<james_w> Bluehorn: thanks for the feedback
<james_w> luks: thanks, I'll look in to that
<luks> it's utf8 in debian/changes, seems to be parsed as latin1
<luks> *changelog
<Bluehorn> luks: probably dependent on the current user locale... ;-)
<luks> yeah, not a good solution if you are importing the whole distro
<BarryRWUK_> Hi All, I have a problem using Bazaar when sending files using FTP. Apparently my hosts ftp server doesn't support the APPE command. Is there a way around this?
<fallenpegasus> how do i change a default parent like doing --rememeber, without actually doing the pull?
<Tak> fallenpegasus: can you do something like: `bzr pull -r latest-local-revision --remember /foo/bar` â½
<jelmer> fallenpegasus: you can edit .bzr/branch/branch.conf
<fallenpegasus> thanks!
<BasicOSX> Is there a delay from when you push to LP to when PQM can access it?
<LarstiQ> BasicOSX: yeah
<LarstiQ> BasicOSX: you can test that by accessing it via http
<BasicOSX> ok, that explains why I push to lp, the pqm submit and pqm yells at me with a "non-PQM managed branch"
<theAdib> hello all, someone send a diff to me via email starting "# Bazaar merge directive format 2 (Bazaar 0.90)" ... . What do I have to do now?
<jelmer> theAdib: "bzr merge <filename>"
<jelmer> theAdib: or "bzr pull <filename>"
<LarstiQ> theAdib: assuming you are using bzr
<LarstiQ> hey jelmer!
<theAdib> cool: bzr pull foo.patch worked thanks
<LarstiQ> theAdib: good :)
<LarstiQ> theAdib: generated by `bzr send` btw
<james_w> would putting a sentence in the header make sense?
<james_w> either a pointer to a help topic, or "you can use bzr merge <filename>" or something?
<BasicOSX> PQM failures are  back for me, nothing different from the last time I submitted. Error here: http://www.nopaste.com/p/aLsVQmm8v
<LarstiQ> james_w: yeah, I think so
<jelmer> LarstiQ: dude!
<LarstiQ> jelmer: I'm not dead yet!
<jelmer> LarstiQ: how are things?
<jelmer> vila: pingz0rz
<vila> BasicOSX: replace your lp url by an http one (I had troubles with PQM and lp urls, different than yours, but worth a try)
<vila> jelmer: pong
<LarstiQ> jelmer: Anu came to visit from 26th of march till 3 april
<LarstiQ> jelmer: back to long working hours now
<LarstiQ> vila: a colleague of mine has (recently) done some work to build on httplib (and urllib2 a bit iirc) to make it do things we need, more than just GET
<LarstiQ> vila: ie PUT, 100-continue, and I forget more
<jelmer> vila: I was wondering if you had any more feedback on my username patch :-)
<LarstiQ> vila: would you be interested in discussing with him possibly joining forces? Since Bazaar beefs up stdlib in that area as well.
 * LarstiQ would ideally want to upstream it all the way to Python, but maybe a good library on top of it is more feasible
<vila> jelmer: no time today, but roughly, except for maybe  a s/password/user/ it sounded good, I hope to review it tomorrow
<jelmer> LarstiQ: Ahh, that explains your sudden quietness on IRC (-:
<vila> LarstiQ: certainly
<jelmer> vila: Cool, thanks :-)
<vila> the urllib based implementation shows its limits, replacing it by an enhanced httplib is the way to go (urllib2 is targeted at *downloading* *one* url, not the fundation I will chose today if I was starting again)
<LeoNerd> Ooooh the new 'bzr shelve' is now in my debian/testing desktop...
<LeoNerd> Finally
<vila> LarstiQ: httplib is more oriented to connection handling like we need
<vila> LarstiQ: but bzr-webdav already has PUT and some more :-) (It even had 100-continue at one point :)
<jelmer> LeoNerd: yeah, the new shelve is really neat
<LeoNerd> It's cute... it can .. like.. actually cope with pending-add and pending-delete now
<LeoNerd> And it doesn't litter .shelf about the place
<jelmer> LeoNerd: it can even shelve renames :-)
<LeoNerd> Oh.. the old shelve could do that
<jelmer> oh, ok, I wasn't aware of that
<LarstiQ> vila: cool, should I just give him your email address, or is there a more suitable forum to discuss things?
<vila> LarstiQ: here, email, bazaar ML all are fine I think, 100-continue will be welcome in bzr and landing webdav in core is on the agenda, so...
<LarstiQ> vila: k
<jelmer> Tak: hi
<Tak> jelmer: hey, what's up?
<jelmer> Tak: Looks like I can finally build monodevelop-bzr \o/
<Tak> hooray!
 * Tak brace for critique
<jelmer> Tak: I'm not getting it to load yet
<jelmer> Tak: I've also fixed some things in my  branch to get it to build
<jelmer> Tak: System.InvalidOperationException: Type 'MonoDevelop.VersionControl.Bazaar.BazaarCommands' not found in add-in 'MonoDevelop.VersionControl.Bazaar,1.9.3'
<vila> BasicOSX: Once my patch land, you may want to edit the NEWS file, I wasn't clear about where to put the fix for #355273
<BasicOSX> ok
<BasicOSX> PQM still eating on it
<Tak> jelmer: that's defined in BazaarCommands.cs - is there maybe an old assembly floating around?
<vila> BasicOSX: Eerk, just saw that, I thought your 'Approved' meant: 'Go, sent it to pqm' :-/
<BasicOSX> he
<BasicOSX> heh
<BasicOSX> Your mailing list said if you would like to merge yourself
<vila> BasicOSX: So, you're still using lp:~tanner/bzr/1.14rc1, you can use http://bazaar.launchpad.net/~tanner/bzr/1.14rc1
<vila> BasicOSX: *I* had problems with lp urls making PQM hang, but that's me :)
<vila> BasicOSX: yeah, sure, no problem
<vila> I'm off, have a nice day all
<vila> BasicOSX: by the way, I worked a bit on bug #355454, AFAICS, the warning is still harmless, we should avoid it, but the strings *are* different when the warning fired (one path is file, the other is its base dir), so don't worry too much about it)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/355454/+text)
<vila> if even ubottu times out now :)
<pygi> who's gonna gimme a quick line to migrate git repo to bzr? :)
<pygi> (and yes, I know about fast-import)
<jelmer> Tak: no, that doesn't seem to help
<jelmer> pygi: bzr git-import ?
<pygi> jelmer, o, such a command exists? xD
<jelmer> pygi: if you have bzr-git installed
<pygi> jelmer, yes, I do
<pygi> jelmer, I tried doing "bzr branch git://path" but it didn't work :p
<jelmer> pygi: oh, that should work
<pygi> jelmer, hm, this command seems to have same problem...compressing objects stops at random percentage
<jelmer> pygi: please file a ug
<jelmer> *bug
<pygi> jelmer, bzr: ERROR: mmap.error: [Errno 22] Invalid argument
<pygi> oh well
<pygi> will do
<jelmer> pygi: ah, you're running python2.6 ?
<pygi> jelmer, yes?
<jelmer> pygi: there's a bug in the way bzr-git uses the offset argument to mmap apparently
<jelmer> and that parameter is only available in py2.6
<pygi> jelmer, right, so I should just try calling bzr with py2.5?
<jelmer> Tak: perhaps I'm installing the plugin differently; I'm building a repository and installing from that
<jelmer> Tak: is there an easier way?
<Tak> I'm building the plugin, then manually dropping the dll into my addins directory
<Tak> I guess if it doesn't work to create a repo and install that way, it needs to be addressed, though
<pygi> jelmer, want a patch for sha deprecation warning?
<jelmer> pygi: where is that occurring?
<pygi> jelmer, dulwich if I remember right
<BasicOSX> pygi:  sure that isn't a pycrypto issue?
<pygi> BasicOSX, well, it tells me that sha is deprecated, to use hashlib instead :p
<jelmer> pygi: Are you using the latest dulwich, I thought we had fixed all those issues..
<jelmer> Tak: woot, I got it working now
<pygi> jelmer, latest from bzr
<Tak> woo!
<BasicOSX> vila:  just point of interest, if my pqm of your patch played ok, won't your pqm just fall out with nothing to do? I still see your patch playing.
<jelmer> pygi: in that case, please submit
<pygi> jelmer, will do, I'll try to fetch/install once again
<lifeless> BasicOSX: it will find a merge to do
<jelmer> lifeless: pong
<lifeless> hi
<jelmer> lifeless: you pinged me yesterday?
<lifeless> *gone*
<lifeless> [as in the reason is gone]
<jelmer> lifeless: ah, ok
 * jelmer wonders how much review plugging he can do before it becomes annoying
<lifeless> jelmer: for your serialiser?
<jelmer> lifeless: InterBranch.pull in particular, as that will be very noticable to bzr-svn users
<jelmer> lifeless: I'd already given up on RIOSerializer making it into the new format - am I mistaken?
<lifeless> yes, it can't get in 1.14, it can in 1.15
<lifeless> beta format != no more changes
<jelmer> lifeless: ok, so I guess that means I have at least another week or to to whine about reviews for that :-)
<james_w> hmm, I seem to have a case of bzr pushing a full branch to launchpad again
<james_w> Using saved push location: bzr+ssh://james-w@bazaar.launchpad.net/~james-w/bzr/bzr.dev.hooks
<james_w> Source format does not support stacking, using format: 'Remote BZR Branch'
<james_w>   bzr remote repository
<james_w> Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/
<james_w> then lots of data being sent
<lifeless> james_w: bzr version?
<james_w>     revision: 4230
<james_w> hmm, that's a bit old
<jelmer> lifeless: what is record_entry_contents() used for these days?
<lifeless> jelmer: commit
<jelmer> lifeless: as opposed to record_iter_changes, I mean?
<lifeless> jelmer: we use record_iter_changes when it will be faster
<jelmer> is there any way I can force either to be used?
<lifeless> not currently, why?
<james_w> still get the same message with the tip of bzr.dev
<lifeless> james_w: rev 4174 fixed it in theory, if the /~bzr/bzr/trunk is stackable on lp
<grettke> Hi folks, I've got a question about doing a bzr push to a svn project that does not yet exist. I'm doing a bzr push --create-prefix [url.../trunk] but bzr complains: ERROR: Prefix missing for branches/merged; please create it before pushing. Both branches and tags projects exist. I am confused; what is wrong here?
<james_w> it should be, if it isn't we should certainly fix that
<jelmer> grettke: which version of bzr-svn?
<lifeless> james_w: it is
<jelmer> lifeless: I don't have record_iter_changes implemented for bzr-svn yet
<lifeless> james_w: so, check your ~/.bzr.log
<james_w> nothing interesting
<jelmer> grettke: if it's not bzr-svn trunk then you need to use "bzr svn-push" rather than "bzr push"
<lifeless> james_w: if you can reproduce this, get a trace using -Dhpss and file a bug
<james_w> [14773] 2009-04-06 23:52:29.421 INFO: Source format does not support stacking, using format: 'Remote BZR Branch'
<james_w>   bzr remote repository
<james_w> [14773] 2009-04-06 23:52:29.427 INFO: Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/
<james_w> 11.267  Using fetch logic to copy between KnitPackRepository('file:///home/jw2328/devel/bzr/.bzr/repository/')(<RepositoryFormatKnitPack6>) and RemoteRepository(bzr+ssh://james-w@bazaar.launchpad.net/%7Ejames-w/bzr/bzr.dev.known_hooks/.bzr/)(<RemoteRepositoryFormat>)
<grettke> jelmer: I am using bzr 1.12 (standard install). Where do I check which bzr svn is it?
<grettke> jelmer: I see. It is definitely not trunk.
<jelmer> grettke: in that case you can't have the latest bzr-svn, so you'll need to use "bzr svn-push"
<jelmer> grettke: as of bzr 1.14 "bzr push" will Do The Right Thing
<grettke> jelmer: I see. Thanks
#bzr 2009-04-07
 * SamB gripes about bzr viz not being able to run from a repo ...
<jelmer> lifeless: will iter_changes() yield unchanged parent directories of changed files
<lifeless> jelmer: look for use_record_iter in commit.py
<lifeless> james_w: ping
<james_w> hey lifeless
<lifeless> james_w: can I get you to debug the stacking bug you stuffered?
<james_w> sure
<lifeless> look at rev 4174
<lifeless> it has the last change to this
<lifeless> and a test
<lifeless> pdb somewhere in its new code should help isolate whats going on
<spiv> lifeless: you're welcome to come up here today.
<lifeless> spiv: ok, I'll head up shortly then if thats ok; we've got a lot to get across :)
<james_w> ah, that sort of debugging :-)
<lifeless> james_w: yes :)
<james_w> tomorrow then I feel
<spiv> lifeless: sure.
<lifeless> ok
<lifeless> james_w: please attach bzr info -v of your source branch then
<lifeless> james_w: as well as checking you did push with a bzr >> 4174
<pygi> is there any docs for nested branches support?
<jelmer> lifeless: well, I'm almost done implementing record_iter_changes
<jelmer> lifeless: is iter_changes() O(delta) or O(tree) on bbc trees?
<lifeless> jelmer: working tree is O(tree), revision trees are a function of delta size and log(tree)
<lifeless> -> train to spivs, online again in ~40
<thewrath> hello all
<lifeless> jelmer: back
<jelmer> lifeless: IIUC iter_changes does depth-first search based on the target tree?
<jelmer> so if I see a directory is being processed and then see some sibling is being processed I can assume that directory is "done" ?
<lifeless> jelmer: I wouldn't make that assumption
<lifeless> jelmer: because it can jump around with renames and stuff
<lifeless> it might start with one file in a dir, then subdirs, siblings, then find that the dir was reparented and include the parent
<BasicOSX> lifeless:  just came here to report the stacking issue, but I see you are on it, I was just about to upload 1.14rc1, I can wait if bug 354036 fix is close
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036
<lifeless> BasicOSX: we're getting close, I'm landing the last bits of brisbane-core at the moment too
<BasicOSX> we are all good then, was working vila  osx patches and Ian's filter registration patch, so I can hold off until that lands
<lifeless> BasicOSX: cool
<Peng_> BasicOSX: Are you planning to merge the RemoteBranchConfig stuff from r4251 of bzr.dev into 1.14?
<BasicOSX> Peng:  no one specifically requested that
<Peng_> Eh.
<Peng_> lifeless: ^^ Did you want that for 1.14?
<lifeless> BasicOSX: Oh, I thought I did
<lifeless> BasicOSX: in my mail about it to the list, I noted that it fixes a regression vs 1.13
<BasicOSX> hmm, only merge requests I see are the osx test failures and the simplify the content filter registration API
<BasicOSX> well, and bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036
<lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D53C9C.2070200%40mattnordhoff.com%3E
<lifeless> actually thats not the one
<lifeless> BasicOSX: its rev 4251 of bzr.dev
<lifeless> I'll send a mail now
<vila> hi all
<Peng_> vila: Hello
<BasicOSX> lifeless:  got that,   (robertc) Fix handling of fallback repositories some more, just cannot find request to cherry pick it (hello vila)
<lifeless> BasicOSX: I've just sent one to the list
<vila> BasicOSX: That was the purpose of lp:~vila/bzr/1.14
<BasicOSX> I apologize if I missed the initial request... oh, wait
<BasicOSX> info overload lately trying to weed through the 1.14 RC date thread :-(
<lifeless> :P
<vila> BasicOSX: np, that's what teams are for :)
<lifeless> if I can ask a small favour
<lifeless> please leave pqm clear for thie next cole of hours, I'm trying to land all of brisbane core
<BasicOSX> np
<lifeless> and finding gaps in e.g. python2.4 support for it
<lifeless> which are trivialish but a round trip to fix
<Peng_> lifeless: All of it? Like, "bzr merge ../brisbane-core"?
<vila> lifeless: fwiw, full test suite passed for python2.[456] here
<lifeless> Peng_: well no, I'm not planning on do that at all
<lifeless> Peng_: but do the point there is nothing we want to land
<lifeless> vila: check the _chk_map.pyx and _groupcompress.pyx files :)
<lifeless> vila: _chk_map is in .dev, groupcompress in p.u.c/~robertc/baz2.0/integration
<Peng_> lifeless: Oh. Well, congrats. :)
<lifeless> groupcompress up to ascii :)
<BasicOSX> lifeless:  sorry to pester, but did you find the initial request to merge fallback repositories stuff? I would like to know so I can attempt to fix the holes in my tracking of merge requests.
<lifeless> BasicOSX: I haven't kept looking
<BasicOSX> np
<lifeless> BasicOSX: the fallback repositories stuff was fallout exposed by fixing the config stuff
<lifeless> the branch was about configs
<vila> BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it and prepare the branch for you to merge
<vila> BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it *in bzr.dev* and prepare the branch for you to merge in 1.14
 * BasicOSX groans 
<lifeless> bug 354036
<BasicOSX> Getting 354036 issue
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/354036/+text)
<lifeless> bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036
<lifeless> vila: thats a different bug ;)
<vila> grr
<lifeless> vila: so have we fixed --parallel ?
<BasicOSX> Peng:  thanks for the catch on the missed merge
<vila> then #354075 fixed by matt, merged by lifeless in his 'Fix handling of fallback repositories some more' patch
<BasicOSX> should the http transport for vila's 1.14 branch work (pass the smart server code)?
<vila> lifeless: --parallel works great here
<vila> lifeless: but you mentioned problems with ec2 ?
<BasicOSX> http worked :-)
<vila> BasicOSX: you mean for pqm submissions ?
<lifeless> vila: yes
<BasicOSX> no, to merge your code into my prepare-1.14rc1 (lifeless  requested I stay out of PQM for a couple hours)
<lifeless> BasicOSX: http doesn't trigger the problem
<lifeless> BasicOSX: oh, you can merge from lp all you want, just don't run bzr pqm-submit :)
<lifeless> vila: give ec2test a spin, you'll see
<lifeless> FAIL: test_merge.TestMergerEntriesLCA.test_one_lca_supersedes_path
<lifeless>     RemoteException: Traceback (most recent call last):
<lifeless>   File "/home/bzrtest/test_branch/bzrlib/tests/test_merge.py", line 1598, in test_one_lca_supersedes_path
<lifeless>     self.assertEqual, [], list(merge_obj._entries_lca()))
<lifeless>   File "/home/bzrtest/test_branch/bzrlib/tests/__init__.py", line 1055, in expectFailure
<lifeless>     raise KnownFailure(reason)
<lifeless> KnownFailure: We don't do an actual heads() check on lca values, or use the per-attribute graph
<BasicOSX> lp = smart server
<BasicOSX> ?
<vila> lifeless, BasicOSX : Someone else than *me* triggers the lp/pqm bug ? Hurrah ! Not jinxed anymore !
<lifeless> still
<lifeless> BasicOSX: lp: urls reoslve to using bzr+ssh and thus a smart server
<vila> lifeless: I can't do that, I don't have access to ec2, not even sure I can find boto module ?
<BasicOSX> yep, and I'm getting bit but the smart server bug, so I just got vila's patch via http
<lifeless> BasicOSX: oh right, I'm synced() now :)
<lifeless> vila: sign up :)
<lifeless> vila: see the company cloud computing policy in the all hands list archives
<vila> lifeless: I'll look
<vila> By the way, it seems that we have more "warnings.warn("%r was gc'd while locked" % self.repr)" these days nist of them (if not all, involving a LockableFiles(<bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:33810 blah blah), does that ring someone's bell Â¿
<vila> gee how did I type that reverse ?
<BasicOSX> heh
<lifeless> -> home, groupcompress has landed, I'll be landing the remaining bits very soon.
<lifeless> well, ->home shortly
<lifeless> vila: the answer btw to InterCHKRevisionTree is s/development5/development/
<lifeless> vila: found the ec2 doc stuff?
<lifeless> -> home now
<vila> lifeless: I need to find what login/pass I should use to access allhands archive first :-(
<fullermd> Well, if it's allhands, I presume you need a fingerprint rather than a password   8-}
<vila> time to upgrade ff then :)
<lifeless> BasicOSX: around?
<igc> lifeless: thanks for landing that stuff today
 * igc dinner - bbl
<vila> lifeless: still around ?
<vila> I'd still prefer to run locally (for many reasons including ease of debugging). So my question is: do you feel that the problem you encounter is related to the tests protocols rather than any ec2 specific reason ?
<vila> lifeless: by 'locally' I mean connecting via ssh in my LAN to get a close-enough approximation of course
<vila> lifeless: and also because that's a setup I want to be able to use from my laptop to my "data center" :-)
<lifeless> igc: nearly done
<lifeless> vila: yes, I'm around
<lifeless> vila: I would like it if you were familiar enough with bzr-ec2test to debug problems when it is used
<lifeless> vila: thus, I plan to drag you kicking and screaming through it once :)
<vila> lifeless: ha, I thought so but was unsure :-)
<lifeless> vila: concretely it is failing to de-and-re serialise from ec2
<lifeless> which I haven't had time to debug myself test.
<vila> lifeless: so it's not directly related to my last patch (as in, it was failing before ?)
<lifeless> I think so
<lifeless> :)
<vila> devil :)
<lifeless> well
<lifeless> I figure a little latitude is due, for doing the heavy lifting to get you your desired parallel suite :)
<lifeless> vila: I have a separate favour for you to do though, and this is rather more important. I'm about to land --development6-rich-root
<vila> huh ? We still separate rich-root ?
<lifeless> its the only one
<lifeless> no dev6
<lifeless> and aaron has said subtrees need more stuff so leaving out for now
<vila> ha, to underlined that it *is* rich root
<lifeless> yes
<vila> ok
<lifeless> *do-not* want random upgrades and folk having deep troubles
 * awilkins applauds the lack of not-rich-root
<vila> Didn't we say we'll call it --dev6-rich-root-eat-your-dog ?
<awilkins> --dev6-rich-root-cat-taxidermist  ?
<vila> anyway, what favour ? (The more you wait to ask, the bigger is should be, the more I'm frighten :)
<vila> awilkins: don't touch cats
<awilkins> Toxoplasmosis?
<lifeless> vila: merge all the components of brisbane-core from bzr.dev to a single branch and then that into 1.14/get BasicOSX to merge it into 1.14
<lifeless> vila: *note* I *have not* and do *not intend* to merge the brisbane-core branch directly.
<lifeless> vila: it has content we don't want to land in bzr.dev at this point.
<vila> lifeless: right, so cherry pick from bzr.dev ok. Two things,
<Peng_> The sucky thing about not having a non-rich-root format is that the Big Rich Root Transition will have to take place before I can use it locally on most projects. :\
<vila> lifeless: Do you have some reference branch I can use for verification purposes (though one)
<vila> lifeless: two: that means losing the annotations or did your (and Ian's) submissions somehow preserve them ?
<vila> lifeless: if answer to two is yes, don't bother explaining, I can understand why, just want to be clear
<awilkins> What exactly is the reason for things not being bi-directionally compatible with rich-root?
<bob2> why aren't floats bidirectionally compatible with ints?
<awilkins> That isn't "exactly"
<bob2> rich-root has data non-rich-root can't represent
<awilkins> Yes, but what is it?
<vila> awilkins: root data :)
<awilkins> Ginger? Valerian?
<vila> awilkins: that data makes root rich
<bob2> an id for the root directory of a branch
<lifeless> vila: they are gone, we have used --author
<lifeless> awilkins: and versioning of the root
<lifeless> awilkins: which we use in a number of merge corner cases, and for nested trees.
<awilkins> The band-aid needs to be ripped off!  .... of course, it doesn't matter much to me, the majority of branches I use are rich-root so I can keep my manager happy with svn commits
<lifeless> vila: btw its 120 seconds for me to run the test suite with 2 ec2 instances
<vila> lifeless: right so, from bzr.dev log that means revnos 4262 4261 4260 4259 4254 4248 4247 4246 4245? 4244 4243 and the one where you land the --dev6 format ?
<vila> lifeless: 120... hmpf
<vila> lifeless: that doesn't include bzr-loom of course :-)
<lifeless> igc: ping
 * lifeless tapdances on igc's toes
<lifeless> vila: it passed tests in bzr.dev because many tests were not running for it
<lifeless> vila: grab my integration branch if you want to see it blow up ;)
<vila> lifeless: errr, context ? ec2 ? bbc ?
<igc> lifeless: here to help - which branch should I grab?
<lifeless> igc: my integration branch
<lifeless> vila: bbc
<lifeless> igc: if you run bzrlib.tests.workingtree_implementations.test_eol_conversion.TestEolConversion.test_eol_native_with_crlf_i
<lifeless> for selftest
<lifeless> it should fail with a clearly wrong line ending
<lifeless> I see
<lifeless> AssertionError: not equal:
<lifeless> a = 'hello\r\nworld\r\n'
<lifeless> b = 'hello\nworld\r\n'
<lifeless> for instance
<lifeless> give me a clear pointer at whats likely wrong and I'll happily fix. right now I'm fixing real issues with tests that were incorrectly not enabled in bbc that became clear as I did the integration
<lifeless> s/real/other real/
<igc> lifeless: grabing the branch now. The code on lp is up to 4248 and due for mirroring again in 2 hours so I can't just use loggerhead there
<lifeless> igc: sorry yes :)
<lifeless> igc: regardless loggerhead wouldn't help you I don't think
<igc> np - it's down now
<lifeless> so, found an issue with labels
<lifeless> without labels in the pack
<lifeless> two packs with different content can then collide, but the indices are no longer equivalnet
<lifeless> [tests fail]
<igc> lifeless: ./bzr selftest TestEolConversion --no-plugins -1 passes for me
<igc> on 4249
<igc> of your integration branch
<igc> hmm
<lifeless> set LANG=C
<ronny> hmm
<ronny> sadly bzr is the only vcs that has merge instead of pull if the remote diverged
<bob2> 'has'?  you can merge in git in that situation (after fetching)
<igc> ronny: try bzr merge --pull
<ronny> hg and git allow me to pull first, merge later
<bob2> you can bzr pull to your local mirror of that branch (and if it is in a repository with your branches, it is space efficient)
<lifeless> ronny: bzr can do that too, via fetch
<bob2> bzr's mass branch management is a bit lacking alas
<ronny> lifeless: so fetch pulls a dangling head into the backing repo?
<igc> lifeless: setting LANG=C doesn't break things for me
<ronny> hmm
<igc> I'll try a wider set of tests
<ronny> i love how this shit differs - in hg/mtn pull is history sync, in bzr/git it has some merge potential (and bzr is the one that needs explicit merge)
<ronny> lifeless: will the fetched remote data get any special marker other than showing up in the heads?
<lifeless> igc: interesting
<lifeless> ronny: no
<igc> lifeless: so the filtered views tests are failing for me cause you deleted development-wt6 - trying them now with development-wt6-rich-rott
<igc> roo
<igc> root
<lifeless> igc: yes,they are passing for me
<lifeless> I have some uncommitted fixes fixing most of the tests
<igc> it needs to go as well and be replaced with you new format
<igc> lifeless: so filtered view tests pass on development6-rich-root, development-wt6-rich-root needs deletion if you haven't done it already
<lifeless> igc: yes, done
<igc> lifeless: did you try --no-plugins?
<jelmer> hey lifeless, igc
<igc> hi jelmer
<jelmer> vila: ping
<jelmer> vila: You mentioned using factory.stdin.getvalue() in your review
<jelmer> vila: but the rest of the file also uses factory.stdin.readline() and the main point is checking the position of the stream
<igc> lifeless: if you put the output from bzr diff in a pastebin, I'll apply that and run the tests again
<vila> jelmer: I think the comment says: ensures stdin is empty no ? Oops, no, the previous test is with a non-empty stdin, sorry, forget that remark then
<jelmer> vila: ok, just making sure I wasn't missing anything. Thanks again for reviewing, I've fixed the other issues.
<lifeless> igc: sure, one sec
<lifeless> http://paste.ubuntu.com/146177/
<lifeless> sorry, phone call
<lifeless> igc: ^
<lifeless> igc: I'm going to recommit in a minute, as I had to back out some of the cleanup
<lifeless> and try it again
<lifeless> ok ec2testing
<lifeless> igc: if it fails on the NoEol stuff, I'm going to shove it a pqm
<lifeless> I think it might be me ;)
<igc> lifeless: might be. bzr selftest eol filter --no-plugins -1 works fine for me with your patch ..
<igc> and visually inspecting it, it looks fine
<lifeless> igc: yea,  I can't see anything in this breaking it :(
<igc> I got out of bed to help so I'll head back there now
<lifeless> igc: I'm so sorry
<lifeless> igc: where should I look if it still breaks
<igc> lifeless: np. email me if there's still an issue and I'll look into it first thing
<lifeless> I'm staying up till this is landed
<lifeless> I don't need you to fix it, just to point me at the code areas that are potentially implicated
<igc> well bzrlib/filters/eol.py is the starting point
<igc> beyond that, it depends
<igc> sorry - that's not much of an answer
<lifeless> thats ok
<lifeless> I will follow my nose as needed
<lifeless> sleep well, and sorry again
<igc> lifeless: good luck and I'll possibly be up early - hard to tell as the chemo makes me very both very sleepy and very awake depending on god knows what
<igc> so please email any issues
<igc> night all
<lifeless> will do
<lifeless> bombs away
<vila> lifeless: your pending submission in pqm is the last I should backport to 1.14 right ? (It passes tests here)
<lifeless> yes
<jelmer> vila: I'm wondering what to do with smtp as the current implementation asks pre-emptively
<jelmer> vila: ideally we wouldn't always be doing that but only in the cases where the server requires us to
<jelmer> vila: but that seems impractical (impossible?) for smtp
<vila> jelmer: smtp starts by using its own smtp_username and smtp_password config options, I'd say it should use authentication.conf instead
<vila> jelmer: iow, out of scope for your fix IMHO
<jelmer> vila: the problem is get_user() will now return getpass.getuser() rather than None if there's no user configured in authentication.conf
<jelmer> vila: and previously it would skip authentication if None was returned
<lifeless> jelmer: can I ask a favour?
<jelmer> lifeless: you can always ask :-)
<lifeless> jelmer: ... say yes to my next request
<lifeless> jelmer: may I kill your pqm job, its 11PM, want to land development6 and sleep
<jelmer> lifeless: sure, go ahead
<lifeless> tanks
<jelmer> lifeless: please let me know when yours is done so I can requeue mine
<vila> jelmer: I'm pretty sure lifeless will be asleep when pqm lands its patch :) But nothing forbids you to queue now, I think that was the last missing patch
<lifeless> vila: I will be awake till it lands
<vila> lifeless: sorry no offense intended :)
<lifeless> vila: only way to be sure
<lifeless> non taken
<vila> lifeless: good ! So you may have a look at lp:~vila/bzr/bcc-1.14 and tell me if everything looks fine so far
<vila> :)
<vila> lp:~vila/bzr/bbc-1.14 of course
<lifeless> to your list above
<lifeless> 4257
<vila> indeed, just merged it
<jelmer> vila: any idea about smtp?
<vila> lifeless: errr, was about to merge it (not pushed)
<lifeless> :)
<jelmer> vila: I could add a "return_non_if_default" boolean parameter but that just seems plain wrong
<vila> jelmer: consistency is good, I think smtp should align to either http or getpass.getuser()
<jelmer> vila: but the new behaviour makes unauthenticated smtp impossible
<jelmer> as get_user() will never return None
<jelmer> lifeless: I just got a "success" message from PQM and my branch was merged
<lifeless> jelmer: odd...
<vila> jelmer: unauthenticated http is possible, do the same :-)
<jelmer> vila: yes, but in the case of http we only ask after the remote host gives a "Permission denied"
<vila> jelmer: sure, I was trying to get some time to think :)
<awilkins> jelmer: That reminds me about svn+ prefixes
<jelmer> vila: :-)
<jelmer> awilkins: what about them?
<awilkins> jelmer: I seem to think that if your web server refuses access to the locations that bzr probes to determine whether a web server is a repo, things just stop
<awilkins> I should make a more coherent report
<vila> jelmer: so smtp._authenticate() says: """If necessary authenticate yourself to the server.""", so there should be a way to find if auth is necessary
<vila> In the worst case it means: try to send, catch auth error, authenticate, send
<vila> there is smtplib.SMTPAuthenticationError ....
<vila> ... whose doc string says " Most probably the server didn't accept the username/password"... I love the most probably part :-/
<jelmer> vila: yeah, SMTP sucks
<vila> jelmer: probably smtp servers requiring auth suck less :-)
<jelmer> vila: The annoying thing here is that we probably won't know whether we need authentication until we've tried sent a full email
<jelmer> s/sent/to send/
<vila> jelmer: indeed, that's the way http achieve auth, try without and if it fails try with auth
<vila> lifeless: ha, 4259, the fun stuff :-(
<jelmer> vila: what about an optional default= argument to get_user() that defaults to getpass.getuser() ?
<jelmer> vila: smtp could set that to None
<jelmer> and keep behaving the way it does atm
<vila> jelmer: if you add a FIXME in smtplib about converging and/or addressing the problem, that sounds perfect for your submission
<jelmer> that would keep smtp in the current state but at least support prompting for http
<jelmer> vila: cool, thanks
<lifeless> yes :)
<lifeless> vila: see the pyrex issues?
<lifeless> also: http://pqm.bazaar-vcs.org/ - the eagle is landing
<lifeless> jam: ^ :)
<vila> lifeless: not yet (but I suspected that when you mentioned the problem), I'm in Resolve confclits in NEWS
<jam> lifeless:  /cheer /train
<jam> Though your post about duplicate content was a bit concerning
<jam> I have some thoughts about exploiting duplicate content within a group, but having this across .pack files ...
<lifeless> jam: yes; it is rather pathological, but worth resolving in some way for production version
<jam> lifeless: so... we could go with some sort of labels as an easy fix, or push more for getting text content into a chk structure
<jam> I'm concerned about the CHK index exploding even further...
<lifeless> jam: indeed
<vila> landed in bzr.dev
<lifeless> vila: cool
<lifeless> jelmer: go for it
<jelmer> lifeless: thanks, it's already in though :-)
<lifeless> vila: so are you good to get a passing testsuite version for 1.14?
<vila> I run selftest at each commit, I'm at bzr.dev@4261 so 3 more commits to go
<lifeless> cool, I'll hang about a bit then
<vila> err 2 even
<lifeless> as I know you have fast tests :)
<vila> indeed, could not have afford to do that otherwise
<vila> lifeless: yeah for the big fat NEWS entry  about bbc :)
<vila> lifeless: ready to merge in 1.14 pushed at lp:~vila/bzr/bbc-1.14 care to have a look, jam too ?
<vila> still running the tests, will do a 'make check' after that
<lifeless> vila: I'm shattered; the mainline is done, I'm happy to hand off
<vila> lifeless: ok
<vila> lifeless: good job, sleep well, no test failure to report so far :-)
<lifeless> vila: cool, thanks.
<jam> vila: so is that cherry-picking brisbane-core into 1.14?
<jam> lifeless: is this the bug you were looking at with spiv:
<jam> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has
<jam>  no attribute 'get_bytes_as'")
<lifeless> jam: yes
<jam> k
<lifeless> jam: I mailed the list the bug number
<jam> because I just failed to branch vila's code
<lifeless> the fix is to upload more content
<jam> bug 354036
<lifeless> yes
<vila> jam: yes, it should be: bzr-1.14 + (bzr.dev@4265 - everything not related to bbc)
<lifeless> vila: apply the fix from bug 354036 to the bzr you use to push, remove the branch and push again
<jam> well, for now I can just branch from "http://bazaar..."
<lifeless> indeed
<lifeless> well, I'm halting() or I'll be more than tired tomorrow
<vila> lifeless: I use bzr.dev@4263 to push so the fix should already be included
<ubottu> Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text)
<lifeless> vila: we haven'tlanded the fix for that bug
<ubottu> Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text)
<vila> grrr
<Peng_> lifeless: There's an error in the docs for development-rich-root: It says it's interchangeable with pack-0.92, not rich-root-pack.
<vila> ubottu you didn't help here ! That's the second time I cross the bugs and that you can't display them >-/
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<vila> ubottu: that wasn't exactly what I was thinking :-)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> Peng_: thanks. vila/jam if you could fix that oversight that would be grand
 * lifeless goes
<vila> uuuurgh, can't pull ~spiv/bzr/stacking-inventory
<vila> ok, pulled with bzr-1.13
<vila> and pushed with ~spiv/bzr/stacking-inventory  at lp:~bzr/bzr/bbc-1.14
<vila> jam: can you pull that one ?
<jam> vila: I already fetched it with http://
<jam> but I'll try again on another machine
<vila> jam: rats, I missed that one
<jam> vila: bzr.dev@4265 still fails to branch lp:~bzr/bzr/bbc-1.14
<jam> maybe you need some actual data transferred so it doesn't no-op the push?
<jam> vila: you could try 'commit --unchanged' and uncommit it later if it works
<jam> (commit --unchanged, bzr push, bzr uncommit lp:...)
<vila> jam: it's a new branch ! The former one was lp:~vila/bzr/bbc-1.14
<jam> ah
<jam> well, it failed
<jam> so it seems the stacking fix isn't sufficient/complete yet
<Peng_> So, um, anyone want to fix the doc issue I just mentioned, or should I send a trivial patch or something?
<vila> Peng_: send a trivial patch so that it doesn't get lost
<Peng_> vila: Okie dokie.
<Peng_> Okey dokey? Whatever. Anyway.
<Peng_> Wait, what should it be against? bzr.dev? bbc-1.14?
<vila> bbc-1.14 will be merged in bzr.dev at some point so at least against it
<Peng_> Whee, AbsentContentFactory traceback!
<beuno> Peng_, downgrade to 1.13.1  :)
<beuno> I had to do that yesterday
<Peng_> \o/
<Peng_> I don't have 1.13.1 anywhere.
<beuno> it's stacked branches and bzr.dev not getting along AFAIK
 * Peng_ kicks the "Target directory already exists" error.
<vila> Peng_: bzr branch http://bazaar-vcs.org/bzr/bzr.1.13/
<Peng_> vila: Well yeah.
<Peng_> Tags would make it easier to figure out which revision is right, though.
<Odd_Bloke> So I just ran "bzr push svn+ssh://odd_bloke-guest@svn.debian.org/svn/python-modules/packages/python-whoosh/trunk" and got "bzr: ERROR: Prefix missing for branches/python-whoosh; please create it before pushing.".  How can I tell bzr-svn to actually push to where I'm telling it?  Would it make a difference if .../trunk already existed?
<Odd_Bloke> jelmer: ^ :)
<awilkins> Odd_Bloke: python-whoosh needs to exist
<awilkins> Odd_Bloke: Don't create trunk
<Odd_Bloke> python-whoosh does exist.
<Odd_Bloke> It's talking about an as-far-as-I-can-tell-unrelated '_branches_/python-whoosh'.
<awilkins> Ah, maybe it's branches that needs to exist (or you need to make it think something else about branching scheme)
<Peng_> Are format help strings hardcoded in the tests anywhere?
<Peng_> In other words, is bzrdir.py the only place you have to make changes to them?
<Odd_Bloke> awilkins: Using 'bzr svn-layout'?
<awilkins> Odd_Bloke: I'm not entirely sure
<awilkins> Odd_Bloke: I've just resorted to conforming to expectations :-)
<vila> Peng_: running the tests should tell you :)
<Peng_> vila: But you can tell me more quickly! ;-D
<Peng_> Wait, so bbc is going to go in 1.14?
<vila> Peng_: I don't know that one by hearth, so I'll have to run the tests :)
<vila> Peng_: that was always the plan :)
<jelmer> Odd_Bloke: hi
<jelmer> Odd_Bloke: you need to use svn-push if you're running an older version of bzr
<vila> BasicOSX: ping
<Peng_> Well, it looks like the tests weren't updated last time they changed, so I'll go with that.
<Peng_> So should I send the patch to the mailing list? [1.14]?
<vila> Peng_: yup
<Peng_> This process needs more magic. All I'd have to do is think "vila, fix this bug" and bang, it would be in bzr.dev 30 seconds later. :(
<vila> Peng_: when in doubt, use more magic
<Peng_> Shoot, I branched from bbc-1.14, meaning a diff against bzr.dev includes lots of other stuff. :(
<Odd_Bloke> jelmer: Ah, cool, didn't realise how long it had been since I'd updated my bzr.dev/bzr-svn on this machine.
<Odd_Bloke> jelmer: Thanks. :)
<vila> Peng_: why are you diffing against bzr.dev ? Is your branch parent correct ? And the submit one ?
<Peng_> vila: Well, when sending a bundle to the list, it's most convenient to have the parent be in bzr.dev. Which the tip of bbc-1.14 isn't. Or something.
<Peng_> I don't want to expend more effort thinking about this! :(
<Peng_> vila: So, you want the patch against bbc-1.14?
<vila> Peng_: it's indeed the most convenient when sending bumdles against bzr.dev :-) But here you want submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14/
<vila> Peng_: whatever is easier for you, as I said, we don't want it to be lost, that doesn't mean you have to suffer :)
<Peng_> So it looks like you and lifeless made the same changes (or at least the same commit messages) in different revisions, one for bbc-1.14 and one for bzr.dev.
<Peng_> Hence my problems.
<vila> Peng_: I indeed copy/pasted a lot to cherry-pick
<Peng_> If only we were using darcs. :(
<Peng_> On a different subject, ice cream! See you later. :)
<Tak> ice cream is always on topic
<Peng_> What about cake?
<Tak> I suppose that's a matter for debate
<vila> ice cream on top of cake ?
<vila> passed under a chocolate fountain ?
<Peng_> And deep-fried!
<vila> ubottu don't like chocolate :)
<Peng_> With M&Ms and powdered sugar on top.
<Peng_> Heh.
<vila> chocolate
<vila> BasicOSX: ping
<vila> BasicOSX: I have a fix for bug #355454
<vila> come on ubottu, you should have that one in your cache, it's a hot one
<ubottu> Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix committed] https://launchpad.net/bugs/355454
<Peng_> 1.14 is getting a *lot* of patches.
<vila> Peng_: 1.14rc1 is not out yet, at least because of the above bug :)
<tony> hello?
<vila> jam: ping
<tony> hi
<jam> vila: pong
<tony> heh
<vila> jam: regarding fix for #355454, I think abspath is needed because we'll call stat, so my last remark is invalid
<jam> I think I've tracked down the ambiguity, so we just need to decide on a fix
<jam> specifically
<jam> walkdirs()[4] ==> a path that you can pass to stat or open() to get the object
<jam> which may be Unicode or may be an fs path
<vila> yet, we may want to have both rel and abs available to avoid re-calculating rel from abs, I'm pretty sure we use the path that can be either utf8-encoded or unicode depending of what dir reader we use
<vila> jam: exactly
<jam> We use this so that internal to dirstate, we don't have do .decode('utf8') every file
<jam> sorry
<jam> every ptah
<jam> path
<jam> on UTF-8 filesystems, etc.
<vila> yes, same page
<jam> So it sounds like you're finding that the _content_filter stuff *requires* a Unicode string?
<vila> so, do you agree that path is either unicode or utf8 encoded ?
<vila> tree.relpath does
<vila> AFAIK
<jam> vila: I think for current implementations, we do
<jam> I don't think the api requires that
<jam> so I think the problem is how stat_and_sha1 is intermingling with the walkdirs stuff
<jam> I think we already have a reasonable relpath available
<jam> we just *also* need abspath to actually open the file from disk
<vila> so pass both ?
<jam> something like that
<vila> with relpath=None as default ?
<jam> Let me look at the code a bit
<vila> jam: far more tests than actual code (and too much for me to fix it *today*, no problem if it can wait tomorrow)
<jam> if we look at _walkdirs_utf8 we have a bunch of things that are "utf8_relpath" etc.
<jam> vila: I just don't want "fixing" it on Mac to break it on Win32
<vila> jam: I didn't fix it on mac, I fixed it on interpid
<vila> and I think BasicOSX is also on Linux
<jam> vila: how was it breaking there? (and why wouldn't it have been breaking on PQM)
<vila> jam: ha ha pqm, still the same LANG=C joke ?
<vila> it broke here with python -Werror
<jam> well, supposedly lifeless fixed PQM's LANG issue
<vila> lifeless filed a RT request, I don't know if it has been fixed yet
<jam> he mentioned the likelyhood that things may start breaking accidentally
<jam> so I thought it had happened
<vila> python -Werror ./bzr selftest -s bzrlib.tests.tree_implementations.test_test_trees.TestTreeShapes.test_tree_with_merged_utf8
<jam> so certainly WT.relpath() is comparing the path with self.basedir
<vila> jam: can you try that ?
<jam> which should be a unicode string
<jam> vila: well, on Windows the tests pass
<jam> because they use Unicode strings for that argument :)
<vila> see ? That's the right fix ! :-)
<vila> lol
<jam> win32 walks in Unicode, because we get it directly from the FooW apis
<vila> jam: doh ! It passes on OSX too !
<jam> vila: interesting, I get d to convert both arguments to Unicode - interpreting them as being unequal
<vila> ha wait, no extension built here
<jam> vila: right, it will pass without extensions, because the global fallback path is to walk using Unicode
<vila> did you use 'python -Werror' ?
<vila> jam: sure
<jam> vila: well with -Werror it fails, without it just warns
<jam> anyway
<jam> I would actually say the 'correct' fix is to do:
<jam> if type(x) is not unicode:
<jam>   x.decode(_fs_enc)
<jam> however, at the moment
<jam> the code paths
<vila> jam: That's the bug ! That's why make check-dist-tarball fails
<jam> state that the only time x isn't unicode
<vila> because it uses python -Werror
<jam> is when fs_enc == utf-8
<jam> so.... we have a utf-8 relpath already
<jam> it is part of the walkdirs api, and we could pass it into the stat function
<jam> but for ease...
<jam> vila: BB:tweak ... for now your fix is fine, as long as we update the documentation on SHA1Provider.stat_and_sha1() to declare that abspath
<jam> may be a filesystem encoded absolute path
<jam> since it is coming from walkdirs_utf8
<vila> right, I'll then enhance the patch to provide relpath too and more importantly add some tests parametrization as discussed in brisbane
<jam> vila: the one thing to be aware of... relpath *might* be from a subdir of a directory, I'm not 100% sure where the 'walkdirs' is starting from.
<vila> jam: hmm
<jam> I'm thinking it can be trusted
<jam> I just need to poke around the code and make sure
<jam> vila: it should be fine
<jam> of course...
<vila> jam: ok, I'll add tests for it :)
<jam> this means that we'll have to decode every path again, but perhaps only if they miss the sha hash
<jam> which would be ok
<jam> sorry, the stat fingerprint hash cache
<vila> jam: what worries me more is that g_content_filter_stack queries for filters which may in turn result in IO...
<jam> vila: what IO, you mean having to read config files to figure out if there is a filter for the given file?
<vila> jam: things like that, I didn't dig that far to be 100% sure, just a bad feeling
<vila> since the SHA1Provider already cache the tree, I thought some more may need to be cached, but may be it's already the case and I should not worry
<vila> jam: last thing before I quit, did you had a look or have comments about bbc-1.14 ? Can you make sure BasicOSX is aware of it ?
<vila> s/did you had/did you have/ geee, why do I keep making that one...
<vila> ...is it correct ENglish or *not* ?
<jam> "did you have a look"
<jam> though "did you look at" is easier
<abentley> vila: Isn't it very similar to a French construction where the past tense is used?  "As-tu eu.."?
<vila> abentley: that's where my error is coming most probably: As-tu jetÃ© un coup d'oeil sur
<vila> my fingers and my brains walking at different speeds in parallel in French and English just mess things up :)
<vila> brain, mutli-core but still mon-brain :)
<vila> mono argh, time to stop :)
<vila> cooking time
<alaa_> hey guys. So am getting a stack trace every time i run "bzr st". It is bzr 1.13. The error is TypeError: run() got an unexpected keyword argument "verbose"
<alaa_> I'll file a bug a bit later, but is there anything i can do now?
<james_w> alaa_: you need to upgrade your copy of the bzr-loom plugin
<alaa_> james_w: ah yes. I was just looking at the trace, and i saw the loom reference. I'll try that and report back
<alaa_> james_w: That worked. So this is a known problem then, right?
<Peng_> alaa_: Yes. Hence it being fixed in newer versions of bzr-loom. :P
<james_w> alaa_: yeah, I would guess that it is the most frequently reported bug in the history of bzr :-)
<alaa_> Right. It's amazing how it got through since it is in the most used command in bzr :)
<alaa_> james_w: thank you for your help
<james_w> np
<catojo> hello guys
<Peng_> Hi
<catojo> Hi Peng_
<catojo> Can, do you know how much sites that supports the bazaar ?
<Peng_> What?
<catojo> So, I'm from brazil, thus, I do not speak english correctly.
<catojo> But i want to know how many sites supports bazaar
<catojo> I know launchpad only.
<Peng_> catojo: Oh. SourceForge added support recently.
<catojo> Cool.
<catojo> I will see.
<catojo> Thanks.
<catojo> Peng_
<catojo> A have a free software stored at sourceforge.
<catojo> But I'm use SVN.
<catojo> I will try to migrate to bazaar.
<Toksyuryel> bzr rocks
<Toksyuryel> :)
<beuno> It sure does!
<beuno> $
<Peng_> catojo: You can use bzr-svn to convert. http://bazaar-vcs.org/BzrForeignBranches/Subversion
<catojo> hmm
<catojo> I will see.
<catojo> Some people will go to FISL 10 ?
<catojo> http://fisl.softwarelivre.org/10/www/
<Peng_> beuno: So, which version of my Loggerhead YUI CDN thing do you like best?
<Peng_> :D
<catojo> Peng_ Yahoo library ?
<catojo> javascript ?
<catojo> YUI
<Peng_> catojo: Yes.
<catojo> Peng_ Javascript smells good.
<beuno> Peng_, I have options?
<beuno> did I not approve that branch?
<Peng_> beuno: I made 3 different versions of my little patch.
<Peng_> beuno: Sure, you did, and then I changed it again. :D
<beuno> ah!  hehe
<beuno> ok
<beuno> so
<beuno> URL?
<beuno> and
<beuno> what's your preferencec?
<Peng_> beuno: http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/changes
<Peng_> beuno: I think revision 322 is the prettiest, but revision 324/325 uses a single, combined JS file instead of half a dozen individual ones, so it should be faster.
<beuno> Peng_, agreed
<beuno> one comment
<beuno> how about not using "yui" as a variable name?
<beuno> ie, use cdn generically
<beuno> other than that, I'd love for that to be merged in
<beuno> don't forget to update NEWS
<Peng_> beuno: Wait, so do you prefer 324/325 or 322?
<beuno> Peng_, I think 322, even though the URL is hardcoded
<beuno> and I know I complained about that
<beuno> I'm actually ok either way I think
<beuno> both are good, and both itch
<Peng_> beuno: 324/325 just hardcodes it in the template, and in a more obfuscated way.
<beuno> yeah, that's what itches me about that
<Peng_> :D
<beuno> so making the var names more generic, and landing 322 I think is a good compromise
<Peng_> Which var names?
<beuno> use_yui_cdn
<beuno> and def yui_url
<beuno> I'd use:  use_cdn, and cdn_url
<beuno> we're using YUI, but we're not married yet  ;)
<beuno> maybe even the --yui-cdn
<beuno> to --use-cdn
<Peng_> Hmm, I see your point.
<beuno> so if we change js libraries, people don't have to update their start scripts   :)
<Peng_> I kind of like the name "yui_url" for the function, though, since it *is* specific to YUI.
<beuno> true
<Peng_> Well, it's just as specific as the rest of the code. Still, I'd prefer to make the other changes, but stick with "yui_url".
<beuno> I'm fine with that
<Peng_> I guess it would have to be changed if the JS library is ever changed, but Loggerhead doesn't guarantee internal API stability anyway, does it?
<beuno> not for now, no
<beuno> I'm more concerned about changing things to the users
<Peng_> Right. Users shouldn't care about the name of that method.
<Peng_> (Which means *somebody* will, of course. :P )
<beuno> heh, exactly
<Peng_> Why are lines in NEWS only about 70 characters wide instead of 79?
<beuno> no idea
<beuno> crazyness
<beuno> like a lot of the rest of the code  :)
<Peng_> Heh.
<Peng_> beuno: On a different subject, mind if I make LoggerheadConfig a new-style class? Can I do it directly in the trunk without getting reviewed? :D
<beuno> Peng_, Go for it.
<Peng_> Thanks.
<beuno> this is why you got access to trunk!  lower barrier to JFDI stuff
<Peng_> beuno: Yeah, but I'm still afraid to do it. How much am I allowed to JFD? Trivial things like that? Simple bug fixes?
<beuno> Peng_, in general, it's small bits that don't change anything drastically
<beuno> very small bug fixes, doc changes, etc
<beuno> reviews are a fantastic safety net, and as we get more tests, we may even get a PQM
<Peng_> Oh, neat.
<beuno> so we can ensure tests pass as well
<Peng_> Well, I just did it. Pushing to LP is slow!
<Peng_> (The LoggerheadConfig thing, I mean.)
<beuno> is it?
<beuno> it seems amazingly fast for me with 1.13
<beuno> I use a checkout to commit to trunk
<beuno> merge in changes from the branch, and commit
<Peng_> It was like 19 seconds vs. 4. Actually, I'm not sure why. They should both be new enough. Maybe it's just because LP is farther away from me.
<beuno> maybe it autopacked?
<abentley> jam: ping
<beuno> Peng_, I've added 'debug_flags = hpss' to my bazaar.conf
<Peng_> beuno: It didn't autopack. bazaar.lp seems just plain slow ATM.
<beuno> so you can always look at the logs when these things happen
<beuno> Peng_, could be. mwhudson was working on something with ssh auth
<Peng_> beuno: Seems slow over HTTP too.
<LarstiQ> Peng_: mail wrapping is usually 72 or 70 characters.
<Peng_> LarstiQ: Ah, good point.
<Peng_> beuno: Yeah, but it'll make .bzr.log *really* spammy.
<beuno> Peng_, yes, also called useful  :)
<Peng_> beuno: So, the diff for yui-cdn currently looks like this: http://paste.pocoo.org/show/111505/ bb:approve?
<Peng_> beuno: But it won't be useful very often.
<beuno> and it tells you how many hpss calls where made
<Peng_> Hmm, I *do* like weird statistics.
<LarstiQ> :)
<beuno> Peng_, where is yui_url called from now?
<Peng_> beuno: macros.pt.
<beuno> aha
<beuno> Peng_, bb:approve
<beuno> or lp:approve (?)
<abentley> beuno: " review approve"
<Peng_> abentley: That's longer. :P And "Bundly Buggy" sounds cool.
<Peng_> Makes me want to chew bubble gum.
<Peng_> beuno: Can I land it?
<abentley> Peng_: Thanks.  I like the name, though it makes less sense now that it's primarily tracking merge directives.
<Peng_> abentley: True, but cool > sensible.
<Peng_> beuno: wb?
<beuno_> yeah, my ISP is sucking big time
<Peng_> < Peng_> beuno: Can I land it?
<beuno> Peng_, yes!
<beuno> 15:52 < beuno> Peng_, bb:approve
<beuno> 15:52 < beuno> or lp:approve (?)
<beuno> but of course, that got eaten by the internets blackhole
<Peng_> beuno: It came through, but I wasn't sure if we should wait on mwhudson or something. (Sorry for the highlight, mwhudson.)
<beuno> Peng_, I think our policy is just 1 review
<Peng_> Okay.
<bpierre> hi
<Peng_> beuno: Pushed to my server in 6.57 seconds and LP in 33.05.
<Peng_> Isn't there some weird performance issue with certain versions of certain things?
<beuno> Peng_, you've downgraded to 1.13, right?
<Peng_> beuno: Nope.
<Peng_> beuno: I used http to work around the AbsentContentFactory issue the one time I hit it.
<beuno> ah
<beuno> well, ~1.14 works amazingly well with 1.13
<beuno> so maybe it's the ssh problem
<beuno> rockstar, abentley, any ideas  ^?
<bpierre> I'm trying to use the new code in bzr.dev for EOL handling, and so far nothing work: I've created a 1.14 format branch, added some files, then put '[name *]' 'eol = crlf' in ~/.bazaar/rules, so if I branch the initial branch I should get windows like EOL, right?
<rockstar> beuno, mwhudson was saying something about a regression between 1.13 and older versions of bzr on the client.  That's all I know though.
<abentley> beuno: Sorry, no.  Others are investigating slow username lookups, which may be related.
<rockstar> abentley, ah, I forgot about that.
<Peng_> abentley: Slow username looks? What does that impact? Regular old push to bzr+ssh://bazaar.lp.net?
<Peng_> s/looks/lookups/
<abentley> Peng: any sftp or ssh access to bazaar.lp.net
<Peng_> abentley: Ah. That could do it, then, I guess.
<Peng_> Thanks for the hand-holding. :)
<fbond> Can I pull without updating the working tree?
<james_w> not from the UI I don't think
<rockstar> abentley, hey
<abentley> rockstar: hey
<rockstar> abentley, get_rev_id seems to be confused.
<abentley> rockstar: how so?
<rockstar> So I pass in the revno, and it throws a NoSuchRevision exception, even though I navigated from the history listing of the branch by clicking that revno.
<rockstar> abentley, I'm sure it's because I'm confused, but the documentation looks pretty plain that I just pass in a revno.
<abentley> rockstar: Is it an integer revno, or does it have dots?
<bpierre> did you pass a string or a integer? I recently got a problem with buildbot because of that (after upgrading bzr)
<rockstar> abentley, in this case, it's an integer revno.
<rockstar> abentley, I can take it all the way back to revno 1, and it says it doesn't exist.
<abentley> rockstar: It works for me.
<rockstar> abentley, :(
<abentley> rockstar: https://pastebin.canonical.com/16055/
<rockstar> abentley, I think I figured it out.  The revno was actually '322'
<jelmer> 'evening abentley, rockstar
<abentley> jelmer: Hi.
<rockstar> Hi jelmer
<jelmer> abentley: Do you know what the expected behaviour of revno's is when there are ghosts in the lhs history?
<rockstar> abentley, so it doesn't handle strings that can be converted to integers.
<rockstar> abentley, does this mean I can't get the dotted revnos then?
<bpierre> exactly my problem!
<abentley> rockstar: No, it doesn't.
<abentley> rockstar: That's UI-level functionality.
<abentley> rockstar: Branch doesn't fold, spindle or mutilate its input.
<jelmer> abentley: simply count the first known revid as revno 1?
<rockstar> abentley, that's a good contract, I just needed to figure it out.
<abentley> jelmer: No, it should work backwards from the current revid/revno
<rockstar> abentley, so if I get a dotted revno, how would I get that revid?
<abentley> jelmer: Due to ghosts, the revids for some revnos may not be known.
<jelmer> abentley: ah, that makes sense
<abentley> rockstar: Branch.get_revision_id_to_revno_map
<abentley> rockstar: That operation is much more expensive, and makes sense to cache.
<jelmer> abentley: so in the case that we don't have a reference revno when the revno is unknown, what is the expected behaviour? revno=-1, revno=None or is that simply not possible yet?
<abentley> jelmer: I don't think that case is possible.  If we had to handle that case, I'd probably assign the ghost to revno 1.
<jelmer> abentley: ok, that makes sense. thanks
<Necoro> wow ... I just noticed that loggerhead now has syntax highlighting :)
<Necoro> thanks to the author :)
<lifeless> Necoro: :)
<lifeless> mwhudson: was that you?
<mwhudson> lifeless: it was originally a patch from peter bui iirc
<mwhudson> Peng_ and i improved it a big
<mwhudson> *bit
<thumper> a big bit?
<Bluehorn> Hrm, when branching, what does this error message tell me: KnitPackRepository('file://...') is not compatible  with
<Bluehorn> KnitPackRepository(...) different rich root support
<Bluehorn> I am branching bzr-builddeb from launchpad into a directory created using bzr init-repo.
<Bluehorn> What worries me is that the message basically tells me, $foo is incompatible with $foo (same values for $foo ;-))
<cody-somerville> Upgrade your repo
<Peng_> Bluehorn: They're both KnitPackRepositories, but one has the "rich root" flag on and one doesn't. Yes, the message is rather unhelpful.
<Peng_> Bluehorn: Do you have any other branches in your repo?
<Peng_> Bluehorn: What format did you create it in? The default (pack-0.92)?
<Bluehorn> Peng_: yep, default
<Bluehorn> Peng_: just bzr init-repo bzr-builddeb
<Bluehorn> Peng_: Just created a new repo, bzr init-repo --rich-root bzr-builddeb
<jelmer> hmm
<jelmer> 1.15 is going to be awesome
<Bluehorn> Peng_: But I have to admit that the different formats (suggested by bzr help upgrade) are a djungle.
<lifeless> Bluehorn: we are working to remove them all
<Bluehorn> Peng_: I'll go and read bzr help formats
<Bluehorn> lifeless: but you will need backwards compatibility, no?
<lifeless> Bluehorn: yes, but that doesn't mean showing you everything under the sun
<Bluehorn> lifeless: :)
<beuno> lifeless, I see brisbane-core has landed?
<Bluehorn> nice. bzr branch tells me that my repository is deprecated and I should run bzr upgrade. bzr upgrade tells me: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
<Bluehorn> so what is the latest and greatest format for rich root repositories?
<james_w> --1.6-rich-root would be recent
<james_w> --1.9-rich-root  is the shiniest
<james_w> --development6-rich-root will eat your pets but will be very shiny indeed soon
<lifeless> Bluehorn: --default-rich-root is what you should use if you need rich roots;
<beuno> how's the performance between 1.6 and development6-rich-root?
<lifeless> Bluehorn: note that rich roots are a *one-way* upgrade,so only use them if you know you need to, and don't branch other projects into the same repo
<lifeless> Bluehorn: once we make rich roots the default this advice will go away :)
<Bluehorn> james_w: just upgraded to 1.9-rr. thanks!
<Peng_> Of course, one of the major reasons rich roots aren't the default yet is *because* they're a one-way upgrade. Yay chickens and eggs.
<lifeless> mmmm omelete
<Peng_> Or some other metaphor or whatever.
<lifeless> jelmer: ah I remember why I pung
<lifeless> I wanted to ask if its cool and accurate to say 'samba4 uses subunit'
<jelmer> lifeless: yeah
<jelmer> lifeless: so far it's mainly the subunit *protocol* though, not yet the subunit project
<lifeless> jelmer: same thing IMO :)
<jelmer> lifeless: I actually hope we can ship with a subunit parser that can do formatting for the buildfarm
<lifeless> would be good
<lifeless> you know I'm very happy to add a perl/ module to upstream
<jelmer> lifeless: and allow developers to use the subunit projects' fancy tools if they have them on their system elsewhere
<jelmer> lifeless: I might contribute back our perl parser at some point, but I need to make it a bit less hackish first
<lifeless> jelmer: why? [less hackish] - I'm not qualified to critique perl code beyond simple readability
<Peng_> jelmer: Is it a good idea for bzr.dev users to switch to bzr-svn 0.6 now? Will it be really unstable for a while or anything?
<jelmer> lifeless: in particular the API should be hashed out, don't want to break it on people
<jelmer> Peng_: yeah, that should be fine. the main thing atm is that you won't have dpush yet
<lifeless> jelmer: you could put it up with a note saying clearly 'unstable api'
<lifeless> better an unstable api than none
<jelmer> lifeless: or I could just fix it and then contribute it rather than contributing it now, then fixing it, then sending updates :-)
<lifeless> jelmer: up to you
<lifeless> jelmer: just encouraging release early release often, where it seems possible without great risk
<lifeless> jelmer: from my perspective you'd basically own a perl/ subdir; commit directly to it if you want
<james_w> statik: ooh, thanks :-)
<lifeless> james_w: ?
<james_w> in response to a mail
<lifeless> I'm naturally nosey
<lifeless> Odd_Bloke: how does whoosh compare to bzr-search in terms of performance?
<Odd_Bloke> lifeless: I've never used bzr-search, so I don't really know.
<Odd_Bloke> For that matter, I haven't used Whoosh in any performance-critical manner.
<lifeless> ok
<vila> pqm announces: bbc landed in 1.14 :-)
<lifeless> thanks vila
<vila> lifeless: thanks BasicOSX (who manages to *avoid* that annoucement :-)
<lifeless> did you incorporate peng's doc fix for it?
<vila> I don't think so,
<Peng_> \o/
<vila> but I also think that the doc fix was making unclear that non rich root format can be imported
<BasicOSX> when will the 1.13.2 stuff be ready :-)
<vila> but the fix is available for all (especially those mastering English :) to comment
 * vila goes to sleep now
<lifeless> BasicOSX: jam and vila had issues with it yesterday, spiv and I will tackle it more today
<Peng_> vila: Hmm, you have a point.
<BasicOSX> woah... poolie ! :-)
<poolie> hello!
<BasicOSX> Anymore stuff to squeeze into 1.14rc1?
<lifeless> BasicOSX: no, I think the 1.13.2 fix can go into whatever 1.14 we're up to when its ready - don't block on it
<poolie> i literally just logged in to a computer for the first time in 12 days
<poolie> so i presume you're not asking me :)
<Peng_> poolie: Well, if you can think of anything... :D
<BasicOSX> poolie:  not asking you ;-)
<BasicOSX> Peng:  >8-(
<poolie> oh typing feels weird :)
<poolie> hello lifeless, peng
<Peng_> Hi! :)
<Peng_> BasicOSX: But if there weren't dozens of things being squeezed in at the last minute, wouldn't you feel underutilized? :)
<lifeless> welcome back poolie
<BasicOSX> Peng:  ironically, that would be the truth :-)
 * BasicOSX cheers
<BasicOSX> All test pass now
<james_w> hey poolie
<poolie> hello james_w
<BasicOSX> should I just close the bugs listed as closed in the NEWS but are still listed as open by tools/check-newsbugs.py ?
<poolie> BasicOSX: probably not just close them, but check whether they ought to be closed
<poolie> it's possible some were eg reopened later, or not totally fixed
<poolie> are there many of them?
<BasicOSX> ok, I opened bug on it,  bug 354984
<ubottu> Launchpad bug 354984 in bzr "./tools/check-newsbugs.py NEWS found issues" [Undecided,New] https://launchpad.net/bugs/354984
<thumper> abentley: are you still waiting on a review for your big nested tree branch?
#bzr 2009-04-08
<BasicOSX> hmm, test suite core dumping
<lifeless> :(
<BasicOSX> trying pristine pbuilder to make sure my environment isn't the problem
<thumper> hi guys
<thumper> if I have a branch that is stacked on another
<thumper> how can I confirm (in a unit test) that the branch that is stacked doesn't have all the revisions?
<thumper> a simple count of revisions in the branch's repository would suffice for the test case I guess
<lifeless> stacked_branch.bzrdir.open_repository().all_revision_ids()
<thumper> lifeless: ta
<lifeless> stacked_branch.repository.all_revision_ids()
<lifeless> set and difference kgo
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> so jam and vila seem to not be fixed by the bug fix
<lifeless> see last night around 11
<spiv> Hmm.
<abentley> thumper: yes.
 * spiv tries to reproduce
<spiv> lifeless: I can't reproduce; if I push that same bbc-1.14 branch with bzr.dev I get the error on pull, and if I push it with the fix branch I don't get the error.
<lifeless> spiv: then I blame 'they didn't use the new branch'
<spiv> lifeless: that's my guess.
<spiv> It's possible that at the time vila pushed up the bzr.dev in LP was a bit different so as to tickle subtly different case, but that strikes me as unlikely.
<lifeless> agreed
<lifeless> vila: ping
<lifeless> jam: ping
<lifeless> ^^^^
<skip_m> hello - is this the place for bzr help?
<lifeless> its a place ;)
<skip_m> anyone will do - thanks ;-)
<skip_m> I'm a *complete* bzr naif.  Here's my problem. (Sorry if my terminology is wrong.)
<skip_m> I branched mailman 2.1 awhile ago and made changes to one file, .../cron/gate_news.
<skip_m> I then pushed that to launchpad.  Now I want to make a mailman 2.2 branch and
<skip_m> transfer all my changes to that branch.  How do I do that?  I have my mailman 2.1
<skip_m> branch and a pristine mailman 2.2 branch.  My first change was at rev 1135.  My
<skip_m> last was at rev 1139.  Do I just get a diff and apply it with patch or is there a more
<skip_m> bzr-ish way to do that?
<lifeless> cd mailman2.2; bzr merge $path_to_mailman2.1
<james_w> you could first try "bzr merge <your 2.1 branch with changes>"
<james_w> depending on how mailman 2.1 and 2.2 are maintained this may do more than you want
<james_w> if it's small things such as the version number you can revert them and commit
<skip_m> Yeah, I just want *my* changes to the 2.1 branch
<james_w> if it's huge then you want to cherry-pick
<lifeless> skip_m: start by trying the simplest thing
<lifeless> skip_m: if that grabs too much, use merge -r branch:lp:mailman/2.1.. $your-mailman2.1-branch
<skip_m> The simplest thing for me is 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' but is that the correct way to do things?
<skip_m> liefless: I don't understand the merge -r branch... thing.
<lifeless> skip_m: it would figure out the 1134..1139 for you
<lifeless> 'bzr diff -r1134..1139 | (cd ../mailman2.2 ; patch -p0)' is better written as 'bzr merge -r 1134..1139 ../mailman2.1'
<skip_m> And if that merge command doesn't do what I want is there a way to easily revert it or do I just blow away my mailman2.2 repo and branch again?
<lifeless> 'bzr revert'
<skip_m> ok  - skip holds his breath and gingerly types 'bzr merge -r 1134..1139 ../mailman2.1' RET
<lifeless> have you tried just 'bzr merge ../mailman2.1' ?
<skip_m> not so good.  Something about 34 conflicts.  To many files I didn't touch.  bzr revert looks bad too.  Time for 'rm -rf ; bzr branch ...'
<skip_m> lifeless: no, i'll try that next.
<lifeless> skip_m: huh, no need to rm -rf
<lifeless> what did bzr revert do?
<skip_m> it was ugly:
<skip_m> % bzr revert
<skip_m> -   cron/
<skip_m> -D  cron/gate_news.OTHER
<skip_m> -D  cron/spambayes.ini
<skip_m> Conflict: can't delete cron because it is not empty.  Not deleting.
<skip_m> And I wound up with a mailman2.2 which had a 2.2 directory and an empty cron directory.
<skip_m> It's all gone now.
<skip_m> (should I be using pastebin or something for these little snippets?)
<lifeless> skip_m: no, its fine
<lifeless> anyhow, if you ever feel the need to rm -rf, just ask; you shouldn't ever get that wedged with bzr
<lifeless> so, try 'bzr merge ../mailman2.1'
<skip_m> lifeless: that's what people tell me about mercurial too.  I think it probably boils down to me being an old fart.  CVS and Subervsion are probably about all my feeble brain can handle. :-/
<lifeless> its the simplest, and often the right command to use
<Ursinha> hey beuno :)
<Ursinha> do you know if there's an equivalent in bzr to rebase in git?
<lifeless> so all the conflict means is that there was a file (gate_news.OTHER) that bzr didn't put in cron, that would be permanently lost if bzr deleted the cron directory
<lifeless> Ursinha: 'rebase'
<Ursinha> hahaha
<Ursinha> simple as that :)
<Peng_> It's a plugin, though, bzr-rebase.
<Ursinha> oh, now I understand why I couldn't find it right away
<Ursinha> thanks Peng
<Ursinha> Peng_, even
<Ursinha> and lifeless
<lifeless> np
<lifeless> skip_m: so, bzr doesn't delete cron and lets you decide how to handle the situation
<lifeless> skip_m: how did 'bzr merge ../2.1' go for you ?
<lifeless> (and when we say ../2.1, we mean the path to your patched copy of 2.)
<spiv> (although, IIUC, it seems like a bug that revert doesn't implicitly mark conflicts as resolved, thus removing the conflict files, thus removing one common source of irritating and confusing "can't delete some_dir" conflicts)
<skip_m> ok - i figured out what went wrong.  I had INSTALL, FAQ, cron, ... in my mailman2.1 dir.  When I branched in my mailman2.2 dir it created a 2.2 dir containing INSTALL, FAQ, cron, ...  Doing a bzr merge there failed miserably.  Next time around I mv'd 2.2/* and 2.2/.bzr* to . which then made mailman2.1 and mailman2.2 proper siblings.  The merge worked *much better*:
<lifeless> spiv: it does, but revert can conflict itself
<skip_m> % bzr merge ../mailman2.1
<skip_m> +N  cron/spambayes.ini
<skip_m>  M  cron/gate_news
<skip_m> Text conflict in cron/gate_news
<skip_m> 1 conflicts encountered.
<skip_m> I'm sure I can fix the gate_news conflict with no problem.
<skip_m> Thanks for the help folks.  Right now I'm off to the pool (swim, swim, swim - sure beats typing at the keyboard every now and then!!!)
<skip_m> ciao
<spiv> lifeless: any case that "bzr merge SOMETHING; bzr revert" doesn't Just Work smells odd to me.
<lifeless> spiv: I agree; skip_m hadn't done that though :)
<lifeless> the .orig file causing the conflict was the output of patch
<lifeless> igc: could I bother you to get usertest to tell us if trunk has regressed in performance at all
<lifeless> igc: what with the big merges yesterday
<igc> lifeless: sure. I'm working on exactly that (great mind think alike)
<igc> lifeless, spiv: some pain though ...
<igc> bzr.dev 4266 can't branch Bob's 1.14rc branch :-(
<igc> the AbsentContentFactor get_bytes_as bug
<spiv> igc: grab it via http rather than bzr+ssh
<spiv> as a workaround
<igc> spiv: cool. I was about to try that
<igc> spiv: just a reminder about how bad that bug is (not that you needed reminding)
<igc> so spiv: how do I find http address for an lp branch? It's no longer in the UI?
<igc> jml: ^
<spiv> igc: lp:~aa/bb/cc -> http://bazaar.launchpad.net/~aa/bb/cc
<igc> thanks
<thumper> igc, spiv, poolie: can we get some reviews of abentley's big branch for nested trees please?  We don't want it to go stale again.
<thumper> lifeless: you around?
<thumper> lifeless: I have a stacking question
<lifeless> thumper: ask the question :)
<thumper> lifeless: skype would be easier I believe
<lifeless> spiv: I reckon land that fix
<lifeless> thumper: ok
<spiv> lifeless: hmm, yeah
<davidstrauss> Any major bzr folks in the Bay Area?
<lifeless> davidstrauss: thats SF right?
<davidstrauss> lifeless: yes
<davidstrauss> lifeless: I'm in SF for the week for Drupal.org sprinting, and I'm always looking to see friendly free software faces :-)
<lifeless> davidstrauss: uhm, dunno :). robey pointer is there I think, but he's paramiko/loggerhead and other things, not so much a regular bzr person
<davidstrauss> lifeless: I met with Aaron when I was in Toronto
<lifeless> davidstrauss: I'd drop a mail to the list TBH
<lifeless> or twitter or whatever
<davidstrauss> lifeless: TBH?
<davidstrauss> lifeless: I'll tweet it
<lifeless> to be honest
<davidstrauss> ok
<davidstrauss> lifeless: thans
<davidstrauss> lifeless: thanks
<rockstar> igc, ping
<igc> hi rockstatr
<igc> rockstar^
<igc> thumper: sure, planning to review it RSN
 * spiv -> lunch
<igc> thumper: just running some performance tests first so we know when 1.14 is better than 1.13 and --development is better than --1.9
<Peng_> jelmer: Yay, you upgraded bzr-svn to btrees. :)
<thumper> igc: great
 * igc lunch - bbiab
<rockstar> igc, hi, for some reason, your response didn't turn my tab blue.
<davidstrauss> If I branch a library into a subdirectly of tree and "bzr join" it, will I still be able to merge in upstream changes from the library's original branch?
<davidstrauss> And, if so, how would I perform such a merge?
<rockstar> igc, I'm integrating your revnocache into loggerhead.
<rockstar> igc, and I'm can't think of a single use case for RevnoCache.
<rockstar> igc, but I can see a use case of the opposite graph: {revid: revno}
<rockstar> Er, I mean {revno: revid}
<rockstar> igc, so I guess I have two questions: (1) how is RevnoCache supposed to be used, and (2) why use a tuple to describe a dotted revno?
<igc> rockstar: so the secret to integrating revnocache is this: make sure loggerhead is getting the graph by using Branch.iter_merge_sorted_revisions()
<igc> rockstar: there is no step 2 :-)
<igc> rockstar: revnocache is about to be superceded by bzr-historycache btw
<rockstar> igc, :(
<igc> bzr-historycache will do the same thing but more
<davidstrauss> Is --reference being dropped as an option to "join"?
<thumper> davidstrauss: the nested tree stuff is actively being changed right now
<rockstar> igc, so my RevGraphCache gets created with Branch.iter_merge_sorted_revisions()
<thumper> davidstrauss: abentley is the man to ask
<igc> rockstar: so revnocache had multiple ways of caching revnos - history will use just the best of those and be configurable as to whether it's on or not
<davidstrauss> thumper: Currently, if I join a branch, I lose "common history" with the branch I joined from
<igc> rockstar: yes
<davidstrauss> thumper: I'll ask abentley
<thumper> :)
<igc> and the next call to it (or the next call to a dotted revno lookup) uses that cache
<rockstar> igc, ah, so I was using all three types of cache, but it seems like RevGraphCache and a mapping of revno->revid should be all I need.
<igc> rockstar: you want graph caching, I think it's called "revgraph" or something like that in revnocache
<rockstar> igc, yea, RevGraphCache.
<igc> ignore the others
<rockstar> igc, yea.
<igc> rockstar: I'm about a week away from releasing historycache
<rockstar> igc, so, I also need to convert a stringified revno to a tuple revno for that graph.  Is there a helper function for that, or do I create my own?
<igc> I have some other things ahead of it in my queue, e.g. confirming the NG format is performing well on all use cases, reviewing nested trees, etc.
<igc> rockstar: I'll look, but something like tuple(revnostr.split('.')) ought to go close
<rockstar> igc, yeah, that's similar to what I was thinking.
<igc> rockstar: so it turns out to be slightly more complex ...
<igc> grab parse_revno from revnocache/revnocache.py
<thumper> if I have an open branch, how do I get the transport for that branch?
<igc> it would be nice to have that in the core I guess, so put up a patch if you get a moment
<igc> rockstar: ^
<igc> rockstar: any other questions for now? I'm about to head into the other room where my desktop is for a while
<poolie> hello igc
<igc> hi poolie - welcome back!
<poolie> thanks
<igc> poolie: hope you had a great break
<rockstar> igc, I don't believe so.  I'm already pretty far along.
<poolie> it was great, thanks
<igc> rockstar: if you do, just put a message into IRC or email and I'll check back later
<rockstar> igc, thanks for the help.
<thumper> nm
<sohail> how can I update my working tree to a specific revision?
<BasicOSX> I'm not finding the "Register a release" under the 1.14 series, perms problem? vila ? poolie ?
<poolie> hi BasicOSX
<BasicOSX> hi, attempting to register 1.14rc1 and upload the .zip and tar.gz, but do not see the "Register a release" for 1.14 series
<poolie> sohail: 'bzr pull -r 123 .'
<poolie> BasicOSX: hm me either
<BasicOSX> don't see it for 1.13 either :-(
<poolie> BasicOSX: i think this changed in the last release of lp
<BasicOSX> hmm, once I figure it out, I'll need to update the releasing documentation
<BasicOSX> I see your Code for this series now
<poolie> BasicOSX: maybe you need to add a milestone?
<poolie> there was some work on fusing releases and milestones
<BasicOSX> There is a 1.14rc1 milestone there already, let me look at it
<poolie> http://blog.launchpad.net/coming-features/linking-project-releases-in-launchpad-to-milestones
<lifeless> BasicOSX: you could ask in #launchpad
<lifeless> some devs idle there ;)
<skip_m> I get this message from bzr status: 'Text conflict in cron/gate_news'
<skip_m> I took care of the conflicts in the source and deleted the cron/gate_news.<STUFF> files. Still the
<skip_m> conflict message is there. How do I get rid of it?
<SKArfaceGC> long time cvs user. . . been reading about and playing with bzr.  Seems v.cool, is this an appropriate place to ask questions if I need help?  (after researching first)
<lifeless> SKArfaceGC: 'bzr resolve'
<lifeless> sorry
<lifeless> skip_m: ^
<SKArfaceGC> :)
<lifeless> SKArfaceGC: sure it is
<SKArfaceGC> cool.
<lifeless> but not from me right, now
 * lifeless heads to the shops ;)
<SKArfaceGC> Don't have any at the moment.  just lurking
<skip_m> lifeless: thanks
<skip_m> In my mailman2.1 repo I have this push branch:
<skip_m> bzr+ssh://smontanaro@bazaar.launchpad.net/%7Esmontanaro/mailman/SpamBayes/
<skip_m> Can I just push to it from my mailman2.2 branch without creating problems?
<AfC> SKArfaceGC: you may want to know that both this channel and the project's mailing list are used jointly for  user[s of bzr]  as well as hacker[s working on the tool] discussion. So sometimes it can get a little esoteric
<SKArfaceGC> I write large security software for a living.  I can deal with esoteric.  :)
<sohail> poolie, thank you!
<skip_m> I used bzr push --overwrite ... which seemed to work.  If that was a bad thing, speak now or forever hold your peace. :-)
<spiv> skip_m: push --overwrite will overwrite the history in that branch to be the same as the branch you are pushing from
<spiv> skip_m: so if that's what you wanted to happen, then that's fine :)
<skip_m> spiv: Thanks - that's fine.  Mailman 2.1 is a dead end.  I was asked to port my changes to Mailman 2.2.  I officially no longer care about
<skip_m> mm 2.1.
<spiv> lifeless: btw, my fix branch failed because it adds one more get_parent_map call the stacked push acceptance test.
<spiv> skip_m: sounds good then.
<spiv> skip_m: (normally in that situation I would have merged 2.2 into my branch and committed that, in which case a regular push would work just as well as there is no divergence of history)
<SKArfaceGC> hrm. . . are there any karma granting/branch locking hooks available?  Something like sheila for CVS
<skip_m> spiv: i know nothing about the possibly divergent histories of mm 2.1 and 2.2 (and don't really care).  I just wanted to get my little enhancement out there for people to use.
<lifeless> spiv: as it stands it has to
<lifeless> spiv: so +1 to increasing the ratchet
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14rc1 released 07 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<spiv> lifeless: that's my feeling too.  Glad you agree :)
<Peng_> BasicOSX: Congrats on the release (candidate). :)
<BasicOSX> long road traveled on this one.. thank you though
<Peng_> On a different subject, is it just me or do some of BasicOSX's gpg-signed emails fail verification? Like the 1.14rc1 announcement on the announce list.
<BasicOSX> That's the 2nd time I've heard that. Seems to be only to mailing lists.
<Peng_> Oh, nice.
<BasicOSX> First time was a user on Win32, so I, well, kinda ignored them
<BasicOSX> tbird doesn't have the best pgp hooks
<BasicOSX> (not that mail.app is any better)
 * Peng_ is using Thunderbird + Enigmail
<BasicOSX> :-P
<BasicOSX> On windows? :-)
<Peng_> No, an out-of-date Ubuntu box. :D
<BasicOSX> sheesh bug reports coming in on 1.14rc1 already
<Peng_> I think several of you have been to bed and gotten up again while I've been awake. :\
<Peng_> (Well, if you haven't, then you should be getting more sleep!)
<spiv> lifeless: btw, I'm using ec2test.
<BasicOSX> PQM playing 1.14rc1 back into bzr.dev, afk for dinner
<lifeless> spiv: liking it ?
<spiv> lifeless: it's neat, but it'll be much more likeable with the rough edges smoothed off :)
<lifeless> spiv: thats true
<lifeless> spiv: feel free to shave :)
<igc> lifeless: any thoughts on bug 357478?
<ubottu> Launchpad bug 357478 in bzr "development6-rr vs gc-chk255-big regressions" [Undecided,New] https://launchpad.net/bugs/357478
<lifeless> igc: none beyond my reply
<igc> oh, I didn't see that - I'll look
<vila> hi all
<lifeless> hmm, I may not have disabled tree references enough
<igc> hi vila
<lifeless> spiv: +1 on any changes to ec2.test
<lifeless> .txt
<lifeless> spiv: possibly we should ask the source, or more-local of the repositories for the parents.
<lifeless> spiv: or something
<spiv> lifeless: yeah.  It would be nice to have a good way of saying "get these {parents,revisions,whatever} from a set of repositories, but try the most local first".
<spiv> It's a desire that comes up occasionally.
<sabdfl> hello all, congrats on landing brisbane-core in trunk
<sabdfl> two observations
<sabdfl> commit after status seems really quick (delta over status is low)
<lifeless> excellent
<lifeless> that was one of the key things we were removing overhead on
<lifeless> and thanks
<sabdfl> explicit commit (commit file file file) seems slower than normal commit, which i don't understand since it doesn't have to check as much dirstate
<sabdfl> and commit after add seem much slower than it used to be
<lifeless> explicit commit: we can't use the new commit code path in all cases yet; we have to teach our core diff logic (iter_changes) to report parent directories in some cases, or you end up with a broken commit
<sabdfl> aha
<lifeless> this is one of the things we'll polish while its a beta format
<lifeless> so you're seeing the older commit codepath when you do commit [paths..]
<lifeless> doing commit -x path  will trigger that too, as iter_changes hasn't been taught to do excludes
<lifeless> commit after add: is it slower for both the initial commit, and later commits after adds, or just the initial one?
<lifeless> the split inventory structure requires more calculation to create the initial tree than the old flat-file xml format (but it wins massively on subsequent commits as you're seeing)
<lifeless> so another item of polish is to work on making that initial tree operation faster
<lifeless> The old format just wants everything in the tree appended to a list, whereas the brisbane-core format builds a dictionary. That said, there is plenty of room for optimisation.
<lifeless> BasicOSX: please do update NEWS in bzr.dev :) its in the process I thought..
<BasicOSX> I merged bzr.dev into my local branch, fixed up the conflicts, PQM'd it back, got a success
<BasicOSX> merge lp:~tanner/bzr/1.14rc1 http://bazaar-vcs.org/bzr/bzr.dev
<BasicOSX> Command was successful.
<vila> lifeless: ec2 fix BB:approved, lowering (but not zeroing !) ec2 setup priority :)
<BasicOSX> I did merge my lp branch "merged" so it doesn't show
<BasicOSX> and a fresh branch of bzr.dev show my merge
<lifeless> ok
<lifeless> I've just not pulled in the last 40 minutes :P
<BasicOSX> hmm, patch succeeded at 1:22am CDT
<lifeless> fsvo 40
<lifeless> :P
<vila> BasicOSX: bzr version now shows 1.14rc1 in bzr.dev !
 * BasicOSX hides
<lifeless> lol
<BasicOSX> I'm bring down fresh, I'm sure I forgot something :-( last part of releasing documentation isn't very detailed (I'm fixing that)
<lifeless> BasicOSX: when you merge back you need to preserve bzr.devs concept of being bzr.dev
<lifeless> so its merge, tweak NEWS bzr bzrlib/__init__.py
<BasicOSX> yes, my mistake
<vila> BasicOSX: visual inspection bzr diff -c 4267 doesn't reveal anything else, you're doing good !
<vila> BasicOSX: I suspect you're bumping into many "it's so obvious it's not documented" points due to previous RMs being more experienced and you did a good job already updating the release process documentation, so, it's just part of it
<BasicOSX> sadly, my free time is 11pm-3am, so the documentation is my double check when I'm sleepy
<lifeless> well, the docs used to say to do this
<lifeless> but perhaps lost at some point
<BasicOSX> If it's not already done, advance the version number in bzr and bzrlib/__init__.py. Submit this back into pqm for bzr.dev.
<BasicOSX> I read that as advance it from 1.13final to 1.14rc1
<lifeless> that line lies
<lifeless> or
<lifeless> is overly brief
<BasicOSX> I got notes now, need to make sure it's 'dev'
<lifeless> so advance means 'change 1.14dev to 1.15dev'
<BasicOSX> ok, just need branch, it's 1,14,0,'dev',0,
<lifeless> yup
<lifeless> later all
<BasicOSX> do I need to update bzr's _script_version too ?
<vila> BasicOSX: yes, it's even surprising it isn't mentioning dev...
 * BasicOSX winks
<BasicOSX> lifeless:  beat me to pqm
<BasicOSX>   lp:~tanner/bzr/bzr.dev has my fix in it, if someone wants to verify
<BasicOSX> v$ ./bzr --version
<BasicOSX> Bazaar (bzr) 1.15dev
<BasicOSX> 3:17am, sleep, email me if I need to work on other stuff I messed up :-)
<vila> BasicOSX: good night !
 * igc dinner
<johnf> spiv:  you about?
<poolie> hello johnf
<johnf> poolie: howdy
<Mez> using the central repository model, is there an easy way to get the server to run a test suite every time something is checked inot the branch (or merged in, etc)
 * Kinnison uses a pqm for that, perhaps a server-side commit hook?
<Bluehorn> Mez: PQM is here: https://launchpad.net/pqm
<Bluehorn> *: Is there a way to aggregate multiple changes into a single revision in bzr?
<Bluehorn> Background: I was messing around with bzr-gtk (not having used pygtk for a while) and would like to post the patch.
<Bluehorn> But I don't think anybody would like to see the debugging code I originally had in there and the bzr misuse I did (created a conflict due to bzr push not updating the working copy).
<lifeless> Mez: sure use a pre_branch_tip_change_hook
<lifeless> Mez: (see bzr help hooks)
<lifeless> Mez: pqm is not easy ;P
<Bluehorn> lifeless: but it looks like an interesting concept ;-)
<lifeless> Bluehorn: it is, and it works well, its just not easy ;)
<Mez> lifeless: only through p1m?
<Mez> lifeless: never mind, was reading something els.e
<Mez> I'm actually looking for a post-hook, but something easy
<lifeless> mail the list, its late for me, I'll whip one up for you tomorrow
<Mez> thanks lifeless
<ormandj> Hi, I am attempting to follow: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style however, I am unclear about the setting up the shared repository step. I did the setup mentioned at the "Starting a central branch" section a bit higher up, then followed the distributed setup, but after I make my feature branch, and try to merge ../trunk/ to the feature branch, it complains I have uncommitted chang
<ormandj> es
<ormandj> the documentation didn't make this clear what I should expect
<lifeless> ormandj: you haven't committed your changes
<lifeless> ormandj: you need to commit after you make a change to a branch
<ormandj> lifeless: the documentation example didn't show the commits that's why i was confused about this
<ormandj> it shows running the merge *before* committing
<ormandj> ie: merge from the trunk to my new branch, then commit the merged changes along with my updates
<ormandj> (i'm doing the distributed style setup described)
<lifeless> well, the new branch has no changes in it when its just made; if you are getting told you have changes something odd is happening :)
<xnevermore> Hey. I want to use bzr on my web server to keep web development projects organized. I'd like to have a main branch and a development branch, then my main public_html folder where i would pull from the main branch for deployment. What would this kind of workflow look like?
<lifeless> it would look like a main branch, a development branch, and your public_html folder a third branch :)
<lifeless> or you could use bzr-upload for deployment
<xnevermore> so the main folder used to serve web pages to apache would be a bzr branch itself? or a mirror? or something else?
<lifeless> most people seem to use bzr-upload for that folder
<lifeless> its a plugin
<LarstiQ> that is what I would advise
<xnevermore> cool
<xnevermore> i'll check that out
<xnevermore> thank you
<lifeless> vila: I've just sent a new [MERGE] request
<lifeless> vila: which has the other stuff I was muttering about
<vila> lifeless: ok, will have a look (by the way, the tests *were* passing here ;-)
<lifeless> vila: not with my print intend change
<lifeless> vila: your write() call wasn't indented
<vila> lifeless: indeed, because I just copy/paste from my branch :)
<lifeless> see ;)
<vila> lifeless: doesn't really matter, it's just that we talked about it but it was never merged
<lifeless> sure
<lifeless> I think you'll like it
<lifeless> vila: if you wanted to review it now, I could land it immediately ;)
<vila> lifeless: I am
<lifeless> thank :)
<vila> BB:tweak, I think there is another atexit.register() you may want to get rid off, the one that delete the /tmp dir, plus some tests for done, startTests() :)
<vila> or did I miss the tests ?
<lifeless> well
<lifeless> I moved code
<lifeless> nothing 'new' really :) so existing tests should suffice
<lifeless> if nothing was testing the output, then I haven't reduced the coverage; if it was tested, then I preserved the behaviour
<vila> nothing 'new' but startTests() and done() just want to be extended/overriden :0)
<lifeless> what sort of tests would you like to see?
<vila> simplest ones: they are called once
<vila> seeing the modification of InstrumentedTestResult made me think they should be trivial to add
<jam> morning lifeless, shouldn't you be sleeping by now :)
<lifeless> jam: yes
<lifeless> vila: cut you a deal :) add some tests, land it ? :)
<vila> deal
<lifeless> cool - thanks
<vila> More often than not I feel I want to do that for many reviews...
<lifeless> with this, the output from selftest --parallel=forked looks like normal
<vila> err, I hope you haven't addressed the tracebacks *during* execution :-)
<lifeless> oh, you'll want https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346
<lifeless> for obvious reasons
<lifeless> what tracebacks?
<vila> lifeless: when tests errors out, the tracebacks is output directly *and* when selftest finish
<vila> I know it's a bug, but I like it :)
<lifeless> thats normal
<abentley> jam: I have tried to use py_memory_dump, but the files it creates are truncated at 128MiB
<lifeless> vila: its done by the ExtendedTestResult
<lifeless> I'm off to sleep
<lifeless> vila: jam has plain tweaked :) - but I'll leave it in your capable hands
<jam> abentley: I've got 200+ MB ones here.
<abentley> jam: What python are you using?
<jam> 2.5
<abentley> I'm using 2.6, though I'd be surprised if that was the difference.
<jam> mwhudson was using it with 64-bit python 2.4 and it worked for ~140MB ones, IIRC
<jam> abentley: I'm just using fprintf() I don't see why that would be truncating anything
<abentley> jam: Hey, all I know is that it's truncated.
<jam> abentley: what platform?
<abentley> I'm doing "bzr selftest", then using ^\ to get a pdb, and then calling dump_gc_objects
<abentley> jam: Jaunty
<jam> abentley: can you try adding a file.flush() in memory_dump/scanner.py ?
<abentley> jam: sure.
<abentley> jam: I tried twice.  Both were truncated; one at 120 MiB and one at 123 MiB.
<jam> abentley: you aren't running out of disk space, or something weird like that  (sorry for the delay, I was on the phone with Vincent)
<abentley> jam: 92 G left
<jam> abentley: is the program crashing, or returning just fine, and the file is just clearly truncated?
<jam> (I certainly don't do anything like truncate.... so something strange is happening)
<abentley> bzr.dev selftest is not crashing.
<abentley> The function is returning None.
<abentley> jam: Have you tried it from pdb like me?
<jam> abentley: I generally was using it via ^|, which drops you into pdb, yes
<jam> I wasn't doing it for selftest, more for 'bzr branch'
<jam> i'll try something again
<abentley> jam: I tried it with bzr branch, and that also truncated it.
<jam> abentley: does "python setup.py build_ext -i && python run_tests.py" work for you?
<jam> I just found it starting to fail on a different platform, which is a bit strange, but I'll try to sort it out
<abentley> jam: no: http://pastebin.ubuntu.com/147034/
<jam> hmm... seems to be a negative integer problem here
<jam> abentley: you are running that in the 'runsnakerun' branch, not the memory_dump branch
<abentley> jam: No, I'm just running it in the wrong branch.
<jam> (I *do* have a negative integer problem here, which I'm going to fix just now)
<jam> not that it would have anything to do with what you were seeing
<abentley> jam: still borked: http://pastebin.ubuntu.com/147035/
<jam> abentley: yeah, it seems that under Linux you get more malloc() in the upper memory segment
<jam> (>2GB)
<jam> so I just need to handle the high bit being set
<jam> abentley: I just pushed revno 59, can you see if that gets the tests to pass for you?
<jam> (just an 'unsigned long' versus 'long' fix)
<jam> I just dumped 262MB...
<jam> maybe a 2.6 issue?
<jam> though I guess now loading that dump is giving me "long int too large to convert to int", but I'll sort that out, too :)
<abentley> jam: I get two errors about expected sizes now.
<jam> abentley: can you paste that?
<jam> It is possible that objects changed size in 2.6 from 2.5
<abentley> http://pastebin.ubuntu.com/147043/
<jam> yeah, it looks like type objects have a different size...
<jam> so not something that means the code isn't working
<abentley> jam: The new version still truncates, though.
<abentley> jam: The ones I've done with branch were both truncated at 28016640 bytes.
<abentley> kfogel: I've updated http://bazaar-vcs.org/NestedTreesDesign with comparisons to other systems.  Would value your input, especially wrt SVN.
<SKArfaceGC> are there any tools for bzr that can handle granting/revoking commit privs to a central repo?  (similar to shiela in CVS)
<SKArfaceGC> I did some looking and didn't see anything.
<kfogel> abentley: will look over today (it's on my calendar, actually) thx
<abentley> kfogel: great
<abentley> Git submodule docs: "If you want to make a change within a submodule and you have a detached head..."
<kfogel> abentley: well, does that describe our users? :-)
 * SamB_irssi wonders why "Bazaar Bisect Plugin does not use Launchpad as its bug tracker."
<eka> hi all
<eka> shouldnt bzr diff /myoriginalbranch/ do a diff between current and that original one?
<eka> instead I use bzr diff --old /myoriginalbranch/ to see the differences
<LarstiQ> it used to be that way, I believe it changed to --old because bzr diff /myorginalbranch/some/file is ambigious
 * SamB_irssi leaves a question at https://answers.launchpad.net/bzr-bisect/+question/66893
<eka> LarstiQ: But what I ment is to compare both branches, and not a file. I thought that bzr diff /otherbranch/ was intuitive :P
<LarstiQ> eka: hey, I'm in the same camp :)
<eka> LarstiQ: oks... still I'm new to bzr so I thought that there was something wrong
<eka> s/ment/meant
<SKArfaceGC> are there any tools to handle granting/revoking commit permissions per branch?  I know it can be done at the OS level, but automating user group changes seems less than ideal
<LarstiQ> eka: it is a concious decision to do it this way. The exact reasoning would take some digging up.
<eka> could be a bug?
<eka> ah ok
<eka> thx
<SKArfaceGC> <- still very new with bzr.
<SKArfaceGC> :)
<nir> How can I merge various small projects branches into single branch without loosing the history of each branch?
<mwhudson> nir: the merge-into plugin, perhaps?
<nir> perhaps :-)
<lifeless> vila: pin
<lifeless> g
<plastik9> Hi. What's the best way to manage a web site with bzr (locally, the server is located on the same machine)?
<lifeless> plastik9: probably just use bzr-upload to upload to the directory of the website, because bzr-upload doesn't include the bzr history and metadata that you may not want people downloading by mistake
<plastik9> lifeless: does that work the same way as a lightweight checkout?
<lifeless> not really
<lifeless> you would have a separate branch or checkout that you edit in, then when you want to deploy a new version just do 'bzr upload'
<plastik9> ok, cool. thank you.
<plastik9> i noticed there is a section of the wiki devoted to these sorts of questions (http://bazaar-vcs.org/Scenarios), but I was disappointed to see that it hasn't been completed yet
<lifeless> that often happens with wikis :)
<nir> I tried to use merge-into plugin - but it does not keep the history of the merged-in branch. Is it possible to to do this?
<nir> e.g. project-a + project +b -> project-c with all history of a and b.
<lifeless> nir: it should; why do you say it doesn't ?
<nir> I don't see any log except the merge in
<lifeless> what bzr version are you using?
<nir> 1.10
<bob2> was the log format change a speed thing?
<lifeless> you *should* be seeing all the commits of the branch you merged in, nested in the commit that you made after the merge in
<lifeless> nir: are you seeing any nested commits at all? If you're not try 'log --log'
<lifeless> erm
<lifeless> log --long
<lifeless> jam: ping; I do have merge-into correct don't I? ^
<jml> lifeless: thanks for pushing done() out there.
<lifeless> jml: needed doing; I'm thinking of actually doing it as startTestRun and endTestRun
<nir> I don't see any nesting in this case
<lifeless> jml: and saying 'whoever creates the result is responsible for calling both these methods'
<lifeless> because otherwise its asymmetrical
<jml> lifeless: in some cultures, asymmetry is the cornerstone of beauty
<lifeless> jml: This is true; I will leave the asymettrising of python code beauty appraisal to other hands than mine
<jml> :)
<lifeless> in fact, a german research group has disproved the 'beauty is symmetrical' theory
<lifeless> http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/symmetrie/symmetrie.htm
<lifeless> summary 'the same face made more symmetrical is perceived as more beautiful, but only by a small amount'
<nir> More info: I do see all the history when I merge in another branch.
<lifeless> nir: I'm not sure whats going on. I suggest filing a bug or askig on the list if jam: doesn't reply here soon
<lifeless> nir: you have committed the merge-into right?
<nir> I did this:
<nir> mkdir test; cd test; bzr merge-into /path-to-branch; bzr commit; bzr log
<nir> The first merged-in branch comes without history. The second with history.
<nir> Third also ok
<nir> Anyway the merge is not what I expected - I want the same history in the new branch. For example, If I have branch a with 10 revisions, and branch b with 20 revisions, I want the merged branch to have 30 revisions.
<nir> With merge-into, I have only 2 revisions.
<lifeless> Is there something special or different about your first merged-in branch?
<nir> Each branch may be created on different platform with different bzr version
<nir> bzr log --short show that I have revisions -101 to 3
<lifeless> wow, thats odd :)
<nir> revisions -101 to 0 are seems like the revisions of the first branch
<lifeless> could you file a bug please
<nir> ok
<jam> lifeless: are you guys now off of daylight savings time?
<lifeless> jam: yes, its 0808
<lifeless> jam: this probably interferes with your evenings
<poolie> hello jam, lifeless
<lifeless> hi poolie
<jam> lifeless: yeah. We're probably going to have to work something else out for standup calls.
<jam> hey poolie
<poolie> jam, because this is the time when lena's coming home etc?
<jam> poolie: yeah, stopping my work day at 6pm+ doesn't work very well.
<jam> I might be able to do a split shift, where I come back around 8-9
<jam> but then that is in the middle of your day
<jam> I could probably do 1 standup per-week, or something like that
<jam> but every day is a bit much
<lifeless> jam: does my reply about uses_deltas make sense?
<nir> lifeless: see #358059
<lifeless> bug 358059
<ubottu> Launchpad bug 358059 in bzr-merge-into "merge-into merge a branch using negative revnos" [Undecided,New] https://launchpad.net/bugs/358059
<nir> nice bot
<jelmer> lifeless: moin
<lifeless> moin moin
<jam> lifeless: anyway, I think I understand your point, and responded. I'm off for now, but I'll try to be back around later, as we haven't really chatted in a while.
<jam> poolie: ^^ as well
#bzr 2009-04-09
<spiv> Mez: if you install a pre_change_branch_tip hook, and only allow write access via a smart server, then you can enforce it.
<poolie> jam, hi
<igc> morning
<poolie> hello igc
<poolie> does anyone have ideas for Ubuntu Open Week?
<poolie> apparently emmajane is going to talk
<igc> hi poolie, jam, jelmer, lifeless, spiv
<poolie> https://lists.ubuntu.com/archives/ubuntu-devel/2009-April/028061.html
<SamB> is there some secretly better version of bzr-bisect that I'm somehow missing out on?
<jelmer> SamB: what's wrong with bzr-bisect?
<SamB> it seems to have a tendancy to introduce changes into the working directory that conflict with eachother ...
<SamB> ... and bzr proper seems unaware what revision bzr-bisect is looking at ?
<jelmer> SamB: please file a bug
<SamB> jelmer: where/how?
<jelmer> SamB: launchpad.net/bzr-bisect I guess
<SamB> jelmer: er, uh, can't!
<SamB> see https://answers.launchpad.net/bzr-bisect/+question/66893
<jelmer> SamB: ah, I guess Jeff doesn't use launchpad
<SamB> well, I don't think that HTTP URL is going to accept any bug reports, somehow ...
<jelmer> SamB: you should still be able to report bugs in Launchpad though even though the project isn't officially using it
<SamB> jelmer: perhaps!
<SamB> but I can't see a way past all these yellow boxes
<SKArfaceGC> are all of the permissions with bzr handled via fs perms?  are there any plugins that can handle blocking/accepting various types of access?
<spiv> SKArfaceGC: There's contrib/bzr_access in the source releases, I'm not sure how good it is.
<SKArfaceGC> hrm.  I'm ultimately looking for something that does for bzr what sheila does for CVS.
<SKArfaceGC> I'll check that out.
<SKArfaceGC> It's also possible I'm just thinking about the problem incorrectly.  only been messing with bzr for a week or so.
<Odd_Bloke> SKArfaceGC: What does sheila do for CVS?
<SKArfaceGC> Odd_Bloke: it allows certian users to grant karma to other users so that they may commit.  it also facilitates locking the repository so no one can commit.  i.e. while running builds etc.
 * igc lunch & medical stuff - back in a few hours
<Toksyuryel> Doesn't sound like what sheila does would apply to bzr, since the whole point of distributed vcs is to remove the situation that makes something like sheila necissary
<Toksyuryel> Then again it's possible to use bzr exactly like cvs (if you're insane) so maybe it exists?
<lifeless> SKArfaceGC: bzr has atomic commits, so we can lock ourselves
<lifeless> SKArfaceGC: and untrusted users just commit to their own repository, so you don't need to have portions of a repository writable by different people - you just create a new repository
<lifeless> jml: this should be a no-brainer to review : https://code.edge.launchpad.net/~lifeless/subunit/done/+merge/5346
<jml> Done.
<lifeless> thanks
<poolie> lifeless: i would like, possibly in vain, to drive to 0 New bugs
<poolie> it would help if when you file bugs by mail you also mark them confirmed
<lifeless> poolie: ride, surely.
<poolie> and set a priority
<lifeless> I often do
<lifeless> I also often don't.
<poolie> yes :)
<lifeless> poolie: You've mentioned this before. I guess I don't make it a must-do simply because we're usually wrong anyway
<poolie> about the priority?
<poolie> i agree
<poolie> i think basically i just want one bit which says "this has been considered by a developer"
<poolie> possibly i should write a script which looks for untriaged bugs filed by one of us and marks them confirmed:whenever
<Peng_> What if the bug really isn't confirmed?
<fullermd> If it isn't confirmed, maybe it's infirm?
<lifeless> Peng_: if $coredev files a bug its fair to assume its confirmed
<lifeless> poolie: actually I have a suggestion
<lifeless> poolie: a search for bugs with no activity by a core dev
<lifeless> [open bugs]
<Peng_> lifeless: $coredev can make a mistake.
<lifeless> Peng_: yes, but I don't think martin is interested in confirmation
<Peng_> Although that will be rare, so it'll take less effort to fix mistakes than to confirm every bug filed by #coredev.
<Peng_> s/#/$/
<lifeless> Peng_: I think he is interested in identifying bugs that a core dev has not looked at and considered.
<poolie> that's correct
<poolie> sometimes one developer will want to disagree with another one's bugs, but that's a different problem
<poolie> or, not really "problem", "case"
<vila> hi all
<lifeless> hi vila
<vila> lifeless: great, you're still there, your patch raised questions I wanted to clarify instead of blindly landing
<vila> lifeless: you did get my mail right ?
<lifeless> yes
<lifeless> I replied
<vila> ok, so I didn't have the right subunit
<vila> but you're saying startTests is optional, is that true for done too then ?
<lifeless> they are not well defined yet
<vila> 'startTests' doesn't convey that, it surely shouldn't be used for suite.setUp for example as I was tented to do, nor done() for suite.tearDown()
<vila> s/tented/tempted/
<lifeless> its on result, you can't use it for those no matter how tempted you are
<vila> I realized that
<lifeless> also if you want to do a suite.setUp, you're thinking about the problem wrong
<vila> I don;t want a suite.setUp(), but we use atexit anyway and that's wrong too
<vila> and I don't like re-installing a hojj in the test suite either :-)
<vila> s/hojj/hook/
<lifeless> where do we use atexit?
<lifeless> oh, make_test_root
<vila> test/__init__.py to delete TEST_ROOT
<lifeless> it should be deleted after every test
<lifeless> its buggy
<lifeless> or use testresources
<vila> wazzat ?
<lifeless> lp:testresources
<jamesh> speaking of testresources, there are some proposed changes that need reviewing ...
<lifeless> jamesh: yes
<lifeless> I'm hoping to get to it in easter
<lifeless> its not exactly work..
<jamesh> cool.
<jamesh> maybe if bzr used testresources it could count as work? :)
<lifeless> vila: I want to leave these fuzzy for now
<lifeless> vila: good definitions are being hammered out on the tip list; when we have them bzr can just inherit them
<vila> lifeless: haa, just what I wanted to confirm, why don't you tell that first :-)
<vila> lifeless: and I missed that hint about subunit yesterday obviously :-/
<vila> I see it now... it looks like most of the messages I miss on IRC occur just after I send one, my parser should be buggy
<vila> lifeless: so, now that *I* have sync, I've remove the getattr for done,
<lifeless> ok
<vila> so if we you don't want more strict testing of the supported TestResult (but which ones), I can land
<lifeless> conformance testing of test results isn't something I feel we need for this change to be landable
<ronny> lifeless: are there any plans to support some kind of automated setup + aggregation in subunit, im in search of automated ways to run the testsuite for anyvc against different versions of hg/bzr
<lifeless> ronny: subunit can aggregate already; setup is something orthogonal - subunit won't get in the way but it isn't really in a position to help either
<ronny> so i'll have to find a way to encode the currently tested versions in the context
<ronny> lifeless: did the integration into other testing tools get any better?
<ronny> at least its still not easy_install-able
<lifeless> ronny: I would accept patches for easy-install; downloading random code off the internet isn't something I buy into though
<lifeless> I'm in the [rather large] easy_install OMG
<lifeless> group
<ronny> lifeless: its pretty convient
<lifeless> ronny: what sort of integration do you mean though?
<ronny> lifeless: stuff like nose
<lifeless> well, you were working on that
<ronny> i wrote a initial plugin some time ago, but it didnt seem to get any further attention
<lifeless> weren't you?
<lifeless> bzr uses subunit now, for parallel testing
<ronny> lifeless: i think all it needs to be easy-installable is a src tarball on pypi (at least for the python parts)
<lifeless> ok, well I'm happy to put it on pypi
<ronny> lifeless: oh, and is there finally any way to report additional metadata about a test
<lifeless> tag: foo
<ronny> stuff like stdout/err + profiling + coverage comes to mind
<lifeless> well
<lifeless> this is what you were asking about before
<ronny> hmm
<lifeless> I'm happy to discuss ways to embed this in the stream
<lifeless> unittest has no standard for it today, so its a little awkward to talk about it
<Mez> spiv: I dont want to enforce it, I want to have it run the test suite after a commit. So that 1) commits dont take forever and 2) we can still commit and just fix after
<spiv> Mez: running a buildbot is the usual way to do that.  You can have it trigger on commit emails and the like.
<spiv> (or by a post_change_branch_tip hook that pokes it directly...)
<ronny> lifeless: until it is standardized one could do something xdata: stdin [ ... ]
<vila> lifeless: one more thing: leaking threads report (data collection really) is broken for both fork and subprocess (by design), just something to keep in mind
<lifeless> ronny: well it should be in  the result comment area
<lifeless> ronny: IMO
<lifeless> ronny: the problem isn't defining stream handling for data, its defining how to present it to the TestResult in python
<lifeless> TestCase->TestResult is a [deliberately] narrow interface
<ronny> lifeless: well, then one would have to mangle it somehow and not mess up other parsers
<lifeless> ronny: I don't see why
<lifeless> subunit expects arbitrary data there
<ronny> hmm, so something like a trace is not actually expected?
<lifeless> it does the best it can
<lifeless> but you don't get traces from tap, or the C unit tester 'check' or cppunit or a bunch of other places
<ronny> it would be nice to have more metadata about what is in there
<lifeless> I agree; there is a tension between simple and structured
<ronny> ideally there would also be a way to hook into it via rpc and introspect the objects/data
<BasicOSX> poolie:  You should also merge (not pull) the release branch into lp:~bzr/bzr/current, so that branch contains the current released code at any time.
<BasicOSX> That is the releasing documentation (bug 358199) the wording is confusing to me. I'll make changes and RFC it.
<ubottu> Launchpad bug 358199 in bzr "eol filter silently ignores unknown settings" [Undecided,New] https://launchpad.net/bugs/358199
<BasicOSX> oops sorry Bug 357521
<ubottu> Launchpad bug 357521 in bzr "lp:~bzr/bzr/current is out of date" [High,Fix released] https://launchpad.net/bugs/357521
<lifeless> its meant to be sufficiently transparent that 'import pdb;pdb.set_trace()' will just work
<lifeless> ronny: ^
<ronny> lifeless: but how will that work with parallel tests and or wireing it into a ide
<BasicOSX> I also thought lp:~bzr/bzr/current meant bzr.dev
<ronny> specifying new hooks?
<lifeless> as a streaming protocol, you don't really want it to keep things around - in fact you can't be sure it will do that at all
<lifeless> IMO running in debug mode is a setup issue - subunit can pass the output from debugging mode over the wire, including any IDE or other control data
<ronny> ok, so subunit is purely reporting
<lifeless> (by 'it' I mean the remote test code; it could be C, or just a saved file)
<lifeless> subunit is a wire version of the TestCase->TestResult API
<lifeless> where users of subunit want things that belong in that API, but the API doesn't support them yet, I've tried to add them in tasteful ways that don't distort the base design
<lifeless> vila: so are you landing that branch now?
<lifeless> vila: oh I see, its now playing :)
<vila> :-)
<ronny> lifeless: i'll try to build something around it while im away, the next few days i might be disconnected
<Peng_> jelmer: Why make bzr-svn's default stacked format 1.9-rich-root instead of 1.6.1-rich-root? The latter would be better for compatibility.
<lifeless> ronny: ok cheers
<lifeless> ronny: I'd start just by getting your tests to run in a subprocess.
<lifeless> e.g. use IsolatedTestSuite
<lifeless> or if you want more control
<lifeless> (such as execing a new thing) ExecTestCase
<lifeless> or more control still
<lifeless> use the ProtocolTestClient and TestProtocolServer
<ronny> lifeless: i'll try - i need to figure a simple way to set up virtualenvs for the tests and install the currently required versions
<lifeless> http://lists.idyll.org/pipermail/testing-in-python/2009-April/001458.html
<lifeless> that describes using the result and proxy testcase directly
<lifeless> or you could look at bzr.dev's selftest --parallel=subprocess
<lifeless> later all
<Peng_> jelmer: Also: You left some pdb bits in test_repository.py in 0.5 and 0.6.
<yogsototh> Hi all
<yogsototh> I make a bzr pull ftp://name@orange.fr:pass@perso-ftp.orange.fr/root
<yogsototh> and it works on OS X
<yogsototh> but not on Windows XP with Cygwin
<Peng_> yogsototh: What version of bzr on OS X and XP? Pastebin the traceback you got.
<Peng_> (Not that I'll be able to help, but other people will probably need that information.)
<yogsototh> on Cygwin I installed a bzr version 1.3.1 (details http://www.mibbit.com/pb/TEixVg )
<yogsototh> The traceback is http://www.mibbit.com/pb/swVLXd , which means It cannot retrieve my username (certainly because of the @ in the user name wich can confuse with the @ just before the servername.)
<Peng_> yogsototh: What version of bzr on OS X?
<yogsototh> sorry my bzr version is 1.13.1 on Cygwin and I believe it is older on OS X but I don't remember exactly wich, may be 1.11, but I'm not certain.
<Peng_> yogsototh: There have been recent fixes related to usernames with @ in them. Maybe the version you're running on XP is too old but the version you're running on OS X is new enough.
<Peng_> Oh. Haha, never mind, I guess. :D
<yogsototh> 1.13 is the last stable version
<BasicOSX> 1.13.1
<yogsototh> Then I'll try with the 1.14rc1
<Peng_> yogsototh: Unless you're running 1.14rc1 on OS X, I'm probably wrong.
<Peng_> Wait a minute, from the error you pasted, it sounds like the error is coming from the server, not the client.
<yogsototh> I clearly not running the 1.14rc1 on OS X
<yogsototh> Yes
<yogsototh> The error come from the server
<yogsototh> But the weird thing about that is that it works on OS X
<yogsototh> OK, you're certainly right.
<yogsototh> I don't understand why, but I cannot connect my ftp server from windows, even with filezilla.
<yogsototh> Sorry then, it is then not a bazaar issue.
<stewart>  bzr branch lp:~eday/drizzle/eday-dev
<stewart> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('NoSuchRevision',)
<stewart> from latest bzr
<Peng_> stewart: As a workaround, you could branch over http or sftp.
<lifeless> spiv: is the fix done?
<bob2> hm, something on my system is weird and made bzr's progress bar print one line per update
<lifeless> lol
<lifeless> some terminals do a line feed when you hit the bottom right square
<lifeless> other terminals can emulate this on demand
<lifeless> we write a lot of ' ' to blank out a line
<natureshadow> hi there!
<natureshadow> I just want to checkout a branch from a project's bzr repository on launchpad and generated an ssh key which I also uploaded to Launchpad
<natureshadow> But I renamed it to ~/.ssh/launchpad because I don't want so many files called id_dsa around ;)
<natureshadow> How do I make bzr use this key file?
<poolie> BasicOSX: ok
<poolie> bob2: try running the command 'reset'
<Kinnison> natureshadow: You can add "IdentityFile ~/.ssh/launchpad" to an appropriate Host section of your .ssh/config
<Kinnison> natureshadow: I've never tried before, but from reading 'man ssh_config' that seems the appropriate thing to do
<natureshadow> Kinnison: oh, of course .... stupid me, didn't think of ssh config ;)
<natureshadow> What is the hostname, then?
<Kinnison> Now that, I couldn't say
<natureshadow> bazaar.launchpad.net ?
<Kinnison> but *.launchpad.net wouldn't be a bad guess
 * Kinnison hugs wildcarded hosts
<natureshadow> Kinnison: ok :)
<Kinnison> good luck anyway
<Kinnison> this is all untested guesswork advice
<poolie> natureshadow: i think it tries id_* or something
<natureshadow> I actually wonder what I need this for anyway, I thought I only need it for committing changes
<lifeless> or just do 'ssh-add ~/ssh/launchpad
<Kinnison> poolie: according to the manpage, it only does id_rsa and id_dsa
<Kinnison> lifeless: that also works, but only for one session
<natureshadow> Now bazaar advices me to file a bug report because of an itnernal error
<natureshadow> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 32: ordinal not in range(128)
<lifeless> garh
<lifeless> loggerhead search support broken
<Peng_> It is? How?
<Peng_> (Not that I'll fix it, but I'm curious.)
<lifeless> search.py is imported before load_plugins() is called
<lifeless> Aarons change to plugin path defaults means that that breaks loading search when search isn't globally installd
<Peng_> Aughhhh! Loggerhead filled up my /tmp directory!
<Peng_> Stupid ext3 32k link limit. But aughhh! Loggerhead, WTF?!
<Peng_> Oh god, shell autocomplete is slooow.
<Peng_> And I spammed the heck out of auth.log by trying to "sudo mv" them all at once. :D
<Kinnison> Peng_: tmpreaper might be your friend
<Peng_> Kinnison: Also Loggerhead not creating thousands of directories.
<Peng_> Looks like I noticed after only 2 hours. Great. :)
<Peng_> Glad my Loggerhead site is so unpopular. :D
<lifeless> Peng_: I have put a fix up for bug 334250
<ubottu> Launchpad bug 334250 in loggerhead "Search does not seem to work" [High,Confirmed] https://launchpad.net/bugs/334250
<lifeless> Peng_: if you wanted to poke at it that would be good
<Peng_> lifeless: Currently busy on "Loggerhead filled my /tmp", but I'd be happy to look at it, though there's an extremely small chance of me knowing how to help.
<lifeless> Peng_: 'works for me'
<lifeless> Peng_: would be a good start :)
<Peng_> lifeless: OK. Yeah, WFM.
<lifeless> that tmp thing looks fugly
<Peng_> What looks fugly?
<Peng_> The bug, or using /tmp at all or what?
<lifeless> 30K tmp dirs :)
<lifeless> at the very least it could create a subdir off of tmp to put it's dirty linen in.
<Peng_> lifeless: Well, it's only *supposed* to create one per load.
<Peng_> Although it doesn't clean it up on shutdown.
<Peng_> Err, by "load" I mean "starting Loggerhead", not "page load".
<poolie> night all
<Peng_> poolie: Good night.
<Mez> I keep having issues that I cant check in, it just sorta hangs at Transfer: Stage 0/4
<lifeless> that means you are using a checkout from a network branch, sos it has to push
<lifeless> what bzr version
<lifeless> and what branch did you checkout
<Mez> 1.13
<awilkins> How's Ashton-under-Lyne today?
<Mez> yeah, we have a checkout of a network branch, and we're checking out over bzr+ssh.
<Mez> (It's our own repository)
<Mez> but it's just hanging, doing nothing. (sometimes comes back with "too many concurrent connections)
<Mez> but this seems to be something that's happening a lot of late.
<lifeless> Mez: in which case, the time it takes to commit will be roughly the same as 'bzr push' after doing a commit in a local branch rather than a checkout
<lifeless> hmm
<lifeless> run with -Dhpss
<lifeless> see what it is hanging on
<lifeless> also check the server .bzr.log for errors
<Mez> well, I'm running a reconcile on the server at the moment.
<Mez> 1.760  opening SVN RA connection to 'chroot-3076886316:/home/bzr/fusion'
<Mez> wtf?
<Mez> http://rafb.net/p/sYsx3J74.html
<Peng_> Mez: bzr is trying to figure out what type of branch it is, so it asks bzr-svn, along with checking the built-in formats.
<awilkins> Would anyone be against `bzr revert` accepting globs?
<Peng_> awilkins: Well, since I'm not a Windows user with a crappy shell, I would be.
<Peng_> awilkins: It would mean I'd have to double-escape paths so they wouldn't be interpreted as globs, right?
<awilkins> Peng_: That's just mocking the afflicted though :-) - if it's good enough for SVN.......
<awilkins> I hadn't considered that ; but I don't see it either - what would you have to escape to stop it looking like a glob (my internal definition of "glob" may also be wrong here)?
<Mez> lifeless: this is the .bzr.log so far up until it's hanging
<Mez> http://rafb.net/p/Fxi2Dc91.html
<Peng_> awilkins: Well, if  want to version a file called "foo*.txt" for some strange reason, I'd have to escape the filename for my shell, and then I'd have to escape it again for bzr.
<awilkins> My example would be ; when I export a load of VBA form modules so I can version them, VBA inserts time-specific data into form resources, making them change every time, despite having no substantive changes in them. This I want to revert en-masse ;   svn allows   `svn revert *.frx` , bzr doesn't. As you pointed out, Windows isn't as accomplished in the shell dept and doesn't have xargs, for example
<awilkins> Peng_: Are you even allowed to name files like that on Linux VFS?
<lifeless> awilkins: we process *.foo ourselves on windows
<lifeless> awilkins: its completely fine to file a bug saying 'revert does not do this correctly on windows'
<lifeless> awilkins: because we special case windows ;)
<awilkins> Does it work using bash?
<Peng_> awilkins: Bash does glob expansion itself.
<awilkins> That was my next question :-)
<awilkins> I'm using Powershell, which is good
<lifeless> awilkins: 'bzr add' for instance definitely does shell expansion itself; its probably a small matter of code to fix revert
<lifeless> [on windows]
<awilkins> The neatest construct I've found that works well so far is `ls *.frx | foreach { bzr revert $_ }
<lifeless> Mez: thats odd
<lifeless> Mez: is the process on the server busy?
<awilkins> But that invokes a separate process for each file so less than ideal
<awilkins> bzr revert (ls *.frx) #  that works much better
<Mez> lifeless: not particularly
<Mez> http://rafb.net/p/G5WRq285.html
<lifeless> Mez: thats a lot of active processes
<lifeless> are they all from the same user?
<Mez> yes
<Mez> they're all root
<lifeless> *blink*
<Mez> though I think some of them are previous failed attempts?
<lifeless> are you connecting as root?
<lifeless> or perhaps you're running an anonymous server at the same time ?
<Mez> (we're logging in through SSH as root, as it seems to be the only way to get round the damned issues with permissions)
<lifeless> oh
<lifeless> could you strace them all
<lifeless> get a few seconds activity
<Mez> Process 14831 attached - interrupt to quit
<Mez> read(0,
<Mez> is the latest one, and it's hung there
<Mez> they're all the same
<lifeless> ok, they are waiting for a request from the bzr client
<lifeless> do you have ssh connection sharing on ?
<lifeless> (Master* stuff in your ~/.ssh/config)
<Mez> not that I know of
<lifeless> well
<lifeless> kill them all
<lifeless> then, your branch is probably locked
<lifeless> so 'bzr break-lock' the url of your branch
<lifeless> on the server
<Mez> afk
<awilkins> Gragh, BB needs to support searching
<Mez> bak
<Mez> lifeless: ok, all killed... what next (sorry, lunchtime)
<lifeless> Mez: break-lock as above
<Peng_> Well, only if it's necessary.
<Peng_> Or do we already know that it is?
<lifeless> Peng_: one known cause of toomanyconcurrent
<lifeless> Peng_: fixed I think, but - worth checking
<Peng_> Oh, really? Interesting.
<SamB> hmm, why does bzr have to keep deciding that directory adds cause conflicts :-(
<SamB> just because I personally have a directory in a given place already ?
<lifeless> SamB: two possible reasons; if you ahve an unversioned local dir, bzr can't make the dir that a commit you're pulling added
<SamB> why can't it just use the same one ?
<lifeless> SamB: and secondly bzr versions directories so if A and B both add a dir called 'foo', seperately, bzr doesn't know that it should be the same dir
<lifeless> well say you had a dir called tests
<lifeless> with some thousands of test logs
<lifeless> and someone adds a dir called tests to the project, with real files
<lifeless> when you pull, would you want those intermingled?
<SamB> what makes it particularly lame is that I think bzr tried to delete the directory in the first place ... but decided not to since there were files in (which I did not care about)
<lifeless> SamB: right, this is a particular bug, its in discussion on the list, and its really annoying when it happens
<lifeless> SamB: we will be fixing it!
<SamB> oh good
<lifeless> the issue is those files that weren't versioned
<lifeless> bzr doesn't know 'ignored, passwords' from 'ignored, editor backups'
<lifeless> so we err on the side of preserving user data.
<SamB> I'm not saying it should have deleted the directory
<SamB> ;-)
<lifeless> well
<lifeless> there are a number of ways to fix bzr here
<SamB> but it would be nice if it remembered that it had tried
<lifeless> I'm just explaining the background
<Mez> damned netsplits :D
<Mez> did everyone survive ok ?
<SamB> lifeless: I don't suppose you can turn on bug-tracking for bzr-bisect?
<lifeless> SamB: if the author is maintaining it outside launchpad, he won't see bugs put into it...
<lifeless> SamB: also its late, and I don't trust my judgement at this hour :)
<lifeless> Mez: yes; have you break-lock'd the branch?
<Mez> yup
<james_w> SamB: I thought it was on
<lifeless> Mez: ok, try your commit now
<Mez> seems to have frozen again
<lifeless> check strace on the server
<lifeless> if its in read(0, ) again
<lifeless> then a) file a bug
<lifeless> b) hit ctrl-\ on the client, then 'bt' to get a backtrace.
<lifeless> and put that in the bug report too
<lifeless> do a bzr check on the server on the branch
<lifeless> gnight all
<Peng_> lifeless: Good night. :)
<OllieR> hey I have renamed the directory which contains a bzr branch. It seems to think that it is still at its old location. See http://stikked.com/view/94640778
<Peng_> OllieR: ls -l .bzr
<jelmer> vila: hi
<jelmer> vila: how do you think the fallback credentials stores should work?
<OllieR> Peng_: yeah there is a .bzr dir in there
<vila> by being queried when they are registered iff no user and/or password is found
<OllieR> Peng_: see output here http://stikked.com/view/95451041
<jelmer> vila: but where should the fallbacks hide?
<jelmer> vila: AuthenticationConfig.get_credentials()?
<vila> jelmer: but before the user is prompted
<jelmer> vila: right
<vila> yes, get_credentials sounds right and should respect the constraints above naturally
<Peng_> OllieR: You're either using a checkout or a shared repository. If the former, fix the path in .bzr/branch/branch.conf. If the latter, make sure the branch can still find the shared repo.
<vila> jelmer: did I lose track of your get_username submission or should you still send one ?
<Peng_> OllieR: Probably; I dunno. :P
<OllieR> so ls .bzr/branch/ output format  location
<OllieR> location shows the old dir
<OllieR> i will try changing this
<jelmer> vila: I still need to send it
<jelmer> vila: I need to fix the tests still
<vila> ok
<bialix> igc: around?
<Peng_> bialix: ffwiw, he said "back in a few hours" 10 hours ago.
<Peng_> fwiw*
<bialix> anybody using fast-import plugin? I saw in ML several days ago fast-import trunk is broken for pack-0.92 format
<Peng_> Sorry, not me.
<bialix> hmm
 * bialix won't try to pull latest trunk then, and use known stable rev.
<Peng_> beuno: Pingy ping? :D
<Mez> ok, power fail :(
<SamB> how come the Bzr wiki doesn't have a place where you can click on the node title to see backlinks?
<Kinnison> What is the recommended way for a new project wanting a robot-controlled mainline and web-based review to set up using bzr these days?
<Kinnison> At one point it was bundlebuggy+pqm
<Kinnison> then there was talk of launchpad doing it
<Kinnison> and I've been out-of-the-loop for too long
<Peng_> Kinnison: You can replace Bundle Buggy with Launchpad if you want to, but you're stuck with PQM.
<Kinnison> I read about someone writing something which used launchpad's branch review stuff to trigger merges
<Kinnison> I think it's 'tarmac'
<Peng_> Ah. Good point.
<Kinnison> I used to run a PQM
<Kinnison> So I might stick with that and sort out a bundlebuggy
<Kinnison> But I do quite like launchpad's review stuff
<Kinnison> urgh
 * Kinnison shall have to think about this, thanks peng
<emmajane> hey all -- I'm adding myself to the OpenWeek schedule for an intro-to-bzr session.
<SamB> hmm ... how do I switch a working tree to a specific revision?
<Peng_> SamB: You can't really. Best you can do is "bzr revert -r 123".
<jam> vila: good morning
<vila> jam: hi !
<jam> vila having a good day?
<vila> jam: not one of the best :-/
<SamB> hmm ... ran into bug 348456 ...
<ubottu> Launchpad bug 348456 in bzr "reconfigure always use default formats" [Undecided,New] https://launchpad.net/bugs/348456
<SamB> and there's something wrong with the URL formatting in http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<kfogel> abentley: in Nested Trees, does "push" nest automatically?  If you run push in the containing tree, and you supply a dest argument, I guess the containing tree pushes to that location, but where would subtrees push to -- same place (hmrmrm) or to a remembered location?  Or not push?
<kfogel> (abentley: realized it makes more sense to ask you bzr questions here!)
<abentley> kfogel: I believe push doesn't currently nest, but it should.  It would push branches for subtrees to the same relative path the subtree is at.  Branch already does nest.
<kfogel> abentley: thanks.  So just curious: if you go inside a subtree and do 'bzr push some-other-location --remember', will that memory be pushed up too?
<kfogel> E.g, later you do 'bzr push' from the containing tree, with or without dest and with or without --remember, subtree still goes to old remembered location?
<abentley> kfogel: --remember will only have a local effect.
<kfogel> *nod*
<abentley> kfogel: So perhaps when you push to a location, that branch should be consulted to determine where to push subtree branches to.
<abentley> So, with branch "a" and branch "a/b", pushing to "c".
<kfogel> abentley: that's one possibility, yeah.  I can see how figuring out the expected behavior might get complicated here :-).
<abentley> Push a to c.
<kfogel> abentley: support for single-file subtrees?  That is, do subtrees have to be directories?
<abentley> look up d's location for b.
<abentley> sorry, look up c's location for b
<abentley> Which is 'd'.
<abentley> Push to 'd'.
<kfogel> (I like that solution best, I think.)
<abentley> kfogel: Subtrees have to be directories.
<kfogel> The whole push question has nothing to do with the Subversion comparison, of course -- Subversion doesn't support that stuff anyway.
<abentley> Maybe not, but I appreciate the questions.  These answers have a bearing on what I'm working on right now.
<kfogel> no plans to change the "subtrees must be directories" thing, right?
<kfogel> And, any plans to change the "must be specific revision-id" rule?
<abentley> kfogel: It doesn't really make sense to me.
<abentley> kfogel: If it were a file, what would the reference point to?  You can't have a working tree without at least a root directory.
<kfogel> abentley: in terms of user-visible behavior, we could describe what it means.  How it would be implemented, I have no idea.
<abentley> kfogel: the must be specific revision-id thing isn't a firm stance-- I'm curious why using head might be a good idea.
<kfogel> abentley: you could horn the metadata into the containing tree's metadata, i.e., "we've also got this file here from out of town...".  Not saying this is clean or desirable, just describing how svn does it.
<abentley> kfogel: Ah, so svn externals may be files?
<kfogel> abentley: some projects under development want (even need) to track the dev versions of dependencies.
<kfogel> abentley: yes.  svn's single-file support is currently weak, but that's only because of technical reasons; there are plans to make it stronger.
<abentley> kfogel: Sure.
<abentley> But I think you would address that by updating to the latest dev version, and committing.
<abentley> You can still pull new dev versions at any time.
<kfogel> abentley: it's interesting -- it sort of approaches the same result, over time, yeah.
<abentley> kfogel: I think it makes a lot of sense that when you check out a tree that has subtrees, you get a reproducible result.
<kfogel> abentley: I agree that can be a useful property.
<abentley> I thought maybe svn didn't do that because users were managing that metadata.
<kfogel> I think that's a good analysis.
<abentley> And updating it all the time would be a pain.
<kfogel> the way bzr does it is more appropriate for bzr.
<abentley> kfogel: Yeah, reading the SVN docs, I realize that nested trees are not going to be a superset of externals, at least not initially.
<kfogel> abentley: so you can read this at the newly-updated http://bazaar-vcs.org/NestedTreesDesign page, but: svn has a "--ignore-externals" flag that can apply to any operation that would normally pay attention to externals.
<abentley> kfogel: If we decide we want to allow the head to be specified, we can use one of our reserved revision-ids.
<kfogel> abentley: interesting!  Yeah.  But I kind of think you're right: there's no need to support it, and in fact it would be rather un-bzr-like.
<kfogel> Subversion just does it that way because updating the specific revision-id would not be easy, given that it doesn't come for free with the other UI around updating.
<abentley> Similarly, once we support partial checkouts, we might be able to support references to single files.
<kfogel> ah, cool
<abentley> kfogel: At the same time as supporting references to parts of the tree.
<abentley> kfogel: For now, we can suggest using symlinks like launchpad does.
<kfogel> partial trees will be nice, I think.
<abentley> kfogel: You're not the one who'll have to update merge :-(
<kfogel> abentley: that's right :-)
<kfogel> abentley: why, I'm so enjoying the freedom to have opinions without worrying about how I'd implement them.  "Waiter, I'll take one more of these, please!  No, actually, make that two."
<abentley> kfogel: lol
<abentley> kfogel: Thanks for looking at that.
<abentley> kfogel: Is there anything I should clarify in the design doc?
<kfogel> abentley: who is the intended audience for the design doc?
<kfogel> devs or users?
<abentley> kfogel: devs
<kfogel> cool (that was my guess).  I think just clarify the plans around push, since the answer there is not obvious.
<abentley> Cool, will do.
<SKArfaceGC> kfogel: thanks for your comment on my learning bzr stuff I posted last week.
<kfogel> SKArfaceGC: hey, glad you're writing it
<SKArfaceGC> kfogel: I think I'm going post about messing around with repositories and push/pull next.  I'll work on auth/permissions in the next one.
<kfogel> ok, I'll wait :-)
<SKArfaceGC> how did you find it?
<kfogel> google alert
<kfogel> bzr
<SKArfaceGC> aaah
<SKArfaceGC> after using cvs for 10+ years bzr is like a breath of fresh air.  Still working through stuff, but I think it may ultimately solve several problems for us.
<mrooney> Anyone know where svn stores its cached auth data in windows, I need to clear it.
<mrooney> I bet jelmer would know :)
<Peng_> I bet #svn would know! :P
<Peng_> (Kidding kidding.)
<mrooney> Peng_: I asked there too but there are plenty of smart svn people here :)
<jelmer_> kfogel: I noticed you added some comments about svn:externals to the NestedTrees wiki page
<jelmer_> kfogel: I've been trying to decide how to deal with unversioned svn:externals in bzr-svn as there doesn't seem to be a good bzr substitute for those
<abentley> jelmer: Did you see my comments under "Comments on differences"?
 * jelmer_ looks
<jelmer_> abentley: most of the svn:externals uses I have seen so far don't use an explicit revision
<jelmer_> abentley: I'm not sure if this is because it's hard to update the revision (you have to edit a revision property to do so) or because people prefer pointing at HEAD
<jelmer_> s/revision property/file property/
<abentley> jelmer_: I think it's probably the first.
<abentley> jelmer_: it may be that we add head support anyway, just to make bzr-svn work.
 * LarstiQ certainly uses revision pinning in svn:externals
<LarstiQ> hello, btw
<abentley> LarstiQ: hey.
<jelmer_> hi LarstiQ
<jelmer_> vila: Is it correct that webdav support may end up in bzr core?
<LarstiQ> hi abentle, jelmer_
<jelmer_> LarstiQ: have you looked at bug 336749 recently?
<ubottu> Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [Undecided,Invalid] https://launchpad.net/bugs/336749
<LarstiQ> jelmer_: no. I realize you'd like to tackle it before 1.0
<LarstiQ> jelmer_: please tell me I'm not the only hope of progress?
#bzr 2009-04-10
<fbond> When I do bzr combine-thread, I lose a reference to a head revision.
<fbond> How can I get it back?
<lifeless> fbond: bzr heads --dead
<lifeless> and then branch with -r revid:<revid>
<lifeless> fbond: but why are you deleting threads that are heads?
<jfroy> jelmer: ping+
<fbond> lifeless: Maybe I'm using the wrong words.
<fbond> I guess that's my problem.
<fbond> It *wasn't* a head.
<fbond> I tried bzr heads, but only found a single revision that I didn't really care about.
<fbond> lifeless: For some reason, I can't help but think of threads as branches with a tip.  But that's wrong, huh?
<SKArfaceGC> general usage question: when would I use pull instead of merge?
<SKArfaceGC> i.e. what does pull do that merge doesnt?
<Peng_> SKArfaceGC: When you have a mirror of a branch.
<SKArfaceGC> Peng_: ok, so it's mainly for copying a branch and be able to keep it updated.  i.e. pull a branch into a public_html directory to publish a website?
<SKArfaceGC> is it different than running update on a checkout?
<Peng_> SKArfaceGC: It's basically equivalent, but branches and checkouts are different things.
<Peng_> Omg, brisbane-core got merged to bzr.dev! Awesome! :D
<Peng_> A few revisions got left out, though.
<SKArfaceGC> one more... is a branch that I've bound to it's parent any different than a checkout?  conversly, is a checkout that I've unbound different than a branch?
<Peng_> SKArfaceGC: Bound branches are another name for checkouts. Unbound branches are regular old branches.
<SKArfaceGC> perfect.  Than I actually do understand what I think I understand.  Thanks   :)
<Peng_> :)
<lifeless> fbond: well its right to the extent that each thread has a tip; but in a normal loom all the threads are merged upwards most of the time, so there is still usually only one head
<lifeless> fbond: bzr log in the top thread will all the heads
<lifeless> jelmer_: so why do you want to drop sqlite?
<vila> hi all
<vila> jelmer_: putting webdav into core has been proposed by poolie and is considered but not done yet ;)
<jelmer> jfroy: hi
<jelmer> vila: thanks
<jelmer> lifeless: bug 185200
<ubottu> Launchpad bug 185200 in bzr-svn ""database is locked" bzr internal error" [High,Triaged] https://launchpad.net/bugs/185200
<lifeless> jelmer: do you know, how friendly is the new gnome vfs thingy
<lifeless> the old one was rather ugly
<jelmer> lifeless: I haven't looked at it closely yet
<lifeless> oh god
<lifeless> I just started to look closely
<lifeless> it depends on out of process, dbus rpcs to use the file system
<lifeless> http://library.gnome.org/devel/gio/stable/ch01.html
<jelmer> lifeless: it wants to be able to use GPL'ed libraries in LGPL'ed libs
<lifeless> hmm, I really need to sit down and do the rejiggering of your liballocevent or whatever you called it and libevent
<jelmer> ah, libtevent :-)
<lifeless> jelmer: thats not the reason they give, and if so, thats trying to do an end run around the GPL, which I *do not* approve of
<lifeless> if someone doesn't want their code used in non GPL apps, it shouldn't be used in non GPL apps.
<jelmer> lifeless: it seems to me like that's at least one of the reasons
<jelmer> (libsmbclient is GPL, and libgvfs is LGPL)
<lifeless> so
<lifeless> I think its time I wrote a C VFS
<lifeless> an async C VFS
<lifeless> because I like pain
<lifeless> where is the libtevent source? I'm going to compare/prod it and libevent
<jelmer> Samba's git repository, in lib/tevent
<Peng_> libev?
<lifeless> url please
<jelmer> git://git.samba.org/samba.git
<lifeless> jelmer: no http viewer?
<jelmer> oh, probably
<jelmer> http://gitweb.samba.org/
<lifeless> Peng_: hmm, better than libevent?
<Peng_> lifeless: I've never used either one, but libev was designed to be faster and have a better API. Plus it has a libevent-like API for lazy people.
<lifeless> jelmer: ok, still lost. can you give me the url to view the source please
<lifeless> Peng_: ok; IME when people claim that its 50-50 whether they are right or wrong :)
<jelmer> lifeless: try "apt-get source tevent"
<jelmer> :-)
<Peng_> lifeless: Right. I just wanted to put it on your radar. :)
<lifeless> jelmer: heh; so you can't find it in the web ui either
<lifeless> Peng_: I'd almost use ACE, except its hugely overcomplicated
<lifeless> jelmer: what did you think of my rewrite of the subunit README?
<lifeless> jelmer: is there a tevent man page?
<jelmer> lifeless: haven't seen it yet, not done my mail readin for the day yet
<lifeless> jelmer: kk
<jelmer> lifeless: no, most of the documentation is in the main header file
<lifeless> k
<lifeless> so what I want to exist is a good clean minimal extendable nonblocking [as opposed to async] C VFS
<Peng_> jelmer: BTW, um. Did you know you left a couple pdb bits in bzr-svn's test_repository.py (in both 0.5 and 0.6)?
<lifeless> with that in existence, people can write async or sync on top
<jelmer> Peng_: Are you sure you're looking at current sources?
<lifeless> jelmer: don't suppose you happen to know if such a beast exists?
<jelmer> Peng_: ganieda:~/bzr-svn/0.6% grep pdb tests/*.py | wc -l
<jelmer> 0
 * Peng_ pulls
<Peng_> jelmer: grep pdb tests/*/*.py
<jelmer> lifeless: I'm not aware of one
<lifeless> probably cause its hard.
<lifeless> right, time for a bit by bit hobby project
<jelmer> lifeless: :-)
<lifeless> interested?
<lifeless> oh, and fortunately, noone seems to have taken libvfs, at least not according to apt-cache search
<jelmer> I'm not sure, I try to stay away from the file system bits in Samba generally :-)
<Peng_> jelmer: Err, sorry. I didn't know there was a tests/test_repository.py. I meant tests/mapping_implementations/test_repository.py.
<lifeless> jelmer: :>
<lifeless> jelmer: my feeling is the reason that there are a bazillion different bad vfs' out there is because everyone is building them half-baked, so they play bad with threads, or with async, or with networks
<lifeless> I don't mean bad code, I mean their design principles are such that the product isn't reusable in many contexts
<jelmer> lifeless: You might want to talk to tridge about this, he's done quite some async work in Samba
<lifeless> I would but he's not online :)
<lifeless> I'll get my basic interest and notes together, then we can see
<jelmer> lifeless: IIRC there were also still problems with the kernel support
<jelmer> lifeless: (there is no way to make "open" non-blocking, ?)
<lifeless> its hard to argue that the kernel should be fixed when there is no userland that can represent it
<lifeless> from a VFS perspective you need: an interface that balances easy to use with getting the most out of good underlying facilities
<jelmer> chicken-egg :-)
<lifeless> then you can use threads or even helper processes over e.g. dbus, to get a non-blocking open
<jelmer> lifeless: yeah, that's one of the things that's been talked about for Samba IIRC (helper processes)
<lifeless> as long as client code can go 'for path in paths: pending_open = vfs_open(ctx, path)'
<lifeless> squid uses a helper to do IO on BSD systems
<jelmer> lifeless: anyway, my memory is all a big vague about this, you should really talk to tridge :-)
<lifeless> ('diskd')
<lifeless> on windows you can use completion ports to get nonblocking open
<lifeless> the os calls back in on the next event loop cycle
<jelmer> lifeless: any chance you can re-review my InterBranch.pull patch?
<lifeless> remind me tuesday
<lifeless> (its easter :P)
<jelmer> ok
<jelmer> lifeless: ah, ok
 * jelmer is looking at git -> git pull today
<lifeless> jelmer: having looked at tevent, I still think you'd be better off wrapping libev
<lifeless> or libevent
<jelmer> lifeless: Oh, I've never said we weren't
<jelmer> lifeless: My day only has 24 hours though
<lifeless> well thats true
<lifeless> but you were rather dismissive of potential benefits when I raised this
<jelmer> lifeless: the benefits are minimal
<lifeless> I rather suspect they are more than you think
<jelmer> lifeless: compared to the required investment
<lifeless> perhaps
<jelmer> lifeless: what would the benefit be, other than the fact that we have less code to maintain and fix bugs in?
<lifeless> thats rather a big win in itself; but you would get the features from the library you wrap (both support quite a bit more), and they are likely more scalable FWICT
<jelmer> lifeless: what sort of features does libtevent not have? last time I looked libevent lacked a couple of things that libtevent needed
<lifeless> libevent may have nothing; libev is much more featureful
<lifeless> child process watching, inotify support, that sort of thing
<lifeless> signal reflection
<jelmer> why do you need special inotify support, isn't that just waiting for a fd to become readable?
<lifeless> shrug
<lifeless> I'm not saying you should go change tomorrow
<lifeless> I'd need to do a whole bunch more reading to make a strong case; and as the samba team clearly have more pressing concerns its not exactly a wise use of time to do that
<lifeless> the key thing for me was looking at it now, and deciding that even if I use talloc internally in libvfs, I feel happier binding to libev, at least for now.
<jelmer> makes sense
<jelmer> lifeless: readme looks good
<jelmer> looking forward to seeing that check patch land
<lifeless> jelmer: me too
<jelmer> woot, "bzr pull" from git into git works \o/
<lifeless> grats
<lifeless> oh bugger
<lifeless> I think I just pushed a development6-rich-root repo to LP :P
<fbond> lifeless: bzr log in the top thread will show all tip revisions, but how can I tell which revisions they are?
<lifeless> by their branch nick
<lifeless> they get the nick from the thread
<lifeless> don't you hate it when you end up recursing to solve a problem
<vila> :-) As in: 'I want to do X, but first I need to fix Y, but to fix Y I need to fix Z' ?
<lifeless> yes
<lifeless> find a URL library that isn't part of an http client
<lifeless> for C
<lifeless> kgo
<vila> may be in an xml library ? :-}
 * lifeless spanks vila
<lifeless> time to register another launchpad project
<jelmer> hmm
 * jelmer wonders if he could finish colocated branches in time for 1.15..
<jelmer> are there any plans to have loom support in core (even if just the infrastructure so we could have a common format) ?
<lifeless> I'm not at all sure colocated branches _could_ have a common format with loom
<lifeless> as loom threads cannot have different push locations etc etc
<lifeless> nor do you [want or need I imagine] pending-merges on multiple branches stored at once
<jelmer> I'm not saying they should necessarily have a common format
<jelmer> but each of those changes will mean format changes
<jelmer> and it seems reasonable to bundle those to avoid users from having too many upgrades
<lifeless> I'm not currently convinced that colocated branches are the answer to the issues we have
<jelmer> sorry, I should've specified common better
<lifeless> they are *an* answer to be sure
<lifeless> I encourage you to discuss the problem more on the list - that would be good
<jelmer> I prefer colocated branches to the alternatives I've seen
<jelmer> personally
<lifeless> I think its a neither-fish-nor-fowl situation
<lifeless> I'd rather we choose
<lifeless> if branches are colocated, repositories are hard to justify, so we should look at ripping the separated-repo facilities out or evaluating why we can't do that, and so on
<lifeless> if repositories are still useful, then we'll have non-colocated branches in repositories, and we aren't we making them as easy to work with
<jelmer> s/repositories/shared repositories/ ?
<lifeless> yes
<lifeless> anyhow
<lifeless> midnightis
<lifeless> -> sleep
<lifeless> also, launchpad.net/liburl and libvfs :P
<lifeless> because the world needs more skeleton projects
<jelmer> lifeless: that doesn
<jelmer> 't help me in the near future though, nor does it help with foreign git repositories
<jelmer> lifeless: 'night
<vds> on my jaunty bzr hangs when I do pqm-submit to launchpad, if I stop it after a while with ^C I don't get any useful info
<joschan> Hi. I am just having a little accident - I said "bzr revert" in the root folder if a live website. It seems all changes after the last commit are gone. Is this what revert normally does?
<joschan> And is it somehow possible to get the latest version in the live fodlers (that was never commited) back?
<joschan> it seems the old versions of changed files were copied as oldname.~1~
<joschan> and new files were not deleted
<joschan> i will re-rename manually and commit again
<jelmer> joschan: yes, that's the intended behaviour of bzr revert
<jelmer> vila: thanks!
<vila> jelmer: np, are you going to do fallback credential store ?
<SamB> hmm
<vila> jelmer: I just tought about it and I think we need a way to desactivate it without uninstalling bzr-svn for example (if only for debug purposes)
<joschan> jelmer thank you
 * SamB wonders what is with the link: * http://starship.python.net/crew/mwh/bzrlibapi-oe/  (editable version)
<jelmer> SamB: editable ?
<jelmer> vila: yeah
<vila> SamB: I get a 503, but mwh sounds a lot like mwhudson to me
<SamB> well, I guess I'm wondering whether I should delete it from the BzrLib node ...
<jelmer> SamB: I think it should be without -oe
<SamB> jelmer: there's a link like that too
<SamB> which actually works
<SamB> what configuration does mwh use to generate this ?
<jkakar> Is there a reason 'added', 'modified' and 'unknowns' are hidden commands?  I use them all the time and only just noticed that they're hidden commands (as a result, they don't tab complete).
<jfroy> jelmer: If you pinged me back, I couldn't see your message as it went past the scrollback buffer. But I just wanted to let you know your bzr branch has been working pretty well, even though push still seems to not work quite right for new branches.
 * SamB wonders why the files in doc/developers don't seem to be set up to activate rst-mode in emacs ...
<jelmer> jfroy: hi
<jelmer> jfroy: Ah, cool
<jelmer> jfroy: Can you elaborate on "seems to not work quite right" ?
<jfroy> bzr was unable to create a new branch, even with --create-prefix. I had to use svn mkdir to create the destination directory, then push --overwrite
<jelmer> jfroy: hmm, odd
<jfroy> creating a new branch -> push a bzr branch to svn
<jelmer> jfroy: --create-prefix would only help if one of the parent directories of the target branch didn't exist yet
<jelmer> jfroy: e.g. if you push to /branches/foo and /branches doesn't exist yet
<jfroy> right, which was the case
<jfroy> (new project, pushing its initial trunk basically)
<jfroy> commit.py:593 raised MissingPrefix
<jfroy> (even with --create-prefix, that is)
<jelmer> jfroy: and did creating just /branches and then pushing /branches/foo work?
<jfroy> I didn't try that
<jfroy> I was pushing to <host>/<prefix>/<project name (does not exists)>/trunk
<jelmer> jfroy: please file a bug
<jfroy> Will do, as always :)
<jelmer> jfroy: It looks like this requires a change from bzr as well as from bzr-svn
<BUGabundo> hey
<BUGabundo> need your help again
<BUGabundo> how do I restore the content of an entire folder?
<BUGabundo> system crashed and I last all files in that dir, so need to restore from last bzr commit
<jelmer> BUGabundo: bzr revert <foldername> should create it again if it existed in the last commit
<jelmer> vila: still there?
<vila> jelmer: not for long but yes :)
 * SamB wonders why the heck he still has Python 1.5 installed ... probably Red Hat's fault somehow ...
<BUGabundo1> sorry.. I'm back... second system crash
<jelmer> vila: So, I'm trying to decide whether to add a new object for the fallback credentials
<jelmer> vila: or whether to reuse (and extend) CredentialStore
<vila> I think adding a fallback parameter to the register funcs should be enough
<jelmer> ok, so just "fallback=True" during registration
<jelmer> and requiring the object to provide a "get_credentials()" method if fallback=True?
<vila> sounds reasonable
<vila> now, do we want to allow more than one ?
<vila> if yes in which order are they tried ?
<vila> let's start by allowing only one :)
<jelmer> vila: can't we just allow multiple in the order they are registered?
<vila> and the first returning a credential wins ?
<jelmer> that seems easiest, since we could just walk the registry rather than remember which one was special
<jelmer> vila: yeah
<BUGabundo1> how do I restore the content of an entire folder?
<BUGabundo1> system crashed and I last all files in that dir, so need to restore from last bzr commit
<vila> again, sounds reasonable
 * BUGabundo1 I know repeating is bad :\
<vila> sorry BUGabundo1, I was replying to to jelemer :-/
<BUGabundo1> I know vila
<jelmer> BUGabundo1: bzr revert <foldername> should do that
<jelmer> vila: ok, I guess I should get to work then :-)
<BUGabundo1> jelmer thanks
<BUGabundo1> jelmer it worked. thanks so much!
 * BUGabundo1 is happy to store all ~/ ,conf in bzr
<BUGabundo1> now to file a bug on kdepim
<mdke> hi there. I'd like to branch something and place the .bzr folder and working tree in an existing folder. Is that possible?
<jelmer> mdke: afaik 'bzr init .' will happily do that
<jelmer> alternatively you could create a .bzr directory somewhere else and then move it into the folder
<jelmer> but please file a wishlist bug if you have to do that
<mdke> jelmer: what I'd like to do is to download an existing branch into an existing folder containing unversioned files
<mdke> jelmer: to give you the details, say I download "desktop moin", which is an installation of Moin which I extract into my home directory. I then want to grab a Launchpad branch with some theme files, which are in the same folder structure as the Moin installation, and put them into the Moin installation under version control
<mdke> (without putting other files under version control)
<mdke> dunno if that explanation is clear or not :(
<jelmer> mdke: so have you tried running
<jelmer> bzr init in that directory?
<mdke> jelmer: ok, and after that?
 * SamB wonders why pydoctor takes so long to generate the bzrlib docs ...
<newz2000> what's the best way to handle two projects that are both managed by bzr and you want one to be a subdirectory inside the other?
<newz2000> (the subdir is a library used managed by someone else that my proj uses)
 * SamB supposes it might help if it didn't look at all those tests ...
<mdke> newz2000: I don't know anything about it, but in the absence of another response, I think this is the answer: http://bazaar-vcs.org/NestedTreeProgress
<mdke> newz2000: no doubt someone else will know more though
<LarstiQ> newz2000: lp:bzr-scmproj or config-manager are other options
<newz2000> thanks mdke, looks like what I want when it comes. LarstiQ: I will check it out, thanks
<DawnLight1> hello. would anyone want to help to develop a configure script for a small project?
<LarstiQ> newz2000: ideally, yes, nested trees
<LarstiQ> newz2000: for now, you can of course have a branch as a subdir of another branch, but can't version it at the moment
<newz2000> yeah, my problem is that I use bzr to publish my code for review and deployment
<newz2000> so I do the nested subdir but I have to do multiple pushes (there are actually four different sub-projects managed separately from mine)
<LarstiQ> newz2000: right
<distatica> Is there by chance a bzr version that runs on Python2.3? running redmine on shared host, and they do not have bzr installed. Unfortunately they also only have python2.3 (which is horrible).
<distatica> I can run git which is setup and working nicely, and this is the only thing stopping me from going bzr vs git.
<Odd_Bloke> So I have two bzr branches, a and b.  I would like b to become part of a at a/b.  Is there any good way to do this (I don't care about the time data, and all the revisions in b were committed by me)?
<Odd_Bloke> Rebase?
<jelmer> mdke: just "bzr pull" from the location
<mdke> jelmer: oh!
<jelmer> distatica: I don't think there is one
<jelmer> Odd_Bloke: bzr join?
<distatica> jelmer: I'm trying to compile python2.6 on the server now, I'm hoping that works out.
<distatica> It's really unfair that they don't have a half up to date python distro, but call themselves a host with python.
<jelmer> distatica: yeah, 2.3 is really old
<mdke> jelmer: that's not bad, although it's moved some of the existing folders as conflicts rather than coexisting with them
<Odd_Bloke> jelmer: Will joining a bzr branch into a bzr-svn branch Just Work?
<jelmer> mdke: yeah, that's intentional; if you resolve the conflicts it should deal with that happily
<jelmer> Odd_Bloke: that's the idea
<jelmer> Odd_Bloke: be sure to use a recent enough bzr-svn, other than that it should work fine
<mdke> jelmer: I'll move the non-versioned files back
<mdke> jelmer: thanks for the help
<distatica> does anyone know, if I do all my local commits and then push that to a server, does it keep a record of all my local commits on the server? Or does it just keep the last one before I pushed?
<NfNitLoop> distatica: it keeps everything.
<NfNitLoop> distatica: even if you do merges, every commit to each separate branch gets maintained throughout history and can always be retrieved.
<distatica> nice
<NfNitLoop> which is quite refreshing coming from SVN. :)
<distatica> I got python 2.6 on the server running fine, I hope bzr installs.
<distatica> Perfect, I have bzr :)
<LarstiQ> jelmer: quite the dos on pk-bazaar-commits
<jelmer> LarstiQ: hmm, not sure where that came from
<jelmer> LarstiQ: somebody restarted somethign :-)
<LarstiQ> jelmer: I need to find a way to limit how many messages exim accepts in one connection.
<LarstiQ> jelmer: oom-killer kept visiting exim, until the entire server was unusable
 * LarstiQ babysits it with iptables and atop in the mean time
<LarstiQ> jelmer: woo, smtp_accept_max_per_connection helps
<jelmer> \o/
<lifeless> moin
<lifeless> I just found out that libgetopt++ is packaged :P I wrote that ages ago!
#bzr 2009-04-11
<bob2> haha
<lifeless> I wrote it in 2002, it got package by dato in late 2007 :P
<lifeless> no idea why
<NfNitLoop> Saluton?
<NfNitLoop> durr, wrong channel.
<dfrbn> are there any options for integrating netbeans with bazaar currently?
<dfrbn> (aside from writing a plugin ;)
<NfNitLoop> Last I checked (which, admittely, was a while ago), no.
<NfNitLoop> There *is* an Eclipse plugin.
<NfNitLoop> and the eclipse plugin is modularized in a way that should be mostly reusable if someone wanted to make a Netbeans plugin.
<NfNitLoop> (ie: POJOs and communicating w/ bzr via XML output)
<NfNitLoop> again, all this is a bit dated.  I just use the commandline. :p
<NfNitLoop> dfrbn: are you developing on *nix by any chance?
<dfrbn> NfNitLoop, yeap, entirely
<NfNitLoop> I recently have become fond of a program called 'meld'.
<NfNitLoop> it's a visual diff analizer, but it works with svn and bzr to show you local changes in your working copy.
<NfNitLoop> and resolve conflicts.
<NfNitLoop> I find meld + command-line bzr better than any IDE plugins I've used.
<dfrbn> nice, tks for that, I'll check it out.
<NfNitLoop> hint w/ meld though, for bzr it always wants you to run it pointing at the root dir of your repo.
<dfrbn> right on. I do like using svn in netbeans, I find the ui very comfortable to use
<NfNitLoop> which you can handly do with:  meld `bzr root`
<NfNitLoop> :)
<dfrbn> I'm debating on where to host a project and am leaning to mercurial just cuz of the netbeans integration. But I don't have any experience with either.
<NfNitLoop> I've been keeping an eye on mercurial...
<NfNitLoop> as an openly biased bzr groupie, here are the reasons I stick with bzr:
<NfNitLoop> 1) bzr keeps things simpler.  (without actually lacking features)
<NfNitLoop> 2) bzr-svn is the best svn integration I've seen.
<NfNitLoop> 3) the bzr team has been really responsive to my questions/bug-reports/etc.
<NfNitLoop> Oh, and launchpad.net is pretty spiffy.  :)
<dfrbn> So I could have my own master repo in subversion for the project (which I already do), and  merge my changes into bzr and use both?
<NfNitLoop> dfrbn: Yep!
<dfrbn> agreed on launchpad :)
<NfNitLoop> you can do 'bzr branch' from a svn repo and it is a fully fledged bzr repo.
<NfNitLoop> which just happens to have enough metadata to merge back into a svn repo.
<dfrbn> interesting
<dfrbn> I like the idea of keeping my own master repo
<dfrbn> as long as it's easy to merge back and forth
<NfNitLoop> There are a couple caveats...
<NfNitLoop> SVN can't represent nonlinear history.
<NfNitLoop> so it's best to keep a bzr branch that mirrors svn, then merge (or rebase) onto that, then push that up to SVN to keep things linear.
<NfNitLoop> you wouldn't lose any data doing it another way...
<NfNitLoop> but your svn history would be...
<NfNitLoop> not what svn users expect. :)
<dfrbn> gotcha
<NfNitLoop> (This applies to any DSCM that interfaces with SVN)
<dfrbn> I see. the only kinda distributed one I've ever worked with was a windows email based on called code coop by relisoft. it was actually pretty cool, but that was a long time ago
<NfNitLoop> hopefully you'll find that things have improved quite a bit since then. :)
<dfrbn> :)
<NfNitLoop> the bzr wiki has a great into to different distributed workflows.
<NfNitLoop> let me find it...
<NfNitLoop> http://bazaar-vcs.org/Workflows
<NfNitLoop> heh, easy enough.
<dfrbn> I use subversion at work at am not a fan. Hopefully if I get some experience with something new I can persaude them to switch :)
<NfNitLoop> SVN is exactly what it intended to be -- better than CVS. :p
<dfrbn> haha, that I is true
<NfNitLoop> or, if they're reluctant to switch, you can just push for using bzr to manage branching/merging.
<NfNitLoop> or, if they're very opposed, you can do what I do and just use it without telling anyone.
<NfNitLoop> hehe
<dfrbn> heh. cheers
<Peng_> jml: You should check out ack as an alternative to grep. http://betterthangrep.com/
<Peng_> Oh, uh. The URL used to be a bit less...arrogant. :P
<jml> Peng_: one day :)
 * Peng_ pokes at Google Code.
<Peng_> jml: Only takes 30 seconds.
<NfNitLoop> Peng_: oh, cool, I'm so installing that at work.
<NfNitLoop> Our codebase is so... disorganized that I *constantly* just grep the entire codebase to see where a function is being called.  :/
<lifeless> don't you have tags ?:P
<NfNitLoop> LOL.
<NfNitLoop> We don't even have /** code docs */
<NfNitLoop> *sigh*
<lifeless> I mean etags -r .
<lifeless> or something equivlaent
<NfNitLoop> aah.  That... might work, but...
<NfNitLoop> our include paths are nonstandard and don't match how things are organized in SVN.
<NfNitLoop> It's all a sad mess.
<NfNitLoop> But it pays well and looks good on the resume. :p
<Peng_> For searching a *lot* of data, ack is probably slower than grep, since it's Perl.
<Peng_> It's smart exclude rules usually make up for that, and anyway, it's usually fast enough.
<NfNitLoop> I don't mind waiting 2 more seconds if it takes me 2 seconds less to type out the command. :p
<Peng_> Right.
<Peng_> jelmer_: ping
<lifeless> jelmer_: gimme a shout when you're around re bug 185200
<ubottu> Launchpad bug 185200 in bzr-svn ""database is locked" bzr internal error" [High,Triaged] https://launchpad.net/bugs/185200
<lifeless> svnvie damage...
<lifeless> clicking on a dirname - contents, filename - log activity'
<lifeless> dirname revno - log activity, filename revno - contents
<fbond> Hi.  I've seen some odd conflict representations using bzr-rebase.  With normal merges, the conflicting areas in the file are always well-constructed.  If I remove one side of the conflict, the other fits back into the context the way it should.  But I've seen some conflict representations with bzr-rebase that would result in dropped lines if I remove one side of the conflicting area.
<fbond> Is this a known issue?  I'm having a hard time characterizing it completely.  I'll probably have to spend a bit of time experimenting to reproduce it.
<jelmer> fbond: bzr-rebase basically does a set of "bzr merge -c" commands
<fbond> jelmer: Does it sound like what I'm saying would have any validity at all?
<jelmer> fbond: oh, the situation you are seeing might be correct
<jelmer> fbond: but inherit to the way rebase works
<fbond> jelmer: As in rebase is unable to get it right due to the nature of what it is doing?
<jelmer> fbond: it can get it right but you're seeing the conflict of one of those cherrypicks, not of the whole rebase operation
<fbond> Right, I see these conflicts along the way as I rebase several revisions.
<fbond> The conflict is correct, but the textual representation of it is missing lines on one side or the other.
<fbond> jelmer: I'll see if I can produce a good example and create a bug report, I guess.
<jelmer> fbond: yeah, it's much easier to talk about a specific situation
<ElMonkey> hola
<ElMonkey> anyone got some tips for installing loggerhead on debian lenny?
<ElMonkey> i am currently failing to grasp the process
<SamB> isn't that, like, stable or something now?
<ElMonkey> there's no loggerhead package in stable apparently
<ElMonkey> quite possibly i am overlooking something, though
 * SamB always uses testing
<ElMonkey> my sysadmin skills are a bit rusty
<ElMonkey> also, as this is a remote machine i am trying to get things to work on, i'd rather not nuke it
<ElMonkey> i just thought things would be simpler
<ElMonkey> but alas, looks like there's no way without jumping hoops
<vadi2> how can I make bzr delete all ignored files? it seems clean-tree doesn't do that
<LarstiQ> vadi2: clean-tree has an --ignored option
<LarstiQ> ElMonkey: there is no backport?
<ElMonkey> LarstiQ, none that i'd discovered
<ElMonkey> i installed bzr from lenny-backports, but i didnt find loggerhead
<vadi2> LarstiQ: thank you
<jelmer_> ElMonkey: I might upload a backport to lenny-backports at some point
<klbate> Is there some command to make 'bzr push' always run 'bzr sign-my-commits' before pushing?
<klbate> Just so I know before I hack up something of my own.
<jkakar> klbate: I have this http://pastebin.ubuntu.com/149103/ in my ~/.bazaar/locations.conf which makes Bazaar sign my changes when I 'bzr commit'.  Not quite what you're asking for, but it may be a potential solution.
<klbate> jkakar: Yeah, that works too. Thanks!
<klbate> I didn't find anything about those config options in 'man bzr'.
 * klbate puts that in [DEFAULT].
<jkakar> klbate: 'bzr help configuration' has a bunch of useful information, including the details about creating signatures.
<jkakar> klbate: If you haven't discovered them yet, the following commands are very helpful for discovering Bazaar's functionality: 'bzr help commands', 'bzr help topics' and 'bzr help hidden-commands'.
<ElMonkey> jelmer, it would certainly be appreciated, at least by me :)
#bzr 2009-04-12
<obst> hi! If I got a revision 1, 2 and 3, is it possible to remove the changes introduced in revision 2 without affecting rev 1 and 3?
<lifeless> bzr merge . -r 3..2 && bzr commit -m "backout commit 2"
<obst> it removed the changes from third revision not from the second
<lifeless> sorry
<lifeless> 2..1
<lifeless> :P
<lifeless> just uncommit and revert to get back to where you were before my recipe
<obst> hehe
<obst> lifeless, this generates a conflict and still seems not to be what I want: http://pastebin.com/d3a215904
<lifeless> looks like you changed the seond revision line in rev 3 as well
<lifeless> or something like that
<lifeless> it does, in general, work
<obst> here is a better example, I cant get it to work: http://pastebin.com/d44722d64
<lifeless> http://pastebin.com/d2c0e4857
<lifeless> write that to e.g. demo.sh
<lifeless> and run it
<obst> hah! that works, but when I try to nearly the same it generates conflicts
<obst> but Im now confident thet it will work in general, thank you!
<blueyed> If I add a file in a branch and later add the same file to the parent branch/trunk and merge from there, I'll get a "Contents conflict". Is that expected? IIRC I have to "bzr rm" the file in the branch and "bzr mv foo{.OTHER,}", right?
<jelmer> blueyed: yes
<jelmer> blueyed: the files have a different identity
<jelmer> blueyed: also see "bzr ls --show-ids"
<jelmer> if you add them with the same file id they won't conflict
<blueyed> jelmer: thanks. Well they got added to the trunk already.. the "--file-ids-from" option is new to me, but would not have helped, since trunk gets auto-converted from CVS. I guess it's not possible to fumble with the file-id in the current state? It's not really an issue, but thanks for explaining it to me.
<jelmer> blueyed: no, it's not currently possible to do anything about that
<jelmer> I hope we can come up with a solution to that problem ("parallel imports" is what it's usually called) at the next sprint
<OllieR> Hey I am setting up a bzr repo for my personal and public projects. Private will only be read/writtable by myself by public will be readable over web (served by apache) at writtable by certain other people. What is the process for setting up bzr permissions. Is it just a case of setting up users/groups as required. Will I have any problems if i do the bzr init-repo using my own account?
<OllieR> there seems to be a lack of documentation around
<pygi> OllieR, can you run a custom daemon or is that too much to ask? :)
<OllieR> pygi: please elaborate..
<pygi> OllieR, do you have powers oj
<pygi> on the server to run a daemon?
<OllieR> powers oj, you mean root?
<OllieR> it is my server I have full control...
<pygi> well, actually no :P Any home account will do :)
<OllieR> ok so what are you suggesting?
<pygi> ok, moment :)
<OllieR> ok col
<pygi> OllieR, http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
<pygi> OllieR, note: bzr 1.12, it doesn't work with 1.13
<pygi> (on server side)
<OllieR> ok interesting idea
<pygi> Its still a bit rough, but I'm on it
<OllieR> is this your brainchild?
<pygi> nop
<pygi> but since its not really maintained properly, I talked with the creator about some things I want to do, and I'll change quite some things in there
<OllieR> interestante
<pygi> first things first, I don't like its security aspect
<pygi> it needs to be more flexible =)
<OllieR> good luck with it looks interesting
<pygi> OllieR, looking at it like this, do you have any feature requests? :)
<OllieR> support for 1.13 :)
<pygi> ha!
<pygi> indeed :p
<a_c_m1> i have a head checkout thats lost its .bzr folder, what the simplest clean way to make it back into a back into a branch - the added complication is it has local changes
<xnevermore> Hey. I want to use bzr for my web projects. I'm using bzr-upload for deployment. However, I don't want to have to do an upload every time I want to test out my changes. I thought the best solution would be to have a small testing webserver (with php support) to run in my working tree (the same way rails projects have webrick or mongrel).
<xnevermore> Does anyone have any ideas?
<lifeless> that sounds fine
<xnevermore> any ideas for a small webserver to use?
<lifeless> apache?
<xnevermore> that seems a little overkill for my purposes
#bzr 2010-04-12
<lifeless> poolie: quick sanitty check
<lifeless> /usr/lib/python2.6/dist-packages/bzrlib/transport/local.py(484)stat()
<lifeless> that does a 'stat()'
<lifeless> not an 'lstat()'
<lifeless> is it just me or is that nuts ?
<poolie> hi
<poolie> this was discussed a while ago
<poolie> during the review that added it
<poolie> i can see arguments either way
<poolie> consistency vs probably wanting to know about symlinks explicitly
<lifeless> oh, actually.
<lifeless> I think my package version is just a little old
<lifeless> trunk does an lstat
<SmileyChris> i just did a checkout lp:django and realised i should have really used a shared repo
<SmileyChris> is there an easy way to copy a stand alone repo into a shared one?
<lifeless> sure
<lifeless> make a shared repo and move your branch under it
<lifeless> then do bzr reconfigure --use-shared (It hink thats the option - --help will tell you)
<SmileyChris> cool
<SmileyChris> lifeless: thanks
<poolie> lifeless: and you want it to do an lstat?
<poolie> i think that's what i recommended
<lifeless> poolie: trunk does an lstat, and yes thats what I want.
<poolie> generally we want to handle symlinks explicitly/consciously
<lifeless> 2.1.1 does a stat
<poolie> that's slightly surprising, i thought it all landed together
<lifeless> transport.stat is very old
<lifeless> IIRC
<spiv> Good morning.
<AfC> Saw an O'Reilly book on Git. It was very confusing :)
<lifeless> spiv: did you sleep on https://code.edge.launchpad.net/~lifeless/bzr/commands/+merge/23068
<lifeless> ?
<spiv> lifeless: oh right, thanks
<spiv> lifeless: reviewed.  (Spoiler: I approved it)
<lifeless> changes needed ?
<spiv> Suggested a docstring change.
<spiv> Your call on what to do with that.
<thumper> I have a question...
<thumper> if I call b.iter_merge_sorted_revisions(some_rev_id), i.next() is the revision I specify
<thumper> but if I call b.iter_merge_sorted_revisions(some_rev_id, direction='forward'), i.next() is the first revision
<thumper> as in revno 1
<thumper> why?/
<thumper> is it an error
<thumper> or expected behaviour
<spiv> thumper: The docstring does say "forward returns tuples in the opposite order to reverse."
<spiv> And direction='reverse' is the default.
<lifeless> spiv: thanks
<thumper> spiv: ah
 * igc out for a few hours
<lifeless> thumper: hey, can I chat with you for a minute (voice) ?
<thumper> lifeless: sure
<thumper> lifeless: pots or skype?
<lifeless> skype :P
<lifeless> poolie: subunit : http://pqm.bazaar-vcs.org/
<poolie> sounds intriguing...
<poolie> meaning... progress bars? or it now mails back subunit spam?
<lifeless> both
<lifeless> the display is pqm parsing the subunit stream
<thumper> lifeless: do you know of an object that acts like a list, but is fed by a generator and reusable?
<lifeless> uhm
<lifeless> I've written things that are likish that
<lifeless> storm might have one
<thumper> lifeless: it would make my logic much more easy to follow
<thumper> lifeless: and still benefit from not calling a whole history operation
<spiv> thumper: "acts like a list" meaning "indexable"?
<thumper> spiv: no, I mean iterable again
<spiv> Oh, reiterable.
<lifeless> caching iterator
<thumper> yeah
<lifeless> http://code.activestate.com/recipes/576941-caching-iterable-wrapper/
<lifeless> thumper: ^
<thumper> lifeless: yeah, saw it, looks overly complicated for what I want
<thumper> making something simpler
<thumper> thanks though
<lifeless> de nada
<wolfgang00> is there anyway to get bazaar to push changes to a host filesystem? i've tried using bzr+ssh://domain.com but keep getting the error "bzr: command not found" and then ERROR: Connection closed: Unexpected end of message.
<RAOF> wolfgang00: Just drop the âbzr+â bit of that url and you'll be able to push the changes.
<lifeless> RAOF: bzr doesn't support ssh urls
<lifeless> wolfgang00: you can relpace bzr+ssh with sftp
<RAOF> Gah, of course.
<wolfgang00> when i just use ssh: bzr: ERROR: Unsupported protocol for url "ssh://yardbutl@yardbutlerstore.com": bzr supports bzr+ssh to operate over ssh, use "bzr+ssh://user@domain.com".
<lifeless> our network fetching really is choppy :(
<spiv> :(
<poolie> hi spiv
<poolie> welcome back to full time
<spiv> Thanks :)
<lifeless> poolie: theres another hydrazine branch up for you, fwiw
<poolie> heh, that's more cheering
<lifeless> I've tested status='Queued' and it works ok on staging
<lifeless> not flawless, but the web pages don't blow up
<bialix> igc: ping
<poolie> hi bialix
<igc> hi bialix
<lifeless> poolie: I have a fairly big hydrazine change
<lifeless> lp:~lifeless/hydrazine/cron - I hope you'll like it
<poolie> k
<poolie> hi igc
<poolie> i was just merging some of them now actually
<igc> hi poolie
<lifeless> poolie: I'm calling it a day
<lifeless> poolie: if you want to talk this one through with me before I sign off, I'd be delighted to do so.
<lifeless> poolie: btw tomorrow mornign I'll be awolish - popping up to the doctor at sparrows fart
<poolie> wow, interesting
<poolie> let's chat tomorrow afternoon?
<mwhudson> spiv: do you have any ideas on how to test the ssh rekeying thing locally?
<mwhudson> it would be good to test both paramiko against an openssh server and openssh client against conch i guess
<spiv> mwhudson: manually hack REKEY_BYTES in paramiko/packet.py, maybe?
<lifeless> poolie: ok
<mwhudson> spiv: ah, that might work
<lifeless> poolie: I have some personal stuff to organise with you too, this week before the weekend if at al possible
<spiv> mwhudson: it's possible there's something in conch for that too
<spiv> mwhudson: I don't know if it's something either side can trigger
<mwhudson> spiv: ah, i was going to say
<mwhudson> i /thought/ it was a client side thing
<mwhudson> maybe not though
<spiv> mwhudson: maybe Conch gets confused if both sides trigger at about the same time? ;)
<mwhudson> spiv: oh god, if it's that complicated someone else can fix it :)
<mwhudson> although noone will :/
<spiv> mwhudson: heh
<spiv> mwhudson: thinking of concurrency, I happened to see your lp code review about CachingIterator, and you need to be more devious :)
<spiv> mwhudson: I sent mail explaining how :)
<mwhudson> spiv: "don't use it with threading"
<spiv> mwhudson: pfft
<mwhudson> ah i see
<spiv> mwhudson: I don't need no stinking threads to break stuff ;)
<mwhudson> spiv: does thumper's update work better with your code?
<spiv> Haven't seen it, so don't know.
<spiv> If it does better than giving three different answers, all wrong, then that's a start :)
<vila> hi all
<lifeless> vila: hi!
<lifeless> vila: hey, lost+found merges; is that in progress, or just something we've been discussing
<vila> lifeless: still not in progress but my next target once I come back to conflicts
 * mwhudson becomes a little stabby trying to get paramiko to connect to launchpad.dev
<igc> hi vila, spiv
<igc> hi mwhudson
<vila> hi Ian
<poolie> hi vila
<vila> hi  poolie
<mwhudson> igc: hello
<mwhudson> spiv: it's conch
<spiv> mwhudson: \o/
<spiv> mwhudson: I guess the rekeying logic in conch is not carefully unit tested...
<spiv> mwhudson: btw
<spiv> mwhudson: thumper's updated code is differently broken :)
<mwhudson> spiv: what an outrageous accusation
<mwhudson> (both of those!)
<mwhudson> spiv: what are the chances that the hardest part of fixing this upstream will be figuring out how to test it
<spiv> mwhudson: depressingly high :(
<mwhudson> i wonder if it's something as dumb as the server continuing to send the data from the subprocess while key exchange is happening
<spiv> mwhudson: that sounds quite plausible.
<thumper> spiv: what update code?
<mwhudson> what also sounds plausible is that it's time for dinner
<spiv> thumper: your CachingIterator has bugs, see my post to the code review
<thumper> spiv: do you have a solution too?
<MvG> Has Command.pligin_name() been deprecated or something? Doesn't seem to work on my bzr 2.1.1 any more, though it used to in the past.
<mwhudson> spiv: is there any way i can change what options bzr passes to ssh?
<spiv> thumper: no, although simply raising an exception if someone tries to use it re-entrantly would probably be adequate.
<mwhudson> spiv: other than "hack the source dummy"
<spiv> mwhudson: write a plugin to override the ssh vendor implementation, dummy? :)
<spiv> mwhudson: (no)
<mwhudson> luckily i can use .ssh/config for this
<mwhudson> ah "cool" can reproduce with openssh as well as paramiko
<spiv> mwhudson: That's... "good"  :)
<mwhudson> yeah
 * mwhudson files a twisted bug
<poolie> spm, can you answer the mail thread about bzr-email and the hpss chroot?
<spm> poolie: which list?
<spiv> poolie: you me, perhaps?
<poolie> oops, i did mean spiv
<spiv> "you mean me", rather.
<spiv> Obviously it's too late in the day to expect accurate typing :)
<spm> spiv: which should so do a nick change and really confuse people - som april fools ideas just come too late....
<vila> poolie: could you land your 2.2b1 branch into lp:bzr/2.0 ? That would make it easier to track what is in the corresponding 2.2b1 tarball
<poolie> do you mean into bzr/2.2?
<vila> poolie: what ? You still can't parse my typos ? :-/ Yeah I meant lp:bzr/2.2 of course
<poolie> vila, sure, i'll try to do that soon
<vila> poolie: thanks !
<bialix> hi all
<igc> hi bialix, spm
<bialix> hi igc
<bialix> igc: I think I also need CRT90 redistributable?
<bialix> igc: I don't trust the tools that I don't understand
<igc> bialix: yes, you'll need that
<igc> bialix: do you have VS 2008?
<igc> bialix: http://www.py2exe.org/index.cgi/Tutorial#Step52
<bialix> igc: no, I haven't
<igc> bialix: thei nstaller code tries to implement that process
<igc> installer
 * bialix reads
<igc> bialix: http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en
 * bialix starts to think using buildout is not the best idea
<igc> bialix: my feeling is that buildout is not the best fit here - wget + bzr would be less complex and more reliable IMO
<bialix> igc: maybe I should install VC2008 Express?
<bialix> http://www.microsoft.com/express/Downloads/#2008-Visual-CPP
<bialix> igc: I think my traceback caused by damaged svn-1.6.6.zip file.
<igc> bialix: can you remember why we need pywin32? Was it needed for tbzr packaging?
<bialix> *svn-win32-1.6.6.zip
<igc> bialix: got to run
<igc> delete that corrupted zip and try again
 * igc dinner
<bialix> pywin32 is must have for windows and bzr
<bialix> igc: bon appetit and gnight
<bialix> igc: deletinbg file does not help: I have the same problem again
<millun> hi
<millun> just wondering... what if i use colocated tree model and happen to delete the whole directory?
<jelmer> millun: how do you mean?
<millun> jelmer: if i delete the php project (not intentionally) including the .bzr directory
<millun> i am screwed right? i use bzr explorer. i obviously should PUSH quite often?
<millun> to some remote repository
<jelmer> millun: yes
<jelmer> unless you're using a shared repository that you haven't deleted?
<millun> no, i am not using a shared repository (not quite sure what you mean by that). i come from SVN, u know
<millun> i use "colocated branches"
<millun> because that's what i've learned in the tutorial
<jelmer> millun: colocated branches aren't an officially supported feature
<jelmer> millun: what tutorial was this?
<millun> on the official pages
<millun> lemme look it up
<millun> http://doc.bazaar.canonical.com/explorer/en/guide/processes/starting_a_project.html
<millun> at the very end
<millun> In most cases, the best model comes down to personal preference. In some case though, the colocated branches model is the only choice, e.g. if you want to version control files in a special location (like /etc or a set of web-server configuration files).
<jelmer> igc: hi
<jelmer> igc: The starting_a_project page seems to use the term colocated branches for something different than we do elsewhere
<lifeless> gnight
<cr3> how can I create a branch which only contains code until a specific revision and not the subsequent revisions? the problem is that I forgot to create a milestone at some point for my project and I now need to go back in time to create a bugfix for an earlier milestone
<rubbs> cr3: it's been a while since I've done it, but you can do the branch command with -r rev# it should work
<rubbs> like this bzr branch -r 2.3.1 ./ ./new
<rubbs> IIRC that is. you can do bzr help branch to make sure I got the syntax right
<cr3> rubbs: seems like you got it right, thanks!
<rubbs> np
<Lo-lan-do> Hi all
<Lo-lan-do> I hacked a bzr-gc.sh script (http://paste.debian.net/68592/), does it make you run away screaming?
 * fullermd runs and screams.
<__monty__> How would I go about fixing this bug: https://bugs.launchpad.net/bzr/+bug/45599 ?
<ubottu> Launchpad bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,In progress]
<wolfgang00> is it possible to push files to a remote server? ive tried bzr push sftp:// but i get the error This transport does not update the working tree
<gioele> wolfgang00: use the bzr-upload plugin
<gioele> push will push only the branch-related info, not the real files
<wolfgang00> hmmm. when i use bzr upload i get the message "bzr: ERROR: Cannot upload to a bzr managed working tree:"
<jelmer> wolfgang00: bzr upload is only for non-bzr managed trees
<jelmer> wolfgang00: I mean, it can only update a remote tree without a .bzr directory
<wolfgang00> jelmer: so is there a way to upload to a bzr managed tree? im not entirely opposed to just removing the .bzr folder and not having it managed but its been a nice feature up till now.
<IslandUsurper> wolfgang00, there's the push-and-update plugin
<wolfgang00> IslandUsurper: do i have to then use checkouts?
<IslandUsurper> wolfgang00, no, you just push from one branch to the other, and push-and-update runs `bzr update` over ssh
<jam> vila: if you are still around, /wave
<wolfgang00> with push and update installed i get "This transport does not update the working tree of: ..." still
<IslandUsurper> wolfgang00, it lies
<IslandUsurper> a bug has been filed
<IslandUsurper> but you should log in to the other server to make sure
<IslandUsurper> you can see it say "running ssh bzr update" right?
<wolfgang00> i do not get it running bzr update.
<wolfgang00> it pushes the changes but i have to do update manually
<IslandUsurper> when you do `bzr hooks`, do you have update-after-push under "BranchHooks: post_push:" ?
<IslandUsurper> wolfgang00 ^^
<dougx> How do I delete a branch?
<awilkins> dougx, delete the folder
<dougx> awilkins: thanks
<awilkins> dougx, if it's in a shared repo, the revisions will remain but they will have no accessible tip
<dougx> ok, I see
<dougx> done:-)
<wolfgang00> ok figured out the push and update plugin was not installed properly. thats fixed but when i run bzr push i get the error that ssh cannot find the file specified but it looks like its dropping the ~ out of the location
<matt2000> Hi. I'm trying to upgrade an Ubuntu Jaunty server to Bazaar 2.x. I've added the PPA source to apt, but it's still nto upgrading it. Am I missing something?
<wolfgang00> when i try to push to a remote server i get the error "ssh yardbutl@yardbutlerstore.com bzr update "public_html/testing.yardbutlerstore/" its dropping the ~/ from public_html
<wolfgang00> and i do not seem to have update-after-push under branchhooks
#bzr 2010-04-13
<spiv> Good morning.
<jelmer> moin spiv
<spiv> jelmer: Morning.
<spiv> jelmer: Any thoughts on /foo,bar/baz? :)
<jelmer> spiv: I posted a comment on that MP less than 20 seconds ago
<jelmer> :-)
<spiv> Ooh :)
<poolie> hi spiv, jelmer
<poolie> biab
 * igc out for a few hours
<poolie1> thanks for the bug triage, spiv
<poolie1> the queue was getting a bit long again
<spiv> Not a problem.
<spiv> Do you remember which bug tag we decided on for the content merge hook?  content-merge-hook maybe?
<spiv> Ah, just 'merge-hook' I think
<spiv> Hmm, my IRC log is inconclusive.
<spiv> poolie1: care to make a decision (or flip a coin) on that?
 * spiv goes with 'content-merge-hook'
<spiv> Zero new bugs.  Time for coffee.
<lifeless> spiv: I'd just take them merge, myself.
<poolie1> spiv: wfm
<poolie1> lifeless: the point is to have a name for the feature
<poolie1> it's more than just merging
<lifeless> poolie: I think too many semantic tags becomes a bit counterproductive
<poolie> i don't think every bug needs to have precise coordinates in its tags
<poolie> the original discussion is that we had a few user conversations of saying "you should use that thing like is used for news merges"
<poolie> and it's worth having some name for that
<lifeless> poolie: http://www.rendell.org/pebble/software/2010/02/09/1265756844985.html might be an interesting read for you
<poolie> yes, it is
<igc> me back
<poolie> yay
<poolie> igc i'll see you monday! :)
<lifeless> spiv: your pull relock is +1 from me
<lifeless> spiv: lp barfed on my control mail
<spiv> whee, ok.
<lifeless> OOPS-1564CEMAIL22
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL22
<lifeless> oh wheeee
<lifeless> ProgrammingError: permission denied for relation codeimport
<lifeless> spm: ^
<lifeless> Methinks we has a problem.
<lifeless> mwhudson: / thumper: ^
<spm> I shall arbritarially blame spiv. No reason other than it's been a while, and hence his turn.
<lifeless> I'm thinking more 'uhm is all mail merge processing about to go boom' ?
<spm> gawd I hope not - this has been active since the last rollout I believe....
<lifeless> have a look a the oops
<lifeless> doesn't look like a temporal issue
<mwhudson> lifeless: what did your merge proposal do?
<lifeless> mwhudson: review: +1 merge: +1
<mwhudson> lifeless: on which branch?
<mwhudson> is it proposed to merge into a code import branch?
<lifeless> no
<lifeless> spivs bzr pull-relock branch
<lifeless> mwhudson: forwarded you the email
<mwhudson> lifeless: looks like we do have a problem indeed
<spm> still sounds like spiv's fault to me
<lifeless> mwhudson: Yah, I try to avoid the panic button otherwise ;)
<vila> hi all
<spm> hey vila!
<mwhudson> i guess a simple grant select on codeimport will fix it though
<vila> hey spm !!
<mwhudson> i'm confused as to how this is only turning up now though
<spm> lifeless: can you (just being a paranoid sysadmin) easily recreate this to test it works if I run the grant?
<lifeless> spm: sure
<spiv> FWIW, I just voted on a bzr branch proposal a few minutes ago via email with no trouble.
<lifeless> spiv: by no trouble, do you mean 'it has taken effect'
<spiv> lifeless: yes
<spiv> Or at least, the email from LP tells me it did ;)
<mwhudson> oh, i sort of see
<mwhudson> you have to be able to edit a merge proposal to approve it, obviously
<mwhudson> this is the check:
<mwhudson>         return (user.inTeam(self.obj.registrant) or
<mwhudson>                 user.inTeam(self.obj.source_branch.owner) or
<mwhudson>                 check_permission('launchpad.Edit', self.obj.target_branch) or
<mwhudson>                 user.inTeam(self.obj.target_branch.reviewer))
<mwhudson> the third line there blows up
<lifeless> mwhudson: I can edit that proposal, can't I ?
<mwhudson> i guess spiv (and most of us) hit the first couple of lines
<mwhudson> or indeed, the earlier cases of the check in the third line
<mwhudson> lifeless: file a bug?
<lifeless> mwhudson: I don't understand
<lifeless> mwhudson: I can approve it in the web ui
<lifeless> mwhudson: why would I be lacking permission in the mail UI ?
<lifeless> mwhudson: I think you should file the bug, you understand whats going on here.
<mwhudson> lifeless: it's not a failure of permission, per se
<mwhudson> lifeless: it's the check that you have permission hitting a db permission issue
<mwhudson> i'll file the bug
<mwhudson> lifeless: btw, i wrote some code you'll *really* hate today
<mwhudson> lifeless: https://pastebin.canonical.com/30468/
<lifeless> as opposed to every other day ? :>
<C-S> Does anybody know how to get the download links from launchpad such as launchpadlibrarian.net/xxxx
<C-S> ?
<C-S> I am searching for the correct link to download bzr-gtk
<lifeless> C-S: hit the web page
<C-S> lifeless: I know I could do that :-) but I need the link for implementation in the FreeBSD port system
<lifeless> C-S: FreeBSD should learn to follow redirects :)
<lifeless> C-S: I'm not being facetious or difficult - thats really the issue.
<C-S> lifeless: anyhow. I am not sure if it does :-)
<lifeless> Uhm, wget -S of the url you see in the web page should show you the redirect info
<C-S> lifeless: cool. I should maybe try both ways. to be honest, the redirect link would work
<lifeless> mwhudson: so, as I read that, 'if its an import push by copying packs' ?
<mwhudson> lifeless: yeah
<C-S> lifeless: but its more comfortable like this. Thanks a lot
<lifeless> mwhudson: so, uhm, I think this needs some pretty significant justification. And a bug in bzr related to that code bidirectionally, *at a minimum*.
<mwhudson> lifeless: and copy_tree_to_transport doesn't work when the source is an http transport
<mwhudson> lifeless: well, part of the justification was dependent on whether it helped
<lifeless> mwhudson: its also buggy
<mwhudson> (and i now know that it does)
<mwhudson> lifeless: i'm not surprised
<mwhudson> so yeah, i'll send an email/file a bug tomorrow
<lifeless> to make it less buggy you need to:
<lifeless>  - take the pack names lock
<mwhudson> lifeless: the basic story is that 2a fetch is slow
<lifeless>  - delete obsolete pack and index files
<lifeless> by less buggy I mean 'wont blow up hugely eventually'
<mwhudson> grabbing the kernel import takes ~an hour on the slave, grabbing it via copy_tree_to_transport takes 30 seconds
<lifeless> mwhudson: why are you copying it around at all ?
<mwhudson> because that's how the import system has always worked
<mwhudson> it would be nice to use stacking, but that doesn't work for other crappy reasons
<mwhudson> (that i should probably dig into)
<mwhudson> but!
<mwhudson> tomorrow
<lifeless> I was thinking lightweight checkout
<lifeless> not stacking
<mwhudson> hm, might work i guess
<mwhudson> the puller has the same issue though
<mwhudson> i guess there would be other ways around that
<mwhudson> but really
<mwhudson> tomorrow
<lifeless> ^^
<AfC> I'm trying to follow jam's emails about history-db, and I'm a bit confused. I thought Bazaar's packs were already a database, so I'm a bit vague on how another is helping him?
<AfC> [there is no criticality whatsoever associated with me knowing what he's talking about, but I enjoy following the engineering discussions here and learn from them]
<spiv> Horses for courses, AIUI.
<spiv> I haven't yet looked closely enough to give you a more informed analysis than that, though :)
<AfC> spiv: jam's emails are kinda long
<poolie> he tends to be very detailed
<spiv> I figure he writes so much to let me I don't need to read it, because he's obviously checked everything already ;)
<AfC> Isn't it funny that we all write too-long emails (expecting people to follow and appreciate our every last detail), but complain at everyone else having the temerity to write long messages that have detail.
<lifeless> so
<lifeless> bzr's repository is a database
<lifeless> there is a particular query that we have to do a table scan to answer today
<lifeless> jam has been working on a schema to avoid that table scan when answering that query
<lifeless> and doing it as a plugin for more freedom in testing and deploying it.
<lifeless> it may end up part of our core database, or a separate one (partitioning for different write patterns) eventually;
<lifeless> note that its new db content, not a new db engine
<AfC> lifeless: plugin, sure. Adding an sqlite dependency, that seemed a bit odd.
<lifeless> oh, did he? I missed that
<vila> AfC: a key point in the experiment is that it's easier *today* to do range queries
 * AfC could be wrong
<lifeless> uhm, thats likely expediency
<AfC> lifeless: no doubt.
<lifeless> preprocessing graphs for range queries is a well studied problem in the literature
<AfC> lifeless: but on the other hand, you might want to be careful lest that gets too far out into the wild
<lifeless> I don't know if jam looked into that.
<AfC> reputation and memes 'n all that
<lifeless> AfC: I don't follow
<vila> AfC: I share these concerns
<vila> :)
<AfC> "Bazaar is so inefficient they had to turn to sqlite to store their data. Which is yet another format change. God these guys are idiots. And another dependency to boot"
<AfC> all of that is untrue, but we have had a PR problem for a long time
<lifeless> oh
<lifeless> *if* we need a better k-v store, I'd rather use sqlite than roll our own for the sake of it.
<lifeless> and sqlite is really really good
 * AfC has to get going cycling home before it gets too dark
<AfC> see ya
<lifeless> ciao
<AfC> [sorry to run out on an interesting topic]
<spiv> lifeless: so if we're using subunit on PQM now, should we try --parallel as well?
<lifeless> spiv: the machine is old
<lifeless> spm: please confirm balleny's cpu core count
<lifeless> spiv: (we could do --parallel without subunit btw)
<spm> lifeless: 1.
<lifeless> spiv: ^
<lifeless> we could use the EC2 plugin on the canonical UEC cloud
<lifeless> with a little work
<spm> or #cores == #cpus :-)
<spm> ... or bribe me to sneak a pqm instance onto eg wildcherry.... :-P
<lifeless> spm: what would that take?
<lifeless> a VM on there would be fine.
<spiv> Ah ok.  For reason I had misremembered that our PQM had more than that.
<spiv> s/For/For some/
<lifeless> spiv: I think the new LP pqm box doth have it
<spm> lifeless: joke. not  going to happen. LP main DB server? I think not. :-)
<spiv> lifeless: and a crushingly slow test suite to match!
<lifeless> spm: go back far enough ....
<spm> spiv: is *that* your fault then?? (still trying to pin blame on teflon-spiv here...)
<lifeless> spm: yes, I believe spiv did the first commit to launchpad, so its clearly all his fault.
<spm> we have a blame
<spiv> I did?  I guess it's possible...
<lifeless> spiv: your previous flat; a demo with the basical url dispatch and what was that orm again
<bialix> hi all
<spiv> lifeless: that does ring a vague bell, yeah...
<spiv> lifeless: a long time ago :)
<lifeless> in a flat far far away!
<edgimar> If I have checked out a branch via "bzr checkout --lightweight", how do I get the revision that the directory is currently associated with?
<edgimar> revno just gives me the lastest revision of the branch from what I can tell.
<edgimar> (which isn't necessarily the revision associated with the files currently in my local directory.)
<lifeless> bzr revision-info --tree
<edgimar> lifeless, ok thanks.  I wonder why it needs to be so complex -- I would intuitively like "bzr revno" to do that for me, but oh well...
<lifeless> edgimar: well, one of the two has to be the default :)
<edgimar> I should be able to find out the latest revision just by 'bzr log' -- or there could (should?) be a 'bzr latestrevno' command.
<vila> hey bialix
<vila> edgimar: 'bzr revno' *is* the latest, using an option or using a different command anyway...
<bialix> heya vila!
<vila> edgimar: when the tree and branch revnos disagree bzr is generally issuing a warning about using 'bzr update', did you encounter a case where it didn't ?
<edgimar> vila, right - I wan't it not to be the latest, but to be "my current".
<vila> edgimar: as lifeless said, one of them should be the default and I think there are more cases where you want it to be the branch one, so use --tree
<awilkins> edgimar, bzr qlog has an indicator on the log list where the tree is at
<vila> jelmer: ping
<edgimar> awilkins, ok - good to know.
<edgimar> awilkins, is qlog a standard command in bzr?
<bialix> edgimar: no, it's from QBzr plugin
<edgimar> one other question: how do I update to a specific revision number?  it seems that "update" won't work for this?
<edgimar> ok found it - revert.
<edgimar> If I have a lightweight checkout, though, and I do "bzr revert <filename>", does it change the file to the *latest* revision, or just the revision which you get from 'bzr revision-info --tree'?
<edgimar> Hmm, revert doesn't seem to work at all for lightweight checkouts -- I get bzr: ERROR: Cannot lock LockDir(chroot-47767537201040:///bzrroot/path/to/repo/.bzr/branch/lock): Transport operation not possible: readonly transport
<edgimar> So does that mean that there's no way to switch your tree to a different rev with a lightweight checkout?
<lifeless> edgimar: I thought we fixed that bug
<lifeless> edgimar: what bzr release are you using ?
<edgimar> 2.0.2
<edgimar> lifeless ^^
<lifeless> edgimar: its merged into 2
<lifeless> 2.0.6 shouldhave the fix
<edgimar> ok.
<lifeless> 2.0.5 might have it
<lifeless> it was merged 9th march
<lifeless> if you wanted to test and let me know that would be grand ;)
<edgimar> I can't right away, but perhaps if I have some spare time later.
<lifeless> sure
<lifeless> uhm
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/498409 is the bug
<ubottu> Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,Fix released]
<lifeless> just for your reference
<lifeless> poolie: still around ?
<lifeless> poolie: please pencil a quick call with me tomorrow am :P
<awilkins> Anyone know a good comparision of bzr-svn vs git-svn ?
<jelmer> awilkins: in what sense?
<awilkins> jelmer, In the sense - what features does each support, what are the differences
<awilkins> jelmer, Not especially fussed about performance but it's nice to know
<awilkins> jelmer, e.g. - I've not played with git enough, but from a cheatcard I saw today there's a special command for pushing to SVN but in bzr I know you just push (in general) - that sort of thing
<awilkins> Thinking of using git for a versioned data store for a particular project and realised that I haven't used git beyond playing with it.
<dcoles> Bazaar uses the svn props to you can roundtrip via a svn repository
<dcoles> Which is actually quite nice
<awilkins> Currently I manage my local branches of the sources via bzr-svn, but I thought I should switch to git-svn and dogfood for a bit to gain some familiarity
<dcoles> (though can confuse the heck out of non-bzr people)
<dcoles> I think git initialises a subversion metadata directory on the client side... not sure if it pushes extra stuff to the svn repo
<jelmer> dcoles: no, it doesn't push extra stuff to the svn repo afaik
<lelit> hi all! I'm back on my svn->bzr switch... I was using "bzr branch https+urllib://..." for my tests; to move faster, I got a local copy of my svn repos, so I thought there was a "bzr+svn://local/path"... Is there?
<lelit> I got the thing with "svn+ssh://localhost/", but maybe I'm missing an even better way
<lelit> doh, bzr does magics :)
<lelit> branch file:///local/path works as (un)expected :)
<jelmer> lelit: hi
<jelmer> lelit: yep :-)
<lelit> jelmer, is there a trick to get just a subtree with that url?
<lelit> I mean, I get an error trying "branch file:///repos-path/branches/interested-in"
<jelmer> lelit: what error?
<lelit> ERROR: Not a branch: "..."
<lelit> uhm, wait
<lelit> jelmer: ignore that, sorry
<edgimar> lifeless:  I checked the problem I had before with bzr 2.1.1, and it still occurs (same error).
 * awilkins is being driven mad by the obliqueness of git
<jelmer> edgimar: I think lifeless is probably asleep (he's in .au)
<edgimar> jelmer, ok- I guess he'll see it sometime - I'll check back later...
<AfC> awilkins: I observed in here the other day that I saw the Git book from O'Reilly ... and that it was very confusing.
<vila> jelmer: ping
<vila> jelmer: lowering the alert level about using name=name instead of name, it was due to an overly aggressively blind local patch to bzr-loom,
<vila> jelmer: the remark still stand though, since you're adding a keyword arg than can be None, better use the name= syntax to avoid breakage
<jelmer> vila: I agree it's a good idea to use name= anyway
<vila> jelmer: cool :)
<abadger1999> jelmer: I've updated https://code.launchpad.net/~toshio/bzr-gtk/handle-dirty-patches/+merge/18856
<abadger1999> jelmer: But the web ui hasn't updated yet and I'm seeing problems with the branch. (bzr log traceback)
<jelmer> abadger1999: hi
<abadger1999> jelmer: Let me know if it gives you problems when you review it.
<jelmer> abadger1999: thanks
<abadger1999> jelmer: Sure, not a problem.
<jelmer> abadger1999: I see only one revision as well
<jelmer> abadger1999: I guess there should be more?
<abadger1999> jelmer: Yep.  If you bzr branch lp:~toshio/bzr-gtk/handle-patch-fix
<abadger1999> The second is present in diff.py
<abadger1999> *second change
<abadger1999> But the branch is definitely not happy (bzr log => bzrlib.exceptions.SyntaxError, bzr diff -r last:1 => ReisionNotPresent)
<abadger1999> You could manually diff against lp:bzr-gtk
<abadger1999> Or I could create a new branch
<jelmer> can you create a new branch perhaps?
<jelmer> I'll promise to review it today
<abadger1999> okay
<abadger1999> jelmer: https://code.launchpad.net/~toshio/bzr-gtk/handle-patch-dirty/+merge/23330
 * abadger1999 submits bzr bug for the corrupted branch
<jelmer> abadger1999: thanks and thanks :-)
<abadger1999> :-)
<vila> abadger1999: you're toshio !!!! I would have never guessed :-/
<abadger1999> vila: Hehe :-)  Yeah, we need and irc nick::name mapping :-)
<vila> abadger1999: indeed :) It's already hard to map nick <-> face :)
<jelmer> abadger1999: I'll have a look in an hour or two
<abadger1999> jelmer: Thanks.  No hurries -- I'm just processing my downstream bug queue :-)
<jelmer> abadger1999: :-)
 * jelmer wished launchpad supported recognizing merges based on patch contents rather than revids, that would make +activereviews really useful for this sort of thing
<jam> vila: still around?
 * vila cries in log code :(
<vila> morning jam
<jam> hey vila. I think I responded to your request for history-db info. I'd be happy to chat more directly about it.
<jelmer> vila: btw, thanks for that --strict fix
<vila> jam: reading
<vila> jam: sorry EOD time has come, I promised :-/ So, roughly: my feeling is that you should either: 4) profit for lp and loggerhead OR keep hammering until you get something that can be backported
<jam> so I think 'hammering until backported' should block on me finishing the rework of PackCollection
<jam> and possibly the annotation cache
<vila> the later means an incremental merge sort at a minimum (if I understand you correctly) based on gdfo or anything else (I don't care that much :)
<vila> jam: yup
<vila> jam: I think the plugin is already worth deploying for lp/lh
<vila> jam: by the way, I fixed a typo:
<vila> jam: http://paste.ubuntu.com/413761/ my revno is 90
<jam> I don't make typos, the world just doesn't know how to spell consistently with me :)
<fullermd> Wait, vila FIX a typo?
 * vila notes
 * fullermd core dumps.
<vila> LOL
<vila> fullermd: thanks for making my day end in a good laugh, I needed that :)
<jam> fullermd: actually, I would say vila fixes his typos all the time :)
<jam> have a good evening vila
 * fullermd waves at vila.
<vila> jam: I'll try to answer to your mail with more details later or tomorrow
<vila> jelmer: hehe, in fact I high-jacked your bug, we discussed it far before and I thought there was a bug for it until you filed yours ;-)
<durin42> jelmer: hi
<durin42> jelmer: gotta get legal approval for contributing to another project, will take me a couple of hours depending on latency there
<cody-somerville> I'm doing a bzr pull and its causing bzr to crash with TooManyConcurrentRequests
<fullermd> That error is usually a knock-on from something else...
<cody-somerville> yes indeed
<cody-somerville> odd
<cody-somerville> 'bzr --pull merge <branch>' works though
<cody-somerville> (it did a pull and not a merge too)
<fullermd> I'm slightly surprised that that works, but merge --pull WILL do a pull if it can.
<cody-somerville> aye
<cody-somerville> just wonder whats causing just plain ol' bzr pull to crash
<__monty__> I'm looking for some help with a bug, this one to be precise: https://bugs.launchpad.net/bzr/+bug/45599
<ubottu> Launchpad bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,In progress]
<jam> cody-somerville: my guess, some plugin you have (like bzr-search) which is trying to do something other than 'just pull', and isn't triggering from 'bzr merge --pull'
<mwhudson> huh
<mwhudson> clicking around http://bazaar.staging.launchpad.net/~mwhudson/linux/trunk/files is reasonably performant
<mwhudson> a pleasant surprise :)
<lifeless> edgimar: yes, its not in 2.1.1 yet
<lifeless> edgimar: we have multiple release branches - 2.0.x, 2.1.x, 2.2.x, for users wanting stability.
<lifeless> edgimar: the upshot of this is that a fix in 2.0.Z isn't necessarily in 2.1.B, for any B - you have to check the date of the releases.
<lifeless> mwhudson: can you land that patch please, I haven't gotten across the new landing procedures yet
<mwhudson> lifeless: sure
<lifeless> mwhudson: also, were there docs I should have updated, that describe the limit to end users ?
<lifeless> mwhudson: could the diff be related to db-devel/devel split ? though only one unmerged revision shows...
<mwhudson> lifeless: i very much doubt it
<mwhudson> lifeless: db-devel/devel, yes maybe
<lifeless> mwhudson: and devel was the right branch to target for this change ?
<mwhudson> lifeless: yes
<mwhudson> lifeless: we do have edge codehosting now, so it makes sense to target devel
<lifeless> ok cool
<mwhudson> i guess that'
<mwhudson> s another reason for some kind of authenticated lp:-resolution: we can direct beta testers to bazaar.edge.launchpad.net
<lifeless> mwhudson: or we could just assign some % to edge
<lifeless> and monitor stats about behaviour
<lifeless> :P
<mwhudson> well, it's been a while since we had a really bad bug in codehosting...
<lifeless> mwhudson: did you review by email ?
<lifeless> or web ui ?
<mwhudson> lifeless: web ui
<lifeless> thanks
<lifeless> one bug fixed, two bugs filed.
<lifeless> its going to be one of those days ;)
<mwhudson> lifeless: so, to continue from last night, i'd like to talk about why i did that packs hackery
<lifeless> ok
<lifeless> did you mean voice when you say talk ?
<mwhudson> no, i think irc will be fine
<lifeless> kk
<mwhudson> basically the problem is the amount of cpu entailed in doing a from-scratch fetch of a kernel-sized 2a branch
<lifeless> right
<lifeless> we validate all the data - process it not dumb copy
<lifeless> we don't do any cross checks
<mwhudson> right
<lifeless> [not expensive ones anyway - we do check that all the texts are present etc]
<lifeless> it also trims unreferenced data, which is important for privacy
<lifeless> if you commit a password, uncommit it, and then push; the password revision must not propogate
<mwhudson> but in my case i really don't care about this
<mwhudson> i just want to move the files from there to here
<mwhudson> because i control the process that produced the branch
<lifeless> why don't you rsync, or copy the entire branch that way
<mwhudson> because, boringly, the branch is accessed over http
<lifeless> the thing that is particularly squicky is copying only some data as a dumb fs operation
<mwhudson> i guess changing that is probably the right thing to do
<mwhudson> then i can use copy_tree_to_transport again, and not grub around in pack internals
<lifeless> I mean, if you say 'hey, I cp -a, which you guys support, and X happens', in the future, we're in a good position to analyse and fix without false starts
<awilkins> I found 2a a lot more cpu-hungry than the previous formats, I really noticed it
<awilkins> Especially the periodic repacks
<lifeless> awilkins: thats interesting; was it also *longer*, or just more intense ?
<lifeless> awilkins: and do you have the C extensions built ?
<mwhudson> lifeless: is there scope to make the checks/filtering faster in the medium term?
<awilkins> lifeless, definitely longer ; C extensions built. Not sure how typical the trees I have are
<lifeless> mwhudson: there is scope to (for instance) preserve intact the packs structure and avoid all compression overhead
<lifeless> mwhudson: however without looking at current profiling data I can't really comment on time to make improvements
<lifeless> mwhudson: nor what scale they would be
<mwhudson> lifeless: over the internet you don't really notice, but over the data centre network or if you use 2a branches without a shared repo, you definitely notice the cpu cost of 2a
<lifeless> mwhudson: how long does git take to do a full scratch clone
<lifeless> of linux, for a head-head comparison
<mwhudson> lifeless: yeah, don't know
<lifeless> git does a similar amount of conceptual work
<lifeless> so a reasonable comparison point
<mwhudson> wow, my isp must have really done something useful recently
<lifeless> ?
<mwhudson> getting ~1 megabyte a second download for the kernel
<lifeless> who are you using ?
<mwhudson> that sort of thing never used to happen
<mwhudson> lifeless: vodafone
<lifeless> wired ?
<mwhudson> adsl
<mwhudson> (2+)
<lifeless> interesting
<lifeless> I'll have to consider staying with them next month
<mtaylor> yup
<mwhudson> oh rught
<lifeless> vodafone NZ seems a lot more sane
<mwhudson> right
<mwhudson> mmm
<lifeless> than AU
<mwhudson> customer support is a bit flaky
<mwhudson> but i don't have experience with anyone else
<lifeless> mwhudson: I was impressed by their forums... where engineers actually post!
<lifeless> with helpful comments!
<lifeless> this is unheard of in .au
<mwhudson> i thought all techy people were on internode in .as
<mwhudson> .au
<lifeless> mwhudson: vodafone are only mobile here
<lifeless> internode are only really wired
<mwhudson> oh right
<lifeless> so yes, I'm with internode :)
<mwhudson> well for mobile you don't get a lot of choice here :)
<lifeless> It would be fun to have international number portability
<lifeless> mwhudson: 3 providers I think, for mobile?
<lifeless> mwhudson: or is it 4 ?
<mwhudson> vodafone (big megacorp) telecom (ex monopoly) telstra (ex .au monopoly, don't have their own network i think) 2degrees (payg only)
<lifeless> hmm
<lifeless> and you chose?
<mwhudson> voda
<mwhudson> i think they are the best choice
<mwhudson> but the customer service is a bit crap
<mwhudson> telecom's network has had some embarrassing outages
<lifeless> clear were pretty good when I was there
<mwhudson> now telstraclear -- probably enough to put anyone who's spent time in .au off? :)
<lifeless> tempting to knee jerk
<lifeless> however as the underdog I'd expect them to actually have to do shit in NZ
<mwhudson> also they don't have their own network, i think they resell voda
<lifeless> mwhudson: for mobile, heh that would be entertaining
<lifeless> mwhudson: for backhaul they should have their own network
<lifeless> they started with the railway country backbone
<poolie> hi all
<poolie> (phone)
<mwhudson> lifeless: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git took 8m24 wall clock and 1m39 user, 25s sys
<lifeless> ok, significantly faster
<mwhudson> yes
<lifeless> so
<lifeless> its worth having a bug open I think
<mwhudson> a local clone took 20s
 * lifeless twitches
<lifeless> mwhudson: for your copy, can you guarantee noone else is writing to the source branch when you make your copy?
<mwhudson> i guess not, strictly speaking
<lifeless> so, you'll need to loop
<lifeless> until your copy and the source mach
<lifeless> match
<lifeless> bzr does this a little more cleverly
<mwhudson> how do i tell if they match?
<mwhudson> sha1 the pack-names or somethign?
<lifeless> same ls -lR
<lifeless> uhm
<lifeless> first approximation is list-and-copy everything; list again, and if its changed copy everything again
<lifeless> as copying is fast we don't expect this to be a problem
<lifeless> particularly as this the exceptional case, not the normal case
<james_w> lifeless: seen http://chasmd.org/ ?
<lifeless> james_w: yes
<lifeless> in discussion with them about collaboration; I think lmirror is substantially more complete at this point
<james_w> looks like it
#bzr 2010-04-14
<lifeless> jelmer: lp:~jelmer/bzr-pqm/fix-branch-root
<lifeless> jelmer: why the rejection?
<jelmer> lifeless: it just fixed the hack that was there, somebody else fixed it properly in the meantime by using the lp API
<igc> morning
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/562666
<ubottu> Launchpad bug 562666 in bzr "2a fetch is very cpu intensive" [Undecided,New]
<poolie> hi igc, still here?
<igc> hi poolie
<poolie> Dirk might be willing to do x64 builds (see mail)
<poolie> that would be cool if it works
<igc> poolie: it certainly would
<igc> poolie: I'll reply to Dirk later today
<poolie> cool, i thought you would, just wanted to make sure you saw it
<igc> poolie: yep, I did
<johnf> can someone remind me how to add an existing branch to a shared repository?
<fullermd> You mean reconfigure --use-shared?
<johnf> fullermd: thankyou
 * igc out for a few hours
<mtaylor> bzr: ERROR: exceptions.ImportError: cannot import name XMLSerializer
<mtaylor> aroo?
<spiv> I haven't seen that for a while.
<spiv> IIRC it has been due to installing bzr on top of an older installation without first cleaning out the .pyc files.
<spiv> If that's not the issue, then more details please :)
<krobertson> anyone know of some good documentation for bazaar's python API?  need to write some stuff that programmatically queries a repo
<mtaylor> spiv: GREAT.
<mtaylor> spiv: well. that would fix the activity
<lifeless> krobertson: our pydoc is ok
<lifeless> krobertson: for specific use cases we generally advise people to look at the code in builtins.py
<krobertson> lifeless: thanks, I will check that out
<spiv> spm, lifeless: pqm has (I assume) failed my branch twice, but has not sent me a failure email
<spm> spiv: Ahh I think I know why - and it's likely your fault. again. ;-)
<fullermd> It doesn't want to hurt your feelings...
<spm> spiv: smtplib.SMTPSenderRefused: (552, '5.3.4 Message size exceeds fixed limit', 'pqm@bazaar-vcs.org') <== I haven't yet had a chance to chase down tho
<spiv> spm: erk
<spm> that's a *guess* mind. but I've noticed 2 of them...
<spiv> spm: that would be because of the log of the failing test run, I suppose :(
<spm> spiv: 8.30 last night; and 11.05 this morning. Sound about right?
<spiv> Yep.
<spiv> Any chance you can send me the most recent one manually?
<spiv> How big is the offending message, do you know?
<spm> I suspect they get dropped; but the pqm log for it may exist...
<spm> spiv: ~spiv/bzr/diff-relock ?
<spiv> spm: right
<lifeless> spm: oh, can we get that limit raised ? :)
<spm> lifeless: I suspect so. :-) submit an RT? it'll be a GSA task.
<spm> spiv: https://chinstrap.canonical.com/~spm/patch.1271201969.log.gz
<lifeless> spm: how big is that unzipped ?
<spm> lifeless: 44Mb
<lifeless> woah
<lifeless> hmm
<lifeless> we may want to strip passing tests sooner rather than later.
<spiv> spm: thanks!
<spiv> lifeless: yeah
<lifeless> thats a pqm tweak
<spm> lifeless: afaict, something changed around the 2d of April (~ 3K gzip) and the 6th 22K, and later on the 6th, was 44Mb.
<lifeless> spm: subunit detailed streams
<lifeless> spm: we're getting much more data about errors now
<spm> ahhhh
<spm> wasn't sure if know change; or not. coolio.
<spiv> Not to mention much more data about successes ;)
<spm> known*
<spm> heh
<lifeless> spm: sent to launchpad at rt.c.c
<spm> ta
<lifeless> spm: which I'm told makes an instant right-queue task
<lifeless> spm: is pjdc an appropriate naggee for this ?
<spm> lifeless: not atm unless super zomg critical
<lifeless> spm: we shouldn't leave errors getting blocked for long
<spm> Erik's the current VG, so our mornings.
<lifeless> theres no vg listed atm ?
<spm> he finishes around midday I believe
<spm> 11. close enough. DST changes.
<lifeless> ok
<lifeless> so I want to make sure this is changed before 5pm - or whever you clock off
<lifeless> its my fault its been left like this :(
<poolie> lifeless: re bug 562079
<ubottu> Launchpad bug 562079 in bzr "incorrect warning after update" [High,Confirmed] https://launchpad.net/bugs/562079
<poolie> is this actually a regression, ie something that used to work?
<lifeless> poolie: I'm pretty sure it is
<poolie> also, please put a meaningful subject line on
<poolie> "incorrect warning after update" could mean almost anything
<lifeless> I think the rearranged update code is picking up some noise
<lifeless> poolie: I do try to put meangingful subjects
<lifeless> poolie: I'm sorry that that one isn't meaningful enough
<poolie> np
<mwhudson> is there code for doing the moral equivalent of ls -lR on a transport somewhere already?
<poolie> iter_files_recursive
<poolie> but it does not directly get the stat values
<poolie> or do you want a human-oriented one?
<lifeless> mwhudson: for http you'll need webdav
<lifeless> mwhudson: to do listing
<mwhudson> lifeless: we can switch away from http
<mwhudson> poolie: thanks, i think that'll do
<lifeless> poolie: on the subject of subjects etc; you seem to remind people a lot; perhaps you could just lead by example and say 'I've changed the subject to XXX which I think is clearer'
<mwhudson> lifeless: for a dump copy, does http://pastebin.ubuntu.com/414067/ sounds vaguely like what you meant wrt ls -lR ?
<mwhudson> mm
<mwhudson> i guess i should sort them
<lifeless> mwhudson: yeah
<lifeless> as a first approx thats simplest and it shouldn't a) infinite loop or b) trigger often
<mwhudson> simple is good here
<mwhudson> lifeless: fwiw, i don't think i've said this yet, this is only for the initial mirror of the branch
<lifeless> mwhudson: sure, you have and I got that ;)
<mwhudson> ok cool
<lifeless> maybe not explicitly but I'm passingly familiar with the problem
<jam> hey spiv... it looks like your _move_index code has higher overhead than we predicted
<jam> I'm profiling loggerhead
<jam> and a bit of code that iterates over 'get_parent_map()' in order to build up the mainline history
<jam> ends up calling _move_* 5k times for the mainline
<jam> which ends up taking 3.7s of runtime
<jam> I can reproduce it by just using "branch.revision_history()"
<jam> certainly something we usually avoid, but still, 5k get_parent_map() calls shouldn't end up costing 3.5s of wall-clock time
<jam> one possibility...
<jam> hit_names is a list
<jam> and you do "for name, index in X: if name in hit_names"
<jam> which means that if you have 20 indices
<jam> and all are hit
<jam> you end up doing 20x20 lookups, rather than 20x1 lookups
<jam> I'll poke a bit
<jam> changing it to a set didn't really help
<jam> changing it to only _move_to_front every 10th call to iter_entries did
<jam> (dropping total time from 3.5s => .35s...)
<jam> found a better fix, at least for my use case
<jam> if the given indexes are already at the front, skip trying to reorder
<jam> happens 5138 out of 5153 times
<spiv> jam: ah, nice
<jam> I think this is bug #562429, btw
<ubottu> Launchpad bug 562429 in bzr "performance regression for 'log' in trunk?" [High,Confirmed] https://launchpad.net/bugs/562429
<jam> but haven't actually looked at the bug close enough yet.
<spiv> jam: yeah, I just guessed that :)
<jam> I'm not sure about the hit_names being a set vs a list
<spiv> "if the given indexes are already at the front, skip trying to reorder" sounds good to me.
<jam> I *think* a set is better
<jam> but since the real improvement is to just skip
<jam> I'll leave that code alone for now
<spiv> Yeah.
<spiv> Or to rephrase: "if no accessed index was a miss, then don't reorder."
<spiv> How common is it (in your use case at least) that iter_entries doesn't look at every index in self._indices?
<jam> https://code.edge.launchpad.net/~jameinel/bzr/2.2-move-to-front-if-changed-562429/+merge/23371
<jam> spiv: so I'm iterating the mainline
<jam> I may hit a few of them on the way back
<jam> but the last few thousand are all in the same index
<spiv> I'm thinking that iter_entries could note how many it looked at, and tell _move_to_front, so that _move_to_front can avoid touching the last half if only the first half needs to change.
<jam> spiv: something like that could be worthwhile, but the above fix is pretty trivial
<jam> and solves my prob completely
<jam> to give an impression, my '.rix' has 1.3MB as the largest, next is 120k, 88k, 6x40k, 4x4k, 8x1k
<jam> So orders of magnitude each, and I'm guessing 90% of my query is that first index
<jam> spiv: alternatively, your iteration loop could see once all hit_names have been found
<jam> and stop the loop
<jam> wouldn't that do the same?
<spiv> jam: which loop?  The one in _move_to_front_by_index?
<spiv> The loop in _move_to_front_by_name would benefit from that, but I don't think that alone would benefit as much as your current fix.
<spiv> I expect most of the cost is in _move_to_front_by_index, not _move_to_front_by_name.
<spiv> Although there is a little bit of repeated effort when _move_to_front_by_name is invoked, because it calls _move_to_front_by_index which constructs the same list comprehension.
<jam> spiv: as an example: http://paste.ubuntu.com/414088/
<spiv> The way _move_to_front_by_index has to zip-then-unzip the self._index_names + self._indices lists doesn't help.
<jam> and yes, the cost is in _move_to_front_by_index according to lsprof
<jam> That avoids the packing and repacking
<jam> well, with a bug
<jam> http://paste.ubuntu.com/414089/
<jam> that should be better
<spiv> Oh, right, yes that approach would be a little better.
<jam> anyway, *my* fix avoids calling all the siblings entirely
<poolie> lifeless: oh good idea re commenting on the bug
<spiv> Right.
<poolie> hi jam
<jam> hi poolie
<jam> spiv: it would be nice to be 'cheaper' in case we don't know about other cases
<spiv> Hmm
<jam> I was also thinking about the 'ordering' issue
<spiv> That's true.
<jam> And iter_entries() should preserve the existing order
<jam> given that is *why* we are bothering to reorder them
<spiv> I don't expect http://paste.ubuntu.com/414089/ will perform worse than the current implementation in any case.
<jam> so if the first indexes are all 'active' then we won't be thrashing the first few for minor improvements
<jam> which my original proposal of "sort by count() of hits"
<jam> could have done
<jam> (though again, in my particular use case, it wouldn't matter)
<spiv> Right.
<spiv> And of course, over the network the relative cost of a little CPU thrashing vs. extra IO looks different to what you're looking at.
<jam> sure
<lifeless> poolie: econtext I think
<spiv> So if we can keep both down reasonably easily, we're both happy ;)
<poolie> from before our conversation, about explaining why i'm retargeting
<poolie> s//resummarizing
<jam> spiv: right. Also, don't all the sibling entries have identical index ordering?
<spiv> jam: yeah :/
<jam> well, good and bad
<jam> it means that if we built a map of where to move them
<jam> we could just apply it multiple times
<jam> however
<jam> the good is that if we know this one is sorted well enough
<jam> then we don't have to worry that we aren't sorting a sibling
<spiv> Right.
<lifeless> poolie: oh right
<lifeless> poolie: and for laughts, a bugfix for the bug we discussed
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/update/+merge/23372
<jam> lifeless: merge: approve
<jam> though there would be potential other cases if you had >1 pending merge and only one of them ended up filtered
<lifeless> right
<jam> but hey, no need to be perfect about it
<lifeless> thats the history analysis or api changes to feed those decisions up the stack that I refer to
<lifeless> poolie: https://code.edge.launchpad.net/~lifeless/bzr/update/+merge/23372 - using my patched hydrazone
<lifeless> *zine*
<jam> spiv: some perf results
<jam> bzr.dev: 2.142s
<jam> my paste w/o shortcut: 1.491s
<jam> shortcut: 1.111s
<poolie> thanks
<jam> shortcut w/ paste: 1.111s
<jam> enough variability to be within the noise with or without the paste
<jam> so... we may want to merge it, as it would have helped
<jam> but the shortcut helps more
<jam> spiv: oh, and the reason I put it in _move_... is because it is called from 2 places
<jam> _iter_entries and iter_entries_by_prefix
<jam> lifeless: what's with the "Status Approved => Queued; Queue Position => 68" message?
<poolie> jam/lifeless: any thoughts on the possibly ip problems in https://answers.edge.launchpad.net/bzr/+question/98657
<jam> poolie: other than saying "I've seen similar throughput issues from launchpad" I don't really know
<spiv> jam: cool, that's about what I'd expect.
<spiv> jam: I think I'm happy for you to merge the paste too, because as you say there might be other access patterns that the shortcut doesn't entirely fix.
<spiv> jam: I'm glad that the results are matching up with our analysis of the problem :)
<lifeless> mwhudson: hey, I beg to differ: '# Looms suck.'
<lifeless> jam: moving towards using the queueing abstraction in lp
<spiv> lifeless: don't beg, just invoke /usr/bin/diff :P
<mwhudson> lifeless: i guess someone should test if that bit is still necessary
<lifeless> jam: I realise the extra mails may be a little annoying, I'm going to beg^Wask for a little patience
<mwhudson> i have this recollection of being extremely angry getting that code to work
<lifeless> mwhudson: and *file a bug* if it is
<mwhudson> (i think weaves broke it too, or something ridiculous like that)
<lifeless> oh
<lifeless> is 2.2 open ? can't seem to choose it when proposing for merge
<jam> lifeless: trunk
<jam> 2.2 is still just a merge from trunk away
<jam> it is just there to make the RM manager's life easier
<jam> well, at least how I used to RM
<jam> speaking of which.. poolie did we ever get pqm happy with your 2.2 tarball?
<poolie> no, still on my plate for today
<jam> k
<jam> night everyone
<poolie> so i should close my mail :)
<poolie> night
<lifeless> jam: I was noting that you merged to 2.2 in pqm
<igc> back
<lifeless> poolie: sorry for the spam messages from me; still learning hotkeys etc
<fperez> Howdy, anyone with a sec to help with a question regarding shared repository formats?
<lifeless> sure, just ask
<fperez> thx1
<fperez> question is: can I find out what the repo format of lp:ipython is?
<fperez> bzr info gives me:
<fperez> Standalone branch (format: unnamed)
<fperez> Location:
<fperez>   branch root: bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/trunk/
<fperez> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/trunk/" and relative path "../../../../%7Evcs-imports/ipython/main/"
<fperez> I need to create a shared repo that I can then push from, but all my attempts end up with
<lifeless> try bzr info -v nosmart:lp:ipython
<lifeless> sorry
<fperez> Using saved push location: lp:ipython
<fperez> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ipython-dev/ipython/trunk/.bzr/)
<fperez> is not compatible with
<fperez> KnitPackRepository('file:///home/fperez/ipython/repo/.bzr/repository/')
<fperez> different rich-root support
<lifeless> try bzr info -v nosmart+lp:ipython
<lifeless> that may work better
<fperez> aha!
<fperez> many thanks!
<fperez> Standalone branch (format: pack-0.92)
<fperez> L
<fperez> That's what I needed :)
<lifeless> fperez: I suspect though
<lifeless> fperez: that the vcs import is in 2a or similar, and that you'll want to upgrade trunk, and your local branches - everything - to 2a.
<lifeless> #launchpad can talk about branch mgmt stuff in more detail. Well we know here too, but that is the right channel :P :)
<fperez> Mmh, let me try the push I was about to make and see how it goes. Back in a sec.
<jelmer> moin
<fperez> lifeless: actually it just worked:
<fperez> amirbar[lp]> bzr push
<fperez> Using saved push location: lp:ipython
<fperez> Pushed up to revision 1232.
<fperez> thanks a lot, you saved me a ton of grief
<lifeless> fperez: ok cool
<lifeless> fperez: glad I could help
<parthm> hello. i am trying to write a test case for bug #413406
<ubottu> Launchpad bug 413406 in bzr "bzr export fail with directory contain non-ascii char." [Medium,Confirmed] https://launchpad.net/bugs/413406
<parthm> http://pastebin.com/sb8hMUU1 the test doesn't seem to throw the exception while doing the same from command line throws the exception
<lifeless> hmm something seems to have broken bzr-search :<
<parthm> do i need to do something differently in the test?
<lifeless> parthm: intersting
<parthm> lifeless: the fix is quite simple actually http://pastebin.com/SS5TKqFw i am assuming bzr uses utf8 internally. is that correct? the only thing i don't have is an automated test :(
<lifeless> parthm: we use unicode internally
<lifeless> parthm: utf8 in some code paths where we have audited it carefully
<lifeless> parthm: if name is the filename on disk we're meant to create, it sounds like the user in that bug has an invalid fs encoding
<lifeless> hmm, bug shows that assumption is wrong
<lifeless> parthm: I've commented on the bug
<lifeless> parthm: you need to use the fs encoding, not utf8, because its a pathname on disk we're setting
<parthm> lifeless: makes sense
<parthm> lifeless: i suppose they fixed it in py3.0 :)
<lifeless> parthm: possibly, but likely not.
<lifeless> parthm: as fo the unit teset
<lifeless> test
<lifeless> try
<lifeless> self.run_bzr(['export', '--format', 'tgz', u'test.tar.gz'])
<parthm> lifeless: yes. that makes the test case work. thanks.
<lifeless> I'd add a comment there that we're tickling a posixpath.py bug and need a unicode argument to do so.
<lifeless> for clarity.
<parthm> lifeless: for fs encoding does bzr provide an api or is os.getfilesystemencoding() the suggested way? i see osutils doing "_fs_enc = sys.getfilesystemencoding() or 'utf-8'"
<parthm> lifeless: good point. will do that.
<lifeless> look in osutils
<lifeless> we do have a wrapper/cache I think
<parthm> lifeless: osutils.get_user_encoding?
<lifeless> no, thats the terminal
<lifeless> _fs_enc
<lifeless> is what is used throughout the module
<parthm> lifeless: will use that. maybe that should be _fs_enc? or exposed via a api?
<lifeless> spell it osutils._fs_enc
<lifeless> for test friendliness
<lifeless> it is exposed through an API :) - osutils._fs_enc
<parthm> lifeless: :) thanks for your help. i will raise a merge proposal for this fix.
<lifeless> cool
<parthm> looks like bzr 2.1.1 was not announced. is missing on the feed on homepage. https://launchpad.net/bzr/+announcements
<maxb> and from the channel topic :-)
 * igc dinner
<lifeless> poolie: is there a way to mute things that are 'to: me' in gmail ?
<lifeless> poolie: (e.g. all lp bug fail)
<edgimar> are there any PPAs which have packages of the 2.0.x release branch in them?
<lifeless> OOPS-1565CEMAIL38
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1565CEMAIL38
<lifeless> mthaddon: (losa) ^ - looks like we're still failing on merge emails
<edgimar> It seems that all of the PPAs listed in http://wiki.bazaar.canonical.com/DistroDownloads don't contain the 2.0.x branch.
 * vila back online and from dentist
<vila> hi all
<edgimar> how do I convert a lightweight checkout to a heavy checkout?
<bialix> heya vila!
<bialix> edgimar: reconfigure
<edgimar> bialix, ok thanks.
<vila> bialix: _o/
<edgimar> bialix, tried 'bzr reconfigure --checkout', and got "bzr: ERROR: exceptions.AssertionError: <bzrlib.bzrdir.BzrDirMeta1 object at 0x24acad0> is not a RemoteBzrDir"
<edgimar> (using 2.1.1)
<bialix> this is a bug
<bialix> edgimar: please, file a bug
<edgimar> how can it be that this kind of bug has not already occurred (or has it?)-- no one else has ever tried converting a lightweight to a heavy checkout??
<bialix> edgimar: I suspect the problem here is that your master branch is not local one
<edgimar> Yes, that is correct.
<bialix> I believe it works correctly if master branch is local one
<bialix> and I think there is even test for the local case
<bialix> just somewhere between here and there something become broken, and there is no corresponding test, so core devs won't noticed it
<bialix> as a workaround you'll need create heavy checkout from scratch :-/
<edgimar> ok fine -- but I guess that for every test which is performed on local branches, it should also be tested on remote branches, right?
<bialix> anyway you'll need to download entire branch history from remote location
<bialix> vila: ^
<bialix> edgimar: in theory -- yes. in practice???
<vila> bialix: you're correct, filing a bug will help find the hole in the test coverage
<edgimar> I'm sure that doing the testing in both scenarios for all tests can be automated/encapsulated.
<edgimar> anyway, I'll file the bug...
<bialix> edgimar: thanks
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.1.0 is out
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | bzr 2.1.1 is out
<bialix> indeed 2.1. is out
<edgimar> But filed at: https://bugs.launchpad.net/bzr/+bug/562896
<ubottu> Launchpad bug 562896 in bzr "crash when converting lightweight to heavy checkout with remote master branch" [Undecided,New]
<lifeless> vila: http://pqm.bazaar-vcs.org/
<lifeless> vila: check the pqm message out :P
<vila> lifeless: even better ! the leading 'success' is new right ? (the running [ x%] was there for a couple of days already)
<lifeless> vila: the success is not new
<vila> lifeless: what is then ?
<vila> the test ids ?
<lifeless> vila: the (lifeless)  and (Parth Malwankar)
<vila> haaa, the *message* ! I had a crash last day and forgot to file the bug after that
<vila> lifeless: where did you fix that ?
<lifeless> hydrazine
<lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/hydrazine/cron/
<lifeless> thumper: why you get up, why do new queued proposals get queu position *68* ? it seems oddly high,,,
<spiv> And highly odd.
<spiv> But also even.
<vila> 2 * 2 * 17, perfectly regular
<lifeless> spiv: even if its highly odd, its still oddly high
<spiv> lifeless: :)
<vila> lifeless: where is this queue coming from ?
<lifeless> lp
<lifeless> vila: if you use my branch and set a message, and submit them, I'll do the signing.
<vila> meh
<vila> you mean your cron job will do the actual pqm submission ?
<vila> is there an url on lp where I can see this queue ?
<vila> lifeless: ^ ?
<lifeless> vila: oh, no.
<vila> not wanting to wake up fullermd by fixing typos but did you mean "it'll do the signing" ?
<lifeless> my gpg key
<lifeless> so 'me'
<vila> lifeless: *I* do a submission and *you* sign it ?
<lifeless> yes
<lifeless> decoupled 'queue' and 'tell pqm'
<lifeless> anyone with review approval permissions can land stuff now, using my hydrazine cron branch
<vila> ha ok, I'm not the primary target. So, that will avoid ready-to-land patches languishing but I'm a bit uncomfortable with automated landing... (I already make mistakes manually :)
<lifeless> vila: its no more automated than what you're using
<lifeless> someone has to say 'land this now', by hand.
<vila> lifeless: ok, I was confused by 'cron', you still need to run feed-pqm
<lifeless> right
<lifeless> you run feed-pqm
<lifeless> and it sets the metadata
<lifeless> then my feed-pqm picks it up and sends the email
<vila> ok, ok, there is a race condition of course but I doubt we run into it soon, may be the patch pilot should be the one to run with --cron
<lifeless> vila: race condition ?
<vila> if two people try to send_mp()
<lifeless> no race
<lifeless> or rather, no worse than bzr-pqm's pqm-submit command has
<vila> lifeless: hmm, in queue_mp(), you have setStatus(status='Approved') followed by setStatus('Queued')
<vila> lifeless: then in send_mp, you check that the mp has already been sent and return early, if two users come here they will both miss the other submission and will both submit no ?
<lifeless> vila: only one person will be running the email mode
<lifeless> vila: so its up to lp to prevent in-flight collisions on the metadata
<vila> lifeless: says who ?
<lifeless> vila: says me
<vila> by email mode you mean --cron ?
<lifeless> yes
<vila> right, then indeed no race :)
<lifeless> vila: try it - run that branch 'feed-pqm bzr'
<lifeless> vila: and submit it
<vila> lifeless: wanna approve https://code.edge.launchpad.net/~vila/bzr/cleanup-log-direction/+merge/23382 ?
<vila> lifeless: trivial
<lifeless> vila: not trivial at all, but I have already approved it
<vila> lifeless: hehe, feed-pqm sees it but lp not yet :)
<vila> lifeless: done
<vila> lifeless: I see the mp status is not Queued on lp, but this can't be set from the web right ?
<lifeless> right
<vila> lifeless: using your branch means I can't submit directly myself anymore
<lifeless> right
<lifeless> thats the point
<lifeless> it is submitted now
<lifeless> in the sense of 'you have done what you need to'
<lifeless> you should not have put (vila) in the commit message though
<vila> lifeless: but I now depend on you before pqm see my submission
<lifeless> yes
<vila> lifeless: meh, I see no code to put it there in your branch
<lifeless> vila: trust me
<jam> lifeless: thanks for the catch on the 2.2 thing. I recently reworked my layout to handle having 3 stable branches, and accidentally did the work in the 2.2 area. So the default submit was the 2.2 branch.
<lifeless> vila: change the message, take (vila) out
<jam> morning vila, /wave lifeless
<jam> just heading to breakfast
<lifeless> jam: moinmoin
<vila> morning jam enjoy it
<vila> lifeless: I can't: Looking for ['Approved'] mps in https://api.edge.launchpad.net/beta/bzr
<vila> Nothing matched status ['Approved']?
<lifeless> vila: you can in the web ui, or by passing --queued to feed-pqm
<vila> lifeless: done
<lifeless> vila: http://pqm.bazaar-vcs.org/
<lifeless> vila: and if you want to see where teh code is - look for the format string (%s) %s (%s)
<lifeless> vila: now, this isn't running fully cronned yet, I need to make a subkey for it or something.
<lifeless> vila: but
<lifeless> vila: It would be good to get other people with code to land to use this
<vila> right, I found the code.
<lifeless> gnight
<vila> lifeless: but I still don't get why you want to introduce a *single* sender (I understand why for people without pqm access), that's just adding another point of failure on top of pqm
<lifeless> vila: refactoring to remove layers
<lifeless> vila: checkout lp:pqm
<vila> jam: Am I the only one *feeling* pqm slower these days ?
<jam> vila: not sure, but the new cron script is certainly making my review folder bloat
<jam> feed-pqm was bad enough
<jam> cron adds at least 1 more message... :(
<vila> killfiles ftw !
<jam> we will now get 7 messages for your cleanup-log-direction, one is your proposal, 2 is your approval, the rest....
<jam> vila: how do you separate out the automated messages about "queued" from the "review: approve" messages?
<jam> anyway, I'll survive
<jam> but certainly I am surprised when I get up and my review folder has 30 new messages
<jam> but oh, only 5 of them mean anything
<vila> jam: I don't kill them but since they are in the same thread, it's easy enough to handle them
<jam> still a 2.5:1 noise to signal ratio
<vila> jam: sure, but... wfm :->
 * bialix feels unhappy too
<spiv> vila: pqm feels much slower for me too, lately
 * vila suspects subunit buffering..... /me whistles
<spiv> vila: random thought: maybe all the verbose subunit details, including log text from passing tests, is part of it?
<spiv> It emits ~44M of stuff now, which stopped PQM sending me a failure message today :(
<vila> spiv: my gut feeling is that the bandwidth is not relevant here but I may be wrong
<vila> wow, 44M !
<vila> spiv: worth a critical bug
<spiv> I suppose it's not too hard to run the experiment...
<spiv> Submit a branch that changes the Makefile to call date before and after the selftest, and then fail.  (i.e. date; selftest; date; false)
<spiv> And then do the same, but remove the --subunit option
<spiv> And then compare the times.
<spiv> Oh, except I'm not sure if sending of failure messages from --subunit is fixed :/
<jam> and hope the load is similar both times
<spiv> Still, I guess you could do the second half of my experiment, and just watch existing PQM jobs to find the time for the first half.
<spiv> Anyway, bedtime for me.
<vila> spiv: you wish ! I'm sure Vincent wants to play with his daddy *now* :)
<jam> vila: well, Vincent slept through the night last night
<jam> I'm guessing he's been asleep for a while :)
<jam> spiv: have a good evening
<vila> jam: how do you know that ? 8-)
<jam> vila: spiv's wife has a baby blog
<jam> http://incrementum.dreamwidth.org/
<vila> Ha yes
<jam> since I have a recent newborn, it is fun to read about someone else's experience
<vila> hehe, yeah, I know the feeeling: oooh, now *they* are in trouble :-D
<vila> jam: anyway, from the discussion above, I guess you don't want me to do a merge proposal for yet another update-copyright cleanup ?
<vila> jam: I'm sure you Approve the idea of pqm-submitting it directly :-D
<vila> jam: more seriously, is there an easy way to use your plugin to check the copyrights for *all* files ?
<jam> vila: I think my plugin has an explicit "don't do everything" check which can be disabled.
<jam> let me check real quick
<jam> one option
<jam> just disrupt the copyright line of every file :)
<jam> vila: run "bzr update-copyright"
<jam> should be enough
<vila> jam: you really want me to resurrect my old perl script ? :-D
<jam> should do a recursive check-everything-and-update
<vila> jam: awesome
<jam> on my bzr.dev it seems to be at about 200 changed, vs 600
<jam> still going
<vila> 355 updated
<jam> $ bzr update-copyright
<jam> Checked 1183 files
<jam> Updated 356
<jam> Already correct 383
<jam> No copyright 444
<vila> 381 already correct, 444 no copyright
<vila> huh ?
<jam> .png .svg, some .txt don't have copyright statements
<vila> we have so many of them ?
<jam> also, I only update specific copyright statements, if they aren't the first line, they don't get touched, etc.
<jam> we have 1200 files
<jam> My guess, though, is the "not first line" thing
<vila> jam: here is the full list: http://paste.ubuntu.com/414352/
<jam> vila: a lot of those look correct
<jam> lots of doc file
<jam> files
<vila> yup
<jam> and 'tools' files
<jam> we have a source check to ensure .py and .pyx inside bzrlib/*
<jam> but not elsewhere
<jam> I'm surprised on the .c .h and _patiencediff_py.py files, though
<jam> ah, not first line
<jam> though the #! line is wrong anyway...
<jam> given there is no __name__ == '__main__' line
<vila> jam: also, http://www.gnu.org/software/hello/manual/texinfo/copying.html says ranges are not allowed
<vila> I don;t remember the details, but I'm pretty sure there is a legal reason behind that (but IANAL)
<jam> vila: meh
<jam> we had that, then we didn't, then we did
<vila> I've read a discussion about it years ago
<jam> ranges look a lot cleaner
<jam> 2005,2006,2007,2008,2009,2010 is getting really long for some of the files
<vila> they sure look cleaner, but lawyers...
<vila> yeah, they say The copyright `line' may actually be split across multiple lines
<jam> vila: well, Martin manually editted some to use ranges, I took that as an opportunity to update the plugin
<jam> I *really* don't want to rehash all 1.2k files now :)
<vila> :-)
<vila> jam: pfff, no need to rehash, what I really like with your plugin is that it updates things without trauma for anyone
<SamB_XP> vila: what about lawyers?
<SamB_XP> they can't really argue that 2002-2009 is any less meaningful than 2002,2003,2004,2005,2006,2007,2008,2009
<vila> SamB_XP: they sometimes do things in a way that makes no sense to me, yet, they have good reasons for that (or not that good, but you get the idea)
<SamB_XP> it's not like it tells you which parts of the code are copyrighted when either way!
<SamB_XP> if you wanna know that you've got to use "bzr annotate" or something
<vila> who knows, some lawyers recently spend some 7 years arguing about who owns  the Unix copyright...
<SamB_XP> vila: that's different
<vila> why ? Because they didn't have a VCS ?
<SamB_XP> there was actually some so-called "intellectual property" that had actually changed hands somewhere in the vicinity of that case
<SamB_XP> ;-P
<SamB_XP> I do admit it is kinda pathetic it took 'em 7 years to settle it
<vila> SamB_XP: I thought they finally agree that "it" didn't change hands :)
<SamB_XP> vila: I meant, the trademark on UNIX has been given to that standards body
<vila> SamB_XP: yeah, kidding, I stop reading groklaw on a regular basis long ago ;)
<SamB_XP> vila: me too
<vila> SamB_XP: But I'm glad it still exists !
<SamB_XP> I only looked at it recently because my mom seemed to think something BAD for Linux had been decided in some case
<SamB_XP> she didn't have any details, so I looked on groklaw and found out that Novell finally won that very day
<SamB_XP> but probably after she'd heard something about the case mentioned on the radio
<vila> yup, typical clash between the broadcast and peer-to-peer models distribute information :)
<SamB_XP> hmm, what was the reason they had to delay the ruling? one of the jury-members had an urgent vacation or something ?
<SamB_XP> vila: well, maybe they were actually talking about what the outcome COULD mean
<SamB_XP> depending on what it was
<SamB_XP> I think my mom said she hadn't been listening very attentively
<SamB_XP> was Novell in no particular hurry to win the case or something ?
<vila> sure, it's easier to re-read a web page than to catch the next broadcast of that news you were listening to with one ear
<SamB_XP> vila: well, you CAN go online and look for the archived show usually
<SamB_XP> or news segment or whatever they call those things
<SamB_XP> it's not like, you know, there are for-profit stations with news on the radio anymore ;-P
<vila> :)
<SamB_XP> at any rate my mom doesn't listen ...
<SamB_XP> ... but in any case, a lawyer who prefers the listing of all years to a listing of ranges is, IMNSHO, just being silly and paranoid
<vila> http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html#Copyright-Notices
<SamB_XP> I'm not even sure why it's helpful to have anything but the most recent years (and lots of places they don't)
<vila> but they don't explain *why* ranges should not be used
<SamB_XP> citing GNU is not a good way to convince anyone that the idea isn't silly and/or paranoid
<vila> the url above explains that they indicate when older versions might theoretically go into the public domain
<SamB_XP> yeah, okay, true
<vila> I don't care that much, it's just that I don't want us to do the bad thing just because we didn't know
<SamB_XP> but they're not useful for determining when any part of the version of the source you're seeing now will be in the public domain
<SamB_XP> anyway, will any of it EVER be?
<vila> enough law for me, back to coding ;)
<SamB_XP> disney always pushes back the copyright expiration just in time, don't they ?
<vila> don't start me on that :)
<SamB_XP> heheehe
<jam> vila: the other reason I didn't run' bzr update-copyright' on everything was to avoid artificially adding 2010 to all the files. Since I don't think updating a copyright line would be considered a valid code update :)
<vila> jam: point taken, end of the experiment :)
<vila> jam:  as said above, I find the workflow implied by your plugin really nice, the only caveat if that merging bzr.dev in a loom tend to trigger updates and I was looking at an rough estimate of files that still needed to be updated
<jam> vila: I wouldn't block it if you want to just run it
<jam> Probably some of the changes are "spurious" in that it is simple formatting
<jam> alternatively do this
<jam> take an old bzr.dev
<jam> merge in a new bzr.dev
<jam> have those files get updated, and submit it
<jam> then it will only touch actually modified files
<jam> you could merge bzr.dev into, say the 2.0 branch
<vila> hmm, that makes me realize that I need to install the plugin on my other dev machine :0
<sabdfl> http://hginit.com/ looks fantastic
<jam> vila: graph.is_ancestor() is probably a really painful way to do it. It is a heads() graph search for every pair...
<vila> jam: I know, but what is the cheap alternative ?
<jam> vila: graph.find_unique_ancestors() or there is another, let me check
<jam> Graph.find_difference()
<jam> I think you want to do:
<jam> interesting_set = Graph.find_unique_ancestors(wanted_tip, [unwanted_tail])
<jam> x = merge_sort()
<jam> for rev in x:
<jam>   if x not in interesting_set:
<jam>     continue
<vila> jam: haa, I searched for something like that but the name didn't ring a bell
<vila> sabdfl: it has mentioned here (or was it the ML)  when it came out, various reactions, summary: except for the graphical (nice) look, our various docs covers the subject but yet another friendly introduction can be tried, people found the humour a bit too distracting
<vila> s/has/was/
<vila> sabdfl: thanks for the heads-up anyway
<sabdfl> sure
<sabdfl> my brother says:
<sabdfl> (16:14:38) Brad Shuttleworth: great marketing for his hg-apps
<sabdfl> (16:15:05) Brad Shuttleworth: the bzr stuff is *really* dry, and is all "you can do almost anything you want" rather than what *i* want to know
<sabdfl> (16:15:16) Brad Shuttleworth: "how should i do it, how does it make my life easy".
<sabdfl> i think he's right
<sabdfl> for 3.0 we need to tighten up the UI, the way we prioritise how people learn about the tool
<sabdfl> our stuff is written from the perspective of people who already love it
<sabdfl> not from the perspective of people coming from svn or cvs
<vila> yeah, I mentioned having a 'what's next' command too for beginners (or even newcomers) that could propose commands based on the state of the current tree
<vila> or interactive tutorials...
<vila> jam: thanks for the heads-up, I did a real-life test (wrong) and didn't notice a bug impact on performance. Redoing it more carefully reveals a *huge* penalty if using only is_ancestor
<jam> vila: yeah, if you had say 100 revs to be displayed, it would be bad
<jam> also, Graph.heads() is O(N^2) IIRC
<jam> so is find_unique_ancestors() but at least you only do it once
<vila> yeah, I wanted to do something like that if needed. It's needed :)
<vila> it's still a bit dirty to calculate the graph difference and iterate anyway, but well.. enough on that
<vila> jam: pushed
<jam> vila: well, iter_merge_sorted can be given a range
<jam> or you are already inside there
<jam> anyway, you still need to sort them
<vila> I am and I need a different stop_rule (hackish)
<jam> vila: on the plus side, bzr-history-db, can
<jam> a) Compute the graph difference cheaper
<vila> :-P
<jam> b) compute only a partial merge_sort
<jam> c) already hooks in there, and just needs to support the new rule
<vila> jam: gimme that in core :)
<jam> vila: respond to my comments off-list :)
<vila> I should... I really should...
<jam> any loggerhead hackers around
<jml> jam, beuno-lunch is probably at lunch, and mwhudson is a couple of hours away
<jml> I know this is probably in a faq somewhere, but why does PQM say that it's the author of the commit to do the merge?
<jam> jml: pqm says it is the committer, which is accurate, I don't think it sets --author
<jml> jam: thanks.
<jam> the primary reason is that we don't send information for pqm to use to set the real committer
<jam> or author
<allquixotic> Hello! Using bzr+ssh, what is needed from ssh to make it so that the root directory when logging in to ssh is the bazaar depot home, so I can check out files with bzr+ssh://my-server.com/my_project instead of bzr+ssh://my-server.com/svr/bzr/my_project ?
<jam> allquixotic: look into the 'bzr_access' script
<jam> in contrib/bzr_access
<jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_access
<allquixotic> jam: that has to be used from the client side?
<jam> allquixotic: you set up bzr_access on the server
<beuno> jml, jam, hi, what's up?
<jam> beuno: trying to get my head around some of the loggerhead code
<jam> specifically "get_view()" does something with a revid and a start_revid
<jam> and I don't quite understand what it is trying to do there
<beuno> jam, without even looking, isn't that to batch the log view?
<jam> well, it seems to play pretty fast-and-loose with which value it uses at a given time
<jam> and pretty much every time I check start_revid == revid
<jam> hmmm...
<jam> beuno: so I'm trying to improve perf
<jam> and I've found some interesting bits
<jam> with my bzr-history-db plugin, and some reworking of History
<jam> I can get to render bzr.dev in about 0.5s
<beuno> I've been following the thread with a sense of shame for not participating
<beuno> wow, that's amazing
<jam> the next bit I noticed
<jam> was that we always walk the full mainline
<jam> but we only end up displaying the last 20 revs
<jam> so I can shave maybe another 100ms by skipping that
<jam> however, I just saw that I lose the "Older>>" and "Newer>>" links
<jam> beuno: do you know what causses those to get showwn?
<jam> ah 'navigation' is the object
<jam> do we actually pay attention to the page_position / page_count anymore?
<jam> I guess it isn't terrible.
<jam> On emacs it is 0.467s vs 0.339s to render that page
<jam> weird, after navigating, it becomes 1.318s
<jam> so if start_revid is set, it slows way down
<jam> and now, even without it I"m at 900ms
<jam> very weird
<jam> i'm guessing a cache is getting filled out and causing gc overhead, but I'm guessing
<jam> ah, I see now
<jam> changes => 300ms
<jam> changes/99865 => 866ms
<jam> changes/99865?start_rev=99865 => 1300ms
<jam> it is being slow on a dotted => revid lookup
<jam> which is a bit weird
<beuno> hm
<beuno> (sorry, in the middle of firefighting)
<beuno> dotted revnos have always been the slow point I think
<jam> I found a bug in my code
<jam> beuno: now changes => 350ms, change/99885 => 350ms, changes/99885?start_revid=99885 => 350ms
<jam> \o/
<jam> bzr-history-db was finding the map quickly, and then continuing to search the rest of history
<beuno> ah
<beuno> jam, the start_revid is also used to diff revisions IIRC
<jam> beuno: so how does loggerhead deal with caching a given branch, and handling the 'stateless' nature of HTTP?
<beuno> lets excersize my memory
<beuno> we use the LRU cache for some bits
<beuno> and fall back to sqlite
<jam> beuno: but you basically instantiate a History object per request, right?
<beuno> yes
<jam> ok
<jam> cause I got rid of both caches in History :)
<beuno> in loggerhead/apps/branch.py
<beuno> get_history
<jam> RevInfoMemoryCache and RevInfoDiskCache
<beuno> ah, heh
<beuno> that's pretty mind-blowing  :)
<jam> all about data-structures
<jam> you have to create ones that match what you want to get out of them
<jam> beuno: loggerhead.zptsupport.expand_into
<jam> that is the take a template, turn it into html code?
<beuno> yes, although that's mwhudson's code, so he can answer with more conviction than me
<beuno> it looks like it
<jam> ok, I was wrong, I had a different bit here
<jam> If I stop iterating history at 100 revs
<jam> things are fast
<jam> otherwise emacs trunk takes 6s
<jam> vs 300ms
<jam> which is why I wanted to stop early
<jam> but it seemed to mess up the page navigation code
<beuno> it needs to know the ranges
<beuno> so maybe you can get $current+1
<beuno> or $current+batch_size
<jam> well, you seem to need to know + and -1 page
<jam> which is a bit tricky to get Newer by 1 page without starting from the 'start_revid'
<jam> but I could start at start_revid, and stop once I've found revid + 1 page
<jam> It means looking at 10k old revisions would be slow
<jam> but I doubt people do that often
<jam> and still faster than today :)
<jam> beuno: the other bit is how to handle the 'merge_points' stuff
<jam> I think I understand the point of it
<jam> but either it is buggy, or I'm actually misunderstanding
<jam> specifically, if I click on a merged revision
<jam> I can sometimes see a link back to the rev that merged me
<jam> but generally not if that revision was trunk
<jam> for now, I've disabled merge_points, because it was the one bit of code that I can't cheaply answer via regular bzrlib apis which bzr-history-db just makes faster
<jam> I'd have to actually query the new db
<beuno> I think dropping that is fine for now
<beuno> it's intersting to navigate up
<beuno> but not crucial
<mtaylor> hey all ...
<mtaylor> bzr: ERROR: exceptions.ImportError: cannot import name XMLSerializer
<mtaylor> happened to me after I upgraded
<james_w> is that the "this revision was merged to the mainline at revision" stuff?
<beuno> james_w, yes
<beuno> and hi  :)
<jam> james_w: morning
<james_w> mtaylor: could you run whatever you did again with -Derror and pastebin the traceback?
<james_w> hi beuno, jam
<mtaylor> james_w: yes!
<james_w> I like that in loggerhead, and would like to be able to query that sort of information in bzr often
<jam> james_w: so right now all revs have a merge_points
<jam> however, it seems buggy in its implementation
<jam> namely, if you click on a directly merged rev, it doesn't seem to show
<jam> for example, expand the first revision here: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/5129.1.3
<jam> It *should* show that it was merged into bzr.dev 5158
<james_w> yeah, I'm fine with losing it for other improvements, but was just piping up to support re-implementing it on top of faster bzrlib APIs that would then make it available in the bzr client :-)
<beuno> jam, but if you go to the revision: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5129.1.3
<beuno> This revision was merged to the branch mainline in revision 5158.
<beuno> and you can click to it
<beuno> which is the interesting bit I think
<mtaylor> james_w: http://pastebin.com/gsd1RQbJ
<jam> however, it is present here:
<james_w> mtaylor: how do you have bzr installed on that machine?
<jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/5080.2.1
<beuno> odd
<mtaylor> james_w: installed from source -it's a centos5 box
<beuno> jam, and yes, feels broken
<jam> beuno: ah sorry, the link is present there is pointing to another merge
<jam> but if you follow *that*
<jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes/4797.33.4
<jam> you can see both arrows
<jam> My guess is something weird with _simplify_merge_points
<jam> james_w: the main prob in bzrlib is that we only have child => parent mappings
<jam> to find parent => child, you have to walk all the revs
<james_w> yeah
<jam> bzr-history-db has them
<jam> and you built them during the 'load_whole_history' step
<jam> which I'm trying to get rid of :)
<james_w> you can answer the question reasonably cheaply using Graph, but not from the cli
<james_w> mtaylor: hmm, something is odd
<mtaylor> yeah
<jam> james_w: so with my current implementation, I can probably answer "what mainline rev merged X" fairly cheaply, but it doesn't scale into merges-of-merges
<james_w> mtaylor: hoe does python -c "from bzrlib.xml_serializer import XMLSerializer" fare?
<jam> does that make sense?
<james_w> yeah, I think so
<jam> would that be a reasonable tradeoff?
<mtaylor> james_w: quite poorly
<jam> it means that when you find the revision that andrew merged into 2.1 and then into bzr.dev
<mtaylor> ImportError: cannot import name XMLSerializer
<james_w> yeah, I'm usually after "does this release contain this revision" type stuff
<jam> you would see when it landed in bzr.dev, but not a direct link to the 2.1 branch
<jam> unless you were looking in the 2.1 branch :)
<james_w> mtaylor: python -c "from bzrlib import xml_serializer" ?
<eday> http://pastebin.com/iZNAaZ5c any quick thoughts/fixes on this error?
<james_w> hi eday
<eday> james_w: hi!
<mtaylor> james_w: that works
<james_w> gosh, when it rains it drizzles
<eday> mtaylor: oh, you're here
<mtaylor> james_w: should I just delete the install on the box and go from scratch?
<jam> mtaylor: any chance you have different versions of python on your path and it is getting confused about ti?
<jam> it
<james_w> mtaylor: I think it's something do to with elementtree
<mtaylor> jam: not that I can find ...
<jam> bad marshal data
<jam> sure looks like something wrong with .pyc files
 * mtaylor deleted all the .pyc files
<mtaylor> oh - hrm
<james_w> mtaylor: can you import elementtree and cElementTree ?
 * mtaylor is very confused - this box was working perfectly and then, all of a sudden, it had bzr 1.14 installed 
<mtaylor> james_w: yes
<james_w> hrm
<james_w> I don't see yet how you can import bzrlib.xml_serializer but not have XMLSerializer in it
<james_w> mtaylor: could you pastebin your /usr/lib64/python2.4/site-packages/bzrlib/xml_serializer.py?
<mtaylor> james_w: very odd - I moved bzrlib out of the way and installed again and now it works
<james_w> hmm, that is odd
<mtaylor> james_w: http://pastebin.com/hfWnFr7G
<mtaylor> james_w: there's what was there
<james_w> aha
<james_w> that's out of date or something
<james_w> for some reason that file wasn't in sync with the rest of your bzrlib
<mtaylor> james_w: so I installed over top of the 1.14 that was there - perhaps setuptools decided to not install some of the bits of 2.1
<eday> jam: the bad marshall data went away with 2.1.1 upgrade. strange thing is it had just stopped working, even after removing .pyc files
<james_w> that seems both unlikely and likely at the same time
<james_w> you are both up and running again now?
 * mtaylor is
<jam> mtaylor: setuptools doesn't delete things that are already there
<jam> and possibly a perms issue for overwritting it?
 * james_w goes back to using your code instead then
 * mtaylor _so_ prefers packages
<jam> beuno: \o/ changing it to number until revid + pagesize +1 worked. It only takes 400ms to show the tip of emacs trunk, but I still get the navigation links
<beuno> jam, I'm almost in tears knowning that you're working on this  :)
<beuno> jam, so, I should reply to igc's thread
<beuno> but my original idea was to make loggerhead a layer to serve anything bzr over web
<beuno> ie, it would always return jsons
<beuno> it would come with a set of templates that renders it and makes it standalone
<beuno> but it can be very well used for a hosting facility of bzr branches that needs to extract information and display on a web ui  :)
<jam> side note
<jam> I believe you always open the branch from scratch each time
<jam> is that correct?
<jam> (It seems to be done in apps/transport/__call__)
<beuno> yes
<jam> Which means that any caching that might have been done at the Branch level would be lost
<jam> which means that my changes will destroy loggerhead w/o my plugin... sigh
<jam> some changes would have done ok, as long as the Branch caches stayed in effect
<jam> slow to start, but decent at N+1 requests
<jam> maybe add an lru cache of branch objects?
<jam> they aren't very thread-safe, though
<beuno> don't we do that already?
<jam> beuno: transport.py BranchesFromTransportServer __call__
<jam> always calls open_from_transport
<jam> BranchWSGIApp was always lock_read and unlock around doing stuff
<jam> which I was hoping to push up higher
<jam> but doesn't really matter if we are getting a completely separate Branch object each time.
<beuno> ah. we stick graphs in the LRU cache
<jam> right
<jam> which is what I'm getting rid of
<jam> in favor of just using Branch apis
<jam> which bzr-history-db was overriding to make fast
<jam> I was hoping to get to the point where I could say
<jam> "you can use loggerhead, and install bzr-history-db as an accelerator if you need it"
<jam> but I'd have to bring back the old code to make that feasible
<jam> and then change the code back to querying primarily on loggerheads cached objects
<beuno> well, if you're code makes such a difference, I think I'd be inclined to include it by default
<beuno> not sure why we wouldn't want that
<beuno> are you using sqlite?
<jam> beuno: atm I'm using sqlite
<jam> the goal was to simplify loggerhead
<beuno> right, so that would make sqlite a dependency
<jam> switch to standard bzrlib apis
<jam> and introduce this new bzrlib accelerator plugin
<jam> which long-term may not use sqlite
<jam> beuno: sure, but loggerhead stores its existing cache in sqlite if you use anything on disk
<jam> I guess the it can run with just in-memory
<beuno> yeah, ot checks for sqlite, otherwise it defaults to not caching outside of the LRU cache
<jam> beuno: sure, though getting rid of the in-memory cache would be a big win for memory consumption...
<beuno> absolutely
<jam> though not that huge maybe...
<jam> I'm seeing 120MB for just emacs/trunk
<jam> and it only goes to 140MB when I get a second branch
<jam> I guess that is vs 30MB, with my code, though
<jam> StaticTuple helping there...
<jam> Peng: /wave
 * jam needs food, bbiab
<james_w> abentley: is there a preferred way to check if your cwd is a pipeline or a plain branch?
<james_w> I get the impression that's not really so much of a distinction with pipelines
<abentley> james_w, plain branches are pipelines with a length of 1.
<james_w> right
<james_w> so what's the preferred way to determine if there are previous pipes for the current branch?
<james_w> cli-accessible that is
<abentley> james_w, create a PipeManager for the branch, and execute get_prev_pipe
<abentley> james_w, from the commandline, run "bzr pipes".
<lifeless> jam: so sqlite is single client
<lifeless> jam: but loggerhead is multithreaded;
<jam> lifeless: sqlite is multi-reader 1 writer
<jam> but the writer is supposed to only block when the 'commit' step happens
<jam> not for the whole transaction
<lifeless> jam: thats not a complete description
<lifeless> http://www.sqlite.org/lockingv3.html
<jam> lifeless: sure, I've read the doc
<jam> We'd have to see the specific impact in practise
<jam> and see how to work around it.
<jam> For launchpad's instance, we could just move the backend db to postgres and not worry about concurrancy
#bzr 2010-04-15
<igc> morning
<spiv> lifeless: for landing lp:~spiv/bzr-pqm/submit-relock, which has 1 new rev, do you prefer a direct push to lp:bzr-pqm, or merge+commit in a checkout?
<poolie> hi spiv, all
<lifeless> spiv: if the lhs ancestry is unchanged I don't care
<lifeless> spiv: besides, its jams code ;P
<spiv> lifeless: ah :)
<lifeless> spiv: are you lunching with us?
<spiv> lifeless: hmm!
<spiv> lifeless: I think I will.
<lifeless> poolie: if you want to tell RAOF spiv and I the alternate venue you have in mind, please do so
<lifeless> brb brekfast
<poolie> lifeless: i don't care where it is as long as it's some specific place
<poolie> the link in your invitation points to 6 different restaurants
<lifeless> poolie: what link ?
<poolie> you sent an invitation whose 'where' link points to the set of all chinese restaurants in st leonards :)
<lifeless> poolie: anyhow, how would you describe the generic asian on the east side of the station
<poolie> now i know what you mean
<lifeless> hmmm, I thought i said 'station' rather specifically
<lifeless> oh no, I didn't
<lifeless> because google calendar failed and I had to retype
<RAOF> I was planning to just turn up at the station in an hour and a half and hang around looking awkward until someone noticed me ;)
<RAOF> Hm.  That reminds me.  Who's got my copy of /A Bit of Fry and Laurie/?  Is it you, spiv? :)
<spiv> RAOF: It is
<spiv> RAOF: I was thinking today would be a good opportunity to return it :)
<RAOF> Superb!
<poolie> :) i like that, but i have my own copy
 * igc out for a few hours
<poolie> igc, do you need anything from me atm re doc builds?
<allquixotic> I am looking for an authentication/control mechanism for bzr that (1) uses PAM for authentication, (2) controls access to individual files by file level permissions (r-w-x), (3) does not require public key infrastructure (but rather uses passwords for authentication), and (4) restrictions directory navigation to files contained in a designated "root directory" (or a subdirectory). ssh+bzr with BzrAccess seems to be applicable
<allquixotic>  on all accounts except (3), and plain old bzr+ssh can't give me (4). Any other options to get all four requirements?
<fullermd> What do you mean by "individual files"?
<allquixotic> fullermd: chmod/chown, basically. native Linux file permissions coupled with PAM's user database provide (1) and (2) exactly, built-in, so anything that hooks into that system (such as ssh) will immediately benefit from it. That's why I'm hesitant to give up bzr+ssh at all, but I don't want to have to pull in PKI just to get the benefits of BzrAccess (namely, (4))
<fullermd> Right, but I mean what "individual files" do you want to control access to?
<fullermd> Are you talking about individual files within a branch?
<allquixotic> in a practical sense, what I'll probably do is have a root directory containing N project directories. Each project directory will be controlled by potentially different people, with o-x permissions so that people who don't have the right user or group can't go snooping in there.
<allquixotic> Everyone should be able to access and view the contents of the root project directory, but not necessarily the sub directories unless I've specifically set the permissions that way.
<allquixotic> which is how linux file permissions work anyway
<allquixotic> but within a given project, I expect all the permissions to be exactly the same
<allquixotic> in practice, anyway
<fullermd> Well, you can do 4 with a chroot, as long as you have enough in the chroot to run bzr.
<allquixotic> yeah, I was thinking of doing that, but I'm not sure exactly what bzr needs to run, and I don't know of a convenient way to capture exactly (and only) the files needed.
<allquixotic> I don't necessarily want to enable these users to login to a bash shell over ssh though, I just want them to be able to use bzr itself for official bzr operations on files within the repository. so for example they shouldn't be able to overwrite a file in the chroot's /usr/bin, or set something executable and exec() it.
<fullermd> Well, python and bzrlib should be enough.  You drag in some extra deps for client-side sftp support, but you don't need that there.
<fullermd> If they have permissions to overwrite files in /usr/bin, chroot or otherwise, you need to rethink your life   :p
<allquixotic> well, true
<allquixotic> i guess the latter part of that sentence is more sobering than the former. so, say, they have rwx permissions within a project directory they own. if they can exec a shell, they can create an arbitrary executable file in there and exec() it. Can they potentially do that with bzr being the command ssh invokes as their shell?
<fullermd> It's very hard to absolutely lock things out.  Hard enough that I always assume it's impossible and work from that.
<fullermd> Probably.  I can dream up ways (at a high level) it could be made to happen, and dream up ways of shutting those doors to prevent it.
<fullermd> But I would never assume I could think of every dodge.
<fullermd> If you can mount all the FSen that are writable noexec, and not have anything that could function as a command interpreter...   nope, too late, there's python.
<allquixotic> Hmmm... this is a problem shared with git. It's just a normal UNIX-y binary on the system, and authentication/network transparency is left completely up to the sysadmin. I really wish there were a way to lock this down as well as 99% of the other services out there. I mean, I don't typically worry about people who can HTTP GET from Apache being able to invoke a shell and exec() stuff.
<fullermd> Well, you could do bzr+http.
<fullermd> But you're still talking to bzr on the server.  If you can manage to get a plugin in place, you could make it do anything.
<fullermd> Only way to absolutely lock it out would be dumb server.  Dumb servers suck though.
<allquixotic> What is the best practice, then? I assume people who connect to Launchpad over bzr+ssh to do their (free) open source commits are in a different group than the list of people Canonical trusts performing arbitrary fork/exec on their servers. So what's the catch?
<fullermd> Launchpad is a whole different ballgame.
<fullermd> It runs a custom ssh server, and talks to a completely virtual filesystem.
<allquixotic> I know, but Launchpad hosts bzr, and somehow they do it in a secure manner.
<allquixotic> oh, I see.
<allquixotic> very interesting.
<allquixotic> that's kind of nice. since Launchpad is (recently-ish) open sourced I guess I could deploy that on my own box and have a more robust system all around.
<fullermd> The code is available, so you could potentially grab those pieces out of it and try working from there if you wanted.
<fullermd> Presumably it would be easier than trying to get the whole thing running, which I understand is a bear.  But maybe not.
<allquixotic> yeah -- actually I wouldn't mind deploying the entire Launchpad on my box. We have a very small dev team (3 people) so I'm not sure how useful all the wiki/bugtracking features would be, but it would be nice to have them.
<fullermd> Yeah, I handle those issues with my co-developers in totally different ways.
<fullermd> Specifically, I know where they live, and I'm better armed than any of them.
<allquixotic> I long to have the project I'm working on open sourced, but unfortunately we're still being bitten by licensed code from the 90s. Long story. Short version: closed source freeware.
<allquixotic> And with not having a budget of $250/year, we can't go launchpad commercial.
<fullermd> With a public system (like LP), you definitely need to lock down hard.  But with a small dev team like that, I'd just rely on them not being retarded or evil (and deal with those cases by a bootoff)
<fullermd> I mean, if they're likely to go to moderately extreme lengths to do something evil, you wouldn't be letting them have access in the first place, neh?
<allquixotic> well, yes, I can definitely trust the two other people who have access to a fairly good extent. I do want to make read-only accounts for testers within the community (who are not developers) but if I'm willing to give someone write access to the source code, I'm also willing to trust them with exec() powers on the system.
<fullermd> Oh, that's plenty easy.
<allquixotic> I guess I was being a little overzealous in that regard, actually. The people who _really_ shouldn't be exec()ing anything on the system will not have access to it at all, except for public http of webpages.
<fullermd> Just setup read-only bzr+http.  Easy peasy.
<fullermd> Assuming bzr doesn't itself have a hole allowing access (hard-to-impossible to prove, but a reasonable base assumption), the only way somebody with RO access like that could do something evil[er than DoS] would be with inside help.
<allquixotic> Perhaps a requirement easier to satisfy, then: instead of (for read/write access) going to a URL like bzr+ssh://user@server.com/path/from/root/filesystem/to/bzr/repos/my_project, how about a way to shorten it to bzr+ssh://user@server.com/my_project ?
<allquixotic> BzrAccess _can_ do that, and so can chroot, but they both have rather burdensome baggage that's part of the game.
 * fullermd shrugs.
<fullermd> I'd just toss in a /repos symlink and call it a day.
<allquixotic> oh, that works... why didn't I think of that :P
<fullermd> Or use home-relative paths, and setup users home dirs appropriately.
<fullermd> bzr+ssh://user@server/~/mybranches/...
<fullermd> (possibly with the two combined; symlinks in the homedirs)
<fullermd> You need a relatively recent version for the ~ over bzr+ssh.  2.1 maybe?  Or was that in 2.0...
<fullermd> 2.1 looks like.
<allquixotic> yeah, I read the release notes mentioning the ~ syntax
<allquixotic> we are using 2.1 so that's fine
<fullermd> Technically, I think that's all server side, so a pre-2.1 client may still work fine as long as the server is 2.1.
<allquixotic> fullermd: Thanks for the help. I'm not at all upset that there isn't any whiz-bang solution to my original query. I might be able to live with the /repo symlink, since I do trust the SSH users after all.
<allquixotic> I needed more conceptual help than technical it seems ;)
<fullermd> I'm always in favor of insane overengineering.  But in general, not always in specific   :)
<AfC> I
<AfC> I'm at a client, where [as I mentioned] I saw the Git book. They're Subversion right now, and going to switch to Git on the strength of:
<fullermd> NGO?
<AfC> 1. perception that more people have Git skills
<AfC> 2. perception that IDE integration (IntelliJ + Eclipse) is better
<AfC> there was no real interest in technical argument about Bazaar's superiority (or inferiority, or anything else). It was really "I can hire guys who already know Git"
<fullermd> Nobody ever got fired for buying IBM.
<AfC> If any Canonical people are in the room, I can pass on the name of this Engineering Manager, but I'm not sure anyone at Canonical is making sales pitches to small medium business.
<AfC> But as a more general comment, it sounds a lot like the "you should switch from {Windows,Solaris} to Red Hat because" that is what RH sales & marketing does for a living.
<AfC> [with some success, I gather]
<AfC> and perhaps we as the Bazaar community are going to need to chip in on a well co-ordinated campaign along the same lines.
<AfC> Said engineering manager also said "VHS vs Beta"
<AfC> which is scary because that meme "justifies" the choice of an inferior product based on perceived market adoption, and I'm VERY worried that's going to get hung on Bazaar
<gregcoit> if I branch lp:/project-dev to ~/project, can I then point ~/project to lp:/project?
<fullermd> What do you mean "point to"?
<gregcoit> fullermd: I'd like to change the repo from lp:/project-dev to lp:/project
<gregcoit> fullermd: does that help?
<fullermd> That...   doesn't make any sense.
<fullermd> Do you mean you want to change the _parent_ pointer?
<gregcoit> I think so
<fullermd> The repo is in ~/project (or maybe ~/, or ~/../, etc, but probably not)
<fullermd> You can use 'pull --remember' to set the parent.
<fullermd> It sounds a little XY-ish, though.
<fullermd> What are you trying to _accomplish_ by this?
<gregcoit> allow people who are using out dev branch to upgrade to our non-dev branch
<gregcoit> without having to wipe the files from their local dir first
<fullermd> So, the equivalent of `rm -rf ; bzr branch lp:project` without all the re-copying.
<gregcoit> yeah
<gregcoit> exactly
<fullermd> Something like `bzr pull --overwrite --remember` will mostly do it.
<gregcoit> killer
<fullermd> Of course, if they have pre-existing push locations or the like, that won't change them.  But presumably they'd still be correct.
<fullermd> --remember is needed to reset the 'parent' pointer; otherwise it'll stay at the old one, and just use the given location for THIS pull, not future ones.
<gregcoit> ahh, ok, good to know
<fullermd> --overwrite makes it throw away anything that's not part of that new branch, which is what you'd want for switching from one to another.
<fullermd> (not if they have local work on top of the branch to be preserved, though)
<gregcoit> fullermd: exaactly what we need
<gregcoit> good to know
<gregcoit> i'm new to version control (that's probably obvious).  bzr is amazing.  *so* much betetr than svn
<cakoose> The benchmarks page is slightly out of date and I would like to update it.  I have a script that will run the benchmarks and generate the output table.  Who should I contact regarding this?
<fullermd> cakoose: I think igc might have been the last person to do much work there?
<gregcoit> fullermd: thanks for your time
<fullermd> igc: ^^
<cakoose> igc: I'd like to update the benchmarking page.  fullermd tells me you might be the one to talk to about this.
<spiv> cakoose: if igc isn't around at the moment, try the mailing list.  igc (among others) will see it there.
<cakoose> spiv: k, thanks
<igc> back
<igc> hi cakoose: you're very welcome to update the benchmark page
<fullermd> He just snuck out on ya  ;)
<poolie> igc can you answer https://answers.launchpad.net/bzr/+question/107463
<igc> poolie: sure
<vila> hi all
 * fullermd flops at vila.
<vila> fullermd: you mean something like: _o/ \o/ \o_ ?
<fullermd> Oh, I didn't think it through that carefully.  I just thought it would be a nice change from waving.
<vila> I only knew flop in 'megaflops', 'teraflops' and the like, so I had to look in my dictionary :)
<fullermd> I mostly think of it as what a fish does when you toss it on the ground   :p
<xeviox> morning
<xeviox> when I add a patch from a peer to the trunk, needs the peer to merge instead of pulling the newest trunk?
<poolie> hi vila
<vila> hey poolie !
 * igc dinner
<radoe_> Hi, if i shelved some changes, how can I see what exactly is in a specific shelved change?
<poolie> radoe_: unshelve --preview
<poolie> night all
<jave> I'm a bzr newbie, id like to publish an emacs bzr branch on savannah. have anyone here done this?
<lifeless> kfogel probably has
<radoe> Thx, and now I have to file a bug regarding the bzr crash occured while previewing my shelved changes :(
<jave> kfogel: ping
<radoe> I shelved some changes, bzr unshelve --preview produces "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7: ordinal not in range(128)'
<lifeless> radoe: please do file a bug
<radoe> What should I attach to a bugreport in addition to the crashlog?
<lifeless> the crashlog should be sufficient, initially.
<lifeless> obviously a description of what went wrong.
<radoe> lifeless: got already reported as bug #518916 two months ago.
<ubottu> Launchpad bug 518916 in bzr "`unshelve --preview` fails with unicode error" [Medium,Confirmed] https://launchpad.net/bugs/518916
<lifeless> radoe: if the backtrace is /identical/ it may be the same issue
<kfogel> jave: have you tried just pushing it?
<kfogel> jave:  should work
<lifeless> radoe: but unicode errors can turn up from many places; I don't assume that they are the same without checking in detail
<kfogel> jave: lp:~kfogel/emacs/3646-bookmark-format-compat for example
<kfogel> jave: expanded, that's https://code.edge.launchpad.net/~kfogel/emacs/3646-bookmark-format-compat
<radoe> lifeless: except for  the last line where the bugreport has an additional reference to encodings\cp866.pyo the backtraces are identical.
<radoe> I'll attach it to the bugreport nevertheless
<jave> kfogel: so, "bzr push sftp://jave@bzr.savannah.gnu.org/srv/bzr/emacs/imagemagick" in my case?
<jave> I  tried it and it didnt complain, so maybe it worked. how do I verify it?
<jave> http://bzr.savannah.gnu.org/lh/emacs says "loggerhead disabled due to unstability; if you're interesting in maintaining it, please contact us"
<jave> ok, "bzr ls sftp://jave@bzr.savannah.gnu.org/srv/bzr/emacs/imagemagick" shows some files
<bialix> jml: ping
<cr3> how can I remove a tag?
<spiv> bzr tag --delete FOO
<cr3> spiv: thanks!
<damiro> can anybody answer me some questions about binary file handling?
<spiv> damiro: probably :)
<jml> bialix: pong.
<damiro> can bzr identify binary files?
<spiv> damiro: in what sense?  When merging?
<damiro> no.. only to prevent line-ending conversion
<spiv> Ah.
<spiv> bzr doesn't convert line endings, unless you configure it to: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/eol-help.html
<damiro> ahh... thats good.
<damiro> so there will be no difference in handling files?
<IslandUsurper> damiro, `bzr diff` won't tell you *what's* different in binary files, only that they *are* different
<IslandUsurper> otherwise, they're all just files
<damiro> and what about the data store... if i have a bigger binary file with 2 versions. saves bzr the delta to version 1 or the whole file again?
<bialix> jml: I saw your new article and want to ask about its title
<spiv> damiro: it saves a delta
<damiro> thats fine :-)
<spiv> The deltas are optimised for text files, but work ok for binary files.
<spiv> (Assuming that the versions aren't completely different, of course... some binary file formats tend to produce completely unrelated-looking bytes after minor edits)
<damiro> in my case it will be media data, mostly png and wave..
<LeoNerd> Hmmmmmm
<jml> bialix: yes it is from The Big Lebowski :)
<LeoNerd> I'm trying to roll back to an earlier revision.  I have 79 revisions in branch.   bzr up -r75; bzr revo  =>  prints 79
<LeoNerd> so... how do I see what the revno of the checkout is.. rather than the top in the branch?
<maxb> LeoNerd: revno --tree
<LeoNerd> Ah
<damiro> ok.. thank's a lot, spiv and IslandUsurper
<spiv> damiro: you're welcome
<james_w> anyone have a neat way with the API to find the earliest mainline revision to merge a specific revid?
<lifeless> branch.iter_merge_sorted
<james_w> so I have revision A and revision B, and want to find the earliest revision in revision A's left-hand ancestry that has B in its ancestry
<james_w> that looks overly expensive for this job
<lifeless> james_w: I'm not aware of anything better other than jams history db, at this ponit.
<james_w> ok
<james_w> it seems to me that if I walk through revision_history() and find the first revision to answer no to is_ancestor(B) I will have it
<james_w> [a for a in branch.iter_merge_sorted_revisions(start_revision_id=A, stop_revision_id=B, stop_rule='include', direction='forward') if a[1] == 0][0][0] by my reading of the docstring
<lifeless> james_w: is_ancestor is about as expensive as list(iter_merge_sorted_revisions) but you'd be calling it *per* ancestry point
<james_w> ok
<lifeless> james_w: thumper recently landed code in lp to do precisely what you're wanting to do
<lifeless> james_w: something like that comprehension, yes
<lifeless> its too late for me to bend my head completely around though
<vila> pqm fails to send mail on failures ?
<james_w> vila: I think there is a suspicion that the output exceeds some limit now
<james_w> due to the extra information in the subunit stream
<vila> yeah spiv mentioned it a couple of hours ago, but *where* is it failing ? At the sending site ? At some intermediate one ?
<vila> james_w: are you still working on your ancestry check ?
<james_w> I've got something coded now, working on tests
<vila> ok
<james_w> my guess would be postfix on the pqm box
<james_w> but it could be anywhere in between I guess
<jelmer> lifeless: hi
<jelmer> lifeless: are you debugging something with PQM?
<vila> jelmer: \0_
<vila> jelmer: I think he said it in one of its mails :)
<vila> s/its/his/
<jelmer> ah, I see now
<jelmer> Just saw a bunch of emails
<vila> yeah, me too, weird, especially since *I* didn't get mails for my last submissions which failed ;)
<lamont> james_w: one of the losas could verify that for you
<vila> Ha, silly me, losa ! Gimme a losa !
<Chex> vila: hi let me look at you
<james_w> heh
<james_w> vila: look behind you!
<vila> Chex: Hi ! So, it seems pqm failed to send me an email after a failed subsmission
<vila> james_w: same wall as usual ;-)
<vila> Chex: twice in fact
<Chex> vila: hmm, interesting.
<vila> Chex: no, scratch that, the second one has not failed yet, it's still running !
<vila> Chex: but it's almost the same merge and already mentions an error at http://pqm.bazaar-vcs.org/
<vila> so it *will* fail
<Chex> vila: test_no_conflict_marker.py, yes?
<Chex> vila:  is yours?
<vila> Chex: no, Merge 2.1 into bzr.dev including fixes
<jam> dang lifeless, you really know how to spam the review queue....
<jam> morning vila
<vila> morning jam, yeah, let's hope he *is* awake  :)
<james_w> well, he apparently just set the thing back to Queued, and I don't think that would be a bot would it?
<jam> I just set it to WIP
<jam> james_w: well, it is cycling, and I don't think Lifeless is awake
<vila> jam: I don't think it's cycling, there are tiny differences in the error messages the last one being being about a module without exit defined
<james_w> and now it's back from WIP to Approved
<jam> perhaps, but 20+ messages is a decent threshold if he isn't actively processing it
<jam> Main problem is that bots act as users
<jam> so you can't tell *who* is actually doing the action
<vila> I bet he is awake :)
<jam> Of course, having to manually subscribe to a branch so I can say I don't want email is a bit weird, too
<jam> And since I've commented on the mp, I don't even know if that will work
<jam> lifeless: go to bed and stop spamming my inbox :)
<lifeless> jam: you know when you're at the final stage of getting something done
<lifeless> jam: I'm done now; the frankenbeast is working
<lifeless> I was menaing to be asleep 2 hours back. argh.
<lifeless> jelmer: queue position - not new, but newly used.
<jelmer> lifeless: ah, ok
<jelmer> lifeless: what were you trying to get working?
<jelmer> lifeless: just trying to fix a PQM bug or is this new fancy stuff?
<jam> jelmer: he's working on a cron script
<jam> so you can mark a mp Queued
<jam> and it will land it for you
<jam> or block it, I assume
<jelmer> ah, neat
<jelmer> it's great to finally see stuff happening in pqm again
<vila> he was awake, I won :)
<vila> ui.note() doesn't support unicode, does that ring a bell ?
<jelmer> not to me..
<Guest00963> Anyone have any experience/opinions re: bzr-eclipse vs qbzr-eclipse?  Is one proj more-active / recommended than the other?
<Tak> is there a trick to using svn+ssh:// on windows? I used the 2.1.1 standalone installer, and I keep getting: [Errno 2] Can't create tunnel: The system cannot find the file specified (on a pull)
<jelmer> Tak: it's having trouble finding the ssh executable
<jelmer> Tak: I'm not sure what the best fix is exactly
<Tak> hmm - doesn't it use paramiko?
<jelmer> Tak: no, since bzr-svn just calls out to libsvn
<jelmer> Tak: and that's written in C and needs to call a SSH executable
<Tak> oh, ok
<Tak> trying http://agateau.wordpress.com/2007/07/03/windows-svnssh-and-the-subversion-command-line-client/
<vila> jam: what encoding should ui.note() use IYHO ?
<jam> vila: trace.note uses utf-8
<jam> ui.note() should take Unicode
<jam> and the ui_factory should determine what encoding to use
<jam> ideally, TextUIFactory would use sys.stderr.encoding
<jam> probably osutils.get_terminal_encoding()
<jam> however, we've historically had lots of problems with that stuff
<jam> so... meh
<vila> that's the suprising part in bug #563997 ... that we didn't encounter the problem sooner
<ubottu> Launchpad bug 563997 in bzr "ui.note doesn't support unicode" [High,Confirmed] https://launchpad.net/bugs/563997
<jam> vila: we rarely use ui.note() vs trace.note()
<jam> and the latter has currently been hard-coded as utf-8
<vila> ha, good point
<jam> *I'm* pretty surprised to see that ui.note() is going to stdout, rather than stderr
<vila> jam: well, the problem will be the same
<vila> I was about to add a msg = msg.encode(osutils.get_terminal_encoding(), 'replace') but I realized that this isn't cached... and could be quite costly to call for each note()
<jam> vila: in other places we set up the output file at one point, and then use it repeatedly from there
<vila> yeah, I guess I could cache it __init__ anyway since different ui objects will be used, there is no way to change stdin/stdout/stderr (other than accessing the attributes dirrectly...)
<vila> jam: hmm, looks like the truth is elsewhere, bzrlib.tests.TextTestResult is using ui.note, but I see no good reason for this (may be to avoid calling ui.clear_term() explicitly...)
<jelmer> jam, vila: How do we cope with the lack of atomic renames in bzr exactly?
<jam> jelmer: osutils.fancy_rename()
<jam> generally, we fake it
<krisives-gearbox> How do I get a file back that has been removed from version control?
<krisives-gearbox> When I do `bzr cat -r` with an old revision it says its no longer under version control
<krisives-gearbox> When a file gets removed from bzr, are all traces gone after that?
<IslandUsurper> try reverting that file to a good revision
<IslandUsurper> I'm surprised cat didn't work though
<fullermd> I think cat may look at the current tree to find the file.
<fullermd> revert is the better answer anyway though.  cat/add won't resurrect it, it'll make a new file.
<krisives-gearbox> I tried using `bzr cat -r someOldVersionThatWasGood` and it didn't work
<krisives-gearbox> It says its not versioned anymore
<IslandUsurper> krisives-gearbox, use `bzr revert -r xxx filename`
<krisives-gearbox> IslandUsurper: I tried that too, it's saying this:
<Stavros> hello
<krisives-gearbox> bzr: ERROR: u'administrator/components/com_fpslideshow/configuration.php' is not present in revision stoysnet@hostedbycorephp.com-20100412210927-21s7b7c2ftm709um
<Stavros> does anyone know if dulwich 5.1+ is available anywhere?
<krisives-gearbox> Why is the revision name so long, I don't remember seeing that before
<Stavros> erm, 0.5.1
<Stavros> all i can see is 0.5.0
<fullermd> krisives-gearbox: Well, that's the name of the revision   :)
<fullermd> krisives-gearbox: Are you sure the file did exist in that rev?
<krisives-gearbox> How can I see the name of the revision?
<fullermd> Adding --show-ids to log will show the revids.  But you can use the revnos just as well; it doesn't matter for what you're doing.
<krisives-gearbox> I think this was caused by FTP and `bzr update`. I always use SFTP, can anyone give me a heads up on how FTP and `bzr update` work /
<krisives-gearbox> When I remove a file from version control, how can I make sure that file doesnt get deleted later when I do a pull/push ?
<krisives-gearbox> http://stackoverflow.com/questions/2648362/remove-files-from-bazaar
<vila> krisives-gearbox: this sounds like a bug, please file it at https://bugs.launchpad.net/bzr/+filebug
<krisives-gearbox> vila: Really? Not arguing, but it's a bug?
<vila> krisives-gearbox: well, at least the bzr behaviour doesn't match your workflow
<krisives-gearbox> Is it supposed to be default to have it delete the files/
<vila> One can argue that you want your cake and eat it too (don't version it, but please keep the last version of the file in place)
<vila> yes it is, that's what you want generally: a versioned tree should be recreated as it is versioned and if you get new versions you want the tree to be updated
<vila> I can't think of a good way to address your workflow but may be others will have better ideas
<vila> krisives-gearbox: in the mean time, you should advertise how to restore this file to your users
<vila> krisives-gearbox: bzr revert -rxxx file
<krisives-gearbox> We're trying to version many clients, so that's not a possibility right now
<krisives-gearbox> Another problem is that `bzr revert -r SomeVersion file` says it's been removed from version control, so we end up having to do a hunt for the last version that it was versioned under (which could be 20+ revs ago)
<vila> krisives-gearbox: one thing I don't get is how would a new client start from a recent version ?
<vila> krisives-gearbox: where will the file be coming from ?
<krisives-gearbox> The scenario is that they have a lot of existing clients that don't have any kind of version control
<krisives-gearbox> We've version controlled the development and testing sites
<krisives-gearbox> To version the clients I'm copying the .bzr directory to the client site, which gives me a way to see what all the changes are when I do a `bzr status -V` or in text editor when I use `bzr commit`
<vila> ok
<lifeless> someday I'll learn how to sleep in after a late night
<lifeless> but not today
 * vila is not sure to agree :)
<lifeless> thumper: ping
<dash> jelmer: i just encountered bug #413113 in bzr-svn 1.0.2
<ubottu> Launchpad bug 413113 in subvertpy "SubversionException: ('Svndiff contains a too-large window', 185001)" [High,Fix released] https://launchpad.net/bugs/413113
<jelmer> dash: what version of subvertpy/bzr-svn are you running?
<dash> subvertpy 0.6.8
<dash> bzr-svn 1.0.2
<jelmer> dash: see that bug report
<jelmer> dash: that bug was fixed in subvertpy 0.6.9
<dash> jelmer: hup! i am blind
<dash> jelmer: i read that as bzr-svn 0.6.9
<dash> thank you. ;)
<jelmer> ah, heh
<dash> jelmer: that works, of course
<dash> jelmer: btw thank you, bzr-svn has made my life significantly less frustrating at work
<thumper> http://www.platocafe.co.nz/
<thumper> damn
<thumper> up arrow
<thumper> lifeless: pong (but on a call)
<lifeless> thumper: hey great.
<lifeless> thumper: who can set merge proposals to 'Queued'
<lifeless> thumper: also check out the latest commits to lp:pqm
<jelmer> dash: happy to hear it :-)
<lifeless> thumper: so, yo
<thumper> lifeless: still on a call
<lifeless> ok
<thumper> lifeless: I believe that the owner of the target branch can mark something queued, or the owner of the merge queue
<thumper> lifeless: merge queues aren't exposed yet through either the web ui nor api yet
<lifeless> thumper: its definitely more than the target branch owner.
<thumper> lifeless: if the proposal has been approved, then I think it is anyone with launchpad.Edit on the proposal
<lifeless> thumper: perhaps I'm in the merge queue owner group though; are there implicit queus for series ?
<thumper> lifeless: I'd really have to take more of a look
<lifeless> thumper: I guess what I really mean is, 'how can I tell' ?
<thumper> but both rockstar and I would like to see the feature finished off
<thumper> lifeless: read the source is the only way
<lifeless> thumper: ok, where should I start
 * lifeless fires up the lpdev vm
<lifeless> thumper: yes, I know its not finished and you want to finish it.
<thumper> lifeless: if the proposal is not approved, only reviewers can queue it, if it is approved anyone who can set the status can queue it
<thumper> lib/lp/code/model/branchmergeproposal
<lifeless> thumper: I'm very happy to dogfood and deal with glitches
<lifeless> thumper: all going well, pqm for bzr will be lp queue enabled today
<thumper> cool
<lifeless> thumper: I just need to figure out if I'm opening a huge gaping security hole
<thumper> lifeless: the whole is no bigger than pqm currently is
<lifeless> or whether the lp permissions model is close enough to what we do in the config file today.
<lifeless> thumper: currently, pqm requires a gpg signature from specific people to do a merge
<thumper> lifeless: yes, but I could submit a branch for you that you could then push new revisions to before it is handled
<thumper> lifeless: it is similar for LP queues
<lifeless> thumper: if you think I'm trustworthy and you're wrong, yes.
<thumper> I think lp deals at the same level of trust
<lifeless> thumper: for that particular vector, yes. But we may be letting all of ~bzr send to pqm, for instance.
<thumper> true
<lifeless> which is/was an open team
<lifeless> what defines 'reviewers' for a merge proposal
<lifeless> thumper: I think you may have the permission description you gave me a little confused
<lifeless> I see a comment that says
<lifeless> 'non reviewers can toggle between approved and queued, but not make anything else approved *or queued*'
<lifeless> thumper: oh, actually, you have it right, but the explanation confused me.
<lifeless> 'only reviewers can permit a proposal to end up in the 'queued' state.'
<lifeless> thumper: I need a small hand
<thumper> lifeless: yes?
<thumper> I have to head out for an appt shortly
<lifeless> thumper: two questions: what defines 'reviewer' for a mp
<thumper> lifeless: in the review team of the target branch or in the owner team of the target branch
<lifeless> and the other q is generic LP APIs, I'll ask in #lp-dev
<lifeless> thumper: ok, so I think I'll do my own permission check on the queuer
<lifeless> thumper: and file a bug, because I think we want more reviewers than landers. Or something.
<lifeless> thumper: we've got 33 people in the review team for bzr.dev
<lifeless> thumper: oh I should also say - thank you very much for your refactorings of the pqm code base
<lifeless> they made this possible
#bzr 2010-04-16
<jelmer> lifeless: do you have any plans to merge Dan's outstanding patches?
<lifeless> jelmer: I've looked at all the proposed branches, I thought.
<igc> morning
<spiv> Morning.
<poolie> good morning
<jelmer> lifeless: Rather than reorganizing everything we have at the moment, couldn't we just have a new "bzr-committers" group ?
<lifeless> jelmer: thats what I've said I'll do :P
<jelmer> lifeless: sorry, looks like I'm just behind on mail
<igc> mwhudson, jelmer: any ideas on bug 563118?
<ubottu> Launchpad bug 563118 in loggerhead "Lucid upgrade switch to serve-branches.conf without providing one" [Undecided,New] https://launchpad.net/bugs/563118
<igc> mwhudson, jelmer: I can't even find where the configuration file name is defined
<igc> Could it be a packaging issue?
<igc> poolie: what approach should I take for 2.2b1 Windows builds? Should I use a revision on trunk or use the 2.2 branch?
<mwhudson> igc: it might be a packaging issue i guess
<igc> mwhudson: all I can find is loggerhead.conf.example in the code
<igc> I can't see where loggerhead.conf is referenced though
<mwhudson> igc: it's passed on the command line maybe?
<mwhudson> i think jelmer has a packaging branch somewhere that has an initscript that mentions it
<jelmer> http://bzr.debian.org/pkg-bazaar/loggerhead/unstable
<jelmer> or deb:loggerhead for short :-)
<jelmer> lifeless: I'm considering moving some per_repository tests into a new per_repository_vf.test_supported, does that sound reasonable?
<igc> jlemer, mwhudson: any chance one of you can look at that bug or direct me on how to fix it?
<lifeless> jelmer: what are they testing ?
<igc> jelmer, mwhudson: I need to head up the hospital right now
<jelmer> lifeless: they are the tests that rely on .revisions/.texts/.inventories existing
<mwhudson> igc: i'll have a look, but i think it's going to be a bit tricky
 * igc out for a few hours
<igc> mwhudson: thanks
<mwhudson> because we're deprecating the entry point that's used before lucid
<lifeless> jelmer: I want those to be supported on foreign repos too
<lifeless> jelmer: they are part of the contract
<lifeless> I don't think its appropriate to have them unsupported anywhere
<jelmer> lifeless: why? They rely on a specific serialization, and we don't always have access to that serialization
<jelmer> lifeless: in particular, inventories don't exist in git/hg/svn so we have to generate an inventory manually *and* serialize it
<jelmer> lifeless: fwiw these plugins work fine without .{texts,revisions,inventories} at the moment
<lifeless> jelmer: see the docstring in bzrlib.repository.Repository
<lifeless> jelmer: the meaning is per-format
<lifeless> jelmer: the interface isn't
<lifeless> jelmer: which is why I didn't like your mirroring onyl *part* of it last week or so
<lifeless> its a regression in our interface, moving away from the unified keyspace
<jelmer> lifeless: can you expand on "the meaning is per-format, the interface isn't" ? I don't understand what you mean.
<lifeless> I mean that the serialisation is specific to the format
<lifeless> and external code to the format knows that it doesn't know
<lifeless> but that the graph is intrinsic
<lifeless> all formats should be capable of generating graphs for revs, invs, texts
<lifeless> and this is the interface to talk to that
<jelmer> lifeless: where do we rely on graphs for invs and texts at the moment?
<jelmer> lifeless: providing those for foreign formats would be hard to make perform well
<jelmer> lifeless: I understand that's what's in the interface now, but I'd rather see that interface change..
<jelmer> lifeless: ... and have vf's be part of the implementation of a particular category of repositories rather than all of them
<lifeless> per file log
<lifeless> inv graph we don't care about
<lifeless> jelmer: I don't see why it imposes a performance penalty; either you have to generate the data, or you don't.
<lifeless> if you're doing per-file log to bzr's behaviour, you need to generate the data
<jelmer> lifeless: ok, point taken
<jelmer> lifeless: that's just one function in the VF interface we use though, that justify requiring a VF imho
<lifeless> the point of the vf interface is a consistent graph interface that is *not on Repository*
<lifeless> its part of the long term fixing of repository.
<lifeless> which you undid some of last week :(
<lifeless> if you've got a better direction to take it, I'll happily support that
<jelmer> lifeless: and much more, I don't see how access to serialized commits/inventories should be a public part of repositories
<lifeless> but so far, abently's proposed 'storage' interface - a single unified graph - seems to be a likely winning contender
<lifeless> jelmer: its been very useful so far to have it in a consistent supported manner
<lifeless> jelmer: for repo-stats and other plugins
<lifeless> debuggability is an important feature
<jelmer> lifeless: I'm not saying it can't be available, just would prefer to not have it in the contract of Repository itself
<lifeless> we have, for instance, used access to the graph to fix stacked branches
<jelmer> nothing stops a VersionedFileRepository from existing
<jelmer> anyway, this is a blocker for me for using the standard per_repository tests for foreign repositories
<lifeless> jelmer: seems to me there are two positions we could take
<lifeless> a) that bzr-svn etc are 'complete' and the tests need to be divided
<lifeless> b) that they are not complete, and the tests primarily need to be tweaked to remove bzr-only assumptions
<lifeless> I currently hold position b
<lifeless> jelmer: I don't want to block you, but you seem to hold position a?
<jelmer> lifeless: I don't consider b to be possible, unless you're happy to strip the VersionedFiles interface down to just get_parent_map() and get_known_graph_ancestry()
<lifeless> jelmer: because you can't get raw data from svn ?
<jelmer> lifeless: nor can I get an inventory text from git
<jelmer> lifeless: it's also not possible to add any text
<lifeless> jelmer: you can get the root tree node
<lifeless> jelmer: I'm ok with making the _required_ support on the vf objects be very minimal
<jelmer> lifeless: to just revisions.{get_parent_map,get_known_graph_ancestry}, texts.get_parent_map ?
<jelmer> lifeless: generally the way this is structured ({revisions, texts, inventories} as serialized files) makes a lot of assumptions about the way the repository is set up that aren't true for foreign repositories
<lifeless> jelmer: this is why I want to move to a single unified graph!
<jelmer> lifeless: is that aaron's storage thingy?
<lifeless> jelmer: which is one of the key complaints about that merge I keep coming back to
<lifeless> jelmer: closely related, yes.
<lifeless> jelmer: CHK repositories are pretty close to git internals, and the mapping structure we have works ok for them too
<lifeless> jelmer: so, not, not just revisions & texts
<lifeless> for instance git could support chks trivially
<jelmer> lifeless: that doesn't mean it's easy to implement VersionedFiles on top of Git while using Bazaar file ids/revids though
<jelmer> lifeless: anyway, do you have pointers about the unified graph?
<lifeless> jelmer: I know, but revision_tree.get_texts takes the same interface
<lifeless> jelmer: so its no harder
<jelmer> lifeless: I don't have a RevisionTree.get_texts...
<lifeless> jelmer: mumble, I forget the exact api name
<lifeless> see what export uses
<jelmer> iter_files_bytes() ?
<jelmer> that doesn't return any parent keys
<jelmer> anyway, I'd better get some sleep
<jelmer> lifeless: thanks for the comments; I'll hold off on this for now, at least until the new better storage thing
<lifeless> jelmer: perhaps we can talk at UDS
<lifeless> I do want to unblock you
<lifeless> but we seem to be unagreed about where to go
<lifeless> I'm concerned that you seem to be busy undoing a good years worth of refactornig
<lifeless> if you weren't, I'd be much more lassez faire about stuff
<jelmer> lifeless: it was just one function...
<lifeless> jelmer: no, its more than that
<lifeless> the VF interface is a key part of stacking working
<jelmer> lifeless: I just added a wrapper in Repository, I didn't move anything
<jelmer> lifeless: everything else seems to be happy calling Repository.*
<lifeless> to be clear, I don't think you're doing bad code, but we - you and I at a minimum - havent' figured out a foreign <-> core compromise
<jelmer> lifeless: right
<jelmer> lifeless: talking about this at UDS might be a good idea indeed
 * jelmer really gets some sleep now
<lifeless> gnight
<raof> Congratulations on bzr-git, by the way.  I've been using it to browse the kernel tree's commit log, because bzr's default log format is vastly superior to anything I've found in git.  âbzr logâ in the kernel tree takes approximately as long as âgit logâ
<lifeless> jelmer: ^
<lifeless> raof: thats awesome
<lifeless> and a little terrifying
<raof> :)
 * raof doesn't quite get why git thinks commits should be in chronological order, interleving commits from different branches into one mixed stream
<thumper> here is a mind bender
<lifeless> shoot
<thumper> I have an existing branch that I had on the wrong revision
<lifeless> 'wrong' ?
<thumper> I want to make a branch that is cherry pickable
<thumper> but I started with production-devel
<thumper> rather than the lca with devel and production-devel
<thumper> so when I proposed my production devel based branch, I get conflicts galore
<thumper> so...
<thumper> I uncommitted and shelved
<thumper> now I want to get to a good start revision
<thumper> how?
<lifeless> bzr pull . --overwrite -r revid:`bzr find-merge-base devel prod-devel`  [actually the backtick expression won't work, consider it a conceptual example]
<thumper> no revisions to pull :)
<lifeless> then you were on the revision already?
<thumper> I think deleting the branch and starting again might be faster
<thumper> no
<thumper> shouldn't be
<thumper> actually yes it is
<thumper> but the revno seems all wrong
 * thumper stabs it a bit
<lifeless> thumper: pull --overwrite is the canonical way to just shift to a different revision
<thumper> lifeless: worked with 'bzr pull ../db-devel --overwrite -r 9184'
<thumper> lifeless: but giving it a revid (probably a different one) got it to 10622
<thumper> given that the branch I was pulling from has under 9300 revisions
<thumper> it seemed screwy
<lifeless> heh
<chx> hi. trying to get bundle buggy up and running. i have turbogears2 installed and http://turbogears.org/2.0/docs/main/WhatsNew.html says tg-admin sql create â> paster setup-app development.ini but what's development.ini?
<chx> meh, i will just get turbogears 1.1
<chx> AttributeError: 'ScopedSession' object has no attribute 'query_property' :(
<chx> and there i am stuck :(
<chx> abentley: I am trying to install bundle buggy
<poolie> chx, perhaps it's a bit out of date
<poolie> try googling those names
<chx> poolie: the error message? i googled the error message, there is nothing
<chx> literally nothing
<chx> Results 1 - 1 of 1 for " AttributeError: 'ScopedSession' object has no attribute 'query_property'".
<chx> and that's a chatlog
<chx> "have you seen that before? nope"
<poolie> can you pastebin the traceback?
<chx> poolie: http://bzr.pastebin.com/8wRuteUF
<poolie> to me this looks like a version mismatch within elixir vs turbogears
<poolie> chx, suggest you send mail about it to aaron or to the bzr list
<chx> poolie: OK :(
<chx> will attempt with turbogears 1.0 as a last try
<poolie> ok
<poolie> most of the attention here has moved to lp reviews recently
<mkanat> So, I did I hear something about bzr releasing the GIL sometimes?
<mkanat> (Strike that first "I")
<lifeless> yes
<lifeless> some of our C extensions know how to release the GIL
<mkanat> lifeless: Okay. Is there some code I can grep for to see where that happens (or a list of places where it does)?
<lifeless> bzrlib/*.(?i:py$) :)
<mkanat> lifeless: The reason that I ask is that, though I haven't fully investigated, the codebrowse deadlock may be somewhere in the python interpreter layer, and a released GIL seems like a possible culprit.
<lifeless> I'm not sure which modules release
<lifeless> I'm pretty sure the groupcompressor does
<lifeless> possibly diff does
<spiv> The only C extension that uses Py_BLOCK_THREADS/Py_UNBLOCK_THREADS is bzrlib/_groupcompress_pyx.c, according to grep
<mkanat> spiv: Okay. So that would only happen on a write operation, right? So loggerhead wouldn't call that code.
<lifeless> look for nogil in the pyx files
<mkanat> lifeless: Thanks. :-)
<lifeless> mkanat: apply_delta does nogil
<lifeless> so its both compression and decompression
<spiv> mkanat: no, I think it uses nogil sometimes while reading too.
<spiv> mkanat: that said, I'd be a bit surprised to find that using nogil was the problem
<mkanat> spiv: What happens if a thread that has the GIL released gets an exception (from the launchpad-loggerhead no-activity thread killer)?
<mkanat> spiv: Will the GIL be reacquired?
<mkanat> spiv: You'll have to forgive me a little, I've actually not used much python code that releases the GIL.
<spiv> mkanat: assuming no bugs in Pyrex (or Cython if that's what you're using), yes.
<mkanat> spiv: Okay.
<spiv> Look at how the translated C code handles those conditions if you like.
<lifeless> mkanat: python code can't release the gil, only C code written to CPython
<mkanat> lifeless: Right.
<lifeless> well
<mkanat> lifeless: I was speaking loosely. :-)
<lifeless> I guess the python dynamic access to C code could release it
<lifeless> it would be hilarious
<mkanat> Okay, yeah, looks like only groupcompress uses nogil anyhow.
<mkanat> Okay, I've looked and not found this--where can I find how to get a working local instance of launchpad-loggerhead?
<maxb> https://dev.launchpad.net/  ?
<mkanat> maxb: Thanks.
<mkanat> spm: What does nagios/whatever do to check whether codebrowse is alive?
<spm> mkanat: oh we gave up on that ages ago. it's kinda /dev/random > 20% - alert. otherwise is fine.
<mkanat> spm: lol
<spm> mkanat: /usr/lib/nagios/plugins/check_http -H bazaar.launchpad.net -u /~vcs-imports/busybox/main/changes -e " 200 OK"
<mkanat> spm: Okay.
<spm> basically a simply http check alive/dead against a known url
<mkanat> spm: Okay. Does nagios do the check more than once, or do you get paged immediately if it fails once?
<spm> 3 or 3 fails I suspect. it's very rare for any of our checks to be different to that
<spm> 3 *of* 3
<mkanat> spm: Okay, thanks.
<spm> np
<poolie> hi spiv, lifeless, igc,
<poolie> and vila
<poolie> i'm thinking it's probably best to do 2.2b2 now, off trunk, rather than recutting 2.2b1 with fixes
<poolie> any problems with that?
<igc> poolie: ok by me
<lifeless> poolie: fbm
<poolie> i feel a bit weird so i'm going to stop after that
<spiv> Yeah, seems fine to me.
<vila> poolie: I merge 2.0 -> 2.1 -> 2.2 and 2.1 > bzr.dev yesterday, so both ways are fine to me, I thought that was the plan anyway
<poolie> thanks
<poolie> yes, it was
<poolie> i just had a somewhat dopey day today
<vila> poolie, lifeless: Can we talk about https://code.edge.launchpad.net/~vila/bzr/563997-selftest-unicode-reporting/+merge/23501 ?
<poolie> sure
<vila> lifeless: you r comment is terse and doesn't help me there, what's your point ?
<poolie> sure
<poolie> so vila, i think the main point of using them would be to synchronize with the progress bar
<poolie> that might be unneccessary if self.stream is already obtained from make_output_steram
<poolie> stream*
<poolie> um
<vila> no its' not, it's a totally different beast
<vila> well, AFAICS
<vila> and I think the pb has already been cleared (my manual testing didn't show any problem there)
<poolie> ok
<vila> What *I* like is to separate the issues there: 1) make selftest robust, 2) address unicode support in ui
<poolie> so i would still say that the real problem is #2
<lifeless> vila: hi
<lifeless> uhm
<poolie> but if this is more pragmatic i don't think it's wrong
<poolie> i think pb.note should be for something that kind of maps into an information dialog popup
<lifeless> selftest shouldn't be calling a global function, which it might be
<vila> yeah, but 1) was blocking me and trying to address 2) was more... involved
<poolie> it's not clearly defined
<poolie> so i don't mind removing callers
<lifeless> in-python gui runners mightlike the current behaviour
<vila> lifeless: yeah, part of the problem, I have no idea if there are one or several ui objects involved
<lifeless> OTOH they can use their own result object
<lifeless> vila: if it calls via module.ui_factory, it will end up calling the ui object * of tests *
<vila> lifeless: I realize that, I'm not sure how approriate it is for selftest itself (given that it's the only place and that this code path is *not* involved is you use selftest -v !
<vila> I went with the pragmatic approach when I realized that (-v does it this way)
<lifeless> vila: so, I'm saying that selftest needs to be solidly isolated
<lifeless> I found some bugs when donig the testtools thing
<lifeless> where selftest was doing 'progress' but we would not see it because the test ui factory was installed
<poolie> lifeless: yes, i know of them
<poolie> in vila's patch it uses self.ui
<vila> lifeless: yes, I don't have the line at hand but testtools use a UnicodeOrBytesToBytesWriter for stream (or something)
<lifeless> ok cool
<lifeless> poolie: ^
<poolie> which is the outer ui, meant to be isolated from any global state changes
<poolie> mm, i remember the conversation
<vila> outer ui... I missed that
<lifeless> anyhow, I really don't mind what is done here; self.ui is our ui abstraction, but we don't have to use it
<vila> makes sense tough
<poolie> vila: the ui that's talking to the user about the progress of the test, not the ui for a particular test
<vila> sure
<poolie> lifeless: my suspicion is that the problem originates in doctests
<poolie> i think some isolation we do in the test base class actually needs to be done in the runner
<poolie> or, similar
<poolie> i mean, or in the doctest
<lifeless> poolie: really? That surprises me
<poolie> i think doctests will see ui.ui_factory pointing to the real one
<poolie> imbw
<poolie> i haven't actually fixed the bug
<poolie> it's only a suspicion
<lifeless> poolie: we can setup setup and teardown functions when we thunk doctests into unittest's api
<lifeless> poolie: so if thats happenning, we should create such functions
<lifeless> it sounds plausible
<vila> poolie: the issues I went into trying to address 1) were: ui.show_* methods doesn't encode, the only method that encodes is prompt()
<poolie> vila: i suggest you merge this for now and get unblocked
<poolie> i don't think it's a step back in any regard
<vila> amen & thks
<vila> poolie: I'll file a new bug for ui.note and friends then
<spiv> There's a bug still open about the lack of isolation for our doctetss
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/321320
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed]
<bialix> heya all
<spiv> bialix: good evening.
<vila> spiv: yeah, and I still can't run the test suite in a bound branch :)
<bialix> spiv: :-)
<bialix> let's call this rainy morning an evening
<vila> bug #309309 what a lovely number...
<ubottu> Launchpad bug 309309 in bzr "selftest can't be run in a bound branch" [High,Confirmed] https://launchpad.net/bugs/309309
<lifeless> vila: could you please start setting commit messages in your proposals ? Thanks!
<vila> lifeless: you mean when I do the proposal or when it is approved ?
<vila> lifeless: by the way, the only thing that blocks me to always use feed-pqm is the lack of --fixes support
<lifeless> vila: when you do put it up
<poolie> ok i might call it a day
<lifeless> vila: how do you mean --fixes?
<spiv> poolie: I suggest "Friday"
<poolie> hee hee
<lifeless> vila: if you mean the #TODO I have in my hydrazine cron branch, patch it :P
<poolie> it's the quiet ones you've got to watch :)
<vila> poolie: if I land something in bzr.dev can I still target it at 2.2b2 ?
<poolie> nup
<poolie> well, not truthfully :)
<vila> poolie: ?
<poolie> i've just sent a merge to pqm from trunk into the 2.2 branch that will be 2.2b2
<vila> lifeless: I mean the ability to say that the final commit is the one that really fixes the bug
<lifeless> vila: I'm not sure how thats connected to feed-pqm
<vila> lifeless: if my mp has been reviewed but doesn't mark the bug as fixed, I merge it into my integration branch, commit with --fixes and pqm-submit it
<lifeless> vila: why don't you just commit a no-op --fixes?
<lifeless> vila: or even not stress about it :P
<bialix> poolie: "call it a day" means EOD or long day fionished successfully?
<vila> lifeless: matter of taste I presume
<poolie> more of the first in this case, but either
<bialix> good weekend for you then!
<poolie> you too
<vila> poolie: 2.2b3 milestone activated, let's keep 2.2b2 active for a couple of days though
<poolie> yep
<poolie> i haven't sent something to trunk to bump the version yet,because pqm is a bit queued
<poolie> you can if you want
<poolie> cheerio
<vila> poolie: enjoy your week-end
<vila> lifeless: woot ! thanks for approving/submitting my mp :-D
<lifeless> vila: tools are good
<geser> Hello, I'm looking at updating a python script to use LP API (instead of screen scraping) and while at it to also replace the bzr calls with using the bzrlib module.
<geser> Is there any documentation how to "translate" bzr calls to usage of bzrlib?
<geser> I've found http://doc.bazaar.canonical.com/bzr.2.1/developers/integration.html which seems to cover most what I need.
<lifeless> geser: often, looking builtins.py can show you a great deal about what is going on
 * igc dinner
<geser> how do I translate "lp:foo" to something I can use as a branch location within bzrlib?
<spiv> geser: that should work automatically if you load plugins
<spiv> geser: "from bzrlib.plugin import load_plugins; load_plugins()"
<geser> ah, thanks
<spiv> (The "lp:" namespace is provided by the launchpad plugin)
 * spiv -> dinner
<putrycy> Hi! I'm looking for some system control software that fits my requirements. I would like to realize the following scenario: I and my few friend are in LAN and we have some project. We would like to have system controlling and backup at once. I.e. every would run server and commit command would send changes not only to local server but to my friends' servers too. Is it possible with bazaar? Could you point me out a piece of doc ragarding that? 
<jderose> putrycy: a bzr "bound" branch does exactly what you're asking for. if you have bzr installed, see `bzr help checkout` and `bzr help bind`
<jderose> putrycy: also see http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/central_intro.html
<putrycy> jderose: thanks, I'll take a look for sure. Tell me just one thing more: If some server is turned off will it be synchronized later?
<jderose> yes, but you can to do this manually (this is a feature I'd like to see in bzr)
<putrycy> I _can_ or I _have to_?
<jderose> when you go offline, you would `bzr unbind`.  when you go back online, you would `bzr bind` and then `bzr update`
<jderose> yes, you can certainly flip between bound and unbound, sync later when you are online
<jderose> it just doesn't happen automatically
<putrycy> OK, I'll dig in doc for details. Thanks a lot once more
<jderose> putrycy: no problem, good luck!
<quicksilver> I think putrycy was anticipating the changes would go *instantly* to his friends.
<quicksilver> that would require a something on the central server pushing to the friends on, perhaps, a commit hook or similar.
<quicksilver> there is no particular advantage to doing that
<quicksilver> unless you expect the main server to regularly burst into flames.
<vila> putrycy: keep in mind that by being distributed you already have a backup: all your friends have a copy of all the revisisions you've shared so far
<vila> putrycy: if you add a server in the mix acting as a synchronization point, you get one more copy and a point where you can decide how you share your history
<vila> plus a place where everybody can check for new changes and push his own changes of course, but the point is that this central server is not mandatory, you can find other ways to sync
<vila> putrycy: bzr itself doesn't provide a way to push to multiple targets automatically.
<vila> putrycy: bound branches allows you to push every revision you commit to *one* server
<jderose> putrycy: The "Workflows
<jderose> " doc give a good overview of the options, in case I didn't understand your needs: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html
<putrycy> oh.. I'm a little confused now. Why I would like to have repository on many servers? For safety. I.e. my real environ would contain just two machines: mine and of my friend. So I think it is possible one of them 'burst into flames'
<putrycy> In the of my computer corruption I would like to have a copy of my work
<putrycy> with all previous versions etc.
<jderose> putrycy: as bzr is distributed, when you create a local checkout or branch, you have the full set of revisions and history locally... so it's always on at least each person's machine who is working on it
<vila> if you have only two hosts it's simpler, start by reading http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief , the vocabulary will be clearer
<vila> putrycy: as soon as both of you have a branch, you backup each other
<putrycy> vila: OK, thanks
<putrycy> and with 3 parts?
<putrycy> I don't except corruption of two servers but I'm just asking
<putrycy> if somebody else would like to participate in our cooperation
<jderose> putrycy: the server is *another* backup, but also a potential means of synchronization
<vila> putrycy: it's the same, a branch use a repository to store revisions, as soon as you merge changes from your friends, you get  a copy of their revisions
<putrycy> oh
<putrycy> I think about another scenrario
<putrycy> i.e.
<putrycy> everyone work on another project
<putrycy> and I don't need to explicitly obtain their branches
<putrycy> (of course everyone could join to each other project but it's another story)
<vila> what do you mean by "I don't need to explicitly obtain their branches" ?
<putrycy> I mean a situation: on every sever there is a main dir containing repository. There are three different project: ProjectA, ProjectB, ProjectC. Each project is managed by another man. I think that I can work only on ProjectA. I.e. my server of course have to have a copy of ProjectA, ProjectB and ProjectC but my local workspace would contain only ProjectA
<putrycy> (My english doesn't help me to explain what I mean:/)
<putrycy> I think about bzr like about SVN... am I wrong?
<vila> putrycy: I think so, you *can* share a repository between branches and even between projects, but you interact mainly with branches
<putrycy> so
<vila> so when you pull or merge from a friend's branch into your branch, you get only the revisions for his branch, not for the other projects
<putrycy> when I change something in my branch I would like every of my friend could see that change on his server
<vila> putrycy: they will need to pull from your branch
<vila> or merge
<putrycy> so, cannot I commit to many different servers?
<putrycy> to 3 in this case: my local and of my friends
<vila> putrycy: you can commit locally and to *one* server by using bound branches
<putrycy> OK
<putrycy> thanks for youre patient
<vila> putrycy: no worries
<putrycy> patience
<vila> putrycy: you can write a plugin to do so,
<vila> putrycy: keep in mind that not all servers will be online 24/7 though
<putrycy> I know
<putrycy> I know
<putrycy> that's why I would like they to be synchronized
<vila> putrycy: or you can have a look at multi-pull which allows one to automatically pull (not push) multiple branches
<putrycy> when they are on
<vila> what OS are you (plural) using ?
<putrycy> mainly windows but I'm going to use linux as welll
<putrycy> (and perhaps FreeBSD)
<putrycy> I have to write cross platform p2p soft
<vila> putrycy: hehe, then once you've got the "who is online" sorted out, you can either push or pull :)
<putrycy> I don't want to: 1) lost my work 2) wait for long commit (sloooow internet connection) 3) show other my work (for some reasons) neither to pay (like in the case of assembla)
<putrycy> vila: you wrote it in a context of plugin? If it's not too hard to write such a soft and I will have some free time then perhaps...
<putrycy> Would be usefull, I think
<vila> putrycy: yes
<putrycy> OK, thanks a lot once again
<vila> I think the subject of pushing to multiple places at once has been raised in the past, you may get a larger feedback by writing to the mailing list
<putrycy> with my english skills it's a bit dangerous....
<putrycy> :D
<putrycy> I wonder how did you understand me...
<putrycy> ;)
<vila> putrycy: you're doing *very* well, and non-native english speakers tend to focus a bit more in their discussions, it helps ;-)
<goundy> Hi guys
<goundy> I've an ftp that I use as a bazaar repository
<goundy> and I'd like to add the possibility to browse the sources online (web-front)
<goundy> But, I do only know loggerhead, which is written in python, and works with bazar server
<goundy> Is there any simple alternative that browse the source directly from storage ?
<goundy> Thank you very much
<Daviey> goundy: erm, you can use loggerhead with access to a local bzr repo, don't need to have a bzr server running.
<goundy> Daviey, but I still do need python and this is the problem :p
<goundy> cuz I own a simple FTP that I got from a free hosting service
<goundy> Daviey, isn't there any php based bzr browser ?
<Daviey> goundy: http://wiki.bazaar-vcs.org/WebInterfaces <-- is your options :)
<goundy> oh didn't see that page
<goundy> dude, thank you very much
<Daviey> goundy: no worries
<jam> morning all
<Joyer```> evening at asia~
<bialix> ~~~
<jelmer> jam: ping
<jelmer> hi bigjools
<jelmer> *bialix
<jam> morning jelmer
<bigjools> enjoying your vacation jelmer? :)
<jelmer> irssi is trying to be smart since I talk to bigjools more often :-)
<jelmer> bigjools: yeahp, thanks :_)
<jelmer> jam: I was curious, is there anything I can help to move ~jameinel/bzr/2.2.0b2-pack-collection forward?
<jam> you could work on it. :), but nothing specific
<jam> I've just been working on other things recently
<nphase> "bzr: ERROR: exceptions.ImportError: cannot import name XMLSerializer " <- where can I get XMLSerializer? i'm not seeing much by way of the googles
<nphase> yeah. when i run bzr branch
<nphase> "ImportError: cannot import name XMLSerializer"
<jelmer> I think mthaylor was seeing that problem as well
<jelmer> not sure how he resolved it
<nphase> hm
<nphase> jelmer: if only he was around :(
<jelmer> nphase: probably off enjoying his weekend
<nphase> jelmer: overrated!
<james_w> nphase: one of your files wasn't updated when you installed a newer bzr
<nphase> ah
<nphase> ill uninstall the old one
<james_w> I don't know why it's happening
<james_w> we haven't found a hash collision or something have we? :-)
<nikin> hy... can someone tell me why bzr-gtk depends on technically everything? including pulseaudio?
<nphase> james_w: yep, that did it. thanks :)
<james_w> np
<goundy> Hi
<goundy> Question: I use bazaar in FTP mode, but when I connect to my FTP using an ftp client, I can't see my branches
<goundy> but if I do bzr branch ftp://..... I can checkout and push my branches... how come ?
<dash> goundy: is there a .bzr directory?
<goundy> dash, I can't even see it
<goundy> that's really weird
<goundy> But I tell ya, my branches are really there lol
<dash> does your ftp client hide directories starting with .?
<goundy> No I disabled this
<goundy> I want this solved to be able to see all branches I create
<goundy> since I didn't find a bzr command that lists branches in a shared repository
<goundy> that's really weird stuff
<lifeless> jam: hi
<lifeless> jam: do you have a recipe for getting a meliae dump from a plain old python process that has gone rogue ?
<jam> lifeless: hi, I do not. I would presume you can interrupt it using gdb, and then somehow get into a python interpreter
<jam> but I don't know how to do that
<goundy> dash, no hints ?
<slestak> dash: dang, man, you get around
<slestak> im having some issues with the current unix (aix) builds of bzr.  I have talked a bit with the maintainer and another maintainer of the package giving me problems.
<slestak> it has to do with conflicting python packages.
<slestak> i think I am just going to build this from src myself.  I understand the c routines are just additional helpers for speed, not required.  Is that true or are they highly recommended or mandatory?
<slestak> or in other words, can I run pure python bzr?
<beuno> slestak, yes you can
<slestak> ive been around and around with this problem, and just need some bzr.  (or cowbell, not sure which)
<dash> slestak: if you've got a C compiler and headers for python it shouldn't be a big deal to build the C extensions
<slestak> the problem i was running into is chris requires the use of his 2.6.2 python rpm for his bzr build.  I use mike perzls rpm on 2.6.5.  There is a library difference that makes these two incompatible.  (.a vs .so)
<slestak> i could use this liek a month ago, so time to move forward.
<dash> sure
<slestak> question, I have been using bzr in all kinds of places.  wonder if this is a best practice.  One example I questioned was in my rsyslog.conf and rsyslog.d for a central loggig server.
<slestak> since .bzr is hidden, othe rteam member may not be aware that a random file in a dir (/etc) is even versioned at all.
<slestak> does that seem liek a misuse to use at that micro-level?
<dash> yeah versioning /etc is a nice idea but tricky
<slestak> that just seems marginally valuable.  prob need to think of another solution.
<fullermd> Eh, I do it.
<slestak> i'd really liek to version my icinga configs as well
<fullermd> Figure that if nobody else ever uses it but you, that's still at least a LITTLE better than no versioning at all, right?
<slestak> fullermd: all of /etc in one repo, or many small repo's?
<fullermd> Well, I version the whole thing, sorta, but I only cherrypick maybe the half dozen files that really get edited on any given box.
<fullermd> And ignore everything else.
<slestak> fullermd: granted.  better than the typical foo.sh, foo011410.sh, foo.sh.bak, foo.sh.dont discard...
<fullermd> But places like under /usr/local/etc/ there are usually several small branches.
<fullermd> And on boxes that other people admin too, I yell and scream and throw hissy fits until they start checking in their changes.
<slestak> interesting commint messages, Jim changes this crap, wish he would log too
<fullermd> Yeah, I've made a few of those  :p
<slestak> i just wonder if maybe there should be a visual indicator in teh dir that a repo exists.  the tortoise* apps do with emblems.  why is this not necessary/helpful for console users?
<fullermd> `touch USE_BZR_FOR_THIS_YOU_IDIOTS`
<jelmer> moinmoin fullermd
 * fullermd waves at jelmer.
<slestak> bom dia
<slestak> fullermd: i think that would be sufficient.  May add it as a init hook to make it by default, and add it to .ignore
<slestak> hey, a plugin!
#bzr 2010-04-17
<xnox> what types of trees can live in the filters.ContentFilerContext().source_tree()?
<xnox> I'm trying to add a new keyword Revno
<xnox> -keyword_registry.register('Rev',
<xnox> -    lambda c: c.source_tree().get_revision_id())
<xnox> works
<xnox> +keyword_registry.register('Revno',
<xnox> +    lambda c: c.source_tree().branch.revision_id_to_dotted_revno(c.revision_id()))
<xnox> doesn't
<nikin> hy again... i already asked the question before... but why does bzr-gtk depend on things like pulseaudio?
<xnox> nikin, Depends: bzr (>= 1.17~), bzr (<< 2.2~), python-gtk2 (>= 2.8), python-glade2 (>= 2.10), python-notify, python (>= 2.4), python-central (>= 0.6.11)
<xnox> nikin, one of those depends on pulseaudio
<dash> xnox: that's the problem of the maintainers of those other packages probably
<xnox> through the chain of dependencies
<nikin> i understand... so its a package maintaining bug.
<nikin> thank you... so i wait for a gui with less deps before i leave the command line.
<xnox> More general questions: can a content filter assume there will be a branch in the ContentFilterContext available?
<xnox> or how a content filter find out which branch it is on right now
 * Joyer` 
 * Joyer 
<xnox> I take my frustrated comments back!
<xnox> Bzr rocks =)
<dash> hooray :)
<xnox> dash, got keywords plugin to output CurrentRevno, CurreentRevid as well as last Revno file was modified in
<xnox> working on the testsuite now
 * xnox knows I was meant to do it the other way around
<xnox> actually testing helps.
<xnox> I'm nowhere near to being finished
#bzr 2010-04-18
<xnox> almost done =) soon will push & do merge request
<xnox> keywords plugin can now update files in the working tree on post_change_branch_tip
<xnox> including current revno & current revid of the tree =)
 * xnox says bzr kicks svn =)
<dcoles> Is it possible to use bzr-git to push to a git branch other than master?
<Shin-LaC> your standalone windows installer hoses the path environment variable on windows server
<Shin-LaC> I had path=%path%;c:\program files\python\bin (etc.) in the administrator user's settings
<Shin-LaC> the installer took that entry, removed it, appended c:\program files\bazaar (or whatever) to it, and used that value to overwrite the *system* path variable
<Shin-LaC> as a result, all of the standard path locations (eg system32 etc.) were dropped from the path
<Shin-LaC> breaking a multitude of programs (you wouldn't believe how many things depend on having "more" on the path)
<mathrick> Shin-LaC: https://bugs.launchpad.net/bzr/+bug/565963
<ubottu> Launchpad bug 565963 in bzr "Windows installer incorrectly modifies %PATH%" [Undecided,New]
<mathrick> reported it for you. but if you want to subscribe, you'll need an account
<Shin-LaC> thank you!
<mathrick> you're welcome
<Shin-LaC> hm
<Shin-LaC> I hope it wasn't actually the guy who worked on that machine before me who hosed up the path
<mathrick> Shin-LaC: try it? Uninstall things, make sure the path is correct, try installing, see if it broke?
<Shin-LaC> I have a VM with windows server 2008
<Shin-LaC> I'll try the installer on that
<mathrick> good
<mathrick> just make sure the %PATH% setup is sufficiently complicated
<Shin-LaC> blagh
<Shin-LaC> activating windows...
<mathrick> Shin-LaC: you might want to snapshot it before you hose it
<Shin-LaC> sweet
<Shin-LaC> Content from the website listed below is being blocked by the Internet Explorer Enhanced Security Configuration. http://www.bing.com/
<virus_found> Hello. How do I: 1) know current rev number of a working copy (local); 2) know global revision number (knowing only its internet address); 3) get a changelog (log) between $rev1 and $rev2 ?
<Shin-LaC> ok
<Shin-LaC> never mind
<Shin-LaC> it was the other guy who hosed the path settings on his server
<Shin-LaC> no problems on my VM
<Shin-LaC> mathrick: sorry, you can recall that bug report
<mathrick> Shin-LaC: okay, so mark as invalid?
<Shin-LaC> yes
<Shin-LaC> or delete it entirely if possible
<mathrick> nah, that's exactly what "invalid" means
<mathrick> done
<mathrick> btw, is there any plan to make it possible to request merges for particular revnos in launchpad?
<virus_found> Ehm, bzr revno $url shows remote revision number, that's ok. But how do I get the rev number of current local working copy? I made bzr up -r 100, but bzr revno shows me remote number all the way. I need it to show me "100". Is it possible?
<mathrick> virus_found: you don't, there's no such thing as "current working dir revno". The working dir is, by definition, files on disk, not a tree state
<mathrick> you can compare the working dir to some revision, but there's nothing to tell you it corresponds to a particular revision
<mathrick> virus_found: also it seems like you're referring to a lightweight checkout of a remote branch? If so, then yes, the UI for that sucks in this regard
<virus_found> Ok, bzr st shows me, that current copy is old.
<virus_found> Then how to get a changelog between my copy and the global one?
<virus_found> Say, my copy is at rev 100, global is 111. How to get log between 101 and 111?
<virus_found> Or 100 and 111
<mathrick> virus_found: if by "global" you simply mean the latest, then it's bzr diff
<mathrick> but again, are you working on a full branch or on a lightweight checkout?
<mathrick> the answer differs depending on that
<virus_found> I mean the latest rev, that's on the server.
<virus_found> I did bzr co
<virus_found> Does bzr branch provide more ways of performing my task?
<virus_found> bzr diff shows nothing, despite the fact, my working copy is old.
<mathrick> virus_found: more like different. Lightweight checkouts differ from other ways of fetching the branch in that they don't maintain a local state and refer to the remote location for everything
<mathrick> but co without --lightweight creates a bound branch, which is a real branch, just tied to the remote location
<virus_found> Hm.
<mathrick> virus_found: if you did bzr co lp:some-project -r 100, then bzr diff will show you nothing
<virus_found> Then I'll do bzr branch
<mathrick> virus_found: wait
<mathrick> because the local branch is at that revision
<mathrick> if you want to compare branches, then bzr missing is what you want
<virus_found> Ok.
<mathrick> virus_found: you can also use bzr diff --new=lp to see the difference in source text and not in revisions
<mathrick> it all depends on what you want to see and how you arrived there
<virus_found> bzr co $smth ; bzr up -r 100 ; bzr missing $smth    results in "Branches are up to date."
<virus_found> But the $smth is at 111
<mathrick> hmm, lemme check
<virus_found> Maybe it's due to checkout?
<mathrick> virus_found: oh, right
<mathrick> up operates on the working tree
<virus_found> I can do branch if it helps
<mathrick> missing operates on branches
<mathrick> you first did a full checkout
<mathrick> so the local branch *is* up to date
<virus_found> Yes.
<virus_found> Then I'll do "full" branch :)
<mathrick> virus_found: so it's back to my first answer, your question has no answer because the working tree is not versioned, by definition. Only the tree is. So there's no way to tell that it's at revision something or other
<mathrick> virus_found: just do bzr up -r 111
<mathrick> s/the tree/the branch/, to make it less confusing
<virus_found> If I do branch, how do I make it "old" (to check "missing" after that)?
<virus_found> up -r ?
<mathrick> virus_found: Ã¦h? I think you're too confused now
<mathrick> why'd you want to make it old?
<virus_found> :)
<mathrick> what is it you're trying to do in the first place?
<mathrick> virus_found: again, branching won't change a thing, because you're asking a question without an answer
<virus_found> I need to check: 1) if my branch or whatever is older, that on the server; 2) get a "diff" or "log", what's the actual difference.
<virus_found> Actually, cvs, svn, darcs, git and hg    all have means of performing my task. It's hardly believable, that bzr can't do it.
<mathrick> virus_found: why do you need to check if you just asked for a way to make it "older"?
<mathrick> that's not what you're trying to do, please tell me what your goal is, not how you think it should be done with bzr
<mathrick> this way it'll be easier for everyone to understand
<virus_found> I do bzr co or bzr branch. (at rev 100). Time goes. Some commits happen to the server (lp:blah). I want to check, if there were any commits on it. And if so, get a changelog.
<mathrick> virus_found: bzr missing. But bzr up -r 100 is a different thing and that's why it doesn't work, because what you describe abov is *not* what you did with bzr up
<mathrick> virus_found: and actually, git doesn't have any means of doing this. You need to fetch the remote branch before you can compare it
<virus_found> git fetch && git log --date=local ..origin/master
<mathrick> that's what I said
<mathrick> it's not telling you about the remote branch
<mathrick> it's telling you things about your local copy of it
<mathrick> OTOH, bzr missing will tell you about any branch, including remote ones
<virus_found> Ok, I don't mind fetching. I'd like it to tell me what has changed :)
<mathrick> virus_found: if you want to see what changes have happened between branches, bzr missing is the command you want
<virus_found> Without flags?
<virus_found> I wanted to make my copy "older" to emulate time going :)
<mathrick> virus_found: if no flags are given, it uses the remembered pull location. If none is found, it errors out. But you can set a default pull location and then you don't have to specify anything
<mathrick> bzr missing lp:someproject if you want to be explicit
<mathrick> virus_found: bzr up does *not* operate on branches. It updates the working tree. That's where you went wrong
<virus_found> I see.
<mathrick> if you wanted to check out an older revision (which is a perfectly fine thing to do), it's bzr co -r 100
<virus_found> Great.
<mathrick> notice that the revspec is given to a different command
<virus_found> I'm sorry, but would "bzr missing" work, if I did bzr co --lightweight  ?
<mathrick> no, because lightweight checkouts operate completely differently, and are frankly just confusing
<mathrick> well, they're useful, but most of the things bzr will tell you will be confusing
<virus_found> Ok, I see. Thank you vey much for your time.
<mathrick> virus_found: the problem with lightweight checkouts is that they refer to the remote branch for *everything*. So if you say bzr revno, it'll do as you say and give you the revno of the remote branch
<mathrick> which is pretty much never what you want
<mathrick> the UI here could use a lot of improvement
<mathrick> virus_found: no problem. Though I'd suggest asking questions about your actual goals in the future, it's way easier to answer those
<virus_found> Perhaps, yes :)
<virus_found> mathrick: I'm sorry to bother again, simple question. How do make it stop generating the log file ~/.bzr.log    ?
<mathrick> virus_found: I don't know if there's a way. It generally does it when there's been an error. It's an important clue if something goes astray, so I wouldn't want to disable it
<virus_found> Ah, I don't have an ID.
<virus_found> Ok.
<RumblePure> hi all
<RumblePure> I commited back to my main branch from my laptop, and now one file is all messed up.
<RumblePure> The file contains stuff like "<<<<<<< TREE".
<RumblePure> and also ">>>>>>> MERGE-SOURCE".
<RumblePure> These things are written on a few lines.
<mathrick> RumblePure: read what bzr tells you when you merge :)
<mathrick> you have a text conflict, and these are markers to tell you which parts of the file come from which source
<mathrick> RumblePure: `bzr conflicts' should list files that are conflicted
<RumblePure> mathrick: I didn't merge, I committed back from the laptop.
<mathrick> what do you mean by that?
<mathrick> bzr won't let you commit to a diverged branch
<mathrick> you have to merge first
<RumblePure> mathrick: I have done bzr conflicts. It gives nothing.
<mathrick> okay, describe exactly what you have done to get there
<RumblePure> Ok... hope you have aspirine pills close at hand...
<RumblePure> I didt bzr checkout bzr+ssh from my laptop so I could continue my work from the laptop.
<RumblePure> Having worked with my code over a few days and committed locally on the laptop, it was time to put it back on my stationary, where the main branch is.
<RumblePure> So yes, initially I checked out the code from my stationary, through ssh, to my laptop.
<mathrick> RumblePure: so that'd be me@laptop$ bzr co bzr+ssh://desktop.me/repo/project ?
<RumblePure> When I wanted to commit back to my stationary, it had a new ip-number and like always I had to open branch.conf and manually change the ip-number.
<RumblePure> yes mathrick, exactly. I did that on my laptop a few days ago.
<mathrick> RumblePure: okay, what do you man by "commit back to my stationary"?
<RumblePure> mathrick: well, after having changed branch.conf, I do "bzr commit --strict"
<RumblePure> And that is when my problems start.
<mathrick> wait
<RumblePure> Bazaar talks about conflicts with the main branch, suggesting I do "bzr update".
<RumblePure> And when I do bzr update, I get these new files called "foo.php.BASE" and similar names.
<mathrick> RumblePure: so you were doing bzr commit --local while working on your laptop?
<RumblePure> mathrick: yes, I thought that was standard procedure....
<mathrick> yes, I'm just making sure
 * RumblePure is ready to get barked at. :-)
<mathrick> RumblePure: well then, you still have conflicts
<mathrick> didn't bzr update tell you that?
<RumblePure> mathrick: yes, and when I have done bzr update it suggests I do bzr conflict file_name.
<mathrick> and it's right :)
<mathrick> RumblePure: you got text conflict, it's that simple
<mathrick> have you committed anything to the stationary branch in the meantime?
<mathrick> you or anyone else?
<RumblePure> mathrick: but how come? I didnt touch my code on the stationary after checkout.
<RumblePure> NO, strictly no!
<RumblePure> This time I have been super duper truper careful with NOT doing that.
<RumblePure> Because this is not the first time i have this kind of problem!
<mathrick> okay, then bzr got confused about what your tree is, somehow
<RumblePure> mathrick: does it have to do with the fact that my ip got changed on stationary?
<RumblePure> I did modify .bzr/branch/branch.conf after all....
<mathrick> not sure, it shouldn't, but then I suspect I don't have a full picture of what happened yet
<mathrick> RumblePure: bzr pays no attention to IPs, only the tree states are of interest, and these are immutable and identified by hashes
<mathrick> but somehow you convinced bzr that the changes you made are already there
<RumblePure> mathrick: then I dunno what's going on.
<mathrick> RumblePure: let's debug it
<xnox> Reading bzr/docs/developer/testing didn't help much. Reading tests...... well there are loads of them
<mathrick> bzr log --show-ids bzr+ssh://desktop/repo/projects shows what?
<RumblePure> mathrick: ok, let me run that.
<mathrick> please paste the first ten or so commits in pastebin
<xnox> can you please suggest a good testsuite of a small plugin that extends standard bzr commands?
<mathrick> xnox: I have no idea about the testsuite, but the plugin pager extends standard commands in several places
<mathrick> *pager plugin
<RumblePure> mathrick: I will do shortly mathrick. I appreciate your help and want to get to the bottom with this. But please let me first fix that super important files that now has lots of "<<<<<< TREE" in it. The documentation says I should be able to resolve them manually.
<RumblePure> mathrick: and then I'll run your commands asap.
<mathrick> RumblePure: don't do that, because it's fixing things that shouldn't happen
<mathrick> your files didn't go anywhere, so spending time on fixing them is useless
<mathrick> determining what exactly went wrong is a much better use of your time
<RumblePure> mathrick: but I can see the changes that I have been working on my laptop. I can see them. It's just that they have been messed up with <<<<< TREE and such stuff.
<RumblePure> mathrick: ok, I'll cancel.
<mathrick> if you want clean copies of them, just branch the last revision of your laptop branch
<mathrick> it'll give you a nice working tree
<mathrick> RumblePure: when you're done, run the same thing for your laptop branch, and paste it in pastebin too
<mathrick> then link here
<RumblePure_> mathrick: ok done: http://pastebin.com/8H9t25V6
 * RumblePure_ is RumblePure from his laptop.
<mathrick> RumblePure_: that's the log for the stationary branch?
<RumblePure> mathrick: eyh yeah that's the log for the stationary when I ran that command from the laptop.
<mathrick> rumblePure: okay, could you give me the *exact* command you ran to do that commit? Just copy it straight from the history, without any editing
<mathrick> ie. the first command after which bzr told you to update
<RumblePure_> will do chief.
<RumblePure> ok, now I'll give an accurate recap of what I did.
<RumblePure> 1. I modified .bzr/branch/branch.conf, on my laptop, to match the ip-number of my stationary.
<RumblePure> 2. I did bzr commit --strict on the laptop, and that's when the problems started.
<RumblePure> 3. I did bzr update
<RumblePure> 4. I did bzr conflicts
<mathrick> rumblePure: okay, I'm beginning to suspect one possible scenario that could lead to that, and which'd mean a UI bug in bzr
<RumblePure> At this time I realized that a file php/cassandra/cassandra.php was screwing around.
<mathrick> lemme test that
<RumblePure> Ok, I'll continue to recap while you do that.
<RumblePure> 5. I did bzr resolve php/cassandra/cassandra.php (still on lappy).
<RumblePure> This produced some files called cassandra.php.BASE, cassandra.php.BASE.moved and etc.
<RumblePure> 6. I removed those newly created files, because they weren't on main branch on stationary and since I wanted to do a strict commit they had to be removed or added.
<RumblePure> 7. I finally managed to do my bzr commit --strict on the lappy. When I had done bzr update on my stationary, that very important file was messed up.
<RumblePure> There you go, my 7 steps to one hour waste of time. :'-(
<mathrick> rumblePure: first of all, that's not how you deal with conflicts
<mathrick> a conflict means bzr wasn't able to resolve changes automatically. Removing things without understanding the conflict is the wrong way
<RumblePure> Well, I had a feeling I was doing _something_ wrong. :-/
<mathrick> now, I've tried to do what you described, and it works just fine
<RumblePure> mathrick: ok, well then I dunno what is wrong. Should I do a step-by-step simple checkout and commit to and from my lappy to see if it happens again?
<mathrick> rumblePure: are you able to share these two branches? That is, could you zip up stationary's and laptop's branches and send them to me for testing?
<mathrick> rumblePure: yes, please
<RumblePure> no, can't share content of branches, sorry. :-/
<mathrick> and if it happens, give the exact history of all your commands, without any editing
<RumblePure> ok, will do so.
<mathrick> rumblePure: or maybe try doing that on fresh branches. Make a new branch, check it out to your laptop, edit as you would with your normal work, and then if it hits the conflict, zip them both up and send together with the command history
<RumblePure> sure, gimme a minute.
<RumblePure> ok, I have created a new dummy project and a bzr branch, let me check it out to the lappy.
<RumblePure> check out went fine, will play with the dummy file a bit and do some local check ins.
<RumblePure> *local commits
<RumblePure> I'll even go so far that I'll disconnect my stationary to obtain new ip-address.
<RumblePure> mathrick: are you there? I obtain the same error!
<RumblePure_> bzr: ERROR: Bound branch BzrBranch7('file:///media/disk/files/test/test/') is out of date with master branch RemoteBranch(bzr+ssh://purerumble@213.113.65.67:60000/home/purerumble/files/temporary-files/test/).
<RumblePure_> To commit to master branch, run update and then commit.
<RumblePure> haum, maybe printing that was a bad idea. :-/
<RumblePure> mathrick: If you want you can tell me now what to do in order to proceed and investigate the problem/bug.
<mathrick> rumblePure: that's not an error, the question is if you get conflicts after that
<RumblePure> mathrick: ok, so i'll do bzr update
<mathrick> proceed as you did with your normal work, ie. update and try to commit again
<RumblePure> mathrick: nope, no problems at all. At this time I'll give up.
<mathrick> rumblePure: then you had to do something differently
<mathrick> what I suspect might've happened is that you committed twice at some point, without realising
<RumblePure> mathrick: I didn't change the ip-number in branch.conf but you keep saying that shouldn't matter.
<mathrick> and because the IPs were different, it recorded different revids
<jml> how could I use bzrlib's mail APIs to build and send an email with a binary attachment?
<mathrick> rumblePure: I said it shouldn't, but that doesn't mean it doesn't, we're trying to determine it. And since you said you'd do it, I assumed you did
<cyberswat> Hi, Is it possible to generate a report on a specific users commits in a projects?
<jml> oh huh
<RumblePure> mathrick: yeah i said that but this time my stationary refused to change ip-number. :-/
<jml> SMTPConnection.send_email accepts a MIMEMultipart object
<RumblePure> let me see if turning the modem off will convince it otherwise.
<RumblePure> so i'll probably go offline and crawl my way back up. :-/ but lemme first do the checkout so i can proceed if the ip is modified.
<RumblePure> ok i'll go offline now and be back.
<mathrick> k
<cyberswat> I'm trying to process the output of bzr log and retrieve all information on a specific user ... is there a known method for doing this?
<RumblePure> mathrick: ip-number wont change. BASTARD! :-/ You know how I can change the interface's mac address? I'm convince that would give me a brand new ip-number.
<mathrick> RumblePure: linux?
<RumblePure> mathrick: yes dont bark at me I'm doing a google-search right now. :-)
<mathrick> am not barking, just asking
<dash> cyberswat: bzr-xmloutput might be handy if you want to parse it from another program
<RumblePure> mathrick: I was kidding, but that's the normal comment you get on irc: "google" :)
<mathrick> RumblePure: ifdown eth0; ifconfig eth0 hw ether 00:01:02:03:04:05
<mathrick> I think
<cyberswat> dash: thanks .. we are looking for a quick report so it looks like output to a text file and then grep will get us there for a short term fix
<RumblePure> ok, i'm going down again and will reappear.
<mathrick> s/eth0/proper iface name/ of course
<RumblePure_> mathrick: I've got the new ip-number, so I'll proceed now.
<RumblePure_> mathrick: Just what's a bit spooky is I've got the modified mac-address even after reboot. :-/
<RumblePure_> mathrick: Problem/bug reproduced!
 * RumblePure is testing on laptop.
<RumblePure> mathrick: Ok, one thing that I remembered to do is to do a bzr commit --strict without modifying branch.conf. I've always done this accidentally before realising that the conf-file must be changed.
<RumblePure> mathrick: So then I modified branch.conf and then did bzr commit --strict, and now I get this error:
<RumblePure> mathrick: I get this error: http://pastebin.com/9szZAAnL
<mathrick> rumblePure: okay, lemme try to reproduce it, and in the meantime please zip up both branches, and the command history
<RumblePure> mathrick: so you think somethings is wrong here?
<RumblePure> mathrick: gimme an e-mail address.
<mathrick> rumblePure: if you could reproduce it, then something is going wrong
<mathrick> though I just tested with local bound branches, and it works fine even after I change the location
 * mathrick checks with his checking out off his desktop machine
<RumblePure_> remember, I get a new ip on stationary and change branch.conf on laptop.
 * RumblePure_ is writing down command history
<mathrick> rumblePure: btw, you should be able to use avahi to get symbolic names for the machines automatically, so that you don't need to edit IPs
<mathrick> rumblePure: it should be available in ~/.bash_history
<RumblePure_> mathrick: what's your e-mail?
<mathrick> rumblePure: I sent it to rumblePure in /msg
<RumblePure_> mathrick: you should have it now.
<mathrick> yu[
<mathrick> *yup
<mathrick> lemme try recreating this
<RumblePure_> mathrick: now, would you please let me know how I can get my old mac-address back? :(
<mathrick> RumblePure_: it should be back after reboot normally, I dunno why it preserves it. What's your distro?
 * mathrick senses some redhat madness
<RumblePure_> mathrick: this is how God screws around with me; whatever small amount of time of my free time I can spare for my project gets consumed by problems with stuff like revision control. :'-(
<RumblePure_> mathrick: I use Kubuntu (no surprise there). :)
<mathrick> maybe you were being naughty
<RumblePure_> mathrick: i dont drink. i dont smoke. i dont do drugs. i dont even have a girl.
<mathrick> RumblePure_: also I think setting 00:00:00:00:00:00 as the mac restores the default, but lemme check
<mathrick> RumblePure_: consider starting smoking, drinking, drugs and girls then :)
<RumblePure_> mathrick: yeah, just to balance things out. LOL! ;)
<RumblePure_> mathrick: oki you got my e-mail and I'll hang around. Now I'll start working on my project if no one minds. :-/
<mathrick> RumblePure_: sure, I just recommend branching the last revision of your laptop branch and working on that without committing to the stationary yet
<mathrick> you'll avoid dealing with the conflicts this way
<mathrick> RumblePure_: btw, lshw -class net will show you what should be original MAC addresses
<RumblePure_> mathrick: ok will use lshw -class later.
<RumblePure_> mathrick: Regarding the file that was screwing around, I fixed it with brute force. It didnt have many issues (not many "<<<<<< TREE") so it was ok.
<RumblePure_> But mathrick, I've got something else weird to report.
<RumblePure_> This problem that arises, that bzr says there are conflict problems with some file when compared to main branch after changing ip-number... it _always_ happens only for a single file!
<RumblePure_> I just checked other files that I had been working on on my laptop. They are prime and good.
<mathrick> RumblePure_: okay, this is very weird, I did more or less the same and it works just fine
<mathrick> only thing is that I didn't change the IP but the symbolic host name
<mathrick> RumblePure_: what does bzr --version say?
<RumblePure_> 2.0.2 ...........
<RumblePure_> what version do you have?
<mathrick> RumblePure_: okay, please paste the output bzr plugins -v
<mathrick> 2.1.0 here
<RumblePure_> why won't mine update? I've got repositories.
<RumblePure_> Oh wait, maybe I'm using ubuntu's repositories.....
<mathrick> 2.1.0 is not in the main archive I believe
<RumblePure_> 2.1.0 is not stable?
<mathrick> anyway, that's beside the point, if it's always one file, I suspect there are external factors at play
<mathrick> it is, but that doesn't mean it'll be pushed to released versions' repositories
<mathrick> and the bzr distribution in ubuntu has changed recently, I'm confused about the exact details
<mathrick> 2.0.2 is recent enough, I'm more interested in the plugins you run now
<mathrick> because something is clearly touching a single file
<RumblePure_> http://pastebin.com/0jtH9s5p
<mathrick> RumblePure_: and it happened in test.php as well you say, in the test repo?
<RumblePure_> I've not played around with plugins to my knowledge.
<RumblePure_> yes, test.php
<RumblePure_> and in my main project repo, it happens to a specific file.
<mathrick> hmm, nothing suspicious
 * mathrick moves to looking at the zipped repos
<mathrick> that might take some time
<RumblePure_> mathrick: but you didn't change the ip-number. couldn't be that?
<mathrick> RumblePure_: it's very odd, since nothing of this sort happens here
<mathrick> RumblePure_: I changed the hostname
<RumblePure_> mathrick: change the ip!
<mathrick> that should be enough, if it's triggered by the remote host's name
<mathrick> will try that later
<RumblePure_> mathrick: well maybe it fetches the ip number in the end and somehow uses that (for hashing or such).
<RumblePure_> mathrick: maybe changing hostname doesnt matter because it does something to ip on some lower level.
<mathrick> it still shouldn't affect anything
<RumblePure_> but this problem should not arise in the first place! so what difference does it make that it _shouldn't_ affect anything?
<RumblePure_> this is a bug, so all bets are off! :)
<RumblePure_> for instance, maybe somewhere in the source code some other subroutine is used when connecting via ip-number and that subroutine is faulty. It is far fedged I know but possible.
<mathrick> RumblePure_: the zips you have sent me have a terribly unusual directory structure. I suspect that might not be unrelated
<RumblePure_> mathrick: it's a test-directory, containing a test.php and the .bzr.
<RumblePure_> mathrick: and you say my faulty use of faulty directory structure causes this problem arise, but only if I change the ip-number?
<mathrick> RumblePure_: and the zip has paths like ../../../../../../home/
<mathrick> RumblePure_: I'm saying there's something fishy, and I can't extract these zips
<RumblePure_> mathrick: euh, where do you see that cause I cant recall that?
<mathrick> branch_on_laptop.zip you sent me
<RumblePure_> mathrick: what's wrong?
<RumblePure_> RumblePure: let me package them again.
<mathrick> /../../../../home/purerumble/files/temporary-files/test/
<mathrick> for instance
<mathrick> that's from the stationary
<RumblePure_> mathrick: where do you see that in the zip? in what file?
<mathrick> no idea what happened here, but it's not normal
<mathrick> in both zips you sent me
<mathrick> there's a single directory called ".." at the toplevel of the file
<mathrick> in it is a single directory called ".."
<mathrick> etc.
<RumblePure_> mathrick: making tar.gz now
<RumblePure_> mathrick: there, you should have two tar.gz files now.
<mathrick> RumblePure_: it has the same paths, how are you creating them?
<RumblePure_> i use the gui in kubuntu.
<nitian> when i do bzr merge i get : bzr: ERROR: No location specified or remembered ?
<RumblePure_> let me do command-style
<mathrick> RumblePure_: it's okay, I can extract them
<mathrick> it's just odd
<RumblePure_> mathrick: I can run tar from bash to get you the tar.gz files if you want me to.
<mathrick> nitian: you have to say bzr merge bzr://some.brach/or/another/
<mathrick> the first time anyway, it will remember it for subsequent uses
<mathrick> RumblePure_: nah, it's okay
<RumblePure_> ok, now let me see if I can get some darn work done here. :(
<mathrick> RumblePure_: out of curiosity, could you please run `bzr status .directory' in any of your branches?
<RumblePure_> not to say it hasn't been fun tracking this problem/bug down. :) Cause it has really been auhm, educating. :)
<RumblePure_> mathrick: oh oh, I forgot about that.
<RumblePure_> my distro keeps creating these .directory files in every directory.
<mathrick> yes, it's KDE doing that
<mathrick> and bzr --strict doesn't complain about it?
<RumblePure_> On my main project, I tell bzr to disregard from .foo.bar files
<RumblePure_> mathrick: euh, why should it complain when it was added to the branch from start?
<mathrick> dunno
<RumblePure_> now i dont have the konsole open to check, but if the .directory was there from start and i did bzr init & bzr add then the file would have been added.
<mathrick> it doesn't add .dotfiles by default I believe
<RumblePure_> are you sure? cause if it doesn't then you got that file by misstake only. then please disregard from it
<RumblePure_> but oh ok i'll do bzr status
<mathrick> RumblePure_: okay, I have absolutely no idea how you got there, but that history graph is NOT right
<RumblePure_> mathrick: ....... what history graph?
<mathrick> of your branches
<mathrick> both of them show rev 2 as a merge, and basically neither has the original changes in the mainline history
<RumblePure_> still dunno what you're talking about.
<mathrick> that's wrong
<nitian> mathrick: would this work too: bzr merge lp:something
<mathrick> RumblePure_: bzr log stationary
<mathrick> nitian: yes, and branch spec will work
<mathrick> including plain directory paths and whatever else you might have registered
<nitian> mathrick: where there is a : bzr branch lp:something
 * mathrick has colo:origin/trunk for instance
<RumblePure_> mathrick: bzr log > http://pastebin.com/RUqzvwtA
<nitian> mathrick: ok.what is a branch spec? :)
<mathrick> RumblePure_: oh, I know, I was telling you what history graph. Re-run the same command with -n0 added
<mathrick> notice the indented revisions
<mathrick> does it look familiar?
<mathrick> now notice how neither branch has them non-indented, as if both merged from the other
<mathrick> I don't understand how you got there
<RumblePure_> mathrick: just look at the dango commands i sent ya
<mathrick> nitian: anything bzr understands to be a location of a branch. That includes http://, bzr://, /path/to/dir, lp:something, and whatever else plugins might register
<mathrick> RumblePure_: that's what I'm doing sir
<nitian> mathrick: ok. thanks :)
<mathrick> it doesn't make it any less baffling
<RumblePure_> mathrick: look, if it hasn't crossed your attention by now then yes, I'm a newb with capital letters. But I've sent you step by step instr on what I've done to end up here. You're the expert so you tell me what's causing this.
<RumblePure_> mathrick: and if there is anything else I can do then tell me and it will be done.
<mathrick> RumblePure_: I know you're a newb, and I'm trying to explain the problem to you so you have a clue too. Just because I have used bzr for some time doesn't mean that graph starts making sense or that I see how it could result from the commands you ran
<mathrick> basically, what you got is impossible
<mathrick> or should be
<RumblePure_> mathrick: well don't overlook this simple observation that has been made: something freaky happens when I change ip!
<mathrick> okay, so this is how the UI for checkouts works apparently. I can't say it's in any way intuitive or sensible
 * mathrick notes to file a bug later
<RumblePure_> mathrick: yes, because I just did checkout and commit to/from laptop without changing ip-number and the indentation remains.
<RumblePure_> so that is working as they feel it should.
<RumblePure_> on both branches it simply stattes that revno 2 was a merge back to stationary. this makes sense to me, and I'm a newb... so you're just making it too complicated. :)
<RumblePure_> *states
<RumblePure_> mathrick: did you test changing ip-number? 'cause I really cant think of anything else that's causing this bug.
<mathrick> doing that now
<lifeless> moin
<rhkfin> commit - push - uncommit - undo changes - how do I now push the 'uncommit' to the push-repo??
<mathrick> you don
<mathrick> 't
<mathrick> well, not directly
<mathrick> perhaps push would establish a new tree tip, but anything with the deleted revision as the parent would continue to derive from it
<mathrick> in general, once you publish thing, unpublishing them is Hardâ¢
<dash> worst case, you can use push --overwrite
<rhkfin> So locally I'm now one version 'behind'..
<Manganeez> If you have shell access, you can go uncommit in the push-repo.
<rhkfin> Can I pull the rev, make new changes and make new commit?
<rhkfin> Manganeez: no shepp access.. Launchpad :/
<dash> remember that doing this is basically rewriting history, so you're breaking compatibility with any other branches
<rhkfin> mathrick: ok, so you always want to think before pushing..
<rhkfin> dash: push --overwrite, will check what it does..
<rhkfin> dash: hmm.. that's not what I want..
<rhkfin> compatibility needs to be stored..
<mathrick> RumblePure_: one question, when you commit from laptop without strict, do you have any uncommitted changes, or is that on a clean tree with everything previously recorded by commit --local?
<lifeless> rhkfin: push --overwrite
<rhkfin> So if I now push to a new repo, things will work and be compatible with other branches??
<lifeless> is what you need to do
<RumblePure_> mathrick: you mean "without local", right?
<mathrick> RumblePure_: yes
<mathrick> rhkfin: define "compatible"?
<RumblePure_> mathrick: no I don't have any uncommitted changes.
<Manganeez> I wanted to ask for advice on the best way to track a vendor subversion repository while maintaining my own local changes separately. Specifically, I want to track Wordpress, including being able to switch to a new version tag when one is created (as easily as possible), while committing my own customizations (which will never be pushed upstream) locally using bzr.
<mathrick> if anyone has branched / pulled the deleted repo, no, it will be incompatible
<RumblePure_> mathrick: everything has been committed.
<mathrick> RumblePure_: ok
<RumblePure_> mathrick: but remember that this is irrelevant if ip-number hasn't changed. because then it will work even if nothing has been modified since last local commit.
<rhkfin> mathrick: hmm.. I'll see..
<RumblePure_> mathrick: sorry for naging about the ip-numbers, just wanna point that out. :9
<RumblePure_> *:)
<mathrick> I know, I know
<mathrick> I have changed the I
<mathrick> IP even
<mathrick> Manganeez: bzr-colo with an origin/trunk branch might be a useful setup
<RumblePure_> mathrick: ... and......
<mathrick> Manganeez: but really, any branch should work if you don't ever want to push upstream. Bzr-svn is careful to assign reproducible revids
<rhkfin> mathrick: can I bzr pull http://pushedrepo (as it's now one version ahead?), then manually undo my last changes and make new commits & push, and compatibility with other pulled repos is maintained?
<rhkfin> extra commits are no problem
<mathrick> rhkfin: no, the compatibility will never be maintained once you back out an already published revision
<mathrick> it's impossible to do
<dash> rhkfin: if you want to undo a revision, you don't use uncommit, you use merge to back out the changes then commit that
<mathrick> if anyone has grabbed that repo, they will need to remove it manually
<rhkfin> pain..
<rhkfin> ok, I'll see if anyone already pulled the repo..
<mathrick> rhkfin: but look at what dash says, because it looks like what you want to do really
<dash> rhkfin: no need, just do it the sensible way :)
<dash> rhkfin: "bzr merge -r-2..-1 ."
<dash> this will apply the changs needed to undo the last revision
<rhkfin> dash: ok, I see..
<dash> rhkfin: so you just check that in
<dash> rhkfin: 'uncommit' is different, because it removes the commit from the branch entirely; this way just creates a new revision that undoes an old one.
<rhkfin> dash: I see now.. thanks for pointing that out
<dash> uncommit is handy for a local branch where you committed earlier than you meant to.
<Manganeez> dash: only branches created between the commit and uncommit would be affected, right?
<dash> but if the change has been shared, you can't really unshare it :)
<mathrick> Manganeez: FSVO "only"
<Manganeez> hehe
<rhkfin> on merge text conflict I solve it manually, right
<rhkfin> ?
<mathrick> yes
<Manganeez> so, on the subversion thing: I'd like something as close to this as possible: Checkout/branch svn-repo/tags/2.9.2; repeat: (make local customizations; bzr commit); New upstream ver! Switch to svn-repo/tags/2.10.0 (and merge?); bzr commit? repeat: (more local customizations; bzr commit). What's the easiest scenario?
<mathrick> Manganeez: bzr branch svn://repo/tags/2.9.2; ...; bzr merge --remember svn://repo/tags/2.10.0
<mathrick> as far as I know, it should Just Workâ¢
<Manganeez> Even better: I'd really like to have a centralized bzr repo for my customization (there are more than one of us working on it)
<mathrick> Manganeez: then you do the same, except you also have a cetralised branch that tracks upstream :)
<Manganeez> mathrick: thanks a heap - I hadn't seen --remember before....reading about it
<Manganeez> Oh, remember does almost nothing: the "just works" comes for free even without that, it seems
<Manganeez> wow - maybe I just messed up when I tried it. Retesting
<mathrick> RumblePure_: okay, I can't reproduce it. I'll have to direct you to more experienced bzr folks. lifeless seems to be awake, FWIW :)
<nitian> mathrick: if i stop(ctrl-c) a merge activity while it is running merge, would there be any problems?
<mathrick> no
<Manganeez> mathrick: the svn urls can be just http for subversion, correct? Sorry, I'm still in n00b-mode on bzr-svn
<mathrick> nitian: if C-c ever breaks things, it's a bug and needs to be reported
<mathrick> all bzr does is supposed to be atomic
<mathrick> Manganeez: yes
<nitian> mathrick: ok! so i could do bzr merge lp:something tomorow as well! actually i have to go ! and merge is taking lot of time. :)
<rhkfin> mathrick: dash thanks for your help, I think I got it now solved :)
<mathrick> nitian: that's some big trees you have there then
<nitian> nitian: and/or slow b/w! ;)
<nitian> mathrick: and/or slow b/w! ;)
<Manganeez> Is there a way to branch from an svn repo without the *full* history? I don't need the details on individual vendor commits.
<RumblePure> mathrick: do we give up for today? I'll update bzr later to see if the problem persists.
<mathrick> RumblePure_: yes, though you really need to grab someone more versed in bzr. It's beyond my ability to debug
<mathrick> Manganeez: no
<mathrick> it's a commonly requested feature, but it's not trivial
<Manganeez> yea, I can visualize how that might not be so easy
<mathrick> so it hasn't been implemented yet
<RumblePure> mathrick: ok. thx for all your time & help today.
<Manganeez> ditto on the thx to mathrick
<lifeless> Manganeez: RumblePure: whats wrong ?
<mathrick> no problem
<RumblePure> lifeless: Manganeez is not involved
<lifeless> Manganeez: sorry! I meant mathrick.
<mathrick> lifeless: RumblePure_ has been running into a bug where bzr up on a checkout causes conflicts with the bound branch, even though only commits on the checkout have happened
<RumblePure> lifeless: gimme your e-mail address and you'll have something that describes it all
<lifeless> what version of bzr are you using ? We recently changed the algorithm bzr uses for update
<RumblePure> lifeless: 2.0.2
<lifeless> get 2.1.0 or newer
<lifeless> * ``bzr update`` performs the two merges in a more logical order and will stop
<lifeless>   when it encounters conflicts.
<lifeless>   (Gerard Krol, #113809)
<lifeless> is included in 2.1.0
<RumblePure> lifeless: did mathrick tell you that this only happens when the ip-number of the host keeping the main branch changes?
<mathrick> lifeless: how come it encounters conflicts in the first place?
<mathrick> lifeless: and while we're at it, why does update do merges at all? That makes no sense, it should fast-forward whenever possible
<lifeless> mathrick: well, its persumably a bug; the question is whether we have already fixed it.
<lifeless> mathrick: as for why it does merges, any time you integrate code its a merge
<lifeless> RumblePure: does the old ip stop serving ?
<lifeless> RumblePure: or are you using a CNAME or something ?
<RumblePure> lifeless: ? the ip of the stationary that keeps main branch is dynamic, so it changes. and on laptop i have to modify branch.conf
<lifeless> anyhow, the first thing to do is to check bzr 2.1.0 on th client
<mathrick> lifeless: but it hides revisions. What it does is turn purely linear history on a single branch into merges just because I happened to make some commits while disconnected
<mathrick> that's makes no sense at all
<RumblePure> lifeless: I wanna use this repository https://launchpad.net/~bzr/+archive. you know what i have to write in sources.list? I've got ubuntu karmic.
<mathrick> even the need to update is not clear, it should just push
<lifeless> mathrick: it will still be linear if no one committed to trunk
<lifeless> mathrick: it will however roll up your commits, because thats what you're asking it to do
<lifeless> mathrick: what bzr version are you using ?
<mathrick> 2.1.0
<lifeless> RumblePure: on the web page you linked are instructions
<mathrick> lifeless: how am I asking it to roll up?
<mathrick> ah, you mean by commit instead of push?
<lifeless> mathrick: and do you also get spurious conflicts ?
<mathrick> no
<lifeless> mathrick: yes, precisely.
<mathrick> I couldn't get any conflicts whatsoever
<mathrick> lifeless: presumably that's a UI bug and it should somehow suggest using push instead
<mathrick> TBH, I haven't even thought of using commit for that before, but I can see where that came from
<nitian> mathrick: would you please have a look here: http://pastebin.com/vQSkSht0
<mathrick> nitian: bzr info ~/proj says what about the format?
<nitian> mathrick: format: 2a
<mathrick> nitian: then the lp:something branch is old. I dunno how upgrading on lp works
<nitian> mathrick: how can i change the default push branch of bzr, it is showing something i had made while learning bzr. Related branches:     push branch: bzr+ssh://nazi@bazaar.launchpad.net/~nazia/%2Bjunk/myproject/
<mathrick> nitian: sure, --remember
<nitian> mathrick: whereas it should be bzr push lp:~nazia/something/myproject
<mathrick> nitian: bzr push --remember lp:~nazia/something/myproject
<nitian> mathrick: ok! :)
<nitian> mathrick: changed. thanks.
 * Manganeez is confused
<mathrick> why?
<Manganeez> bzr branch http://core.svn.wordpress.org/tags/2.7.1/ ; Make a comment change in one file for testing; bzr commit; bzr merge http://core.svn.wordpress.org/tags/2.8/; 41 conflicts in files I did not touch.
<rhkfin> Any idea why bzr push sftp://me@my.web.server only creates new folderbut with no data files in it, only .bzr folder
<Manganeez> rhkfin: push doesn't do an update
<mathrick> rhkfin: bzr help push
<mathrick> first paragraph
<rhkfin> great, thanks :)
<mathrick> Manganeez: hard to say, but might be because they were backporting changes
<rhkfin> OK, interesting.. so what's the way to get the folder populated? THe server doesn't have bzr installed...
<mathrick> Manganeez: svn doesn't exactly have robust merges, which ripples as you try to slurp from it...
<mathrick> rhkfin: there are plugins, such as push-and-update or rsync
<mathrick> browse the plugins listing on the website
<rhkfin> bzr plugins, c00l :)
<rhkfin> ok, thanks!
<Manganeez> I think push-and-update requires bzr installed on the server, because it just ssh's in an runs bzr update for you
<rhkfin> ok, so it'll not work..
#bzr 2011-04-11
<mgz> okay, that's nearly back to email stability.
<mgz> looks like jam fixed a couple of longstanding workingtree test issues.
<TJNII> If I'm reading the docs correctly bazaar doesn't implement its own network layers but instead wraps itself inside ssh, http(s), (s)ftp, etc... Does bazaar do any password authentication / storing itself, or does it delegate all that to the transport layers it uses?
<poolie> hi mgz
<poolie> TJNII, you can run plain bzr over tcp
<poolie> but it does not do its own encryption or authentication
<poolie> so plain bzr is really only for anonymous readonly mode
<TJNII> poolie: So it would be clear text passwords?
<TJNII> Will bazaar cache clear text passwords like svn?
<poolie> there are no passwords at all
<poolie> you should run over ssh
<TJNII> Got it
<TJNII> So bazaar itself doesn't use a password, it uses the permissions of the user / underlying authentication methods?
<TJNII> I've been reading the SVN book.  The svn command does take a password which, until recently, it would store in clear text on the disk.  That is a huge red flag for me and something I don't want.  So now I'm looking at bazaar and trying to transfer my newfound knowledge to it, which includes understanding the differences.
<mwhudson> TJNII: most people run bzr over ssh and so use whatever authentication they use with ssh (public keys mostly)
<TJNII> So how does bzr authenticate those users against the repository?  System username?  Filesystem permissions?
<fullermd> Strictly speaking, it doesn't, it just tries to write files it's told to.  Filesystem permissions would prevent that and make things stop, to be sure.
<mwhudson> depends which ssh server you're running
<mwhudson> using openssh, sure, it's the system user
<fullermd> The ssh or higher-level authentication just determines whether you can talk to bzr in the first place.
<TJNII> Aah, I think I've found my answer: "Bazaar provides a script called bzr_access that can be used to provide access control based on usernames, with authentication performed by SSH."
<TJNII> And so, bazaar doesn't handle any passwords itself, so I don't have to worry about how it handles said passwords.  Is this correct?
<TJNII> I know I'm asking the same basic question over and over again, but I want some certainty on this.
<fullermd> bzr doesn't even handle usernames.
<lifeless> TJNII: bzr depends on your ssh client to do password management
<lifeless> TJNII: there are many different ssh clients around, some that use keyrings, some that use GUIs, etc.
<TJNII> I think I've got it.  Thanks.
<poolie> o/ fullermd, mwhudson
 * fullermd wave at poolie.
<spiv> Good morning.
<poolie> hi there spiv
<poolie> o/ jelmer
<poolie> spiv, so are you going to pilot some more this week?
<poolie> hi jelmer
<poolie> the queue is still pretty big
<poolie> spiv also i'll update by command deprecation patch
<spiv> I managed to get the queue back down a bit but then jelmer and vila kept proposing patches!  https://code.launchpad.net/bzr/+activereviews
<spiv> Er, I meant: http://webnumbr.com/bzr-active-reviews
<poolie> yeah i saw
<spiv> There are worse problems to have :)
<spiv> I think you're on the roster for this week, but I keep can piloting this week if you'd like.
<poolie> i'll take the helm, but there's such a large number i think it'd be good if you keep reviewing too
<poolie> i'd like to work with vila on his config stuff
<poolie> well
<poolie> it's a bit fire and forget because i think he's going away from tuesday or wednesday
<spiv> Ok.  Mainly that leaves jelmer's patches.
<poolie> spiv is https://bugs.launchpad.net/bzr/+bug/721710 a dupe of something you already fixed?
<ubot5> Ubuntu bug 721710 in Bazaar "Not possible to pull or update using smart server in 2.3.0" [Medium,Confirmed]
<poolie> to do with locks getting tangled up on bound branches?
<spiv> poolie: fixed in 2.3.something, yes
<spiv> poolie: https://bugs.launchpad.net/bzr/+bug/733350 I think
<ubot5> Ubuntu bug 733350 in Bazaar "LockContention error when pushing (with new tag) to a bound branch" [High,Fix released]
<poolie> ok will you tell Nicholas or shall i?
<spiv> poolie: ah, fixed in lp:bzr/2.3, but not in a released version yet
<spiv> (Interesting data point for recent discussion about the meaning of "Fix Released", perhaps?)
<spiv> I'll do it
<poolie> indeed; thanks
<poolie> i might try to put that tweak into the kanban software later
<kgoetz> poolie: hi! about bug 756228 . what sort of information woudl you like about the bzr repo? i have a copy of it, so hopefully i can bashi it in any ways you need
<ubot5> Launchpad bug 756228 in Bazaar "bzr: ERROR: exceptions.StopIteration" [Undecided,Incomplete] https://launchpad.net/bugs/756228
<poolie> kgoetz, are the filenames secret?
<kgoetz> poolie: nope. anything you need. its a d-i checkout with my breakage added
<poolie> then please just attach a tarball of the repo to the bug and reopen ti
<kgoetz> sure
<kgoetz> poolie: added, thanks. repair-workingtree doesn't see issues with the repository, so i'll keep watching the ticket incse i need to provide anything else
<poolie> ok
<bradm> ok so hi
<poolie> lifeless, could you give bradm a clue how pqm finds the right chroot to work on
<poolie> hi
<lifeless> amd64
<lifeless> erm
<lifeless> pqm-amd64
<poolie> heh
<lifeless> to find it from first principles
<lifeless> start with the pqm crontab
<poolie> so mail comes in
<poolie> and is queued and run from cron?
<lifeless> which will tell you the pqm config file
<bradm> lifeless: ah so pqm runs via cron?  I didn't even know that much :-/
<poolie> the context is we want to switch it to a different chroot which is running lucid
<lifeless> look in the pqm config file, and it uses paths that point into the chroot + dchroot-run to run commands that DTRT cd wise into the chroot
<lifeless> all you should need to do to do that is have the chroot prepared and edit the bzr pqm config file
<bradm> lifeless: its a dist-upgraded copy of the existing chroot, so it should be ok I hope
<bradm> aha, found the path
<poolie> there is also a web server
<poolie> this is secondary
<poolie> it might need to be updated to look at a different path too though
<bradm> bzr-pqm.conf
<lifeless> the webserver doesn't look in the chroot at all
<poolie> the log is in a separate directory?
<poolie> bound under the chroot or something?
<lifeless> the progress stuff is done via stdout of the test process
<lifeless> straight into pqm, and it writes it to its own log area
<bradm> okey, thats updated to the new chroot, I can juggle the paths once we're happy with this
<poolie> sorry i don't understand
<poolie> 'happy with this' in the sense it can now be tested?
<bradm> well, assuming there's only one spot to change, yes
<bradm> I don't really know pqm very well, so I'm not really sure what else if anything needs to be done
<poolie> ok, i'll send something in and we'll see
<bradm> cool
<poolie> sent...
<bradm> ugh, found a typo
<bradm> there, fixed
<poolie> bradm, ok, it failed because python-docutils was not installed
<poolie> i think this means either bzr-build-dependencies (is that the right name?) is not installed, or it's missing that dependency
<poolie> the correct name is in the rt ticket
<bradm> poolie: oh, there's a python path pointing to python 2.4 as well
<poolie> or that
<bradm> poolie: python-docutils is definately installed in the chroot
<bradm> poolie: so I guess update from python2.4 to python2.6?
<poolie> update where?
<poolie> i mean, where is the thing set that you're going to change?
<lifeless> pastebin ftw
<bradm> there's a bunch of stanzas like https://pastebin.canonical.com/45898/
<bradm> I updated the chroot-amd64 to chroot-amd64-new, its the python2.4 bit I think needs to change to python2.6
<bradm> thats in pzr-pqm.conf
<poolie> oh, not a pythonpath as such
<lifeless> bradm: yes, the python value there needs changing
<poolie> i wonder if it would be better just to cut it out and use the chroot's default
<poolie> s//i think it would be
<lifeless> poolie: its set because of bzr's Makefile
<lifeless> poolie: IIRC
<poolie> surely we default to just 'python'?
<lifeless> $severalyearoldmemory
<poolie> i mean, i believe you, but i think bzr will do fine without $PYTHON set
<bradm> actually, hrm, I haven't seen where the chroots defined either
<lifeless> bradm: pqm doesn't know about the chroots per se
<lifeless> bradm: it knows about paths that are in the chroot
<bradm> lifeless: aha, right.
<lifeless> bradm: and it calls (per the config) dchroot-run which will chroot + cd + exec
<poolie> so it's set in /home/pqm/bin/dchroot-run
<lifeless> no
<poolie> or something reached from there
<lifeless> yes
<lifeless> dchroot-run queries dchroot -l
<poolie> probably /etc/dchroot/*
<bradm> right, and matches it up to the path, cool.
<bradm> that PYTHON variable is updated
<bradm> time for another test?
<poolie> bradm, can you just delete the PYTHON= thing?
<lifeless> bradm: I wrote that when the logic for pqm to do chroots was discussed and I was ... argh
<poolie> avoiding overwriting stuff unnecessarily is better
<bradm> poolie: *shrug* sure, if you'd prefer
<poolie> i would
<poolie> will save fixing it again if we go to natty or whatever
<poolie> also, would you mind please running 'dchroot -l' and tell me if you get any warnings about deprecated options?
<bradm> poolie: yes, there's warnings about the deprecated options
<poolie> thanks
<poolie> let's get this going first
<poolie> then if you want i can file a separate ticket asking for them to be updated
<bradm> okey, try that?
<poolie> k
<poolie> seems to be running ok
<poolie> it will take a fair fraction of an hour to complete
<poolie> hm
<poolie> would you like me to file a ticket about the warnings?
<bradm> um, I guess its probably worthwhile, they seem to be popping up wherever we use lucid and dchroot
<poolie> ok, rt 45200
<bradm> ta
<bradm> right, so if this works we can change the pqm-amd64 to be pqm-amd64-old and the new one to pqm-amd64 - leave the old one around for a bit, then get rid of it
<poolie> yep
<bradm> okey, let me know when the test has finished
<bradm> we can leave it for a while if you'd prefer more than one test?
<lifeless> whats the new chrood called ?
<bradm> pqm-amd64-new
<lifeless> heh cool
<lifeless> are you going to pivot it onto the old name once qa'd /
<lifeless> ?
<bradm> lifeless: yep, thats the plan
<lifeless> sweet
<bradm> lifeless: just didn't want any confusion - wel, any _more_ confusion
<poolie> bradm, i wonder if rather than switching it to the be pqm-amd64, it would be better to rename it to something like pqm-bzr
<poolie> blah
<poolie> pqm-bzr-amd64-lucid
<poolie> this would have saved some other questions earlier
<bradm> poolie: sure, that'd make it very clear what it is
<poolie> ok
<poolie> i'll let you know when this job passes or fails
<vila> hi all !
<vila> poolie: if it helps, I can put my proposals 'work in progress' before leaving
<vila> it would be nice to still review them before I come back though ;)
<poolie> hi vila
<poolie> i don't think you need to do that
<poolie> we can do it if they're cluttering things up
<poolie> or someone else may fix them
<poolie> bradm, ok, that test concluded
<poolie> wow that's pretty slow
<bradm> poolie: interesting, I wonder why its slow then
<bradm> poolie: maybe a python 2.6 thing?
<poolie> it's 7-year-old hardware :}
<poolie> it's no slower than it was in the other chroot
<bradm> poolie: ah, right.  I thought you meant it was slow compared to the other chroot
<poolie> there's a separate ticket discussing getting a faster machine
<poolie> anyhow, it finished, and failed
<poolie> i don't know if that was because of an actual bug in the branch or something in the chroot
<poolie> i might try another landing, maybe of a trivial branch
<bradm> poolie: sure
<lifeless> what was the error ?
<poolie> lifeless,  see https://code.launchpad.net/~jelmer/bzr/mutableinventorytree/+merge/57061
<poolie> hi spiv?
<spiv> Hi poolie
<poolie> spiv, hm, that really is a bit of a trap in lp that you can approve a dependent branch without the predecessor being approved
<poolie> i wonder if hydrazine should specifically check it
<poolie> it could
<spiv> poolie: yeah, I'd really like if LP made that more visible
<spiv> poolie: maybe even with a loud âhey are you sure you don't want to review X first?â notification box
<poolie> indeed
<spiv> And also by not stating it is âready to landâ on +activereviews
<poolie> ! indeed
<poolie> i think there are bugs for at least some of these
<spiv> It probably deserves a new section on that page, like âApproved but has unapproved prerequisitesâ
<poolie> lifeless, so does that failure seem to you like one caused by the chroot?
<poolie> it might be failing to import because it failed to build or something
<lifeless> is _FastPath a C / pyrex module?
<lifeless> if so, yes a build failure seems likely
<poolie> but there is nothing shown earlier in the output
<poolie> and it may also just be simply missing
<poolie> anyhow, i will look in a bit
<spiv> lifeless: no, just a regular class in bzrlib.mutabletree
<lifeless> an import failure there seems odd
<spiv> That patch is reorganising tree code a bit, it might be that jelmer's accidentally introduced a circular import or something like that.
<spiv> (i.e. for that error I'd suspect the patch before the chroot upgrade)
<bradm> we could flip the chroot back if you wanted?
<bradm> hmm, that bzr-landing-dependencies isn't installed, but for some reason that depends on python2.4 ?
<vila> bradm: the reason is the pqm is the only place testing against 2.4 to ensure bzr is still compatible with it
<vila> s/the pqm/that pqm/
<bradm> all of the dependencies are installed anyway
<bradm> vila: ah, cool
<vila> but lucid doesn't provide 2.4 anymore right ?
<fullermd> What, don't we have users for that?   :p
<poolie> yes i suspected something like what spiv said
<poolie> it will be easy to test
<bradm> vila: erm, its still installed
<vila> bradm: python 2.4 ?
<bradm> vila: yes
<vila> bradm: wow, great, then may be we should keep using it then, poolie ?
<bradm> vila: obviously just not removed after the dist-upgrade from hardy
<bradm> vila: interestingly it'll mean if you ever want to install the bzr-landing-dependencies somewhere it won't work until you find python2.4 debs somewhere
<vila> ha, erm, forget my remark then, I'm not familiar enough with chroots but istm that we shouldn't rely on it if it's just a fallout from the upgrade
<poolie> vila what is 'it'?
<vila> bradm: right, I think bzr-landing-dependencies was a work in progress needing validation :)
<bradm> vila: well, I think we just proved it wasn't right :)
<poolie> i think we should update that package to depend on python>=2.4 <3 or something
<vila> poolie: python 2.4, but it may rather be  a bug in bzr-landing-dependencies
<spiv> It's important to test against 2.4, but we could do that just as well via babune as in pqm itself.
<vila> bradm: indeed, hence my reamark ;)
 * vila nods
<vila> there are a couple of TODO items for that on babune, didn't find the time to get to them for... sometimes :)
 * fullermd expects vila's support in his campaign for 36 hour days...
<poolie> spiv, hm, interesting point about lack of detail towards udd stuf
<vila> fullermd: I'd rather invest in cloning  than mucking with time travel *again*
<fullermd> vila: The beauty is, if you do either one, you have spare time to do the other too   :p
<vila> :)
<spiv> poolie: glad you think so!
<spiv> poolie: I'm not sure it's a simple spectrum, but it feels a bit like we haven't found the happy medium between "spec it to death so we know exactly what we plan to do to get there" and "just do it without wasting time writing specs doomed to be stale in a month's time"
<poolie> right
<poolie> feel free to say that outside of reviews
<poolie> at the moment, i think improving the udd importer and dealing with our shortlisted bugs is a good path towards i
<poolie> *it
<poolie> but perhaps i should communicate that more
<bradm> poolie: I'm off for the day, let me know what you want to do with the chroot :)
<poolie> i think it's good; have a good night
<poolie> i'll send a mail about it
<bradm> poolie: righto, if you're happy I'll fix up the names tomorrow, we can go with the one you suggested if you want
<poolie> great
<poolie> then i guess there's no rush to delete the old one
<poolie> yes, i still think that name would be good
<bradm> nope, not overly, I'd just like to make sure we don't stay using pqm-amd64-new :)
<bradm> but I'd like to also not keep the old one around forever if we don't need it, just more stuff filling up the disk once we're happy we don't need it
<poolie> right
<poolie> i think we should be able to rm it by the end of the week
<bradm> excellent, works for me
<poolie> even that is being pretty cautious; there really should be no reason to roll back
<poolie> thanks mate
<bradm> no worries, seeya tomorrow
<vila> poolie: so pqm runs python 2.5 now ?
<lifeless> 2.6
<vila> hmpf, way to go ;)
<lifeless> erm, maybe 2.5
<lifeless> lucid default
<spiv> Ok, baby meltdown.  I think that's my cue to finish my work dayâ¦ see you folks tomorrow.
<vila> I've lost track of where all is documented :-/ I know some wiki pages were explaining everything at some point...
<vila> spiv: ouch, meltdown ? I hope I missed the joke here...
<vila> spiv: is it a way to say he has high fever or something ?
<fullermd> Either that, or leaking radiation (or other noxious substances)   :p
<poolie> vila, do we have babune builds on 2.4?
<vila> no
<poolie> i looked at babune today but i couldn't work out which ones were expected to be failing and which are expected to work :{
<vila> all builds use the defaults provided by the distribution
<vila> poolie: you came at a really bad time
<vila> there are a lot a spurious failures these days
<vila> a total mess
<fullermd> You could build a 2.4 BSD vm pretty easily.  May need a slightly older ports tree; not sure just how decommissioned 2.4 is now.
<fullermd> But since everything just builds against what you've got installed...
<vila> right, I can do that on the existing hardy, jaunty or karmic slaves, but
<vila> many failures seem to derive from using the karmic slave (don't ask me for why running a karmic slave can leak to a lucid one)
<vila> so I'd probably use hardy for that, jaunty has been disabled for quite some time since it's EOL
<vila> even karmic was disabled at some point and got re-enabled... by some jenkins upgrade apparently (I didn't check carefully)
<poolie> vila, so the thing is, it's not very actionable
<vila> but the thing is, many failures have re-appeared since karmic is enabled again (it may just be a red herring...)
<vila> what ?
<poolie> (i realize you already probably know this, and i understanding it may be a bad day)
<poolie> well
<jam> fullermd: http://xkcd.com/320/
<poolie> if i lookd at them, i don't know if i should do anything about it
<poolie> hi jam
<jam> but that is only 28 hour days
<jam> hi poolie
<vila> ha, babune, yeah, total crap these days, it's a shame
<vila> the problem is that it's kind of out of control, the bugs seem to be coming from jenkins and/or vbox with no trail to follow :-(
<poolie> seriously
<poolie> can't we run eg hardy in a chroot?
<jam> vila: yeah, I've been following the failures, but haven't ever found a true positive recently. I guess there was one a month-or-so back
<vila> they have been there for quite some time but triggering only rarely whereas they start triggering daily lately
<vila> jam: yup, the main result is still that we don't regress, but it's becoming harder to verify
<vila> since it's still < 15 minutes a day, I still wait for a new vbox release
<poolie> why do we have to use vbox?
<vila> poolie: switching to chroots is an option for Ubuntu only
<poolie> how about running ubuntu from chroots
<poolie> and, i guess, windows and mac os are the hard parts
<vila> I didn't so far because it's less effort to use vms and I still haven't setup a single chroot
<vila> well, I use real hardware for osx
<poolie> really less effort?
<poolie> do you know debootstrap?
<vila> no, less effort because unknwon >> known
<vila> err, that 'no' was for 'do you know debootstrap'
<poolie> ah, ok
<poolie> anyhow, so if it seems to be a source of noise, and it does, maybe we should reconsider that
<poolie> for windows and mac os i don't know what to do
 * maxb has been quite impressed with the ease of use of kvm for linux stuff - not sure for other OSes
<poolie> that would be high on my list
<vila> right, kvm is still on my radar too, the main problem being that I can't test it on a host where vbox is installed :-/
<maxb> Especially, kvm + approx + preseeded d-i install == awesomeness for Debian install testing :-)
<maxb> s/installed/running/
<poolie> anyhow
<poolie> i would kind of rather shunt aside all the builders or jobs that have intermittent failures and just
<poolie> have one screen that really is expected to be blue all the time and build from theer
<vila> strictly speaking, that would be empty :-(
<vila> even FreeBSD suffers from spurious failures (while it hasn't for months)
<vila> the problem is that *some* spurious failures have been good hints about real problems in the past
<poolie> well
<vila> test isolations/ lazy import order, are just a few exmaples
<poolie> to be more precise, i mean getting a set where a failure is highly likely to be something that we should look into as an actual upstream bug
<poolie> sure
<vila> yeah
<poolie> for instance if 90% or even 80% of failures were "real" failures, it would be worth investigating them
<vila> one way to address it would be automatically retry failures
<vila> yeah
<poolie> my impression is that it is not so high at teh moment
<vila> last time I activated the option it half worked
<poolie> ok, so that is one option
<poolie> another option is to trim back to a core set plus some non-core builders
<poolie> i guess another is to use chroots rather than vbox for some of them, or different virtualization software, if we think that's a cause of many failures
<poolie> i guess using chroots would have the benefit of confirming whether vbox is the problem or not
<vila> well, I witnessed some cases where *all* running vms were shut down at once while a single one were asked to
<vila> so I *know* there is a bug in vbox (leading to corrupted ext4 fses, leading to spurious failures)
<vila> there is just no way I know of to 1) reproduce, 2) point a finger to a more precise part of vbox
<vila> and still
<vila> this either happen once a week or twice a day...
<jam> vila: what about trying to run the VMs more sequentially, rather than all at the same time?
<jam> (can't shut down a VM that isn't running)
<poolie> well
<poolie> given all this, i don't see why we should still use it
<vila> jam: they are limited to 2 indeed, I did limit to 1 in the past
<poolie> when you get back maybe we can pair to set up some chroot builders
<poolie> then see if they are stable
<vila> sure
<vila> I was using a *single* solution to lower maintenance costs, if the cost of the noise if the results become unbearable, that sould be re-considered
<vila> anyway, except for lucid, they are all back in blue as of *now*
<jam> vila: sure, but I follow babune via the rss feed, and when I'm at the point that I expect "failure" to be bogus, that means it isn't providing benefit
<jam> (for me)
<vila> jam: what do you propose ?
<poolie> yeah, same here
<jam> vila: that stability of babune (just like our test suite) is the primary importance. Better to do less testing but to trust the results.
<jam> I don't know exactly how to get there.
<jam> having a False Positive rate higher than True Positive rate means it won't be trusted.
<jam> If we actually had more accidental bugs in bzr
<jam> then we could accept a higher false positive right :)
<jam> rate
<fullermd> I can submit some broken code if that'll help...
<jam> fullermd: thanks. It has to pass on PQM, but then fail on babune, so anything you can do to help
<jam> vila: we've certainly caught some windows bugs
<jam> but for the 2 bugs we caught, we've had like 10+ accidental failures. and I really don't (personally) know how to make the system more reliable.
<jam> vila: IF starting/stopping the VMs is a problem, could we have fewer and just leave them running?
<poolie> i was actually just reading something like this
<poolie> http://horicky.blogspot.com/2011/03/compare-machine-learning-models-with.html
<poolie> fullermd, breaking bsd would be an easy way to do that :)
<vila> ok, so the lucid failure was again a fallout from a crash
<poolie> anyhow
<vila> so, actually the only way to get a good picture of babune's result, is not from the rss feed (which is noisy), but to wait for me to cleanup the noise
<poolie> vila, you're away from tonight?
<vila> no, tomorrow afternoon
<poolie> ok
<jam> poolie: ROC curve is very popular in medical fields. Lots of chances for changing the threshold to get better/worse FPR, etc.
<poolie> i look at the web page not the RSS
<poolie> in a nutshell my position is: avoid false negatives is more important at this point than coverage
<jam> vila: sure, but then it is synchronous polling, vs async updates
<vila> jam: yeah, I'm just confirming the actual state, which is of course not ideal
<poolie> anyhow, i am repeating myself
<poolie> and i should stop
<poolie> work
<jam> poolie: have a good night
<poolie> thanks, you too
<fullermd> Could do something like "bzr selftest ; echo whee" and watch for the echo to catch VM crash interruptions, presumably.
<fullermd> Though I have no idea how easy that would be to hook.
<vila> fullermd: that's kind of the problem, jenkins sometimes lose the connection with vms that are still running, so you can't filter between crashes and connection lsot
<vila> lots
<vila> lost !
<fullermd> Maybe it just needs the config checked by someone who can tpye  ;)
<vila> fullermd: that would help, bu only a bit, everything is version controlled to catch the tyops ;)
<vila> but
<vila> jam: but back to the number of concurrent slaves running, the bug is still there in vbox when *I* run a vm outside of babune regular scheduling, so I've seen cases where running a single vm in babune killed *my* unrelated vm :-/
<vila> hehe, retweet: Kanter's Law: Everything can look like a failure in the middle - http://j.mp/gadlnP
<jelmer> are PQM submissions failing for anybody else?
<jelmer> ERROR: bzrlib.tests.test_crash.TestApportReporting.test_apport_report fails for me
<jelmer> jam, vila: ^
<vila> jelmer: I fired one this morning let me check
<vila> shudder, no email feedback
<jelmer> I did see your MP (2.3 -> bzr merge) fail with a single error
<jelmer> not sure what though
<vila> where did you see that ?
<jelmer> http://pqm.bazaar-vcs.org/
<vila> note that it all the commit did was really merging a news entry...
<jelmer> hmm, seems likely it's the same issue then
<vila> yup, that's why I mention it
<vila> jelmer: pqm wsa upgraded to lucid this morning, you know that ?
<jelmer> vila: yeah, that's why I'm asking. I think it's related.
<vila> ok, just checking we were all the same page
<vila> jelmer: did *you* get emails for the failures /
<vila> ?
<jelmer> yep
<jelmer> I guess I'd better have a look at what's causing the error then
<jelmer> vila: thanks
<vila> jelmer: was just looking briefly, this test requires a feature already, so... weird setup on pqm will be my first guess
<vila> jelmer: may be you have a traceback to refine the diagnosis though
<jelmer> vila: http://pastebin.ubuntu.com/592599/
<vila> ha, right in the probe :-(
<jelmer> vila: do you know if PQM has its own private copy of apport?
<vila> no idea
<jelmer> I'll talk to a losa
<vila> well, no idea in general that is, looking at the path, I have some doubts though
<vila> this reminds me that __import__ is... trickier than it looks and sometimes returns a different module than the one you're asking him to import (a parent one though, but still I remember at least one case where it picked up the wrong one in pyutils but that's probably unrelated)
<lamont> OS locks are exclusive for different processes (Bug #174055)
<ubot5> Launchpad bug 174055 in Bazaar "can't run bzr info while dirstate is locked (dup-of: 98836)" [Low,In progress] https://launchpad.net/bugs/174055
<ubot5> Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836
<lamont> is there a 2.3.1 version of bzr backported to hardy, I wonder?
<vila> lamont: yes, https://launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
<lamont> yay
<cheater> hi
<cheater> i have a problem, my diff's and commits are taking way too long
<cheater> like half a minute to a minute, that's not so nice :(
<cheater> how can i make this faster?
<vanguard> Are there any plans to i18n bazaar?
<jelmer> vanguard: vague plans at this point, it's something we want to do in the future but nobody's actively working on it
<vila> cheater: is your tre bond to a remote branch ?
<vila> tree
<vanguard> jelmer: A first step would be to wrap everything in _(), right? I mean that is something I could do â¦
<cheater> vila: not sure. i am using the "centralized" workflow
<vila> cheater: 'bzr info' should tell you
<jelmer> vanguard: it's not as simple as that, it needs some thought to make sure we only call gettext on things that actually get displayed
<cheater> vila: so i have created a repository on a server and have done bzr checkout sftp:// blah blah
<cheater> vila: ok, as soon as it's done checking in those several files -_-
<vanguard> jelmer: true, translating internal messages might break the program.
<jelmer> vanguard: that won't really be an issue, it's more about the performance
<vila> cheater: if the server is slow, so are the operations involving it,
<vanguard> âWeâ already lost the performance battle to git, so why bother? ;-)
<cheater> vila: it's a dedicated server
<cheater> vila: i don't think it's slow, it's a nice ubuntu server from slicehost with nothing else on it..
<vila> cheater: slow includes network latency
<cheater> how can i make this faster?
<jelmer> vanguard: bzr's performance has improved significantly; it's not as quick as git but we have other features and we don't want to go back to being slow.
<cheater> it would be best if my commits were like instant
<jelmer> vanguard: it should be possible to do i18n without noticably impacting performance, so let's do it that way
<vanguard> jelmer: Personally, even on my 10k Line Project, I do not find bzr to be really slow. But git sometimes amazes me on how fast it is.
<vanguard> jelmer: where could I pour in my motivation to get i18n started?
<vila> cheater: if you work in a centralized workflow, you're *asking* that your commits happen on the server, using a decentralized workflow allows you to commit locally and *then* merge your result on the server at a different times
<vila> cheater: well, there are various intermediates, but roughly that's the main difference
<jelmer> vanguard: I'd recommend bringing it up on the mailing list; we might also want to invite dpm to join in the discussion
<cheater> vila: how do i do this so that i merge stuff manually?
<cheater> vila: i am guessing i could just have like a daemon merging stuff every 15 minutes or so
<vila> cheater: merging can crate conflicts, conflict resolution can't be automated
<vanguard> jelmer: I should be just able to branch lp:bzr and play around with i18n to get to know the material, right?
<cheater> vila: i'm the only one using bzr right now, so it's fine for me
<cheater> vila: i am currently using bzr as a better rsync.
<vila> ha, then just use a branch locally and push only when you're happy
<cheater> well i don't want to bother wondering if i pushed everything so that i can continue working at home
<vila> cheater: i.e. 'bzr branch <remote server url>' instead of 'bzr co <remote url>'
<cheater> so i think i'll set up a job to push all the time
<vila> and then 'bzr push <url>' when you want to... push your changes to the server
<jelmer> vanguard: yep
<vanguard> cheater: if you are the only one with the master copy you could even to `bzr push --overwrite`
<cheater> vila: that's a great idea thanks
<cheater> vanguard: aha
<vanguard> jelmer: let's see how long it takes to branch it with my internet connection
<vanguard> cheater: then there are no merge conflicts, since nothing will be merged
<cheater> vanguard: aha
<cheater> great help, thanks guys
<cheater> also i have a separate question
<cheater> how can i set up bzr well for big files?
<vanguard> cheater: how big is big?
<cheater> well it's big enough that i don't want to have it in the same repository
<cheater> they're just big photos, say 20-50 mb at a time
<cheater> but lots of em
<vanguard> cheater: I guess you just have to create multiple branches/repos
<cheater> yeah
<cheater> but is it better to have the centralized thing, or to branch out?
<vanguard> cheater: but I do not really see the point in using version controll on binary files
<cheater> well i can track renames, overwrites, etc
<cheater> those files get remade sometimes
<vanguard> cheater: okay, makes sense. And you get a backup in case you save the original and so on.
<cheater> say we send something off to get photos of it, the photos come back bad, we need to get new ones, and then we overwrite them
<cheater> yeah
<vanguard> jelmer: the mailing list is this one? https://lists.ubuntu.com/mailman/listinfo/bazaar
<jelmer> vanguard: yes
<vanguard> jelmer: I guess I will set up a new email address for this, I guess there are more than a few messages a day on it.
<vanguard> jelmer: where are all the strings I usually see? I found nothing really in bzrlib/status.py for example :-/
<vila> vanguard: bzrlib/delta.py ?
<jelmer> vanguard: e.g. bzrlib/errors.py, a lot is in bzrlib/builtins.py
<vanguard> jelmer: okay, there are a lot of string literals in delta.py, but which of these can be i18n'ed â¦ I guess I grasp how difficult that will get â¦
<vila> vanguard: on the positive side, 'status' may not be the easiest to start with either
<jelmer> vanguard: I think simply translating all the strings in the codebase is the wrong way to go about this
<vanguard> what would you suggest?
<jelmer> vanguard: A lot of these strings will never be shown to the user, so translating them has an unnecessary performance impact
<jelmer> vanguard: we need to discuss where the translation calls are going to happen first
<vanguard> jelmer: planning is never a bad idea :)
<jelmer> vanguard: I think you're right to investigate to see what the situation is, just mentioning it to prevent patches that would be rejected and waste your time.
<vanguard> jelmer: sure, I consider what I do right now just to check whether I am not thinking of a way too huge task. I do not think I will submit anything before a discussion week or so
<vanguard> yeah, I crashed it -> I found the right spot :D
<vanguard> jelmer: I hacked something together that works basically (result: http://pastebin.com/MSxrdcVy). But to implement it in a nice way is the challence I guess
<vila> jelmer: any news about pqm ?
<jelmer> vila: talking to Michael
<jelmer> I've tried to reproduce the issue locally, but it works fine here
<vila> ha, right, sorry
<jelmer> vila: I can't reproduce the actual error but it seems that the problem is that a ImportWarning is being raised rather than an ImportError
<vila> and pqm turns warnings into errors
<jelmer> vila: how does it do that?
<vila> hmm, nothing changed there... or is it a python thing (we switch from 2.4 to 2.? 5 or 6 ? couldn't get confirmation this morning)
<vila> hmm -Werror ?
<jelmer> vila: Ah, yep
<jelmer> vila: any chance of a review of https://code.launchpad.net/~jelmer/bzr/importwarning/+merge/57184 ?
<vila> jelmer: I'm not sure this is correct, but 1) I can't put the finger of why I have this feeling, 2) pqm needs to be unblocked
<vila> jelmer: approved
<jelmer> vila: thanks
<vila> jelmer: we probably want to investigate *why* this happened on pqm and fix the config there anyway
<vila> jelmer: but blocking pqm is *never* a good idea, so thanks
<jelmer> vila: the apport/ directory in bzr.dev doesn't have a __init__.py and -Werror triggers this problem
<vila> jelmer: but pqm didn
<vila> t try to import from there (or did it ? I couldn't parse the path properly)
<jelmer> vila: ImportWarning was introduced in python 2.5
<jelmer> I suspect prior to that you would just get a ImportError in all cases.
<vila> aaah
<vila> ooooh
<vila> the sooner we stop supporting 2.4...
<vila> ... which we plan to do starting with 2.4 IIRC, just to confuse everybody ;)
<cheater> what is the difference between cloning and branching?
<Tak> bzr doesn't do cloning?
<cheater> ok
<cheater> thanks :)
<Tak> it can be really difficult to apply concepts across VCSs, because they all have different models and different terminology
<cheater> hmm yeah
<poolie> hi all
<poolie> those were nice numbers, john
<bradm> morning.
<bradm> poolie: so, hi :)  how's the new chroot looking?
<poolie> some things seem to have landed overnight
<poolie> i didn't see anyone complain
 * poolie checks
<poolie> nup, no replies complaining
<bradm> awesome.
<poolie> thanks for your help
<bradm> no worries, I'll flip the chroot name now and then we're all good
<bradm> pqm-bzr-amd64-lucid, right?
<poolie> yep; unless there's any precedent for putting those in any other order?
<bradm> well, the current precedent on balleny is chroot-amd64, so I think we can ignore it :)
<bradm> I'm not aware of anywhere else we do anything like that, so its good for me
<bradm> I'll move the old one to pqm-bzr-amd64-hardy too
<bradm> actually, chroot-pqm-bzr-amd64-lucid, although thats getting a bit long
<bradm> thats what I'll call the directory
<bradm> dchroot is pqm-bzr-amd64-lucid, filepath is chroot-pqm-bzr-amd64-lucid
#bzr 2011-04-12
<poolie> that makes sense to me
<poolie> under /srv or something?
<bradm> yeah, /srv/pqm.ubuntu.com/chroot-pqm-bzr-amd64-lucid
<bradm> poolie: okey, all changed.
<poolie> thanks, we can call that ticket done then if you like
<poolie> i don't know if it's easy for you to then do 42500(?) about the dchroot warnings, or if that's with someone else
<bradm> poolie: did you want to leave the old chroot hanging around until the end of the week?
<poolie> if that's not too much trouble
<bradm> nope, thats fine, I'll just reply to the ticket saying its all done bar the shouting^Wremoval, and close it off after I get rid of it on Friday after checking with you
<poolie> you could even lodge an at job now
<poolie> though i would find an at job doing 'rm -rf' a little scary to set up myself :)
<poolie> ah, and of course it will need care if anything is bind mounted
<bradm> poolie: yeah.
<poolie> brb, rebooting natty
<vila> poolie: passing around, but there was a problem with pqm, see https://code.launchpad.net/~jelmer/bzr/importwarning/+merge/57184
<poolie> oh hi vila
<poolie> thanks for pointing that out
<poolie> vila, i had inferred that this was just a change due to moving from 2.4 to 2.6
<poolie> that it now raises a warning rather than an error
<poolie> does the patch fix it?
<vila> yes, at least it landed, I'm surprised we never encounter it though, so I wonder if there isn't something weird in the pqm setup
<poolie> vila, it may be that pqm runs selftest with -Werror and we normally don't?
<poolie> or i normally don't
<poolie> or actually does selftest turn that on itself?
<vila> IIRC all branches are configured independently and each one specify PYTHON=python2.4, so I don't know if only trunk were updated for that or all other branches too (well at least the ones we still need: 2.3, 2.2, 2.1 may be not 2.0)
<vila> ha right, yeah good point
<vila> tsk, I even mentioned to jelmer that -Werror may be involved...
<poolie> bradm, ^^ can you just check we don't have any more PYTHON= things hanging around?
<vila> I don't think selftest turns it on, it's make check I think
<poolie> that was what i thought, but i'm not sure without checking
 * jelmer waves
<jelmer> vila: you're up late :)
<bradm> poolie: looking..
<vila> jelmer: yeah, can't sleep :-/
<bradm> poolie: nope, definately no PYTHON= in the bzr-pqm.conf
<poolie> excited about your trip?
<poolie> thanks
<poolie> or, trying to fix everything in bzr before you go? :)
<vila> poolie: hehe, probably hafl excited and half worried about my daughters and half trying to finish fixing the remaining bugs ;)
<poolie> are they going to be looking after themselves while you're away?
<vila> yup for roughly a week, after that they'll be with family
<vila> first time I managed to convince Val, so now *I'm* worried ;)
<spiv> Good morning.
 * spiv reboots into natty, hopefully
<inductiveload> hello! how do i create a patch containing binary files?
<inductiveload> i just added some icons to a project, and i'd like to send the changes as a patch, but all it says in the diff is "Binary files ....... and .......... differ"
<inductiveload> and when i try to do --format=svn (it's an SVN repo i want to contribute a patch to), it complains about it being a binary file
<spiv> inductiveload: the patch format doesn't support binary files.
<spiv> inductiveload: bzr's native merge directives support them
<spiv> inductiveload: but I don't know that SVN has a builtin tool to consume patches to binary files.
<inductiveload> ok
<spiv> (If it does, then it'd probably be a bug in the bzr-svn plugin if --format=svn doesn't emit that)
<inductiveload> then what would be the "right" way for me to hack on an SVN project and submit a patch (or patch-like sometihng) that can be used to apply my changes?
<inductiveload> i've only ever submitted normal diffs to things before, and never a binary file
<idnar> favourite command-line of the day: bzr missing --mine-only --include-merges :parent
<mDuff> inductiveload, ...well, there's xdelta, but the real issue is that there _isn't_ any format which will show the differences between two binary files in a human-readable and mergable way, and at that point you might as well just submit the whole new file unless it's a size/bandwidth constraint.
<mDuff> (err, maybe it's xxdelta)
<inductiveload> right, so i just have to send an archive with the image folder saying "paste this into the root directory"?
<inductiveload> there's no size or bandwidth problem, it's just that I thought there'd be a way to pass over a single file holding all the changes i'd made
<idnar> for binary files, svn diff just says "Cannot display: file marked as a binary type."
<idnar> and I don't think svn has a command for *applying* patches at all?
<inductiveload> i have no clue, i've never used svn, that's why i'm using bzr
<inductiveload> but the sourceforge repo is SVN, so how do i get my change across, short of tarring the whole damn thing, and letting them make a diff?
<spiv> inductiveload: ask the developers how they'd like to receive changes
<inductiveload> ok, i tohught there would be an "easy" way to do it ;-)
<spiv> inductiveload: or e.g. send them the xxdelta, but also explicitly say "if you'd prefer this in another format, just let me know"
<spiv> Not that I know of, unfortunately.  But talking to people is usually not *too* hard ;)
<inductiveload> :-p ack....interaction....
<poolie> hi there spiv
<poolie> spiv i'm going screen and un-hide the ubuntu bzr bugs
<inductiveload> spiv and co, thank you for you help
<spiv> poolie: sounds good.
<spiv> inductiveload: you're welcome.
<inductiveload> and thanks for making bzr - it's great!
<spiv> poolie: I've been spending the morning mainly getting used to natty & unity, and about to dive back into that pack retry bug
<spiv> (I'm going to have to retrain my fingers a bit; I used to use Super-<num> to switch workspacesâ¦)
<poolie> ok
<poolie> how's hamster?
<vila> poolie: almost there ;) For hamster on natty, Alberto Milone started a project to put hamster into the indicator area: http://albertomilone.com/wordpress/?p=502
<poolie> spiv, well, i hit some more natty bugs including the rather amusing 758335
<poolie> but now, for sure, bug re-publicizing
<poolie> hi vila
<poolie> that sounds good
<vila> poolie: I didn't found the time to test it yet, only looked at the code which seems simple enough
<poolie> i was thinking about puttting it into couch so it would sync across machines
<poolie> there may be easier ways
<vila> poolie: hehe was about to mention my trick
<thomi> hi - I'm wondering if it's a bug that 'bzr qlog' shows revision numbers starting at 1 and 'bzr log --line' shows them starting at 0? It's really confusing when 'bzr revno' doesn't show the same number as 'bzr qlog'.
<thomi> is this worth reporting? It seems like something you probably already know about...?
<vila> poolie: there is a single file you can copy across hosts (~/.local/share/hamster-apple/hamster.db)
<vila> poolie: I have tested that it can be copied while no activity is tracked
<poolie> that's true
<poolie> maybe i should just do that
<poolie> thomi, bzr log --line really shows a revision 0?
<vila> good enough for me, I never track two activities at once
<poolie> please do file if so
<thomi> poolie: pretty sure....I'll double check thanks
<poolie> vila, i was a bit concerned it would touch the file even if nothing's being tracked
<poolie> probably unlikely
<vila> poolie: it seems to update it only when needed
<vila> hehe, probably too vague a description :-)
<spiv> thomi: interesting, is the very first revision a merge perhaps?
<vila> but I did some copys back and forth across several dats
<thomi> spiv: possibly - I just noticed that it doesn't happen to all branches - but I have access to the branch where I noticed the issue
<thomi> err, how would I tell? in qlog it doesn't show as a merge...
<thomi> unfortunately I cannot make the branch public, it's not open source code :(
<spiv> Oh wow, doing a merge in the initial rev gives some screwed up results!
<spiv> revno -174 anyone?
<poolie_> spiv, there might already be a bug for that
<spiv> Yeah, I think so too, this looks familiar
<thomi> oooh - if I do 'bzr log --include-merges' the numbering becomes identical to what qlog reports
<spiv> 'bzr init foo; cd foo; bzr merge $otherbranch; bzr ci' makes a branch with broken revision-info according to 'bzr check'
<thomi> nice...
<spiv> thomi: what does 'bzr check --branch' report for your branch?
<spiv> poolie_, thomi: bug 522740
<ubot5> Launchpad bug 522740 in Bazaar "Merging a branch into empty branch shows negative revision numbers in bzr log" [Low,Confirmed] https://launchpad.net/bugs/522740
<poolie_> yup; probably should bump that up to at least medium
<thomi> found error:Internal check failed: revno does not match len(mainline) 15 != 16
<thomi> so, is there an easy way to "fix" my branch?
<spiv> thomi: bzr reconcile
<thomi> cool - that works a treat, thanks
<vila> hi all ! Last run ;)
<poolie_> so what's up for the last day of school?
<vila> poolie_: addressing some FIXMEs in my config proposals, mostly related to tests
<vila> poolie_: I came across them yesterday trying to implement the current locking scheme, hmm, more like option life cycle scheme instead
<vila> the later should just be to save on every modification, but testing that was... messy, so I stepped back
<vila> the "bug" is that from_string can't be easily re-used for all stores as it requires handling the same parameters as __init__
<vila> that's wrong
<vila> mainly because it makes creating in-memory config objects far too hard
<vila> so I will allow load_from_string instead, targeted at tests only (AFAICS) as it makes no sense for code to inject a bunch of new options without going thru the "regular" API
<poolie_> sorry, i didn't get to read them last ight
<vila> no worries
<vila> you'll have two weeks ;)
<vila> but if I can leave you a cleaner place, you should enjoy playing with it a bit more ;)
<vila> also, loading from a string *is* wrong if the store is already loaded (unless you're testing a particular case and knows what you're doing)
<vila> I'm not quite sure if I should leave such a method in the public API or only hack it from tests (test code in production is bad) but I'll start with the former anyway
<poolie> sorry i didn't look closely enough to say
<poolie> vila bug 712775 may be of interest?
<ubot5> Launchpad bug 712775 in bzr (Ubuntu) "bzr crashed with InvalidEntryName in __init__(): Invalid entry name: bindings/Makefile.in" [Undecided,Confirmed] https://launchpad.net/bugs/712775
<vila> poolie: 85% sure it's a dupe and fixed in later releases
<poolie> :)
<poolie> hooray
<vila> bumping to 95%, the bug was due to my misunderstanding of the tt API, never ever try to use relpaths, always deal with parent_id and basename
<vila> :)
<vila> ghaaaaaaa
<vila> one more VM dying under my crying eyes :(
<fullermd> Don't cry.  It makes VB sad, that's why it's crashing.
 * vila disables karmic again, as silly as it seems, the huge number of spurious failures these last days *always* included it
<vila> on the positive side, upgrading the natty vm *today* allowed unity to start for the second time (since I started tracking it)
<maxb> hmm. natty
<maxb> I wonder when I should dare upgrade my main machine
<vila> maxb: AIUI, one of the main risks is the graphic card (any card less than 5 years should be supported though)
<vila> maxb: I had 3 tests setups: vbox, kvm, an apple laptop, all 3 works today but only the later has been working for a couple of weeks now
<maxb> My laptop's under a year old, so I should be fine
<vila> maxb: there is a live CD that should allow you to test it without installing too
<vila> maxb: another important risk is that the UI is quite different so if you customized your setup you'll probably have to find alternatives
<vila> for values of setup including mainly the desktop/wm that is
<spiv> I just started using natty today.  I haven't found the transition too painful.
<spiv> Despite having some custom key shortcuts I've been used to that unity really wants to use for a completely different purpose :)
<vila> two remaining nits: gnome do incremental matching is better than the dash one, no more hamster in the toplevel bar
<vila> spiv: yup, Unity stealing my Super key from emacs required some xmodmap trickery and muscle memory re-training
<soren> My major gripe is the globalmenu.
<soren> It really doesn't work very well with focus-follows-mouse.
<vila> I love it, one more usable line to display code
<soren> I can appreciate more screen real estate for code.
<vila> soren: hehe, yeah, same here, one trick is to type Alt first to activate the menus
<soren> vila: Oh, that makes them stay?
<vila> soren: yeah, if Alt is still available (which isn't my case ;-})
<soren> Heh :)
<soren> vila: I should try that. I've just disabled the globalmenu proxy thing.
<vila> Alt is Meta here
<vila> soren: the other trick is to use applications where I *use* the menus in full screen mode (where ffm doesn't really make sense anymore ;)
<soren> I have a pretty big monitor. I bought so that I didn't have to make all the windows fullscreen to be usable. :)
 * fullermd would be lost without his ffm...
<fullermd> 'course, I don't have to deal with gnomes or "globalmenu"en, whatever that is.
<spiv> soren: happily I stopped liking focus follows mouse over a decade ago so I don't have that problem :)
<soren> fullermd: It's a plugin that takes the menu from your application and puts it at the top of the screen. Whichever window is active is the one whose menu shows at the top.
<fullermd> How odd.  That would cover up my xbuffys...
<vila> fullermd: the twist compared to other global menus implementations is that most of the time the menu isn't shown
<vila> spiv: well, ffm to me, is a bit like tapping instead of clicking, I just move my mouse where I want the focus, I don't have to clik to confirm
<vila> a bit like: 'Are you sure you want to do that ?' , yes, don't ever ask again
<fullermd> Plus most clicky implementations autoraise the window too.  Blech.
<spiv> vila: you move the mouse to change focus?  How inefficient ;)
<fullermd> (never mind the poor interaction with the icon manager...)
<vila> spiv: hehe, no, I also use other means
<fullermd> Oh, I'm sure he doesn't.  Why bother with the mouse when he can just Ctrl-Meta-Q Hyper-Meta-N Ctrl-Top-Shift-X and *boom*, changed!
 * Tak also <3 FFM
<vila> spiv: but since I share my keyboard and mouse bewteen two hosts, yes, switching from one to the other still requires moving the mouse
<vila> tsk tsk, switching from frame to frame and from buffers inside the frame (emacs window) is bind to...
<vila> M-TAB, what else ?
<vila> eerrrr
<vila> Ctrl-TAB
<fullermd> Six of one, half a dozen of the other.  You just mash your hand down on the left side of the keyboard, it'll hit the right keys at some point.
<mgz> bug 686161 looks like more failing-to-treat-paths-as-unicode fun
<ubot5> Launchpad bug 686161 in bzr (Ubuntu) "bzr crashed with UnicodeEncodeError in run()" [Undecided,New] https://launchpad.net/bugs/686161
<vila> everybody loves shortcuts, but emacs *itself* only uses Ctrl and Meta, the others are free, I regularly check that I'm not overriding the emacs ones but only defines new ones (including using Hyper since Unity insists on using Super ;)
<vila> mgz: grr, str(thing)
<vila> mgz: hello by the way !
<mgz> hi!
<mgz> the Conflict class doesn't even have a __unicode__ method
<vila> mgz: bah, did that even exist in these days ?
<mgz> even though most/all the subclasses need to present paths to the ui
<vila> yeah...
<mgz> wonder if I'll have some time this evening to write up some tests for the whole module.
<soren> Do you guys have any idea how long it takes to branch lp:linux?
<vila> mgz: that would be nice
<vila> soren: that will heavily depends on your bandwidth/latency, but well, don't expect miracles either
<soren> vila: hours? Days?
<soren> I'm 25 minutes in now.
<mgz> right, time to leave
<vila> soren: 'bzr info -v lp:linux' should give you an idea
<vila> mgz: have fun !
<jam> soren: Looking at the repo, it is about 500MB, probably less once it is all tightly packed in your local repository.
<jam> ah, missed one, make that 700MB
<soren> jam: "bzr branch" says it's copied 557803kB so far. "du linux/.bzr" says 252568. Which one of those must reach ~700MB before I'm done? :)
<jam> soren: the first, though it may go up a bit  more that 700
<jam> I wouldn't expect much more, though.
<soren> jam: No problem. I'm just trying to gauge the order of magnitude and whether I want to wait for it.
<soren> "675747kB   868kB/s / Fetching revisions:Inserting stream:Estimate 1879972/2512932"
<poolie> hi jam, soren, mgz
<poolie> maxb: thanks for all the ppa updates
<soren> o/
<poolie> should we update the topic now?
<poolie> i think so
* Topic unset by poolie on #bzr
<poolie> sheesh
<maxb> nice topic
<maxb> :-)
<jam> poolie: hi
* maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.4b1 is officially out (ppa:bzr/beta needs love)
* 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: spiv
<jam> poolie: for bug 758164, if we are printing the filenames, and decoding to unicode, isn't that enough to explain the difference?
<ubot5> Launchpad bug 758164 in Bazaar "first status after add is slow" [High,Confirmed] https://launchpad.net/bugs/758164
<poolie> jam, it could very well be
<maxb> Actually, bzr/beta still needs love
<jam> Your "very different" is 400ms vs 200ms
<jam> which yes, is 2x, but it is also only 200ms
<poolie> indeed
<jam> poolie: I know we took pains to *not* decode utf-8 to Unicode for paths that don't appear modified
<poolie> jam, i was going to profile it and see if anything stuck out
<poolie> we almost need 'status -q' :)
<jam> but if everything is freshly added, we shouldn't be sha1-summing things (that would be more like 30s)
<poolie> right
<poolie> so it may be that formatting the file names is slower than it could be
<poolie> well, almost certainly it could be made faster
<poolie> but i don't know if it sticks out as something especially slow
<jam> poolie: utf-8 => unicode => utf-8
<jam> would be something that sticks in my head
<jam> we like dealing with unicode in memory, but it does have a fair amount of overheda
<jam> overhead
<poolie> heh
<vila> hmm, so I have a registry which return classes, but building objects require different parameters, what could be a tasteful way to design the __init__ methods and how could test provide parameters knowing that they'd like to refer to the test instance itself for that ?
<vila> example: a global config doesn't requires at most a transport object but a branch config requires a branch object
<jam> vila: "doesn't requires at most" ?
<vila> s/doesn't//
<poolie> that's quite a sentence
<vila> hehe
<vila> ok, want me to split it ? (the point being that I can imagine solving both points separately but I'm still searching a combination that works well)
<poolie> i guess generally speaking, provide a method or function that takes only the parameters the callers are likely to care about
<vila> for the __init__ ?
<poolie> perhaps add either an adapter layer, or a separate class method, that will convert to the right constructor call
<soren> jam: Hmmmm... "1091782kB   520kB/s / Fetching revisions:Inserting stream:Estimate 1994478/2512932
<soren> Still ~20% to go.
<jam> soren: and "du linux/.bzr" ?
<soren> 333440	linux/.bzr
<vila> right, but this route leads me to a test that needs to define a method which knows about the specific parameters OR a test method on the config class (bad)
<vila> hmm
<vila> ha, right, one test registry where specific adapters can be added
<poolie> ok, i've disposed of about 70% of the ubuntu/bzr stuck bugs
<poolie> the rest are now non-private
<vila> \o/
<poolie> i had a quick check for anything sensitive
<poolie> https://bugs.launchpad.net/ubuntu/+source/bzr/+bugs?search=Search&field.status=New
<poolie> many are dupes
<poolie> of course
<poolie> so that's most of what i've been doing
<poolie> i wrote a little script to put the traceback attachemnte into the description-
<vila> poolie: and that's because you can now see the private ones right ? (I ~remember looking at the list but it was quite short)
<poolie> that's right
<vila> great
<soren> If I CTRL-C my way out of a "bzr branch"... Can I resume it at a later time?
<poolie> good night all
<jam> soren: unfortunately, no
<jam> if you start from scratch, you can do "bzr branch -r XXX; and then bzr pull -r YYY" etc.
<jam> soren: btw, do you know if you are going via http or bzr+ssh?
<jam> jelmer: question for you
<jam> '92745@138bc75d-0d04-0410-961f-82ee72b054a4:trunk%2Flibstdc%2B%2B-v3%2Ftestsuite%2Ftr1%2F4_metaprogra...'
<jam> is that a revision id from bzr-svn?
<soren> jam: bzr+ssh.
<jam> It is measuring ~ 158 characters
<jam> which is a *lot* longer than the standard 60char bzr revid
<soren> jam: It has transferred 1.6GB now.
<jam> soren, when it finishes, the final transfer amounts should all be in .bzr.log
<jam> you're welcome to submit a bug about this. 1.6 seems significantly excessive
<jam> I have thoughts as to why, but nothing very concrete.
<soren> jam: Will do.
<soren> jam: bug 758620
<ubot5> Launchpad bug 758620 in Bazaar "branching transfers excessive amounts of data" [Undecided,New] https://launchpad.net/bugs/758620
<vila> jam: question for you, I just tried 'bzr branch lp:linux' with bzr.dev and -Dhpss, and after 10 minutes it seems to still be issuing get_parent_map calls *only* alarmingly under-using my bandwidth
<vila> jam: could that be another fallout from querying tags first ?
<jam> soren: if you wait for it to finish, the summary of bytes transferred will be in bzr.log, It would be nice to get that in the bug report as well.
<jam> vila: into an existing repo, or into a new standalone branch?
<vila> jam: new repo
<vila> shared
<vila> but empty
<soren> jam: I'll do that once it finishes. If the average time per revision transferred holds, it'll be another 11 minutes.
<vila> also, the perfmeter shows little peaks every ~30 seconds...
<jam> vila: so into a shared-but-empty means we end up walking the whole history to find that you don't have anything we don't need to transfer.
<vila> jam: as if the smart server was... maybe loading the the ancestry graph to answer each query and being quite slow at that
<vila> >-/
<vila> jam: a standalone branch would be better /
<vila> ?
<jam> vila: we have a special case in place for "target did not exist"
<jam> which is known deficient for "target exists but is empty"
<vila> ok
<jelmer> jam: That's a file id from bzr-svn
<jam> jelmer: k, still really-really big :)
<jam> I was debugging some loggerhead memory consumption
<jam> and 6MB for the intern dict ,+ 20MB of interned strings
<jelmer> jam: It looks like an old style one though, from bzr-svn < 0.6
<jam> jelmer: it is the gcc-linaro repo
<jelmer> jam: bzr-svn parses the file id at the moment so this is tricky to solve easily
<jelmer> from looking at the code, it could indeed also be a new style file id
<jam> jelmer: it isn't critical at this point. but it is something that surprised me.
<soren> Is there a fast way to create a repository out of this mammoth branch (lp:linux)? I could just "bzr init-repo ." in its parent dir and do a "bzr branch linux linux2", but given the size of this, I was hoping there'd be a simpler way.
<soren> Err... Not necessarily simpler, but quicker.
<fullermd> Well, nothing will be really quicker.  You can use 'reconfigure' to turn the existing branch into one using the shared repo.
<fullermd> Not necessarily quicker, but simpler   ;)
<fullermd> ('course, a local 'branch' will be a putz of a lot quicker than going across the network, so it would certainly be 'quicker' in that sense)
<soren> I did it a couple of hours ago with lp:launchpad. It wasn't much faster than the initial bzr branch lp:launchpad, actually.
<soren> fullermd: bzr reconfigure --use-shared ?
<fullermd> Sounds like it, yah.
 * soren awaits
<soren> Oh, lunch!
<jam> soren: touch .bzr/repository/shared-storage
<jam> it is now a shared repository
<soren> jam:  So to make other branches share its data, I have to... what?
<jam> soren: create them underneath that dir
<soren> Oh.
<soren> What about its existing working dir?
<jam> soren: if you really want to relocate stuff, I would say:
<jam> bzr init-repo ../
<jam> rm -rf ../.bzr/repository
<jam> mv .bzr/repository ../.bzr
<soren> Wicked.
<soren> Can I safely kill a "bzr reconfigure --use-shared
<soren> "?
<jam> soren: I think so
<jam> I'm pretty sure it just does a fetch
 * soren takes a chance
<soren> Awesomesauce. Looks to have worked.
 * jelmer is off to the dentist, back in ~1.5 hours or so
<soren> bzr actually just committed a changed file faster than git.
<cheater> hey guys
<cheater> if i make a cvs, svn or git checkout inside my bzr checkout - how do i make bzr not treat it with imports and all that stuff, just ignore the metadata?
<LeoNerd> I believe bzr by default will ignore metadata from most other VCSes
<LeoNerd> I've run mixed bzr + svn checkouts before
<cheater> nah i did svn i think and it did that
<cheater> i had to rm -rf all .svn dirs
<LeoNerd> Both bzr and svn have the ability to ignore files based on wildcard matches
<cheater> is that the way to do it then?
<LeoNerd> bzr ignore .svn;  svn setprop svn:ignore .bzr
<cheater> or is it possible to turn off this importing stuff?
<Peng> I don't know if that would prevent bzr-svn from noticing the .svn dirs, though...
<LeoNerd> Ahhh... That's an interesting one. Yes, you would have to disable the bzr-svn plugin
<LeoNerd> (or uninstall it or something)
<cheater> even if the dirs are ignored?
<cheater> ok i am now going to make a git checkout (ok clone) and will need bzr not to get confused by that
<LeoNerd> bzr ignore .git
<LeoNerd> Which I suspect it'll do by default
<cheater> yeah but then i get bzr-git or something like that
<cheater> and it will go crazy, no?
<LeoNerd> Hmm.. I'm not sure
<cheater> same situation as peng mentioned
<vila> hmm hmm, I think foreign plugins detect the dor dirs before even thinking about .bzrignore
<LeoNerd> Without plugins, a mixed bzr+git checkout should be fine
<cheater> what do you think Peng? what will happen?
<LeoNerd> I'm not sure how the bzr-git plugin will react in the presence of both sets of metadata
<cheater> i hadn't installed any extra plugins but i don't know what is installed by default
<cheater> how do you find out what plugins are installed?
<LeoNerd> Ideally, it'd be nice if you could disable plugins on a per-workdir basis
 * Peng shrugs
<Peng> cheater: "bzr plugins"
<LeoNerd> So just configure "Oi; bzr-svn, not now please"
<vila> but the foreign plugins are also intended to allow you to interact with foreign repos, not mix things into your working tree
<cheater> hmm i did "bzr help topics" and "plugins" was not listed as a command
<cheater> oh it's in "bzr help commands"
<LeoNerd> help topics  just lists a few more things you might want to ask for help about;  help commands  lists all the commands
<cheater> thanks
<jam> cheater: I would expect bzr-git to work fine with .git and .bzr in the same dir, because .bzr is probed first
<jam> however
<jam> bzr-svn and bzr-hg both put their probers before bzr
<jam> AIUI
<jam> and with bzr-svn if you were in a subdir, bzr wouldn't see the .bzr in the parent dir before bzr-svn saw .svn in the current dir
<cheater> jam: my problem is that i don't want bzr-git to work at all
<jam> cheater: then why have it installed?
<cheater> jam: i don't want any git integration stuff or anything, i just want it to be normal files to bzr
<cheater> jam: i guess i don't have it installe
<cheater> d
<jam> You can set "BZR_DISABLE_PLUGINS=git" I believe if you ever do have to have it installed but not working.
<cheater> thanks
<LeoNerd> Ahhh cute
<jam> cheater: you can do similar things with bzr-svn, etc "BZR_DISABLE_PLUGINS=git:svn:..."
<cheater> cool :)
<cheater> thank you jam
<vila> aaaargh, noooo not *now*: bzr: ERROR: exceptions.AttributeError: 'LoomMetaTree' object has no attribute 'inventory'
<vila> jelmer: ^ :-/
<vila> pfew, reverting to revno 578-0 indeed worked
<vila> jelmer: I filed bug #758696
<ubot5> Launchpad bug 758696 in Bazaar "bzr.dev revno 5781 or 5782 broke bzr-loom (needs .inventory)" [High,Confirmed] https://launchpad.net/bugs/758696
<jelmer> re
<jelmer> vila: thanks, I'll have a stab at that bug
<jelmer> jam: bzr-git, bzr-svn and bzr-hg all insert themselves before the bzr prober for server side things
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr-loom/inventorytree/+merge/57311
<vila> jelmer: and compatible, rock&roll ! Well done
 * vila hot bugs are always easier to fix...
<vila> jelmer: approved
<jelmer> vila: Thanks :)
<mok0> When I am done with a branch in a shared repo, I usually just rm -r the directory. Is there any other way to do it? I am concerned that the data in the shared repo just accumulates this way
<beuno> mok0, not really, those revisions do stay around
<mok0> beuno: and there's no way to clear it out?
<beuno> not sure if there's a plugin that will clean out un-referenced revisions
<mok0> Hm, this source tree is around 75 Mb
<mok0> So if I get 75Mb of orphaned revisions every time I make a junk branch...
<mok0> Need I say more? :-)
<beuno> right, although if it shares any revisions with other branches, it re-uses them, obviously
<mok0> beuno: ok, so it's not quite as bad... but still, a whole bunch of bookkeeping files I imagine
<vila> mok0: a single revision use only a fraction of the tree size, so what accumulates is only the set of revisions that are not merged in any other branch
<mok0> vila: I see, thanks
<vila> mok0: not a single one, if you rm the branch, the .bzr/branch (which contains the files related to the branch itself) are deleted
<vila> mok0: only the shared repo is preserved since it's in a parent directory
<mok0> vila: is that "bzr rm branch" ?
<vila> hmm, no a regular 'rm -fr', 'bzr rm' is for versioned files
<vila> versioned files *inside* a versioned tree that is
<mok0> vila: ah so it's what I've been doing
<vila> mok0: yes
<mok0> vila: yeah bzr rm ... I use that frequently
<vila> ok, I'm off, time to pack (a bit more than one hour before leaving for... see, sun and fun :)
<vila> have fun all !
<mok0> See you, vila
<TeTeT> hi, just encountered a problem with bzr on Lucid - a fix might be worth an SRU: http://pastebin.ubuntu.com/593214/
<maxb> TeTeT: I believe it's already planned, though the intent is currently to get the in-flight maverick SRU sorted first
<TeTeT> maxb: great, thanks!
<cheater> if i have a bzr checkout, and i do commit --local, what happens?
<jelmer> cheater: the revision only gets committed to your branch, not to the master branch
<jelmer> so they diverge
<cheater> if i later do a successful commit (without --local), will it add all those local commits too?
<LeoNerd> Useful for offline commits, say, on a laptop
<LeoNerd> You won't be able to commit at that point. You'll have to push first.
<LeoNerd> My usual workflow is: on laptop (offline), commit --local. When I get home, push. Or if I have some outstanding changes push --no-strict
<cheater> LeoNerd: but if i just "commit" i don't need to push, right?
<LeoNerd> You won't be able to commit
<LeoNerd> commit on a bound branch without --local will -first- try to check upstream. It will then notice the remote branch is not up to date, and refuse to work
<LeoNerd> To solve that, you have to commit --local (even though you are now online), then push. push will repopulate the remote branch.
<LeoNerd> Alternatively, you can immediately push --no-strict, to push the outstanding revisions, ignoring the fact you have local uncommitted changes
<Jordan_U> I'm looking for a good introduction to bzr aimed at a new user, on Windows, that has no concept of what a revision control system is at the moment. Preferably GUI.
<jelmer> Jordan_U: have you seen the desktop guide ? http://doc.bazaar.canonical.com/bzr.dev/en/
<Jordan_U> jelmer: I hadn't that looks great (aside from the navigation being a bit non-intuitive).
<Jordan_U> Scratch that last comment about being intuitive, the page hadn't finished loading.
<Jordan_U> jelmer: Thanks :)
<jelmer> np
<groo_> hi/2 all
<groo_> ranch imports?
<groo_> could any kind dev tell me what is the status in supporting git nested trees in branch imports?
#bzr 2011-04-13
<jelmer> groo_: It hasn't changed recently - see the bzr bug report for details: https://bugs.launchpad.net/bzr/+bug/402814
<ubot5> Ubuntu bug 402814 in Launchpad itself "Importing revisions with submodules is not supported" [Wishlist,Triaged]
<poolie> good morning
<groo_> jelmer: tks for info :)
<spiv> Good morning.
<poolie> hi spiv, jelmer
<maxb> hrm
<maxb> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing text keys: [('dulwich/____init____.py', 'git-v1:f60d0a17de087f21708f7f32115b7cc957d51a1a'), ....
<maxb> in our dulwich-daily recipe
 * maxb suspects the damaged divergence of pushed and dpushed dulwich
<TJNII> I've set up bzr as a centralized vcs successfully.  Now I would like to set up a directory that gets updated every time something is committed to the central repo, so that it always the newest and shiniest bits.  This directory will be read only, so merging should not come in to play.  Is a hook script the best way to do this, or can loggerhead do this better?  I'm mainly wondering what documentation to read at this stage.
<spiv> TJNII: loggerhead is a web UI for viewing bzr branches
<spiv> It looks like http://bazaar.launchpad.net/+branch/bzr
<TJNII> Okay, so that's a no, then.
<TJNII> Thanks for the example, though.  I was wondering what it looked like.
<poolie> TJNII: there is a push-and-update plugin that might be what you want
<TJNII> poolie: But that needs to be installed for each client, yes?
<maxb> although, that relies on the person pushing to use it
<maxb> I think a hook would make the most sense here
<poolie> yes
<TJNII> Requiring all users to run it isn't really feasable.... Is there a sound argument against a hook?
<poolie> a server side hook to do this would be good
<TJNII> Okay, that's what I thought.
<poolie> there probably is such a hook
<TJNII> Thanks for the confirmation.
<poolie> post_tip_change
<poolie> but i don't know if there is something that hooks into it that will update the tree
<maxb> although a hook will only fire if the push is over a smart transport
<poolie> if you know python it should not be hard to run
<poolie> there is that too
<poolie> another option is to just set up a cron job to update the working tree
<TJNII> Which transports would not be considered "smart"?
<maxb> Ones which do not rely on there even being a copy of Bazaar installed on the server
<spiv> TJNII: http://doc.bazaar.canonical.com/plugins/en/automirror-plugin.html might be close enough.
<spiv> TJNII: pushing over bzr+ssh is "smart", i.e. runs bzr on the server.  Pushing over sftp isn't.
<maxb> bzr+ssh is smart. http will try to use smart bzr+http if available, otherwise fall back to dumb http. sftp is dumb file operations
<spiv> The automirror plugin is at least an example of using the post_change_branch_tip hook.
<TJNII> maxb: How does that work in a centralized configuration without bzr?  I thought bazaar did not maintain a usable tree that could be accessed directly due to logistical reasons at the core repo?
<TJNII> By "usable" I mean "directly accessable"
<TJNII> My verbage was not to good, there.
<maxb> directly accessible by a human using basic file tools isn't the same as accessible using Bazaar remotely
<TJNII> Oh, so the remote bazaar modifies the .bzr directory?
<spiv> TJNII: is your central repo written to via bzr+ssh?
<TJNII> spiv: Right now, yes.  I think I can maintain that, though I haven't played with the Windows end yet.
<spiv> Ok, that works well then.
<spiv> Because bzr+ssh means bzr is running on the server, and the client is merely asking the server's bzr to make changes rather than writing to .bzr itself.  So you just need to install the hook on the server, and it will be run.
<TJNII> Aah, I understand.
<spiv> I'd try the automirror plugin first, I think it's pretty close to what you want.
<TJNII> Gotcha, thanks.
<poolie> jelmer, are you still here?
<poolie> what do you think of bug 758758 vs bug 681582?
<ubot5> Launchpad bug 758758 in Launchpad itself "bzr out of memory during auto-build (dup-of: 681582)" [Undecided,New] https://launchpad.net/bugs/758758
<ubot5> Launchpad bug 681582 in bzr-builder "fails to build with "bzr: out of memory"" [Medium,Fix committed] https://launchpad.net/bugs/681582
<ubot5> Launchpad bug 681582 in bzr-builder "fails to build with "bzr: out of memory"" [Medium,Fix committed] https://launchpad.net/bugs/681582
<spiv> poolie: do you know anything about âAssertionError: NoWhoami not raisedâ test failures on lp:bzr/2.3?
<poolie> hi spiv
<poolie> there is a bug open for it
<spiv> Hmm, do you have the number handy?  A search didn't find it for me.
<spiv> I'm a bit puzzled about how it passed PQM, perhaps there's a test isolation problem?
<poolie> spiv it is a test isolation thing
<poolie> specifically the heuristic of having /etc/mailname probably works on your laptop but not on pqm
<poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/56503
<poolie> is supposed to have fixed it
<spiv> But isn't merged to 2.3?
<poolie> ah ha
<poolie> was meant to go in to 2.3 but did not
 * spiv wonders where his ssh agent went
 * spiv wonders where the environment variables pointing to the perfectly good ssh agent went
<poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/57436
<poolie> the diff to 2.3 looks reasonable so i'll send it
<spiv> poolie: if it's the same fix already approved & merged for lp:bzr then I approve without even looking at it :)
<spiv> Thanks!
<spiv> For bonus points, do you think gnome-session is a reasonable package to file a bug against if my new terminal instances started by Ctrl-Alt-T (but not Ctrl-Shift-N from an existing terminal!) are lacking environment gnome-sessiony variables?
<poolie> and, ah, https://bugs.launchpad.net/launchpad/+bug/676769
<ubot5> Ubuntu bug 676769 in Launchpad itself "resubmitting a merge proposal should reuse the old commit message" [Low,Triaged]
<poolie> filed by you :)
<poolie> spiv i'd guess that was a gnome-terminal bug
<poolie> that's surprising
 * spiv hmms
<poolie> it seems like it would have to try hard to break it
<spiv> Huh, yes, maybe g-t
<spiv> Using Alt-F2 to run xterm inherits the vars ok
 * spiv wonders what the Ctrl-Alt-T shortcut does exactly.
<spiv> Hmm, part of the âGnome compatibility pluginâ in ccsm
<poolie> wow
<poolie> ok, i sent that to pqm
<poolie> spiv i might go out for a bit, as i have some calls tonight
<poolie> should be back about 5
<spiv> Ok, see you later
<maxb> mm yay it's beta time again, watch the ~bzr/beta ppa become a nightmare of uninstallability
<maxb> jelmer: I want a bzrtools snapshot in ~bzr/beta for installability, are you interested in having it in experimental too (i.e. should I prepare it on the alioth experimental branch?)
<spiv> losa ping: http://pqm.bazaar-vcs.org/ is giving 503 Service Temporarily Unavailable.  Is that a known issue?
<spm> hrm. not by me.
<spm> spiv: iz back; had crashed
<spiv> spm: thanks!
<spiv> And apparently poolie's patch for 2.3 didn't land.  Hmm.
<spm> I call cause and effect. poolie's patch is clearly evil and crashed the pqm ui.
<poolie> maxb: what happens around beta time?
<poolie> bzr betas?
<maxb> the usual api compatibility versioning nonsense mess
<poolie> because of bzr changes?
<poolie> oh, from 2.4b1?
<poolie> :/
<maxb> yes
<maxb> and of course right up there in front in bzrtools
<maxb> I have a lot of disbelieve that bzrtools 2.3.x cannot function reasonably with bzr 2.4
<maxb> *disbelief
<maxb> but it insists on being awkward
<maxb> aaaaanyway. I should probably go to work
<poolie> i agree
<poolie> i mean i share your disbelief
<poolie> i'd like to put up a patch to relax the check
<poolie> either in bzrtools or bzr core
<poolie> hi jam
<jam> maxb: abentley prefers to make sure that at least the test suite passes before he "signs off" on it being compatible
<jam> hi poolie
<poolie> jelmer are you up yet?
<poolie> spiv, spm, i didn't getting a failure message from pqm
<spiv> poolie: hmm!
 * spm hi-fives spiv - troll successful;
<poolie> i'm preitty sure
<spiv> spm: it's cheating if you use your admin powers to crash the system to rig the result ;)
<poolie> canberra must be more boring than i remembered
<spm> poolie: 1, spm 0
<bob2> haha
<poolie> spm, so, seriously, is there any evidence?
<poolie> hi bob2
<bob2> 'evening
<spm> poolie: that your patch crashed it? Idoubt it. the ui is independant of pqm itself. I've not et chased why it crashed.
<spm> poolie: when was your patch sent in? I'm not seeing anything in the log since about 10am our time, and that was something from jam
<poolie> ah, i wonder if it even left my machine
<jam> spm: last patch was about 1am my time I think. Which is, 23:00 UTC?
<spm> jam: dat's der bunny
<poolie> nup, stuck in postfix!
<spm> poolie: that's impressive! that your patch didn't even hit pqm and still managed to crash the ui!!
<spm> spiv: hrm. looks like it may have been down for a while. since ~ 8am on the 11th our time.
<spm> no reason why, just no running, afaict.
<spiv> spm: hmm.  Please arrange the cosmic ray reflectors in the data centre to point at someone else's box, thx.
<poolie> spm, you know bradm did the upgrade to lucid the other day?
<poolie> ok, apparently a change to my internet setup was causing my mail to queue up here
<poolie> it should have left now
<spm> poolie: that was just in the chroots aiui?
<poolie> yes, we copied the chroot, upgraded the new copy, and pointed pqm at that
<poolie> so it should not have caused pqm to stop running
<poolie> unless the config change had a typo or something
<spm> hrm. the timing is sus
<spm> very sus. aligns perfectly. I'd say that was it. something about the chroot upgrade crashed it.
<jelmer> poolie: hi
<spm> hey jelmer
<jelmer> hey Steve
<poolie> spm, but other pqm requests do seem to have got through in the interim
<jelmer> maxb: having bzrtools in experimental seems reasonable
<spm> poolie: for sure. the UI isn't needed to get stuff thru pqm; it's actually a very separate process(?) within the same code.
<jam> poolie: are we doing the standup now?
<maxb> ok, I'll look at that after I've got 2.4b1 done for all series
<poolie> yes, it's time
<jam> poolie: jelmer spiv and I are in mumble
<poolie> hm having some trouble getting in
<jam> poolie: mwa-ha-ha-haaaa!
<jelmer> jam: your laugh is particularly diabolical today ?
<jelmer> poolie: you've muted me, I can't unmute myself as far as I can tell
<poolie> oop
<poolie> why would i do that? :)
<poolie> jam perhaps you should take more inprogress bugs onto your kanban
<poolie> Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
<poolie> jelmer, https://wiki.ubuntu.com/UDS-O#preview
<poolie> spiv, spm, i did get back an apparently real failure
<poolie> i wish our pqm failures were a bit more to-the-point
<poolie> SRU progressed, yay!
<poolie> http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates#preview
<maxb> Yay
<maxb> Give Karmic's impending EOL, any objections to changing "not urgent" to "not going to happen" ?
<jelmer> maxb: I think so
<poolie> +1
<poolie> i would like to get the lucid one out though
<poolie> someone asked about it the other day
<maxb> poolie: Oh, if you really want to test in a ppa, if you define a new dput configuration stanza using incoming = ~%(ppa)s/ubuntu/maverick, the trailing path segment will override the specification in the changelog and changes file
<poolie> perhaps this will get faster
<poolie> maxb maybe you should apply for upload rights too?
<poolie> oh, that's useful
<poolie> could you add that to the page if you're changing it?
<poolie> ok, really offline now
<poolie> have a good night
<poolie> or whatever
<maxb> I'm not sure I recomment it however
<poolie> i think on the whole there are probably enough checkpoints
<maxb> Because it will cause .debs to exist in your ppa which are named and versioned like the primary archive, but are not the same build
<poolie> right
<maxb> yeah, maybe I should apply for PPU - between PPA stuff and Ubuntu process knowledge, I probably qualify
<jml> poolie: your blog is down.
<jml> http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html fails
<poolie> maxb: i would certainly endorse you
<poolie> hi jml
<poolie> i think the machine might be down
<briandealwis> jelmer: thanks for the new bzr-git release.  But 0.6.0 complains that it needs dulwich >= 0.7.1 â which isn't available
<briandealwis> â¦ah, but there is a dulwich-0.7.1.tar.gz available on jelmer's dulwich page, though it's not linked
<jelmer> briandealwis: not linked where?
<briandealwis> http://samba.org/~jelmer/dulwich/
<briandealwis> Ah, it shows 0.7.0 twice
<briandealwis> jelmer: ^
<jelmer> briandealwis: should be fixed now
<briandealwis> coolio, thanks.
<briandealwis> jelmer: in case you want more nits, lp:bzr-git lists 0.5.4 as the latest and lp:dulwich lists 0.7..0 as the latest
<jelmer> briandealwis: you mean the tags?
<briandealwis> jelmer: both the latest file versions, and I guess the tags (they're listed as "milestones" with an open circle vs the closed circles for the other versions)
<jelmer> briandealwis: the milestones aren't related to the tags
<jelmer> briandealwis: the file versions on the site are updated automatically by Launchpad, I guess it hasn't picked them up yet
<sambatyon> hey guys, I need some help. There is some file in the repository, the project file. This project file will be changed in my local branch but I don't want it to be commited, or updated nor pulled nor merged, or anything of the sort, since paths and other stuff are particularly to my environment. However the project needs to be in the main branch so new programmers can customized it. Is there a way to avoid these things to get caught by
<sambatyon> bazaar in merges and things like that?
<maxb> The standard solution is to keep a template file in the branch, and let developers copy it to a new name before making their local modifications
<maxb> e.g. project.conf.template in the branch, people use it to create a project.conf locally
<sambatyon> yes, I would do thatâ¦ unfortunately I am not the admin
<sambatyon> (and now it is too late for that)
<gypsymauro> hi
<gypsymauro> I'm trying to ceckout a working copy with sftp but I get this error: bzr: ERROR: Not a branch: "sftp://root@192.168.64.244/home/bzr
<gypsymauro> any hint?
<maxb> Ok... Is that location actually a branch? Does /home/bzr/.bzr/branch/format exist?
<gypsymauro> yeah Bazaar Branch Format 7 (needs bzr 1.6)
<maxb> OK, please try the command again with the -Derror flag and pastebin the output
<gypsymauro> maxb: http://pastebin.com/WhdUW8A2
<maxb> What version is Bazaar on the client side?
<gypsymauro> the same on the server 2.1.2-1
<gypsymauro> funny is that if I run bzr co on local machine it works
<maxb> Please try running:
<maxb> echo "get /home/bzr/.bzr/branch-format" | sftp root@192.168.64.244
<gypsymauro> File "/home/bazar/.bzr/branch-format" not found.
<gypsymauro> but there is that file
<gypsymauro> doh...
<mgz> spelling?
<gypsymauro> two ssh processes on the same ip...
<gypsymauro> sorry :)
<gypsymauro> I need a cup of coffee..
<mgz> maxb or someone, what's the right way of dealing with all these bzr (ubuntu) bugs poolie opened up?
<mgz> I can mark it confirmed, but should I open it against bzr (upstream) where I have tracker rights?
<jam> mgz: I would use "Also Affects Project"
<jam> and add bzr
<jam> and then we can decide what to do with the upstream portion
<jam> I often close it with a "moving to upstream"
<mgz> thanks jam.
<jam> because we don't usually care about the status in a particular "Ubuntu" package
<jam> It is unfortunate that you can't just say "this is Upstream" directly
<mgz> just posting a commect on your bug 758652 as well.
<ubot5> Launchpad bug 758652 in loggerhead "'leaks' Branch objects" [Medium,Confirmed] https://launchpad.net/bugs/758652
<jam> but I think there is a bug open in LP about it.
<maxb> mgz: what bugs?
<mgz> bug 686735 for eg. which I want to fix today.
<ubot5> Launchpad bug 686735 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError in run_subprocess_command()" [Undecided,New] https://launchpad.net/bugs/686735
<jam> mgz: yeah, it looks like reporting bugs via apport defaults to making them private
<jam> so Martin has to go through them and make sure there isn't anything personal included and manually make them public
<mgz> right.
 * jam doesn't like bottlenecking things through a single person
<gypsymauro> suppose I move a repository from a machine to another , there is a way to udpate a local working copy to point to the new location of the repository?
<jam> gypsymauro: if you are using a lightweight checkout "bzr switch --force"
<jam> (--force if the old repo no longer is available)
<gypsymauro> jam: not lightweight
<jam> gypsymauro: heavy checkout then? 'bzr switch' still works
<jam> if it isn't a checkout, and just a branch, and you want to update the push and pull locations
<jam> use '--remember'
<jam> bzr push --remember new-location
<jam> etc
<gypsymauro> doen with "checkout" is an heavy right?
<vanguard> how much work would it be approx. to do i18n on the bzr cli?
<jam> gypsymauro: yes
<jam> vanguard: There are quite a lot of strings around. I think the biggest hurdle we ran into was that importing gettext is *slow*
<jam> added something like 0.5s to every run
<jam> I don't remember the details anymore, but that was a fair punishment for trying to do it.
<vanguard> jam: so it is basically cancelled?
<jam> vanguard: I don't think anyone has confirmed the results in a while (like a couple of years)
<jam> so it might be wrong
<jam> I know the guis are translated
<vanguard> Explorer and qbzr are, bzr-gtk is not I think
<jam> right
<jam> I know bzr-gtk does import gettext
<jam> it used to break when in a debugger because of gettext evil and the '_' operator
<jam> (gettext would create a builtin '_' operator, but pdb uses '_' as the result-of-last-command variable
<vanguard> maybe it just has no german l10n. What is the gettext evil?
<vanguard> right, I see
<jam> which would then break like mad when bzr-gtk would try to _() a string)
<vanguard> so the _ is not that clever in python I gather
<gypsymauro> there was a new file, I made a ci and it marked aas unknown, now if I do a bzr add it doesn't add it :/ the default is recursively right?
<jam> gypsymauro: what does "bzr status" say?
<jam> add is recursive by default, yes
<jam> The file might be ignored?
<gypsymauro> it says, unkown: pathofthefile
<jam> gypsymauro: if it shows up as unknown, then it should be added by plain 'bzr add'
<jam> Only thing I can think is if you have a secret subtree that is in the way
<gypsymauro> uh
<gypsymauro> no
<gypsymauro> I defenitely need a coffee
<gypsymauro> you can see the status if you are in a different subtree
<gypsymauro> but bzr add doens't works globally
<gypsymauro> u need to be on the root
<gypsymauro> or on the right folder
<jelmer> jam, vanguard: bzr-gtk uses _i18n rather than _()
<jelmer> the gettext import overhead is negligable these days
<jam> jelmer: it does *now* it didn't many moons ago
<jam> AIUI, it does specifically because of that
<jelmer> jam: Yes, exactly
<gypsymauro> can bzr and svn work on the same working copy? :) I mean I've a project that is mantained by a guy that uses svn , but I want to keep the revision on my own too, can they live togheter?
<jam> jelmer: are you including the time to install the specific language, etc for gettext?
<jam> "import gettext" is pretty fast, but ISTR it costing more to actually set up translations, et.c
<jam> gypsymauro: you can, but things get weird if you install bzr-svn and try to share a working tree
<jelmer> jam: I'm not sure about that, this is the overhead on my system (which has LC_ALL=en_IE.UTF-8)
<jam> (bzr-svn lets you checkout from subversion as though it were a bzr branch, etc)
<jam> jelmer: my point is that it isn't just 'import gettext', I don't remember the specific invocation, though.
<jelmer> jam: binding to a specific gettext domain, etc is included (but without any actual translations present)
<gypsymauro> jam: oh no I want just let him to work on his project with svn , but I want to keep track of theproject on my own with bzr
<jelmer> I'm not sure how worried we are about overhead for users without i18n enabled vs the overhead for users who do want i18n
<jam> jelmer: you haven't actually said what the overhead is :)
<jam> gypsymauro: jelmer is the man to talk to. Anyway, I need to go do family time. See you guys later.
<jelmer> jam: have a nice evening :)
<jelmer> jam: I said negligable, which can mean anything.. ;-)
<jelmer> I'll get some more details
<jelmer> gypsymauro: you should be able to just "bzr branch <svn-url>"
<gypsymauro> jam:  tank you :D
<gypsymauro> jelmer: ?
<gypsymauro> I've already a working copy I want to create a new repository from it
<jelmer> gypsymauro: you'd like to create a bzr branch from a svn repository?
<jelmer> sorry, from a svn working copy?
<gypsymauro> I'm not sure what u mean with "branch" , I mean that I want to version a svn working copy with bzr :)
<gypsymauro> something like cvs add
<jelmer> gypsymauro: so you'd just like to version the entire tree, without preserving any of the existing svn history?
<jelmer> gypsymauro: in other words, the fact that it's a svn working copy isn't really relevant?
<gypsymauro> jelmer: exactly
<jelmer> gypsymauro: see the bzr in 5 minutes guide
<jelmer> (http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html)
<jelmer> basically - "bzr init; bzr add ."
<gypsymauro> tank you jelmer
<mgz> vanguard: I'm curious, why do you want to work on making the cli german rather than just qbzr/explorer?
<mgz> most devs I know, even the ones with localised web browsers and so on, don't expect native command line tools.
<mgz> and the gnu stuff pisses the hell out of my by guessing my prefered language incorrectly.
<briandealwis> Does anybody know if I can do a bzr-svn dpush from a loom or a pipeline?  I'm looking to "hide" some (orthogonal) local patches required to get the tree in a running state on my machine.
<jelmer> briandealwis: Somewhat; if you don't dpush the tip of the pipeline then you'll have to rebase the unpushed pipes after dpushing
<briandealwis> Ok, makes sense.  Unfortunately I'm working against an old Subversion installation that won't be upgraded, and I want to avoid polluting with file-properties.
<briandealwis> Thanks Jelmer
<jelmer> does anybody else have trouble accessing e.g. https://code.launchpad.net/~maxb/bzr-builddeb/no-error-unknown-distro/+merge/56998 when logged in?
<maxb> trouble?
<jelmer> I get a 403
<maxb> How odd
<maxb> I can see it fine, anonymous, as ~maxb, and as ~maxb-autobuild
<jelmer> it's fine now if I refresh but I can confirm it from two machines
<jelmer> maxb: what about the MP linked from https://code.launchpad.net/~spiv/bzr-loom/plugin-init ?
<maxb> fine
<maxb> oh, the MP
<maxb> the MP OOPSes
<maxb> Shall we transfer to #launchpad-dev ?
<jelmer> sure
<dpm> hi jelmer, all set for your appdeveloperweek session later on?
<jelmer> dpm: still working on some notes, but ready otherwise
<dpm> jelmer, excellent. Thanks and good luck on the session!
<jelmer> dpm: It's 4 hours from now right?
<dpm> jelmer, yeah, at 23:00 for you, if you're on CEST -> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable
<jelmer> dpm: Thanks
<jelmer> dpm: Just double checking, it wouldn't have been the first time I missed up a tz :)
<jelmer> *messed
<dpm> jelmer, no worries, thank _you_ :)
<Fidelix> Hello. I have some files in an Unix remote server, and I'd like it to be a central place for developers to commit. How can I do that?
<LeoNerd> Most likely just something simple over ssh; either bzr+ssh, or sftp.
<Fidelix> LeoNerd, was that for me?
<LeoNerd> Yes
<Fidelix> LeoNerd, how should I create the repository on the remote server?
<LeoNerd> bzr push sftp://server/path/to/repo
<LeoNerd> will create it if it doesn't exist
<Fidelix> LeoNerd, but the files are on the server.
<LeoNerd> Hmmm?
<Fidelix> The files are already on the server.
<Fidelix> The files are ONLY on the server.
<LeoNerd> Just as bare files, not managed by bzr?
<Fidelix> The project was started there. Using simple FTP.
<Fidelix> LeoNerd, exactly.
<LeoNerd> I see.. Well... bzr init; bzr add them, bzr commit  to create the first revision... now it's a branch.
<LeoNerd> Others can access that branch, check it out, commit to it, etc.. by any of the usual mechanisms
<LeoNerd> Though note that not all transports can update a remote checkout after a push
<Fidelix> LeoNerd, what is a transport? A user?
<Fidelix> *an user?
<LeoNerd> file or sftp or bzr+ssh or whatever...
<LeoNerd> URL schemes
<Fidelix> Oh, ok. Can bzr+ssh do that?
<LeoNerd> Hmm.. pass. Not sure offhand. Try it out.
<LeoNerd> There's a warning message if it doesn't.
<Fidelix> OK. Thanks.
<Fidelix> LeoNerd, what is "Lightweight Checkout" ?
<LeoNerd> A checkout that doesn't haev a branch.
<LeoNerd> Think like CVS checkouts
<Fidelix> Alright. That's what I need. Thank you very much
<Fidelix> Authentication (publickey) successful!
<Fidelix> Secsh channel 1 opened.
<Fidelix> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
<mgz> Fidelix: paste the full traceback somewhere? you possibly have some filenames that are not utf-8, or a misconfigured locale.
<Fidelix> mgz, I closed the window, opened again, and it worked fine.
<Fidelix> I'm using bzr explorer
<mgz> I'm curious about what the actual error was, can you find it in .bzr.log and put it somewhere for me to see?
<Fidelix> I believe it is this bug: https://bugs.launchpad.net/bzr-explorer/+bug/599860
<ubot5> Ubuntu bug 599860 in Bazaar Explorer "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 84: ordinal not in range(128)" [Medium,Confirmed]
<Fidelix> yes, I'll paste.
<Fidelix> mgz, where is bzr.log ?
<mgz> I think explorer will tell you where to find it under 'about'.
<mgz> otherwise run `bzr qversion` from the command line.
<mgz> hm, not in about, can do Bazaar/All Commands... and type 'version' in the 'Command' drop down and hit okay, then scroll the output so you can see where the log file is.
<Fidelix> mgz, I hope you don't mind... I removed some personal data. http://pastebin.com/H8vaabTX
<mgz> that's fine.
<mgz> actually, looks like the bug I am looking into *just this second* which is bug 686735
<ubot5> Launchpad bug 686735 in Bazaar "bzr crashed with UnicodeDecodeError in run_subprocess_command()" [Low,In progress] https://launchpad.net/bugs/686735
<mgz> what's your qbzr version? that's something the explorer 'about' will tell you.
<mgz> finally, in the parts you starred out, were there any non-ascii characters or % encoded URL bits?
<Fidelix> mgz, http://felipefidelix.com/f/System_Information-2011-04-13_14.39.59.png
<Fidelix> Not on the server, but on my computer, maybe... IF # is utf-8, which I don't think it is...
<mgz> sorry, that's the other dialoge box, I wanted the info in Bazaar Explorer's Help/About Bazaar Explorer specifically the line that says for me:
<mgz> QBzr 0.20.0.dev, ....
<Fidelix> http://felipefidelix.com/f/About_Bazaar_Explorer-2011-04-13_14.43.57.png
<mgz> The # should be fine indeed, just needed to check
<mgz> thanks Fidelix.
<Fidelix> No, thank you!
<mgz> feel free to +metoo that bug I linked and I'll mark it confirmed.
<Fidelix> Alright
<mgz> wait, I... edited the wrong bug earlier >_<
<TJNII_work_> I want to set up bzr to run a shell script on post_commit.  I'm looking at the docs, but I don't understand the naming system in .bzr/hooks.  Where should a script like this go?
<TJNII_work_> The hooks page talks about "types": branch and server, but doesn't clearly state what the differences are, and the hooks help uses post_commit whereas the hooks page uses post-commit.
<jelmer> TJNII_work_: the hooks are installed by bzr plugins, they're not shell scripts
<jelmer> where do you see a reference to .bzr/hooks ?
<TJNII_work_> wiki.bazaar.canonical.com/BzrHooks
<TJNII_work_> under "Specify hooks in directories"
<TJNII_work_> So I can't just have bazaar run a shell script on post_commit?  That is no longer supported?
<TJNII_work_> I need soemthing server side.  Requiring all clients to install a plugin is unacceptable.
<TJNII_work_> I was under the impression I could install a hook in the server .bzr direcroty and the "smart" protocols would activate it.
<mDuff> TJNII_work_, I haven't kept up with bzr very closely, but I wasn't aware that server-side hooks were ever supported without a PQM.
<mDuff> TJNII_work_, (...speaking of which, have you *considered* a PQM?)
<mDuff> ...hmm. Actually, looking at that page, it looks like they are. Nifty.
<mDuff> (supported since 1.6, apparently)
<TJNII_work_> What is a PQM?
<mDuff> a patch queue manager, a central daemon which receives and handles please-merge-my-branch requests (typically with configuration to support running unit tests, or voting on whether to accept the patch, or the like first)
<mDuff> btw, http://doc.bazaar.canonical.com/latest/en/user-guide/hooks.html and http://doc.bazaar.canonical.com/latest/en/user-reference/hooks-help.html look relevant (the latter discusses exactly when hooks are run on the server)
<TJNII_work_> I see.
<TJNII_work_> Where is that documented?
<TJNII_work_> Is is not in the users guide
<TJNII_work_> The admin guide has a heading for it, but no content.
<mDuff> https://launchpad.net/pqm is one particular PQM instance
<TJNII_work_> Yea, I'm looking at those pages, but they don't clearly define what pathing bazaar uses
<TJNII_work_> Would it be .bzr/hooks/branch/post_commit?  Or .bzr/hooks/branch/post-commit?  or .bzr/hooks/server/post_commit?  I don't know.
<mDuff> Docs clearly specify "the plugins subdirectory of your configuration directory" should have a Python plugin that installs your hook.
<mDuff> ...so you're writing Python code rather than a shell script (even if it's Python code that starts a shell script)
<mDuff> ...in the initial BzrHooks wiki page you pointed at, support for shell scripts is listed as a "desired improvement", not a feature.
<TJNII_work_> Oh, I see.  So even though the docs clearly say "In addition to plugins installing hooks, users can provide shell scripts to run when hooks are triggered. The scripts to run for hook xxx are specified in the following directories: " it doesn't actually do that.  Which is kinda documented in the "Requested Improvements (Dec 2007)" block.
<mDuff> ...well, you'd want someone who actually knows the code (or is at least willing to grep it) to give a _conclusive_ answer
<mDuff> ...but having a behavior that's documented only in the wiki but not the manual isn't exactly confidence-inspiring.
<mDuff> oh, that's under "ideas"
<mDuff> "Configuration Ideas"
<mDuff> ...so yup, that would clearly look to be brainstorming for future implementation.
<lifeless> TJNII_work_: there is a plugin that will run shell scripts of your choice on actions
<lifeless> TJNII_work_: you can install that server side
<lifeless> TJNII_work_: as long as folk use bzr:// to push it will run.
<lifeless> I don't remember its hane, sorry - but jelmer may.
<TJNII_work_> lifeless: Where?  I'm looking for it and not finding it.  If you know the URL that would help greatly
<TJNII_work_> The plugins page lists shell-hooks, but that's dead
<TJNII_work_> Nothing on the site
<lifeless> thats what I was thinking of I suspect
<TJNII_work_> Yea, there's a trunk directory from 2008 that is empty.  No code.
<TJNII_work_> So, what would the python script / plugin need to be named?  post_commit_hook.py?
<mDuff> TJNII, ...the plugin's name doesn't matter -- it's the contents that do the registrations
<mDuff> TJNII, umm, you say "empty" -- it's a bzr repo
 * TJNII_work_ smacks his forehead
<TJNII_work_> duh.
<maxb> OK, this is not so bad. All plugins in ~bzr/beta install and at least load except bzrtools bzr-pipeline and bzr-svn
<maxb> abentley: What stage in the 2.4 beta process are you likely to release compatible versions of bzrtools and bzr-pipeline?
<abentley> maxb: probably when bzr 2.4.0 goes gold.
<maxb> ah. I should probably think about snapshot .debs then
<abentley> maxb: currently, these are both slow-moving projects whose trunk declares compatibility.
<abentley> maxb: The whole versioning thing is a mess, as we recently discussed on the list.  But I would expect the last release of bzrtools to work with beta versions of bzr.  It doesn't?
<maxb> Oh!
<maxb> It looks like we may have mis-transliterated its internal API versioning into debian package dependencies
<abentley> maxb: Yeah, it wouldn't be compatible with final bzr releases, but it shouldn't complain about betas.
<maxb> Ah....
<maxb> bzrtools special-cases 'dev' but not 'beta'
<maxb> So it will work, but it will warn
<abentley> maxb: Oh.  I was assuming that betas were dev, since they're not releases.
<maxb> They're beta releases :-)
<maxb> Perhaps != 'final' would be best?
<abentley> maxb: perhaps.  API changes can still happen in the betas, right?
<maxb> IIRC we pick a specific beta as the start of API freeze? Usually the last beta?
<maxb> (so, yes)
<abentley> maxb: It doesn't make sense for bzrtools to claim compatibility with 2.4 until it the final bzr 2.4 API is available, so there ought to be a way for bzrtools to work with betas.
<mDuff> -
<maxb> Right - so, treat 'beta' and 'dev' version classes the same
<abentley> maxb: okay, I'll look into revamping the versioning of pipeline and bzrtools so that they work with the subsequent betas.
<maxb> Great!
<maxb> bzrtools works now, except that it claims that bzrtools 2.4 should be available if you run it against a beta release
<abentley> maxb: Yes.  For now, I guess snapshots are the way to go.
<orospakr> Hey, can I delete tags from a repository (not a branch)?
<orospakr> for that matter, how can I get the equivalent of "bzr log" from a repository?
<fullermd> Oh, removing tags from a repository is easy.  You just...  do nothing   :).  Tags are in branches, not repos.
<orospakr> ah, I found another way around my problem. nvm.
#bzr 2011-04-14
<poolie> hi all
<mgz> hey poolie.
<poolie> hi there
<mgz> poolie: what do you want done with the Ubuntu bits of theses new exciting bugs you've made public? jam suggested closing them after opening an upstream task, but I'm not sure I have perms to do that.
<poolie> mgz i don't know
<mgz> ...where 'bits -> 'bug task'
<poolie> hm
 * mgz needs to clearer
<poolie> i guessed
<poolie> in some ways, if they are not going to be *specifically* fixed in upstream
<poolie> they should be 'wontfix'
<poolie> but, that sounds a bit negative to the reporter perhaps
<poolie> you could just make them mirror the upstream tasks?
<maxb> Wouldn't it make sense to leave the Ubuntu tasks open, until we eventually close them via LP: #nnnnn in debian/changelog ?
<poolie> mm that could be good
<poolie> in that case then triaged or confirmed, and matching importance
<mgz> well, that's like the 'fix released' issue poolie posted about the other day.
<mgz> unless there's some automation there already?
<maxb> Well, for Ubuntu package tasks, there's an automated robot which closes bugtasks from debian/changelog uploads
<mgz> how does it get in the changelog though?
<poolie> manually i think
<poolie> well, perhaps for a new major release there could, or perhaps is, a script to gather it?
<dchilton> Hi I just launched a series of lp:whatever updates with bazaar @ a bunch of different machines ... everyone's returning: "ssh: connect to host bazaar.launchpad.net port 22: No route to host".  Is anyone else seeing anything?  Not sure if there's a status page to check ...
<mgz> I got that just now, branched locally instead, launchpad likes midnight updates.
<dchilton> mgz: ah, didn't realize launchpad's in Europe ...
<mgz> http://identi.ca/launchpadstatus/ <- doesn't look planned this time.
<dchilton> mgz: a status page!  evern better, thx!
<dchilton> good excuse to go get a beer early ... thx!
<mgz> and I need to sleep, will have to do mps tomorrow.
<poolie> sleep well
<mgz> ...fell into the just one more bug trap. now I'm really going. :)
<spiv> Good morning.
<poolie> haha
<poolie> hi spiv!
 * spiv blinks
<spiv> mutt crashed.  That's new!
<bob2> heh, it reliably crashes every night for me while doing imap idle
<spiv> I use offlineimap to handle the actual imap
<spiv> I'm not sure I really want to send a 1.7GB apport report though!
<spiv> I'm rather impressed than an 8MB crash file can apparently expand that muchâ¦
<spiv> Ah, no, apport's GUI is just lying to me.
<AfC> jelmer: Doubt you noticed in the avalanche of bugmail, but regarding the problem pulling from GNOME git trying to clone GTK, I discovered
<AfC> jelmer: that you can duplicate with the public (anonymous [sic]) git:// URL as well as the git+ssh:// one. So with any luck you might be able to duplicate the crash I'm experiencing
<AfC> jelmer: [all on the bugs are bad but encountering someone else's reproducible bug might find something deeper that does matter]
<poolie> spiv do you use tribunal or subunit on pqm failures?
<poolie> tribunal seems to not be coping with them recently
<poolie> just started digging into it before lunch
<poolie> nm, stupid bug
<poolie> spiv i'm going to backport the importwarning fix to 2.1, 2.2 and 2.3
<poolie> it seems necessary to land anything on those branches in lucid
<poolie> that code didn't exist in 2.0
<poolie> do you see any risks?
<poolie> sent anyhow
<spiv> poolie: sorry, was out for a bit over lunch.  The importwarning fix seems ok... oh, but is it in 2.4?
<spiv> poolie: Hmm, no, docs say ImportWarning is new in 2.5
<spiv> poolie: I don't use tribunal for that, partly because I happily don't get too many failures back from PQM, and partly because it just doesn't work quite well enough :/
<poolie> :/
<spiv> Subunit streams seem a bit fragile, so it seems like half the time I have to try random filtering options to use them.
<poolie> that is true
<poolie> there was an embarassing total-failure bug in trunk, the presence of which indicates not that many people are using it
<poolie> which is fine
<poolie> anyhow, if you hit stuff that's not stream fragility, let me know
<spiv> But also each time I use tribunal I get itchy to make it better, rather than work on what I was originally doing :)
<spiv> It's been a while since I've tried though
<poolie> yeah
<poolie> that actually puts me off using it :)
<poolie> too many yaks
<poolie> in this case i did though
<poolie> i might fix bug 760387 now though
<ubot5> Launchpad bug 760387 in Bazaar "failures are not easily visible in pqm make check error output" [Medium,Confirmed] https://launchpad.net/bugs/760387
<poolie> how is the pack code?
<spiv> Fairly good.  I've mostly extracted out the state and logic I wanted to extract into its own class, although it's still a bit more bound up with the original class than I'd like
<spiv> I've got some basic tests using that, and I'm about to start writing tests for the edge cases that brought me here in the first place.
<poolie> lifeless: hi, just quickly, can you tell me what if any special expectations pqm has for subunit support?
<poolie> does it look for a selftest.log file?
<lifeless> no, it parses stdout
<poolie> or does it just expect that stdout might be a stream?
<poolie> that's all?
<lifeless> yup thats it
<poolie> do you recall what it is that generates the summary in the pqm rejection mail?
<poolie> well, not a summary, but a list of skipped tests etc
<lifeless> poolie: sorry, I'm looking at this cisco issue
<lifeless> the mail body is generated by pqm using the subunit library
<lifeless> pretty straight forward to change if you want it different
<poolie> np
<poolie> that'd be something to change in pqm's code?
<lifeless> yup
<lifeless> pqm/output.py
<lifeless> client = subunit.test_results.TestResultFilter(client)
<lifeless> constructs the used filter
<lifeless> what do you need changed?
<poolie> i'd like it to just tell me about the tests that actually failed (!)
<poolie> at the moment the output is enormous and mostly irrelevant
<poolie> https://bugs.launchpad.net/bzr/+bug/760387
<ubot5> Ubuntu bug 760387 in Bazaar "failures are not easily visible in pqm make check error output" [High,Confirmed]
<lifeless> I think thats a combination of things; its showing skips which changing the line to include filter_skip=Tre as a parameter will address
<lifeless> and the skips have an attachment which is useful when debugging why something skipped
<lifeless> but not great en masse
<lifeless> spm: ping
<spm> yo
<lifeless> on balleny, in the pqm checkout that pqm runs from
<lifeless> can you change
<lifeless> client = subunit.test_results.TestResultFilter(client)
<lifeless> to
<lifeless> client = subunit.test_results.TestResultFilter(client, filter_skip=True)
<lifeless> in the file
<lifeless> pqm/output.py
<lifeless> if this works and makes poolie happy, I'll commit said change to the public branch
<spm> lifeless: hrm. that'd be a no. I can't get to balleny atm
<lifeless> ah
<lifeless> E-pic routing
<spm> purple routing?
<spm> I lie! I'm in!
<lifeless> you are such a tease
<spm> it was staring at me for ages diong nothing....
<lifeless> sadface
<lifeless>     raise errors.NoWhoami()
<lifeless> bzrlib.errors.NoWhoami: Unable to determine your name.
<poolie> hooray cowboys
<poolie> lifeless: on where?
<lifeless> poolie: pqm test suite
<spm> lifeless: ~ line 97?
<lifeless> spm: zigactly
<spm> lifeless: changed
<lifeless> poolie: toss something broken at it
<poolie> i think it's full at the moment
<poolie> i'm sure i will give it something broken in good time
<poolie> thanks for that
<poolie> re: reliability, the problem may be that other output from bzr or pqm or make sometimes gets into the stream
<poolie> in some ways it is in an unhappy compromise between being strictly defined and requiring a reliable transport, and being fuzzy
<lifeless> poolie: I would like it if you can tell me in the next week whether its better or not
<lifeless> so we don't have an extended cowboy
<lifeless> poolie: pqm keeps stdout and stderr separate; it is still possible to have things messed up of course.
<lifeless> but stderr/stdout interleaving is the most common cause
<poolie> i will tell you
<poolie> there are some things in bzr that leak to stdout
<poolie> also ,tribunal is kind of buggy
<poolie> ok i sent in an intentionally buggy merge
<poolie> it should get to the top of the queue in a couple of hours
<lifeless> cool, thank you
<poolie> lifeless: btw next in the queue is my fix for bug 751824 which might be related to your nowhoami thing
<ubot5> Launchpad bug 751824 in Bazaar "whoami-related test failures with bzr.dev" [High,In progress] https://launchpad.net/bugs/751824
<poolie> well, it's _related_ though i don't know if it will fix it
<lifeless> possibly
<lifeless> basically pqm gets few edits
<lifeless> so it only encounters bzr api changes infrequently
<jam> morning poolie
<poolie> hi there jam
<spiv> poolie: I think the ImportWarning fix needs to be updated to support Python 2.4, which doesn't have ImportWarning.
<poolie> ah, yuck
<poolie> just when it finished merging all the way up too
<poolie> spiv i actually found a better way to do it, which is to just set a -W option
<poolie> ImportWarning is ignored by default even in 2.7 and i don't think it will actually help with anything to turn it on
<poolie> just for curiousity, did you just think of that, or did you notice in babune?
<poolie> spiv: a great example that nothing is truly trivial i guess
<poolie> spiv: hm the last ubuntu release with 2.4 is karmic which is eol now, or really soon
<poolie> but better not to accidentally break it
<poolie> lifeless: i got the result from your pqm tweak
<poolie> it's still including knownfailure/xfail results
<poolie> it would be nice to exclude them too because they're not relevant to any particluar landing
<poolie> aside from that it looks really good
<poolie> (not urgent)
<lifeless> that may need a tweak to subunit to know about that class in the filter module (or I may have an old version in my lp vm)
<lifeless> poolie: remind me monday
<poolie> sure
<poolie> thanks for the patch
<poolie> spiv yes that does fail on 2.4, not surprisingly
<poolie> ok i'm out for a bit, good luck
<lifeless> poolie: http://iatp.typepad.com/thinkforward/2011/04/us-subsidizes-brazilian-cotton-to-protect-monsantos-profits.html may entertain you
<spiv> poolie: I didn't check babune, the 2.4 issue is just something I thought of glancing at that patch for probably the 4th time in the last week or so
<spiv> poolie: the definition of âtrivialâ certainly isn't trivial!
<poolie> :)
<jelmer> spiv: +1
<jelmer> vila and I explicitly talked about the fact that ImportWarning wasn't in python2.4 when we were discussing why the ImportWarning didn't happen on hardy.
<jam> jelmer, poolie: So... time to deprecate python 2.4 support?
<jam> We've been searching for an excuse
<jelmer> jam: I don't remember what came out of the discussion in January; does bumping the minimum version to 2.5 gain us much?
<jam> jelmer: clearly it gets us ImportWarning
<jelmer> well, apart from that extremely exciting feature :)
<jam> jelmer: with statements
<poolie> jam, i think we should drop it in trunk
<jam> try/except/finally
<jam> jelmer: a much easier way to migrate to a python3 code base
<jam> note, though, that 2.5 still doesn't let us use "bytes()"
<jam> poolie: AIUI, the primary reason to support it was that RHEL5 only has python-2.4 and will be supported by RH for another 5 years or so
<jam> and if we introduce a new repo format that users need to upgrade to, they won't be able to get that on their RHEL systems.
<jam> poolie: but personally, I'm probably in favor of dropping 2.4 support in trunk. Especially since RHEL6 is officially out, so RHEL people have an upgrade path they can use.
<rom1> hi all
<rom1> I am checking a problem that i have with bzr-xmloutput
<rom1> about the ssh connections not closed until the rpc server is closed
<rom1> I am a bit lost to understand the flow to open a ssh connection through bzrlib
<rom1> Is there a developer doc describing this ?
<rom1> Or can you give me an api that i could  check ?
<jelmer> rom1: hi
<jelmer> rom1: The ssh connection is opened from a SFTP or SSH Transport, both of which get created when you open a Branch, Repository, BzrDir, etc at a remote URL
<jelmer> rom1: there isn't any functionality to close ssh connections as far as I know, I think there's a bug about it in bzr
<poolie> mm, i think there is a disconnect method
<poolie> but can you say more about just what's going wrong?
<rom1> thx jelmer
<rom1> poolie : in fact, i have many users using bzr-eclipse
<rom1> and for each commands sent to a remote repository, a connection is openned and never closed
<rom1> connections in bzr+ssh
<rom1> I had up to 400 connections for one user
<rom1> I have detected in fact taht's the xmlrpc server that keeps openning connections without nor closing them nor reusing them
<rom1> and i've seen that closing the rpc server, the connections are closed.
<rom1> i haven't this issue using directly the bzr command line
<rom1> so i try to see if i can force the connection closure in the rpc server (i am talking about the server from bzr-xmloutput)
<poolie> rom1, there is a Transport.disconnect method
<poolie> the key thing is to decide when it ought to disconnect
<poolie> and indeed why it's not reusing the existing connection if it is keeping them open
<rom1> indeed
<rom1> from what i see in the code, it calls the commands.main method
<rom1> code of the rpc server
<rom1> does bzr normally reuse existing connections ?
<poolie> rom1 only when the transport object is reused
<poolie> there's no implicit cache
<poolie> now i need to sleep though...
<rom1> good night poolie, and thx !
<jam> night poolie
<AfC> Oh man, I'm doing a bzr clone of a git repo, and it's "fetching revisions" at about 1 per second with 100% CPU. That's ok. Only 30,000 to go.
<LeoNerd> Last time I tried doing that, it ended up bombing out because it'd filled the /tmp partition with a huuuuuge binary blob file
<LeoNerd> I haven't touched it since
<AfC> I'm going to have to leave this running overnight. Wow.
<soren> AfC: A public get repo?
<AfC> soren: yes,
<AfC> $ bzr clone git://git.gnome.org/gtk+
<soren> https://code.launchpad.net/~vcs-imports/gtk/trunk
<soren> If you'd rather go that route.
<AfC> soren: that's a _conversion_ isn't it?
<AfC> soren: not a bzr-git repo?
<maxb> AfC: It's a bzr-git repo
<AfC> oh
<maxb> well, branch
<AfC> hm
<AfC> well, shit, ok
<AfC> Do you know if they're globally unique and repeatable? If I then use bzr-git myself against upstream am I going to end up with the same revids?
<james_w> AfC, yes, it is deterministic
<james_w> that branch is what you would get if you waited for yours to finish
<AfC> james_w: That's the word I was looking for, thanks. Clearly it's zzz time
<jelmer> AfC: Are you using bzr and dulwich with compiled extensions?
<AfC> james_w: very cool. Thanks. Pity it takes so long. Most people trying this wouldn't come here to ask / wait for it to finish [in the damn, more bad press sense]
<AfC> jelmer: hey
<jelmer> AfC: The gtk+ conversion took less than an hour here
<jelmer> AfC: Hi! Sorry, missed the conversation here earlier.
<AfC> jelmer: I couldn't say - I'm using whatever is packaged in the Bazaar PPA
<jelmer> that should be the packaged bits.
<jelmer> AfC: Are you using the nightly PPA or another one?
<AfC> jelmer: no releases. You guys have years of track record of warning people that dailies are broken. I don't need to try them myself to experience it.
<AfC> deb http://ppa.launchpad.net/bzr/ppa/ubuntu maverick main
<AfC> jelmer: ^ that one
<jelmer> AfC: snapshots may be broken, but the PPA packages run the testsuite before they're built
<jelmer> AfC: The followup on the bzr-git bug report, was that using a release?
<AfC> jelmer: yes
<AfC> jelmer: (I said so there :))
<AfC> jelmer: I've been working on your request to blow it away and start again
<jelmer> AfC: is that 0.6.0 or something earlier?
<AfC> wha? It's whatever you released into the Bazaar PPA
 * AfC looks
<AfC> yes
<AfC> git 0.6.0
<jelmer> ok, that should be recent enough
<AfC> Wow. It did a repack at 10,000 revisions and now it's back to 1/second.
<AfC> Only 22,000 to go
 * AfC is astonished this only took you 1 hour
<jelmer> AfC: do you have bzr 2.3 or 2.4 ?
<AfC> jelmer: whatever is released by the Bazaar project in the PPA.
<AfC> $ bzr --version
<AfC> Bazaar (bzr) 2.3.1
<jelmer> I'm running 2.4. I'd be surprised if it made that much of a difference though.
 * jelmer tries another clone of gtk+
<AfC> {shrug} don't want to waste your time
<jelmer> it's not that much effort :)
<AfC> but it seems like some profiling of this run might bear some fruit
<AfC> I guess I should abort this and just use ~vcs-imports
<jelmer> it'd be great to know if it was indeed related to the shared repository you were doing the clone in
<AfC> jelmer: but I will let it continue & then attempt to pull in it periodically over the next few weeks so as to confirm that bug is gone
<AfC> jelmer: I'm disappointed that the branch's revisions got corrupted like that, though. I've never experienced that with Bazaar before.
<AfC> jelmer: obviously we don't want that to happen, so I wish I could give you more information.
<jelmer> AfC: it's not corruption, it's just that bzr-git can't regenerate the original git commit from the bzr revision
<jelmer> though I admit the error message looks a bit scary
<AfC> just a little [and to an end user, it's corruption :)]
<AfC> Well, I will leave this running. I'll check back tomorrow
<BasicOSX> do! heh Adium on Colloquy!
<poolie> hi BasicOSX!
<BasicOSX> hello
<BasicOSX> wrong channel :-)
<poolie> :)
<kirkland> maxb: hey, i finally got around to testing your lp:~maxb/bzr-builddeb/no-error-unknown-distro branch ...
<kirkland> maxb: it gets me past the first error, but still another blocker:
<maxb> hi
<kirkland> maxb: bzr: ERROR: Inconsistency between source format and version: version is native, format is not native.
<maxb> uh, well, that's slightly good :-)
<kirkland> maxb: :-)
<maxb> cat debian/source/format and head -n1 debian/changelog say what?
<kirkland> maxb: okay, i worked around that one by removing debian/source/format
<LeoNerd> It strikes me that 'bzr missing' is slightly misnamed, if it reports that the local branch has more than upstream does..
<maxb> nah, it tells you what upstream is missing :-)
<LeoNerd> Hmmm... I suppose that's true
<knighthawk> I just did a bzr svn-import
<knighthawk> now when I try to create a branch I get the following errr
<knighthawk> zr: ERROR: Not a branch: "/home/pluvious/wc-grc/.bzr/branch/": location is a repository
<knighthawk> is there something I need to do first to access it?
<knighthawk> I also tried to do a checkout but I think I got the same error
<mr-russ1> knighthawk: you don't branch the .bzr
<mr-russ1> wc-grc is the repository that hosts branches.
<mr-russ1> you should be able to branch from  wc-grc/trunk
<knighthawk> mr-russ1, thanks
<knighthawk> I may have a layout issue.
<mr-russ1> knighthawk: probably, I've found it painful to get svn converted to bzr the way that I'd like.
<mr-russ1> repository is a collection of branches.  it's there to save space as the common revisions are only stored once.
<mr-russ1> repository is really good for projects with multiple branches.
<mr-russ1> off to work for me now.
<maxb> knighthawk: So, wc-grc was the root directory created by the svn-import?
<maxb> It should contain within it a number of other directories which mirror the structure of branches within the svn repository
<knighthawk> maxb yeah I just had to drill down to the trunk
<knighthawk> seems to be working now. only I did a branch instead of a checkout so I'm not all that sure how many extra steps I'm going to have to do to have it work like svn (well sort of like svn)
<poolie> hi all
<spiv> poolie: Good morning
<spiv> poolie: http://albertomilone.com/wordpress/?p=502
<poolie> that's good
<poolie> o/ cinerama :)
<cinerama> hi!
<poolie> spiv i'm finding i get by fairly ok with hamster just in the launcher
<jelmer> 'morning poolie, spiv
<poolie> hi jelmer
<poolie> i guess first of all i should revert the importwarning landings, unless someone else already did
<jelmer> nobody has yet, I wasn't sure what the right thing to do was
<jelmer> I guess we can fix it to use ImportWarning if available and otherwise just catch ImportError /
<poolie> i think the right thing is -Wignore::ImportWarning as long as that works on 2.4
<poolie> i think it will, but i'll test it now
<poolie> it seems to
<poolie> so i'll revert the change to the except statement and add that to the makefile?
<jelmer> wfm
<spiv> jelmer, poolie: see my comment on the MP
<spiv> You can just do "try: errors = (ImportError, ImportWarning) except NameError: errors = ImportError" then use "except errors"
<spiv> Oh, jelmer just said basically that.
<spiv> I don't have a strong opinion on -Wignore::ImportWarning vs that
<spiv> I guess we don't need that normally because normally we don't use -Werror?  Does the -Wignore::foo stack nicely with -Werror?
<poolie> yes, as long as you specify them in the opposite order to what the manual implies :)
<poolie> -Wignore is shorter :)
<poolie> arguably we should actually just blacklist with -Werror warnings we do actually care about
<poolie> if this happens again i'd probably do that
<poolie> biab, natty upgrades...
#bzr 2011-04-15
<mgz> Invalid -W option ignored: unknown warning category: 'ImportWarning'
<mgz> I get spew, but otherwise seems harmless.
<mgz> That one line change does seem a daft thing to drop Python 2.4 support over.
<poolie> oh, do you?
<poolie> i don't want to drop 2.4 support over this
<poolie> ah, i was wrong
<poolie> i forgot karmic's _default_ python is not 2.4
<spiv> mgz: we need -Wignore:UnknownWarningWarning ;)
<poolie> :)
<poolie> so it's either a conditional binding of that name if it exists, otherwise just -Werror for some explicit things
<poolie> hm, really rebooting now, unity bug filing done for teh moment
<hugogee> greetz all :D
<hugogee> I run openbsd and am interested in using Bazaar. Good stories, bad, i would like hear. tx
<hugogee> sup poolie
<poolie> hi hugogee
<poolie> it's good; i like it
<poolie> what are you going to use it for?
<hugogee> Yes it seems good. I just want to know what i am up against trying to get the shoe to fit. :D
<hugogee> community collaboration.
<hugogee> how well does it work with binary files?
<poolie> what kind?
<poolie> it compresses them well, if they're at all compressible
<hugogee> Word, excel...
<poolie> it's not going to be able to natively diff or merge them
<hugogee> diff ? or
<poolie> there is a plugin to diff them
<hugogee> oh, do tell.
<poolie> to show the changes from one version to the next
<poolie> i have to say Word and OpenBSD sounds like a strange combination to me :)
<hugogee> Hehehe
<hugogee> Its for collaboration.
<poolie> if it's all office files, you may be better off using microsoft's collaboration things
<poolie> much as i like bzr it is designed more for managing code
<hugogee> naw!
<hugogee> yes i understand but subversion does handle binary. so long as i can backup and restore all will be fine.
<hugogee> m$ < great
<hugogee> m$ > free
<poolie> if you're happy with svn's binary handling bzr should be fine too
<poolie> spiv one more thought:
<hugogee> yes, i am trying to make it easy for this nice little community of people.
<poolie> spiv, mgz, getting a -W meta warning during 'make check' is pretty harmless
<mgz> that's my feeling too.
<poolie> otoh other places might also hit ImportWarning
<mgz> I prefer changing the makefile to the code.
<poolie> other than just this thing
<poolie> right
<spiv> I'm fine with just changing the makefile.
<spiv> I don't think anything depends on stderr of 'make check' being clean
<poolie> so 2.1 apparently fails on py2.7 with AttributeError: 'module' object has no attribute '_WritelnDecorator'
<poolie> this rings a bell
<mgz> I didn't fix 2.7 errors on 2.1
<mgz> only 2.3
<mgz> a couple also landed on 2.2, but if you want to use... dammit... Python 2.7, you need Bazaar 2.3
<poolie> fair enough
<poolie> i was just testing my change didn't break later versions
<mgz> this may not be clearly documented anywhere.
<poolie> i would almost land a change saying this or giving a clean error
<poolie> but it can probably wait until someone hits it
<poolie> it's a bit like the plugin versioning thing, and whether it's important to warn about too-new bzrs
<lifeless> hi mgz
<mgz> hey lifeless!
<poolie> hi lifeless
<lifeless> hey poolie
<poolie> wow running the 2.1 tests on natty is a bit annoying
<poolie> bzr itself runs fine but there are snags around the edges
<poolie> lifeless: thanks for the pqm improvement
<lifeless> poolie: my pleasure
<poolie> can we have one of us also do xfail?
<poolie> ah a clearer way to put that would be
<poolie> could you either do it (not right now) or give me a clue where to change it?
<poolie> do those machines just run pqm trunk?
<lifeless> So xfail
<lifeless> The machine uses subunit from package
<lifeless> and a branch of pqm which the losas pull into on request
<lifeless> *if* the subunit they have has a TestResultFilter ready to handle xfail
<lifeless> then its easy - just another parameter to the filter thats constructed
<lifeless> if not, then we need to start with subunit and bubble it through
<lifeless> not terribly hard
<poolie> k, so first we need to either grep the package for that, or find out what package is installed
<poolie> and this would be the subunit outside of the chroot
<lifeless> poolie: yes
<lifeless> poolie: my packaged subunit here says
<lifeless>  |  __init__(self, result, filter_error=False, filter_failure=False, filter_success=True, filter_skip=False, filter_predicate=None)
<lifeless> for pydoc subunit.test_results.TestResultFilter
<lifeless> so I think johns patch needs a re-look, then merged, a release, package, and updated in CAT
<poolie> ok
<poolie> biab
<poolie> nice revert speedup jam
<poolie> spiv:
<poolie> blah
<poolie> https://code.launchpad.net/~mbp/bzr/trivial-2.1/+merge/57802
<spiv> poolie: approved
<hugogee> nite folks! :D
* Topic unset by poolie on #bzr
<poolie> gack
* 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: poolie
<poolie> omg look at them all
<lifeless> poolie: hairball?
<poolie> xchat-gnome has what may be a natty regression
<poolie> that just typing //topic doesn't print the topic, it clears
<poolie> it
<puzzlement> poolie: Sent you an email re spiv's availability (or lack thereof) this afternoon.
<poolie> got it, thanks for letting me know
<poolie> no problem
<jam> thanks poolie, morning?
<poolie> hi jam!
<poolie> spiv is off sick
<poolie> or more precisely his son is sick
<poolie> jam, how are you
<poolie> i'm going to merge up the 2.4 regression fix, and finish off some old patches in the queue
<jam> poolie: things are going pretty well here. Getting some random fallout in the test suite from my 'faster-merge' patch. It turns out that a fair amount of code accidentally assumed that all files would be declared to the TreeTransform
<jam> so only mentioning the actually changed ones had random fallout elsewhere
<jam> nothing hard, just annoying
<jam> and then I fixed one incorrectly, but accidentally ran the bzr.dev test suite instead of my working copy before submitting it again :)
<poolie> :)
<poolie> in a while we might get a faster pqm, which would be nice
<poolie> it's funny how old bzr 2.1 is
<jam> poolie: indeed.
<jam> (on both accounts)
<poolie> eg it has hard test suite dependencies on paramiko and others
<jam> poolie: we always tried to make stuff like paramiko soft, but we often missed a test here and there.
<poolie> i think i will try to finish the diffoptions thing
<poolie> maybe after one more of jelmer's patches
<bradm> poolie: so, hi
<bradm> poolie: do you think we still need that old chroot on balleny?
<poolie> bradm: nah
<bradm> poolie: okey, I'll blow it away then, and close off that ticket
<jam> poolie: you have both "760435-unittest-deprecations" and "760435-less-fail" was the latter supposed to have a precondition on the former?
<poolie> ah yes
<jam> poolie: anyway, both "merge: approve"
<jam> Of course, assuming it is all mechanical
<jam> but it certainly seemed fine
<poolie> it is
<poolie> thanks for checking though
<poolie> jam i've been stewing on a blog post about matchers
<poolie> maybe after i do one more hr task i will actually write it odwn
<lifeless> poolie: too java ish ?
<poolie> a bit
<lifeless> poolie: you should see the one I turned my nose up... was worse
 * poolie looks
<poolie> haha
<poolie> i'd like to say
<poolie> assertsomething not fileexists('foo')
<poolie> and have it give a smart message when it fails
<poolie> i think i have a testtools bug about it
<jam> poolie: specifically that 'not' gives bad messages?
<jam> or that fileexists('foo') tends to just give success/failure rather than a clear message?
<poolie> by the time it gets to 'not', all it sees is a boolean
<poolie> ideally this would be a bit more HOF-ish
<lifeless> HOF ?
<lifeless> poolie: assertThat('foo', FileExists()) doesn't work for you ?
<poolie> higher-order-function
<poolie> that's ok, though a bit longwinded
<poolie> what if i want to assert it does not exist?
<lifeless> poolie: assertThat('foo', Not(FileExists()))
<poolie> so you get 'foo matches FileExists(something)'
<lifeless> what is something ?
<jam> lifeless: I think the point is that if "assertThat('foo', Not(FileExists())" fails, he wants to get a nice message "file "foo" was not supposed to exist, but what found"
<jam> *but was found
<lifeless> so it will say "'foo' matches FileExists()" with current testtools
<jam> And Not(Matcher) doesn't tend to give good error messages.
<lifeless> it is a currying/HOF approach; the protocol is /slightly/ more than simple functions can do though
<jam> lifeless: so I can't put my finger on it exactly, but I have noticed that bzr test suite failure messages are more legible than the Launchpad ones going through Matches
<jam> Matchers
<lifeless> jml and I would welcome improvements
<poolie> lifeless: in short i wonder if they should return matches as well as mismatches
<lifeless> matchers are taking off organically in lp development
<poolie> also i would like to just call them, getting rid of the self.assertThat
<poolie> which is a bit longwinded
<jam> poolie: golang seems to just use "assert(...)"
<poolie> raising an exception is a clear indication of failure
<jam> using matchers
<jam> at least from niemeyer's examples that I've seen
<lifeless> a key part of the point of matchers is to separate [mis]matching and error conditions
<lifeless> things raising AssertionError are pretty awkward to layer upon
<poolie> well, this is the tradeoff
<poolie> perhaps it is possible to find something that is not so longwinded but does allow layering
<poolie> jam i think there assert() is a semi builtin
<poolie> like in python in fact
<poolie> though not crippled
<jml> It would be easier in a language that had better partial function application syntax
<jam> poolie: http://paste.ubuntu.com/593640/
<jam> it is on an object
<jam> I don't know what "c" is
<jam> case ?
<poolie> too much python :)
<jml> There are some issues with the matcher traceback that make it harder to read (duplication, layers of stack that are boring to most people)
<poolie> i think it's a good step forward,  just not utopia
<jml> sure
<jml> I don't have solutions for the syntax issues that you are raising, so I'd welcome ideas.
<poolie> jam i'd guess it's basically a typedef for TestCase
<jam> poolie: yeah, that was my guess, too. though having "s *S" and "c *C" is really odd to me. :)
<jam> also, declarations are backwards from c, so c *C is "C *c" in C-code
<jam> I might have been able to fit more letter C in that sentence
<poolie> jml: stephane says "why are they having a thing called Thunderdome in Dublin? Shouldn't it be in Silverton?"
<jml> :)
<poolie> "the cracked lookingglass of a servant, a symbol of irish art"
<lifeless> c.Assert(result.Host, Not(Equals), host)
<lifeless> looks almost exactly like our Matcher syntax
<lifeless> slightly less curried
<lifeless> or more, depending on point of view
<poolie> mm the half-currying is a bit odd too
<poolie> maybe it's good if it makes the expected bit clear
<poolie> anyhow, i really have to go...
<poolie> have a good weekend
<lifeless> ciao
<poolie> congrats on your appservers
<lifeless> it will be nice to be running lp on something more powerful than your pqm machine :P
<lifeless> [thats a slight troll, we do have some seriously powerful machines in play already :))
<jml> poolie: one of my many favourite lines from that book :)
<maxb> jelmer: We need to fix the dulwich branches - PPA and daily builds are now being impacted by something similar to what I saw in bug 707170
<ubot5> Launchpad bug 707170 in Bazaar Git Plugin ""Cannot add revision(s) to repository: missing text keys" branching lp:dulwich and alioth packaging branch into same shared repo" [Undecided,Invalid] https://launchpad.net/bugs/707170
<kgoetz> can i list all files modified modified between certain revisions without a full diff?
<lifeless> bzr st -r x..y
<kgoetz> thanks
<Odd_Bloke> I have accidentally branched from a non-trunk branch and created my branch ready to merge into trunk.  How can I remove the changes introduced in branch I based it on?
<tasslehoff> we went from svn to git a while back, and find that git on windows is slow and sad. does bzr-git work well/fast on windows?
<tasslehoff> we thought to start there, and then maybe move everything to bzr if it works out
<maxb> I think bzr-git works pretty well. I don't use Windows, though
<jelmer> tasslehoff: bzr-git on Windows doesn't work with ssh yet
<tasslehoff> jelmer: ah. that was important to know. thanks.
<jelmer> tasslehoff: it shouldn't be hard to fix, it just hasn't happened yet
<knighthawk> I'm still trying to figure out bzr-svn. I did a successful svn-import then pulled a branch from that. but now I have no idea how to do an update or a commit back to the svn repo
<knighthawk> I thought a merge from my branch to the import then I could commit back.
<knighthawk> but I'm still stuck on doing the update.
<knighthawk> it seems my biggest issue right now is that I don't have a working tree in the import (and I don't think I should need one) but then I can't update from there.
<maxb> knighthawk: It sounds like you have some terminology confusion besides other things. I think many places where you're saying "update" you don't mean "bzr update", the command.
<maxb> For clarity, best to avoid that confusable.
<maxb> The key point to understand about bzr-svn is that it presents the virtualization that svn branches operate just like bzr branches
<maxb> Also, there's nothing special about a bzr branch produced by "bzr svn-import" - it's just a shortcut to individually "bzr branch"ing each branch in the subversion repository
<maxb> So, if you want to land a branch developed in bzr back into svn, then you have much the same options as you do when landing a branch developed in bzr back onto its parent bzr branch.
<maxb> So, one option is that if the parent branch has not diverged, you can simply push your changes
<maxb> Or, if the upstream branch has diverged, it's usually appropriate to merge your development into a local copy of upstream, and push the result
<wizonesolutions> I'm getting an I/O error on one of my repository packs :( can't do anything to it, and it's in the repository for a branch I want to check out...
<wizonesolutions> So I don't think I could bzr branch it somewhere else and check out from there either since it'd probably have to touch that pack
<wizonesolutions> e2fsck came back clean, but I think the drive is just old and starting to run into some probs...not really sure how to recover this file or proceed...
<wizonesolutions> as suggested by smartctl
<maxb> wizonesolutions: You should pastebin the exact error, "an I/O error" is insufficiently detailed to best understand your project
<maxb> erm
<maxb> s/project/problem/
<wizonesolutions> maxb: It really is just "input/output error" though from Bazaar's standpoint it's a ShortReadvError or something. But an underlying I/O error is the cause. My box decided to go crazy though so when it comes back...will let you know.
<wizonesolutions> lol @ sed on IRC
<maxb> Hrm. Well, if you can't even copy the file from that disk to elsewhere, then you do have serious problems
<wizonesolutions> maxb: Yeah :/ I'm not sure if bzr branch is working cuz my system is acting weird. Probably cuz of bzr using 100% CPU again or something. But it did seem to be getting farther with that approach than before.
<wizonesolutions> The issue's in the shared repo, not the branch itself.
<maxb> If it's a younger pack which is broken, it's possible that there might be scope for recovering older parts of history. But some dataloss is almost certain
<wizonesolutions> so if I can branch elsewhere then I can save it and I'm good
<wizonesolutions> ah
<maxb> Can you run "find .bzr/repository -ls" and pastebin it?
<wizonesolutions> Sure...couple mins, gotta see if I can still SSH in or something and what it's up to
<wizonesolutions> maxb: http://pastebin.com/Q4Ldj5nF
<maxb> wizonesolutions: And which packs have problems?
<maxb> In any case, if the disk is in doubt, I think your first priority should be to get the files off as intact as possible
<wizonesolutions> maxb: 34d110e625509acc103c649ed7cc6cb7.pack is the culprit. The couple-gigger
<maxb> Ouch, it had to be, didn't it
<maxb> Being that that's the oldest pack in the repository, recovery prospects are not good
<wizonesolutions> Well, I've got the files backed up elsewhere fortunately. Perhaps I can try to restore it from there, .bzr and all, and hope that it comes back sane. This is where every branch containing the full history starts to hold its salt, eh :)
<wizonesolutions> Seems like branching to another dir actually did fail. I mean that makes sense given that the whole point of a shared repository is that it gets touched when doing stuff on the branches under it and that some revs are shared, etc. so I'm not surprised.
<wizonesolutions> maxb: Oh, but it's a checkout, the one I have. But I should be able to unbind it without probs...yeah so I have the files at least. Well that's the main thing
<maxb> lightweight or heavy checkout?
<wizonesolutions> heavy
<maxb> oh
<maxb> well, no problem then
<wizonesolutions> yeah so I'll see if restoring it from backup does the trick...probably should
<wizonesolutions> these hard drives man, they always obey Murphy's Law
<wizonesolutions> I love and hate how hard drives just keep working even as the problems build up
<wizonesolutions> and then eveeeeeentually they nail you when you least expect it
<wizonesolutions> It's one of those things I never test until there's a problem, but by the time there's a noticeable problem things are bad. :/
<wizonesolutions> ah well
<wizonesolutions> thanks a lot maxb for the time and help!
<poolie> hi all
#bzr 2011-04-16
<mgz> hey poolie. must be bedtime again.
<poolie> :)
<poolie> nice to see you
<edsiper> help needed: what means the NotStacked error ?
<kgoetz> lifeless: sorry about not replying yesterday, thanks for the bzr st -r  tip
<ub3rst4r> hi, for some reason when i try to push to a new branch i get this: bzr: ERROR: At lp:lilregdefrag/1.0 you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again. Any Ideas?
<ub3rst4r> !ping
<ubot5> Here I am, brain the size of a planet and they ask me to respond to factoid requests. Call that job satisfaction? Because I don't.
<lifeless> kgoetz: no worries
<edsiper> i'm trying to do a simple command plugin but is not being recognized, i pasted the code here: http://pastebin.com/dpmnBfUf
<edsiper> any ideas ?
<jelmer> edsiper, why the "True" argument to register_command /
<jelmer> "bzr foo" doesn't do anything?
<edsiper> jelmer, just to be sure that no foo command exists previously
<edsiper> jelmer, bzr: ERROR: unknown command "foo"
<jelmer> edsiper, does "bzr plugins" listyour plugin?
<edsiper> nop
<jelmer> edsiper, where have you put the plugin?
<edsiper> jelmer, .bazaar/plugins
<edsiper> a file called foo.py
<jelmer> ~/.bazaar/plugins /
<jelmer> ?
<edsiper> yep
<jelmer> edsiper: you should only specify True when decorating existing commands
<edsiper> jelmer, just drop that flag... continue the same, one question, i have another plugin which acts like a post-push hook and it works (at least is recognized after a push), but is not listed after bzr plugins
<jelmer> not sure what's going on there, "bzr plugins" should show your plugin if it's there
<edsiper> jelmer, i have plugin bazplugin.py , it works after a push, but i don't see any entry with that name in bzr plugins
<edsiper> is there any updated tutorial ?
<edsiper> i'm just stuck in the easier step :/
<jelmer> edsiper, putting a .py file in ~/.bazaar/plugins should be sufficient
<jelmer> it works here
<edsiper> jelmer, hmm, it worked in my local computer, seems like a path problem in the server where i'm working
<edsiper> jelmer, is there any doc/how_to about how to write a new server command with a specific transport ?
<edsiper> i already cloned cmd_serve to create my own server which needs to use a different transport
<edsiper> but not sure how to link it
<edsiper> i'm basing the code in cmd_serve
<jelmer> edsiper, not sure I follow
<jelmer> edsiper, what do you mean with specific transport?
<jelmer> edsiper, if you're adding a thing similar to cmd_serve you should register that command, as you were doing earlier
<effemirc> Hi people
<effemirc> I have a problem and I do not know where to look
<effemirc> Some people use tracbzr with trac?
<effemirc> I have installed trac 0.12 with new tracbzr
<effemirc> 0.4...
<effemirc> I show perfectly repository in trac, but when I do trac-admin project1 repository resync repository1
<effemirc> I get "0 revision cached"
<effemirc> and if I search a keyword in changeset, trac non found nothing
<effemirc> uhm ... where can I go wrong?
<effemirc> thanks....
<vanguard> I have made some changes in my trunk branch, that I would rather have in a feature branch. How can I branch the current stuff of and revert trunk?
<effemirc> somebody use tracbzr plugin?
<edsiper> anyone fixed this ? https://bugs.launchpad.net/bzr/+bug/322299
<ubot5> Ubuntu bug 322299 in Bazaar "bzr starts raising error on all actions after usin repo for a while: # ValueError: invalid literal for int() with base 10: 'None'" [High,Invalid]
#bzr 2011-04-17
<dchilton> I've a bzr-managed tree that's got years of history.  I'd like to ideally clear out all history before a specific revision # ~ 1 month ago.  Is there a way to do that?  Another option is just to start 'from zero history', with a new/immediate revision.  Is that a (better) option?
<quiznilo> ssh-copy-id appears to have locked up!
<quiznilo> is that typically a long-running command?
<wizonesolutions> I just restored a branch from backup that was a bound branch. The repository got corrupted cuz of a bad disk, so I unbound it. However, bzr status shows all files as new and it doesn't appear to have any revision history. I thought that branches should be able to stand alone? Where are the revisions stored? Maybe I didn't restore something...
<wizonesolutions> Oh, and the repository was on a different box, so this was a checkout. I restored just the checkout.
<wizonesolutions> Hopefully once I put the new HD in the offending box I'll be able to restore the bad pack to that too and then maybe I can rebind it and reconcile it. I mean, if I was still able to commit (I was) then perhaps I'm OK. But yeah...if anyone has any ideas on what could cause a checkout that is later unbound to be unaware of its own history (it was a heavy checkout)...all ears.
<lifeless> wizonesolutions: bzr info -v ?
<wizonesolutions> lifeless: http://pastebin.com/YE7vuyyj
<lifeless> thanks, trying to bring that up (having some issue, may be local internet)
<wizonesolutions> lifeless: If it expires let me know...I set it to 10 mins
<lifeless> I can't seem to grab any new tcp connections
<lifeless> outside of nz
<wizonesolutions> lifeless: pm?
<lifeless> sure
<lifeless> that should work
<lifeless> wizonesolutions: what about 'bzr revision-info'
<wizonesolutions> 0 null:
<lifeless> hm
<lifeless> if you have bzrtools you should be able to run 'bzr heads --all' to find out if the history is locally available
<wizonesolutions> "No heads found"
<wizonesolutions> It is truly hosed, doctor?
<lifeless> sounds like it
<lifeless> uhm
<lifeless> bzr dump-btree .bzr/repository/pack-names
<lifeless> might be a non trivial final check
<wizonesolutions> Yep it's empty. Strange. I guess that checkouts aren't as full as I thought when a shared repo is in the mix. Good to know.
<wizonesolutions> This taught that me that I should only use shared repos if I plan to put stuff in them that actually will have shared revisions. Otherwise it's a rather undesirable point of failure for several unrelated branches!
<wizonesolutions> No pain no gain, eh
<wizonesolutions> Good thing for backups
<wizonesolutions> Maybe I will be able to recover it on the new HD, fingers crossed
<wizonesolutions> It's an old pack that's unreadable so I don't think it's been changed for quite some time...
<lifeless> good luck
<sobersabre> hi guys.
<sobersabre> Is there a diagram/table describing time/size complexity of bzr operations - like adding, checkout, update, etc. ?
<lifeless> sobersabre: add should be near instance
<lifeless> operations that extract text from the repo need about twice the size of the largest file they extract in memory
<poolie> hi all
<jelmer> hi poolie
<poolie> hi jelmer
#bzr 2012-04-09
<safinaskar> how to download/checkout/clone remote repo?
<safinaskar> i understand :)
<maxb> The UDD importer appears to be stuck
<maxb> james_w: Hi, what's the status of the UDD importer? (Since you seem to have its crontab open for editing)
<maxb> poolie: Do you know anything about the UDD importer being stuck/stopped?
<poolie> hi maxb
<poolie> i did see some errors over the weekend
<poolie> (we had a long weekend)
<poolie> i don't know anything specific about what james is doing
<poolie> he did have a lot of outstanding patches which i think he was going to merge and deploy
<poolie> so perhaps it's connected to that
<maxb> It looks like it was shut down, but failed to update the sqlite db during shutdown, so the status page claims jobs are still running
<poolie> james_w, don't suppose you're up?
<poolie> maxb, so i suppose our options are to either just start it, or wait for a reply from james
<maxb> pretty much
<maxb> we do seem to have a rather large backlog at the moment
<maxb> max_threads is also set to 4 currently, which is lower than I'm used to seeing
<maxb> I've just run a single package because I wanted a branch up-to-date for my own purposes - no problems observed
#bzr 2012-04-10
<maxb> the vast burst of ssh connection reset errors (which I've just requeued) might be why it was stopped
<maxb> I've emailed the list
<poolie> thanks
<poolie> there was a bug where the importer was tickling an lp bug
<poolie> i think we can ramp it up more now
<poolie> maxb, did you see my pm?
<james_w> hi
<james_w> I stopped it as it was failing hard and spamming error messages every 5 minutes
<james_w> so I disabled it until we could take a more in depth look
<james_w> I should have mailed the list when I did though, sorry
<maxb> james_w: hmm, I did a single import via bin/import-package and it completed fine
<maxb> i'm tempted to start it going with max_threads 1 and see what happens
<james_w> yeah, the issue was sqlite contention
<james_w> so a single import succeeding isn't surprising
<maxb> ok, starting it up
<maxb> huh
<maxb> apache2 is chewing jubany's cpu
<james_w> maxb, for packages.ubuntu.com perhaps?
<maxb> urgh, it appears to be being hit by 4+ webspiders simultaneously
<maxb> Started, seems ok, going to 4 threads
<maxb> seems ok, going to 8 threads
<maxb> seems ok, going to 16 threads
<lifeless> uhm
<lifeless> what does each thread entail ?
<lifeless> you'll get blacklisted and firewalled from LP shortly if that is full concurrent API use.
<maxb> there's a fair amount of unpacking tarballs and local bzr operations
<maxb> hmm, running into sqlite contention again
<maxb> down to 1 thread
<maxb> most finished ok, so back to 8 and seeing if the sqlite db can handle that
<poolie> maxb, maybe we should set up tmpreaper or similar on the tmpdir
<poolie> i thought there might have already been one
<poolie> anything over a month old could probably safely be killed
<maxb> we could. or we could just empty it manually every year :-)
<james_w> heh
<maxb> It's not entirely happy
<maxb> looks like it fails whenever two import threads try to complete at the same time
 * maxb drops it to 6 threads and hopes coincidence will mean that happens rarely whilst it slogs through the backlog
<james_w> maxb, the old code had an sqlite timeout of 30 seconds, the new one defaults to 5
<james_w> maxb, what do you think about trying 30 again?
<maxb> definitely do it
<james_w> maxb, https://code.launchpad.net/~james-w/udd/sqlite-timeout/+merge/101317
<maxb> approved
<james_w> ok, deploying now then
<james_w> I would get stuck waiting for gcc-snapshot to push wouldn't I?
<james_w> oh, it's pulling
 * james_w kills
<james_w> back up and running on the new code
<james_w> maxb, thanks for tracking this
<mgrandi> hmm, got a tree transform is malformed exception o.o
<lifeless> james_w: why don't you move to postgresql?
<poolie> o/ lifeless
<jelmer> 'morning
<mgz> morning all
<vila> hi guys
<jelmer> hey mgz, vila
<lifeless> poolie: hi thar :)
<poolie> hi
<mgz> we doing standup?
<jelmer> in 30m according to my calendar
<mgz> yeay timezones.
<LarstiQ> ooh, standup
<LarstiQ> jelmer: is landing in bzr-svn just pushing to lp:bzr-svn?
<jelmer> LarstiQ: basically, yep
<jelmer> LarstiQ: perhaps push a merge of the changes rather than the individual changes
 * LarstiQ nods
<jelmer> I haven't reallyt been doing that myself though, so me asking is a bit hypocritical :)
<LarstiQ> jelmer: not watching the monkey ;)
<jelmer> (:
<jam1> jelmer, poolie: where are you guys doing standups these days? Still mumble? or is it a hangout now?
<jelmer> hey jam1, are you joining us?
<jam1> Yeah, I should be today
<jelmer> we usually use hangouts
<jam1> and then going forward
<jelmer> \o/
<poolie> hi all, hangouts
<LarstiQ> jelmer: could you lend a hand with https://bugs.launchpad.net/bzr-svn/+bug/920411 ?
<ubot5> Ubuntu bug 920411 in Bazaar Subversion Plugin "bzr info fails due to missing subvertpy" [Medium,Triaged]
<LarstiQ> jelmer: bzrlib/info.py +499 seems to want to instantiate all registered bzrdirs
<jelmer> LarstiQ: that seems like the man issue
<jelmer> *main
 * LarstiQ nods
<jelmer> perhaps this bug should be reassigned to bzr
<poolie> o/ larstiq
<LarstiQ> hey poolie :)
<LarstiQ> jelmer: alternatively perhaps bzr-svn shouldn't register a format if subvertpy is not available, or somesuch
<LarstiQ> but info's behaviour is not nice anyway
<jelmer> LarstiQ: that would cause bzr to silently e unable to open svn woring copies if subvertpy is mising
<LarstiQ> jelmer: so ideally it will complain that subvertpy is missing when it tries to open an svn working copy, but not before?
<jelmer> LarstiQ: yeah
<rbasak> Hello! Any chance of an answer to https://answers.launchpad.net/bzr-fastimport/+question/192715 please? Is this a bug?
<poolie> thanks for the reproduction
<poolie> it does sound like a bug
<jelmer> rbasak: I think you want to specify the marks file to bzr fast-import too
<rbasak> jelmer: bzr fast-import uses its own internal marks file inside .bzr
<rbasak> jelmer: I don't think it needs to know about the id to git hash mapping, does it? Just it's own id to bzr id mapping
<jelmer> hmm, true
<LarstiQ> jelmer: cheers, enough digging for now
<james_w> lifeless, that's exactly what these problems are being caused by :-)
<sudarshans> please note: as I  mentioned here https://answers.launchpad.net/bzr/+question/192935 the developer docs need to be updated
<sudarshans> lifeless: ^
<sudarshans> jelmer: thanks for helping me locate the answer to my question
<lifeless> jelmer: are you RFA'ing the whole bzr stack ?
<jelmer> lifeless: no, just (trying to) reduce the number of packages I'm involved in
<maxb> james_w: ugh ugh ugh. Yes, the problem with requeue --full / --zap-revids *is* non-unicodeness
<maxb> how on earth is storm managing to break so badly that it silently does nothing :-(
<poolie> hi all
<jelmer> hey poolie
#bzr 2012-04-11
<bj0> i have several different projects in their own branches, i want to tag them all with the same tag (because they are bundled together in a release).  Is there an easier way to this than individually tagging every branch?
<bj0> like a 'virtual' branch that points to all the projects?
<spm> out of curiosity, does bzr have the ability to update all branches in a given tree. so if I have main repo A, have in that tree have repo's B & C, is there a bzr update --all style of command that will update all repos in the given branch/tree?
<spiv> spm: your choice of terminology is a bit weird, but IIRC bzrtools includes a repo-pull or multi-pull or something command that will find branches under your cwd and pull in all of them
<spiv> spm: (and maybe the new colocated branches have something along these lines?)
<spm> spiv: hola. right that's pretty much what I was chasing - sorry, was talking svn/bzr with some sysadmin mates, and hence the weirdness.
<poolie> o/ spm, spiv
<spm> o/ poolie
<lifeless> spm: also config-manager can do that
<lifeless> spm: when you're dealing with N-trees (vs N-branches of one tree)
<spm> lifeless: yup. that was the one I was directly aware of; this was more of a can bzr do a more naive implementation to what cm does
<spm> the context was a (brief) discussion wrt svn externals; I was idly curious if bzr had similar - outside of cm
<spm> not that I expect to convert them, yet; but hey. :-)
<bob2> cm, blast from the past!
<lifeless> bob2: there is an internal doc on best practice for dev& deploys
<lifeless> bob2: unknown to me, -ops have been using cm all this time; said doc mandates continued use
<bob2> haha
<lifeless> ironically, LP has reinvented it with a different name, but -ops still use cm to do the deploys
<lifeless> by ironic, I mean hahaonlyserious
<bob2> fascinating
<bob2> surprised no one noticed earlier
<lifeless> spiv: I'm coming to sydney fri/sat/sun; any chance of catching up with you three?
<spiv> lifeless: hmm, probably!
<LarstiQ> spm: there are also bzr-externals and scmproj
<spm> ahh cool, thanks!
<lifeless> spiv: my itinerary is poolies thing on friday, hack day with erik on sat, possibly yum cha, or possibly $whatveer sun, 4pmish to airport
<mgz> morning all!
<vila> mgz: hey
 * fullermd ambushes vila.
<vila> . o O (Stay still or run ?)
<fullermd> So, speaking of bug 964171, which we totally weren't   ;p
<ubot5> Launchpad bug 964171 in Bazaar "date:today in log broken in 2.5+" [Undecided,Incomplete] https://launchpad.net/bugs/964171
<fullermd> Last you left it in Incomplete, where it's in danger of getting auto-reaped at some point.  Is there something needed from me on it?
<vila> ha damn, this one has already overflowed my list twice :-/
<vila> so, I think I wanted feedback about whether this was specific to some branches and reproducible with all bzr versions
<fullermd> It failed for me with 2.5 and .dev, but worked with 2.4 (didn't try earlier, but...)
<fullermd> Pretty sure I tossed together a scratch branch and it acted the same.
<vila> I think jelmer could shed some light there too which is why I subscribed it
<vila> s/it/him/ damn it
 * jelmer if vila is suggesting he is genderless :)
<fullermd> % bzr revision-info -rtoday
<fullermd> bzr: ERROR: Requested revision: 'today' does not exist in branch: file:///tmp/bzr/t/A/
<vila> pfew, fixed the tyop faster ;)
<fullermd> % \bzr revision-info -rtoday
<fullermd> bzr: ERROR: Requested revision: 'today' does not exist in branch: file:///tmp/bzr/t/A/
<fullermd> % ~/src/bzr/back-branches/2.4/bzr revision-info -rtoday
<fullermd> 1 fullermd@over-yonder.net-20120411080736-0x9pjobhkv3gryaq
<fullermd> (.dev, 2.5, and (obviously) 2.4, respectively)
<jelmer> fullermd: it's definitely a bug
<fullermd> 'k.  Can we move it to Confirmed or something?  I don't so much care about "ZOMG we need to fix this today", but if it's in Inc and gets killed off by LP's autoreaper, it'll make things so much harder for me to act smug and point at "see, I totally already reported that" down the road.
<fullermd> (and after all, that's the important part of the process, right?)
<jelmer> fullermd: :)
<jelmer> fullermd: done
<fullermd> Oh, hm, it looks like "I.e. when -rdate:<whatever> is the branch tip" is a point too.
<fullermd> If I stuff another rev on the branch (so both 1 and 2 are today), .dev and 2.5 properly give back rev 1.
<fullermd> I guess this is bzr's way of subtly hinting that I should be getting more work done before asking it questions.
<fullermd> Hm, didn't we fix all the compile warnings at some point?  I get a handful of the pointer->integer cast warnings.
<jelmer> fullermd: I think I've always seen them
<fullermd> Hm.  I don't get them with clang.  Little odd.
<fullermd> Shows up another oddity though; `gmake CC=clang` changes the compiler used in the compile steps, but it still uses 'cc' for the linking.  Not quite exactly a bug maybe, but unexpected.
<fullermd> Anyway.  Better stop looking for excuses to not be working...
<maxb> Anyone fancy looking at an UDD MP for me? https://code.launchpad.net/~maxb/udd/environment-setup/+merge/101307
<mgz> maxb: seems pretty reasonable to me, might just want vila to look it over too
<vila> maxb: the scripts have been rewritten by jml/james_w because they want to reuse udd in a different context so they wanted some dependencies *out* of the scripts (adding pkgimport.conf starts addressing that), putting everything *in* again goes in the opposite direction, you should see with them to reach a consensus
<vila> maxb: have a look at udd/iconfig.py too which already defines pi.install_dir and pi.base_dir based on _root_dir that you're duplicating with udd_scripts_root
 * vila bbl
<LarstiQ> jelmer: hah. Now of course I run into subvertpy missing probe_transport() is called..
<LarstiQ> _when_ probe_transport() is called
<jelmer> LarstiQ: it seems reasonable enough to require subvertpy for that
<maxb> vila: jml / james_w are welcome to re-use the udd.* modules, but making our bin/ scripts do the right thing when invoked without wrapper shell scripts shouldn't affect them, I would think
<jml> maxb: I haven't looked at this change in particular (kind of caught up in something else atm)....
<jml> maxb: but personally, I think the best thing we can do for this code-base is to split the "watch packages on Launchpad" bit away from the "import packages into branches" bit.
<maxb> Sure, but right now I just want scripts that don't die if I don't have a PYTHONPATH set :-)
<LarstiQ> jelmer: it looked a bit funny trying to pull from a colocated branch, but I can't seem to reproduce it
<james_w> maxb, what we have done on other projects is add a py.sh file by some other means (i.e. puppet) that sets the variables for the specific deployment
<maxb> I don't see any reason why the python scripts can't set up at least their path sanely all by themselves
<maxb> Do you use bin/* in your other use of the udd code at all?
<solsTiCe> hi. What is the most likely cause of such an error ? http://paste.pocoo.org/show/579483
<james_w> maxb, we do
<james_w> maxb, the "watch packages on Launchpad" part
<maxb> Hm, that's a surprise, many of them are highly specific
<james_w> add-import-jobs, mass-import etc.Â¸ but not "import-package"
<james_w> requeue-package is the odd one out
<james_w> as we need it, but not the zap-revids stuff
<maxb> Right. Well, even so, I don't think the changes in my MP would break anything per se, though some of them would be unnecessary
<maxb> oh, the BZR_EMAIL one would be undesirable
<maxb> Much of the environment setup could probably be moved into bin/import-packaet
<jml> mgz: congratulations, you've been given commit access to testtools :)
<mgz> ha, thanks jml
<mgz> alas I don't have any branches that need sneaking through without review to abuse my new position
<jml> mgz: heh.
<jml> mgz: I have a branch that needs review, which you're welcome to. But I might wait for lifeless to give it a shot anyway.
<mgz> hm, subunit tag stuff, would be good for lifeless to look at that indeed
<poolie> hi all
#bzr 2012-04-12
<maxb> Has anyone used 'bzr qlog', right-click, "Tag revision...." recently?
<maxb> It throws a medium has reached concurrent request limit error for me
<maxb> filed bug 979484
<ubot5> Launchpad bug 979484 in qbzr (Ubuntu) "bzr crashed with TooManyConcurrentRequests in __init__(): The medium 'SmartSSHClientMedium(bzr+ssh://<email address hidden>/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request." [Undecided,New] https://launchpad.net/bugs/979484
<mgrandi> anyone here ?
<lifeless> nobody here but us chickens
<mgrandi> darn.
<mgrandi> having bugs with bzr-git and no such revision
<jam> morning all
<poolie> o/ jam
<jam> hi poolie
<mgz> morning
<lifeless> poolie: another todo for your handoff list
<lifeless> poolie: gnu maintainer status
<maxb> 'bzr testament' doesn't have any option to generate a v3 testament
<maxb> I wonder if I should do the simple thing of just adding another switch like --strict, or do the more complex thing of attempting to handle testament types like repository format options
<lifeless> imple is good
<vila> simple != easy
<maxb> Hmm
<maxb> So I'd have to create testament format registry to do this right, I suppose
<maxb> Does that sound worth doing?
<maxb> I guess it does, if we have things as simple as bzrlib.log.author_list_registry
<maxb> I wonder if this makes it a sufficiently large change to disqualify targeting not-trunk
<vila> probably, but so does adding a --strict switch
<mira|AO> heh, nice message âThanks for submitting this bug report. We should be in touch soon. If you want to talk to somebody now, try #bzr on the freenode irc network.â
<mira|AO> I like that.
<mira|AO> so, if anyone needs additional info, prod me.
<mira|AO> (LP#979690)
<mgz> mira|AO: hardy, yum. looks like a bzr-svn issue, not seeing an existing bug at quick look.
<mira|AO> yeah, âyumâ â¹
<mgz> can you attach the output of `bzr tags` on the repo you're trying to push?
<mira|AO> bzr tags in the bzr repo or the svn repo?
<mira|AO> yeah, Iâm awaiting the day I can switch to debian testingâ¦
<mgz> I presume the bzr one, but try both.
<mira|AO> ok
<mira|AO> oh. there are tags. apparently imported from upstream svnâ¦
<mgz> potentially deleting a odd (non-ascii maybe?) tag will do as a work around.
<mira|AO> I never worked with tags thoughâ¦
<mira|AO> doesnât look any tags are non-ASCII
<mgz> whoops, path not tag.
<mira|AO> hm?
<mira|AO> bzr: ERROR: unknown command "path"
<mira|AO> (still, independent of this problem, _if_ someone has got current bzr debs for hardy, or source debs for something else of the lenny era which I could probably build on hardy, tell me ;)
<mgz> I'd missed that the failing assertion was on a path, despite being in tag related code
<mira|AO> ah
<mgz> looking at the context now
<mgz> so, the return of:
<mgz> self.branch.layout.get_tag_path(tag_name, self.branch.project)
<mgz> is not str...
<mira|AO> if you need the two svn repositories, I can point you to that. I _think_ I probably can also put my entire shared-repo up somewhere, but that's huge
<mira|AO> ah. maybe this is because the pushed-to repo doesn't have any tags?
<mira|AO> (not even toplevel dir)
<mira|AO> hm let me see if another bzr push will also crash (despite nothing to push)
<mira|AO> yes it does
<mira|AO> ok, I'll mkdir a tags dir
<mgz> running that push with BZR_PDB=1 set, you should land in the python debugger and be able to do `p path` to answer the question of what it is
<mgz> could well just be None if the dir is missing
<mira|AO> nope, will still crash
<mira|AO> ok
<mira|AO> do I need to install something for that debugger?
<mgz> nope, it's part of python.
<mira|AO> ok
<mira|AO> path is None, yes
<mgz> okay, do `l`, and then print the arguments to the function listed above that assert
<mira|AO> (Pdb) p tag_name
<mira|AO> u'debian_version_4_5_14-2'
<mira|AO> (Pdb) p tag_target
<mira|AO> 'svn-v4:9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:tags/debian_version_4_5_14-2:5614'
<mira|AO> 166         def set_tag(self, tag_name, tag_target):
<mgz> ace.
<mgz> what's the layout object, also on the line above?
<mira|AO> *** NameError: NameError("name 'layout' is not defined",)
<mira|AO> oh sorry
<mira|AO> (Pdb) p self.branch.layout
<mira|AO> WildcardLayout(['branches/*', 'trunk/gforge_base/evolvisforge', 'trunk/gforge_base/evolvisforge-5.1', 'vendor/testlink', 'trunk/testlink', 'trunk/mediawiki'],['tags'])
<mira|AO> und _space ?
<mira|AO> oops
<mgz> okay, that should be enough, now either want jelmer, or I'll go back and look at WildcardLayout.get_tag_path in bzr-svn 1.0 because the current version seems fine
<mira|AO> hm wait a secâ¦
<mgz>         # FIXME
<mgz>         return None
<mgz> okay, that's the problem :)
<mira|AO> just realised tags should be 'tags/*' not 'tags'
<mira|AO> doesn't change anything though
<mira|AO> ah ok :)
<mira|AO> fixed in later versions, then?
<mgz> yes. just checking which now
<mgz> you may be able to manually update just bzr-svn without breaking any of your other packages
<mira|AO> hmmmmmmm
<mira|AO> âmayâ ;)
<mira|AO> (on the other hand, I do want a newer bzr anyway, I occasionally run into minor trouble)
<mgz> okay, it's implemented in bzr-svn 1.1.0
<mira|AO> oh well. I'll try that, and try to push my boss to allow me to switch to debian sooner
<mira|AO> thanks
<mgz> you should be able to just remove the bzr-svn package
<mgz> and install from source to your user plugins dir?
 * mira|AO shudders
<mgz> I think https://launchpad.net/bzr-svn/1.1/1.1.2 should be bzr 2.1.0 compatible, and it's an easy check
<mgz> unpacking into to ~/.bazaar/plugins/bzr-svn will tell you
<mira|AO> heh. actually I can't uninstall it, as our dependency metapackage depends on itâ¦
<mira|AO> anyway, thanks for all the help so far
<mgz> your user plugins dir should be checked first so should override even without uninstalling
<mira|AO> ah ok
<mira|AO> Iâll try that
<mgz> there may also be another workaround, it's not clear to me why you only started hitting this today
<mira|AO> argh. the download link doesn't workâ¦
<mira|AO> I did several bzr-svn related things in the meantime
<mgz> hm, just did for me
<mira|AO> so my subversion.conf was changed
<mira|AO> new repos, etc.
<mgz> https://launchpad.net/bzr-svn/1.1/1.1.2/+download/bzr-svn-1.1.2.tar.gz
<mira|AO> oh this is great
<mira|AO> it works with lynx
<mira|AO> not with bloatzillaâ¦
<mgz> heh.
 * mgz is using lynx
<mira|AO> Unable to load plugin 'svn'. It requested API version (2, 4, 0) of module <module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
<mira|AO> mh, I don't normally use it with launchpad
<mira|AO> maybe I should ;)
<mgz> ah, blast, bzr-svn 1.1 isn't compatible with bzr 2.1 it seems.
<mira|AO> mh.
<mgz> I'll write up the details on the bug and see if jelmer has any better ideas.
<jelmer> mgz: is this for bug 979690 ?
<ubot5> Launchpad bug 979690 in Bazaar Subversion Plugin "AssertionError in set_tag on push to svn" [Medium,Incomplete] https://launchpad.net/bugs/979690
<mira|AO> ok
<mira|AO> I mean, if it's fixed in a later version, there's nothing I require from you ;)
<mira|AO> besides, the push works, it just crashes afterwards
<mgz> jelmer: yup, short version WildcardLayout.get_tag_path returns None tripping that assertion, fixed in bzr-svn 1.1.0
<mgz> any work arounds you can think of, given updating bzr on hardy is a pain? what gets WildcardLayout used rather than one of the others?
<mira|AO> mgz, maybe the fact that the pushed-to SVN repo is a fsck'd up PITA that needs WildcardLayout?
<jelmer> unsetting the tags = value altogether, if that's an option?
<mira|AO> that's an option, yes
<mira|AO> ah. that's what I had before, actually
<mira|AO> so the "cause" are the changes to subversion.conf
<mira|AO> now all I get is:
<mira|AO> bzr: ERROR: Tags not supported by SvnBranch('svn+ssh://mirabilos@svn.evolvis.org/svnroot/evolvis/trunk/gforge_base/evolvisforge-5.1'); you may be able to use bzr upgrade.
<mira|AO> and no crash
<mira|AO> ok, that'll suffice for now
<mira|AO> and I'll try to get a permit to drop hardy earlierâ¦
<cody-somerville> Can I use 'remerge' to pull in new revisions from merged branch committed since I began the merge?
<wgz> nope, it's only for redoing the current merge
<wgz> merge --force can pull in the newer changes, but is a little riskier for your current state
<wgz> may have done what you want previously with commit/merge/uncommit but don't recall if I also needed some extra cleanup
<wgz> so if you've got lots of half resolved conflicts, you probably just want to pick between resolving fully then doing the new ones, or starting again with the newer rev
<mgrandi_> so , i gm getting a bzr: ERROR: bzrlib.errors.MalformedTransform: Tree transform is malformed [('overwrite', 'new-65', u'test')] error when i try to revert one of my branches
<damd> how do i remove any new files (non-added, non-commited) in a branch directory?
<mgrandi_> bzr rm --keep or something
<mgrandi_> oh, they arnt added
<mgrandi_> you should be able to get a list of unknowns
<damd> this is on windows by the way, so i really don't have any of those fancy xargs applications
<wgz> see `bzr help clean-tree`
<damd> cheers
<thomi> Hi, I'm trying to figure out pipelines. I'm having an issue where when I do 'bzr lp-propose' while in the second pipe of two, it sets the source branch to be the first pipe in the series, rather than the current one.
<thomi> Any ideas what I'm doing wrong?
<thomi> hmm, it seems like my locations.conf breaks things when I use pipelines.
#bzr 2012-04-13
<bobweaver> Hello there I am using bzr explorer and I was going to push code and I entered the wrong password (caps was on)  but I can not fix this error . I am sure that it is right under my nose but I can not seem to fix this. I tried to sign in from command line to launchpad and all is well there
<poolie> hi there
<bobweaver> Hi poolie
<poolie> you can't fix the problem meaning that it's not giving you a second chance to enter the password?
<poolie> that's a bit icky
<poolie> you should be able to find and edit authentication.conf
<poolie> i think it's stored there
<bobweaver> yup ^^ no 2nd chance
<bobweaver> ohh cool thanks
<poolie> you could file a bug at pad.lv/fb/bzr-explorer
<bobweaver> cool will do
<bobweaver> thanks poolie  !
<poolie> np
<bobweaver> gezz I still can get it worked out under that file there is no passwd this is the error that I am getting bzr: ERROR: Could not acquire lock "(remote lock)":       I have tried to also break the lock but that also did not do anything
<poolie> bobweaver, sometimes that means you don't have permission on the remote machine?
<bobweaver> my ssh key is there
<bobweaver> I am going to try and reboot
<bobweaver> so a no go let me enter password and I def typed correct this time. must be lp ?
<bobweaver> I can log into LP and all my old code is there and asys that it is owned by me
<kbulgrien> so if I have a shared repo somewhere on a machine that isn't up all the time, does it make any sense to rsync it over to another machine, or is that messed up thinking?
<kbulgrien> IE. what might be wierd about having multiple shared repos around.
<kbulgrien> I imagine I should have set up the shared repo on a server... and I guess I can dismantle the other one... but then might there be some benefit to not dismantling the original.
<fullermd> kbulgrien: I can't think of anything particular to shared repos that makes it any different from doing the same thing with any other set of branches.
<fullermd> kbulgrien: It just sounds like a management question of making sure people are pushing things into the right place, not somewhere that'll get overwritten.
<kbulgrien> can you sync the shared repos with bzr, or is just rsync the way to do that?
<fullermd> There's nothing in bzr at the moment that syncs repos.  There's some stuff like multi-pull in bzrtools that gives you some automation of iterating over the branches, but it's all branch-at-a-time.
<fullermd> rsync is simpler.  Could potentially lose you stuff if the right (wrong) things blow up in the middle.
<kbulgrien> I suppose --delete is  out of the question.  files never go away in the repo?
<kbulgrien> only add?
<kbulgrien> Along the lines that you could do two rsync one in each direction to make them the same.
<kbulgrien> if you were to have had things put separately in each.
<fullermd> Files go away with fair regularity.
<kbulgrien> ok
<fullermd> Multiple old files get repacked into one new file.  With bad timing, you could get the old files --delete'd before the new one gets synced, and then the squirrel takes the last bite through the network cable...
<kbulgrien> :-)
<lifeless> nom nom nom
<fullermd> To be sure, it adds that extra savor to the squirrel stew that evening, but you get yelled at a lot before then.
<kbulgrien> its always faster doing it the second time eh? ;-)
<kbulgrien> maybe --delay-updates would foil the squirrel
<kbulgrien> Probably mostly it would make sense for one copy just to be the big giant backup that nobody ever uses except the mirror or the owner in a recovery situation.
<fullermd> Yeah.  You definitely wouldn't want to try using rsync as a "keep both in sync while people are writing to both" thing.
<mgrandi> seems like just a simple script to run 'bzr update' occasionally on whatever branch
<fullermd> You _could_ use bzr itself for that (I mean, that's just distributed development, right?) but I wouldn't try it automated.  So it sounds like just extra complexity in that case too.
<mgrandi> seems like the best way
<mgrandi> cause i assume it knows how to deal with whats happening if its being updated at the same point you are trying to download it
<lifeless> so the problem is
<mgrandi> and i think that the bzr docs say thats the preferred method
<lifeless> rsync isn't file-system order
<lifeless> bzr's primitives ensure ~0 data loss window if they are replayed in filesystem order
<fullermd> Obviously, the solution is "zfs send"  8-}
<lifeless> an external actor (like rsync) doing any of breadth-first, depth-first, etc traversals, with immediate or deferred deletes will create otherwise impossible situations in the receiving copy, if they happen concurrently with bzr acting on the repository
<lifeless> this is the same reason that rsyncing a postgresql DB has no guarantees in the absence of cooperation-with-postgresql
<lifeless> and we haven't written a cooperate-with-rsync/cp/etc module for bzr yet
<lifeless> (FWIW git and hg have the same issue, its not unique to bzr)
<mgrandi> yeah.
 * kbulgrien looks for a repo dump
<mgrandi> thats wht the docs just suggest
<mgrandi> using bzr update/pull
<mgrandi> cause then that way it handles things correctly
<lifeless> one of the things that makes doing a cooperative thing for bzr is that we assume that fsync doesn't work ;) [for good reason]
<kbulgrien> ok multi-pull seems agnostic to what branches exist in a particular folder, so it could just pull everything it finds without someone having to say what to pull.
<mgrandi> i believe it pulls all branches in a shared repo.
<fullermd> No, it doesn't care about repos one way or another.  It's roughly equivalent to `find . -type bzr-branch -print | xargs -n1 bzr pull`
<kbulgrien> hmm and there is automirror
<fullermd> So, it'll pull a set of independent branches, the branches in one repo, the branches in a couple repos, some combination...  whatever it finds under the dir you point it at.
<kbulgrien> its kind of a multipush I guess
<kbulgrien> ok, cool, learned something... I found the backup/restore stuff in the admin guide.
<kbulgrien> I think I read that if, I am the only one using stuff, rsync is faster and ok.  Its when you can't guarantee the copied stuff is static that that becomes an issue.
<kbulgrien> That's what I gathered from the above comments too, so I think I get it.
<lifeless> rsync *can* be faster; it won't right after compactions
<kbulgrien> I would probably be better off sticking to bzr stuff though for sake of making myself more well-rounded and familiar with the tool set.
<kbulgrien> not to mention forgetting the nitpick and messing myself over once I was so used to using the unsafe tool.
<kbulgrien> I'll decline to admit how long I rsync backup'd postgres in the middle of the night ;-) before I wrote a dump script.
<kbulgrien> all the time knowing it wasn't really safe.
<fullermd> I do it every night.
<fullermd> Granted, I mostly care about and rely on the gzip'd dump file also in the dir tree being synced, but..
<kbulgrien> I actually have mine pulling over dumps and the receiving system drops and rebuilds everything based on what it just pulled over.
<kbulgrien> Anyway... trying to get geared up to do bzr stuff in a way so I have a hot backup.
<grettke> Hi folks. I would like to check out files both on windows and linux and have bzr ignore differing line endings. My rules has a name * eol = native but that isn't helping. What am I doin wrong here?
<poolie> hm, that should do it
<mgrandi> does bzr try to convert line endings for you?
<mgrandi> that seems weird o.o
<poolie> what do you mean more specifically by 'not helping'?
<grettke> poolie: when I run a bzr st, all files are reported as changed, but when I do a qdiff and "Ignore whitespace differences" there are no changes
<grettke> mgrandi: I don't know but if it were then that would be a whitespace change in every file wouldn't it...
<mgrandi> i dunno, i thought bzr would just bersion the file and not try and modify line endings
<fullermd> If you hit 'commit', does it actually try to commit those changes, or does it say there's nothing to do?
<grettke> I didn't try committing it. Odd thing is that when I do a revert... it doesn't revert it still reports modifications.
<spiv> mgrandi: only if you configure it to do so
<mgrandi> ah
<mgz> morning
<mgrandi> hey
<mgrandi> if you are up that means i'm up way too late. hmm
<fullermd> I think it just means he's up way too early.
<fullermd> I mean, the sun probably isn't even down yet where he is.
<mgrandi> so, i did a revert the other day and i cant revert the tree cause its says TreeTransform is malformed
<mgrandi> wat do
<mgrandi> or rather should i just report a bug / upload the branch
<mgz> so, the problem with TreeTransform errors, is without a clear way to reproduce there's not much to go on
<mgz> ideally you should work out what change is problematic, and reproduce it in a fresh branch, giving steps in bug report
<mgz> it's generally easy enough to work around not being able to revert something, just branch to a new location from the rev that you're trying to revert from
<mgz> a bug report and packed up branch wouldn't hurt though, if you confirm that someone downloading and trying the steps you give will get the same error
<mgrandi> yeah, i zipped up the branch
<mgrandi> and just report a bug then?
<mgz> sure, but trying to reproduce from scratch woul still be very useful.
<mgrandi> well i just tried it (with the branch that i zipped) and if you do bzr revert on it then it still crashes
<mgrandi> how do you mean do it from scratch, as in make a new branch and try do the steps to break it?
<mgz> right, and you can search the existing bugs to see if one of those already covers your case
<mgrandi> k
<mgz> eg bug 632704 and bug 660125
<ubot5> Launchpad bug 632704 in Bazaar "Can't merge a directory deletion in a wt with a pending subdirectory deletion" [High,Confirmed] https://launchpad.net/bugs/632704
<ubot5> Launchpad bug 660125 in Bazaar "shelve crashes with "Tree transform is malformed" when renamed file already exists" [Medium,Confirmed] https://launchpad.net/bugs/660125
<mgz> working out what the particular case that's making it fail for you is the most relevent thing
<mgrandi> i know i was doing some renaming stuff
<mgrandi> but its late and i'll do it this weekend, and if jelmer is here i'm also having problems with bzr-git >.>
<fullermd> What's 'stat' look like?
<mgrandi> bzr status on the branch?
<fullermd> Yah.  Well, on the WT, but 6.5 of one...
<mgrandi> its ugly D: http://bpaste.net/show/26999/
<mgrandi> not sure what the * means in 'modified'
<fullermd> +/-x
<fullermd> Hm.  How about this part.
<mgrandi> ah, yeah, i never modified the +x by myself
<fullermd> removed: php_frontend/src/codeigniter/system/libraries/Twig/lib/
<fullermd> unknown:   php_frontend/src/codeigniter/system/libraries/Twig/lib/
<fullermd> What if you rm (or move aside) that unknown dir?
<mgz> that looks like a winner.
<mgrandi> yeah
<mgrandi> that fixed it.
<mgrandi> so now the question is how it got into that weird state o.o
<fullermd> A little fiddling with trivial similar setups doesn't show up any problems, so it's liable to be a little twisted.
<mgrandi> i have the log so ill be able to recreate exactly what i did
<jelmer> mgrandi: hey
<mgrandi> hey
<mgrandi> so, i have a bzr branch that i was using to do stuff with github
<mgrandi> and one branch is just a straight up copy of someones github repo, i haven't done anything to it
<mgrandi> i tried updating it and bzr-git says the branches have diverged, and to do 'bzr missing' to see why, but then bzr missing says 'git smart protocol doesn't support that'
<jelmer> mgrandi: yeah, the git protocol doesn't support remote graph inspecition
<mgrandi> then i just tried branching it again in a brand new branch, and i get: bzr: ERROR: Could not determine revno for {git-v1:78d796d1f018bb66d986e73bc4641b6c0b372a55} because its ancestry shows a ghost at {git-v1:78d796d1f018bb66d986e73bc4641b6c0b372a55}
<jelmer> what version of bzr-git?
<mgrandi> how do you get versions of the plugins?
<jelmer> mgrandi: 'bzr plugins'
<mgrandi> git 0.6.8dev
<jelmer> hmmok, that's fairly recent
<jelmer> I'm not sure what's going on there, without looking into it in more detail
<mgrandi> it seems that its something to do with the repo, since making a folder outside of the repo i have works fine
<jelmer> mgrandi: aha
<jelmer> is the repo old, does it perhaps have revisions that might have been fetched with old (broken?) versions of bzr-git?
<mgrandi> the repo isnt that old, and i think ive been using this version of bzr git for a while
<mgrandi> the last commit i have in that branch is  Fri 2012-02-24 21:16:15 -0200
<mgrandi> or that came from the guy whose github i'm branching
<fullermd> Well, I give up.  I've tried a handful of likely-looking slices of those changes, and I don't get any blowups with 2.5 or .dev.
<mgrandi> fullermd: i finally scrolled through my log so i have the exact commands i did
<mgrandi> so i'll try and recreate it
<fullermd> What version are you running?
<mgrandi> 2.5.0
<fullermd> Oh well.
<mgz> the rename of files from a subdir of that clashing directory looks interesting for the revert
<jelmer> mgrandi: so, I'm out of ideas too without looking into the issue more closely
<mgrandi> do you want the entire shared repo / branch?
<fullermd> http://paste.ubuntu.com/927613/   is the script I worked up for testing.
<fullermd> But it works as expected for me, so it's something more than just moving files out of the subdir but leaving it sitting there.
<fullermd> And more than having other stuff beside it also being moved around.
<mgz> you're a twinkling object in the night sky, fullermd
<mgrandi> im uploading the repo/branch/ and bzr.log output
<fullermd> Yeah, I blow a lot of hot gas around sometimes.
<mgrandi> its ugly cause im new to this framework and i couldn't figure out where to put this one library so thats why i have so many 'bzr move' and whatnot, but here it is:  www.kramidnarg.com/stuff/tree%20transform%20bug.zip
<fullermd> Does that include the branch in the state where the revert blows up?
<mgrandi> yeah
<fullermd> Works for me.
<mgrandi> in 'tmprepo.zip'
<mgrandi> really? doing bzr revert inside tmprepo/enquest_work works for you?
<fullermd> Yep.  With .dev and 2.5.0.
<mgrandi> soooo why does mine not work then
<fullermd> Now, here's one difference: You're apparently on OS X.
<mgrandi> yeah
<mgz> maybe a platform dif... what fullermd said
<fullermd> Maybe the fs is doing something with the .DS_STORE's?
<mgrandi> bzr 2.5.0 on python 2.6.7 (Darwin-11.3.0-x86_64-i386-64bit)
<mgrandi> does bzr even use .ds_store? how would that effect it
<mgrandi> and i think i have those ignored anyway
<fullermd> OS X does do some special stuff with unicode normalization, but it looks like all the filenames are 7-bit ASCII, so it's probably not that.
<fullermd> No, but maybe it hits some conflict with the forks when moving stuff around, since the OS treats them special?
<mgz> my first guess was directory rename differences, but that was assuming windows rather than osx
 * fullermd is guessing pretty randomly...
<mgrandi> mac is not case sensitive...which is weird
<mgrandi> maybe that?
<mgz> allowing renaming over an existing (empty) dir is a posix thing, but osx should allow it too
<fullermd> Mmm.  I thought it was.
<mgz> case things is also a possibility.
<mgrandi>  /users/markgrandi is the same as /Users/markgrandi, i dont know if python forces a case sensitivity
<mgrandi> HFS+ supprts case sensitivity but mac os x doesn't do it for some reason
<fullermd> Oh, right, it's case-insensitive-but-case-preserving.
<fullermd> That's the most likely place, yah.  Nothing jumps out at me immediately though.
<mgrandi> are you on windows or linux fullermd
<fullermd> Neither, naturally.  I have [daemonic] standards  ;p
<mgrandi> heh
<mgrandi> i'll try on my windows/linux machines later
<mgrandi> when its not 3 am
<fullermd> Give http://paste.ubuntu.com/927663/ a try locally.
<fullermd> (prob. have to fix the bzr path or something anyway)
<fullermd> 's a few tweaks past the one I pasted earlier.  Still works for me, but since yours does too, maybe it'll blow up for you.
<fullermd> Get you a step closer to an isolated testcase anyway.
<mgrandi> dear ubuntu: why do i have to log in to download a paste. signed, me
<fullermd> Anyway.  's way over my time quota; I've gotta get back to pretending to work in preparation for tomorrow's (later today's) pointless conference call.
<mgrandi> ok
<mgrandi> i'll let you know what happens
<mgrandi> going to bed, i'll be on later to discuss these problems more, ttyl~
<ccxCZ> how can I disable the spinner/speed on actions on ssh repositories?
<ccxCZ> also can I make bzr use /bin/ssh instead of paramiko, so it reuses established master session?
<ccxCZ> got it, BZR_SSH=openssh BZR_PROGRESS_BAR=none
#bzr 2012-04-14
<alexeiser> Question about the smart server jail, and how to "correctly" do auto push changes from one branch to a diverging parent
<LarstiQ> ccxCZ: hmm, shouldn't it pick up on openssh if BZR_SSH is unset?
<RobOakes> Morning everyone. is there anyone who might be able to advise me on the best way to do a complicated merge?
<RobOakes> I work on the LyX project and keep a local branch in Launchpad, using Bzr.
<RobOakes> Just recently, the LyX main development team moved to git and abandoned their SVN repository.
<RobOakes> Even though the git repository has a full SVN history, I am unable to merge it into my bar repo (based on the same SVN). It says that there is no common history.
<RobOakes> Because they are no longer pushing master updates to SVN, I don't have a way to continue work on my branch. Any ideas on how I can begin to pull changes from the git repo into my bar branch?
<RobOakes> I'm using bar 2.5
<aj_> why the first time fetching of a branch is too slow in my system??
<aj_> speed hardly reaches 15 KBps
<aj_> anybody??
#bzr 2012-04-15
<fred___> can i checkout something from google code / svn using bzr?
<fred___> in other words, can you use bzr as a client for git and svn repos?
<treaves> Wow.
<LeoNerd> bzr rebase -r123   <== it's trying to interpret -r as a revision in my local branch, not the rebase source
<jelmer> LeoNerd: yes, that's the intended behaviour
<LeoNerd> Righty... hrm.. so how do I specify the revision of the rebase source?
<LeoNerd> I want to pick the most recent release tag, not the absolute latest development head
<jelmer> LeoNerd: it sounds like you want to cherrypick, rather than rebase
<LeoNerd> I definitely want a rebase
<jelmer> LeoNerd: the rebase source *is* the current branch
<jelmer> LeoNerd: you specify the branch on top of which you want to rebase
<LeoNerd> Yah.. so...    bzr rebase ../thing.TRUNK  normally
<LeoNerd> I want to pick -r123 of the .TRUNK, even though currently it's at -r125
<LeoNerd> I think --onto 123  is what I want
<LeoNerd> Aaand that got it
<LeoNerd> Yeah, that did it :)
<youlysses-lt> Any resources around that lists "why dvcs are better than non"? I'm finally am picking one ... and right now I'm not informed enough to have a preference. The only that sticks out to me in bzr atm, is it's part of the GNU project.
<LeoNerd> Because I can commit code while I'm offline on the London Underground train to work every morning
<LeoNerd> Tobehonest, is one of my main reasons
<youlysses-lt> So it's great for "on-the-go" types?
#bzr 2013-04-08
<thejoecarroll> is there any way to search all the past commits/diffs of a repo for a particlular string?
<jelmer> thejoecarroll: see the bzr-search plugin
<thejoecarroll> nothing like "git grep" built in?
<jelmer> thejoecarroll: there is bzr-grep as well
<thejoecarroll> but as a plugin
<jelmer> thejoecarroll: later versions of bzr include the "bzr grep" command
<jelmer> the 2.6 betas do
<thejoecarroll> i have 2.1.4 on this particular server, haven't installed any plugins. just using it in conjunction with etckeeper
<jelmer> thejoecarroll: in that case, you can install the bzr-grep plugin for the "bzr grep" command
<jelmer> https://launchpad.net/bzr-grep
<jelmer> there are packages around as well
<thejoecarroll> thanks. is there a quick, easy way to add the plugin at the CLI?
<jelmer> mkdir -p ~/.bazaar/plugins; bzr branch lp:bzr-grep ~/.bazaar/plugins/grep
<thejoecarroll> cheers!
<felipec> I'm trying to check if a tag is in a branch
<felipec> but revision_id_to_revno is too slow
<felipec> ah, lock_ead()
<felipec> read
<jelmer> hey mgz
<jelmer> mgz: Yep, settling well - moved in my new place on Monday. And the weather has actually improved!
<mgz> just when you thought snow was what the uk was about...
#bzr 2013-04-09
<SamB> jelmer: so, #emacs was wondering if you could break it to rms that bzr is dead and it is time to move on ...
<SamB> evidently, "I think it's time to move on" isn't quite explicit enough
<JordiGH> jelmer: Can you send an email to rms to tell him that bzr is dead and GNU should no longer use it?
<lifeless> JordiGH: why should jelmer do that? He is no more authoritative than e.g. I am, or poolie... we don't work for Canonical anymore
<JordiGH> lifeless: Alright, can you do it?
<SamB> does canonical even pay *anyone* to work on bzr anymore?
<lifeless> SamB: I don't know, not working there. Which is my point.
<lifeless> If you want a statement from someone with actual knowledge, you need to ask the sponsor.
<JordiGH> lifeless: rms won't let us go until there's a clear message that bzr is completely unmaintained and unviable.
<JordiGH> Not a blog post, not a wishy-washy "I think..." or "perhaps if we did this, bzr could revive", but a resounding NO on bzr.
<lifeless> JordiGH: So unmaintained means 'set of active maintainers is empty', and while I can say that I am not focused on maintaining bzr anymore (though I still have commit rights AFAIK), I can't say 'the set of active maintainers is empty' because - I /don't know/.
<lifeless> JordiGH: mgz or vila or jam may know.
<JordiGH> lifeless: Do you have their email?
<lifeless> JordiGH: sure, its all over the place ;)
<JordiGH> Which place?
<lifeless> bzr devel mailing list, package metadata for bzr packages, commit logs...
<Peng> This is a sad conversation.
<SamB> hmm, jam apparantly was the most recent to commit
<lifeless> it is a sad conversation, its also an odd one, because AFAIK Canonical are still maintaining bzr.
<lifeless> -> not dead.
<JordiGH> Ugh, then how do we kill it de jure? It's already dead de facto.
<JordiGH> Do we need to tell sabdfl to explicitly kill it?
<SamB> or did he just approve it or something
<lifeless> SamB: jam approved a proposal from a Dylan
<lifeless>  McCall
<SamB> yes, with -n0 that becomes clearer
<lifeless> JordiGH: why do you want bzr killed ?
<SamB> it isn't working very well for Emacs, but rms is extremely stubborn
<JordiGH> lifeless: Because rms won't Emacs stop using bzr unless bzr is officially pronounced dead, and there's a huge majority of users that are mighty pissed off about bzr being used for Emacs. It's a horrible and divisive thorn in the Emacs community. It needs to be excised.
<lifeless> Xemacs V2 ?
<elmo> *blink* why do users care about bzr being used for Emacs?
<elmo> do you mean developers?
<SamB> this is Emacs, how do you tell which is which?
<elmo> SamB: pretty easily, IMO?  I'm an emacs user, for example.  I've never known or cared what VCS emacs is developed in
<SamB> I have papers, but they wanted me to (essentially) rebase -i my code and I obviously cannot do that with bzr ...
<elmo> I'm not suggesting emacs should continue to use bzr; I'm simply suggesting that trying to get the entire bzr project officially killed to stop emacs using it is something of an overreaction/overreach
<SamB> yeah, probably
<JordiGH> elmo: It's already dead, just not officially.
<elmo> JordiGH: no, like lifeless said, dead would be that it has no active maintainers
<JordiGH> elmo: Then why won't the active maintainers not fix the bugs that Emacs has reported years ago?
<elmo> I don't know that it has or hasn't and I'm pretty sure you don't know that
<JordiGH> Nor even acknowledge them?
<SamB> JordiGH: would rms be satisfied by a statement that it was 99% dead?
<JordiGH> SamB: No, he's already gotten that statement
<lifeless> JordiGH: which bugs haven't been acknowledged?
<SamB> JordiGH: which bub numbers do you mean?
<SamB> *bug
<JordiGH> The one that affects the ELPA repo.
<elmo> JordiGH: I've reported bugs in many many free software projects that never get acknowledgement or fixed (I'm pretty sure some of my Debian bugs have been opened > 10 years at this point); it doesn't mean these projects are dead
<JordiGH> elmo: Can we declare it dead for Emacs, then?
<lifeless> JordiGH: thats up to Emacs surely...
<JordiGH> lifeless: No, Emacs needs a statement from bzr.
 * SamB wonders why rms even gets a vote
<JordiGH> lifeless: rms will not relent otherwise.
<lifeless> You want the bzr community to say they don't want Emacs to use bzr?
<JordiGH> lifeless: YES
<JordiGH> PLEEASE
<JordiGH> PLEEEEEEASE.
 * SamB doesn't see how a project with as much wrong with it as bzr has can be considered "alive" when the time between commits to trunk is measured in months ...
<jelmer> SamB, JordiGH: I don't think I'm the right person for that
<SamB> oh, JordiGH disconnected; I guess expecting him to come here because I pasted that in #emacs doesn't make sense ...
<SamB> jelmer: who would be better to ask?
<lifeless> You could ask on the list, but I think its a crazy thing to ask. What community will say 'go away' to a user that they wany to support
<jelmer> SamB: somebody currently involved in Bazaar
<SamB> jelmer: I only have to go 3 commits back to find one from you ...
<SamB> that seems current enough to *me*
<jelmer> SamB: that's a commit from last year I think?
<SamB> yeah
<jelmer> SamB: Anyway, IIRC there is an official GNU maintainer for Bazaar. In the past that was mbp, today it's probably jam?
<jelmer> but I also agree with lifeless that it's a strange question to ask
<jelmer> then again, I also thought the process with which emacs chose bzr as its vcs at the time was odd
<poolie> o/
#bzr 2013-04-10
<lifeless> poolie: o/
<poolie> hi there
 * fullermd can't believe there was a whole discussion in one nobody played the "It's not dead, it's resting" card.
<SamB> fullermd: someone was going to do that the other way on emacs-devel, or joking about it on #emacs anyway ...
<mwhudson> lovely plumage
<vila> It's not dead, it's resting
<vila> Besides, a GPL'ed software dieing is an oxymoron
 * SamB is sad because he can't actually remember any lines from that thing ...
<vila> SamB: It's partly up to you ;)
 * vila reboots and bbiab
<fayaz> hi, how can i generate a sensible diff using bzrlib?
<jelmer> fayaz: see cmd_diff in bzrlib/builtins.py
<jelmer> that should give you an idea of how the diff command does it
<jelmer> hi mgz
<mgz> hey hey!
<jelmer> mgz: did you guys see the whole emacs discussion?
<mgz> I haven't
<kate`> i saw it, and i'm confused because i haven't a clue about either the history or the future for bzr
<barry> mgz, vila, or anyone else.  is there a quick fix possible for: http://package-import.ubuntu.com/status/apt.html#2012-10-12 11:49:18.303380
 * mgz has a look
<vila> barry: sorry, I could never find the time to understand what caused the missing chk node(s) for id_to_entry maps bugs. I vaguely remember jelmer mentioning something but I'm not sure it involved 'bzr reconcile' or some lp surgery
<vila> barry: also, maxb may know too
<jelmer> there are various causes for it
<jelmer> one is caused by older versions of bzr-svn; since this is a package import, I don't think that's relevant
<jelmer> the underlying problem is that there are two disagreeing versions of the inventory for a specific revision around
<mgz> hm, I know the error from bzr-svn
<mgz> hadn't seen it in code imports
<barry> hi guys, thanks.  is there something locally i can do to the branch to rejigger it into happiness?
<mgz> barry: not that I know of. seems bug 1138637 is the same thing. may be worth poking xnox to try a full requeue on his local setup and see if that generates a working import or not, but I suspect it's the branch history that's unhappy
<ubot5> bug 1138637 in Ubuntu Distributed Development "software-center import failing" [Undecided,New] https://launchpad.net/bugs/1138637
<barry> mgz: i think xnox is afk today, but thanks i'll poke him tomorrow.  thanks for taking a look
<jelmer> barry: one of the workarounds involves creating an empty repository and pulling branches into that in the right order - so you get a consistent version of the inventories
<barry> jelmer: i think i understand.  not sure i'll do it, but i see what you're saying
<maxb> Hello. I'm not an expert on the id_to_entry_maps thing, but I am around if I can help with other importerish stuff
<maxb> Is there any way to research which revision's inventory is malformed somewhere?
<xnox> barry: poke me about what? =)
<barry> xnox: see ^^ mgz's comment
<xnox> barry: right. I can do that ones my server is setup ones again.
<barry> xnox: cool, thanks
<janos> when you register a project on LP, does it create a dedicated shared repository for the project?
<jelmer> janos: no, they're all independent branches
<jelmer> (though they're stacked, so you still get efficiency for having multiple related branches on launchpad)
<janos> cool, thanks jelmer
<janos> btw do you know the plans for the 2.6 stable release? (expected date?)
<jelmer> well, I'm not active in the project anymore. I just hang out here to socialise :-)
<jelmer> janos: ask jam, mgz or vila
<janos> haha, thanks
#bzr 2013-04-11
<sbarcteam> hi.
<sbarcteam> I am on linux, using bzr 2.3->2.6 and have "beyond compare" diff tool.
<sbarcteam> when I'm using bcompare for bzr diff of a single file, everything is OK.
<sbarcteam> but, when I'm doing this for multitude of files, bzr is spawning each FILE in its own window.
<sbarcteam> This is even more annoying, b/c it does so sequentially: first file, then I need to close the next one, etc.
<sbarcteam> What I'd want to have is something I have with mercurial: diffing creates 2 tmp dirs, and spawns beyondcompare SMARTLY to compare folders.
<sbarcteam> This means I get to see a bigger picture before diving into the diffs of individual files.
<sbarcteam> Is there a hack to make bzr do this ?
<sbarcteam> (I'm reading ext-merge page to see whether it can do this now... seems it's MERGE oriented)
<fullermd> Could maybe script something up around export.
<sbarcteam> It is what I'm hoping to FIND, not script :)
<fullermd> I'm not aware of anything to be found like that (though I've never looked for any such thing, so that's not exactly definitive)
<sbarcteam> I am ... a bit surprised nobody is bothered by this.
<fullermd> Well, I'm pretty sure I could count on one hand the number of times I've seen beyondcompare mentioned   ;)
<fullermd> And probably have enough left over to play a mean game of Hungry Hungry Hippos.
<sbarcteam> fullermd: not aware of hungry hungry hippos, but I'm still googling...
<fullermd> It's not particularly relevant to anything version-controlish   :p
<Merwin> Having two branches with a lot of diffs, I would like to generate a patch with only some of them. Like running a qdiff, and being and being able to select changes I want and click "generate patch" :P
<Merwin> How can I do this ? I was thinking about some tricks like merging my second branch in the first on, and then revert all the things I don't want. But this sounds a little tricky..
<bob2> maybe you want filterdiff
<Merwin> bob2: How does that work ?
<Merwin> vila: An idea about how I can do this with Bazaar N
<vila> Merwin: well, depending on your needs, I can think of 2 ways: a manual one editing the patch file, an more automated one relying on setting up your tree so that it contains only the parts you want in the patch
<vila> Merwin: or may be just use 'bzr shelve'
<Merwin> Changes are already commited so shelves can't work
<vila> Merwin: i.e. shelve the changes you don't want in the diff
<Merwin> (Unless I missed something ?)
<vila> Merwin: uncommit in a temp branch ?
<Merwin> There's a lot of commits to uncommit :p
<fullermd> That would hardly work for scattered bits through the history...
<vila> Merwin: but I'm surprised by your use case, if it was committed why isn't it worth sharing ?
<fullermd> I'd just make a temp branch, merge, then start merging out the bits you don't want.
<Merwin> In fatch I have to brand : the main one and one for feature A. The problem is that a small feature B has been made in branch of feature A. Now, I ant to extract this features from this branch to put it in the main branch...
<Merwin> In fatc I have two branches*
<vila> Merwin: If I had to do it myself, I'm sure I won't be able to get it right manually at the first try so I'd use a dedicated tree for that to make sure I can refine the patch
<Merwin> So basically, I made a diff between main branch and branch A (containing feature A & B), but I just want to keep feature B, and generate a patch for it :p
<vila> Merwin: right, so *I* would make sure that feature B can me merged cleanly to trunk by.... first building theat featureB branch without relying on feature A and I'll get the diff from there
<Merwin> Yes, seems a good idea, but... how to build branch B... I can't cherrypick commits from branch A because it's badly commited (mixed features in commits...)
<Merwin> Hum, maybe create a branch B from main branch, these merge branch A in it, and before commiting merge, shelving changes I don't want ?
<vila> Merwin: so, like fullermd said, start a new branch with feature A & B and remove the unwanted bits
<vila> Merwin: yeah, something like that
<Merwin> okay thank you vila and fullermd
<vila> Merwin: and to avoid issues in the future, you probably want to not record that first merge with 'bzr revert --forget-merges' so you end up with a "stand-alone" patch
<Merwin> This won't revert changes, just remove the "pending merge" status ?
<vila> Merwin: failing to do so, once feature B is part of trunk, merging feature A will raise conflicts: "You did merge feature A in the past and removed bits, now you're merging feature A again. Do you want to add the removed bits again or leave them out ?"
<vila> Merwin: yes, it would forget which revisioins were merged, keeping only the changes as if you applied them manually
<Merwin> hum ok, interesting I didn't know it
<Merwin> Thank you
<vila> Merwin: this is better understood by toying around with the various workflows in temp branches and looking at the result with 'bzr qlog'
<ggherdov> hi all. when you do "bzr qlog <branch1> <branch2> ... <branchN>" you see a diagram representing the relations btween all mentioned branches (the DAG actually). I always loved that feature. Is it documented somwhere in the website? I want to show it to a friends but I am too lazy to make the minimal example, take screenshots and all that. Is there any pretty pic on the web ?
 * ggherdov also: why http://bazaar.canonical.com/ shows just file listing? wasn't it a nice homepage back in the days ?
 * ggherdov looks like the redirection to http://bazaar.canonical.com/en/ is broken ...
<jelmer> it does indeed look like that's broken..
<ggherdov> yep
<ggherdov> not good for the press ;-)
<ggherdov> ok ok i am doing my own screenshots... :-)
<ggherdov_> err... can anybody try to connect to the link http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style ? it takes 100% of my CPU and 95% of disk I/O... what the heck? I am trying on my ubuntu VM , firefox 20.0  and on my winXP workstation, same version of FFox. Whazat ?
<ggherdov_> does it work fine to you?
<ggherdov_> update, you dont need the fragment #team-collaboration-distributed-style in the url, it's just http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html that goes crazy.
<mgz> redirect loop, really firefox should do something sane with that...
<mgz> you want http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html
<ggherdov_> mgz: yep redirect loop. All firefox does is freezing my OS... good boy :-) thanks for the direct link
<ggherdov_> in the command "bzr qlog <branch1> <branch2> ... <branchN>" , is there any requirement on <branch_i>'s ? like, do they need to share some history ? or can the be like random branches not even branched from the same origin ? like, can I do "bzr qlog lp:mysql-server lp:bzr" i.e. compare totally unrelated things?
 * ggherdov_ is gonna find out very soon
<mgz> they can actually be whatever I believe
<mgz> it's a qlog only wonderment
<ggherdov_> mgz ah nice
<ggherdov> mgz: are you still around? just to say that you were right! you can actually do "bzr qlog lp:bzr lp:mysql-server" look: http://imgur.com/rDyYLIA
<ggherdov> I just put some gimp incantation to make it fit in a viewable size
 * ggherdov gotta go
<mgz> neat :)
<cjohnston> I'm trying to setup Jenkins to commit code to branches. I have jenkins setup on a machine. Right now there are two branches. Each branch needs a different 'launchpad user' to do the comitting. I see how to use different email addresses, but I'm not finding any help with how to use two different LP users to commit code. Is this possible?
<mgz> the easiest way would be to supply different BZR_HOME values
<mgz> then they could have different launchpad_username values set in each ~/.bazaar/bazaar.conf
<ggherdov> Hi all. Git folks have this page http://gitolite.com/1-basic-usage/tias.html that show a super simple way to simulate a real world workflow scenario. You do that and immediately can start playing and grasp what the system does in some situation that you might not understand very well. Is there a similar page for bzr? or, what are the correspondent commands to play the TIAS game in bzr (Try It And See) ?
<ggherdov> bzr init-repo b ; bzr branch b c1
<ggherdov> why do I have "Not a branch: "b/.bzr/branch/": location is a repository." ?
<mgz> ...because you created b as a repo, not a branch
<mgz> compare to `bzr init b; bzr branch b c2`
<ggherdov> msg ah. thank you.
<ggherdov> msg by the way, just to be clear about my intent, I'd like to create a ... $thing (repository? branch?) called "b" to act as the "production", or "reference" line of development (like a central server let's say), and then to "fork" it into what I called "c1", which simulate one of the N developers that will contribute to it. The first names that came to my mind are "repository" for "b", and... "branch" for c1, .., c_n. Is my understanding wrong?
<ggherdov> basically c1, ..., c_n use b to communicate btween them, via push/pull
<mgz> ggherdov: see <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/core_concepts.html>
<ggherdov> msg ok
 * ggherdov calling mgz msg bcse of his dyslexia :-)
<ggherdov> mgz: I think I got it. "bzr init-repo" create a repository, that can potentially contain *many* branches. Thus, "bzr branch" on a repo doesn't make any sense (I guess one can specify a branch inside that repo somehow). OTOH, "bzr init" create a single-repo-single-branch, which is a sort of "limited" repo since it's bound to have only one branch inside. Now, "bzr branch" on it makes sense since bazaar understand that you wanna fork the one and only
<ggherdov> branch in that repo. Am I close?
<mgz> right.
<ggherdov> thanks
<cjohnston> mgz: is there a way to have each launchpad_username use the correct ssh key?
<mgz> if both keys are available, they should just use the one that works, but I imagine you can set up something sane with the ~/.ssh/config
<lifeless> mgz: nooo
<lifeless> username exchange happens before key probing
<lifeless> mgz: (or I may misunderstand what you meant there)
<mgz> the username comes from the bazaar config
<mgz> we don't expose a way to pick which key to use, as far as I know
<mgz> but ssh will try all keys available locally, so if one launchpad account has one key, and the other has a different one, provided both are loaded it should be fine, no?
<cjohnston> I'm getting pubkey errors
<mgz> can you do `ssh -vv USER_A@bazaar.canonica
<cjohnston> two keys exist. one key is on one LP account, the other is on another LP account
<mgz> *@bazaar.launchpad.net
<mgz> and the same for USER_B?
<lifeless> mgz: yes, listing all the keyrings should work fine
<lifeless> or you can just use the same key on both LP accounts.
<cjohnston> they bot gave http://paste.ubuntu.com/5699705
<cjohnston> s/bot/both
<mgz> cjohnston: I brainoed, you want the correction, bazaar.launchpad.net
<cjohnston> http://paste.ubuntu.com/5699711/ http://paste.ubuntu.com/5699712/
<mgz> the first works, the second doesn't have the key
<cjohnston> correct
<mgz> what's the name of the second private key locally?
<cjohnston> qajenkinsbot
<mgz> you just want IdentityFile that then in .ssh/config
<mgz> you can have multiple IdentityFile entries per host
<mgz> ie:
<mgz> Host bazaar.launchpad.net
<mgz>     IdentityFile ~/.ssh/id_rsa
<mgz>     IdentityFile ~/.ssh/qajenkinsbot
<mgz> or similar
<cjohnston> ok.. ty
#bzr 2013-04-13
<Andy80> hi
<Andy80> suppose my current bazaar branch is on revision 2800 and I need to temporary switch back to revision 2799 to do some tests, how do I checkout another revision?
<Andy80> maybe I've found the command but I've a doubt...
<Andy80> for example if I do: bzr revno, I get 2801 (and it's ok). If I do: bzr revert -r2798, and then I execute bzr revno, I still get 2801, why?
#bzr 2013-04-14
<GNUtoo-m4a785t-m> hi, bzr says : No revisions or tags to pull.
<GNUtoo-m4a785t-m> but I guess there are some to pull
<GNUtoo-m4a785t-m> since I don't know a thing abuot bzr I keep re-cloning
<GNUtoo-m4a785t-m> but I guess it's not the right solution
<GNUtoo-m4a785t-m> sorry I've to go
#bzr 2014-04-07
<mbruzek> I am encountering an error when I do bzr push
<mbruzek> ERROR: Cannot lock LockDir: (...): Transport operation not possible:  http does notn support mkdir()
<mbruzek> I looked for the problem on-line and found that one needs to set lauchpad-login to use ssh rather than http
<mbruzek> So I ran:   bzr launchpad-login mbruzek
<mbruzek> bzr whoami looks right,
<mbruzek> Can anyone suggest what else I can do to fix this problem?
<LeoNerd> But you're still pushing over http from the look of it
<mbruzek> LeoNerd, I may have downloaded the branch via http.  Is there a way to change it to ssh?
<LeoNerd> bzr info   will show you what you currently have
<LeoNerd> There might be a command to change it, but personally I just directly edit the  .bzr/branch/branch.conf  file :)
<LeoNerd> It's a few lines of plain text
<jelmer> "bzr config" can do that for you, but yeah, editing the file works too :)
<mbruzek> thank you LeoNerd, and jelmer
<mbruzek> bzr config parent_location=bzr-ssh.... worked
<mbruzek> sorry bzr+ssh
<fullermd> I'd just push --remember.
<mgz> fullermd: that doesn't change the pull location, which is also relevent
<fullermd> Well, pull --r would.  And it solves the immediate problem   :p
#bzr 2014-04-08
<Laney> hello #bzr
<Laney> I got sent here from #ubuntu-devel to ask if there's an equivalent of `git reset --hard origin' in bzr
<LeoNerd> Maybe. How about explaining what it does, for the majority of us who don't know it
<Laney> Ok, thanks for the welcome. It resets your working state to the remote repository's. So if you were doing it separately: uncommit -r <last common revision>, revert, then pull.
<LeoNerd> Ah.. hmm....
<fullermd> I think it's more like a pull --overwrite, followed by a revert.  Except pull --overwrite already does the revert-ish stuff anyway.
<Laney> In git you'd have fetched the state already so it doesn't explicitly pull, but you don't have that in bzr.
<LeoNerd> But if you are simply ahead of upstream,  pull  will do nothing surely?
<Laney> Someone did tell me about pull --overwrite, but I wasn't sure if that did the expected thing or not.
<Laney> Like if you are ju, yeah that
<fullermd> ('s only important in other modes like --soft, where the pull --overwrite would has squirreled you)
<zyga> Laney: bzr revert
<LeoNerd> pull --overwrite will replace diverged history, but if you just have more commits on top of upstream it'll just say it has nothing to do
<zyga> er
<zyga> origin you say
<fullermd> No it won't.  It makes the upstream state always win.
<LeoNerd> Huhreally?
<zyga> Laney: bzr pull --force :parent maybe
<fullermd> No, it's --overwrite.  pull doesn't have a --force.
<Laney> zyga: --overwrite, but yeah, that's what they're saying (I think :parent is implied)
<zyga> Laney: :parent may not be implied :pull is implied
<Laney>   If you want to replace your local changes and just want your branch to
<Laney>   match the remote one, use pull --overwrite. This will work even if the two
<Laney>   branches have diverged.
<zyga> Laney: just use git-lp
<Laney> seems like the thing
<zyga> Laney: much much less hassle
<fullermd> I don't think there _is_ a :pull.  Pull uses :parent.
<mvo> zyga: is that a package?
<zyga> mvo: no, it's not a package, just one script to add to path
<zyga> http://zyga.github.io/git-lp/
 * mvo looks
<fullermd> I guess maybe you could make one yourself; the location aliases might be dynamic enough for that, I don't remember.
<zyga> strings attached but we use it daily and it really works
<zyga> strings == only one workflow tested
#bzr 2014-04-09
<thumper> abentley: hey
<thumper> just a quick question
<thumper> I have a branch that I branched off trunk
<thumper> but I want to make the tip revision the last one that is in common with trunk, and a release branch
<thumper> what's the command for that?
<thumper> nm, found it
#bzr 2014-04-10
<vila> jam, jam1, mgz: https://code.launchpad.net/~vila/bzr-update-copyright/506041-copyright-5-first-lines/+merge/215101
<vila> 6 digits bug ! \o/ ;-p
<jam1> vila: approve
<vila> jam1: wow ! I feel younger ;)
<fullermd> What an odd side effect of merge...
<vila> jam1: pushed to trunk
<vila> fullermd: well known fact, merging kids stuff is what vampires do (for example ;)
<fullermd> Obviously.  Consider the phrase "mineral hair whelk".  Whelk obviously refers to the shell you're working in, and hair to the many strands of development.  And mineral is the good and useful bits to be found in them.
<fullermd> And it's an anagram of "Wilhelmina Harker", thus the connection.
<vila> Whilelmina ! Long time not heard about... how is she going ?
<fullermd> (thus endeth your Random Nerdery Of The Evening)
<vila> poil au morning (unfortunately I'm afraid the translation lose a bit of the joke...)
<fullermd> Dunno, I lost track of her after that whole "beheading on a gypsy road" ordeal.
<LeoNerd> Bah.. How are you -supposed- to use bzr shelve's "edit" feature?
<LeoNerd> Every Single Time I do it, I get a merge conflict on every single manual edit I've done
<LeoNerd> (when I unshelve)
#bzr 2014-04-11
<gorhgorh> hi there, simple noob question â¦ Iâm trying to build kikad, that require those bzr tool so I installed them, created a launchpad account and added a ssh key, when i âbzr launchpad-login gorhgorhâ i got âNot checking SSL certificate for launchpad.net.â
<gorhgorh> i did add a key to my launchpad account
#bzr 2014-04-12
<fullermd> Standalone tree (format: knit)
<fullermd> Man, the things hiding in my ~...
<jelmer> :)
<fullermd> In fairness, it WAS totally up to date.
<fullermd>   latest revision: Sun 2006-11-19 03:56:23 -0600
<jelmer> you were definitely one of the hip kids in 2006
<fullermd> Hey, I'm still a hip kid now!  It's just 2...  3...   uh...   a couple years later!
#bzr 2014-04-13
<johnweldon> anyone wiling ot help me with a couple questions about the pipeline plugin?
<jelmer> hi johnweldon
<jelmer> johnweldon: it's been a while since I touched it, but I can try
<johnweldon> well, it sounds like pipelines are kinda like queues in mercurial and stashes in git?
<johnweldon> thanks jelmer
<johnweldon> I have another persons personal branch that I want to extend
<jelmer> johnweldon: stashes are more like shelves
<jelmer> pipelines are a bit similar to queues
<johnweldon> jelmer makes senes
<johnweldon> sense even
<johnweldon> if I want to work off of a third persons personal branch can I use pipelines to do so?
<johnweldon> i.e. I want to hack on juju-core
<johnweldon> someone has made changes that are in their ~username/juju-core/branch
<johnweldon> can I make their branch a pipeline and begin extending it?
<johnweldon> it's beginning to sound like that doesn't quite make sense
<jelmer> why wouldn't you just create a regular branch in that case?
<johnweldon> if my tree is already pointing to juju-core, can I check out a branch from someone else into that tree?
<johnweldon> sorry just trying to learn bzr
<jelmer> I
<jelmer> 'm not sure if I'm following, sorry :(
<jelmer> sleep first, I'll be back tomorrow :)
<johnweldon> no worries.  Tx.
#bzr 2015-04-06
<qsuscs> how can i check whether i am in a bazaar repo/checkout (whatever the appropriate term may be) in a script?
<beuno> qsuscs, sure, using bzrlib
<qsuscs> beuno: how? iâm looking for something easy, such as:  bzr status || die "not in a repo"
<beuno> qsuscs, is this from a python script?
<qsuscs> beuno: no, makefile
<beuno> qsuscs, then yes, call bzr status
<fullermd> May wanna use 'bzr root' or the like instead, since status would have to scan the whole tree.  Not that it'd matter on smaller projects, but...
<nopf> hi. can i define additional location aliases to more easily push/pull to/from a secondary/backup location? like somehow define :backup ? why not?
#bzr 2015-04-07
<fullermd> nopf: Check out the bookmarks plugin
#bzr 2015-04-11
<kramer3d> hi
<kramer3d> im trying to get the source from a project
<kramer3d> and i keep getting this error You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data.  See "bzr help launchpad-login".
<fullermd> kramer3d: That's usually not an error, just informative.
<kramer3d> ok
<kramer3d> ya i noticed it actually downloaded lol
#bzr 2016-04-12
<bschaefer> hello, having an issue where pushing to a launchpad branch just seems to hang indefinitely?
<bschaefer> the branch in question: https://code.launchpad.net/~mir-team/miral/trunk
<bschaefer> after it fails, ive to break the lock (not sure what was the starting issue)
#bzr 2018-04-15
<lamneth> anyone here who's been able to register SSH keys successfully for launchpad+bazaar on **Windows**  ???
<jelmer> lamneth: yeah, that should work fine
<lamneth> finally got it
<lamneth> *minor* detail was missing from a lot of >how to> answers...  I thought pageant was not working because I read "once open, just paste your key" ...  Nobody specified the thing was started in the icon tray and I kept investigating how to do that via the command line thinking the app wasn't starting properly!
