#bzr 2008-04-14
<jml> I get this error when I branch bzr: bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "thanks.txt-20050309044946-58141ea3091846d8".
<jml> It happens whether I use bzr.dev or bzr 1.3
<bob2> into a rich-root{,-pack} repository?
<jelmer> grrr, I just hit the rich root bug again as well :-(
<jml> bob2: into a standalone branch
<Talden> My Scenario:
<Talden> Reviewers have full checkouts of mainline to merge dev branchs into (update -> merge from dev1 -> review and commit).
<Talden> QA has a lightweight checkout (update -> test and tag)
<Talden> My Question: How do tags propagate in checkouts?
<Talden> The QA tags show up for any new checkouts or brances made from mainline but they don't show up in reviewer checkouts that already have the tagged revision.
<Talden> If a reviewer uses pull (which requires a path strangely) they do get the tags.  Shouldn't update transfer tags like pull and shouldn't pull default, in a checkout, to the checked out location?
<spiv> Good morning.
<spiv> igc: good morning!  I'm jealous :)
<igc> hi spiv
<igc> spiv: if it makes you feel better, it rained a lot :-)
<poolie> dhello
<spiv> poolie: good morning
<poolie> hello spiv
<lifeless> back
<igc> hi lifeless
<lifeless> hi igc, welcome back
<igc> thanks
<igc> jamesh: thanks for working on the set_revision_info hook stuff
<jamesh> igc: no problem.  The API from your branch was better than mine anyway :)
<jamesh> igc: was there a particular thing you wanted the hook for?
<jamesh> (I wanted it for bzr-dbus)
<igc> jamesh: it was part of the work spiv and I started in the Chicago sprint to get good server-side hooks
<Stavros> hello
<Stavros> what is the proper procedure after merging branches that have diverged?
<poolie> Stavros: fix any problems, test or read the diff, then commit
<Stavros> and everything will go in its proper place?
<Stavros> in the graph, i mean?
<poolie> can you explain your question more?
<Stavros> well, i have two branches that have diverged and i merge on mine
<Stavros> and "bzr status" gives me some weird stuff, pending merges and the like
<poolie> right :)
<Stavros> and i am just wondering if that is proper behaviour
<poolie> that's correct
<Stavros> ah, good
<poolie> now commit on your branch
<Stavros> so if i commit everything will work fine?
<Stavros> good
<spiv> jamesh: in combination with the code I recently landed to add a Branch.set_last_revision_info smart verb, it starts making some server-side hooks possible
<Stavros> okay great, thanks!
<poolie> now, depending on the purpose of the two branches you may want to take one further step
<poolie> if they are both _meant_ to be the same,
<Stavros> what's that?
<jamesh> spiv: I suppose you don't see the pre/post_commit hooks on the server side?
<poolie> for example if you are working on the same bug on your laptop and desktop
<jamesh> since it is just pushing a locally committed revision
<poolie> you may want to push your merge from the branch where you committed it into the other
<Stavros> ah
<ubotu> New bug: #217031 in bzr ""bzr launchpad-login -v MYNAME" gives no feedback" [Undecided,New] https://launchpad.net/bugs/217031
<poolie> that will switch the other branch to be in the same revision- you can then push and pull between them without needing to merge
<poolie> however
<poolie> if the branches have different purposes
<Stavros> well i have a different workflow with a master server, but i see what you mean
<spiv> jamesh: right
<poolie> for example if one is the trunk and one is your feature branche
<Stavros> yes
<Stavros> that's it
<poolie> then you shouldn't do this
<poolie> cool
<Stavros> yes
<poolie> glad i could help
<Stavros> so i just wait until i finish the feature then
<Stavros> thanks a lot!
<spiv> jamesh: and for some cases at least, you might not care if it was a new commit vs. a push vs. uncommit or whatever, you might want to always run a hook if the branch's tip changed.
<lifeless> abentley: ping; you've been talking with alexander about line ending stuff; is he doing roughly what we planned in London, or something different?
<abentley> I don't have a clear idea what he's doing.
<abentley> Sorry, gotta go.
<lifeless> bye
<lifeless> I'll read the thread in detail then
<lifeless> poolie: 1.4 made
<Stavros> i am tagging revisions with already existing tags, but pushing with --overwrite so the tags will get accepted is a bit dangerous, isn't it?
<hersonls> martin pool, you be here?
<spiv> hersonls: he's poolie
<hersonls> poolie, hey guy
<hersonls> poolie, you be here?
<lifeless> hersonls: I suggest you ask the question/start the discussion you want to have; 'presence' on IRC is a fairly weak concept.
<hersonls> lifeless, tanks
<wildfire> bzr internal error: http://pastebin.com/m373ccb16
<wildfire> and is there no way to specify a path delimiter with bzr? e.g. git add -- foo/; git commit -- foo/ seems to have no analogue in bzr
<bob2> as in make it non-recursive?
<wildfire> no, as in not have to specify each of the files in the foo directory to bzr commit individually
<poolie> wildfire: bzr commit foo should do that
<bob2> bzr commit -m 'blah foo/ will commit all changes to foo and below
<wildfire> hmm, apparently I've managed to break the repository and I get the internal error now; so I can't check that that works
<wildfire> even on 'bzr status'
<poolie> hersonls: go ahead
<hersonls> poolie, hey, you remeber me?
<poolie> yes
<hersonls> poolie, tanks for help
<wildfire> bob2, poolie: oh, it appears me doing that command 'bzr commit blosxom' is what caused the internal error
<lifeless> wildfire: is bloxsom versioned?
<lifeless> wildfire: does 'bzr st' work?
<lifeless> wildfire: and do you have nested trees?
<hersonls> poolie, how i crate new team in lauchpad?
<wildfire> lifeless, it was versions, bzr st fails with an internal exception (assuming it is the same, and assuming 'st' is 'status'), not a nested tree, no
<wildfire> s/it was versions/it was versioned/
<wildfire> lifeless, 'bzr st' output http://pastebin.com/m532dfc0e
<poolie> wildfire: i'm looking into that assertion
<wildfire> poolie, okay, I'll probably only be up for another 30 mins or so
<poolie> wildfire:  i think you are hitting bug 150438
<ubotu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [Medium,Incomplete] https://launchpad.net/bugs/150438
<poolie> can you provide any moer information beyond the traceback about what caused it?
<wildfire> poolie, progsoc is using bzr to manage /etc on a few machines; I did a 'dpkg -P blosxom' which also removed the /etc/blosxom directory
<wildfire> poolie, I then wanted to commit that directory removal, so I did "bzr commit blosxom" and from this point onwards bzr is failing with an internal error on a number of commands
<lifeless> thumper: I would breakpoint in the failing tests setup(); and check that the queue setup's setUp() really is working correctly
<thumper> lifeless: ok
<thumper> lifeless: I'm just off to collect kids from school et al, and will get back to you
<lifeless> k
<poolie> wildfire: thanks
<poolie> to recover that directory i suggest you
<poolie> bzr branch /etc /tmp/new-etc
<poolie> mv /etc/.bzr /etc/.bzr.broken
<poolie> mv /tmp/new-etc /etc/.bzr
<poolie> (maybe make a backup of all of etc ot a tarball first)
<wildfire> poolie, actually I don't want to recover the directory. I want to record the removal of it ...
<poolie> i meant, to get bzr back in a working state
<wildfire> ah, okay
<poolie> to commit the removal of it and avoid this bug
<poolie> i suggest you just remove it, and then commit the whole thing (with no other changes made)
<spiv> I think the last line should be "mv /tmp/new-etc/.bzr /etc/.bzr"
<poolie> thankyou for reporting it
<poolie> !
<poolie> you're right, sorry
<wildfire> poolie, hmm, the first command 'bzr branch /etc /tmp/new-etc' is also failing with the internal errors
<wildfire> poolie, also, just in case this was related to the interative plugin I checked with that removed and it also fails
<poolie> could you paste it?
<wildfire> sure, one sec.
<lifeless> spiv: ivar - thats ":ivar THING: details" right ?
<spiv> lifeless: yeah, I think so.
<spiv> just like param, except s/param/ivar/ :)
<wildfire> poolie, http://pastebin.com/m5ffc2800
<poolie> what does 'bzr log -r -1 /etc' show you?
<wildfire> wildfire@muspell:/etc$ sudo bzr log -r -1 /etc
<wildfire> ------------------------------------------------------------
<wildfire> revno: 51
<wildfire> committer: Anand Kumria <wildfire-bzr@progsoc.uts.edu.au>
<wildfire> branch nick: Muspell /etc
<wildfire> timestamp: Mon 2008-04-14 11:56:12 +1000
<wildfire> message:
<wildfire>    Ignore generated berkeley db files
<poolie> is that the revision you were trying to commit when it failed/
<poolie> does bzr branch -r -2 work?
<wildfire> bzr log -r -2 works
<wildfire> the revision I am trying to commit is the removal of the /etc/blosxom directory
<poolie> ok
<poolie> can i suggest you start from the branch of revision -2, put it back in place as above, and then try the commit from the top of your tree
<wildfire> poolie, you mean 'bzr branch -r -2 /etc /tmp/new-etc' and then go from there?
<poolie> yes
<wildfire> poolie, done and now 'bzr status' tells me that the blosxom directory has been removed
<poolie> ok
<wildfire> how should I now go ahead and commit that ('bzr commit blosxom' is what caused the breakage before)
<poolie> i think you should just commit with no arguments from the root of /etc
<lifeless> poolie: I'm smelling an update_by_delta bug
<poolie> unless you want to see if that reproduces it
<wildfire> ahh, I have other unrelated changes that I'd like to commit in a separate changeset
<lifeless> wildfire: bzr shelve++
<poolie> ah
<poolie> it's possible those changes are causing this
<poolie> could you paste bzr st?
<wildfire> one second
<poolie> actually it would be easier if you just put it in bug 150438
<ubotu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed] https://launchpad.net/bugs/150438
<poolie> since that's just what i was going to do :)
<wildfire> http://pastebin.com/d1e7a407
<wildfire> poolie, I'll try but it appears progsoc's email is b0rked, which is why I'm trying to look at the configuration (and remove unnecessary stuff)
<poolie> ok, thanks for that
<poolie> lifeless: ^^
<poolie> it doesn't *look* strange
<poolie> wildfire: if you want them in separate commits i suggest selectively committing everything but the blosxom deletion
<wildfire> poolie, just tried (bzr add .bzrignore; bzr commit .bzrignore; bzr status) which returns me to the broken state again
<lifeless> .bzr << bloxsom << dovecot
<hersonls> i need help commit with bzr
<hersonls> someone help me
<wildfire> lifeless, -EPARSE ?
<lifeless> wildfire: I'm speculating about the nature of the bug
<poolie> hersonls: just ask your question please
<hersonls> poolie, how i send the commit to launchpad?
<poolie> lifeless: you suspect another ordering problem in the dirstate?
<wildfire> oh, okay, well I can redo the tmp/new-etc thing and try the dovecot one first then
<wildfire> one sec
<poolie> hersonls: have you created a Launchpad account?
<hersonls> yeah
<hersonls> poolie, i try bzr push and return locked 30 minutes, 24 seconds ago
<poolie> hersonls: what url are you trying to push to?
<lifeless> poolie: in the update via delta code of commit; yes
<hersonls> poolie, bzr+ssh://hersonls@bazaar.launchpad.net/~hersonls/bzr/slackbuild
<poolie> hersonls: did you maybe previously try to push to it and interrupt the process?
<poolie> hersonls: if so ,try 'bzr break-lock URL'
<wildfire> lifeless, poolie: okay, redone. (bzr add dovecot/dovecot.conf; bzr commit dovecot/dovecot.conf; bzr status) works
<lifeless> wildfire: I speculate that add .bzrignore; commit; status will still break
<wildfire> lifeless, if you had bet, you would be
<wildfire> ...
<wildfire> wrong
<poolie> :)
<poolie> biab
<lifeless> fwiw you could have done 'bzr commit dovecot' - dovecot/dovecot.conf was already added according to your status
<hersonls> poolie, i push to the branch bzr+ssh://hersonls@bazaar.launchpad.net/~hersonls/bzr/slackbuild and in https://code.launchpad.net/~hersonls/ say be empty
<spiv> hersonls: it doesn't look empty to me
<poolie> lifeless: oh could you please fix 1.4 pqm this afternoon, if you did'nt already?
<poolie> hersonls: there is a slight lag before the web ui updates, you might have hit that
<hersonls> poolie, i can lock this branch for push by another users?
<poolie> hersonls: oh is this the data to build bzr in slackware? great!
<hersonls> poolie, yeah
<poolie> hersonls: you want to let them write, or not let them write?
<poolie> man, team creation is just impossible to find in lp...
<hersonls> not write
<poolie> ok
<hersonls> i can do that?
<poolie> because that branch is owned by you, only you can write
<hersonls> ohhh
<hersonls> yeah
<hersonls> i can build team for this branch?
<poolie> on that page it says (to me) "Upload URL:   You cannot upload to this branch. Only hersonls  can upload to this branch. "
<hersonls> oh, tanks...
<hersonls> i brazilian, and my english is bad
<hersonls> sorry
<poolie> if you want it to be writeable by a team create one at https://launchpad.net/people/+newteam
<poolie> it's ok
<poolie> de nada :)
<hersonls> ohh
<hersonls> vocÃª fala portugues?
<poolie> un poco
<poolie> uh that's about the limit :)
<hersonls> bomm
<poolie> but there are several brazilian people in #launchpad
<poolie> or indeed sometimes here
<poolie> like kiko
<poolie> biab
<hersonls> poolie, my team can write in branch?
<poolie> you'd need to also change the branch to be owned by that team
<hersonls> ok
<hersonls> poolie, the list of all files of the branch, can see where?
<hersonls> in http://bazaar.launchpad.net/~hersonls/bzr/slackbuild
<hersonls> ?
<poolie> hersonls: click the directory name
<poolie> (really gone now
<hersonls> i can use that links to wikipage of the bazaar for download?
<hersonls> poolie, ?
<lifeless> bbiab
<thumper> lifeless: found the problem
<thumper> lifeless: ping me when you have some time to talk about it
<lifeless> thumper: so
<thumper> lifeless: bug 217112
<ubotu> Launchpad bug 217112 in pqm "Test failures on a clean checkout" [Undecided,New] https://launchpad.net/bugs/217112
<thumper> lifeless: I was also bitten by 210165
<thumper> bug 210165
<ubotu> Launchpad bug 210165 in launchpad-bazaar "BugBranch links created after pushing a copy of a branch with "bugs" revision properties" [High,Fix committed] https://launchpad.net/bugs/210165
<thumper> lifeless: so I'm cleaning the branch on LP right now
<lifeless> thumper: so, linking the branch is good
<lifeless> what would be better is linking the branch *and* providing a link which will show me the merge preview of the branch.
<lifeless> (presumably via loggerhead)
<thumper> lifeless: the merge preview stuff is coming (RSN)
<thumper> unfortunately I have to head out for an hour and a bit
<thumper> so we could talk about this tomorrow morning if you like
<lifeless> cool; but it should be there *before* the merge is requested, if you see what I mean
<lifeless> thumper: +1 on the fix; but the comment isn't needed there
<lifeless> it is clear that it is the right thing to do
<thumper> ok
 * thumper away
<lifeless> drop the comment and update the branch, I'll merge it to mainline tomorrow
<ubotu> New bug: #217134 in bzr "Break-lock: Bzr doesn't accept my keystrokes to allow it to continue" [Undecided,New] https://launchpad.net/bugs/217134
<igc> night all
<lifeless> thumper: well, a) lp should notify the bug subscribers
<lifeless> thumper: and b) a bug comment would be fine
<poolie> night ian
<thumper> yeah, I guess
<jelmer> Ran 783 tests in 29550.804s
<ubotu> New bug: #217180 in bzr-svn "Bzr update crashes" [Undecided,New] https://launchpad.net/bugs/217180
<ubotu> New bug: #217188 in bzr "bzr update crashes with KnitCorrupt error" [Undecided,New] https://launchpad.net/bugs/217188
<poolie>  /win 12
<guilhemb> Hello! a question: I used bzr on a Windows machine, to modify a file originally created under Unix (lines terminated with LF), and after that the file had all its LF changed with CR-LF, and "bzr gcommit" showed all lines changed because of that.
<guilhemb> I remember some other revision tool which handles that fine (it must discard CR-LF along the way);
<bob2> ideally your editor should not screw them up
<guilhemb> is there a switch in bzr to have that too?
<bob2> but there is development in bzr to add that feature
<guilhemb> bob2: I agree; but I'm not driving Visual Studio's roadmap :))
<bob2> but it does not afaik exist yet
<guilhemb> bob2: this is good news! do you know a place where the planned development is tracked (a bug report, anything?)
<bob2> http://bazaar-vcs.org/LineEndings seems still current tho old
<bob2> "Status of this work: I have working implementation and will send merge request soon.", yay
<guilhemb> bob2: and that comment is 2 days old!!
<guilhemb> bob2: thank you for the link!
<bob2> no worries
<nevans> jelmer: is the 0.4 bzr-svn branch "safe" to use with bzr 1.4rc1 at the moment?  or should I stick with bzr 1.3 for a while longer?
<awilkins> Anyone know the status on custom merge support? The particular case I'm interested in is "per filetype merge support" ; I want to be able to unpack an XML file into a more merge-friendly line format, then pack it back up again after the merge has finished.
 * awilkins reads the code and concludes that he could make a plugin that implemented a merger that inherited from Merge3Merger or Diff3Merger that did the required stuff.
<awilkins> Would that be accurate?
<asabil> awilkins: there is a plugin that implements diff for ms word files iirc
<awilkins> Aha, yes, I'll take a look at the source for that
<asabil> http://gigo-ice.org/scm/bazaar/plugins/docdiff.html
 * awilkins is quick on the draw and is aleady pulling the branch :-)
<asabil> :)
<awilkins> Not quite what I wanted though ; I want something that meshes seamlessly with "bzr merge" for my special case.
<awilkins> I think I see the way though - if I inherit from one of the existing mergers I should be able to register a new one.
<abentley> awilkins: That's correct.  Odd_Bloke was working on support for custom merges at the sprint, but I haven't heard since.
<awilkins> abentley: From what I've read so far, the merge classes could be refactored out a little ot make custom merging a bit easier to implement
<abentley> awilkins: I'm sure that's true.
<awilkins> abentley: e.g. ; all I require is a pre-process step and a post-process step, but I'm probably going to have to (at a minimum) cut/paste the whole text_merge routine from Merge3Merger
<awilkins> Odd_Bloke: awake?
<intellectronica> howdy
<intellectronica> i am having problems pushing a local branch using bzr 1.4rc1 to a server running 1.3.1 (i suspect this is since the upgrade, but am not certain). is that a known problem?
<abentley> intellectronica: no
<intellectronica> abentley: cheers. i'm now discussing this with jam on bzrlp, b.t.w
<ubotu> New bug: #217290 in bzr "Error during "bzr commit" ERROR: exceptions.MemoryError" [Undecided,New] https://launchpad.net/bugs/217290
<Odd_Bloke> abentley, awilkins: Just going to bed, in fact.  To answer several questions at once, I'm not at uni ATM so am catching up with family and friends who I don't see that often.  I head back on Wednesday and so should get back into the swing of things shortly. :)
 * Odd_Bloke --> sleep the sleep of the dead
<ubotu> New bug: #217313 in bzr ""bzr push" fails with error "unable to rename ..."" [Undecided,New] https://launchpad.net/bugs/217313
<LeoNerd> I wonder what the reaction would be to a bzr plugin with an amusing name. I'm thinking of a combined push/pull, which syncs in either direction provided one side is just older than the other... "bzr sync" sounds too generic. What about "bzr llama", as a joke on the Push-me-Pull-you from Dr Doolittle
<sm> good morning.. what's the correct lp: equivalent for bzr branch http://bazaar.launchpad.net/~zope2book/zope2book/zope2book ?
<sm> I thought bzr help urlspec would tell me
 * sm has 1.3
<sm> why do I get bzr push lp:~zope2book/zope2book/zope2book
<sm> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ezope2book/zope2book/zope2book/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<sm> ?
<radix> sm: you can't push to launchpad over HTTP
<radix> sm: use bzr+ssh instead
<sm> ah, thanks
<radix> sm: oh, I see your command. I think you can use 'bzr lp-login' and a sufficiently recent version of bzr to have that automatically happen for 'lp:' urls
<radix> or maybe I'm making all of that up
<sm> trying bzr lp-login username then push lp: .. it's sitting there for quite a while
 * sm has made one small patch
<sm> worked! thanks
<radix> sm: cool!
<radix> I'm not a liar! yay
<fullermd> Hm.  bzr viz misnumbering revisions...
<ubotu> New bug: #217377 in bzr "merge in shared repository failed assertion" [Undecided,New] https://launchpad.net/bugs/217377
<dwt> Hey guys, I'm still new to bzr - is there a way to cherrypick individual hunks out of a file for a commit?
<dwt> I couldn't find anything on the wiki
<dwt> so I figured I'l ask you guys.
<dwt> oh, and I'm on 1.2.0
<awilkins> dwt - bztools shelve plugin
<dwt> thanks
<asabil> dwt: and the interactive plugin provides the opposite
<dwt> awilkins: Thats indeed very cool. I do prefere to puth stuff to the side
<dwt> so I can test in the tree
<dwt>  before comitting
<dwt> However I don't quite get how to tease apart individual hunks.
<dwt> Is that possible with shelve?
<dato> it is
<dato> it will show you each hunk
<dato> and ask what to do with it
<fullermd> No, you can't work at a sub-hunk granularity with it...
<dwt> Is there a way to separate a hunk manually?
<dwt> I mean, so bzr sees it as two hunks?
<dato> ah, I misunderstood the question
<awmcclain> Hi all. Just wanted to say how much we love bzr. We just re-rooted our entire branch effortlessly and bzr handled all the merges like a dream.
<dwt> dato: Thanks anyway!
<abentley> dwt: At sub-hunk granularity, you're better off using your editor's diff mode.
<abentley> e.g. bzr diff --using gvimdiff
<dwt> abentley: Well, my diff tools all dont let me choose what parts of a hunk I want it to see as a new hunk. :-(
<dwt> But maybe I'm missing something
<abentley> dwt: For shelf to work at sub-hunk granularity, it would have to become a crappy editor.
<rockstar_> Can I use bzr-svn on an svn repo over https?
<abentley> So use an editor instead.
<dwt> abentley: yeah, I could try to insert something that was in the old revision in between those so I can shelve the other stuff and then return to the previous state
<abentley> dwt: What is your editor?
<dwt> I use Xcode mostly
<dwt> Or Textmate
<dwt> On OS X
<abentley> Does Textmate have a diff mode?
<dwt> not really - it can view diffs
<dwt> in very nice ways
<dwt> though no commands to bzr from there
<abentley> Ah.  Vim and Emacs both provide ways to edit a file while showing a comparison to a previous version.
<dwt> How does that allow me to split a hunk
<dwt> ?
<abentley> Which makes it easy to restore old lines.
<dwt> ok, true
<abentley> There is no hunk-splitting support in bzr because if you need to split hunks, you really need to use an editor anyhow.
<abentley> This does not mean that the editor does hunk splitting.
<abentley> It means that the editor is a better alternative than hunk splitting.
<Pilky> anybody any idea how long it usually takes for the OS X installer packages to be updated?
<dwt> abentley: Well, thanks for the help
<dwt> I will see how that works.
<statik> dwt: there is a textmate plugin here, but I have not tried it myself: http://bazaar-vcs.org/TextMateBundle
<dwt> statik: thanks for the link!
<ubotu> New bug: #217454 in bzr-svn "Trying to branch a subversion branch into a shared repo gives AssertionError" [Undecided,New] https://launchpad.net/bugs/217454
<mxpxpod> jelmer: does bzr-svn 0.4.9 work with 1.4rc1?
<jelmer> mxpxpod: Nope, there's nothing compatible with 1.4rc1 out yet
<jelmer> mxpxpod: I hope to release something before friday (when 1.4 is released)
<mxpxpod> jelmer: gotcha
<lifeless> jam: I am fixing the regression
<jam> lifeless: thanks
<lifeless> jam: did you file a bug?
<jam> lifeless: no, I didn't. Do you want an official bug?
<lifeless> no
<lifeless> just would have recorded if there was one
<jam> sure, how did you chose to fix it, btw
<lifeless> patience kemosabe :)
<lifeless>     * Severe performance degradation in fetching from knit repositories to
<lifeless>       packs due to parsing the entire revisions.kndx on every graph walk
<lifeless>       iteration fixed by using the Repository.get_graph API. (Robert Collins)
<jam> lifeless: I had thought about that at one point, but it didn't make it into the email, and I also wasn't sure if Graph.get_parent_map() would also be cached.
<jam> But I guess KnitRepo.get_graph() returns a wrapper around the KnitVF itseldf
<lifeless> KnitRepository._make_parents_provider returns a closure with the revision versioned file
<lifeless> actually with my changes it can return the revision vf directly
<jam> lifeless: Implementing get_parent_map directly on KVF?
<jam> lifeless: have you been telling people about your fix on #bzrrlp?
<lifeless> already done
<lifeless> no, should I?
<lifeless> poolie: ping; I think versioned properties are likely a bad idea and not a dependency for the eol stuff bialix has done
<lifeless> poolie: but I don't want to discourage him
<jam> lifeless: I'm happy to tell them
<jam> they were just reverting from 1.4rc1 back to 1.3.1
<jam> and it would be good to have them test it after your patch
<lifeless> oh sure
<igc> morning
<jam> bug #208418
<ubotu> Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Fix released] https://launchpad.net/bugs/208418
#bzr 2008-04-15
<poolie> jam, igc, spiv: call now
<jam> poolie: waiting for you to show up :)
<lifeless> jam: also - #ubuntu-wow
<lifeless> poolie: ^
<poolie> thanks
<poolie> lifeless, igc: reading the thread now, this might take more than 15 mins
<lifeless> -> food then
<igc> poolie,lifeless: let's aim for 10 then
<poolie> k
<lifeless> abentley: ping; are you interested in me making MPVersionedFile meet the VersionedFile (reduced) api ?
<lifeless> abentley: also can I request a review from you for my loom push fix.
<ChrisPitzer> Hello.  I've used bzr in linux before, but now I'm trying to get it working in windows through putty.  I can run bzr in a terminal, or I can run putty and log on to my server (where I'd like to build a repository) with putty... but I'm not sure how to run bzr in putty...  I think I'm missing something.
<lifeless> poolie: igc: its 10
<igc> poolie,lifeless: normal number?
<lifeless> igc: as far as I knew, yes.
<poolie> we could use skype if that's easier?
<lifeless> elevator music @ home sucks
<igc> calling in now on normal number
<dagreen> hey, can someone help a noob with an admin question?
<dagreen> I'd like to setup an server for a central repository
<dagreen> the docs tell me to use sftp to upload a branch
<dagreen> but I want to make it publicly accessible
<dagreen> how would I do this with sftp?
<bob2> you can make it read-only accessible via http, and have users write via sftp
<dagreen> so, setup an apache server?
<bob2> well, whatever htpd you like.  you could setup an anonymous sftp account if you prefer.
<bob2> gnu used to do that for cvs over ssh, iirc
<dagreen> OK.  so, I tried searching for some good docs on settings up sftp, but came up short
<dagreen> can someone point me to a good guide?
<dagreen> I can setup sftp so users can access their own home dir, but not to a shared dir
<dagreen> or even how to allow anonymous access for that matter?
<poolie> this is hard enough even if i can hear you :)
<poolie> dagreen: on unix or windows
<dagreen> fedora
<ChrisPitzer> How do i uze bzr in putty?
<dagreen> unix
<bob2> ChrisPitzer: what preciesly are you trying to do?  use bzr+ssh:// urls?
<poolie> dagreen: so basically you should put them in a unix group
<poolie> and create a directory writeable by that group to hold the repositories
<poolie> if you're trying to host an open source project you can alternatively use launchpad.net
<dagreen> not open source, internal company use
<dagreen> so, if they were to checkout a project by typing bzr branch sftp://my-server/myproject
<dagreen> do I have to put a link to that directory from all their home directories or something?
<bob2> no
<ChrisPitzer> bob2: I'm trying to use putty to ssh onto a server and set up / work with bzr repositories.
<bob2> users connected via sftp have the same access rights as they would if they logged in via ssh
<bob2> so it can go anywhere they could normally reach it (e.g. /srv/bzr/)
<bob2> ChrisPitzer: as in ssh in via putty, and run bzr from the command line on the remote machine?
<ChrisPitzer> i tried that - bzr isn't installed on the remote machine.
<bob2> there's your problem then ;)
<ChrisPitzer> haha.
<ChrisPitzer> i know
<bob2> you can access it remotely with sftp:// urls, have you tried that?
<ChrisPitzer> i have bzr installed on *this* machine though... can't I use this bzr instance to create remote repositories...?
<ChrisPitzer> just from the command line - no putty...?
<bob2> "bzr init-repo sftp://blah/blah"
<ChrisPitzer> hu... I'll give it a shot - brb
<bob2> I think you need paramiko installed for that
<ChrisPitzer> (i still think very "windows" some times)
<dagreen> poolie:  after I shared directory and give the appropriate permissions to the group, how do I make it so that directory is the root when they sftp??
<bob2> don't think regular openssh has sftp chrooting
<dagreen> k, so the only way to make urls look like root is through http then, right
<dagreen> ?
<poolie> dagreen: just use sftp://host//home/group/repo
<dagreen> k.  that should work for me.   didn''t know there was a /home/group
<dagreen> thx
<ChrisPitzer> so... check my crummy syntax here...
<ChrisPitzer>  bzr init sftp://username:password@sub.domain.com/src
<ChrisPitzer> because, that results in a bunch of happy text with a last line of "bzr: ERROR: No such file: '/src':"
<bob2> try //src
<ChrisPitzer> same sad ending.  "no such file: '//src' "
<bob2> is there a /src on sub.domain.com?
<ChrisPitzer> hehe... yes.
<ChrisPitzer> where is // ? root?
<ChrisPitzer> ooooh... bingo
<ChrisPitzer> that's it.  I need to specify full path on the server, not relative.
<fullermd> With sftp you can specify relative with a ~.  sftp://user@dom.ain/~/src
<ChrisPitzer> thanks!
<awmcclain> Hey all. So, am I right in figuring out that bzr-email ONLY works from the client-side?
<spiv> That's right.
<igc> lifeless: was it just me that dropped out?
<awmcclain> That is frustrating.
<igc> poolie:^
<lifeless> igc: yes, credit ran out
<radix> awmcclain:  https://bugs.edge.launchpad.net/bzr/+bug/211967
<ubotu> Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed]
<igc> lifeless: dropped out - I think we're done though, yes?
<igc> poolie:^
<igc> lifeless: if not, you can call me on my home line now
<lifeless> poolie: the knit fetch hotfix has landed in trunk
<spiv> awmcclain: we're working on fixing that.  I just updated the bug radix linked to with some details.
<radix> woot
<awmcclain> yay!
<awmcclain> Ok. Not a problem.
<radix> oh, so it might already be possible?
<radix> great
<spiv> radix: yeah
<spiv> radix: "might" being the important word, I don't think it's actually been tested yet.  In theory it should be fine...
<lifeless> spiv: bzr-email needs to be altered
<spiv> lifeless: right.  I didn't mean to give the impression that bzr-email specifically would Just Work, yet.
<spiv> Just that it should now be possible to write something that uses the new hook, and have that get triggered on the server.
<lifeless> thumper: your patch is merged
<thumper> yay
<thumper> ta
<abentley> lifeless: Updating the MPVersionedFile API is fine with me.  I guess reducing the number of APIs is a win, but it doesn't seem like a big win to me.
<lifeless> abentley: i just noted in passing was all
<abentley> Oh, I thought you were offering to change it.
<lifeless> abentley: yes, if you thought it was a good thing
<lifeless> but I also don't have a strong drive to do so
<abentley> This loom push thing you want me to review is actually a patch to the loom plugin?
<lifeless> yes
<lifeless> there are two folk writing loom code
<lifeless> and I like peer review
<lifeless> I've taken a short cut in fixing push; I'm hoping you'll assess whether the short cut is ok, or say 'its better to leave it broken for a bit and get a more tasteful fix'
<abentley> bb:approve I think it's a worthwhile improvement.  I suspect the wrong hook will fire, but I guess that's tolerable for now.
<pygi> hey folks
<lifeless> thank you
<abentley> re BB, I apologize for the downtime.  It messed up this morning, and I wasn't able to get it working again.
<lifeless> ouch
<abentley> It's like everything I try to improve things makes it worse.
<lifeless> is there any assistence you'd like ?
<abentley> lifeless: I'd like to see if using pgsql clears up the locking issues.  Do you know a good way to convert the data?
<lifeless> I'd probably export vis csv or similar
<abentley> Really.  Huh.
<lifeless> *via*
<abentley> I did try just doing an SQL dump.
<abentley> But it seems like pg doesn't recognize some of SQLite's escaping.
<lifeless> alternatively you could do a select & insert within python
<lifeless> I'm sure there are good toolchains to do this, I've never needed to though
<lifeless> got to love the weather
<RAOF> lifeless: It's probably different where you are than here.  Nice and sunny? :)
<poolfool_> It's dark in Denver Colorado .. but it was a nice day.
<poolfool_> To the BZR team, thank you for a great tool.
<lifeless> RAOF: loud rain
<lifeless> poolfool_: thanks!
<poolfool_> lifeless: have you thought about doing a pod cast? FLOSS with leo leport(sp) had somone from the GIT team on in January.
<lifeless> that could be interesting
<bob2> no swearing.
<poolfool_> http://twit.tv/FLOSS
<poolfool_> bob2: searing?
<poolfool_> s/searing/swearing/
 * spiv -> lunch
<igc> bbiab - picking kids up from school today
<lifeless> http://www.justdave.net/dave/2008/04/06/bugzillamozillaorg-now-in-version-control/
<lifeless> ^ cute
<lifeless> poolie: ping
<poolie> pong, the witch is dead,...
<fullermd> Phew.  That'll save me the alimony...
<lifeless> fullermd: better than 'the bitch is wed'
<fullermd> "Fornication?  But that was in another country.  And besides, the wench is dead."
<joerg_> Hi. Does anybody know what to do if I get the error message "bzrlib.errors.TokenMismatch: The lock token [...] does not match lock token (remote tokens)" while committing?  (bzr 1.3)
<lifeless> jelmer: you had someone break the lock on you
<lifeless> meh
<lifeless> joerg_: ^
<joerg_> any idea lifeless?
<lifeless> try again
<lifeless> it may be out of date
<lifeless> or if its bound it may need to be pushed at this point
<joerg_> I'm not sure what "bound" means. Do you suppose to try bzr update and then bzr commit again?
<lifeless> yes
<joerg_> docu says: "If you have a local branch and wish to make it a checkout, use the bind command like this: bzr bind sftp://centralhost/srv/bzr/X-repo/X-trunk"
<joerg_> That is not the case. Its a checkout from a branch laying on the server repo
<lifeless> k
<lifeless> just do update and commit I think
<joerg_> ok I try it. Thank you!
<poolie> spiv: steve says you were going to speak to jam about the problem of " attempt to add line-delta in non-delta knit"
<poolie> do you know what's up with that?
<spiv> poolie: No, I don't know what's up with that.
<spiv> poolie: jam thought it might be related to the critical fix we did for 1.3.1rc1
<lifeless> bye for the day
<spiv> poolie: which sounds plausible but not hugely likely to me. I don't know anything more about it.
<spiv> (if anything, I'd expect the fix we did to try insert fulltexts unexpectedly, rather than line-deltas)
<poolie> bye lifeless
<poolie> it does seem to be in a similar area
<poolie> i asked andreas to open a bug about it
<fullermd> Is the ghost issue considered serious enough to be a 1.4 blocker?
<spiv> Yeah.  I suspect it's related somehow, maybe the same root cause that caused the 1.3 regression?
<spiv> I don't think I've seen a traceback for it yet though, so it's hard to speculate.
<igc> night all
<poolie> good night
<awilkins> If you have an SSH key in launchpad you should be able to use bzr_shh to download anything from an LP bzr repo, no?
<awilkins> Or is it sftp?
<james_w> both should work
<awilkins> I'm having trouble, is there a particular form for the username?
<james_w> whatever your lp username is
<james_w> what's your lp homepage URL?
<awilkins> https://launchpad.net/~adrian-wilkins
<james_w> and which branch are you trying to fetch?
<awilkins> I've tried my email address (with @ escaped and not escaped), adrian-wilkins, all sorts
<spiv> awilkins: you should be able to use URLs like "bzr+ssh://adrian-wilkins@bazaar.launchpad.net/..."
<awilkins> Hmmph, it works with paramiko but not plink
<spiv> Ah, I don't know much about the magic to make plink work.
 * spiv -> food
<ubotu> New bug: #217650 in bzr "Use of authentication.conf causes update to fail" [Undecided,New] https://launchpad.net/bugs/217650
<awilkins> That's a regression, it should work with either
<awilkins> It used to work with plink AFAIK
<awilkins> Installing paramiko on Win32 is a PITA compared to plink as well.
<awilkins> That horizon feature would be nice around now :-)
<awilkins> What's the practice for submitting merges ; do you submit them all to bzr.dev, or do you submit them to the branch you are making them from?
<ubotu> New bug: #217666 in bzr "exceptions.MemoryError when getting http://arch.sv.gnu.org/archives/emacs/bzr/emacs.app" [Undecided,New] https://launchpad.net/bugs/217666
<james_w> awilkins: bzr.dev, unless you are making a change to something not yet merged, or fixing something on a release branch
<awilkins> james_w: It's jsut a little patch to a couple of the hidden commands to make them more consistent with bzr unknowns
<james_w> bzr.dev sounds right then.
<awilkins> Is there a mail I can bzr send to? Or do I put up a bug with a merge bundle in it?
<awilkins> (PQM is a bit much right now)
<james_w> bzr send --mail-to bazaar@lists.canonical.com
<awilkins> Groovy.
<ubotu> New bug: #217701 in bzr "attempt to add line-delta in non-delta knit" [Undecided,New] https://launchpad.net/bugs/217701
<ubotu> New bug: #217737 in bzr "bzr merge gives error over Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x01697050>"" [Undecided,New] https://launchpad.net/bugs/217737
<dwt> Morning
<dwt> I'm trying to use bzr with svn and have problems pushing to svn
<dwt> it fails with error "('Mindestens eine Eigenschafts"anderung ist fehlgeschlagen; Projektarchiv nicht ge"andert', 175008)" wich roughly translates to "at least one property couldn't be changed"
<dwt> Well, I'm quite puzzled what it means by that and am currently trying to convince it to give me a propper english response so I can search for it.
<andrea-bs> dwt: type `LANG=en_US.UTF-8` in a shell and try to push
<dwt> thanks andrea-bs - I'm trying it right now
<Bronger> How can I force a synchronisation between an SVN repo and a local Bazaar branch?  Bazaar claims that both a diverged (which is technically correct), however, de-facto both branches contain exactly the same files.  I could merge, but then I get tons of conflicts.
<dwt> Well, now it's much more talkative. I actually get a traceback and tells me that 5 should file a bug.
<dwt> well....
<dwt> The error is: SubversionException: ('At least one property change failed; repository is unchanged', 175008)
<dwt> I'm gonna google for that
<dwt> but if anybody of you can give me a hint how to debug this further, I'd love to hear it. :)
<andrea-bs> dwt: this sounds like a bug, could you please past the entire traceback on <http://paste.ubuntu.com>?
<dwt> sure
<dwt> http://paste.ubuntu.com/7133/
<dwt> It could be a bit more verbose about what property exactly it couldn't change....
<andrea-bs> dwt: it seems a repo problem rather than a bzr problem
<dwt> ok.....
<dwt> I'l test that with svn
<dwt> and see what I get
<andrea-bs> I have to go now, bye!
<dwt> thansk anyway andrea-bs
<dwt> Well, subversion works perfectly
<dwt> and I can also pull changes I got from subversion
<dwt> and merge them and everything
<dwt> though no push
<newz2000> jam: can you remind me how your push and update plugin works again?
<newz2000> never mind, I realized it runs automatically
<newz2000> :-)
<jam> newz2000: if you have it installed (the newest version) when you do 'bzr push' it should check if it is an ssh connection, and then run 'ssh host; bzr update' fo ryou
<jam> for you
<jam> newz2000: right, an earlier version required you to run 'bzr push-and-update' instead of 'bzr push'
<jam> the newest version just installs a post-push hook to do it automatically
<newz2000> nice plugin. Just what I need. :-)
<Stavros> can someone help me use bzr-svn? i can't figure it out :/
<Stavros> i do bzr branch svn://whatever and i get bzr: ERROR: Permission denied: ".": Can't get password
<jelmer> Stavros: hi
<jelmer> Stavros: See the FAQ
<Stavros> i did, hmm
<Stavros> it needed an svn info, svn up didn't cache the password
<Stavros> but now it fails with permission denied
<Stavros> :/
<jelmer> did you run "svn info" on the root url of the repository?
<jelmer> What OS are you on?
<Stavros> windows
<Stavros> i didn't, sec :/
<Stavros> apparently i don't have permission to do that
<jelmer> Stavros: Ah, it's broken on Windows atm unless you have Subversion 1.5 I think
<Stavros> i installed the patched binding
<Stavros> s
<Stavros> i can't stand svn, it bogs down my entire system to do a simple diff
<Stavros> bah, i guess i'll have to live with it...
<jelmer> Stavros: the patched bindings don't contain the required fix for this
<Stavros> is it safe to push with bzr-svn?
<Stavros> ah
<jelmer> yes
<Stavros> i ah, good
<Stavros> i don't want to much the repo up if it works eventually
<abadger1999> Hey, how would I get the reverse of "bzr diff"?
<dato> abadger1999: between two revisions?
<abadger1999> ie: the diff of working tree -> latest commit.
<dato> ah
<abadger1999> I released a package out of a modified working tree instead of a fresh checkout.
<dato> personally I'd do
<dato> b commit -m foo
<dato> b diff -r -1..-2
<dato> b uncommit
<andrea-bs> abadger1999: try with "bzr merge file.diff"
<abadger1999> dato: Thanks!  That'll work for me.
<abadger1999> andrea-bs: k.  I'll try that first
<andrea-bs> abadger1999: it works with patches generated by "bzr send" and I'm not sure if this will work also with diff output
<abadger1999> andrea-bs: bzr merge just tells me "Nothing to do."
<andrea-bs> abadger1999: patch originalfile patchfile
<foom> hey, so, is a "bzr obliterate" feature on the plan anywhere? I just had to remove some data from svn that was committed a year ago. It wasn't trivial, but it was possible, without screwing up every developer's checkout everywhere. It seems like with all the fancy DVCSes, that's simply impossible. (which is a problem)
<Noia> >.>
<Noia> whats the difference between bzr and svn
<Noia> lol
<asabil> Noia: to keep it short: bzr is better :p
<lifeless> hi jam
<jam> lifeless: hi
<jam> lifeless: have you done anything with instrumenting packs?
<jam> I've been thinking about doing a little bit of hit/miss stuff
<jam> and then my ISP decided it required authenticated sends, and I had to spend way too much time getting Postfix to properly talk to them.
<lifeless> jam: exim4 ftw :P
<jam> well, my server is currently a really old FC4 install
<lifeless> jam: no, as I said in my mail I don't have the time to do anything about it right now
<lifeless> but I wanted to share the underpinnings that seemed to be missing when folk were trying to analyse it. lsprof is good, but it can't tell right from wrong.
<jam> (the problem was that FC4 versus Breezy, and Breezy didn't recognize my SATA hard-drive card automatically)
<jam> lifeless: well you could pretty easily, if you broke up the cache hit into a separate function
<jam> I've certainly done stuff like create an inner function for loops so I can see how much time is spent in each
<jam> def run_loop_x():
<jam>   for foo in bar:
<jam>   pass
<jam> run_loop_x()
<lifeless> jam: that doesn't tell right from wrong
<jam> lifeless: that is to profile the time spent in that loop (as an example)
<lifeless> yes, but I never said lsprof can't do that
<jam> You could try something similar for cases where there is a hit versus a miss
<jam> call a different func
<jam> but I'm not sure where the time is actually spent
<jam> anyway, I understand your point
<jam> it is still hard to *time* a miss versus a hit
<jam> counting isn't hard
<lifeless> its also hard to decide if the amount of time per unit is as expected, or the number of units is as expected
<lifeless> that requires a model for the operation
<lifeless> e.g. for working tree operations we all share the model of '1 stat per file, and 1 read per file if needed'
<jam> lifeless: by the way, I think our pack => knit fetcher causes weird problems with revision_id references
<jam> specifically, I think I see it generating revisions out of order
<jam> (newest first, rather than topologically sorted)
<jam> I can say that my knit repository (which I push to from packs) has all sorts of crazy stuff going on
<jam> still technically "correct" but just improperly orderd
<lifeless> interesting
<jam> The problem is that I'm generally seeing all of this as artifacts in revisions.kndx, without actually reproducing it
<jam> lifeless:  can I have you take a peek at a line of code
<jam> Specifically line 662 of bzrlib/index.py
<jam> It seems to be mixing indices
<jam>             index = self._parsed_byte_index(location)
<jam>             # if the key is below the start of the range, its below
<jam>             if key < self._parsed_key_map[index][0]:
<jam> lifeless: if I'm actually reading a bug, then it would indicate we are not properly "bisecting"
<jam> or does _parsed_key_map[index] always match up to _parsed_byte_index
<lifeless> in the __init__
<lifeless>         # a sorted list of slice-addresses for the parsed bytes of the file.
<lifeless>         # e.g. (0,1) would mean that byte 0 is parsed.
<lifeless>         self._parsed_byte_map = []
<lifeless>         # a sorted list of keys matching each slice address for parsed bytes
<lifeless>         # e.g. (None, 'foo@bar') would mean that the first byte contained no
<lifeless>         # key, and the end byte of the slice is the of the data for 'foo@bar'
<lifeless>         self._parsed_key_map = []
<lifeless> (they use the same values to lookup
<lifeless> its not a single map to a tuple because of bisect needs
<lifeless> oh, where is my cleanup of this code
<lifeless> I have a branch that introduces an abstraction here
<lifeless> pushing it now
<ubotu> New bug: #217917 in bzr ""bzr commit" MemoryError crash" [Undecided,New] https://launchpad.net/bugs/217917
<lifeless> jam: whats an operation thats still problematic ?
<goozbach> Quick question: I couldn't find an answer in the bzr user guide.
<goozbach> I want a "pushed" branch to always have the current contents
<goozbach> eg, I run bzr push from my laptop, and want the pushed location (a web accessable directory on a server) to automatically update
<jam> lifeless: well 'bzr status' after a pending merge, but that is bad for other reasons :)
<mwhudson> goozbach: the push-and-update plugin can do that
<goozbach> is this possible without creating a hook
<jam> a simple 'bzr log' on a very long history is bad
 * goozbach googles
<goozbach> mwhudson: thanks
<jam> lifeless: 'time bzr log --short -r -10..-1 bzr.dev' is quite a bit longer than it should be
<jam> goozbach: cd ~/.bazaar/plugins;  bzr branch lp:bzr-push-and-update push_and_update
<jam> (possibly with a mkdir -p ~/.bazaar/plugins first)
<goozbach> jam: just got it
<goozbach> thanks though
<jam> goozbach: it will update if it detects that the remote location has a working tree, and you are connecting over sftp or bzr+ssh
<jam> it won't do it if you are using ftp etc
<goozbach> yay!
<lifeless> jam: 2.5 seconds for me
<goozbach> hooray for not re-inventing the wheel
<goozbach> thanks guys
<jam> lifeless: yeah, but it used to be <1s
<lifeless> k
<goozbach> I knew I wasn't the only one who wanted that to happen
<jam> goozbach: it does require that you have bzr installed on the remote machine, and have regular 'ssh' access
<jam> in case that matters
<jam> (it basically just calls 'ssh host bzr update' for you)
<jam> lifeless: 'bzr log --long -r -10..-1' would also be even worse, I just never use it
<jam> --long is going to do a whole revision-graph search because of dotted revnos
<goozbach> jam: it's working.
<goozbach> I was mostly wondering if someone else had done the legwork
<goozbach> yay!
<jam> goozbach: yep, I'm glad it works for you, feel free to post bugs, etc.
<jam> it is pretty simple, though, so I don't expect you would have problems.
<jam> I suppose I should now trap into the 'branch_changed_revision' hook in 1.4, so that it will also work if you have a checkout of the public location, rather than only on push
<spiv> Good morning.
<jam> morning spiv
<igc> morning
<igc> morning jam, spiv
#bzr 2008-04-16
<thumper> morning spiv, jam, igc ;-)
<mwhudson> boo merge --uncommitted doesn't work over ssh
<mwhudson> i'm not surprised, though
<lifeless> heh
<poolie> beuno: hi
<poolie> igc: ping
<igc> hi poolie
<lifeless> spiv: I think we should talk abot get_data_stream
<poolie> tim just forwarded me the patch to fix https://bugs.edge.launchpad.net/launchpad/+bug/181157
<ubotu> Launchpad bug 181157 in launchpad "Product series should have a status (like distro series)" [Medium,Confirmed]
<spiv> lifeless: ok
<lifeless> spiv: I think I know where a bunch of problems are comng from
<poolie> can you look at that quickly and tell me either any other values you think should be allowed, or anything else that comes to mind
<igc> poolie: sure
<lifeless> spiv: voice or irc?
<spiv> lifeless: whichever suits you best
<poolie> hello spiv, lifeless
<spiv> I'm happy either way.
<lifeless> ringing you
<lifeless> ok, false alarm; its not the cause of the bugs we're seeing
<lifeless> hi poolie
<poolie> igc: can you please just look at that quickly now, i want to reply to tim
<igc> commenting on the bug right now
<poolie> oh cool, thankyou
<igc> poolie: done
<igc> I think we want one more status now - Pending Release (or Frozen to mirror the distro name)
<igc> "Future" or Experimental might be good as well but I'd leave it out until we explicitly need it
<igc> i.e. some project asks for it
<beuno> poolie, hey
<poolie> hi beuno
<poolie> igc, hm
<poolie> so this is like a subcategory of active development?
<poolie> oh i see
<poolie> so 1.4 would be in that state now, and 1.5 would be active development?
<beuno> poolie, just got home, so I'll be on and off while I run errands. Do you want to talk now or would it be better for you later on?
<igc> poolie: that's right
<Kamping_Kaiser> hi all. is there a list of what environment variables/bazaar.conf options are available?
<Kamping_Kaiser> also, is last push path remembered like last merge path? (eg per repository?)
<spiv> Kamping_Kaiser: bzr help env-variables
<spiv> Kamping_Kaiser: bzr help configuration
<Kamping_Kaiser> spiv, ok, thanks
<spiv> Kamping_Kaiser: (also at http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#configuration-settings and http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#environment-variables)
<spiv> Kamping_Kaiser: the first time you push, it remembers the path.  You can overwrite the remembered path by passing "--remember" to push.
<Kamping_Kaiser> spiv, sounds the same. thanks again :)
<spiv> Not a problem
<Kamping_Kaiser> of the two help outputs i assume configuration is authoritive? it lists items env-variables doesnt
<spiv> Hmm, that's a bug.
<spiv> But afaik, all the items in the 'configuration' help topic do exist.
<Kamping_Kaiser> BZR_PROGRESS_BAR BZR_SIGQUIT_PDB BZR_PDB are listed in config but not env-var
<Kamping_Kaiser> bzr1.3, btw.
<Kamping_Kaiser> they both give quite different output it seems
<Kamping_Kaiser> "DEFAULT" isnt the only header currently supported by bzr is it? (ALIASES works too?)
<spiv> Kamping_Kaiser: you mean sections in the bazaar.conf?
<Kamping_Kaiser> spiv, yeah.
 * jml frowns
<jml> ubuntu is telling me that I can't upgrade bzr without removing bzrtools
<spiv> Kamping_Kaiser: sounds like a bug in the docs.
<jml> this seems to happen a lot.
<Kamping_Kaiser> spiv, ok :(
<lifeless> jml: its a ppa feature
<jml> lifeless: I'm sceptical.
<RAOF> Yeah; when is a 1.4-compatible bzrtools/bzr-svn likely to be uploaded there?
<spiv> Kamping_Kaiser: I've sent a quick patch to fix it to the list
<spiv> Kamping_Kaiser: thanks for letting us know
<spiv> jml: "feature"
<lifeless> jml: what happens is that the bzr < current upload is immediately removed
<lifeless> jml: hilarity then ensues
<jml> and there's no workaround?
<Kamping_Kaiser> spiv, NP. i was worried you were going to tell me to write the patch myself ;)
<spiv> Kamping_Kaiser: you can if you really want to ;)
<RAOF> jml: You can just not upgrade bzr.
<Kamping_Kaiser> spiv, i really dont. *grin*.
<jml> RAOF: this a bit of a pain.
<RAOF> The current bzrtools depends on bzr < 1.4~.  The PPA contains bzr 1.4rc1, and 1.4rc > 1.4~
<RAOF> jml: Does current bzrtools work on 1.4?  If it does, you probably have the permissions to upload a bzrtools to the PPA with relaxed dependencies.  If not, we're preventing you from accidentally breaking bzrtools.
<lifeless> RAOF: bzrtools is version locked
<lifeless> RAOF: apt can resolve conflicts better if 1.3 is kept in the archive
<abentley> RAOF: Not to mention the fact that even if started at the same time, bzrtools 1.4 and bzr1.4 are unlikely to enter the archive at the same time.
<lifeless> abentley: in fact they can't
<lifeless> abentley: as there is a build sequence constraint
<abentley> Okay,  *very* unlikely :-)
<RAOF> Maybe I'm spoilt by aptitude.  That handles this case just fine.
<lifeless> :P
<abentley> It handles the case where bzrtools requires bzr 1.3 and only bzr 1.4 is available?
<RAOF> abentley: But bzr 1.3.1~rc1 *is* available.
<lifeless> abentley: it offers different resolutions
<lifeless> RAOF: not in the ppa its not
<RAOF> Just not from the PPA.
<RAOF> But that's not jml's problem.
<lifeless> jml: what release are you on, and do you have backports enabled?
<jml> lifeless: hardy.
<jml> lifeless: not sure how to check for backports.
<RAOF> Does'nt matter, there aren't any yet.
<lifeless> RAOF: would for gutsy :P
<lifeless> jml: for reference grep backports in /etc/apt/sources.list
<RAOF> lifeless: Yeah, but I know he's on Hardy :)
<lifeless> poolie: ping; removing deprecated methods question on the list; would like a reply :P
<jdobrien> Im working on a bug Mentored by LastiQ who is in bed...could anyone help for a WorkingTree4 question?
<jdobrien> sorry..LarstiQ Wouter
<lifeless> sure
<jdobrien> I am working on adding a switch which will output relative paths ../path/to/file/filename.py instead of the stripped out paths from bzr stat (and the like)
<jdobrien> unfortunately, (as far as i can see) at the point the stripped out paths are output, there is no indication (like a global varable) where the working path is
<jdobrien> aka WorkingTree4.basedir
<jdobrien> fyi, this is a learning project for me...been doing c,c++ for 15 year...python for 15 days
<jdobrien> this is the 'bug' https://bugs.launchpad.net/bzr/+bug/30159
<ubotu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed]
<jdobrien> yeah IMO...there may be to many side-effects changing the default behaviour
<jdobrien> but i was thinking "bzr status --relative" would probably work
<jdobrien> simple change if i know the basedir when in delta.py
<lifeless> jdobrien: look at status.py
<jdobrien> yeah
<lifeless> jdobrien: iter_changes outputs paths from the root fo the tree
<jdobrien> problem is, it strips out the basedir
<lifeless> yes, thats the correct internal representation
<lifeless> I think you want to do the change at output time only
<jdobrien> yeah
<lifeless> so in ChangeReporter
<lifeless> and the Delta class for old-style status
<jdobrien> k, which still brings me to the question...is the basedir in a global setting so i could calculate the relative path base on cwd?
<jdobrien> it's not passed into change reporter...i could always get it again
<lifeless> I would add a method on Delta to set the cwd
<lifeless> and a parameter to ChangeReporter I think
<lifeless> no there is no global, because in general it doesn't exist
<jdobrien> oh crap
<lifeless> on windows for instance its not per-thread
<lifeless> on most unixes its per-thread
<jdobrien> i missed it...it's passed into show_tree_status
<jdobrien> <---------------idiot
<lifeless> but when used as a library cwd is not ours to fool with
<lifeless> wt is passed in, but not cwd
<lifeless> the paths are already relative to wt
<jdobrien> in this instance, wouldn't it be safe to get get the actual path (wt.basedir + path) and calc relative path based on cwd
<jdobrien> on output only
<lifeless> you need to pass the path to normalise against in though
<jdobrien> yes
<lifeless> as in, getcwd() isn't something library code should be calling
<jdobrien> no
<lifeless> to get the abspath, use wt.abspath(relpath)
<jdobrien> thanks
<jdobrien> not sure how this would work/break if basedir was not a physical dir
<lifeless> :P
<jdobrien> thanks for the help
<jdobrien> bill this hour to wouter
<lifeless> bug 218023
<ubotu> Launchpad bug 218023 in pqm "Use textwrap.dedent to make multiline strings more readable" [Undecided,New] https://launchpad.net/bugs/218023
<lifeless> yay tests pass
<jdobrien> time for a beer
<lifeless> maybe in the evening :P
<jdobrien> 11:55 here USA FL
<lifeless> ITYm 2355 :P
<lifeless> 1355 here
<lifeless> time for /wave
<lifeless> poolie: good progress, I have the output stuff ~= correct
<lifeless> adapters tomorrow
<jdobrien> thanks for the help
<Kamping_Kaiser> can bzr count the lines in a diff? i have a command "$(bzr diff $1 2>/dev/null |wc -l)", and i'm wondering if |wc -l is strictly necesary
<spiv> I usually use "bzr diff | diffstat" myself :)
<bob2> there's a "bzr diffstat" plugin, too, for the minimal typing saving
<thumper> lifeless: it appears in 'bin/pqm' there is an expectation that --config must be set, but the code seems to indicate that it is to specify a non default config file
<thumper> lifeless: aarrrggghhhh
<thumper> lifeless: I found out why I thought that
 * thumper wipes the unclean feeling away
<ubotu> New bug: #218068 in bzr-svn "Pushing to SVN, SubversionException: "File ... already exists"" [Undecided,New] https://launchpad.net/bugs/218068
 * igc dinner
<jimcooncat> are there any good tutorials out there for using bzr for website development? Google's failing me on this.
<poolie> hm i'm not sure
<poolie> people seem to do it a lot
<jimcooncat> I'm not a dummy, but I can't wrap my head around how it works
<jimcooncat> must be a gui tool I can use to walk me through it, should I get a gedit extension or something?
<jimcooncat> bzr-gtk?
<poolie> jimcooncat: can you please send mail with your questions to bazaar@lists.canonical.com and i'm sure someone will help you out
<poolie> unfortunately i have to go in a sec
<jimcooncat> thanks poolie
<visit0r> hello is there a way to set a file to be treated as a binary? it seems bzr diff detects one of our pdf as text due to some ascii lines in the beginning of it.
<ubotu> New bug: #218115 in bzr "corrupt: attempt to add line-delta non-delta knit" [Undecided,New] https://launchpad.net/bugs/218115
<quicksilver> visit0r: that's a really good question and I'm surprised I don't know the answer
<Kamping_Kaiser> i seem to recall there was a flag to merge that allowed it to resolve conflicts better. i cant see that option looking at its help now - have i missed it or was it removed?
<Stavros> hello
<Stavros> how does bzr-svn work with bzr branches?
<visit0r> quicksilver: ok, I'll open a bug
<bob2> Stavros: how do you mean?
<Stavros> bob2: if i have many branches on my local disk, do i have to merge before committing back to svn? does it make svn branches?
<ubotu> New bug: #218128 in bzr "some binary files detected as text: provide a way to flag files binary?" [Undecided,New] https://launchpad.net/bugs/218128
<bob2> Stavros: you can push from a bzr-svn bzr branch to svn, yes
<Stavros> yes, but how will this affect my other branches?
<Stavros> will i need to pull to them again?
<igc> night
<jam> Kamping_Kaiser: there are a couple, --reprocess and --lca are the recommended ones
<jam> (you can also use "bzr remerge --lca foo" to not have to redo the whole merge again)
<jam> Kamping_Kaiser: --reprocess reduces the size of the 3-way conflict chunks by finding lines that are common to both sides
<jam> --lca uses a different merge algorithm that usually does better when you have a criss-cross merge, or other more involved history.
<Kamping_Kaiser> jam, then --reprocess is probably the one thats good for aliasing to merge
<jam> Kamping_Kaiser: correct, I've often thought it should be default
<jam> I think the only reason it wasn't is because it conflicts with --show-base
<jam> (if you remove the common lines, then you don't have the context to show the base lines correctly.)
<Kamping_Kaiser> bzr conflicts drive me crazy :( i prefer svns. if --reprocess makes it less anoying i'll be a verry happy person ;)
<jam> Kamping_Kaiser: try it out and let me know. I think most systems use the "--reprocess" form by default
<Kamping_Kaiser> jam, not sure when i'll face a conflict next ;) but i'll try to remember
<Kamping_Kaiser> thanks for the help :)
<ubotu> New bug: #218191 in bzr "paramiko.SSHException: Server connection dropped" [Undecided,New] https://launchpad.net/bugs/218191
<ubotu> New bug: #218206 in bzr "Pending-deletions error message" [Undecided,New] https://launchpad.net/bugs/218206
<guilhemb> jam: hi! I was reading your lines above about --reprocess and --lca; from them I guess that using --reprocess and --lca in the same "bzr merge" command does not make sense?
<LeoNerd> So.. Suppose I wanted to make a "bzr sync" command which is like pull or push, whichever it finds is appropriate. Is there some example command plugin, or some doc somewhere that explains how to make a plugin?
<jam> guilhemb: I'm not sure, but I think that the style of how --lca works means that there is no need to --reprocess
<jam> You are  welcome to try both
<jam> I don't think it will break anything, just that --lca doesn't leave any lines to be reprocessed
<guilhemb> jam: ok, thanks
<abentley> jam, guilhemb: Yes, --lca implicitly does --reprocess.
<guilhemb> abentley: thanks for the info
<abentley> guilhemb: np
<moquist> I'm working on a project with one other developer. We both work remotely on multiple laptops and move around a lot. I've run 'bzr init-repo ./' and 'bzr init' in the project directory on our ssh server, so we can both run 'bzr checkout sftp://ourserver/path/to/project/' to get a local checkout from which commits can be made to the central repo.
<moquist> How can/should I create a centralized 'working' branch (not sure about my terminology) where I can commit broken code from machineA so I can 'bzr update' on machineB tomorrow and keep working, and then commit to our shared repository when my new feature is working correctly?
<moquist> I think I've made progress here. I can checkout from the shared repository to my own centralized...Thing, create a branch of my centralized Thing on each of my dev systems, and 'bzr push sftp://server/Thing' from each centralized system. Then I can 'cd Thing; bzr update; bzr commit' on the server.
<awilkins> moquist: You shouldn't need a commit after an update (unless you've changed the content)
<LeoNerd> Scripting question... Given two branch objects, is there an easy way to tell if one is an ancestor of the other?
<LeoNerd> I.e. if I should push/pull in one direction
<jam> LeoNerd: well, 'bzr missing' I thought would give that info
<jam> I think it might be slower than it needs to be ATM
<jam> be back in a bit
<LeoNerd> Yes.. sorry.. by "scripting", I mean "I'm writing a plugin"
<LeoNerd> (to anyone else): I can tell if they're identical by comparing branch1.last_revision == branch2.last_revision
<LeoNerd> I presume one is an ancestor of the other if one's last_revision appears somewhere in the history of the other?
<sabdfl> is 1.3.1 due to go into hardy?
<james_w> sabdfl: I thought it was already there
<james_w> or it may have been that the single patch that went in to 1.3.1 was added to the hardy package.
<james_w> ah, it's 1.3.1~rc1-0ubuntu1, and there were no code changes between the rc and final for 1.3.1
<sabdfl> james_w: can we fix the version number, then?
<james_w> probably, I'll submit a patch for approval from the release team.
<abentley> LeoNerd: Ancestry, not history in particular.
<LeoNerd> Right..
<LeoNerd> Should I look for the code that implements the "bzr missing" command, perhaps? That sounds likely to be doing similar tests
<abentley> Probably not.
<abentley> If you just want to know whether one branch is the ancestor of the other, you can determine that cheaply.
<abentley> I.e. with Graph.is_ancestor or Graph.heads
<LeoNerd> Well, I'm writing a command that's basically missing => {push/pull/complain/nothing}
<sabdfl> thanks james_w, please let me know the RM response and status
<james_w> sure
<LeoNerd> So... perhaps it's sufficient to see if either branch can map the other's head revision into a revno
<LeoNerd> ?
<LeoNerd> Since at least one is guaranteed to fail
<james_w> LeoNerd: get the two tip revisions, compare them for equality => do nothing
<james_w> a in b's revision_history() => pull
<james_w> b in a's revision_history() => push
<james_w> otherwise error
<james_w> I think that should work
<LeoNerd> Yes.. it was the being "in the history" that confused me
<LeoNerd> I've already done the first equallity one
<james_w> ah, no, sorry, that only looks at mainline revisions.
<dato> but I don't think you can't pull if your head is not a mainline revision of your parent, no?
<dato> s/can't/can/
<james_w> hi dato
<james_w> if your parent merges from you, then the tip of your branch will be the right hand parent of the paren't branch's tip, and you would be able to pull wouldn't you?
<beuno> abentley, thanks for the amazing response to the show-author-on-commit patch, I haven't responded as I'm working on it, but I really appreciate how thorough it was  :)
 * lamont considers campaigning for bzr 1.3.1 in hardy, wonders what the support level from this channel is
<lamont> rather, how much support for the campaign he can count on...
<dato> lamont: see a bit of backlog above, between james_w and sabdfl
<dato> james_w: I'm not sure anymore :) (sorry, I missed your line at the time)
<lamont> james_w: if 1.3.1~rc1-0ubuntu1 == 1.3.1-1, I'd be happy to do the upload, assuming it's approved...
<LeoNerd> http://paste.leonerd.org.uk/?show=2184  <== my "bzr sync" command plugin. Anyone any comments?
<james_w> lamont: the diff is trivial, I'm testing now, and then I'll seek permission from the release team
<james_w> lamont: thanks for the offer though, I may well take you up on that if it gets approved
<lamont> james_w: no worries - it's blocking some testing that I'm doing, since them machines in question have bzr_1.3.1-1~$mumble installed
<lamont> and the end result is a very annoyed and failing do-release-upgrade
<dato> james_w: ah, right, it does that thingy of making your last commit not-mainline
<lamont> james_w: my technique is to just upload and then explain why. :-)
<james_w> lamont: oh yeah, I'd forgotten everything was frozen so that was possible
<lamont> :-D
<james_w> lamont: this upload would be 1.3.1-0ubuntu1, would that solve your problem?
<lamont> is this an upload to debian, or to ubuntu?
<lamont> no.
<dato> hm
<lamont> >>1.3.1-1~CAT.6.06
<dato> I guess I could upload to debian
<james_w> I was going for Ubuntu, but we could upload to Debian and sync
<dato> I didn't, because 1.4~rc1 was around the corner
<lamont> hrm...
<james_w> dato: if you've got the time, that would be great.
<lamont> dato: are you the normal uploader to debian?
<dato> but rc1 turned out unsuitable for upload, so I ended up uploading none
<dato> lamont: yes
<lamont> sync is pain these days...
<lamont> how about 1.3.1-1 to debian, and 1.3.1-1build1 to ubuntu and lots of handwavy bits about why 'build' is correct
<james_w> we could fake-sync, or -1build1 one it
<lamont> ^5
<lamont> fakesync would be bad.
<lamont> but we want the orig.tar.gz files to be the same both places
<james_w> yeah, that would work, it may make the release team think about it a bit more though.
<james_w> true
<lamont> nah - I'm happy to deal with release team... they're used to my craziness
<james_w> :-)
<james_w> lamont: are we best to just subscribe the release team to the bug and then deal with the actual upload when we have the ACK?
<dato> oh
<james_w> I can provide the upstream diff that we want to incorporate.
<dato> first bzr upload with python 2.5
<dato> not that it really matters
<james_w> dato: it's been 2.5 on Ubuntu for a while, so it should be fine.
<lamont> is there abug?
<lamont> if we just upload 1.3.1-1build1 to hardy, we don't need a bug
<james_w> a non very eloquent one: bug 218257
<ubotu> Launchpad bug 218257 in bzr "Update bzr package to a non-release-candiate version number" [Undecided,New] https://launchpad.net/bugs/218257
<james_w> I was going to expand on it when I had the patch.
<james_w> this would be my first upload-new-upstream-version-to-main-during-final-freeze upload, so I'm still feeling my way around
<lamont> that works.  the other big decision-fork is that if the bits are in debian within the next 45 min or so, there's a very good chance they'll make today's dinstall run, if not -> tomorrow.  to sync them, it's best if the mirrors have had a chance to do their thing
<lamont> if we just upload to hardy, then it's click-to-approve for the release manager
<dato> lamont: it'll be <45min
<dato> wow, what's all this crap pycentral now spits
<lamont> dato: it doesn't spit it, it excretes it
<lamont> james_w: if we know that the same .orig.tar.gz will be used by both uploads, then we can actually upload ubuntu ahead of debian if we want, and I can get back to testing,... :-)
<james_w> dato: is that the "diff" stuff?
<dato> ye
<dato> s
<james_w> it looks like debugging output to me
<lamont> in the ideal world, we want dato's package for debian, with about 5 lines of change in changelog (for -1build1) and an upload...
<lamont> james_w: are you core-dev, or who does your ubuntu uploads?
<james_w> yep
<lamont> ah, cool
<james_w> we need to sync first though?
<lamont> not if we're really really really diff from 1.3.1-1 in only the changelog
<james_w> ah, no, I'm not core-dev, it was your previous statement I was agreeing with
<lamont> ok.  /me is happy to sponsor... so when you/dato are happy with 1.3.1-1 for debian, if I could have a copy of it, I'll smack it into hardy
<james_w> I'm testing 1.3.1 now, so when dato's got the package I should have finished testing
<lamont> \o/
<dato> good lord
<dato> my wireless here sucks
<dato> uploaded nevertheless
<james_w> dato: thanks.
<lamont> dato: got a pointer to your bits?
<dato> yes, http://people.debian.org/~adeodato/tmp/2008-04-16/bzr/
<james_w> :-)
<james_w> lamont: it's passed a selftest here, and stood up to a few minutes use
<james_w> unfortunately I don't have any real work to do in bzr at the moment, so I can't test that.
<lamont> james_w: that's more than my testing before I deploy...:0)
<james_w> :-)
<james_w> lamont: would you like me to do anything with the bug, or is it superfluous now that we have you to prod the release team?
<lamont> oh.  whichnumber?
<james_w> 218257
<lamont> stupid wireless
<lamont> james_w: the upload will close it
<lamont> sigh.  diff orig.tar.gz than the bazaar-vcs download page.
<dato> uh
<lamont> dato: or did you already upload?
<dato> lamont: I used a pristine tarball
<lamont> nfc what poolie used then
<dato> https://launchpad.net/bzr/1.3/1.3.1/+download/bzr-1.3.1.tar.gz <-- link obtained from http://bazaar-vcs.org/Download
<dato> lamont: err
<lamont> hrm
<dato> lamont: when james_w said 1.3.1~rc1-0buntu1 is 1.3.1-1
<lamont> no matter - I'll make sure your .dsc unpacks.
<dato> he meant there were no code changes
<dato> not that the tarball were identical
<dato> poolie used the rc1 tarball, I guess :)
<lamont> 5a2160e057d79288c186c42567aa0dc2  ../bzr_1.3.1.orig.tar.gz
<lamont> he used _that_ one. :-)
<dato> that's the one I uploaded
<lamont> oh right
<lamont> 2c560167aea6c8bde7cfaf7883d267dc  ../../bzr_1.3.1.orig.tar.gz
<james_w> yeah, sorry, there was a NEWS entry, and the version number was changed, but there were no changes to the meat of the code.
<lamont> off by one error
<lamont> testbuilding nwo
<lamont> dh_python -pbzr
<lamont> dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file.
<lamont> heh
<dato> yay cdbs
<lamont> in my mind cdbs is still filed under "slightly less evil than dbs;"
 * lamont goes to talk to the nice folks in #ubuntu-release
<tolstoy> Folks, I'd like to try the fastimport plugin with the cvs2svn plugin, but there's no documentation on the options to use with cvs2svn.
<tolstoy> Do I output to a dumpfile?
<tolstoy> I've seen this: includes an option now for the required output format. Python. But I don't know what that option is.
<lamont> james_w: it'll get accepted post-RC :-(  so fridayish sometime
<tolstoy> cws2svn --dumpfile=app.dump ;; then cat app.dump | bzr fast-import -
<tolstoy> Doesn't seem to work.
<james_w> lamont: ok, thanks
<james_w> tolstoy: does cvs2svn output in the fast-import format?
<abentley> beuno: You're welcome.  Hope it's helpful.
<trepca> hey
<trepca> i have a project that consist of many small projects
<trepca> how would i best organize it with bzr
<trepca> in git there are superprojects
<trepca> you can link to other repositories in them
<trepca> wow, this channel is brimming with life :)
<lifeless> trepca: sure is
<james_w> trepca: bzr will have nested trees that are like subprojects, but they are not ready yet
<james_w> hi lifeless
<trepca> ok, thanks
<trepca> i could create a huge repository as in SVN that would hold all those projects ... but that is probably not optimal for bzr ?
<james_w> yeah, that's not great
<tolstoy> james_w: Sorry, I was out to lunch!  I don't know if it outputs in that format. No command-line switches suggest that it does.
<tolstoy> james_w: But the docs at bazaar-vcs suggests that it does.
<james_w> tolstoy: I don't think that it does
<james_w> ah, maybe I'm wrong, have you got a pointer?
<tolstoy> Hold on....
<tolstoy> http://bazaar-vcs.org/BzrFastImport/FrontEnds
<tolstoy> I'm using the macport version, which might be the problem.
<tolstoy> Hm. I'm using version 2.1.0, but there's a 2.1.1 available as a tarball on their website.
<james_w> "includes an option now for the required output format"
<tolstoy> Right.
<james_w> "now" suggests it is new, so the new version may be needed
<tolstoy> And that's all I can find on the subject.
<tolstoy> Hm. I wonder if the Mac DMG install of BZR contains the bzr subversion plugin.
<trepca> i does not
<trepca> it
<tolstoy> Alas, no, it seems not to.
<xxxYURAxxx> how to configure bzr-email to send emails?
<lifeless> 'bzr help email' should contain enough info
<xxxYURAxxx> thanks
<ubotu> New bug: #218406 in bzr-gtk "olive-gtk.desktop lists incorrect categories" [Undecided,New] https://launchpad.net/bugs/218406
<LeoNerd> Hrm.. It seems I can ssh an alias in my .ssh/config, but I can't bzr push sftp:// it
<LeoNerd> Can't bzr+ssh:// because the host doesn't have bzr installed
<igc> morning
<VSpike> I'm probably missing something obvious here but when I just did a bzr checkout, it created the last directory in the remote path.  i.e. I did bzr checkout sftp://home/blah/bloo/main and it created ./main and filled it with stuff... other times, I'm sure the files have ended up just in the directory I run checkout.  What causes the different behaviour?
<lifeless> VSpike: the only time chekcout creates the files in '.' is when you use 'bzr checkout .' to create a tree on a treeless branch
<lifeless> going for a walk to think about apis
<VSpike> I keep getting the message No handlers could be found for logger "bzr"
<james_w> VSpike: run "bzr --version", and it should say "Bazaar log file: " check that the path there is writeable by your user
<VSpike> ahh.. spot on.  I see the problem.  I ran bzr with sudo the first time I used it
<james_w> that's usually the problem, however the patch I wrote to detect it and explain it to the user was far from appetising.
 * fullermd skips the obvious 'byte' puns.
<VSpike> james_w: thx
<BasicOSX> Can you specify multiple email address on a post_commit_to ?
<thumper> morning lifeless
<thumper> lifeless: as you'll no doubt soon be aware, I've posted a branch for using optparse for PQM as part of the clean up for bug 218416
<ubotu> Launchpad bug 218416 in pqm "PQM has too much config in global scope" [Undecided,New] https://launchpad.net/bugs/218416
<LeoNerd> I asked earlier but didn't see any reply. I've written a push-or-pull command called "sync". Does anyone have any comment? ==> http://paste.leonerd.org.uk/?show=2184
<thumper> LeoNerd: I've not looked, but what happens if they are both different?
<LeoNerd> It prints "Sorry, they diverged" and stops
<LeoNerd> The intention is: If they're identical, it does nothing. If one is an ancestor of the other, it will push/pull in the right direction. Otherwise it complains.
<abentley> LeoNerd: I still think your test is wrong.
#bzr 2008-04-17
<spiv> Good morning
<LeoNerd> abentley: OK... could you suggest a better one?
<poolie> hello
<poolie> spiv, igc call now
<abentley> already did: Graph.is_ancestor or Graph.heads.
<LeoNerd> Yes, but I don't know anything of bzrlib. That sounds like an abstract data set sort of thing... how do I hook that up?
<LeoNerd> Perhaps you could rewrite my ancestor_of() function?
<abentley> branch.repository.get_graph().is_ancestor()
<LeoNerd> Hmm.. OK.. I'll try that out
<abentley> using heads is actually better, because it will tell you which one is the ancestor or else tell you that they are diverged with one call.
<abentley> If you get two results for a heads call, they are diverged.  If you get one head, it is the descendant of the other.
<LeoNerd> From what "heads" call..?
<abentley> Graph.heads
<LeoNerd> But surely each branch individually will only have one head?
<LeoNerd> Which is surely just the last_revision ID?
<abentley> Graphs represent the revision graph of the repository.
<abentley> They have no direct relationship to the branch.
<LeoNerd> Yes. But we're comparing two branches here, each with its own repository. (I hope - the point should be they're on different machines)
<LeoNerd> The idea is I put this in cron.daily between my two machines, to keep my repo. backed up
<abentley> Graphs may also represent the combined revision graph of two repositories.
<LeoNerd> Ah. See, I hadn't got that bit
<abentley> You just do branch.repository.get_graph(other_branch.repository)
<LeoNerd> Right. and that's the combined one?
<abentley> Yes.
<LeoNerd> I suppose symmetrically, so it doesn't matter which I really call
<abentley> This is true, but there are performance implications.
<abentley> other_branch should be the remote branch, if possible.
<LeoNerd> OK
<LeoNerd> Hm. I may play with that tomorrow instead in fact.. it's getting quite late
<poolie> beuno: hello?
<beuno> poolie, morning  :)
<lifeless> poolie: did you put that sketch-of-a-debconf-talk together and I missed it ?
<poolie> lifeless: no, it never got to the top of my queue :/
<lifeless> I have a design problem
<lifeless> I think I'm being overly generic
<lifeless> actually, I'm wrong, I'm not. It was just the order I was writing a test in.
<Noia> ok, I've installed bzr on my ubuntu server
<Noia> how to I interact with it from my mac?
<bob2> install bzr on your mac
<Noia> ohai bob2
<Noia> I'm trying to set up a repo system on one of my servers and its the first time I'm using bzr and  I wouldn't say I'm too accustomed to working with things like this (except tortoise SVN)
<Noia> ok so I have bzr on my mac and my server...how do I set up the repo on the server and sync them ?
<poolie> Noia: did you read http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html ?
<Noia> I read the really skinny guid
<poolie> so, basically
<poolie> use bzr push, pull and merge to move changes between your mac and your server
<Noia> I need to do something like this though right?
<Noia> bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk
<bob2> to initially branch it onto your machine, yes
<Noia> do I need to set up anything specific on the server side or does it just use the file system?
<poolie> Noia: if you use sftp it will just use the filesystem
<Noia> ok
<poolie> if you use bzr+ssh you need to install bzr on the server, but no more
<rolly> and ssh :)
<Noia> I've got bzr on the server
<Noia> I just don't get this thing though >.<
<Noia> I've used CVS and SVN before but SVN was through tortoise, so I'd hadly say it was difficult, and CVS was some years ago now
<Noia> so I'm getting quite confused >.>
<bob2> which bit don't you get?
<abentley> Noia: Repositories are not a central concept in Bazaar.  They provide a space optimization, but they are not a necessary step.
<Noia> getting the workflow going seems awefully complex
<Noia> abentley, yea thats sort of different
<abentley> It seems like you are expecting to do more than you actually have to.
<bob2> so, you have a branch on a remote server.  "bzr branch sftp://blah" creates a branch of that on your local machine.  you update your local branch with remote changes with "bzr pull", you push changes back with "bzr push"
<Noia> alright
<Noia> since I'm running bzr on the server, would it be preferable to run bzr through ssh rather than sftp ?
<Noia> I suppose that might yield better user control since you can spec it against the ssh login
<foom> yes, it'll be faster too, since it'll use the "smart server"
<Noia> hmmm
<Noia> alright, how do I set that up?
<bob2> is 'bzr' in your PATH on the server?  ie does "ssh host bzr version" work?
<Noia> if I ssh in and type bzr version then it works yes
<bob2> you can probably just use bzr+ssh:// instead of sftp:// then
<Noia> ok
<Noia> so er....how? lol
<bob2> bzr branch bzr+ssh://blah/blah
<Noia> error, not a branch
<lifeless> Noia: what exact path are you using, if I may ask ?
<Noia> I'm using /repo/noia
<Noia> repo is 0777 noia is chown to noia, the user I'm sshing into
<lifeless> you're not using ~ in there at all ?
<Noia> nope
<lifeless> ok, thats weird
<Noia> I saw the bug :)
<lifeless> and sftp works ?
<Noia> not tried sftp
<Noia> but I can ssh in, it asks for password so
<spiv> And "bzr ... bzr+ssh://..." asks for a password too?
<lifeless> have you created a branch?
<lifeless> (repositories are not branches, they contain branches)
<Noia> spiv, yes it asks for a password
<Noia> lifeless, er...no?
<Noia> I've only run bzr branch bzr+ssh://....
<lifeless> then it is unsurprising that you get NotABranch :P
<Noia> lol
<Noia> alright, what am I doing wrong >.<
<spiv> Noia: "bzr branch" makes a copy of a branch, it doesn't create one.
<spiv> Noia: so if you don't have a branch yet, it'll give the "not a branch" error :)
<Noia> oh
<Noia> durr -_-
<spiv> "bzr init" makes a branch
<Noia> Branched 0 revision(s).
<Noia> w00t
<Noia> It wont work! waaaaaah
<Noia> so I've got my remote repo, and I've branched to it, and I've got my local repo and I've init'd them both, and when I use bzr commit, it asks for server side password, but it doesn't push any data. When I run bzr push, it says theres no location specified to push to
<Noia> did I miss something?
<lifeless> it sounds like you want to work like cvs
<lifeless> or sv
<lifeless> to do that
<lifeless> just do 'bzr checkout bzr+ssh://host/repo/noia/branch localpath'
<lifeless> cd localpath
<lifeless> do stuff
<lifeless> bzr commit
<lifeless> but that said, what do you mean 'it doesn't push any data' ?
<Noia> Committing to: bzr+ssh://noia@nodetoad.com:2200/repo/noia/
<Noia> bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
<bob2> you need to make some changes before there is any point committing...
<Noia> I've added folders and files >.>
<bob2> as in "bzr add filename filename folder"?  does "bzr status" show them as "A"(dded)?
<lifeless> we have quickstart documentation; you might find that useful to read :P
<jdobrien> with a sweet printable reference card (PDF)
<Noia> I suspect I've bound this wrong >.>
<bob2> if you used bzr checkout, then it is already correctly bound to the branch you checked out
<lifeless> Noia: what does 'bzr st' show ?
<Noia> unknown:
<Noia>   noia/
<Noia> I'm pretty certain I've done it wrong
<Noia> ok
<Noia> how do I unbind and remove all bzr info on a specific folder etc
<bob2> Noia: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<Noia> just scrap this first thing and start again >.>
<lifeless> Noia: rm -rf :P
<Noia> =\
<Noia> so is it just the .bzr folder ?
<lifeless> roughly :P
<Noia> oh dear god vim
<Noia> help
<Noia> I'm stuck in vim >.<
<poolie> lol
<poolie> did you escape?
<spiv> Noia: a prompt for a commit message, I guess? :)
<poolie> remember :qa!
<Noia> I escaped
<fullermd> Once you get into ex mode, it's easy   :p
<Noia> bzr: ERROR: Could not start any editor.
<Noia> well atleast its progress
<jdobrien> noia: you're not alone
<Noia> ok...now were getting somewhere
<Noia> dah, conflict >.<
<lifeless> is there a grue ?
<fullermd> Dunno.  How do you light the lantern?
<lifeless> use matches
<fullermd> Crap.  I dropped the matches so I could pick up this gem...
<lifeless> drop gem
<lifeless> get matches
<lifeless> use matches
<lifeless> is there a grue ?
<fullermd> AS&$+++   NO CARRIER
<jdobrien> Syrnia?
<jdobrien> EverCrack
<bob2> zork
<jdobrien> i don't touch RPG...MajorMudd nearly ended my marriage
<rockstar_> Sounds like a problem with dependencies
<fullermd> I think you can script around that with a good client.
<Noia> yay
<rockstar_> Actually, my wife library is pretty stable.  Requires little maintenance
<Noia> now I have a truly epic system :D
<Noia> lol
<rockstar_> It also supports me writing stupid code that never goes anywhere.
 * Noia reads up and realises hes taken a step back into the past
<lifeless> poolie: transaction backout patch sent
<jml> hi
<jml> I just noticed that 'bzr st' on my project has gone down from 1+ seconds to about 0.5 seconds between 1.3 and bzr.dev.
<jml> well done guys
<ubotu> New bug: #62904 in bzr "merge from bundle should allow revision specification" [Low,Confirmed] https://launchpad.net/bugs/62904
<ubotu> New bug: #62905 in bzr "smart server is noisy on disconnection" [Medium,Confirmed] https://launchpad.net/bugs/62905
<ubotu> New bug: #77753 in bzr "bzr break-lock should take --local argument" [Medium,Confirmed] https://launchpad.net/bugs/77753
<ubotu> New bug: #86917 in bzr "option help text grammar is inconsistent" [Wishlist,Confirmed] https://launchpad.net/bugs/86917
<ubotu> New bug: #86919 in bzr "transport shouldn't indirect through control_files" [Medium,Confirmed] https://launchpad.net/bugs/86919
<poolie> jml: yay
<ubotu> New bug: #208017 in bzr "bzr error message for http 500 series error codes is invalid" [Low,Confirmed] https://launchpad.net/bugs/208017
<ubotu> New bug: #201907 in bzr "bzr crashed with NoSuchFile in _translate_error()" [Medium,Confirmed] https://launchpad.net/bugs/201907
<ubotu> New bug: #218575 in bzr "Rebase fails when the remote and local repositories have not diverged and the local repository is behind the remote repository." [Undecided,New] https://launchpad.net/bugs/218575
<nekohayo> ping james_w, is there an ETA on bzr being able to merge rich-root-pack branches into a regular pack-0.92?
<james_w> nekohayo: no idea I'm afraid.
<nekohayo> weeks? months? :)
<james_w> there's a growing number of duplicates of that bug.
<nekohayo> yeah I saw that
<james_w> I would hope before 1.4, but that's not long now.
<nekohayo> is there a roadmap?
<james_w> not that I know of.
<james_w> releases are monthly
<jelmer> nekohayo: rich root pack branches will never be mergeable into 0.92 branches
<jelmer> nekohayo: however, a future default format in bzr will support merging rich root branches
<nekohayo> jelmer: ah!
<nekohayo> I thought for a second that it would never be possible to merge svn stuff into bzr
<nekohayo> :)
<jelmer> nekohayo: You can also upgrade "regular" bzr branches to the rich root format already
<james_w> jelmer: that's true, but the bug in question is https://bugs.edge.launchpad.net/bzr/+bug/177874
<ubotu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Critical,Confirmed]
<nekohayo> then when is that new format planned to be in use as the default?
<james_w> nekohayo: hopefully we'll have one for 1.5
<igc> night all
<nexus10> hi
<nexus10> Is there any viable way to use bzr as a front end to a git repo?
<jelmer> nexus10: not yet
<nexus10> jelmer: ok, ta. Anything on the horizon? Git is just such an .... 'interesting' piece of kit
<james_w> nexus10: https://launchpad.net/bzr-git
<james_w> it's still a work in progress
<nexus10> james_w: thanks, saw that -- that's the most likely project to get this working?
<james_w> yes, I think so.
<james_w> bzr-fastimport may also help somehow
<nexus10> I really need full roundtrip
<nexus10> rw
<nexus10> jelmer, james_w: thanks a lot -- I'll monitor that project
<tolstoy> Anyone have a recommendation for a web based BZR browser you can install in your public_html (for instance) folder?
<asabil> tolstoy: loggerhead ?
<tolstoy> asabil: Looking at it right now, actually!  Alas, their example server is down.
<james_w> bazaar-webserve is the alternative
<tolstoy> Hm. Loggerhead hasn't seen much development in the past two years.
<james_w> http://bazaar.launchpad.net/~bzr/bzr/trunk/files
<james_w> that's loggerhead
<tolstoy> bazaar-webserve is the one used by launchpad?
<tolstoy> james_w: Thanks for the link!
<james_w> nope, they use loggerhead
<tolstoy> BTW, I'm trying to get my company to move from cvs to bzr, rather than to svn, but it's a hard sell!
<tolstoy> Ok.
<tolstoy> My company uses Atlassian tools (sp?) and so there's a bit of an issue there, too.  I'm still hoping, though.
<tolstoy> Hm. Logger head doesn't seem set up to visualize a directory tree of many, many branches.
<vimes656> While working in a branch I realize that the changes I'm doing should be branched out, how do I branch out with uncommited changes?
<beuno> vimes656, I belive you can do bzr branch --uncommited
<beuno> but I'm not 100% sure
<LarstiQ> merge --uncommitted perhaps
<beuno> ah, that's it, merge
<vimes656> LarstiQ: then I have to create first an empty branch and merge the one I was working on, right?
<LarstiQ> vimes656: I'd cd ..; bzr branch -r -1 previous new; cd new; bzr merge --uncommitted ../previous
<vimes656> LarstiQ: that will work, thanks
<LarstiQ> vimes656: and then revert in previous. Alternatively (for example if you don't have loads of object files), just mv the current tree to a new name, and bzr branch -r new previous
<vimes656> LarstiQ: yeah, that's better in my case, thanks a lot
<vimes656> bzr is great, BTW
<vimes656> the more I work with it the more I like it
<plexq> I'm getting an error running bzr: ImportError: cannot import name RevisionInfo
<luks> check the full traceback from ~/.bzr.log
<plexq> http://pastebin.com/m64621cf4
<mw> whoa, bzr status got way faster since the last time i tried it against a large tree
<mw> nice work
<mw> commit too
<plexq> fixed it
<abentley> plexq: what was it?
<plexq> bad install
<plexq> I re-installed all the files in site-packages/bzr and it worked fine
<plexq> anyway
<plexq> is there anything like gitk for bzr?
<abentley> plexq: Yes, bzrk in the bzr-gtk plugin.
<plexq> thats awesome
<abentley> Actually, I guess it's called "viz" now.
<plexq> hmm I can't get olive-gtk to run
<plexq> it says I don't have libglib.dll or somesuch
<plexq> but gtk2.0 is in site-packages
<plexq> and I have gtk installed
<mw> .dll? :)
<mw> running on windows?
<plexq> yup
<mw> i'd like to help, but i wouldn't know where to start, sorry
<igc> morning
<jam> morning igc, up early?
<igc> jam: I've been starting this early most of the week - just haven't been on IRC this early :-)
<jam> lifeless: just as a pack repo data point, doing 'bzr log -r 10' grabs revision_history to evaluate the '-r 10'
<jam> lifeless: there are 3374 calls to iter_reverse_revision_history
<jam> which generates 3373 calls to get_parent_map()
<jam> which generates 6758 calls to "iter_entries()"
<jam> which generates 30411 calls to index:459(iter_entries)
<jam> I'm guessing the 3373 => 6758 is because the second call has to finish out the generator and then get StopIteration raised
<jam> And then I'm guessing the 6758 => 30411 is because of pack misses
<jam> That repo currently has 17 packs
<jam> well, it has 17 files in 'packs' there are only 13 entries in 'pack-names'
<jam> it is: http://bazaar.launchpad.net/~bzr/bzr/trunk/
<jam> not sure why there are 4 'cruft' packs.
<lifeless> jam: iter_entries - is this a fully packed repo?
<jam> lifeless: no
<jam> it is the launchpad mirror of bzr.dev trunk
<lifeless> ok
<lifeless> not sure what would lead to cruft packs
<lifeless> anyhow, I do think we should get instrumentation like I discussed in my mail in place where it is missing
<poolie> good morning
#bzr 2008-04-18
<jml> poolie: good morning!
<poolie> hello jml
 * ToyKeeper discovers, after typing a very long change log, that Escape means "abort NOW" in "bzr gci"
<ToyKeeper> ... poor fingers can't unlearn "esc :w"
<lifeless> ouch
 * ToyKeeper files a bug about it
<i386_> hey lifeless
<lifeless> hi i386_
<i386_> lifeless: good news - as of next week im an Apache committer :)
<i386_> and we need you over for dinner
<lifeless> indeed
<gotgenes> `bzr checkout`ing from a Subversion repository that has only a trunk and then unbinding is effectively a full migration of the repository to Bazaar, right?
<lifeless> yes
<lifeless> you may as well just bzr branch :P
<gotgenes> ah
<gotgenes> even better
<gotgenes> thanks lifeless
<ubotu> New bug: #218986 in bzr "Escape aborts 'bzr gcommit'" [Undecided,New] https://launchpad.net/bugs/218986
 * i386_ wants to use bzr over at this apache project
<i386_> hows the svn plugin these days?
<RAOF> i386_: I like it very very much.
<i386_> Works well?
<RAOF> i386_: I'm using it to track banshee development & do some hacking, and it works just fine there.
<i386_> cool
<i386_> how does it deal with repositories with huge histories ?
<RAOF> Slowly on the initial branch (obviously), and then just fine from there.
<RAOF> Banshee is on svn revision > 10K, IIRC. (I don't know, my checkout is on bzr revision 1024 :))
<i386_> RAOF: can you push back to svn?
<RAOF> i386_: I _believe_ so, but I don't have banshee svn acces, and I haven't tried with anything else.
<gotgenes> i386_: by default commits occur like SVN commits, immediately sent over the network to the SVN repo
<i386_> RAOF: we suffer from a slow checkout time
<RAOF> gotgenes: Really?  I suppose that depends on how you checked it out, though, since it didn't seem to try for me.
<gotgenes> RAOF: I did a bzr checkout and it's acting as a bound branch
<gotgenes> I think that's the right term
<RAOF> gotgenes: Oh, of course it would, since that'd be the behaviour for checking out a bzr branch.
<RAOF> gotgenes: I did 'bzr branch', and my commits are local.
<gotgenes> RAOF: I assume you just do a bzr push to get the commits out to SVN?
<RAOF> gotgenes: Yes.  If I had write access to that repository.
<gotgenes> sure
<jdobrie1> how long does bzr branch lp:bzr usually take?
<jdobrie1> nm i'll just get from my branch
<jdobrie1> would there be a reason why this works fine: bzr branch http://bazaar.launchpad.net/~bzr/bzr/trunk
<jdobrie1> but lp:bzr just sits
<spiv> What about "bzr branch bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk" ?
<spiv> Is that the same as lp:bzr?
<spiv> If so, it's nothing do with lp:bzr, it's just poor progress reporting when using the bzr protocol rather than plain HTTP.
<jdobrie1> i will check it out when this download ends.
<mwhudson> oh yes, who do i punch about that
 * mwhudson downloaded a 400 meg branch from launchpad over bzr+ssh yesterday
<jdobrie1> ouch
<mwhudson> 'watch du -s' is not really a good progress bar :)
<jdobrie1> yeah...should break out into metallica videos or something
<spiv> mwhudson: bzr -Dhpss ...  +  tail -f ~/.bzr.log    ;)
<jdobrie1> with SSH...bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<jdobrie1> problem on my config
<mwhudson> spiv: not much better
<spiv> Oh, bzr+ssh://YOUR-LP-USER-NAME@bazaar.launchpad.net/~bzr/bzr/trunk, sorry.
<jdobrie1> <------i should have noticed that
<spiv> Assuming you have your SSH public key in your launchpad account (and assuming you have a launchpad account)
<spiv> (I just have my ~/.ssh/config set use the right username for bazaar.launchpad.net automatically, so I keep forgetting that bit)
<jdobrie1> no...with username i get the same ...just sits
<jdobrie1> need to check config and ssh
<bob2> is there a plugin around that lets you interactively select hunks to commit (ala shelve in reverse)?
<jdobrie1> somehow we need to do something about google search
<jdobrie1> type lauchpad bzr and you get massive bug listing
<jdobrie1> not good PR
<spiv> Well, that's like typing 'bugzilla gnome', really :)
<jdobrie1> ouch
<jdobrie1> but true
<spiv> Although when I 'launchpad bzr' into google, I don't get bug reports.
<jdobrie1> add ssh
<spiv> Ah, some bugs start appearing.
<jdobrie1> nevermind i found the problem...it was between my keyboard and chair
<jdobrie1> forgot to register my new keygen
<xenoterracide> I'm trying to use the bzr fast-export plugin. I have bzr fast-import installed... but I have this error
<xenoterracide> bzr: ERROR: unknown command "fast-export"
<xenoterracide> fast-export is a sub of fast-import
<xenoterracide> any ideas?
<igc> xenoterracide: bzr-fast-export.py is a script bundled with the fast-import plugin
<igc> you want something like ~/.bazaar/plugins/fastimport/exporters/bzr-fast-export.py ...
<igc> (no promises that path is correct but you get the idea I hope)
<xenoterracide> so I should just run the file directly?
<igc> yes
<igc> I ought to turn it into a proper command but that's how it is right now
<xenoterracide> igc: hmm... I'm not that familliar with bzr (or how git fast-import works) I'm in the bzr checkout dir and I know the name of the branch I checked out... running bzr-fast-export.py branch |git fast-import ../project doesn't seem to work
<igc> xenoterracide: let's take it one step at a time
<igc> you should be able to redirect the output of bzr-fast-export.py
<igc> and check that it looks right
<igc> I'd have to read the git-fast-import man page but ...
<igc> you probably need to be in the dir holding the .git directory?
<xenoterracide> I'm not sure... looks docs over
<igc> there's some notes at the top of the python file too
<igc> i.e. the top of bzr-fast-export.py
<xenoterracide> right. I totally hate sounding like an ungrateful ass, but these progs really, really need better docs
<igc> xenoterracide: true
<xenoterracide> I'll have to write something up once I figure it out
<xenoterracide> :P
<igc> please do - thank would be good
<xenoterracide> what does --export-marks=marks.bzr doe the name matter? or is it just a file?
<igc> just a file
<igc> see the git-fast-export man page for an explanation
<igc> sorry - git-fast-import
<xenoterracide> waits... hopefully thats working
<xenoterracide> ok... export seems to have went well now I have an import error
<xenoterracide> question is where is the problem
<xenoterracide>  http://vim.pastey.net/85948 git import who should I be bugging the bzr repo owners? git? or the bzr-fast-export maintainer
<igc> xenoterracide: my guess is that the bug is most likely in bzr-fast-export
<xenoterracide> so who do I complain at? you?
<igc> dato was the original author of it, though it's now part of bzr-fastimport so probably me
<igc> can you raise a bug in lp?
<igc> the project should be bzr-fastimport
<xenoterracide> lp=launchpad?
<igc> yes
<igc> either james_w or myself will look into it for you
<igc> others might too
<xenoterracide> igc: yeah I've filed a couple hundred bugs before. but never where I had 3 possible parties who could be at blame...
<xenoterracide> actually 4
<igc> :-)
<xenoterracide> although I have one that I've yet to file thats worse
<xenoterracide> it affects every browser in linux
<xenoterracide> and most programs, except a few...
<xenoterracide> could be the font yet some programs handle it correctly
<xenoterracide> so who's problem is it
<igc> yuk
<xenoterracide> I really should report it to mozilla because it crashes ff 100% of the time
<xenoterracide> but no browser renders it right
<xenoterracide> but OOo and the font browsers handle it fine
<xenoterracide> oh and it only affect *nix systems
<xenoterracide> windows ff does it fine
<xenoterracide> but was reproducable on mac
<xenoterracide> who would you bother first?
<igc> who's most likely to care about getting it fixed?
<xenoterracide> I don't know...
<xenoterracide> igc hmm... it says project doesn't exist in gentoo.... this may rank as my new top crappy bug tracker
<mneptok> xenoterracide: does it crash Epiphany? Konqueror?
<xenoterracide> wait I figure lp out
<xenoterracide> mneptok: doesn't crash konq or opera but it is rendered improperly
<xenoterracide> I haven't tried epiphany
<mneptok> sounds like X font rendering, killing Gecko and not playing nicely with KHTML. can the font be used locally in, say, OO.org docs without issue?
<xenoterracide> yep
<mneptok> not X
<xenoterracide> I haven't tried X directly
<mneptok> it's broswer rendering. report the crasher against Gecko if it kills Epiphay.
<mneptok> (now *there's* some half-assed triaging!)
 * mneptok flexes
<xenoterracide> well it wasn't just browser I had a problem in another kde program
 * xenoterracide doesn't remember which one
<xenoterracide> prolly kwrite
<mneptok> well, to be fair, it's not a bzr issue, so ...
<xenoterracide> I know
<xenoterracide> just talking about haywire bugs
<mneptok> and i supposedly quit working 2h ago.
<mneptok> and now, i shall. g'night xenoterracide. hello PS3.
<xenoterracide> heh
<xenoterracide> https://bugs.launchpad.net/bzr-fastimport/+bug/219042 poof
<ubotu> Launchpad bug 219042 in bzr-fastimport "fast-export doesn't export right" [Undecided,New]
<xenoterracide> ;P
<igc> night mneptok
<TFKyle> the crashing stuff could be pango, though if it doesn't crash normal gtk apps maybe not directly
<TFKyle> (and I'd expect it to crash the gnome font viewer if it was pango too)
<TFKyle> oops, he's gone
<poolie> spiv: how is the patch for the line delta bug?
<spiv> poolie: just pushed a new version of it, was about to send to the list after selftest passes.
<spiv> get_revision_file returns a KnitVersionedFile where delta=True, which is wrong.  So the patch just forces delta=False, and teaches insert_data_stream how to convert a line-delta record to fulltext if not self.delta
<spiv> This fixes the bug with the test branch, as well as giving a local repo with a clean (i.e. all fulltext) revision knit.
<spiv> I don't have tests in my patch yet, but the approach is still reviewable without that, so I'll send to the list first before worrying about that.
<poolie> ok, thanks
<poolie> i'll look at it
<spiv> Ok, selftest with the existing suite passes, bundle sent to the list.
<poolie> i'm just writing a mail about 1.4,
<poolie> i think we should merge these things and do a 1.4rc2 this afternoon
<poolie> but leave final for next week
<poolie> what do you think?
<spiv> I'm inclined to agree.
<igc> poolie: I agree. I think we need an rc2 for 1.4. We want those people who went back to 1.3.1 when they found problems to kick the tires again.
<igc> or "tyres" in the case of us Aussies :-)
<poolie> igc, thansk
<poolie> igc, spiv, i don't think i'll have time to make it today though, i have a commitment with stephane
<poolie> i will try to do it on the weekend
<igc> poolie: ok. I'm heading off rsn also fwiw
<spiv> poolie: ok.  enjoy your weekend (well, the non-work bits at least :)
<matkor_> Hi ! What is  submit branch: in bzr info ?
<poolie> matkor_: it's the public url of the branch you want to merge into
<poolie> typically the main branch of your project
<matkor_> poolie: Hmm, I do not remember me merging into remote branch ... usually I merge to local checkout of main branch, resolve conflicts and commit ... How could I create it ?
<poolie> matkor_: iirc the submit branch just controls the default for bzr send
<matkor_> poolie: Thnx a lot ! I will read on about bzr send
<igc> night all - have a good weekend
<poolie> hello james_w
<poolie> (leaving soon)
<james_w> hi poolie
<james_w> have a good weekend
<dato> igc: I'm happy to look at bzr-fast-export bugs too
<dato> igc: though if you prefer to look into this one, I'm happy to. the problem seems to be that we're instructing git-fast-import to rename a directory, when we shouldn't be doing that.
<james_w> hi dato
<dato> hello james_w
<james_w> if that is the issue then it may be worth talking to Shawn, as it seems that possibly should be allowed.
<james_w> well, git should just ignore it, but I don't see why it should reject it.
<dato> uhm, no, I'm mistaken
<dato> path/dir1 was renamed to path/dir2, and it seems that was accepted (of course)
<dato> and then path/dir1/fileX was renamed to path/dir2/fileY, and that boomed
<james_w> so a directory rename is recursive to git-fastimport?
<dato> well, it is to bzr as well, ain't it?
<james_w> I'm not sure how it's represented internally
<james_w> I would expect bzr-fastimport to do that though
<dato> maybe bzr-fast-export should do some ordering, I'm not sure
<jelmer> mwhudson: hi
<jelmer> mwhudson: should pydoctor work on .so files?
<bjesus> hey, i had a bzr server to which we did 'bzr update' and 'bzr commit' every once in a while
<bjesus> but it's down, so i got a new one
<bjesus> and i have the last commit on my computer
<bjesus> so i coppied it to the new server
<bjesus> and now i want everyone to 'bzr update' from it and 'bzr commit' to it.
<bjesus> the thing is - it always tries to connect to the old server
<bjesus> and since the old server is down, i can't seem to use the new one.
<dato> bjesus: try `bzr unbind; bzr bind new_server_address_and_path`
<bjesus> how can i make a directory created from a 'bzr checkout' and 'bzr update' to something i can checkout and update from?
<bjesus> thanks i'll try
<bjesus> 'bzr unbind' gives me a long error ending with:
<bjesus> RuntimeError: maximum recursion depth exceeded
<bjesus> i can't even see where it's starting
<bjesus> the thing is - if 'a' is the old server, 'b' is my user pc, and 'c' is the new server - b used to do checkouts and updates from a, but what if c wants to checkout and update from b? is that possible? to change the centeral location?
<dato> c wants to update from b?
<dato> I thought you wanted b to update from c...
<bjesus> basically yes, but it seems like simply copying the directory doesn't work, so if i'll update c from b, i'll surely be able to afterward update b from c, and every other computer from c
<bjesus> it seems like it's all about changing the central server, since if i could make the latest-updated-computer a new server, i could checkout it from everyother location and then make the new location the new server.
<jdobrien> larstiq: i had a couple of questions so i could proceed working on the bug i'm working on
<LarstiQ> jdobrien: shoot
<jdobrien> what commands should the change i am making effect?
<jdobrien> status is obvious, diff too?
<jdobrien> cat?
<jdobrien> larstiq: nm not cat
<LarstiQ> jdobrien: ignore perhaps
<jdobrien> larstiq: other question is, you mention <someone> may have already created some unit tests. can't remember who you said and not sure where to look for them
<mwhudson> jelmer: ?
<mwhudson> not here though, send email
<jdobrien> k
<LarstiQ> jdobrien: can't find it at the moment, but it wasn't much
<LarstiQ> jdobrien: I'd focus on status first though
<jdobrien> i was relying on the online log and we apparently were in a private chat when you gave me the name :-/
<jdobrien> k
<jdobrien> i was going to create a separate test for the expected behaviour first, then i would assume i should mod the existing tests for status
<jdobrien> larstiq: opinion?
<LarstiQ> jdobrien: previous tests might not be needed to modified
<LarstiQ> jdobrien: bzrlib/tests/blackbox/test_status.py is where I'd add them
<jdobrien> k
<jdobrien> so no reason to create 'new' tests
<jdobrien> just put them in the status black box testing
<jdobrien> larstiq: thanks. im still obsorbing python so i appreciate the patience.
<LarstiQ> jdobrien: at first, for testing that the commandline status output is what you expect, certainly in the status blackbox
<LarstiQ> jdobrien: np, have a look at the rest of the tests to get an idea
<jdobrien> yeah i have been
<LarstiQ> cool
<jdobrien> larstiq: im used to using nunit/junit so it's not a big leap
<jdobrien> larstiq: the diff between staticmethod & classmethod had me spinning for a few hours last night...different behaviours in c#
<ubotu> New bug: #219246 in bzr "exceptions.KeyError on log" [Undecided,New] https://launchpad.net/bugs/219246
<dwt> Hey, guys, how can I see what will be pushed to a remote location when I say "bzr push"?
<dwt> without pushing it
<grutte_pier> isn't there a option to do this?
<dato> dwt: bzr missing --mine-only
<dwt> seems to work
<dwt> great!
<dwt> thanks guys
<VSpike> Is there any good solution for pushing code from a bzr branch to a webhost via ftp?  I've been looking at rsync and lftp, but rsync has to use curlftpfs which is not reliable, and lftp depends on date stamps, which bzr trashes.  I seem to remember mention of a plugin?
<Verterok> moin
<james_w> VSpike: bzr can push to ftp
<james_w> however it doesn't update/create the working tree, meaning your files won't be visible on disk, you'll only see a .bzr
<james_w> there is a plugin to work around that, but it uses ssh, so you're back to square one if you need it.
<VSpike> james_w: ah yeah, that's my problem in a nutshell
<VSpike> so, no way around it at present?  I guess I just have to ftp up everything every time.
<Stavros> hello
<Stavros> suppose there is a branch to which i only have read-only access, but i want to add a patch, would it be feasible/sane to keep a local copy with the patch indefinitely and still merge the changes from the remote branch in it?
<beuno> Stavros, you should be able to just branch
<beuno> add your path
<beuno> *patch
<beuno> and keep on merging indefinitely, yes
<Stavros> ah, great
<beuno> many of us do it on a daily basis
<Stavros> would this be easy?
<Stavros> or would every patch need manual adjustments?
<Stavros> err
<Stavros> every merge
<beuno> Stavros, nope, you should be fine
<Stavros> ah, that's great
<beuno> I do regular:  bzr merge && bzr ci -m'Merge from trunk'
<beuno> you might have occasional conflicts
<Stavros> that solves the big problem of adding features to various 3rd party packages
<beuno> but you might not  :)
<Stavros> well yes, true
<Stavros> but overall, it sounds much easier
<beuno> Stavros, yeap, I think that's one of the ideas behind DVCS
<Stavros> great great
<beuno> not needing write access to the main branch to work on it and use version control
<Stavros> yes, i was more worried about the "indefinitely" part :P
<beuno> you'll just have to merge n commit instrad of pulling
<beuno> *instead
<beuno> isn't too painful
<Stavros> yes
<Stavros> i agree
<Stavros> great great
<Stavros> i love bzr
<beuno> welcome to the club  :)
<Stavros> i have been a member for a while :p
<Stavros> i use it rather exclusively
<Stavros> does bzr-svn with authentication work in linux?
<beuno> Stavros, I don't use it, but AFAIK, yes
<beuno> jelmer would know more about this
<Stavros> ah, thanks
<[cliff]> hi all!
<[cliff]> is it possible to use, or somehow simulate, nested branches with bzr?
<beuno> [cliff], LarstiQ is the man to answer that
<[cliff]> so I'll have: branch1, which contains references to branch2 and branch3
<beuno> he hides sometimes, but if you win the waiting game, you'll eventually get a good answer for that  :)
<[cliff]> thanks beuno
<[cliff]> lol
<[cliff]> thanks
<beuno> [cliff], alternatively, you can email the list
<[cliff]> yeah, but I was trying to avoid subscribing to yet another mailing list :-)
<beuno> [cliff], right, then "waiting game" seems like your best option for a good answer
<[cliff]> right... subscription is it :-)
<[cliff]> cheer-io-s
<LarstiQ> right, right
<beuno> LarstiQ, don't hate me  :)
<LarstiQ> beuno: I don't :)
<LarstiQ> beuno: more myself really
<jam> LarstiQ: well, it was unclear if he was willing to "fake" it, or if he needed the real thing
<LarstiQ> jam: right. But regardeless of what he wants, it still needs to be done
<beuno> LarstiQ, it's just a recurring ping to either iron out the remaining failing tests, or start merging parts of the code so someone else could potentially take over  :)
<LarstiQ> beuno: thank you for doing that
<beuno> LarstiQ, it's a selfish thing, I've got a use case for it at work  :p
<LarstiQ> jam: I believe you sent a mail related to it? I haven't yet looked at that
<LarstiQ> beuno: that's ok
<jam> I don't remember sending anything but a ping
<tolstoy> Folks!  Is there a way to merge a bunch of commits into one commit?
<LarstiQ> jam: ok
<tolstoy> In other words: bzr branch local, commit 1, commit 2, commit 3, then merge those as one big commit/patchset?
<LarstiQ> tolstoy: and you're not meaning a regular merge? :)
<jam> tolstoy: depends what you think that is
<jam> tolstoy: generally a regular merge will add 1 new commit to signify the joining
<jam> and 'bzr log --short' will only show that.
<jam> If you want to completely remove commits 1,2,3 from the history you can:
<jam> bzr revert --forget-merges
<jam> after the merge
<jam> so it looks like it was all freshly done
<jam> or you can
<tolstoy> I could make lots of little "daily back up commits", then branch at some early point, and merge a big diff and commit that, and toss the original, but was wondering if there was something less clever.
<tolstoy> jam: forget merges, ah, okay.
<jam> commit 1, 2, 3; bzr uncommit -r -3; bzr commit -m "this is the new tip for 1,2,3"
<jam> tolstoy: you probably want 'uncommit' then
<tolstoy> jam: Oooo, I like that. Cool.
<asabil> is there a way to change the email used in previous commits ?
<beuno> asabil, unfortunetly, no
<beuno> the previous commits are immutable
<asabil> :/
<beuno> asabil, I'm working on bug 215334 to try and avoid committing with the wrong info
<ubotu> Launchpad bug 215334 in bzr "Bzr shouldn't permit users to commit without setting author info" [Wishlist,Confirmed] https://launchpad.net/bugs/215334
<asabil> beuno: that's the not the problem
<asabil> I really think that bzr needs something like git-filter-branch
<beuno> asabil, right, then it's a different use case  :)
<beuno> I think the versioned properties bit would be what would solve this
<beuno> some work was done towards it
<beuno> but I'm not sure what the status is
<asabil> ok :/
<lifeless> beuno: how would versioned properties solve this?
<beuno> lifeless, unless I'm completely lost on what it is, wouldn't the committer be a property which could be changed, with the change being versioned so we still have the original information preserved
<beuno> IIRC, something like this was discussed in the sprint, although I might be confused  :)
<ubotu> New bug: #219334 in bzr "Texinfo version of the documentation" [Undecided,New] https://launchpad.net/bugs/219334
<lifeless> beuno: this is exactly why I object to 'generic versioned properties'
<lifeless> beuno: the answer is no, because its a chicken and egg problem
<lifeless> beuno: revisions contain the committer; the revision graph describes the tree
<lifeless> beuno: log would be at least twice as slow if every lookup had to indirect back into the tip revision tree; and the proposed single file property store would fall over cold on something like ooo
<beuno> lifeless, I see. In which cases would versioned properties be applied then?
<lifeless> beuno: I don't know of any other than eol; and I don't htink its a good fit there.
<lifeless> beuno: I want eol badly; I just think this generic versioned property is a dead end introduced because 'svn has them' back at some point in design discussions
<beuno> lifeless, seems reasonable. Although, the issue about changing previous commits comes up too often for us not to look into some kind of workaround. There might not be any, but still, we should keep on trying
<beuno> lifeless, right, I think it's an overkill too, if it's just going to be used for EOL
<lifeless> beuno: if we want to allow changing of commits we just add another authoritative timeline
<lifeless> one that is not human derived; but this adds massive complexity in design (e.g. which attributes can be edited; is there security; how to deal with conflicts)
<lifeless> as well as performance considerations, and the issues of explaining that this is going on
<beuno> right, a heap load of work
<lifeless> this is why none of darcs/git/monotone/hg allow it
<beuno> and there are much important issues ATM
<beuno> lifeless, I'm working on being more verbose to people about what info they are committing with
<beuno> to try and narrow that down a bit
<lifeless> cool
<lifeless> well 5:30, I am going to take a couple of panadol and try to sleep
<beuno> but I suspect this will just keep coming up  :)
<beuno> heh
<beuno> ok
<beuno> sleep well!
<lifeless> the generic answer to 'I want to rewrite my history' is 'ok rewrite your history'
<lifeless> bye
<asabil> beuno: I wasn't asking really about changing the previous commits
<asabil> but about creating a new filtered branch from the original one
<beuno> asabil, right, but in order to change previous authors, you change the commit metadata, so it's more or less the same. You might be able to use rebase plugin and some other black magic to do that, but this is really out of my knowledge  :)
<asabil> thanks anyway for the tips
<beuno> asabil, :)
<foom> the problem with "ok rewrite your history" is that afaik you can't do that without screwing over all your developers. it would be nice to be able to rewrite your history and not have it blow up everyone's checkouts. If the history you're rewriting doesn't end up affecting the current revision, that should at least be theoretically possible.
 * beuno wonders where jelmer is with the new bzr-gtk release
<lifeless> foom: well
<lifeless> asabil: I think a filter branch command might be useful; it does need to rewrite the graph though as in git
<lifeless> foom: indeed; thats why rewriting history isn't part of regular bzr workflows, and why looms does not do it.
<asabil> lifeless: yes I think so as well
<lifeless> beuno: I think you've got the wrong end of asabil's stick.
<foom> lifeless: a solution to the "Nuclear Launch Codes" problem would be nice, though...
<lifeless> beuno: asabil means 'create a new branch with history derived from the old one (synonymous graph, but different ids), and some other arbitrary differences besides'
<lifeless> foom: indeed. I believe heavy radiation is the cure :P
<beuno> lifeless, right, so they become different branches. It's different from what I meant
<beuno> I was looking at preserving it for other derived branches to keep working
<asabil> I don't minds having different branches
 * beuno wonders how long lifeless's panadol takes to kick in  :)
<asabil> as long as the filtered one retain the time stamp and the commit messages
<lifeless> beuno: its failing to
<beuno> lifeless, double or nothing?  :p
<lifeless> beuno: anyhow, consider the problem of indexing a database with two different values for the same unique key :P
<lifeless> shortly, you'll be sharing my headache
<beuno> hehe
<beuno> right
<beuno> I like it on this side of the fence for now  :)
<beuno> so, if I understand this correctly, asabil might be able to pull off what he wants, with some python and bzrlib knowledge. Would be a nice plugin too
<Vantage> Hi all, does anyone know of any strategies for converting and merging cvs modules into one bzr shared repo?
<asabil> Vantage: https://launchpad.net/bzr-cvsps-import
<asabil> and http://bazaar-vcs.org/BzrFastImport
<Vantage> asabil: Converting isn't a problem, but because the CVS tree was all modules, I end up with 15-20 shared repos.  I now want to try and merge them into one tree (that is itself a shared repo)
<Vantage> or rather one new top level repo with all history
<asabil> not sure I understood what you want exactly
<asabil> you meant 15-20 branches
<asabil> not 15-20 shared repos
<asabil> no ?
<ubotu> New bug: #219357 in bzr "UnboundedLocal error when trying to bundle revisions for a branch" [Undecided,New] https://launchpad.net/bugs/219357
<Vantage> asabil: when you use cvsps-import it generates a no-trees repo with all the branches and history.  So I have 15-20 of those
<Vantage> each with their own branches and history converted
<asabil> oh right
<asabil> Vantage: you can maybe bzr init-repo
<asabil> and then bzr branch <branch>
<asabil> inside the repo
<asabil> for each branch in the other repos
<Vantage> asabil: our original cvs repo used nested trees to build a codebase and share modules around, etc.  Since bzr doesn't support that, we have to figure out another way to do it.  The easiest seems to be to just get rid of the modules and merge it all into one tree
<Vantage> asabil: Hrmm that could get quite tedious.  I suppose it could be scripted though
<asabil> I see
<Vantage> asabil: Unless you know of a better approach?
<asabil> yes, a small shell script should do
<asabil> unfortunately not, but I am not used to importing from cvs
<asabil> or rather, am not used to repository administration at all :)
<asabil> maybe you can just wait for someone who is more knowledgeable about it :)
<asabil> sorry
<Vantage> asabil: no problem.  Thanks for the advice
<cpinto> hey all
<cpinto> john meinel around?
<cpinto> jam, we were exchanging emails on the bzr ml
<cpinto> about nested projects and co'ing project subdirs
<jam> you changed your name, weren't you [cliff] before
<jam> ?
<cpinto> yeah
<cpinto> [cliff]'s a legacy handle :-)
<cpinto> anyway, what I was looking for was for a way to be able to work around a python issue (actually it's a non issue but i'm stuck with it)
<cpinto> so I have about 5 different bzr repositories
<cpinto> and all of them have the same directory, let's call it metapackage. each repository then tracks different code in the metapackage, so in repo-a I have metapackage/a, in repo-b I have metapackage/b, etc.
<cpinto> what I wanted was to be able to branch repo-master which contains metapackage, and inside of my local branch to be able to branch repo-a's metapackage/a, etc
<cpinto> so in the end
<cpinto> i'd have, metapackage/a and metapackage/b
<cpinto> being metapackage developed in one repository, a in another and b in yet another
<cpinto> currently, the best I can have is metapackage and metapackage/metapackage/a, metapackage/metapackage/b
<jam> cpinto: can you use symlinks?
<jam> alternatively, you could look into python .pth files
<jam> (i think that is what they are), they control the search path
<cpinto> or, as you suggested, just symlink the directories but I'm a bit wary of that. can you explain a bit further how bzr handles symlinks (ideally picking up my example)
<jam> or you can hack into "metapackage.__path__" to change the search path
<cpinto> yeah, I've though of .pth too
<cpinto> yeah, I've thought of .pth too...
<pekuja> I'm having some trouble figuring out the BzrEclipse plugin
<beuno> pekuja, what seems to be the problem?
<pekuja> hmn...
<pekuja> well that's weird, it's working now...
<pekuja> one thing that I did find weird though is when I'm enabling Bzr for a project, pressing "Finish" apparently initializes the repo, but the window stays open
<pekuja> which was a little confusing
<beuno> pekuja, could you file a bug for that?
<pekuja> yeah
<beuno> the developer is not currently here
<beuno> so the best way to get it solved is to report bugs  :)
<pekuja> also, the Bzr menu was disabled... it doesn't seem to be disabled now though
<pekuja> so I'm not sure I can provide useful data on that now
<beuno> pekuja, I believe it has to detect the project has an actual branch to be enabled
<beuno> so it might have taken a bit longer for it to detect it
<keithy> heel os there an installer for tiger
<keithy> hello, is there an installer for tiger
<keithy> ?
<beuno> keithy, it seems that only for PPC:  http://bazaar-vcs.org/Download
<pekuja> beuno, by the way, is the Bzr-menu the way I'm supposed to use the plugin? nothing wrong with that, it just seems a little rudimentary I guess
<beuno> (tiger is 10.4, right?)
<pekuja> or do you use it yourself?
<keithy> that'l do nicely
<beuno> pekuja, what do you mean? What would be the alternative?
<pekuja> beuno, heh, frankly, I'm not sure. one thing for example that would be nice if it showed be what files I've changed since the last commit in the project view
<beuno> pekuja, AFAIK, it does
<beuno> with decorators
<beuno> but I don' currently have it installed
<beuno> did you download the latest release?
<pekuja> maybe I need to enable it separately
<pekuja> I had to do that for the Bzr menu
<pekuja> hmn, I guess that would also be a bug report / feature request for me
<pekuja> it doesn't really expose a lot of its functionality by default
<beuno> pekuja, check out: http://bazaar-vcs.org/BzrEclipse/Screenshots
<beuno> pekuja, yes, I do think you have to manually enable it
<pekuja> yeah, I found where... it doesn't seem to be working though
<pekuja> also, yeah, I have the latest release I think
<pekuja> it's from the update site
<beuno> pekuja, I don't really know what could be causing it.  I haven't had issues with that myself
<beuno> are the files versioned?
<pekuja> yes
<pekuja> it seems like Eclipse is not finding BazaarLightweightDecorator
<beuno> pekuja, sounds like a bug report to me  :)
<pekuja> hmn, I think I'm going to try reinstalling the plugin just in case
<beuno> pekuja, I'm pinging the developer now to see if he's bored enough to drop by here   :)
<pekuja> heh
<pekuja> nice
<beuno> pekuja, meet Verterok
<Verterok> Hi, pekuja
<Verterok> beuno: thanks ;-)
<beuno> Verterok, :)
 * Verterok reading the irc log
<pekuja> hi
<Verterok> pekuja: could you check the Error log view?
<pekuja> yes, it says "java.lang.NoClassDefFoundError: org.vcs.bazaar.eclipse.ui.decorator.BazaarLightweightDecorator"
<pekuja> I think I might have just fixed that though...
<Verterok> pekuja: huh, thats weird. that class is from the ui plugin
<pekuja> I was able to make the error go away by adding ~/.eclipse/org.eclipse.sdk.ide/updates/eclipse/plugins to the Plugin path of the Bazaar plugin
<pekuja> in Preferences->Team->Bazaar
<Verterok> pekuja: thats not the idea of that config field :)
<Verterok> pekuja: it's for bazaar plugins
<pekuja> hmm, nope, I'm getting the error again
<pekuja> yeah
<pekuja> it didn't really seem to make much sense
<pekuja> I also get "Problems occurred when invoking code from plug-in: "org.eclipse.jface"." before the NoClassDefFoundError
<Verterok> pekuja: which OS, Jvm version and eclipse versiÃ³n are you using?
<Verterok> pekuja: also bzr and bzr-xmloutput versions :)
<pekuja> hmmmm
#bzr 2008-04-19
<pekuja> you just made me notice I'm using gcj for my jvm
<Verterok> that could be the problem
<pekuja> exactly my thoughts...
<beuno> Verterok, can you detect that from the plugin or the setup?  To prevent these sort of things
<pekuja> I'll switch to Sun's JVM and try again
<Verterok> beuno: not really, because the eclipse plugin model is something like: "I'll call you, don't call me" :)
<beuno> ah, java...
<beuno> (I know it's not java's fault, it's just a good time to complain)
<Verterok> beuno: hehe, let me be more specific: ah, OSGI ;-)
<Verterok> pekuja: please, let me know if that fix the error
<pekuja> yeah, I'm still looking into it...
<Verterok> pekuja: np, thanks!
<pekuja> Verterok, I'm pretty much doing everything from scratch now. No errors on the log thus far. I wanted to comment again on the the BazaarConfigurationWizard doesn't close when I press Finish
<pekuja> and after I close it, it doesn't seem like BzrEclipse is aware that the project is now under version control
<Verterok> pekuja: do you get any log in the error log view?
<pekuja> yes
<pekuja> Unhandled event loop exception
<pekuja> hmn, with no stack trace...
<pekuja> also:
<pekuja> org/eclipse/jface/viewers/BaseLabelProvider
<pekuja> java.lang.NoClassDefFoundError for that
<Verterok> pekuja: which version of eclipse?
<pekuja> 3.2.2.
<Verterok> I made the latest build in a 3.3 enviroment, maybe that's the problem
<pekuja> here's the complete stack trace: http://pastebin.com/m4d651544
<pekuja> hmm, ok
<Verterok> pekuja: thanks
<pekuja> so that's produced when I press "Finish" on the project sharing wizard
<pekuja> as well as the unhandled event loop exception
<Verterok> pekuja: I'll download a 3.2 and build a version for 3.2
<pekuja> :-)
<pekuja> thanks
<pekuja> I think I'll just use bzr manually while waiting
<Verterok> pekuja: it'll take me download time + 10min (build and upload), stay tuned :)
<pekuja> nice :-)
<Verterok> pekuja: I can confirm it's a 3.2 - 3.3 compatibility problem
<pekuja> that's good news :-)
<pekuja> kinda
<Verterok> pekuja: indeed, usually I make the builds in my desktop, but it power supply died a few days ago, so I build it on my laptop that only have 3.3 installed :P
<pekuja> hah
<Verterok> pekuja: done, you should be able to install the new 3.2 compatible build from the update site
<pekuja> nice :-)
<pekuja> let's see
<pekuja> installing
<pekuja> seems to work better now
<Verterok> great!
<pekuja> the decorators don't seem to be working though :-[
<Verterok> are they enabled?
<pekuja> yeah
<Verterok> preferences --> General --> Label decorators?
<Verterok> preferences --> General --> appearance --> Label decorators?
<pekuja> ah, there we go
<Verterok> nice, :)
<pekuja> hmm, that's strange
<pekuja> I did a revert and the decorators turned off
<Verterok> indeed, it's strange
<pekuja> seems to be consistent
<Verterok> any errors in the error view?
<pekuja> hang on
<pekuja> yes
<pekuja> a bunch of "NLS unused message" warnings
<pekuja> then some errors
<Verterok> the NLS are ok
<pekuja> I'll copy paste the errors into pastebin
<Verterok> thanks
<pekuja> http://pastebin.com/m6c209d43
<pekuja> that's five error messages
<pekuja> in reverse chronological order (the last one on the top)
<pekuja> the Label Decorations for Bazaar have been disabled after that
<Verterok> pekuja: could you restart eclipse using the -clean argument? (to clean up cached classes from the previous incompatible plugin version)
<pekuja> ok
<pekuja> didn't help though
<pekuja> still running into that problem
<Verterok> pekuja: weird, I can't reproduce it
<Verterok> using eclipse 3.2, etc
<pekuja> :-/
<pekuja> basically, I just modify one of my files, save, then revert, and that happens
<Verterok> do you init the branch using eclipse or direclty from CLI?
<pekuja> using eclipse
<Verterok> s/do/did/
<Verterok> mmm...and then it failed, I'm right?
<pekuja> what failed?
<Verterok> the configuration wizard, with the previous version of the plugin
<pekuja> yes, but I did it all over again with the new version
<pekuja> hmn, that was before I did -clean though
<Verterok> oh, ok
<pekuja> I could do it over once more
<Verterok> check if the project have a .bzr/ dir at the root
<Verterok> it's easier ;)
<pekuja> yes, the revert actually even worked
<pekuja> but it produced those errors and turned the decorators off
<pekuja> oh, and so that we're clear, I'm using bzr 1.3
<pekuja> and bzr-xmloutput 0.4.2
<Verterok> ok, any bzr >= 1.0 should work
<pekuja> and like I said, even in Eclipse, the revert actually does work
<Verterok> I recently commited a fix to xmloutput, but not yet realeased a tarball, it's related to missing command, so it should no bother here
<pekuja> can you determine anything from the backtraces?
<Verterok> pekuja: ok, I'm creating a new workspace, project adding files, etc. a trying to revert
<Verterok> pekuja: there is a NPE but it should keep working.
<pekuja> strange
<Verterok> indeed
<pekuja> hmn, by the way, if I turn the decorators off to begin with, I get less errors
<pekuja> I only get "An error occured while traversing resources."
<pekuja> seems to be the same as before
<Verterok> please, fill a bug report with the stacktrace(s) I'll work on this during the weekend, and try to get it fixed as soon as possible
<pekuja> bug report filed: https://bugs.launchpad.net/bzr-eclipse/+bug/219427
<Verterok> pekuja: thanks, I'm still unable to reproduce it
<pekuja> :-/
<pekuja> odd
<Verterok> yes, it's
<Verterok> pekuja: are you using a particular encoding?
 * Verterok trying to guess what's going on
 * Verterok must leave
<Verterok> pekuja: I'll be back on this issue in a few hours
<Verterok> pekuja: thanks for the patience and good will to help me with this
 * Verterok bbl
<keithy> hello, I am interested in seting up the repo layout in the manual...
<keithy> the one in which the top level is commented thus # The overall repository, *and* the project's mainline branch
<bob2> right
<pekuja> Verterok, particular encoding?
<pekuja> Verterok, the code is ascii I guess, but my system is set for utf-8, if that's what you mean
<keithy> how does the dedicated server handle user/permissions?
<keithy> or is it totally public
<pekuja> Verterok, oh, and I should mention, I'm also using the PyDev module. coding in Python
<pekuja> Verterok, I probably should had mentioned this earlier. Anyways, I just tried this with a Java project instead, and it seems like the same problem occurs
<pekuja> Verterok, I also got this error in addition, in an error dialog window too: "An internal error occured during: "[Bazaar] Refreshing resource status "."
<andresj> hello. I just installed bzr 1.4rc1 using easy_install, but when I try to branch, it shows me a traceback ending in "ImportError: No module named bz2". any ideas on how to fix this? I don't know how to get the bz2 module
<keithy> I want a repo with releases in, that can form the basis of other projects
<keithy> so I can start a project, with a checkout from the releases project
<keithy> how does one acheive this?
<andresj> keithy: so each release can be used to form other projects?
<keithy> esy
<keithy> yes
<keithy> I am not sure whether to make all of my projects as separate branches or separate repo's
<andresj> what is recommended is to have a shared repo.
<keithy> on the one hand it says creating repos is light weight, on the other the dedicated server only serves one repo
<keithy> a shared repo?
<andresj> at least that
<andresj> 's what I got from reading the manual xD
<keithy> I have set up a server
<keithy> as a central repository
<keithy> I have 4-6 releases of a product
<keithy> and I have an add on which I want to test in all 4-6 releases
<keithy> and then serve the "product+addon" releases
<andresj> oh...
<keithy> I amnot sure what having separate repos gives you over havin separate branches
<andresj> mm.. well i guess I would do this: /repo/project/ for trunk, /repo/project/releases/1.2 for normal versions, /repo/project/releases/1.2/with-<addonname> for the special versions. (not putting the "releases" part if you will not create branches)
<keithy> that might work
<andresj> :D
<andresj> keithy, about having separate repos over separate branches for different projects, I think that the central repository should have only the official (stable) development, branches and releases. But it is, in the end, your own convenience.
<andresj> *that decides it.
<keithy> so there is no need to have separate repos really then
<andresj> yes.
<keithy> I always consider branches to be versions of the same thing
<keithy> but lets say I introduce "addon2"
<keithy> normally I would start a separate repo for the addon2 project
<andresj> why?
<keithy> but you suggest just making that a branch of /repo/project/releases/1.2/wth-addon2
<andresj> yes.
<keithy> why because the terminology isnt clear as to what the difference is between arepo and a branch
<keithy> on the one hand it says creating a fresh repo is lightweight indicateing that different projects should have separate repos
<beuno> keithy, the way I do it is have one directory per project  (one that shares some common revisions), let's say, "/bzr_devel/", and I have all the branches I use in there, "/bzr_devel/bzr.trunk", "/bzr_devel/bzr.1.2", "/bzr_devel/bzr.new_feature", etc
<beuno> that way
<andresj> mm... mainly a repo is just a container, useful for saving space if you have shared history.
<beuno> you optimize space usage
<beuno> and branch faster
<beuno> so you don't duplicate more information than necessary
<andresj> keithy, I use different repos for different projects for local development.
<keithy> k
<keithy> can you put symbolic links in the repo tree?
<andresj> mm... i'm not sure. I know they can be added just like files, but I'm not sure if they can link to brancehs themselves.
<keithy> so  /repo/project/releases/1.2/wth-addon2  can be accessed at /addon2
<beuno> keithy, well, that would be outside the repo, so it's fine
<keithy> oh I meant
<beuno> I'm not sure what happens when you version a symlink
<keithy> so  /repo/project/releases/1.2/wth-addon2  can be accessed at /repo/project/addon2
<beuno> I know it's suppose to work, but it always seemed scary to me  :)
<andresj> beuno: from what I remember, it should work well
<beuno> yes, it should
<andresj> so, anybody know where to get the bz2 module? :D
<keithy> so... a branch doenst have to be a variant it can be a completely new thing
<andresj> if im not mistaken, `bzr init my-branch`
<beuno> keithy, yeap, it can be a new thing
<beuno> but, in that case, it doesn't use the shared-repo, as it doesn't have common revisions
<keithy> ah
<keithy> ok
<keithy> interesting
<keithy> in a -notrees repo
<keithy> are all the files in the .bzr directory?
<keithy> thats a bit worrying it looks empty
<beuno> keithy, yeap
<beuno> it saves up space
<keithy> can you move directories around in a repo?
<keithy> (clients might get upset)
<beuno> keithy, yeap
<keithy> but can you do it?
<andresj> keithy, I'm not sure of what you mean by "can you move directories around in a repo?". but I think you could write a plugin to make your repository update its files every time something is committed to it.
<beuno> (I assume you mean directories with branches)
<keithy> can I arbitrarly rename a directory (branch)
<beuno> yeap
<andresj> how? xD
<andresj> *beuno
<beuno> andresj, when you branch within a shared repo, it know where it's storing the revisions, on the parent dir
<beuno> so it shouldn't matter if you rename the branch dir later on
<keithy> if I have a branch that is a subdirectory how do I prevent its files being in the parents project do I have to add it to ignore file?
<beuno> keithy, bzr ignores sub-directories with .bzr in them
<beuno> so it doesn't get versioned
<keithy> aaahhh
<keithy> light dawns
<beuno> :)
<andresj> xD
 * beuno goes find food
<keithy> I forgot the notrees option can I add it later?
<andresj> keithy: I think the remove-trees command will do the trick.
<keithy> ty
<keithy> is there a bzr-gtk mac os x installer  - I dont want to have to install a g worth of xcode tools on my server
<i386> keithy: if you download from the bzr website the .dmg
<i386> inside there is a qt based gui for bzr
<keithy> btw the macports installation doesnt work
<keithy> where is it?
<keithy> I installed that package
<keithy> I tried the mac os x insaller now I get
<keithy> bzr status
<keithy> Unable to load plugin 'qbzr' from '/Library/Python/2.5/site-packages/bzrlib/plugins'
<keithy> bzr is toast
<keithy> hmm the qt based gui is not exactly a binary
<jml> Odd_Bloke: you around?
<jml> Odd_Bloke: so, I was having a look at your bzr-removable branch.
<jml> Odd_Bloke: basically, it OOMs on big repos with lots of branches.
<jml> memory increases linearly
<jml> nothing you do seems obviously wrong though, so I'm looking into BzrDir.find_branches.
<keithy> this QT thing is a nightmare to install
<keithy> how can I remove the qt plugin from bzr
<keithy> bzr reports cant find qbzr
<keithy> and barfs
<keithy> reinstall doesnt fix it
<jml> Odd_Bloke: yep. BzrDir.find_branches actually *does* try to open all of the branches before returning.
<spiv> jml: it's the bzr-svn plugin
<spiv> jml: or rather, the python-svn bindings it uses
<spiv> jml: bzr-removable doesn't OOM if I remove bzr-svn
<grutte_pier> keithy: i'm not sure how mac works, but on *nix the location where the plugin is looked for is not the one you showed
<spiv> jml: also, I have an unmerged patch on the list to make find_branches a generator
<spiv> jml: which makes the plugin start giving results faster
<grutte_pier> keithy: Python/2.5/etc should maybe be Python2.5/etc??
<ubotu> New bug: #219489 in bzr "setup.py puts bzrlib in wrong place" [Undecided,New] https://launchpad.net/bugs/219489
<emgent> morning sabdfl :)
<matid> Hello there!
<matid> Do you guys know what's the state of bzr-git plugin?
<matid> It keeps throwing 'Unsupported protocol' error at me ;)
<jelmer> matid: it's incomplete
<jelmer> matid: I hope to be working on it over the summer
<matid> jelmer: Ah, cool. Looking forward to your work then ;)
<sabdfl> morning emgent
<Stavros> hello
<Stavros> where can i get the bzr ubuntu repo key?
<james_w> Stavros: there isn't one I'm afraid. It's currently not possible to sign those repos.
<Stavros> oh :/
<Stavros> i guess my ubuntu server will have to keep sending me mail :/
<andresj> hello. I am using bzr to manage my website. I have a central repository that is world-readable, and a production repo/branch that is live in my website. There is one file that I want to manage with bzr in the live website (database info, etc.) but I do not want to include in the central, public repository (a security risk). Any ideas?
<sabdfl> andresj: a sub directory that is in a different branch?
<andresj> mm... that might do it xD although it would seem a bit unnecessary.
<andresj> (the complication of having a separate dir, I mean)
<andresj> well that seemed to do the trick.  thanks sabdfl
<andresj> ;D
<andresj> how do I de-ignore a kind of files? I want to include .so files in my branch, but they are ignored by default.
<sabdfl> andresj: what happens if you add then explicitly
<andresj> sabdfl: it still ignores them.
<andresj> sabdfl: it is in my ~/.bazaar/ignore by default.
<james_w> sabdfl: 1.3.1 is in hardy now
<Odd_Bloke> jml: Thanks for having a look at it. :)  Looks like we can blame Subversion though (provided spiv's testimony is accurate :p).
 * Odd_Bloke returns to massive idling.
<andresj> hello. I have two branches. I created "production" first, and then `bzr branch production official`. Now I want "official" to be the parent of "production" instead of the other way around. How can I do this?
<james_w> andresj: you can edit ".bzr/branch/branch.conf" in each
<james_w> "bzr pull --remember" will work for production.
<andresj> james_w: ok. thanks. I'll do that.
<andresj> wait. james_w, is there a limitation for editing and commiting changes in my "production" branch when using pull? (without sending it to the official just yet)
<james_w> I'm not sure I understand what you mean
<andresj> mmm... are branches done with "pull" any different from other branches?
<james_w> nope
<andresj> ok then :D perfect. thanks james_w.
<keithy> Hi, I have finally, (It took almost a day!) installed the Qt thingy, how do I actually use it?
<Verterok> keithy: try with, 'bzr qlog'
<keithy> I have a shared server
<keithy> when I look at the files on this server -notrees , I cant see anything
<keithy> I cant even see which repos have stuff in
<keithy> how can I browse to see what I can checkout?
<keithy> k , qlog and qbrowse work
<keithy> interesting
<keithy> The whole experience has convinced me that c++ and static languages are really crap
<keithy> wait a whole day to compile it all up, for very little result.
<Verterok> keithy: to checkout, you should find the branch you want (you can't do partial checkouts...yet)
<keithy> how can I find the branch I want, I cant see anything
<Verterok> it's a public url?
<keithy> yes
<keithy> well public to me
<Verterok> ok, you should look for a .bzr/ dir
<keithy> I am not running a dedicated server yet, so its sftp
<keithy> ok.
<Verterok> .bzr is located at the branch root
<keithy> ok
<keithy> but there is nothing visible in the .bzr dir
<keithy> noting that identifies the manifest contents etc
<keithy> I just have a tree of 10 .bzr directories
<keithy> I cant remember which ones I have filled up and which are still empty
<keithy> in hg you just use a web browser
<keithy> and hunt around
<Verterok> to see the contents, do: bzr ls <branch>
<keithy> ah
<Verterok> there are a few web interface for bzr
<Verterok> loggerhead, bzr-web
<keithy> ok
<keithy> bzr ls sftp://server/repo  doesnt list the contents
<keithy> Lets lok at those
<Verterok> is "repo" a shared repository?
<Verterok> ls works on branches
<keithy> yes
<keithy> I want to look in the repo to see what is available
<Verterok> keithy: the repository is only for space efficiency
<Verterok> in the repo, you should have a set of folders, each one of those should be branches
<keithy> k
<Verterok> keithy: do you have bzrtools installed?
<keithy> at present my users have to know what they are wanting
<keithy> yes I think so
<Verterok> bzrtools provides a "branches" command :-)
<keithy> bzrtools is not showing up
<keithy> in the commandline
<keithy> is it a binary?
<keithy> thanks for you help Verterok
<Verterok> keithy: it's a plugin
<Verterok> keithy: http://bazaar-vcs.org/BzrTools
<keithy> k logger hear looks ok
<keithy> loggerhead
<keithy> I feel a bit dirty running a pythin process on my machine
<keithy> python*
<keithy> I got unlucky with the first python book I bought I guess
<Verterok> it's a nice language (at least to me)
<Verterok> at the start, the identation thingy feels a bit weird but after a while it's so natural
<keithy> It has operators ont he class side which should be on the instance side and too many exceptions to rules
<keithy> is it String leght or something like that
<keithy> length*
<keithy> anyhow now is not the time...
<keithy> hmm so it looks like loggerhead wants python2.4
<Verterok> keithy: I never installed loggerhead, sorry I can't help you with that
<keithy> why does everything assume I have a 1g Xcode installation
<keithy> I need some sleep IU am gettting cranky
<keithy> If I instal Xcode on ym server that uses 1G of my bandwidth allocation
<keithy> hasnt anyone heard of binary installs!
<Verterok> keithy: loggerhead needs XCode?
<keithy> it uses TurboGears which is trying to recompile some python plugin
<floam> hm, what's the deal with rspush, I can use it once, but then if I try to rspush again it tells me the remote spot isn't a bzr checkout or is missing .bzr -- I have to delete it and rspush from scratch each time
<floam> any idea what that might be?
<floam> er, actually it says: "bzr: ERROR: Remote location is not a bzr branch (or empty directory)"
<keithy> so I have to install Xcode on three machines just to get anything working
<Verterok> keithy: loggerhead should be only in server, right?
<keithy>  and my Xcode is for leopard! and my server is tiger arrgh
<keithy> linux is taking over the asylum
<Verterok> keithy: bzrweb should be more easy to install (I never tried it, but I suppose)
<Verterok> floam: sorry, I never user rpush.
<floam> I'd use just push-and-update like I do on other projects, but I can't install bzr remotely this time
<Verterok> beuno: ping ^^
<Verterok> beuno: what is the status of the plugin to update remote trees?
<Verterok> floam: beuno, could help you. I remember he have a similar workflow
<beuno> Verterok, hey
<beuno> floam, the bzr-upload is usable
<beuno> it's just in beta stage, so it might have it's caveats
<beuno> https://launchpad.net/bzr-upload/
<Verterok> beuno: Hi, and thanks
<floam> oh, is rspush supposed to have problems
<floam> I'll look at bzr-upload
<beuno> floam, there are a few of us already using it, and have run into very little problems
<beuno> but please report any bugs/features you need
<keithy> can I just get the files from a branch without any history, so as to get a fresh start?
<floam>   File "/Users/floam/.bazaar/plugins/upload/__init__.py", line 249, in upload_tree
<floam>     from_tree = self.branch.repository.revision_tree(rev_id)
<floam> UnboundLocalError: local variable 'rev_id' referenced before assignment
<floam> hum
<floam> this just doesn't seem very working
<floam> floam@aaronbox ~/S/KCP> bzr upload sftp://kimblecohnpartners@kcp.lofiart.com/kcp.lofiart.com
<floam> Uploaded .htaccess
<floam> bzr: ERROR: No such file: '/kcp.lofiart.com/.htaccess.tmp.1208645761.062813044.28433.1984642031': [Errno 2] No such file
<Verterok> keithy: you can do a lightweight checkout
#bzr 2008-04-20
<floam> beuno: was I using it right?
<floam> I was guessing on the sftp sytnax
<floam> syntax
<beuno> floam, syntax is correct
<beuno> is kcp.lofiart.com a directory?
<floam> yes
<floam> ~/kcp.lofiart.com
<floam> does it need to be absolute?
<beuno> floam, probably, yes
<floam> oh, weird
<beuno> are you still getting the unbound error?
<floam> most stuff is just relative to your home. I'll change it
<floam> no
<floam> I only got that once
<beuno> hm, that's add...
<floam> I think that's when I tried just foo@foo.com:foo
<floam> like rsync
<floam> it actually tried a local directory
<beuno> ah, could be
<floam> ok, it might now be working when I give the full path from /.
<beuno> :)
<beuno> next time you do bzr puload
<beuno> *upload
<floam> oh shoot
<beuno> it will just upload whatever files where changed since the last upload
<floam> it finished and it worked, but I get that UnboundLocalError agaain.
<beuno> floam, could you report a bug on that?
<beuno> I'd like to look into it
<beuno> with a "bzr info" and "bzr status" on the branch you are trying to send
<beuno> plus the traceback
<floam> okay
<beuno> thanks  :)
<floam> https://bugs.launchpad.net/bzr-upload/+bug/219739
<ubotu> Launchpad bug 219739 in bzr-upload "Getting an UnboundLocalError" [Undecided,New]
<beuno> floam, thanks so much!  I'll try and work on that tomorrow
<beuno> floam, what does "bzr info -v" say?
<beuno> meh, never mind
<beuno> it's enough with what you posted
<beuno> I'll look into it
<floam> https://bugs.launchpad.net/bzr-upload/+bug/219739/comments/1
<ubotu> Launchpad bug 219739 in bzr-upload "Getting an UnboundLocalError" [Undecided,New]
<beuno> floam, :)\
 * beuno runs off offline for a while
<toasterfun> If anybody here tried git (vcs), why is bazaar better?
<toasterfun> has tried*
<ubotu> New bug: #219754 in bzr ""bzr missing" is slow" [Undecided,New] https://launchpad.net/bugs/219754
<gotgenes> How does Bazaar handle symbolic links? Could it follow them and add the files to the repository/track them?
<jblack> bzr became a gnu project? Awesome!
<keithy> shame
<Odd_Bloke> keithy: 'shame' in what sense?
<keithy> I prefer mit
<keithy> and mit gpl aren not compatible
<Odd_Bloke> Well, bzr was licensed under the GPL long before it became a GNU project.
<bob2> also gpl and mit are compatible, leaving the derived work effectively gpl
<Odd_Bloke> Well, that's kinda the point. :p
<Odd_Bloke> So I'm getting some really weird test failures ATM.  The BzrDir.open_containing* tests are failing in a non-deterministic manner with "error: (55, 'select/poll returned error')".  Initial pokings suggest that this is something to do with the port number of the URL returned by TestCaseWithMemoryTransport.get_readonly_url...
<Odd_Bloke> And am kinda wishing it wasn't 7am on a Sunday morning, because everyone else is asleep. :p
<Odd_Bloke> Well, it appears that the issue happens on more than the open_containing tests, though still seems to be BzrDir-local.
<Odd_Bloke> Oh, no, it's happening all over the place.
<sabdfl> thanks james_w
<ubotu> New bug: #219832 in bzr "KnitCorrupt: corrupt: incorrect number of lines while branching from svn" [Undecided,New] https://launchpad.net/bugs/219832
<joh> Hi, I was wondering how stable the bzr-eclipse plugin was. Anyone here got some first-hand experience?
<hsn_> me me
<joh> hsn_: bzr-eclipse? Tell me about it :-)
<hsn_> its stable enough for production, there are some small bugs
<joh> Ok, how is it compared to Subclipse?
<hsn_> i never used it
<joh> Cause on the website, it says bzr-eclipse is alpha...
<hsn_> we are using it in production for months
<hsn_> some operations still needs to be done from command line
<joh> Ok? Like?
<hsn_> merging
<joh> Ok
<hsn_> and bzr st and bzr diff is better from command line too
<hsn_> unless you have large changes per commit
<hsn_> gui diff works
<joh> Ok? Cause the diff in eclipse is very nice.
<joh> Alright, thanks :-)
<hsn_> its too slow for me. i am keeping command line window open and use bzr diff
<hsn_> slow -> lot of clicks
<joh> :P
<emgent> heya people
<Vadi> How can I make bzr nano instead of vim?
<Daviey> Vadi: change the EDITOR enviroment variable
<Vadi> Daviey: Thank you
<Daviey> export EDITOR=nano
<Vadi> Excellent. Thank you very much
<Daviey> add to .bash_rc for long term
<Daviey> ~/.bash_profile, probably better
<Vadi> Added to both!
<Daviey> groovy
<Vadi> :)
<dato> Daviey: (nb, ".bashrc")
<Daviey> dato: yeah.. i thought that once i pressed enter :/
<dato> :)
<floam> I take offense to everybody assuming bash
 * dato uses zsh
<jelmer> floam: somebody not familiar with the EDITOR variable is probably using bash since it's the default shell on the major linux distros and bsds
<jelmer> floam: so I think it makes a lot of sense to assume bash in this case
<jelmer> and I should mention I'm also a zsh user :-)
<Vadi> How can I completely remove bzr from a directory in order to start over?
<Vadi> I've messed up and somehow even managed to get data loss.
<mwhudson> Vadi: rm -rf .bzr, but be careful before doing that :)
<Vadi> Alright thanks
<poolie> hello
#bzr 2009-04-13
<nbjayme> hello all.  I have a couple of projects and each is using a different email address. How do you configure different email address on a per repository/project? (Thanks in advance).
<lifeless> bzr help configuration - you want to set stuff in ~/.bazaar/locations.conf
<nbjayme> thanks i'll have a look at it.
<lifeless> bzr whoami will let you test if its set
<nbjayme> it worked!  thanks so much, lifeless.
<lifeless> my pleasure
<mrooney> Is an export slower than a checkout?
<mrooney> It seems to be, I am wondering I should be using a checkout and removing the .bzr dirs?
<juanje> Hi, guys, anyone here know about bzr-svn?
<juanje> I got a weird issue....
<juanje> http://pastebin.ubuntu.com/150006/
<juanje> Error says something about bugs fixed, but just two of them
<juanje> I don't know if this is global issue or just because those two bugs (launchpad ones) closed are already closed but there are some comments after the closes...
<juanje> this happens in both, but the status is still "Fix Released", so doesn't seem so...
<juanje> I checked the logs and there are a lots of other bugs fixed, before and after those two and didn't say nothing about them
<speakman> hi folks!
<speakman> If i've branched a project and made some changes, and now the projects trunk has also made some changes; is there any way to pull the trunk once again and then put my changes on top of that?
<bob2> pull in bzr implies one side is a subset of the other
<bob2> so you need to merge
<speakman> how about update?
<bob2> 'update' in bzr has nothing to do with the repository or branch
<speakman> really..?
<bob2> it just updates the working copy
<speakman> oh, I see! of course!
<bob2> I'm not sure aht you're trying to do - are you concerned about the 'log' output after you merge in the trunk?
<speakman> I prefer pulling my friends branches, yes.
<speakman> (then they get the credits in the log output)
<bob2> they get credit anyway - the log includes all the revisions merged or pulled
<speakman> can't rebase do something here?
<bob2> you're making this very hard...:)
<speakman> bob2: yes, but it won't show unless you do bzr visualize or bzr log --long
<speakman> :D
<wgrant> vanilla 'bzr log' shows merged revisions.
<bob2> bzr log -n0
<bob2> and only as of 1.14
<bob2> before then, bzr log showed them too
<juanje> speakman: I usually do 'bzr pull [the_other_branch]' or 'bzr merge --pull [the_other_branch]' for that
<speakman> Launchpad doesn't show merged revisions ;)
<bob2> surely your own comit message is "Merge from Foo Bar", anyway
<juanje> speakman: yes, but you have to click somewhere
<juanje> i don't rememeber where, but you can see it
<speakman> Doing "pull" it's a much nicer log output :)
<juanje> that happens to me once
<juanje> yep
<bob2> in short: the sane, simple way is to use "merge", you could use rebase if you really wanted, but rebase has all sorts of sde effects
<lifeless> speakman: you can use rebase; however rebase turns tested code into untested code
<speakman> side effects?
<speakman> oh, i see
<wgrant> And rebase is also very inconvenient if your branch is public.
<speakman> point taken; rebase isn't a very good idea
<speakman> there are more than me and my friend using this lp project
<bob2> are lp branches append only?
<speakman> I'll just use bzr merge --pull instead
<bob2> speakman: and since pull won't work, that's the same as 'bzr merge'
<speakman> no, bzr push --overwrite could do whatever you like
<speakman> bob2: exactly; do pull if I can, else merge. Easy as that :)
<juanje> speakman: I you see this branch (http://bazaar.launchpad.net/~freemix-dev/freemix/head/revision/17) there is a merge from one branch of me, but it didn't show well. But if you click on the '16.1.6 freemix' you'll see all my revisions that were merged
<LarstiQ> bob2: no, they're not
<lifeless> bob2: lp branches are the same as anywhere else -its configurable
<bob2> LarstiQ: its not?
<lifeless> bob2: 'lp branches;
<LarstiQ> lifeless: you don't have direct access to the lp branch.conf I don't think?
<lifeless> LarstiQ: yes, you do
<LarstiQ> hmmm :)
<bob2> via sftpz?
<LarstiQ> handediting and uploading? yuck
<speakman> juanje: but here https://code.launchpad.net/~freemix-dev/freemix/head you won't see your changes. Launchpad should handle that better IMO, since most free software are built on credits.
<bob2> speakman: merge commit messages should have the credit within them
<juanje> speakman: yes, I though so, but actually are there, you can see if you click in the right place, but yes is a bit hiden
<juanje> speakman: http://bazaar.launchpad.net/~freemix-dev/freemix/head/changes/16.1.6
<juanje> speakman: there you can see now my commits merged
<juanje> speakman: all the 16.1.? revisions
<speakman> bob2: yes, that's true
<speakman> But also; a simple merge is nothing of value itself; it's what's merged what's interesting for the log
<juanje> speakman: actually, when there is not problem with pull, all the changes are fully integrated (with credits) in my trunk, the only problems is when I have to do merge
<speakman> juanje: you're on to same "problem"
<speakman> The PQM does a better job imo: https://code.launchpad.net/~bzr/bzr/trunk
<bob2> pqm does everything as a merge
<bob2> isn't that the opposite of what you want?
<speakman> But If you change the commit messages to "Merged from Jelmer" etc, then it isn't that valueble
<bob2> "merged foo bar baz from Jelmer"
<johnf> would it make sense to anyone that bzr 1.14 now has a zlib build dependency which it didn't have previously?
 * johnf is about to go hunting in revision log
<speakman> How about making a certain switch to "bzr merge" which automatically reuses the log messages of the merged branch?
<bob2> how would that work?  you might be merging a thousand revisions
<speakman> Then don't use the switch ;)
<lifeless> speakman: I think an option klke that mght be good
<lifeless> I'd start with a plugin that wraps merge though, see if you can get the kinks out, then propose the logic as a patch to merge/pull --merge/whatever
<lifeless> johnf: yes
<lifeless> johnf: its the new compressor, we use zlib directly as well as via python
<johnf> lifeless: cool, just wanted to check before adding the build depends
<jrydberg> lifeless: how's performance these days?
<lifeless> jrydberg: pretty good; the new format (beta in 1.14) is 20 times faster at a bunch of things; and 1/3 the disk space utilisation
<bob2> --development?
<speakman> You would make GvR rethink his choice of Mercurial ;)
<jrydberg> lifeless: cool. how is it on large trees?
<lifeless> jrydberg: 1.0->0.4 seconds for commit on some very large trees
<lifeless> O(logN) scaling for tree size, diff time proportional to change size etc
<lifeless> I have to go though, can't chat right now :(
<lifeless> bob2: --development-rich-root
<speakman> lifeless: sent a blueprint just to not let it be forgotten: https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log :)
<lifeless> speakman: we don't really get driven by blueprints
<lifeless> speakman: either file a bug, or write some code :)
<johnf> LarstiQ: you about?
<LarstiQ> johnf: nish
<LarstiQ> johnf: we're going to pack our stuff into the car now, and leave Breakpoint in an hour
<LarstiQ> johnf: if you have clear ideas about bzr-svn ppa, go ahead
<johnf> LarstiQ: heh. I've just uploaded bzr and bzrtools to ppa. You want to do newest version of bzr-svn?
<johnf> Yeah I might try the old method and if it's too much hassle use same process as bzrtools and bzr
<LarstiQ> johnf: I can, but not today, might take a couple of days.
<LarstiQ> johnf: k
<johnf> thanks
<johnf> I'll check it out
 * LarstiQ packs
<OllieR> say i have /srv/bzr/project1 should I be doing cd /srv/bzr bzr init-repo at the top level "above" all my projects directories or should I do bzr init-repo within each project sub directory?
<lifeless> OllieR: doesn't really matter
<OllieR> lifeless: the bzr help page says - "Purpose: Create a shared repository to hold branches."
<lifeless> yes
<lifeless> its optional though
<lifeless> branches can be created regardless
<lifeless> and performance will not change greatly whether you have one repo per project or one for all
<OllieR> right the real reason for asking this is because I am trying to work out how I will setup my directory structure
<OllieR> "New branches created under the repository directory will store their revisions in the repository, not in the branch directory." - this may make perms trickier?
<OllieR> basicially I have /srv/bzr/private and /srv/bzr/project/
<OllieR> correction /srv/bzr/public/
<OllieR> so the public dir will have tree and will be accessible via http (apache) so that a user could do a checkout
<OllieR> I would also then like to enable certain people write permissions to certain branches/projects
<OllieR> is this just a case of chowning my bzr branch as necessary?
<OllieR> if I do bzr init-repo then it says my revisions are stored in a repo and no the branch dir itself, well that could make permissions very difficult to setup
<OllieR> I haven't setup a multi bzr setup like this before so really just after a bit of guidance to point me in the right direction :)
<fullermd> Yes, you end up only really being able to set perms at repo granularity.  All or nothing.  Branch-level differences could protect against accident, but not malice.
<fullermd> Also, if you're web serving /srv/bzr/public/ and the branches there are using a repo at /srv/bzr/, they won't be web accessible anyway since the repo can't be seen.
<OllieR> fullermd: good point
<OllieR> ok so essentially I should setup separate repos for each project and then I can grant commit access to trusted parties for that whole project
<OllieR> If I had one repo for all projects then I would restrict myself to being able to grant commit access to every project or no projects which is no desirable
<fullermd> Roughly, yah.  Comes to threat models; if you can read the repo, you can read anything in it, no matter what branch (and you can heuristically guess where branches head out at)
<OllieR> yep so i defnitely want multiple repos
<fullermd> If you can write to the repo, you can pretty much write OVER anything in it, so even if you couldn't change a branch's idea of the rev that's its head, you can change the contents of that rev.
<lifeless> fullermd: well, signed revisions prevent that - data deletion is much more likely a vector
<SamB> why is bzr/bzr-svn asking me for a username+password to access https://freedos.svn.sourceforge.net/svnroot/freedos/freecom ?
<SamB> hmm, at least if I just hit enter it works fine ...
<SamB> jelmer: any idea?
<OllieR> SamB: it doesn't ask for a username/pass for me ...
<OllieR> for bzr branch or via http (browser)
<lifeless> SamB: try nosmart+http
<SamB> well, that was via svn-import ...
<lifeless> SamB: its a change in tip bzr-svn which got backed out - see the list for details
<SamB> ah
<lifeless> what happens is that bzr POST's to probe for a smart server
<lifeless> and the server is giving 401
<lifeless> which isn't strictly true, but all-the-same
<lifeless> bzr then prompts for credentials
* You're now known as ubuntulog
<fullermd> lifeless: signed revs would only help in very limited circumstances.
<jelmer> SamB: latest bzr.dev / bzr-svn 0.6 ?
<jelmer> SamB: sf is probably requesting authentication for POST requests
<SamB> jelmer: yeah, latest
<SamB> also how come "bzr svn-import https://freedos.svn.sourceforge.net/svnroot/freedos/freecom" leaves me with freecom/freecom/{trunk,branches} ?
<SamB> (after hitting "enter" those extra two times, of course)
<jelmer> SamB: should be fixed now (0.6 branch)
<rocky> hrm, i need something a little higher level than a Transport to munge with security :/
<jelmer> rocky: are you trying to do security for stuff inside of a bzr versioned tree?
<jelmer> rocky: or rather security on a per-branch basis?
<rocky> jelmer: ok... let me tell you what i have and what i want...
<rocky> jelmer: i've created this very simple http browser thing that acts like mod_svn whereby you can browse any directory whether it's bzr versioned or not .... and as you go into sub folders, if one of them is a branch, it starts displaying the branch's latest revision file listing as if it were just another directory
<rocky> and you can go deeper into the tree whether it's a branch or not and it looks the wsame
<rocky> *same
<rocky> now i want to control read and write access based on a path that may or may not go into a branch's tree info
<rocky> at the Transport level, i have no notion of the working tree
<rocky> which is a problem
<rocky> jelmer: for an example of what i'm doing ... take a look at http://dev.serverzen.com/bzr/  and drill down until you get to a trunk dir
<OllieR> is it possible to convert a tree less shared repo to one with a tree?
<rocky> didn't think repos could have working trees
<jelmer> rocky: sorry, was away for a bit
<jelmer> rocky: ah, yeah
<jelmer> rocky: You're using something like Branch.basis_tree() to find the tree?
<jelmer> rocky: or do you mean using the bzr smart server?
<rocky> jelmer: i'm using Branch.basis_tree() for browsing the tree, yes ... but, if you browsed through you can see that it gives a bzr url ... that bzr url works against the same server, my little server is smart enough to hand bzr smart http requests to the bzr smart http server app\
<rocky> so my little server is essentially a tree browser and a bzr smart server
<jelmer> rocky: ah, neat
<jelmer> rocky: yes, Transport is the wrong place for fine-grained auth
<rocky> so now, i want to do url-based security
<rocky> for both tree browsing and bzr smart server requests
<jelmer> rocky: but if you let users retrieve revisions using the smart server
<jelmer> they'll get the full tree anyway
<rocky> i don't mind that the url-based security can only go as deep as the branch
<jelmer> you can't let them retrieve parts of the revision as bzr doesn't support partial checkouts yet
<rocky> actually, just discussing this has made me think i can do all of this without worrying about bzrlib's security at all
<rocky> i can implement all security checks right in the wsgi layer if i don't care to go deeper than branch roots
<jelmer> rocky: right
<rocky> jelmer: i'm building this for my own use to make it easier to manage bzr servers with my ClueMapper suite ... hopefully this will be useful to others as well
<jam> morning all
<jam> vila: how's it going?
<jam> jelmer: I've been having trouble trying to convert the latest python trunk branch via bzr-svn 0.5.4
<vila> jam: as an Easter Monday ? Back from a bicycle ride, passing around before dinner ;-)
<jam> ah, I thought you might have today off, I wasn't sure
<vila> jam: what about you ? Neither friday nor monday ?
<jam> vila: it isn't a governmental holiday, so no official days of from canonical
<vila> haaa, yeah, of course
<jelmer> jam: hi
<jam> hey jelmer
<jelmer> jam: What sort of trouble?
<jam> I've been getting quite a few failures, so I'm not really sure where to start
<jam> If I use "svn-import" it runs for a couple hours
<jam> but then dies with:
<jam> AssertionError: Tried registering <CachingRevisionMetadata... as parent while ... already was parent
<jam> If I try to just convert "python/trunk" I get:
<jam> TypeError: Bit 1 of ('2160@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk%2F', u'Lib')...
<jam> which means that something in bzr-svn is trying to use a "key"
<jam> which has unicode in it
<jelmer> jam: there's an open bug about the first issue
<jelmer> jam: not sure about the second, can you provide some more details?
<jam> (I don't have any idea why bzr-svn would be trying to create a file-id with "u'Lib'" as the revision id)
<jam> jelmer: "bzr init-repo --develompent6-rich-root test; bzr branch http://svn.python.org/projects/python/trunk test/trunk"
<jam> I have the feeling we have been silently allowing a bad file_id, revision_id combo
<jam> in older formats
<jam> and now the --dev6 is being more strict about only allowing 8-bit strings
<jelmer> jam: ok, trying to reproduce now
<jelmer> jam: I can't see any obvious places where we would be specifying wrong text revisions
<jam> jelmer: so the backtrace is here:http://paste.ubuntu.com/150280/
<jam> Which at least makes it looks like the code is failing
<jam> because it has generated an exception
<jam> which it is then trying to "prettify"
<jam> (make pretty)
<jam> and the report_inventory_contents is passing some bad paths
<jelmer> jam: hmm
<jelmer> jam: the bit that is failing is in the (file_id, basename) -> file_id map
<jelmer> jam: that's the cache that's only provided by CHK Inventories
<jelmer>         parent_id_basename_index = getattr(self.old_inventory, "parent_id_basename_to_file_id", None)
<jelmer> jam: it seems reasonable that basename is a unicode string
<beuno> jelmer, any fix yet for the AbsentContentFactory error?
<jelmer> beuno: which error?
<jelmer> beuno: I mean, what bug are you referring to?
 * beuno seraches for the bug #
<jam> jelmer: that probably does make sense. I'm pretty sure at the CHK map layer, basename would be a utf-8 string, but I could understand that we should be abstracting that away somewhere inbetween
<beuno> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
<jelmer> jam: ah, encoding it as utf8 makes sense I guess
<jam> jelmer: my guess is that CHKInventory should be doing an encode before passing it lower
<jam> though I think bzr-svn is going after it directly
<jelmer> jam: ah, yeah - CHKInventory is indeed encoding to utf8
<beuno> jelmer, 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
<jam> jelmer: CHKInventory._parent_id_basename_key
 * jelmer tries with utf8
<jam> does an encode('utf-8')
<jelmer> beuno: probably better to ask spiv, I have no idea about that bug
<jelmer> jam: with the encode("utf-8") it seems to work better
 * jelmer commits
<jelmer> (and fast, converted almost 1k revisions already)
<jelmer> jam: r2852
<jam> jelmer: bzr-svn trunk?
<jelmer> jam: 0.6 branch (http://people.samba.org/bzr/jelmer/0.6)
<jelmer> or substitute 0.6 for bzr.dev
<jelmer> (which is a symlink)
<jam> jelmer: so what is 0.6 vs 0.5?
<jam> Is there a format bump in there I should be cautious of?
<jelmer> jam: no, no format changes
<jelmer> jam: 0.6 depends on a few new patches in bzr.dev
<jelmer> jam: and takes advantage of some of my pending patches
<jelmer> jam: (although it doesn't require them)
<jelmer> jam: so, if things work linearly then I can do an import of python trunk in under two hours now
<jam> jelmer: from what I've seen, it isn't quite linear.
<jam> also, have you pushed up 2852?
<jelmer> yeah, 2852 has been pushed
<jam> k, it wasn't just a second ago
<jam> I still don't see it
<jelmer> should have been
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.6 ?
<jam> hmm... I seem to have the launchpad mirror
<jelmer> abentley: hi
<jelmer> abentley: I thought there was a noticable speed differences between trees and inventories, is that not true?
<abentley> There should not be.
<abentley> jelmer: ^^ tree operations should have the same speed as an inventory operation that provides the same guarantees.  Obviously, WorkingTree.get_file_sha1 can't be as fast as InventoryEntry.sha1 (or whatever it's called)
<jelmer> abentley: ah, thanks
<jelmer> abentley: I'll change things to use a tree then, seems better than to use premature optimization
<jelmer> s/use/do/
<jelmer> anyway
<abentley> So what's this code actually doing?  It looks like it's handling renames, but why does it assert no adds or removes?
<abentley> jelmer: It's remapping file-ids, right?
<jelmer> abentley: yeah
<abentley> jelmer: Can I recommend apply_inventory_delta?  It removes the ordering constraints and avoids generating an inventory on dirstate trees.
<jelmer> abentley: the "dpull" operation will have created an exact copy in the remote repository with the same contents but with different file ids
<jelmer> abentley: this code changes the local working tree to use the file ids in the remote repository
<jelmer> abentley: what would that do to unversioned files in directories that are removed using the inventory_delta?
<abentley> jelmer: inventory deltas only affect the inventory, not the filesystem.
<abentley> do all the file-ids change when you dpush, or only the ones for recently-added files?
<jelmer> abentley: only the ones for recently-added files; the current remapping is suboptimal in that regard
<abentley> jelmer: It doesn't sounds like a directory could become unversioned in update_workinginv_fileids.
<jelmer> abentley: well, in case of the inventory delta we'd have to delete the directory with the old file-id and re-add it with the new file-id
<abentley> jelmer: But if it did, the unversioned file would stop being mentioned in Tree.extras or anything else that lists unknown files.
<abentley> jelmer: You would have to delete the inventory entry for the directory with the old file-id and re-add it with the new file-id.  You wouldn't need to delete the directory itself.
<jelmer> abentley: right, that makes sense
<abentley> You could actually use a TreeTransform for this.  In fact, I think you could use WT.revert.
<abentley> Though I guess that would revert any uncommitted changes.
<abentley> jelmer: The advantage of TT is that file-ids aren't authoritative identifiers.  So you can do tt.unversion(trans_id); tt.version_file('file-id2', trans_id)
<abentley> And it will calculate the inventory delta for you.
<abentley> And apply it, of course.
<rocky> jelmer: hey, the only problem with defining the security layer on top of wsgi is that i cannot differentiate between a read and write bzr smart request
<pygi> rocky, what, you :p
<rocky> =P
<pygi> rocky, did you thikn of new things?:D
<pygi> think*
<rocky> pygi: i just finished adding dir-browsing support ... you can take a look at http://dev.serverzen.com/bzr/
<rocky> pygi: now i'm trying to fix up the security ini stuff
<pygi> rockstar, per-repo security?
<pygi> and groups support?
<pygi> rocky, and what kind of difference do you see between bzr branch url and Bzr Path URL?
<pygi> rocky, and did you fix it for 1.13?
<rocky> pygi: sorry stepped away a sec... trying to do per-branch security
<rocky> no groups support yet
<pygi> rockstar, wouldn't per-repo security allow me to do say ~mario, ~rocky and stuff?
<rocky> and the difference between branch url and path url is that you might be several levels deep in a branch so the path url will change but the branch url will ot
<pygi> ups
<pygi> rocky*
<pygi> :)
<rocky> what diff would per-repo and per-branch security do there?
<pygi> well, I create ~mario repo, so user mario can create branches in there?
<pygi> without need for additional configuration?
<jelmer> jam: fwiw a python import (41k revs) now takes 7474.116 seconds here, so just a little bit over two hours
<pygi> (even if that is called abusing repos, but oh well :P)
<jelmer> jam: are there any plans to provide integration for the memory profiler you and mwh wrote?
<rocky> pygi: oh yeah... that would be good to have but is still a bit separate from the security stuff i'm talking about... why would that be abusing repos?
<pygi> rocky, cause repos are supposed to be used for branches that share similarities :p
<rocky> ohhh right
<jam> jelmer: right now I'm purely latency bound, on a 6 year old machine
<rocky> yeah ;)
<jam> so I'm not sure how long... but it should be pretty flat :)
<pygi> rocky, SIGHUP support is in?
<jam> jelmer: I'm not sure what integration we'll end up doing
<pygi> or am I still to do it?
<jam> I might tie something into 'trace.debug_memory()'
<rocky> pygi: well, we could do it a little more like launchpad and make it so you'd do ~rocky/project1/mybranch so ~rocky would just be regular dir and project1 would be the repo
<rocky> pygi: still waiting on you :)
<jam> jelmer: what would *you* like to see?
<pygi> rocky, I like that idea about ~user/project/branch
<jelmer> jam: "bzr selftest --memprof=foo.callgrind" or something along those lines
<jelmer> or bzr --memprof=foo.callgrind branch <...>
<jelmer> writing out the state at the moment bzr is termiunated
<jam> jelmer: when would you dump it? At the peak, at the end, periodically?
<pygi> rocky, ok, you'll have sighup patch by tomorrow hopefully then
<rocky> jelmer: any clues on how i'd distinguish between a read and write request over a http bzr smart server request? (in the wsgi layer)
<jelmer> jam: at the end
<jelmer> rocky: sorry, I'm not familiar with the http bzr smart server
<jelmer> jam: at the peak would be ideal, but it's hard to say what the peak was until bzr has terminated
<rocky> i think i may still have to go back to the transport level for that :(
<jelmer> rocky: you might want to talk to spiv about this
<jelmer> jam: being able to send a SIGQUIT and then easily dumping the memory profile somewhere could also work
<rocky> spiv: ping.... :)
<jelmer> jam: if it's just "import memprof; memprof.dump_trace('foo.callgrind')"
<jam> jelmer: ^| from memory_dump import scanner; scanner.dump_gc_objects('foo.dump')
<jam> at them moment
<jelmer> jam: ah, nice
<jelmer> jam: that's several degrees better than the other profilers I've looked at in the past
<jam> the dump file is currently still json only
<jam> but I have a 'runsnakerun' patch that allows it to be loaded directly
<jam> I'd like to get it in callgrind output, but it takes some thinking
<jam> as dump_gc_objects() is meant to be as lightweight on memory as possible
<jam> (i think it currently costs about 20kB)
<jam> scaling O(num_objects) hurt me with stuff like heapy
<jam> since I had 1GB already...
<jam> there are 2 dump functions, ATM, based on whether you want to use a set while dumping
<jam> my test showed it took about 60MB to dump 600MB
<jam> which is ok, but depends on your needs
 * rockstar curses at pygi for turning his tab blue
<pygi> rockstar, :P
<lifeless> rocky: you can't distinguish in the wisgi layer, you have to use the smart request layer to tell
<lifeless> rocky: transport is overly low, many smart verbs are not directly transport related
<rbriggsatuiowa> using bzr diff --old b1 --new b2 # how do I get a list of the files that changed?
<rbriggsatuiowa> rather than all the changes themselves
<lifeless> rbriggsatuiowa: you need bzr st for that, but it doesn't have old and new. instead do
<lifeless> cd b2
<lifeless> bzr st -r branch:b1
<rbriggsatuiowa> thanks
<rbriggsatuiowa> thanks
<lifeless> spiv: ping
<rocky> lifeless: yeah so now i'm doing a combination of transport level and wsgi layer level
#bzr 2009-04-14
<spiv> Morning.
<poolie> hello lifeless, spiv
<lifeless> spiv: we really need to finish that fix off; will it benefit from pairing
<spiv> lifeless: just paging it back in after the break...
<poolie> spiv, lifeless, i'm planning to be pretty short with mail this morning and then do fetch progress and bugs
<spiv> lifeless: so I'm about to send the client-side fix to the list for review; it's basically the same patch as before, but the fix is duplicated to InterDifferingSerializer too.
<lifeless> ok
<spiv> lifeless: (I'm not thrilled by the duplicated code in InterDifferingSerializer, but then I'm not thrilled about InterDifferingSerializer existing in the first place)
<spiv> lifeless: and I have the server-side fix that I need to add tests for
<jml> merging/pulling in changes that delete directories sucks.
<spiv> lifeless: the big outstanding item is NoSuchRevision errors from the server when doing recreate_search on a vanilla SearchResult
<lifeless> spiv: ack on both points about IDS
<spiv> lifeless: I haven't yet dug into exactly what's going on there, maybe these patches will fix it, but I suspect they might not.
<lifeless> spiv: indeed
<spiv> lifeless: it appears there's a problem that the client, which sees the full graph, has a different len(included_keys) to the server
<lifeless> spiv: that would make sense
<spiv> if the search spans the stacking boundary.
<lifeless> the client knows where the keys came from; it could choose to split the search differently
<spiv> I'm not sure what we should do there; perhaps in the client, if the server is stacked and the server gives NoSuchRevision, it could switch to asking for the ancestry-of the heads and then fetch the missing bits elsewhere?
<spiv> Or as you say ask only for the right keys in the first place.
<beuno> spiv, hi. Do you have any news on 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
<spiv> lifeless: so I'm not sure that pairing is necessary, but if you want to start tackling that part while I finish off the bits I've got, that would be extremely helpful.
<spiv> lifeless: What I have should fix initial pull, but I'd expect the NoSuchRevision flavour could happen if there's already a local repo... I suppose a workaround would typically be "update your trunk branch in that repo then try pull/update of the affected branch again".
<spiv> lifeless: Also, while it's a related bug, I'm going to give the NoSuchRevision bug its own bug report I think.
<spiv> beuno: that's just what we are talking about right now :)
<lifeless> beuno: its been easter
<spiv> beuno: in short: I have a candidate fix to stop the client creating broken branches, and also another fix for the server to stop unfixed 1.13 (and 1.14rc1) smart clients from making broken branches.
<beuno> yay
<beuno> thanks
<beuno> I keep having to downgrade to 1.13 to work on launchpad
<LeoNerd> So... debian updated my bzr/bzrtools, and now I have the new shelf format.. how do I get at my old shelved data? :)
<lifeless> LeoNerd: shelve1
<LeoNerd> Ahhh...
<spiv> lifeless: I've filed bug 360791
<ubottu> Launchpad bug 360791 in bzr "get_stream on stacked branch causes "Error received from smart server: ('NoSuchRevision',)"" [Undecided,New] https://launchpad.net/bugs/360791
<beuno> rockstar, if you're around. Do you know what this would be happening with bzr-autoreview?  http://paste.ubuntu.com/150478/
<rockstar> beuno, jaunty
<beuno> rockstar, python 2.6?
<spiv> lifeless: Having written that bug report I'm pretty much certain its a separate bug introduced by the get_stream verb.
<rockstar> beuno, yeah, it's python 2.6's fault.
<beuno> rockstar, is it launchpadlib?
<lifeless> spiv: yes, I agree
<james_w> beuno: "apt-cache policy python-httplib2"?
<beuno> james_w,  Installed: 0.4.0-1
<beuno>      0.4.0-0ubuntu2 0
<beuno>         500 http://archive.ubuntu.com jaunty/universe Packages
<james_w> beuno: err, where does it say 0.4.0-1 comes from?
<beuno> james_w, ah. Launchpad deps
<beuno> PPA
<james_w> please let whoever controls that PPA know about best versioning practices
<beuno> james_w, ironically, it's celso  :)
<james_w> you can "sudo apt-get install python-httplib2=0.4.0-0ubuntu2" for now
<james_w> heh :-)
<beuno> james_w, thanks
<beuno> works now
<lifeless> spiv: I think I'll do for BzrDir.get_config what I did for Branch.get_config
<lifeless> spiv: to keep moving the ratchets
<igc> morning all
<beuno> hiya igc
<igc> hi beuno
<beuno> how's it going igc?
<igc> beuno: pretty tired actually - slept most of the last 4-5 days
<SamB> jelmer: why do your branches for bzr-svn have to have version numberes?
<SamB> er. numbers.
<beuno> igc, sorry to hear that  :/
<beuno> will we be seeing you at all hands?
<jelmer> moin
<jelmer> SamB: ?
<SamB> jelmer: apparantly I've been stuck on the 0.5 branch without realizing it!
<jelmer> SamB: ah, you mean the release series?
<jelmer> SamB: you can use the 'bzr.dev' branch, which symlinks to whatever release series works with bzr.dev
<SamB> do I just use --overwrite with pull to switch?
<SamB> considering that I have no local commits?
<igc> beuno: no unfortunately - I'm still unable to travel for a while
<igc> hi jelmer
<jelmer> SamB: yeah, and --remember
<SamB> jelmer: why not have lp:bzr-svn -> lp:~jelmer/bzr-svn/bzr.dev ?
<SamB> besides the fact that that's a bad URL
<SamB> jelmer: what's a URL that will always be for bzr.dev ?
<jelmer> SamB: lp:bzr-svn already points at the 0.6 branch
<jelmer> SamB: but bzr stores the expanded URL, not the short one
<SamB> exactly
<jelmer> SamB: what URL lp:bzr-svn points at depends on the active release series
<jelmer> SamB: and there is no 'bzr.dev' release series, only 0.4, 0.5, 0.6, etc
<jelmer> SamB: anyway, http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev should always works
<SamB> heh
<SamB> jelmer: so ... why *don't* you have a bzr.dev series ?
<SamB> bzr does
<poolie> spiv: happy birthday to mary (i think)
<jelmer> SamB: because I don't actually have a separate 'main development' branch like bzr
<SamB> you could just split off your numbered branches after release ;-P
<jelmer> SamB: but I do actually keep working on these branches for a while when I do minor release
<SamB> I noticed
<SamB> otherwise I wouldn't have needed --overwrite ;-P
<SamB> hmm ... I'm still getting asked for username/password :-(
<jelmer> SamB: see the recent thread on the mailing list
<jelmer> SamB: bzr does a POST request to the HTTP server first
<jelmer> and the server replies with a 401 Auth required reply
<SamB> jelmer: oh, I thought you said it should be fixed?
<jelmer> SamB: where did I say that ? :-)
<jelmer> SamB: you can work around the issue by removing get_smart_medium() at bzrlib/transport/http/__init__.py:142
<SamB> <jelmer> SamB: should be fixed now (0.6 branch)
<SamB> about 12 hours ago, I think?
<jelmer> SamB: ah, that was the prefix issue for svn-import
<SamB> oh!
<SamB> heh
<SamB> did you know that jelmer sometimes says ambiguous things? you should fix that ;-P
<spiv> poolie: yes :)
<jelmer> SamB: :-P
 * SamB wishes firegpg wouldn't invoke gpg --import synchronously ...
<SamB> or whatever that option actually is
<jelmer> lifeless: so, now that it's tuesday..
<jelmer> lifeless: Any chance you can have a look at my InterBranch.pull() patch ? :-)
<SamB> jelmer: what do you mean? it won't be tuesday for about two hours and 6 minutes yet!
<lifeless> jelmer: yes, I will try to
<poolie> spiv, do you want me to review your bug 354036 patch? or is lifeless going to?
<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
<spiv> poolie: I hope lifeless will, but another pair of eyeballs is certainly welcome!
<lifeless> spiv: done
<spiv> lifeless: thanks
<spiv> lifeless: it's not immediately obvious to me how to make a good helper function, because the I find the parents in the two different code paths is pretty different.
<lifeless> the variable names, or the data?
<spiv> lifeless: in RepoFetcher we just ask the target after we've inserted the stream, but in InterDifferingSerializer it's a bit messier... perhaps it doesn't need to be.
<spiv> In InterDifferingSerializer I reuse the Revision objects that we already have (in pending_revisions), for instance.
<lifeless> parent data should be either cheap, or cached
<lifeless> I'd use the same code
<spiv> And also I'm doing this before the revision objects are inserted.
<lifeless> uhm
<spiv> Which has the nice property of making sure all the inventories are there before the revisions that depend on them.
<spiv> But perhaps that's not so important?
<lifeless> interdiffering topological anway
<lifeless> bah, insert missing words
<spiv> And letters ;)
<spiv> But even working topologically, if we do "insert inventories; insert revisions; insert the other inventories needed by those revisions", then there's a window when we have nearly-but-not-quite complete data there.
<lifeless> indeed, and agreed
<spiv> Which maybe doesn't matter, because probably if anything goes wrong it'll abort the write group, etc.
<lifeless> can't depend on write groups in this code
<lifeless> uhm
<lifeless> ok, go without a helper
<lifeless> but we want to get to pre-checking it everywhere, or something like that
<spiv> Yeah.
<lifeless> any idea about
<lifeless> SmartMessageHandlerError: The message handler raised an exception:
<lifeless> Traceback (most recent call last):
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 1034, in done
<lifeless>     self.message_handler.end_received()
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/message.py", line 161, in end_received
<lifeless>     self.request_handler.end_received()
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/request.py", line 345, in end_received
<lifeless>     self._run_handler_code(self._command.do_end, (), {})
<lifeless> AttributeError: 'NoneType' object has no attribute 'do_end'
<spiv> Huh, no.
<spiv> Something is resetting _command prematurely?
<lifeless> dunno yet
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 893, in accept_bytes
<lifeless>     _StatefulDecoder.accept_bytes(self, bytes)
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 388, in accept_bytes
<lifeless>     self.state_accept()
<lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 998, in _state_accept_expecting_message_part
<lifeless>     self.done()
<lifeless> I think its the unknown verb handling on the server
<spiv> Hmm, it could be, yeah.
<spiv> I thought that was tested, but perhaps there's a gap.
 * SamB ponders the various difficulties sure to be involved in any attempt to use bzr-svn in DOS ;->
<thumper> igc: Composite tree review pring
<thumper> s/pring/ping/
<igc> hi thumper
<igc> thumper: I'm half way through - hope to finish today
<thumper> igc: that's great, thanks
<lifeless> I'm still really unsure that a different tree class is the right approach
<lifeless> it just seems to move the complexity around
<lifeless> and adds to it
<thumper> lifeless: in which case you really need to talk with abentley and others about this
<thumper> I don't know enough to give intelligent answers
<thumper> but I want to make sure we have a good story here
<lifeless> thumper: I have talked to aaron about it; we disagree
<lifeless> doing it with an external object means we have to have a index for subtrees, and that adds complexity.
<lifeless> iMNSHO
<lifeless> OTOH aaron has working code and thats important
<lifeless> the big thing is to make sure that  there are no performance regressions as the changes land in trunk
<thumper> I think that we are in agreement on that last point
 * igc lunch
<lifeless> spiv: branch done
<lifeless> spiv: onto the next one after a short break
<lifeless> spiv: man, I found another cheap win
<spiv> lifeless: hooray
<lifeless> on the order of 12 round trips
<lifeless> !
<lifeless> running the full test suite now to find issues
<lifeless> well, some stuff breaks
<thumper> lifeless: what are you working on that you found 12 round trips?
<vila> hi all
<lifeless> performance
<lifeless> thumper: I don't have enough info to answer what I think you are asking
<thumper> lifeless: <lifeless> on the order of 12 round trips
<thumper> lifeless: HPSS something or other>
<thumper> ?
<lifeless> well yes, everything is hpss
<thumper> lifeless: I'm just curious
<thumper> lifeless: just wondering if push/pull is going to get faster
<lifeless> thumper: thats the idea :)
 * thumper pokes lifeless in the eye for being obtuse
<thumper> lifeless: it seems you are trying to read too much into my curiousity
<lifeless> thumper: it will get faster as we fix more things; I'm investigating a possible improvement at the moment; it doesn't work so its not an improvement
<lifeless> and I *don't know* what it changes
<thumper> that seems kinda weird
<lifeless> that I don't know?
<fullermd> Pshaw.  This is software; since when is 'working' a necessary ingredient?
<lifeless> fullermd: when you have users
<lifeless> thumper: I don't know because we still have over 50 different method calls on common use cases
<lifeless> thumper: and its hard to tell what actually changes when you tweak something and 10 or so dissapear
<lifeless> I specifically moved around the set_parent method on Branch, thats all
<lifeless> until I diff the network traffic, complete the test run, and so on - its all speculation; and I try to avoid speculating
<lifeless> thumper: also please, enough with the eyepoking, its unpleasant imagery
<lifeless> thumper: so I can answer now, while I still don't know why, getting rid of the set_parent method on RemoteBranch gets rid of 6 hpss calls in our same server use case
<lifeless> and in our push --stacked use case
<speakman> lifeless: Regarding https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log are you willing to guide me where to start, and hopefully I could contribute with code some day?
 * igc dinner
<lifeless> hmm, I'm going to write some code
<lifeless> speakman: well, I'd start with a plugin myself, because I could create a new command, tweak it until it does what I want and get some people to try it out
<lifeless> if its liked, the logic can be yanked out as a patch for bzr  itself
<speakman> plugin sounds like a good idea. But I've never written anything for bzr(lib), so is there any existing plugin you'd recommend tweaking instead of start a new from scratch?
<lifeless> uhm
<lifeless> my plugin-info plugin is nice and small
<lifeless> you could use that as a template for a plugin
<lifeless> and grab the code from bzrlib.builtins.cmd_commit as a starting point for your own command
<lifeless> https://edge.launchpad.net/bzr-plugin-info is the plugin I'm referring to
<lifeless> spiv_: didn't you do a coverage option for selftest?
<james_w> speakman: there's actually a hook to seed the commit message offered to you in the editor
<james_w> so you could create a plugin to provide that hook, and then plain "bzr commit" would offer you an editor with that message that you could edit to your liking
<james_w> would that suit you?
<speakman> I'm sorry for beeing a bit off, but I'm currently at work
<speakman> lifeless: I'll definitly check that plugin out! Thanks alot!
<speakman> james_w: Sorry for not understanding, but what is "seed the commit message" really?
<speakman> and "the editor"?
<speakman> oh, the diff and stuff of course.
<james_w> when you run "bzr commit" with no "-m" argument you are given an editor window to provide the commit message
<james_w> that editor can be "seeded" with a message, but normally isn't
<speakman> --with-diff does seed it?
<james_w> nope
<james_w> that makes changes below the "Everything below this line will be ignored line"
<speakman> (i'm not really sure what "seed" really means. I'm no english expert :) )
<lifeless> speakman: 'prepare'
<james_w> you can also make changes above it
<speakman> lifeless: okay! thanks!
<james_w> so that if you do nothing and save and quit the message that was "seeded" will be used
<speakman> james_w: wow! is there anything that utilize this already?
<james_w> bzr-builddeb is the only thing that I know about
<speakman> But then again; I have no clue how hooks works in bzrlib, and I'm pretty short of sparetime for a while :(
<james_w> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py
<james_w> the "debian_changelog_commit_message" function
<speakman> Great thanks! I really hope to contribute more self-going in the feature. People are talking about bzrlib as an example how beatiful Python code could be. I probably have alot of thing to learn when getting me into the bzrlib code.
<jelmer> moin
<james_w> speakman: something like http://paste.ubuntu.com/150747/
<james_w> morning jelmer
<james_w> speakman: save that code as ~/.bazaar/plugins/merge_commit.py and give it a test
<james_w> speakman: oh, it needs "from bzrlib import msgeditor" at the top
<vila> lifeless: the coverage option is global, not specific to selftest
<speakman> james_w: great thanks! I'll try it as soon as my job ends for the day.
<lifeless> vila: yes I've found it. Its now what I want
<lifeless> *not*
<vila> ok
 * vila goes back to tweaking pronto.tell_me_what_tests_run_me()
<spiv_> lifeless: no, I did a global --coverage option
<spiv> (it was originally just for selftest, but it was simpler to as a global, and potentionally useful too)
<lifeless> spiv: do you happen to know of code to go from line number in a py file to method ?
<lifeless> night all, I'll finish this tomorrow I think
<spiv> lifeless: possibly the inspect module has something, otherwise I don't know of any off-hand.
<lifeless> spiv: not needed
<lifeless> trace has what I wanted, just different params
<spiv> lifeless: cool
<lifeless> at least for this part of my plugin
<lifeless> I'm generating an index of function -> test
<lifeless> its a little long to do lineno->test
<lifeless> anyhoo, will finish tomorrow
<vila> lifeless: you do that for all functions or just on demand
<lifeless> vila: selftest --index
<lifeless> vila: then selftest --changes uses the index
<vila> changes since the last --index ?
<lifeless> since the last commit
<lifeless> must go, very tired
<rahul>  Wanna get your pic on magazine cover??? http://techbuddha.blog.co.in/2009/04/14/wanna-get-your-pic-on-magazine-cover/          --            http://techmaharshi.blogspot.com/
<awilkins> "K-lined" : not seen that in a while
<awilkins> <nelson>Ha-ha</nelson
<jelmer> beuno: is there any loggerhead release in the pipeline?
<beuno> jelmer, oh, I really do want to make a release
<jelmer> beuno: including the start-loggerhead -> serve-branches transition?
<beuno> jelmer, that's the blocker. No config yet
<jelmer> beuno: ahh
<rockstar> beuno, I have a secret plan to re-write large parts of loggerhead.
<jelmer> beuno: any rough idea on when that would be possible?
<jelmer> beuno: (one of the alioth maintainers is asking me for a backport)
<beuno> jelmer, I could make a release anyway
<jelmer> beuno: well, I'm mainly interested in doing the backport *after* the changes
<beuno> rockstar, I hear that, really looking forward to it
<jelmer> as they will affect users
<beuno> jelmer, after the start -> serve migration?
<jelmer> beuno: yeah
<beuno> jelmer, ok. I have had zero time to work on that  :(
<rockstar> beuno, you heard already?  I guess it's not a secret plan then.
<beuno> rockstar, well, unless it's something different than the wholehistory and revnocache bits
<jelmer> beuno: no worries, I was just wondering what the status was on that
<beuno> it can be *our* secret
<beuno> jelmer, "stalled", but mwhudson and rockstar are working on all kinds of places
<rockstar> beuno, drastically different.  wholehistory is not going to be trivial to remove without ripping out all sorts of things.
<beuno> rockstar, oh!  interesting
<jelmer> beuno: ah, thanks
<jelmer> rockstar: wholehistory?
<rockstar> jelmer, wholehistory cache is the bane of loggerhead's existence.
<jelmer> ah, teh cache
<rockstar> jelmer, I'm almost positive that it's the reason loggerhead leaks memory.
<jam> rockstar: well, IIRC when talking with mwh at pycon, we found the problem wasn't strictly the whole-history cache, as much as the 3-4 copies of it
<jam> which is some of the stuff we uncovered with the memory_dump stuff
<jelmer> whoa
<jelmer> merge pulls the revisions for the other tree into the this repo
<luke-jr> jelmer: uh?
<jelmer> if you run "bzr merge" in a subversion working copy (with .svn directories)
<jelmer> it will push the pending merges into the repository, but that happens to be a remote svn repository
<jelmer> and revisions are always visible in svn
<cody-somerville> doh
<cody-somerville> I imported a git branch to bzr
<cody-somerville> and its clearly missing files and whole directories :/
<jelmer> cody-somerville: how did you import it?
<cody-somerville> jelmer, git fast-export --all | (cd ../.bzr-repo; bzr fast-import - &> /dev/null)
<jelmer> ok, no clue then
<cody-somerville> Is there another way to do it?
<jelmer> cody-somerville: bzr-git
<cody-somerville> Is there a package in Ubuntu with that?
<jelmer> not yet
<pygi> there is an archlinux package however :p
<ronny> that doesnt fix all the other reasons for not using archlinux
<cody-somerville> lol
<pygi> ronny, :P
<pygi> ronny, like what? :D
<ronny> well, they ship a broken gvim since years
<pygi> it'd take you 5 secs to fix it... whats the problem exactly?
<ronny> and there have been other incompetence issues - like the package manager doing silent corruption
<ronny> pygi: the vim people told them many times, they dont fix
<pygi> ronny, o.O
<pygi> ronny, could you pm me, so I can do it?
<ronny> the main issue is that their custom gvimrc breaks all colorshemes
<pygi> (not in official repos tho)
<ronny> every few weeks we get a unhappy pida user cause of this, and god knows how many dont even ask
<pygi> ronny, I am just looking at the package...
<pygi> ronny, it ships with gvimrc_example.vim from vim tarball as gvimrc?
<ronny> pygi: last time i brothered /etc/gvimrc or /etc/vim/gvimrc was a custom mess of color hacks in archlinux
<ronny> the fix was to just delete it
<pygi> rockstar, ok, at least now it doesn't seem to be
<rockstar> pygi, please watch your tab completion.
<pygi> rockstar, ups, I did that yesterday too, no? :D
<pygi> ronny*
<ronny> well, shortly after that the archlinux package-manager silently corrupted my install and the package db due to absolute ignorance of a filled harddisk
<pygi> ronny, right :)
<ronny> well, end of the story is - i discourage everyone from using arch
<pygi> hehe nice :)
<pygi> do I have your forgiveness for using it then? :P
<ronny> i just discourage fro using it
<ronny> but i might commit hate-crimes against rpm based things
<jelmer> vila: hi
<pygi> jelmer, new bzr git requires 1.15?
<pygi> w00t? :D
<jelmer> pygi: yeah, bzr.dev
<pygi> meh, so I have to install that too
<pygi> so un-cool xD
<jelmer> lifeless: ping
<lifeless> jelmer: pong
<poolie> lifeless, jelmer, hi
#bzr 2009-04-15
<lifeless> hi poolie
<lifeless> I slept in this morning :)
<poolie> spiv, igc, do you want to talk?
<poolie> lifeless: i was just saying to john i woke up about 6:30 on my holiday but now i find it hard to get going
<lifeless> :)
<spiv> Sure.
<igc> morning
<thumper> morning igc
<jelmer> lifeless: what is the difference between InventoryFile.text_id and InventoryFile.file_id exactly?
<lifeless> text_id? wtf
<jelmer> lifeless: in particular, they don't ever seem to differ - can they?
<lifeless> text_id was bzr 0.0.6 and before only
<jelmer> ah, ok
<lifeless> its in the api for compatibility, you don't want to set it or consult it
<jelmer> I came across it trying to find a solution to two problems in bzr-git:
<jelmer> - ideally I'd like to use one-tuples rather than two-tuples for file texts
<jelmer> - I need a place to stash the file modes that are stored for all git files
<lifeless> what would be in the one-tuples?
<rockstar> igc, thumper was asking about an ETA for historycache.  Can you give me something specific?
<lifeless> spiv: let me know when you've done that review please
<jelmer> lifeless: blob sha
<jelmer> lifeless: that would of course bring up the problem of file graphs
<lifeless> right, bzr core doesn't do this
<lifeless> note that a blob sha != sha of the bytes
<lifeless> its sha of the bytes + git header
<jelmer> lifeless: yes, I know
<jelmer> lifeless: the blob sha is what I get from git though, for the content sha I have to fetch and unpack the blob
<jelmer> anyway, the second issue is more pressing
<jelmer> I've thought of two ugly solutions so far
<igc> rockstar: I'll try to get something out this week, but I think next week is more likely
<jelmer> storing the changed modes in a revision property
<lifeless> by file modes you mean extended permissions?
<jelmer> storing the modes in the texts for the directories
<jelmer> lifeless: unix file modes
<rockstar> igc, that's straight gangsta
<jelmer> lifeless: not sure if that's what you mean by extended permissions?
<lifeless> jelmer: broadly
<lifeless> jelmer: more than 'x' ;)
<jelmer> lifeless: ah, extended in that sense, yes :-)
<lifeless> note that we don't do more than x because extended permissions get in the way of VCS
<jelmer> lifeless: yes, I'm not arguing bzr should do more
<lifeless> I thought git didn't store full unix bits anyway, only a subset
<jelmer> lifeless: it does, but recent versions of git restrict a little bit what you can set
<jelmer> lifeless: (it does store full unix bits I mean)
<lifeless> ok
<lifeless> well
<jelmer> lifeless: In order to be able to reproduce the exact git commits from a bzr revision I need to store these modes somewhere
<lifeless> how does etckeeper store modes
<jelmer> lifeless: plaintext file in the root
<jelmer> lifeless: I'd prefer to keep this data away from the user though
<lifeless> jelmer: so you could either: special case it for git; write a general solution for bzr core and then use that; do something compatible with one of the other 'backup via vcs' tools out there and use that for bzr-git
<jelmer> lifeless: hmm
<lifeless> I'm ok with more bits being storable in bzr and our UI leaving them unset (though it implies a trinary field not a binary - unknown, off, on)
<lifeless> or a mask + bits
<lifeless> or something like that
<lifeless> [we don't want to suddenly start having the problems associated with setting overly strict modes on files we create etc]
<lifeless> this would take discussion
<lifeless> I think its worth doing
<jelmer> yeah, I think that makes sense in that this is something to keep in mind for the future
<spiv> lifeless: reviewed
<lifeless> jelmer: now is a good time as we have a new format in beta
<lifeless> jelmer: if you act fast --development7-rich-root could do this
<jelmer> lifeless: I doubt I'd have enough time for that, unfortunately
<lifeless> jelmer: well, you never know :)
<jelmer> hmm, that reminds me
<jelmer> it looks like bundlebuggy is ignoring my rio serializer patch
<jelmer> abentley: ping
<xiaohui> Hi , when I use 'bzr branch lp:opencog', I got an sokcket error, it said that that 'Connection  timed out'
<xiaohui> but I can connect to lp:opencog using browser
<spiv> xiaohui: do you have an HTTP proxy perhaps?
<spiv> you may need to set the http_proxy environment variable so that bzr uses the same proxy as your browser.
<xiaohui> yeah, I use the HTTP proxy
<xiaohui> I have set this enviroment variable
<xiaohui> hi, spiv, the tracback is :
<xiaohui>  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 846, in run_bzr_catch_errors
<xiaohui>     return run_bzr(argv)
<xiaohui>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
<xiaohui>     ret = run(*run_argv)
<xiaohui>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
<xiaohui>     return self.run(**all_cmd_args)
<spiv> xiaohui: please, use a pastebin for tracebacks, not the channel.
<lifeless> xiaohui: you should set http_proxy to "http://PROXY:PORT/"
<xiaohui> oh ,sorry spiv
<xiaohui> lifeless, that is it.
<lifeless> spiv: 9 less ;)
<xiaohui> I used ' bzr branch http://bazaar.launchpad.net/~opencog-dev/opencog/trunk', it worked
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> my ptch failed
<lifeless> incremental change:
<lifeless> mm, one more sec :P
<spiv> Heh.
<bob2> what was the initial count you knocked 14 and 9 off?
<lifeless> bob2: 6 and 9, 43
<lifeless> === modified file 'bzrlib/tests/bzrdir_implementations/test_bzrdir.py'
<lifeless> --- bzrlib/tests/bzrdir_implementations/test_bzrdir.py	2009-03-23 14:59:43 +0000
<lifeless> +++ bzrlib/tests/bzrdir_implementations/test_bzrdir.py	2009-04-15 02:01:15 +0000
<lifeless> @@ -1712,13 +1712,17 @@
<lifeless>      def test_get_config(self):
<lifeless>          my_dir = self.make_bzrdir('.')
<lifeless>          config = my_dir.get_config()
<lifeless> -        if config is None:
<lifeless> -            self.assertFalse(
<lifeless> -                isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)),
<lifeless> -                "%r should support configs" % my_dir)
<lifeless> -            raise TestNotApplicable(
<lifeless> -                'This BzrDir format does not support configs.')
<lifeless> -        config.set_default_stack_on('http://example.com')
<lifeless> +        try:
<lifeless> +            config.set_default_stack_on('http://example.com')
<lifeless> +        except errors.BzrError, e:
<lifeless> +            if 'Cannot set config' in str(e):
<lifeless> +                self.assertFalse(
<lifeless> +                    isinstance(my_dir, (bzrdir.BzrDirMeta1, RemoteBzrDir)),
<lifeless> +                    "%r should support configs" % my_dir)
<lifeless> +                raise TestNotApplicable(
<lifeless> +                    'This BzrDir format does not support configs.')
<lifeless> +            else:
<lifeless> +                raise
<lifeless>          self.assertEqual('http://example.com', config.get_default_stack_on())
<lifeless>          my_dir2 = bzrdir.BzrDir.open(self.get_url('.'))
<lifeless>          config2 = my_dir2.get_config()
<lifeless> spiv: ^ faster than pastebin ;>
<lifeless> xiaohui: I'm glad its working for you
<spiv> By the time your irc client pastes that at a rate of 1 line per 2 seconds it would have been quicker to just use a pastebin...
<lifeless> we have a known bug with xmlrpc which is a python bug
<lifeless> spiv: my browser is paged out; I have a test run indexing code by test which is making everything crawl
<lifeless> spiv: it would have been several minutes to get it up to a pastebin :(
 * spiv hands lifeless an ec2 instance
<lifeless> spiv: :) I need more glue for that though, its a plugin yada yada
<xiaohui> lifeless: what is the difference between 'lp:opencog' and the URL
<lifeless> xiaohui: lp:opencog makes a xmlrpc request to get the URL
<spiv> lifeless: seems reasonable, bb:approve
<lifeless> xiaohui: and the xmlrpc library in python does not support proxies :(
<xiaohui> so ,you mean that I should always use the URL
<lifeless> xiaohui: I think you will need to until we work around the bug yes
<xiaohui> lifeless: I see , thank you
<lifeless> spiv: and a new patch up, set_parent_location, push down to 28
<xiaohui> lifeless: that will be more convienent if it support the proxies:)
<lifeless> xiaohui: indeed, we want to fix it; need someone to have the time
<lifeless> spiv: [BzrDir.open, mkdir, mkdir, BzrDirFormat.initialize, BzrDir.open, BzrDir.find_repositoryV3, BzrDir.create_repository, Repository.set_make_working_trees, Repository.lock_write, Repository.has_revision, Repository.get_parent_map, Repository.get_parent_map, Repository.insert_stream, Repository.insert_stream, Repository.get_parent_map, Repository.insert_stream, BzrDir.create_branch, Branch.lock_write, Branch.set_config_option, Branch.un
<lifeless> spiv: do you see what I see
<xiaohui> lifeless: It doesn't matter, thank you:-)
<spiv> lifeless: I see a cut-off line :P
<lifeless> spiv: oh foo
<spiv> lifeless: ...Branch.set_config_option, Branch.un
<lifeless> , Branch.unlock, Branch.lock_write, Branch.last_revision_info, Branch.set_last_revision_info, Branch.unlock, Branch.lock_write,
<lifeless>                   Branch.set_parent_location, Branch.unlock, Branch.get_stacked_on_url]
<spiv> Nice.
<lifeless> spiv: or more, do you see what *isn't* there
<spiv> No vfs aside from two mkdirs.
<lifeless> yup
<lifeless> I'm going to drive this to vfs-free today I think
<spiv> Which, presumably, is doing the ensure_prefix or makedirs or whatever we call it.
<lifeless> yes
<lifeless> patch to get to what I pasted there is up for review now
 * igc lunch
<poolie> lifeless: google ads tell me "registry fixes are a rip off"
<poolie> :)
<lifeless> heh
<lifeless> have you tried ec2 test or parallel testing yet?
<poolie> nup
<poolie> i think it was not merged when i left and i haven't run tests since i've been back
 * lifeless encourages
<lifeless> spiv: I think we're sending too much data still
<BasicOSX> hmph, no python 2.6.2 dmg installer
<lifeless> spiv: look in bzrlib.tests.lock_helpers for __dict__ for some special code
<poolie> igc, when you say "6 seconds to branch emacs" i'm presuming that's without building a tree
<poolie> lifeless: hi, we may be getting disconnected regarding registries
<poolie> it seems to me like centralizing them may be best i guess
<lifeless> call?
<lifeless> poolie: I don't really like centralising as an option, even though I raised it; because its hostile to plugins amongst other things
<lifeless> I'm searching for a single root cause fix.
<poolie> i'd kind of rather not have a call, at least today
<lifeless> k
<lifeless> vila: ec2test broken again for knownfailure... this thing is cursed
<lifeless> spiv: poolie: I'd like a review for the patch I'm sending right now
<lifeless> it passes everything, finally
<lifeless> [sent]
<igc> poolie: no - that's 6 seconds *including* the tree build
<lifeless> igc: shared repo yes?
<poolie> wow, so that makes the multiplier even more extreme
<igc> lifeless: yes
<igc> lifeless: and an existing tree already built for the trunk/mirror branch
<lifeless> poolie: so, registries. defer till we're face to face?
<poolie> unless it's blocking you severely
<poolie> i want to reply to igc and then get out of mail etc
<lifeless> its not blocking me
<lifeless> the review I asked or is much more urgent :)
<vila> hi all
<vila> lifeless: :)
<lifeless> it may be an old branch of bzr.dev, but I don't htink so :(
<BasicOSX> Going to be using bzr on win32 over the next 18 weeks.  Windows dev wanna see how this tool I rave about works on their platform (I work linux and osx side of things normally)
<lifeless> BasicOSX: good luck!
<BasicOSX> I tend to need luck when I work on a windows box
 * vila sends more luck to BasicOSX 
<lifeless> 'the luck is in the mail'
<BasicOSX> cool, brisbane can serialize luck now?
<lifeless> bah
<lifeless> provenance, not providence
<lifeless> need dinner
 * lifeless shuts down ec2
<lifeless> poolie: I'm done for the day
<poolie> ok, good night
<lifeless> modulo one last email I'm drafting
<poolie> i need to do some personal sysadmin stuff so will sign off in a bit to do that
<igc> me dinner
<jelmer> nice
<jelmer> new estimated import time for ooo.org: 4 hours
<bob2> wow
 * bob2 remebers when it was a trillion years
<jelmer> I'm sure the git folks have never been able to achieve speed improvements of that factor :-P
<lifeless> thumper: so that thread I was tugging on has been pulled - 1.15 <-> 1.15 will do 23 roundtrips (down from over 40) to push a new stacked branch
<lifeless> jelmer: what did you chnage
<jelmer> lifeless: various speed improvements to bzr-svn over the last couple of months, and --development6-rich-root
<lifeless> its always nice when a basic-analysis + design + turns out well ;)
<jelmer> lifeless: I think this has worked out really well
<jelmer> lifeless: what's the next hot topic?
<jelmer> subtrees? parallel imports?
<lifeless> network
<lifeless> and working area ease of use
<jelmer> ah
 * jelmer mutters something about colocated branches
<lifeless> I'd like to do file copy support too but thats lower return and higher investment
<jelmer> lifeless: file copy as in file copy tracking or merge using that tracking as well, etc?
<jelmer> lifeless: ISTM file copy tracking and the mode bit stuff we talked about yesterday could well be collated
<lifeless> jelmer: I don't think they are that separated;)
<cody-somerville> lifeless, thank you thank you thank you
<cody-somerville> I hate git so much with a passion
<cody-somerville> It is so horrible
<cody-somerville> I don't know how I could live without bzr
 * pygi shoots cody-somerville 
<cody-somerville> Do I merge --squash or do I rebase? Do I patch-format or do I diff? Do I checkout, clone, or branch? To see changes in the working tree, what options must I pass to diff? -- git is confusing.
<pygi> cody-somerville, once you get accustomed to it, no its not
<pygi> and it has books to cover it up
<pygi> free ones even
<cody-somerville> bzr just works the way one expects
<cody-somerville> thats what I like about it
<stbuehler> with git i know what git is doing. with bzr i just hope it does what i want.
<pygi> each DVCS have its use-cases, and their pros and cons
<stbuehler> yep :) i still use bzr for committing to svn, i never liked the git svn support
<pygi> I like git submodules for example ... and since a lot of projects use git, I use it too
<pygi> I'm still not sure of nested branches support in bzr (and if they are in fact supposed to be something like svn:externals && submodules)
 * Kinnison uses git when forced to
<jelmer> pygi: subtrees are landing at the moment
<pygi> jelmer, oh? Bzr.dev then? 1.15 release?
<jelmer> pygi: they're similar to svn:externals and submodules
<lifeless> cody-somerville: :)
<lifeless> pygi: when complete they should be similar to gits subprojects
<jelmer> pygi: it's always hard to say, but I would guess 1.15 (Aaron has submitted nested trees for review, and review is happening atm)
<lifeless> not 1.15
<jelmer> lifeless: oh, ok - why not?
<lifeless> there are performance implications and design decisions to finalise
<lifeless> it will be a 2.0 feature
<pygi> lifeless, will that happen this year?
<jelmer> lifeless: when would 2.0 be due?
<lifeless> jelmer: when development6-rich-root has evolved to production ready
<lifeless> 2-3 months probably, maybe less
<pygi> lifeless, weren't git subprojects a "weaker" form of today's submodules?
<lifeless> pygi: dunno
<pygi> hhhhm
<pygi> stbuehler, you know perhaps? :)
<stbuehler> i did not use submodules myself yet, i only have to deal with them for debian cgit packaging
<jelmer> pygi: depends on what you mean by weak
<jelmer> pygi: they're less integrated into the core commands than the bzr subtrees afaiu
<pygi> jelmer, right...
<mgedmin> files named *.~1~ and *.~2~ -- bzr debris?
<jelmer> mgedmin: hi
<jelmer> mgedmin: yeah, bzr revert creates those files
<mgedmin> hi, jelmer
<mgedmin> ah, revert
<jelmer> mgedmin: you can use --no-backups to prevent it from creating those files
<mgedmin> use case: user cd's to a project working dir, types bzr st to make sure it's clean, types ls to look around and is scared by files named *.~1~
<mgedmin> I honestly thought there was a failed merge with conflicts or something
<mgedmin> but then remembered bzr uses .THIS and .THAT or something like that
<jelmer> a lot of editors also use files ending in ~ to indicate backups
<mgedmin> ... I don't remember running bzr revert on at least some of those files
<mgedmin> vim doesn't
<jelmer> mgedmin: if you "set backup" it will
<mgedmin> "sample-graph.png.~1~" -- I'm pretty sure I didn't edit it with a *text* editor
<mgedmin> oh, right -- this thing (lp:objgraph) was created by the setup.py script
<mgedmin> I might've run bzr revert on it
 * mgedmin looks at his sentence and wonders if it can be understood by anyone else
<mgedmin> there's a project (lp:objgraph) with a README.txt that generates graphviz graphs and wants to include sample images
<mgedmin> so the setup.py has a couple of lines to extract the doctests from the README and pipe the output through dot to produce pngs
<mgedmin> ... iirc
<mgedmin> it's a bit of a hack, really
<mgedmin> I must've run it several times (to produce new images), which overwrote some of the original images, which bzr probably noticed (png has creation time as metadata inside?) and I reverted
<vila> mgedmin: have a look at 'bzr help clean-tree', experiment with bzr clean-tree --dry-run
<mgedmin> thanks
<mgedmin> so, I've some code in my working tree I want to check in and push to a new branch on launchpad without touching the old branch
<mgedmin> what should I do?
<mgedmin> in git/svn I'd create a new branch, switch in-place, then commit
<hsn_> is there way to remove branch/project from launchpad? i would like to use lp for converting CVS into bzr
<james_w> is it just me that finds the last shelve question defaulting to "No" really odd?
<james_w> and also infuriating at times? :-)
<jelmer> james_w: no, it's not just you
<jelmer> I tend to want to shelve just one piece of code often
<jelmer> so I press "n" until I get there, then press y a couple of times
<jelmer> and then enter my way until the end
<jelmer> but often I hit enter one time too much
<james_w> yeah
<james_w> it's not a destructive operation
<james_w> at least not with --destroy
<mgedmin> how do I make bzr forget the last push location? ie. make bzr status not show a push branch?
 * mgedmin is about to edit .bzr/branch/branch.conf with trepidation, there's a scary "do not touch anything here" notice in .bzr/README
<vila> mgedmin: you can use 'push --remember <new_location>' to replace the existing one but you can't *clear* the existing one
 * mgedmin dislikes
<Tak> can you remember '.'?
<mgedmin> interesting question
 * Tak master of hackish workarounds
<mgedmin> yes you can
<mgedmin> "no new revisions to push"
<mgedmin> hey, my bzr ci --fixes lp:NNN appears to have silently ignored the '--fixes lp:NNN' bit, what gives?
<beuno> mgedmin, no, it's stored as meta-data
<beuno> not sure how you can see it with the bzr client
<beuno> but if you push to Launchpad
<beuno> you'll see Launchpad will link that bug with that branch
<mgedmin>  oh, user error: bzr ci --fixes; look at list of files; abort; bzr revert file1 file2; bzr ci<enter>
<NfNitLoop> mgedmin: oops!
<NfNitLoop> :)
<NfNitLoop> huh, I didn't know about the --fixes flag. that's cool.
<mgedmin> yeah, well, I still blame bzr :)
<glen__> does anyone know how to use bzr-gtk?  I have it installed but no clue how to "use" it
<fizzyone> hello
<beuno> fizzyone, run:  bzr-gtk
<beuno> in your terminal
<fizzyone> that is what I thought
<mgedmin> not changing your nickname every 3 seconds might work better if you want an answer
<beuno> in the directory where you have a branch
<fizzyone> no command found
<beuno> fizzyone, actually, ignore that
<beuno> you should have new commands in bzr
<fizzyone> sorry about that...  just wrestling with the client
<mgedmin> bzr viz is one of the commands provided
<beuno> "bzr help"
<mgedmin> I've never used any of the others (assuming there are some, which there probably are)
<beuno> you've also got gcommit
<beuno> again, 'bzr help commands' should say
<fizzyone> awesome thanks
<fizzyone> I have the gui up now
<beuno> all the g* stuff is bzr-gtk
<mgedmin> launchpad rules
<beuno> it does!
<jelmer> vila: ping
<marcoil> Hi, while commiting to a svn server I get "bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4", although I do have libsvn 1.5.1
<vila> jelmer: pong (not really there so except high lag:)
<vila> s/except/expect/
<jelmer> marcoil: you have 1.5.1 locally ?
<jelmer> marcoil: is subvertpy linked against 1.5.1?
<jelmer> vila: I'm trying to think of a way to avoid that 401 on POST
<marcoil> jelmer: libsvn1 1.5.1dfsg1-1ubuntu2
<marcoil> jelmer: how do I check what's subvertpy linked against?
<marcoil> jelmer: in any case, it's the one in the bzr ppa for hardy
<jelmer> marcoil: what is the server running?
<marcoil> jelmer: 1.4, I'm afraid
<jelmer> marcoil: hmm
<jelmer> marcoil: that might have something to do with it
<marcoil> jelmer: it did work last week, I'm sure of it, but I'm not sure which packages I've updated since
<vila> jelmer: hmm, 401 should be ConnectionError, I don't they are yet. From there.... ConnectionErrors may/should (need to be discussed ?) be translated into NotAbranch errors during probes... or something like that, but that should still allow prompting user :)
<jelmer> marcoil: no idea which things are out of date, sorry :-/
<jelmer> marcoil: it does work, but you probably need to upgrade some of the packages on your client machine
<jelmer> vila: so we'd have to do two passes or something like that?
<marcoil> jelmer: I'm trying to compile subvertpy, let's see if that works
<vila> jelmer: I didn't look closely at the code since that mail thread, I'm not sure doing two passes (one without auth one with) is the way to go (ISTR that we probe recursively until root for some cases, so we already have a two-dimensions probe...)
<marcoil> jelmer: manually compiling and installing subvertpy 0.6.5 did the trick! thanks
<jelmer> marcoil: np
<vila> jelmer: may be the solution is to change or allows changes to the probe mechanism, I'm not that sure we can address all the funny ways an http server can be configured....
<jelmer> vila: yeah, that's what I'm worried about too
<jelmer> vila: the quick solution for now is to probe for svn repositories before bzr repositories
<vila> I thought the quickest was to use nosmart+ :-)
<jelmer> vila: nosmart doesn't work, though svn+http does
<vila> jelmer: ? You got POST with nosmart+ ???
<vila> that's a bug in nosmart then
<jelmer> vila: no, nosmart doesn't trigger svn
<vila> that's a bug too !
<jelmer> it would even be wrong if that worked since svn is a smart server protocol too ;-)
<vila> jelmer: ha come on :-) Anyway dinner time here, I may come back later, but I think what we need is a better control of what probe does, being auto should remain the default, but having some way to tweak it by remote server will be needed in the end (whatever the smarts we put in the auto mode)
<vila> jelmer: ... and nosmart+ and svn+http are just two examples of why this is needed...
<jelmer> vila: re
<jelmer> vila: yeah, we do indeed need better control of probe
<jelmer> vila: also, for svn it's only necessary to probe the bottom-layer
<jelmer> vila: if /foo/bar/bloe/bloe is not a svn smart server then even if we can open /foo/bar/ it won't be a valid path
<jelmer> :q
<vila> jelmer: violent agreement I see :)
<ddaa> Hey jelmer
<ddaa> I'm having trouble using bzr-hg.
<ddaa> I have hg branch here, that I can do "hg st" in.
<ddaa> And I have trunk bzr-hg from launchpad with bzr 1.13.1 from jaunty.
<ddaa> But the branch directory (that contains the .hg directory) is not recognized by bzr as a branch.
<ddaa> (In case jelmer is unavailable at the time, anybody with a clue is welcome to help, too)
<jelmer> ddaa: hi
<ddaa> hi jelmer
<ddaa> I'm afraid I'm not going to be able to follow up on the test for bzr-svn. I have just quit that job at the bank.
<ddaa> Any suggestion how to debug that problem with bzr-hg?
<ddaa> I have a special hate for branch detection problems, they provide no feedback at all besides "NotABranch, get stuffed".
<ddaa> s/NotABranch/NotBranchError/
<jelmer> ddaa: pushed a fix
<jelmer> ddaa: yeah, the probe stuff could use some improvement
<jelmer> ddaa: was just talking about that with vila :-)
<ddaa> Did you push on bzr+ssh://bazaar.launchpad.net/~bzr/bzr-hg/trunk/ ?
<ddaa> Because the last commit I see there is "merge new bzr-foreign" date Sun 2009-03-22 00:33:57 +0100.
<jelmer> ah, no - pushed to my private repo
<jelmer> pushing to lp now
<jelmer> done
<jelmer> please be aware that bzr-hg is still highly experimental, moreso than bzr-svn or bzr-git :-)
 * jelmer dinner
<ddaa> When *I* was a kid, bzr was highly experimental ;(
<ddaa> I mean ;)
<ddaa> I just have a one-time import to do.
<ddaa> Gotta go offline.
<ddaa> BBL
<rotty> can I move a shelved collection of changes to another repo?
<LarstiQ> rotty: I don't know if/how to do that directly
<LarstiQ> rotty: but in combination with `bzr unshelve; bzr merge --uncommitted; bzr shelve` you could do something like it
<LarstiQ> jelmer: do you know what the impact of Standard-Version: 3.8.1 is on Ubuntu packaging?
<LarstiQ> it looks to me like I should stick with 3.8.0
<LarstiQ> jelmer: any reason you're not using compat level 7?
<rysiek|pl> hi guys
<rotty> LarstiQ: this doesn't cut it if the repo is on another machine: bzr merge --uncommitted bzr+ssh://192.168.10.1/home/rotty/src/tekuti/r6rs
<rotty> bzr: ERROR: bzr+ssh://192.168.10.1/home/rotty/src/tekuti/r6rs/.bzr/ is not a local path.
<LarstiQ> rotty: right
<rysiek|pl> guys, does bzr support https?
<rysiek|pl> as in
<rysiek|pl> bzr co https://example.com/bzr/project/branch
<LarstiQ> rotty: if you're feeling very adventurous you could try copying .bzr/checkout/shelf
<LarstiQ> rysiek|pl: yes
<LarstiQ> rotty: but that's mucking with the internals, so no guarantees there
<rysiek|pl> hmmm...
<rotty> seems I must branch into a full blown repo do the --uncommited merge, rsync that whole repo over, and merge --uncommited again, or transfer a diff and do the metadata changes by gand
<LarstiQ> rysiek|pl: maybe you have a more pointed question? :)
<LarstiQ> rotty: eh no, that's very suboptimal
<rysiek|pl> LarstiQ: deugging my apache+bzr installation, I'll try managing myself, but thanks ;)
<rotty> hmm, I could also use commit/uncommit
<rysiek|pl> LarstiQ: although if you know of any specific requirements bzr has in regards to read-only access to a branch through apache2, please do tell
<LarstiQ> rysiek|pl: read-only? You could get away with just using file backing for apache. Bit slower than possible, but very low on requirements.
<LarstiQ> rotty: the shelved changes aren't fit for commit yet?
<rysiek|pl> LarstiQ: exactly what I am trying to do
<rysiek|pl> $ bzr co https://brama.elka.pw.edu.pl/bzr/parkour/AltiShock
<rysiek|pl> bzr: ERROR: Not a branch: "https://brama.elka.pw.edu.pl/bzr/parkour/AltiShock/".
<rotty> LarstiQ: yes
<rysiek|pl> aaargh
<rysiek|pl> nevermind, I am dumb beyond recognition
<rotty> it's only one incomplete changeset
<rotty> (moving ongoing development from laptop to desktop)
<LarstiQ> rotty: commit/uncommit actually isn't that bad an idea to transfer them
<rotty> LarstiQ: I've done so now.
<rysiek|pl> LarstiQ: works AOK now.
 * rysiek|pl bangs his head agains a nearby wall
 * rysiek|pl does that - repeatedly
<LarstiQ> rysiek|pl: awww :)
<rysiek|pl> LarstiQ: using *nixes for 5+ years now and *still* run into those dumb lowercase/uppercase problems
<ronny> being conservative at naming files helps
<ronny> all things i do end up with lowercase alhpanum + spaces/dashes/underlines/points
 * LarstiQ tries to stay away from spaces.
<ronny> LarstiQ: those are for non-code things i dont track in a vcs
<LarstiQ> ronny: I grudgingly admit them in .ogg files, but as a shell user I'm leary of abusing the token seperator.
<ronny> LarstiQ: well, all stuff i consider important is in safe filenames
<beuno> man, bb hates me
<bpierre> hi
<bpierre> I'm testing EOL support in bzr.dev, and I'm having issues
<bpierre> my test can be seen here: http://pastebin.com/m6b49c245
<beuno> jelmer, we should go into a merging spree for bzr-gtk soon  :)
<beuno> I keep wanting to do that
<jelmer> LarstiQ: I don't think there was anything particularly important in 3.8.1
<jelmer> LarstiQ: so makes sense to stay with 3.8.0
<LarstiQ> jelmer: I'm guessing you switched to silence lintian? ;)
<jelmer> LarstiQ: which package?
<LarstiQ> bzr-svn
<bpierre> updated test: http://pastebin.com/m503e6b6f
<jelmer> LarstiQ: that's lintian-clean on sid
<jelmer> LarstiQ: what sort of errors are you getting?
<LarstiQ> beuno: bzr-svn 0.5.4 uploaded to bzr-beta-ppa in case you want to test it. It's still Pending publishing.
<LarstiQ> jelmer: oh I'm getting none.
<LarstiQ> jelmer: Just inspected the diff, and noticed 3.8.1 is very recent.
<beuno> LarstiQ, on my hardy server?
<LarstiQ> beuno: yes please
<beuno> LarstiQ, sure. Will try as soon as it publishes. What was that svn I could use to test again ?
<LarstiQ> beuno: svn://svn.gnome.org/svn/gnome-specimen/trunk
 * beuno waits for PPAs' cron to run
<LarstiQ> jelmer: do you think I should look into gutsy and dapper too?
<jelmer> LarstiQ: dapper will be hard as it has the old python infrastructure
<jelmer> I'm not sure about gutsy - are there still many people running it?
<LarstiQ> johnf built packages for them
<beuno> LarstiQ, it seems to me working perfectly. Taking a while to copy the revisions, but no explosions
<LarstiQ> beuno: for that I direct you to either jelmer, the svn repo admins, or your isp ;)
<LarstiQ> beuno: thanks!
<LarstiQ> jelmer: have you seen this specific KnitCorrupt error before http://rafb.net/p/Uq2Hw948.html  ?
<jelmer> LarstiQ: nope
<LarstiQ> bpierre: did you make any EOL progress?
<bpierre> LarstiQ: nope, files are correctly changed to CRLF, but my problem is they show as modified
<LarstiQ> bpierre: sounds like a bug
<bpierre> yeah, it makes EOL unusable
 * LarstiQ will peek at EOL status tomorrow, sleep now
<bpierre> I'm going to enter a bug with my test script
<bpierre> can I put rules somewhere not in ~/.bazaar/rules? or does it always have to be this file?
<jam> bpierre: there is discussion on how to handle per-tree sort of rules, *right now* we only have the global rules
<jam> also, what format are your files *now*
<jam> and what are you setting eol to?
<bpierre> jam: http://pastebin.com/m503e6b6f
<bpierre> the format of the files is what I expect
<bpierre> the problem is status/diff showing them as modified
<jam> bpierre: IIRC, crlf == crlf in the working tree *and* in the repository
<jam> I think you want
<jam> crlf:lf
<jam> or "native" but on your current system, I think native == lf
<bpierre> mmm, are you sure? I'm using the latest help
<bpierre> bzr help eol
<bpierre> crlf:lf was the previous proposed format
<jam> I see what you mean, that was just the last I saw on the discussion
<jam> I'll check the internal
<jam> internals
<jam> I know there was a bug where the eol stuff wasn't getting loaded
<bpierre> yeah
<jam> I'm not sure how that compares with the version of bzr you are testing
<bpierre> I got that with a previous version
<bpierre> it works now
<bpierre> I do see a change in EOL when switching from lf to crlf
<jam> so.... I do see in the internals that 'crlf' => _to_lf in repo and _to_crlf in tree
<jam> so that seems right
<bpierre> how does detection of file changes is handled?
<bpierre> mtime and sha1?
<jam> bpierre: I assume this is doing "bzr init --1.14" or whatever, right?
<jam> bpierre: we use mtime to avoid computing the sha1
<jam> but if mtime is updated, we should then be computing the sha1 of the text as it would be put in the repo
<bpierre> so the problem is content filtering needs to be applied before calculating the sha1
<bpierre> no?
<bpierre> or cache both sha1 (lf and crlf)L
<bpierre> s/L/?
<bpierre> because, at the end of the test, if I do a dos2unix on my file, then it's not modified anymore
<jam> bpierre: when we see an mtime miss, we should read the file and apply the filter
<bpierre> or rather it doesn't appear as modified
<jam> and hash the result
<jam> I know I've seen the patch that was supposed to change it
<bpierre> and compare to the repo sha1?
<jam> we may have missed something
<jam> bpierre: right
<jam> bpierre: out of curiosity, have you done "make" in your version of bzr?
<bpierre> mmm, I do: for cmd in config build "install --prefix=$HOME/progs"; python ./setup.py ${(s| |)cmd}
<bpierre> I checked earlier, and seems some C files are getting compiled
<bpierre> do I really need to do a make?
<jam> shouldn't have to, 'install' should do 'build' etc
<jam> you should see .so files in bzrlib
<bpierre> ah
<bpierre> make did something!
<jam> bpierre: make builds locally
<jam> you can run bzr directly from the source dir, without installing
<jam> the .so files I'm talking about should be somewhere in $HOME/progs
<bpierre> ok, so I should have everything
<jam> or run from source
<jam> :)
<jam> anyway, eol *should* work with or without compiling
<jam> I just wanted to check, as there are 2 code paths
<bpierre> ok
<jam> bpierre: can I ask you to run from source, so I can ask you to do some minor tweaks?
<bpierre> sure
<bpierre> I just need to set PYTHONPATH ?
<jam> http://pastebin.com/m5a2c1d93
<jam> bpierre: ~/path/to/bzr status
<jam> no need to set anything
<jam> just give the full path to the bzr
<jam> you can set PATH if you want to make it shorter
<jam> or you could just set $(BZR) in your script
<jam> etc
<bpierre> ok
<bpierre> jam: http://pastebin.com/m4bb3a281
<jam> bpierre: something seems to be wrong with your rules, etc after the second co
<jam> note that it doesn't give the filters during 'checkout' like it did the first time
<bpierre> ?
<jam> bpierre: line 19
<jam> well 18 + 19
<jam> versus 31
<jam> during the "bzr co" I see "computing stat_and_sha1 ...."
<bpierre> yeah, but they are applied somewhere
<jam> but I *don't* see that in the second half
<bpierre> since the content changes to CRLF
<jam> bpierre: sure, can you try doing a "touch test/work/text" ?
<jam> just to force the mtime to change
<jam> (followed by "bzr status test/work"
<jam> )
<jam> bpierre: Also, if I understand your result, it claims that "text" is modified, but then shows *0* line changes, right?
<bpierre> ok, I just tried to remove the file and then revert it
<bpierre> and it's now lf
<bpierre> jam: yes, no changes in the diff
<jam> bpierre: so it seems the hash check is missing but the content itself is getting filtered
<bpierre> it's weird, revert doesn't seem to apply the filter
<bpierre> I changed for a non-lightweight checkout, to test a remove-tree+co
<bpierre> and the file dosn't change to crlf
<sabdfl> well done folks
<sabdfl> commit on bzr.dev seems fantastically faster
<sabdfl> lifeless told me why the perf improvement hasn't trickled down to commit file1 file2 file3
<sabdfl> but i thought i should say what a great impression this will make when it lands as the default format
<lifeless> morning sabdfl
<ddaa> indeed it will be great when the standard answer to "bzr is too slow" will involve neither "you need to use the very very latest release from last week" nor "you need to use the latest non-default archive format, trust me, it's reliable".
<ddaa> actually, it will be great when people stop saying "bzr is too slow", but I expect this meme is going to take a few years to die out.
<sabdfl> lifeless: does the new commit still do, effectively, status-then-commit?
<jam> sabdfl: I believe it acts effectively like: for entry in status: record(entry)
<sabdfl> where "entry" is "something changed or added"?
<jam> sabdfl: right
<sabdfl> ok, so it's doing all the work of status, then recording
<jam> right. I don't quite remember why partial commits weren't faster
<sabdfl> what's cool is that the time delta for status vs commit  is really negligible on large trees now
<sabdfl> jam: something to do with iter_changes needing a spit and polish
<kkubasik> I was wondering, we have a bzr tree that has some (relatively large) binary files tracked in it
<kkubasik> they don't change very often, and its not a big deal
<kkubasik> but they seem to have majorly impacted the performance of most operations
<kkubasik> any advice/suggestions
<kkubasik> will bzr pack help?
<sabdfl> if this is all true, then any improvements to status will be highly visible, they straight to the commit bottom line
<sabdfl> kkubasik: doesn't hurt to try that
<sabdfl> i believe the new format would help more though, try that and report back
<kkubasik> I had read that people shouldn't run 'pack' just wanted to be sure ;)
<pygi> :P
<kkubasik> which format?
<sabdfl> kkubasik: bzr branch lp:bzr bzr.dev
<pygi> kkubasik,  development6-rich-root
<sabdfl> inside there, make
<sabdfl> then use that bzr to make a new branch of your code
<kkubasik> will do
<kkubasik> 1 sec
<sabdfl> and upgrade that to what-pygi-said
<thumper> hi sabdfl
<sabdfl> then try a few commits in there for fun
<sabdfl> howdy thumper
<beuno> kkubasik, how large are the files?
<jam> kkubasik: I'm not sure why you "shouldn't run 'pack'"
<beuno> kkubasik, also, if you're on Ubuntu, you can get the latest bzr from a PPA: https://edge.launchpad.net/~bzr-nightly-ppa/+archive
<kkubasik> beuno:  Not massive, 2 30MB .air files
<jam> It shouldn't be something you *need* to do, but there shouldn't really be harm in it.
<pygi> sabdfl, is "what-pygi-said" a new name for a bzr format? :D
<kkubasik> and 4 mpeg4's
<sabdfl> could be. dontcha love plugins :-)
<jam> the bigger question is what was actually "majorly impacted"
<pygi> I'll start loving them once jelmer renames local-branches to duck branches :p
<jam> stuff like "branch" I could understand
<jam> stuff like "bzr status" shouldn't be effected
<jam> (much)
<kkubasik> jam:  primarily commit and stat
<beuno> but, pull/merge will, because it brings in almost the full binary
<kkubasik> not incredably
<kkubasik> but like, i notice a pause now
<jam> kkubasik: what platform?
<kkubasik> and when the disk is being thrashed, you notice it much more ;)
<kkubasik> ubuntu (last LTS) and mac os x 10.5
<jam> I at least get the feeling that somehow we are missing a mtime cache, which is causing us to read the file and compute its sha1 again.
<jam> can you do a "stat" on the file and see if there is something strange
<jam> like its timestamp is set 3 days in the future
 * spiv yawns
<kkubasik> jam:  yeah will do, actually, cool if i bring this on the mailing list
<lifeless> sabdfl: the new commit is layered on the same generate that status is layered on
<kkubasik> I gotta run, but would love some help
<jam> kkubasik: sure
<jam> I'll mention that it will take a bit longer to diagnose on the list, because of latency :)
<lifeless> jam: partial commits depend on iter_changes returning parents of new entries
<lifeless> s/generate/generator/
<kkubasik> jam:  many thanks!
<jam> lifeless: ah right, I remember the thread now
<lifeless> sabdfl: thinking of it as status + commit is fine; though we skip the status UI code when doing a commit
<lifeless> sabdfl: for instance, in status we need to diff two files when there is a stat cache miss, so if we actually did layer on status we'd end up doing more sha calculations; because we just sharing the core worker
<lifeless> we just know that that file *may* have changed, and instead pass the content down to the storage layer with a flag saying 'and if it is this sha1, dont store it'
<lifeless> sabdfl: what size tree are you testing on?
<sabdfl> lifeless: you know my benchmark
<sabdfl> 1k, 5k, 10k, 50k, 100k files
<lifeless> yup
<lifeless> I remember we went sour > 10K
<lifeless> I'm wondering if that is still the case
<BasicOSX> bzr.dev revision 4294 throws all sorts of error, reported in bug 362021
<ubottu> Launchpad bug 362021 in bzr "bzr: ERROR: No such file: '<random>.pack'" [Undecided,New] https://launchpad.net/bugs/362021
<lifeless> BasicOSX: windows?
<BasicOSX> osx
<BasicOSX> testing on linux now
<lifeless> BasicOSX: tried ulduar out?
<BasicOSX> heh, guess my bug report points me out as a wow player
<BasicOSX> Yes, attempted 25-man last night
<lifeless> either that or its a serious coincidence :)
<BasicOSX> server stability issues caused us to give up
<lifeless> we had a 2 hour break while they rebooted it
<lifeless> got flame down before hand, had trouble with both xt and razor
<lifeless> BasicOSX: you're missing the directory upload
<BasicOSX> hmm, I did not do anything but install new addon, bzr add, bzr commit
<lifeless> mkdir the upload directory
<lifeless> try again
<beuno> spiv, has the AbsentContentFactory fix landed in bzr.dev yet?
<lifeless> beuno: yes
<lifeless> beuno: remember you need to repush branches to fix them
<lifeless> beuno: the fix only stops bzr *creating* the situation, it doesn't let it deal with it
<beuno> lifeless, ah!  that's the second part that's in progress?
<lifeless> beuno: no
<lifeless> beuno: there is no deal with it planned
<beuno> lifeless, uhm, why not?   if bzr 1.13 deals with it just fine?
<lifeless> beuno: andrew is now working on a fix for the server to get unfixed clients to upload more data
<lifeless> beuno: 1.13 does not deal with it
<lifeless> beuno: 1.13-client just does not call the verb when pulling from stacked branches
<beuno> I half-understand
<beuno> the end result is that I can pull/branch from it
<lifeless> beuno: but the change to the server will not affect people that don't stream up, or use sftp
<spiv> beuno: older clients don't ask the server to stream a set of revisions from a branch
<beuno> ah, I see
<lifeless> beuno: do you want to understand? if so, details coming..
<beuno> lifeless, no, gotcha
<spiv> beuno: which means the client is executing that logic, and the client has access to the fallback repository, which means it can calculate all the data
<beuno> adding a check for that specific case to not stream is not very wise overhead
<lifeless> beuno: basically there is a design flaw in stacking's 'what data goes in the stacking repo' logic since 1.6
<lifeless> beuno: that we found when we got 'stream from stacking branches' working
<beuno> understood
<lifeless> beuno: we're going to supply a script for lp to run to fixup branches hosted on lp
<beuno> makes heaps more sense now
<beuno> perfect
<beuno> just perfect
<beuno> thanks for the splainin'
<lifeless> beuno: you should run nightlies so you don't create bad branches
<lifeless> but there is nothing you can do about other peoples until we have that fix out and running after people push
<beuno> lifeless, I do run nightlies, but they break when branching, so I constantly downgrade. I could use sftp, but you know how lazyness works...
<lifeless> beuno: when you find something you can't branch from, for now, get that person to delete and repush using nightlies
<beuno> will do
<poolie> hello
<pygi> poolie, hi
<pygi> did you ever get a chance to read that short excerpt I gave you?
<poolie> hey there
<poolie> i didn't get to it before i left on holidays but it's high on my list today
<poolie> sorry for the delay
<pygi> hehe, no worries
#bzr 2009-04-16
<BasicOSX> lp's bug database hates me
<beuno> BasicOSX, or, it's down for a bit
<beuno> and will be back in ~30 minutes or so
<lifeless> beuno: should be back much sooner than that
<lifeless> its only an os reboot
<lifeless> though over a few machines
 * beuno likes pleasantly surprising people
<elmo> lifeless: dude, these are not laptops.  some of these machines take 5 minutes just to *POST*
 * thumper wonders what a POST is here
<elmo> I'm not Scotty, I don't over-estimate the downtime just for the hell of it
<elmo> thumper: BIOS POST
<ddaa>  the BIOS thing that happens before first stage bootloader
<cody-somerville> Geez... no wonder people are complaining about Ubuntu boot times :P
<lifeless> elmo: sorry
<lifeless> elmo: on the other hand, how is your scottish brogue?
 * Kinnison ruffles elmo
 * Kinnison 's new machine takes 45 seconds to get from poweron to grub, and then 15 seconds from there to login
<Kinnison> POST sucks
<owh> Salutations. I'm running Eclipse Ganymede and I'm trying to install the bzr plug-in. The plug-in itself installed fine, but step 1 in the installation instructions has me stumped: "install the bzr-xmloutput plugin" - I cannot find an Intrepid package for it. Am I missing something?
<NfNitLoop>  owh: it's likely just a .tgz
<NfNitLoop> which you drop into ~/.bzr/plugins
<NfNitLoop> (unpacked)
<owh> So, that will do it for one user. What about the other users? I'm more than a little surprised that we seem to be back to dropping files into a directory - that feels like stepping back a decade.
<lifeless> owh: its packaged in jaunty
<lifeless> https://edge.launchpad.net/ubuntu/+source/bzr-xmloutput
 * owh wonders if that will just install under Intrepid.
<lifeless> probably it will
<thumper> yay for the jaunty package
<owh> Nope, it depends on python-central >= 0.6.11
<owh> Crap
<owh> Well, while less than orthodox, installing the latest Janty python-central + bzr-xmloutput seemed to install. How do I test to make sure it actually works?
<lifeless> owh: bzr help plugins
<lifeless> owh: should list xmloutput
<owh> Magic
<owh> Much Tah.
<owh> Now to make it all work with Eclipse :)
 * jelmer wished somebody packaged bzr-eclipse
<thumper> igc: want to put two things on the eclipse list?
<thumper> igc: package for ubuntu and windows :)
<jelmer> thumper,igc: fwiw there is some initial work on a debian package in the pkg-bazaar bzr repository
<jelmer> but I couldn't figure out how to build bzr-eclipse non-interactively
<lifeless> jelmer: did you ask veterok
<owh> Hmm, seem to be running into a problem. In the Team Synchronisation View, I click on the Synchronise Button, which brings up a dialog with synchronisation types. I chose Bazaar, and initially it told me that there was an invalid path. I pointed it at /usr/bin/bzr and it stopped complaining, but when I click Finish, nothing happens. Next is greyed out.
<lifeless> odd
<lifeless> uhm
<lifeless> I have no idea :)
<jelmer> lifeless: no
<jelmer> lifeless: I tried out the pre-built version of bzr-eclipse but found it had to many rough edges
<jelmer> lifeless: so froze my effort to package it
<jelmer> that was a while ago though, it may have gotten better since
<NfNitLoop> omg annoying voice guy won't stfu
<lifeless> ?
<NfNitLoop> oops wrong window.
<NfNitLoop> sorry  :)
<thumper> NfNitLoop: heh
<thumper> NfNitLoop: had me laughing
<NfNitLoop> this cellphone connection is laggy... thought i was typing elsewhere
<owh> How do I go about figuring out why I cannot create a bzr team synchronisation in eclipse?
<lifeless> owh: I'd love to help you but I don't know enough about eclipse
<lifeless> owh: make sure have the eclipse version the bzr-eclipse page talks about
<owh> I do, 3.4.1 which is >= 3.3
<lifeless> isn't that incompatible? I seem to recall a different build of the eclipse plugin being needed
<owh> Seems to be working. That's a 'feature' not a bug :)
<owh> Not that I like the word "seems" in a development environment, but backups are there for a reason :)
<lifeless> trace generates _very_ odd results sometimes
<meoblast001> hi
<lifeless> hmm, could be decorators messing it up
<igc> hi all
<lifeless> hi igc
<igc> hi lifeless
<thumper> hi edcrypt
<edcrypt> thumper hi
<thumper> edcrypt: I haven't looked at the source yet, but I have a couple of comments on the readme :)
<thumper> edcrypt: although first a question
<thumper> edcrypt: for the init-workspace, you have the sandbox outside the repo
<thumper> edcrypt: why?
<thumper> edcrypt: I would have thought it easier to have MyProject be the shared repo
<thumper> edcrypt: with trunk
<thumper> edcrypt: and the sandbox checkout
<thumper> edcrypt: then you don't have two different repo styles for --feature-branches or other
<lifeless> I'm really concerned that all these 'make it easy by layering' approachs are just making the problem worse
<thumper> lifeless: all problems are solvable with another layer of indirection L)
 * thumper snickers
<edcrypt> thumper: not big motive, it's just the layout I'm used to
<lifeless> to fix it we need to remove the sand grains causing the issue
<thumper> edcrypt: personally I have my lightweight checkouts outside my repo
<thumper> edcrypt: but I think that the plugin should be simple enough to understand without having two different layouts
<edcrypt> thumper: I think I agree.
<thumper> I'm pretty sure that switch is smart enough now that `bzr switch feature-x` will DTRT
<thumper> rather than `bzr switch ../feature-x`
<lifeless> thumper: it will search in branch-root/../
<lifeless> so yes, qualified
<lifeless> man, it is going to take a long time to index all of bzrlibs tests
<lifeless> why is trace.Trace so slow
<thumper> edcrypt: also the `update-sandbox` command will do weird things if the checkout is no longer trunk
<lifeless> 10 tests in 20 minutes
<lifeless> 2 minutes each, 18K tests, 36K minutes :(
<lifeless> 600 hours :(
<lifeless> 24 days. faaaark
<thumper> lifeless: why are you doing this?
<spiv> lifeless: I guess that's what happens when you run python functions for every bytecode...
<edcrypt> thumper: right. it should check that.
<edcrypt> thumper: thanks for the feedback,
<lifeless> spiv: wheeee
<lifeless> thumper: I have written a plugin
<lifeless> thumper: it indexes tests by the code they exercise
<thumper> edcrypt: my pleasure
<lifeless> then when you run 'bzr selftest --changes' it calculates the changed code  and looks up the relevant tests
 * thumper nods
<lifeless> it works, with some various caveats. I finished it up last night, but without a full index its useless; so I haven't put it out there yet
<lifeless> spiv: possibly I should just use lsprof
<lifeless> spiv: and extract stuff from that, but I do need the module paths
 * lifeless will play after work
<lifeless> jelmer: ping
 * igc lunch
<spm> Am getting a bzr return code of '3' from a bzr checkout - no output unf :-( Any idea what a return 3 from a bzr checkout is? My googlefu can't find a simple table of codes.
<poolie> "failed"
<poolie> hth :)
<spm> poolie: not really :-D
<poolie> is there something in ~/.bzr.log?
<lifeless> spm: no output at all?!
<lifeless> spm: pastebin please
<spm> poolie: yes actually! ta. but is the generic connection failed, pls to using -Dhpss message. hmmm.
<spm> lifeless: from the buildbot log. looks like it throws away stderr/out
<spm> so .bzr.log has: https://pastebin.canonical.com/16383/
<spm> builbot slave log has: https://pastebin.canonical.com/16384/ cf line 21
<lifeless> spm: haven't looked yet but I bet 'fix your dns'
<spm> heh
<lifeless> we'll need stderr thats where the openssh output will have gone
<poolie> hm i thought we removed that "please use -Dhpss" message
<poolie> maybe he has an old bzr
<spm> poolie: Yikes! 1.8
<lifeless> spm: please be using something from this year
<lifeless> spm: but I bet you a liquid refreshment that its dns
<spm> I could really learn to hate ec2... dns seems so fragile there.
<lifeless> igc: I don't really understand your LocalRemoteBranchTypes thing
<igc> lifeless: give it another 30 minutes - what's there was just a 'save-before-lunch' snapshot
<lifeless> igc: ok; if its useful I can say what confused me
<igc> lifeless: sure, go ahead
<lifeless> Given commonly recommended practices like feature branching, the intention when branching locally (start me a new line of development) is different to the intention when branching from a remote location (grab me my copy of that project).
<lifeless> that was the bit that confuses me
<lifeless> I don't know how often you grab a copy of a project without the intent of making changes; but it sure seems to me that mirroring (grab a copy) is less common than editing (get me something I will make changes to)
<lifeless> s/you grab/one grabs/
<lifeless> Anyhow, hope that helps; and please do think about the root cause of the issues; I don't think its accidental that we are having a lot of growing pains here - our design is broken and we need to fix it.
<spm> lifeless: poolie: fyi. pebkac, effectively. ssh-agent fail. fixed now. ta, and sorry for the false alarm as it were.
<lifeless> damn, I owe you water
<spm> high quality tap water at that! No less!
<lifeless> I shall piss in the cup myself
<poolie> ENSFW
<BasicOSX> I've seen NSFW, and VNSFW, what's ENSFW?
<poolie> "error nsfw"
<BasicOSX> extremely? ahh, ok
<vila> hi all
<maxb> window level all
<wgrant> If I make a branch append-only, will the smartserver enforce that? In this case I cannot assume that the people using the branch are not malicious.
<jelmer> lifeless: pong
<lifeless> jelmer: see mail
<jelmer> lifeless: push_branch also pushes to existing branches
<jelmer> BzrDir.push_branch() will open the underlying branch if there is one
<lifeless> jelmer: I know, thats part of the issue ;P
<jelmer> lifeless: but you want to get at a Branch without getting at a BzrDir first?
<jelmer> lifeless: anyway, the suggestions for the helper seem reasonable
<jelmer> lifeless: seems a bit similar to BzrDir.open_containing_tree_branch_or_repository
<jelmer> lifeless: ie BzrDir.open_branch_or_bzrdir()
<lifeless> jelmer: it may create :)
<lifeless> jelmer: look at the network trace
<jelmer> lifeless: so basically, the only thing I can't do is a create without a push
<jelmer> lifeless: which trace?
<lifeless> the one in my mail
 * igc dinner
<jml> how do you deloomify a branch?
<lifeless> jml: bzr export-loom
<jml> meh
<jml> ok, what I really meant was, how can I make this error go away? TypeError: open() got an unexpected keyword argument 'ignore_fallbacks'
<lifeless> upgrade your loom plugin with aaron's patch
<jml> thanks.
<jelmer> re
<LarstiQ> wgrant: it certainly should if they are using the smartserver to access it
<LarstiQ> is there a jaunty user around that could test https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa/+files/bzr-svn_0.5.4-1~bazaar1~jaunty1_all.deb from the beta ppa?
<beuno> LarstiQ, sure
<beuno> ah
<beuno> doesn't work with nightlies
<vila> abentley: ping
<abentley> vila: pong
<vila> abentley: at the end of bzrlib/merge_directive.py MergeDirective2 is registered with a string mentioning 0.19 while its _format_string attribute mentions 0.90, is it deliberate ?
<abentley> vila: doesn't sound like it.  lemme see...
<beuno> LarstiQ, works perfect
<LarstiQ> beuno: thanks!
<abentley> vila: Yes, it looks deliberate.  You see that it's registered twice, right?
<vila> yes
<vila> so why ?
<abentley> 0.19 never existed.  It got renamed to 0.90.
<abentley> But by that point, there were already merge directives in the wild that used 0.19
<vila> abentley: oeuf corse
<abentley> So this was to retain compatibility with those merge directives.
<vila> abentley: added as comment
<vila> abentley: and thanks :)
<abentley> vila: np
<jam> hey vila, how's it going?
<vila> jam: fine, getting closer to submission :)
<jam> I at least saw your commit show up :)
<vila> jam: Ha ! Good, still not here, but at least I fixed the setup (again :-/)
<jam> vila: btw, my recent LRUCache patch *might* be part of the answer for why branch conversions leak a bit of memory
<jam> We were "leaking" LRUNodes by leaving in the linked-list, but not in the dict
<vila> jam: Next on my list to check :)
<jam> The nodes themselves aren't large enough to explain it, but maybe them coupled with referencing a key that then gets repeated would be enough
<vila> jam: and multiplied by the number of LRUCache, multiplied by the number of autorepack during the conversion...
<vila> jam: damn, just realized I haven't approved your patch :-/
<jam> vila: well, when we get rid of the containing btree reference, it should gc the lru nodes
<jam> so... maybe
<jam> certainly I think the fix will help
<jam> and in the meantime I'll finish perf testing the link indirection
<jam> it seems to cost about 10% overhead
<vila> ECONTEXT link ?
<jam> vila: LRUNodes are in a double linked list (.next, .prev)
<jam> which means that if you just del LRUCache
<jam> they stay around until gc.collect() runs
<vila> ha, that link :)
<jam> You can use 'prev_key' and then look up the prev object in LRUCache._cache
<jam> the problem is it adds a dict overhead
<jam> vila: current timing: http://paste.ubuntu.com/152135/
<jam> That is with 2.8M tuples
<jam> 8.2k unique
<vila> jam: this measures only the cache overhead right ?
<jam> right
<jam> this is with a test where a miss has 0 cost
<jam> I just do except: cache[val] = val
<vila> so, you're trying to be quicker without leaking memory, I'd say we don't want to leak memory, whatever the price is :)
<jam> vila: this isn't about *leaking* specifically
<jam> it is just whether the data gets cleaned up during "del foo"
<jam> or during "gc.collect()"
<vila> jam: sure, I shouldn't have say leaked, sry
<jam> vila: the patch you approved was about a more genuine "leak"
<jam> where not even gc.collect() would grab it
<jam> because they were still 'live' in the linked list
<jam> vila: And gc.collect() runs automatically every 700 unmatched allocations or so
<jam> so the data will get cleaned up eventually
<jam> I *think* I want to do it anyway
<jam> I just need a real-world benefit
<jam> and maybe big conversions are it
<jam> since during autopack we'll be generate a new btree index, and "throwing away" the old one
<vila> by the way, the xml cache trick seems to reduce memory pressure too here, I'm (approx) at 20 out 27 hours (instead of 41) and the memory is at 3GB ( instead of 4GB)
<vila> jam: right, and we autopack several times :)
<vila> one just triggers here :)
<jam> vila: yeah, the xml trick means that for the 100 or so revision trees we have in memory
<jam> we only have 1 copy of 99% of the inventory objects
<jam> I would be surprised for it to be 1GB
<vila> jam: those 3 and 4GB are very rough, and the conversion is still not done, yet, from memory (mine) this was growing linearly with time
<jam> then again, it could be *huge* for improving fragmentation
<vila> jam: that's the problem :) We really need to find a better way to measure that fragmentation
<jam> vila: bzr branch lp:~jameinel/+junk/py_memory_dump :)
<vila> jam: Hmpf man malloc(3) BUGS section 8-/
<__alexandre__> hi everybody
<__alexandre__> I have a problem using bazaar and I need some help. Am I in the right place ?
<bialix> hi, jelmer is around?
<bialix> __alexandre__: simply ask the question
<__alexandre__> I'm trying to use bazaar with an HTTP server (lighttpd)
<__alexandre__> but with basic authentification
<__alexandre__> and bazaar does not ask me for my password when it gets 401 error
<jam> __alexandre__: use a username in the url
<jam> http://username@host/...
<__alexandre__> I tried
<__alexandre__> but I get a big traceback
<__alexandre__> if I set the password with it
<__alexandre__> something like
<__alexandre__> http://username:password@localhost/the_path
<__alexandre__> even just http://username@localhost does not work
<vila> __alexandre__: can you pastebin the traceback somewhere ? What bzr version are you using ?
<__alexandre__> Bazaar (bzr) 1.6.1 with python2.5.2
<vila> __alexandre__: hmm, I'm affraid you need to upgrade, 1.6.1 is pretty old and some bugs have been fixed in that area
<__alexandre__> bzr: ERROR: pycurl.error: (65, "necessary data rewind wasn't possible")
<__alexandre__> Traceback (most recent call last):
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors
<__alexandre__>     return run_bzr(argv)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr
<__alexandre__>     ret = run(*run_argv)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases
<__alexandre__>     return self.run(**all_cmd_args)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 840, in run
<__alexandre__>     from_location)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 878, in open_tree_or_branch
<__alexandre__>     bzrdir = klass.open(location)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 756, in open
<vila> __alexandre__: eeerk, pastebin ! not here !
<__alexandre__>     return BzrDir.open_from_transport(t, _unsupported=_unsupported)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 793, in open_from_transport
<__alexandre__>     redirected)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/lazy_import.py", line 125, in __call__
<__alexandre__>     return obj(*args, **kwargs)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/transport/__init__.py", line 1616, in do_catching_redirections
<__alexandre__>     return action(transport)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 770, in find_format
<__alexandre__>     transport, _server_formats=_server_formats)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1593, in find_format
<__alexandre__>     return format.probe_transport(transport)
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 2580, in probe_transport
<__alexandre__>     server_version = medium.protocol_version()
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/medium.py", line 531, in protocol_version
<__alexandre__>     client_protocol.query_version()
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/protocol.py", line 770, in query_version
<__alexandre__>     self.call('hello')
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/protocol.py", line 618, in call
<__alexandre__>     self._request.finished_writing()
<__alexandre__>   File "/usr/lib/python2.5/site-packages/bzrlib/smart/medium.py", line
<__alexandre__> oh ok
<__alexandre__> I'm using the one which is in Ubuntu repository
<__alexandre__> oups sorry
<__alexandre__> (which are not always uptodate)
<__alexandre__> ok I'll try with the last stable version
<__alexandre__> thank you !
<vila> __alexandre__: anyway, the relevant error here is:  ERROR: pycurl.error: (65, "necessary data rewind wasn't possible")
<vila> and I'm pretty sure many fixes applies to solve that :-)
<vila> __alexandre__: if you look at https://launchpad.net/bzr/ you'll find instructions on how to add a bzr sources.list entry for any Ubuntu version, and you can choose to use stable, beta or nightly build of bzr
<__alexandre__> ok it seems to work with a newer version. thank you
<jam> vila: just checked 'man malloc', I'm not particularly worried about the bug
<vila> jam: no, no worries, just... ugh
<jam> It just means that if you have "for(i = 0; i < infinity; ++i) {malloc(100000)}
<jam> it will over succeed
<jam> pages aren't actually acquired until you touch them
<vila> ...and then randomly kill some processes
<jam> I remember benchmarking it in the past
<jonnydee> hello, I need help with nested trees: when I "join --reference" a subtree "bzr st" on the outer tree lists ".bzr" directory of subtree as "unknown". is this correct behavior? (I am using bzr 1.13.1)
<jonnydee> btw, "bzr st" also lists all the other files/directories within the subtree as "unknown", too...
<jonnydee> no one who can help me? I'd love you use nested trees, because they seem to be exactly what I need.
<LarstiQ> jonnydee: nested trees (especially reference) have seen recent development, I don't think 1.13 has all of that.
 * LarstiQ is bad with time
<LarstiQ> jonnydee: http://bazaar-vcs.org/NestedTreeProgress
<jonnydee> particularly, the feature that bzr will remember the revision of the inner tree within the outer tree is very cool!!!
<jonnydee> LarstiQ: I've read this site, but I wonder why bzr 1.13.1 already has "join --reference" released...
<jonnydee> (thanx for your reaction :) )
<james_w> is there a plugin with a pre_commit hook for test before commit?
<james_w> *not* PQM ;-)
<LarstiQ> jonnydee: it's not in bzr.dev, let me check 1.13
<LarstiQ> jonnydee: --reference is indeed on join in 1.13, but join itself is a hidden command.
<LarstiQ> jonnydee: anyway, it boils down to: I'm afraid nested trees as released will not do what you want, just yet.
<LarstiQ> jonnydee: depending on what you want, you could 1) wait 2) try Aaron's recent code 3) use scmproj or config-manager 4) without reference, manual, etc
<jonnydee> ahh ok :)  but do you know what can be done with the current release? I mean can I use join in any useful way?
<LarstiQ> jonnydee: there are cases where it can be usefully used, yes
<LarstiQ> jonnydee: but what's your usecase? Maybe we can help you find something for that.
<jonnydee> I would like to have a 'lib' branch as a subtree of another project branch.
<jonnydee> the lib branch is versioned itself
<jonnydee> currently, I maintain a branch with all my software projects in it. but this turns out to be not quite practicable, because when I develop a feature for project x I branch the complete tree with all projects
<LarstiQ> pretty much the canonical case for by reference nested trees, indeed
<jonnydee> so I would like to have a separate branch for each project
<jonnydee> and get common things for each project by subtrees
<jonnydee> yes, I think it's exactly the use case described in http://bazaar-vcs.org/NestedTreesDesign
<LarstiQ> jonnydee: I haven't looked at scmproj (https://launchpad.net/bzr-scmproj) since it's redesign, but I've used it in the past to accomplish this
<LarstiQ> jonnydee: so you might want to look at that for something that works right now
<jonnydee> oh, thanks for this hint :) I'll have a look to it. and thank you very much for your attention and help :)
<LarstiQ> jonnydee: np
<james_w> vila: around by any chance?
<james_w> I have some testsuite questions :-)
<vila> james_w: lucky you ! :)
<james_w> yay!
<james_w> I want a way to run the testsuite for a plugin that doesn't depend on the plugin being the one that bzr will load
<vila> what testsuite ?
<james_w> so that e.g. "python tests/__init__.py" in the plugin will run its tests regardless of where it is
 * LarstiQ tries to parse that again
<LarstiQ> ah, right
<vila> ok, run the test suite without selftest
<james_w> yeah
<vila> jusdepending on unittest or using bzrlib.tests features
<vila>  ?
<james_w> I've needed it a couple of times, so I'm finally going to try and come up with a working solution, so I thought that I would come to the master
<james_w> bzrlib.tests would be nice
<vila> and why not use selftest -s bp.myplugin ?
<james_w> because that involves making sure that "myplugin" is on the bzr plugin path
<vila> need to test various versions without swapping ?
<james_w> I just wrote a quick pre_change_branch_tip hook for running tests
<james_w> it gets the branch and a revid, so it exports to a tempdir, and runs the tests there
<LarstiQ> james_w: BZR_PLUGIN_PATH=. ?
<vila> james_w: I was thinking about LarstiQ proposal while searching the relevant bug on lp :)
<LarstiQ> bit of a hammer
<james_w> LarstiQ: yeah, it's a bit annoying as it tries to load like setup.py as a plugin for example
<LarstiQ> james_w: ooh
<LarstiQ> right
<vila> james_w: if __name__ == "__main__":
<vila>     unittest.TestProgram(module=__name__)
<vila> if the incantation I use when doing TDD outside bzr
<james_w> so that would be fine for anything not using the bzr extensions?
<LarstiQ> vila: how does that differ from unittest.main()?
<vila> it should be fine to use bzr extensions *except* for load_test() and test_suite()
<james_w> ah, because of inheritance!
<vila> LarstiQ: main = TestProgram
<vila>  in unittest.py ? :-P
<jam> james_w: why not write a 'main()' function which just imports bzrlib.tests and runs itself
<vila> line ~808 :)
<jam> heck, if you want to get crafty, you could have it set BZR_PLUGIN_PATH
<jam> and then run 'bzr selftest -s bp.myplugin'
<vila> ELOOP :)
<jam> vila: not really, it is just a "if __name__ == '__main__':" check
<jam> I suppose it is recursive, but directly terminating
<vila> jam: not the code, the discussion :)
<james_w> ok, putting vila's suggestion in tests/__init__.py runs 0 tests
<vila> I proposed -s bp.myplugin earlier :)
<jam> vila: right, and he said the problem was he didn't want to have to put it into path
<jam> so *I* suggested having the plugin put itself into path
<jam> and have the *plugin* call out to "bzr selftest $ME"
<james_w> putting it in __init__.py fails as you can't run "__init__.py" as it tries to import parts of the plugin, and plugins haven't been loaded yet so they aren't under b.p.
<jam> so his "python tests/__init__.py" would Just Work
<vila> jam: right, I rule that out too fast maybe (I thought there may be several versins conflicting)
<vila> james_w: if you use b.p. imports then you *must* use bzr to load correctly
<james_w> yeah
<james_w> so I want to run bzr, but I want slightly more control over the plugins it imports
<vila> bug #316192
<ubottu> Launchpad bug 316192 in bzr "bzrlib.plugin.load_plugins() loads system plugins even for non-system bzrlib" [Medium,Confirmed] https://launchpad.net/bugs/316192
<jam> james_w: well you could put the "if __name__" check very early
<jam> and have it finish with "sys.exit()"
<jam> (as in, put it before the other 'import' statements, etc)
<vila> bug #82693
<ubottu> Launchpad bug 82693 in bzr "Ability to run tests in a particular plugin" [Wishlist,Confirmed] https://launchpad.net/bugs/82693
<vila> jam, james_w : we could add a test-plugin command that will implement jam suggestion above (load the plugin and run selftest -s bp.plugin) with options to load *only* the plugin or *also* the plugin and accept the plugin path as a parameter
<james_w> that would be great
<james_w> I'm getting there
<james_w> however, the plugin is currently loaded as "bzrlib.plugins.trunk"
<vila> james_w: :-) I know that one, I ended up making my ~/.bazaar/plugins directory a link farm pointing to various ~/src subdirectories
<james_w> that's what I have
<vila> I also love a bzr enable/disable plugin that mv in and out the DISABLED directory :-)
<james_w> \o/
<james_w> it won't work on Windows though
<james_w> if __name__ == '__main__':
<james_w>     import os
<james_w>     import subprocess
<james_w>     import sys
<LarstiQ> mv DISABLED?
<james_w>     dir = os.path.join(os.path.dirname(os.path.abspath(__file__)), "plugins")
<james_w>     retcode = subprocess.call("bzr selftest -s bzrlib.plugins.builder",
<james_w>             shell=True, env={"BZR_PLUGIN_PATH": dir})
<james_w>     sys.exit(retcode)
<james_w> with /plugins/builder -> /
<james_w> (symlink)
<james_w> thanks team, I'll use this for a while and see how it goes
<Kobaz> zr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt)
<Kobaz> i get that while trying to do a pull
<Kobaz> how do i turn off ca validation
<Kobaz> i use self-signed certs
<exarkun> Kobaz: Add your cert to the site ca cert list?
<exarkun> Then you can use self-signed certs /and/ retain some security.
<exarkun> woot.
<LarstiQ> or use http+urllib://
<exarkun> LarstiQ: That's the same as turning off ca validation, right?
<LarstiQ> exarkun: isn't that exactly what Kobaz is asking?
<exarkun> Yes
<LarstiQ> ah, that way.
<LarstiQ> exarkun: yes, I believe it is.
<LarstiQ> exarkun: although our use of urllib may have grown certificate validation.
<LarstiQ> I wish it did, it's the only thing keeping pycurl alive.
<Kobaz> mmm
<Kobaz> so the only way is to add the ca to the ca store?
<Kobaz> oh wait
<Kobaz> what's http+urllib://
<Kobaz> i'm using bzr+https://
<LarstiQ> Kobaz: could you try bzr+https+urllib:// ?
<LarstiQ> not sure if multiple decorators work, but worth a try
<Kobaz> k
<Kobaz> it's weird though, i'm putting bzr on a new box
<Kobaz> i use bzr+https:// on all my other boxes with no issue
<Kobaz> all on bzr 1.13
<lifeless> Kobaz: in bzr 1.13 the server will do more operations; you may be seeing the server itself generatin that error
<Kobaz> bzr: ERROR: Unsupported protocol for url "bzr+https+urllib://
<Kobaz> it's definitly not the server
<LarstiQ> Kobaz: my guess is that all the others do not have pycurl installed
<Kobaz> oh yeah, that's how i fixed it, was removing pycurl
<LarstiQ> good night
<Kobaz> so soon?
<Kobaz> here's something i've been wondering a while
<Kobaz> how do i display relative paths when doing bzr st, or other commands
<Kobaz> bogger {~/projects/system_init} kobaz$ bzr st *
<Kobaz> unknown: system_init/create_postgres_users
<LarstiQ> Kobaz: 23.00, my usual sleeping time
<Kobaz> what i used to do all the time with subversion, is copy and paste the filename and do somethign with it
<Kobaz> so if i copy and paste
<Kobaz> i get bzr diff system_init/create_postgres_users
<Kobaz> which doesn't exist... since i'm already in system_init/
<Kobaz> if i do bzr st *... i should see just: system_init
<Kobaz> er i mean... i should just see the files with relative paths... which would be just one filw: create_postgres_users
<lifeless> Kobaz: we are changing st to be like svn in that regard
<lifeless> Kobaz: for now you could do `bzr root`/<filename>
<Kobaz> i like if you do svn st... and it will show you everything in the tree
<Kobaz> but it would be cool if there was an option to do relative paths
<Kobaz> i think both methods should exist
<lifeless> Kobaz: yes, it will show everything and give relative paths
<lifeless> htats the current plan as I understand it
<Kobaz> nifty
<kfogel> lifeless: the new eol-conversion stuff is entirely client side, right?  that is, if someone wants the feature, and they upgrade their local bzr to 1.14rc1, then they'll get the feature, even if the other servers they talk to are 1.13 or older.  Is that correct?
<lifeless> kfogel: at this point I believe so
<kfogel> lifeless: thanks.  Wanted to make absolutely sure, before I said it to a VIU.
<kfogel> lifeless: I saw your "I believe"; I will CC Martin on my response to make sure.
<lifeless> kfogel: igc has been writing this feature
<fullermd> 'client' is probably the wrong division.  It's all WT-side.
<kfogel> fullermd: well, in a sense that's a subset of "client" (I think this user wants to be told the answer in the simplest way possible).
<lifeless> kfogel: I'm not aware of any changes in the repository api to signal how things should be stored
<lifeless> kfogel: which says its all client side to me
<kfogel> lifeless: *nod*
<Peng_> beuno: Ping?
<beuno> Peng_, pong
<Peng_> beuno: Oh hi!
<Peng_> Um.
<beuno> hai
<Peng_> beuno: Any opinion on bug 358322?
<ubottu> Launchpad bug 358322 in loggerhead "Every call to LoggerheadConfig() creates a new temp dir" [Critical,Confirmed] https://launchpad.net/bugs/358322
<beuno> Peng_, yeah, we should use the same dir, and make it configurable
<beuno> not add the timestamp, or whatever random string to add
<beuno> is that what you where aiming at?
<Peng_> beuno: I wasn't aiming at anything in particular.
<beuno> well, that's what I thought of in the shower a day or two ago  :)
<AmanicA> kfogel: wouldn't you need to update to the 1.14 formats to get that feature? so the old version on the server would not like it
<AmanicA> New formats 1.14 and 1.14-rich-root supporting End-Of-Line (EOL) conversions,
<Peng_> AmanicA: But if the only new format is the working tree, and the server-side doesn't have working trees, it's not a problem.
<Peng_> beuno: Is my patch okay as an interim solution?
<AmanicA> ah
<kfogel> AmanicA, Peng_: or at least, whatever working trees are on the server side are of no concern on our side.
<beuno> Peng_, I did not know there was a patch
 * beuno looks
<beuno> Peng_, you should file merge proposals  ;)
<beuno> now
<beuno> what would the prefix fix?
<Peng_> beuno: Sorry. I didn't because it was only an RFC.
<beuno> identifying it?
<blfgomes> could anybody help me setup bzr to work with a proxy that requires authentication?
<beuno> Peng_, ^ ?
<Peng_> Err, hold on. I just got distracted.
<beuno> sure, didn't know if you had read
<lifeless> blfgomes: export http_proxy=http://hostname:port/
<blfgomes> anybody? I have HTTP_PROXY configured, I can do pretty much everything (wget, apt-get), except for bzr
<lifeless> blfgomes: ok, is it lp: url's that are giving you grief ?
<blfgomes> lifeless: I tried the whole url as well, but it doesn't seem to be authentication in either case
<blfgomes> I just get a 407 straight away
<lifeless> hmm
<lifeless> vila: ^
<lifeless> what proxy is it?
<blfgomes> good question
<blfgomes> I've seen some unorthodox proxy configuration here at work before, where some things wouldn't work... But why should bzr fail when wget runs smoothly?
<lifeless> if its doing NTLM/kerberos we might not support tat
<lifeless> I'm reasonably sure we support digest
<lifeless> vila maintains our http stack
<blfgomes> I'm giving my credentials in plain text in the HTTP_PROXY variable
<lifeless> oh
<lifeless> I'd strace and see what bzr is putting on the wire
<lifeless> note that lp: url's won't work through a proxy at all at this point :(
<lifeless> due to a xmlrpc lib limitation we haven't worked around yet
<Peng_> beuno: On a different subject, I forgot, for "fix is in lp:loggerhead", do you use Fix Committed or Fix Released?
<lifeless> http://bazaar.launchpad.net/ ones will work
<beuno> Peng_, committed
<blfgomes> you're right... lp: urls timeout here, whereas full urls give me the 407 error
<Peng_> beuno: Thanks.
<Peng_> beuno: Anyway. What do you mean about prefixes?
<beuno> Peng_, the cache dirs are created in /tmp
<beuno> with different names each time, no?
<Peng_> beuno: Oh. The prefix argument is just so the directory is named "/tmp/loggerhead-cache-XXXXXX" instead of something like "/tmp/tmpXXXXXX". That's not a new change.
<beuno> Peng_, ok, so, I'm fine with that change
<beuno> bb:approve
<beuno> lp:
<beuno> whatever
<beuno> but the deeper problem is that you shouldn't have to re-generate the cache everytime you restart
<beuno> no?
<beuno> or did I worry for nothing?
<beuno> I do that sometimes
<Peng_> beuno: Honestly, I don't mind that. My cache got corrupted once, so that meant a restart fixed it.
<beuno> I guess you don't have 200mb of caches and a dying server
<beuno> :)
<Peng_> Heh, right.
<beuno> someday, I'll work on Loggerhead again
<beuno> I'm sure
<Peng_> beuno: It doesn't *need* to be recreated every time. Using a static location doesn't cause any problems.
<Peng_> Well, currently I think the file gets deleted on shutdown anyway, and I don't know hwy.
<lifeless> blfgomes: please file a bug
<Peng_> s/hwy/why/
<lifeless> blfgomes: I'll assign it to vila and ask him to look; he's in europe
<lifeless> BasicOSX: ping; is your addons repo work now ?
<beuno> Peng_, yeah. I think making it static is better. And even more if it's configurable
<BasicOSX> lifeless:  I haven't check since the initial debug and troubleshooting
<BasicOSX> I'm still at my real job, will check it again tonight when I'm home
<blfgomes> lifeless: I'll make sure it's a bug, first
<lifeless> blfgomes: thanks
<lifeless> BasicOSX: ok, grab me and we'll sort it out; I have a meeting in ~ 3 hours for <2 hours
<lifeless> BasicOSX: other than that a clear slate to help
<BasicOSX> lifeless:  I also have a backup of the repo (go Timemachine) from 2am that morning, I'm going to restore some place different and see if my repo got corrupt
<Peng_> beuno: If I make it configurable, what do you think the default should be? Going through mkdtemp is really hte safest option.
<Peng_> s/hte/the/ Darnit!
<beuno> Peng_, agreed. Make mkdtemp the default, but let the user pass a config option
<Peng_> beuno: Alright.
<beuno> Peng_, you rock
 * beuno -> home
<beuno> bbiab
<lifeless> james_w: btw let me know if my plugin works ;)
<lifeless> james_w: I didn't test it
<Peng_> beuno: Back yet?
<beuno> Peng_, yes
<Peng_> beuno: What do you want the option to be named? --cache-dir? --sql-dir? Something else?
<Peng_> (FWIW, I picked --cache-dir, since it may be changed to something not-SQL in the future.)
<beuno> Peng_, --cache-dir sounds good
<Peng_> beuno: Alright. Thanks.
#bzr 2009-04-17
<Peng_> beuno: FWIW, my branch is at http://bzr.mattnordhoff.com/loggerhead/loggerhead/358322-sql-dirs/ . LP hasn't mirrored the latest revisions yet.
<beuno> Peng_, cool. Looking good
<Peng_> I'll send a merge proposal in 40 minutes after LP mirrors it again. :\
<blfgomes> lifeless: I have to go, but I'll keep searching tomorrow. From what I can see, the code is getting my credentials but it's getting lost somewhere.
<blfgomes> Thanks for the help.
<lifeless> blfgomes: ok; please do file a bug
<lifeless> as vila may know the answer
<blfgomes> I will
<blfgomes> see ya
<igc> morning all
<Peng_> G'morning!
<jml> lifeless: you may have already got a bug/todo about this
<jml> lifeless: but it would be really great if there could be something like a commit message associated with each thread of a loom.
<lifeless> jml: there should be a bug
<lifeless> jml: as I want that
<jml> arse.
<jml> I can't upgrade a loomified branch6 format branch.
<jml> lifeless: how do you get a log of the commits in a thead?
<jml> thread
<lifeless> bzr log -r thread:..-1
<lifeless> not quite what you want
<lifeless> file a bug
<lifeless> loom needs someone to just spend a couple of weeks on it
<jml> I'd say more than a couple.
<jml> but maybe not a lot more :)
<jml> bzr: ERROR: Start revision not found in left-hand history of end revision.
<jml> nice
<lifeless> da fuck
<lifeless> is that from thread:..-1?
<lifeless> oh, you'll want to set -n0 or whatever it is probably
<lifeless> I suspect the log work done hasn't taken looms into consideration
<lifeless> in a loom the left-hand-history is the work done on the thread
<lifeless> and up-thread does merges into the thread
<lifeless> file a bug
<jml> on bzr?
<lifeless> yes
<lifeless> task on both, if like
 * jml discovers another bug :)
<jml> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/362667
<ubottu> Ubuntu bug 362667 in bzr-loom "Pushing a rich-root loom as a stacked branch is very, very slow" [Undecided,New]
<lifeless> jml: yes
<jml> lifeless: know of a work around?
<lifeless> jml: try sftp://
<lifeless> jml: also have a look at your hpss activity
<jml> lifeless: still the same as on the bug report.
<lifeless> jml: its asking for one rev at a time
<jml> lifeless: handy.
<jml> lifeless: the sftp push took ~260s
<lifeless> yup
<lifeless> we have optimisations for regular branches loom is probably unintentionally disabling
 * Peng_ makes random trivial changes to lp:loggerhead.
<Peng_> It was never a good idea to give me access to it. I do stuff like this all the time. :D
<poolie> is it just me or is the "userdoc driven design" thread getting too much in to particular cases too early?
<lifeless> poolie: thats what that design pattern does IME
<poolie> the pattern of writing user documentation first?
<poolie> i would have attributed it more to having an open email thread
<lifeless> yes
<lifeless> documentation isn't goal level, it makes assumptions about constraints, internals, ffacilities etc
<jelmer> evening
<Peng_> Hi. :)
<grettke> Hi folks. Can anyone verify that symlinks work with bzr on cygwin? I find that they don't work with Windows and bzr.
 * igc lunch
<jkakar> poolie: Heya, I heard we're possibly working on very similar projects.
<jkakar> poolie: I've been basically copying the APIs from bzrlib.options and bzrlib.commands and making a tool that can be used to create applications with a bzr-like command-oriented interface.
<jkakar> poolie: jml mentioned you were working on something similar; the bits I have so far are at launchpad.net/commandant.
<lifeless> jkakar: I've been making bzr libs command internals more modular
<lifeless> jkakar: such that i have a branch which allows completely replacing the ui
<jkakar> lifeless: Nice.  I started by trying to use the bits from bzrlib.commands and friends.
<jkakar> lifeless: It took me several hours to build a working prototype of my application (much of that involved learning about bzrlib) and included some heinous monkey patches.
<jkakar> lifeless: Once I had the basic prototype using bzrlib working I decided it would be too terrible to continue, and, at the time, I wasn't interested in spending the time it would take to "fix" bzrlib.
<lifeless> heh
<jkakar> lifeless: So I reimplemented the basic prototype from scratch using TDD.  It took me exactly 16 minutes.  I've been building on that base. :)
<lifeless> well :)
<lifeless> we're somewhat phobic about external dependencies
<jkakar> I can understand why.
<lifeless> but I'm happy to get bzrlib to the point you can use it reliably
<lifeless> ideally:
<lifeless> import bzrlib.commands
<jml> o/` I get by with a little help from your deps o/`
<lifeless> bzrlib.commands.Command.hooks['find_commands'].clear()
<jkakar> That'd be cool.  I've basically been implementing almost exactly the same APIs as bzrlib.commands and bzrlib.options, so that the possibility of merging our bits stays, well, a possibility. :)
<jkakar> That and I like the command APIs in bzr, so why reinvent the wheel?
<jml> lazr.command
<jml> do it.
<lifeless> bzrlib.commands.Command.hooks.install_named_hook('find_commands', command_loader(__name__))
<jkakar> Nice.
<lifeless> its approximately that in my pending Commands.as_hooks branch
<lifeless> I have some decisions and cleanups to make
<vila> hi all
<vila> poolie: ping
<poolie> vila, hi!
<lifeless> spiv: wow, how long did that analysis take ?:)
<spiv> lifeless: longer than I thought!
<spiv> lifeless: I just concocted a shorter example that exhibits the behaviour.
<lifeless> surely just a long list of non-interned strings is enough
<spiv> lifeless: it has to be a long list of objects that refer to each other, such that the C stack grows with each object dealloc
<spiv> lifeless: e.g. a linked list
<lifeless> right
<spiv> lifeless: and guess what data structure jam was stress-testing? ;)
<lifeless> an actual list :)
<lifeless> not a vector
<spiv> Right.  "list", not "list". ;)
<lifeless> but also reduce(range(8192), lambda x:[x])
<spiv> lifeless: probably, but it's hard to observe the behaviour without using __del__ or weakrefs to observe when dealloc happens.
<spiv> lifeless: http://rafb.net/p/C3wWeG57.html
<quicksilver> is there an option to bzr push to choose an older tree format?
<quicksilver> say I want to push to a server which only has bzr 0.11
<jonnydee> abentley: Can you just tell me when the Nested Trees feature is expected to be released? I mean can you give me an estimation about the targeted bazaar version?
<spiv> quicksilver: you can "bzr init --knit URL" (or --weave?  It's been a while...) first, then push to that.  You may not be able to use bzr+ssh with a server that old (but SFTP should be nearly as good compared to bzr+ssh with a 0.11 server...).
<quicksilver> or I could bzr init on the remote server and then push to it?
<spiv> Right.
<spiv> bzr push will preserve the format of an existing branch.
 * quicksilver nods
<quicksilver> I hadn't thought of initing an empty branch, for some reason
<quicksilver> I only thought of initing a populated branch
<quicksilver> and didn't want ot lose history :)
<MvG> I've just tried to push a branch (of bzr.dev) with two small commits to lp. Noticed that it claimed to use a default stacking dir, but was transferring huge amounts of data, like what seemed to be the whole repo. Progress stayed at "Transferring:Walking content. 24366/24366", only data and speed got adjusted. I canceled, tried again, same thing. Is there something wrong with stacking?
<james_w> MvG: can you pastebin "bzr info -v" of your local branch please?
<MvG> james_w: http://rafb.net/p/hxYeuO24.html
<james_w> Branch format 6
<MvG> So the format doesn't support stacked repos, and the upstream repo was created using the same format?
<james_w> bug 356699 I expect
<ubottu> Launchpad bug 356699 in bzr "not stacking when pushing to launchpad" [Undecided,New] https://launchpad.net/bugs/356699
<MvG> Looks like my guy, yes.
<MvG> How can I remove a remote repo, to re-create it in a stacked format?
<james_w> you can delete it from the launchpad web UI
<james_w> go to branch page and click on the little dustbin next to the branch title
<james_w> however, that may not be enough, you may need to upload your local branch to have it work
<MvG> What formats do support stacking? 1.9?
<james_w> 1.6 and later
<MvG> Doesn't look good. :-(
<adamt> Hi!
<adamt> Is there really no netbeans-plugin in devopment? :)
<kinkie> Hi all, a question: is there a way to reparent a branch? That is: I've branched off http://foo/branch/trunk, which is also accessible as bzr+ssh://foo/bzr/branch/trunk. Is there a way to change the parent location without needing to also rebranch all children? Thanks!
<bob2> bzr pull --remember newurl
<jelmer> hi kinkie
<kinkie> ok. Thanks!
<bob2> or hack .bzr/branch/branch.conf
<jelmer> MvG: just noticed your patch
<kinkie> Hi jelmer :D
 * kinkie would prefer not to hack if possible :D
<jelmer> MvG: it seems like it would be useful to have a common helper function that can take a BzrDir and return an instance of the default format compatible with that BzrDir
<jelmer> MvG: "bzr upgrade" already does this by itself at the moment
<yelly> hey, I'm trying to install bazaar on OS X. I've just installed python 2.6.2, but it's still asking me to update to 2.5, what up with that?
 * SamB wishes bzr would say how the branches have diverged
<jelmer> SamB: bzr missing ?
<SamB> jelmer: hmm.
<SamB> maybe if "bzr pull" would suggest that?
<SamB> would there be a reason not to have it do that?
<jelmer> SamB: no, that seems like a good suggestion
<jelmer> SamB: perhaps it can also say how many revisions have diverged on each side
<SamB> hmm.
<SamB> well, I'll just make the patch to suggest "bzr missing"
<abentley> jonnydee: I can't give anything precise.  I'm expecting it to land in weeks or a few months.
<SamB>      _fmt = ("These branches have diverged."
<SamB> +            " Use the missing command to see how."
<SamB>              " Use the merge command to reconcile them.")
<SamB> how does that look?
<jonnydee> abently: thanx for your answer :) "few months" to wait for such a great feature is no problem for me. best regards, jonnydee :D
<SamB> jelmer: is that a good way to say it, do you think?
<jelmer> SamB: I think so
<lifeless> jam: ping
<lifeless> jam: I have an idea
<SamB> hmm, is there a simple way to say "only run the self tests for bzr (and it's included plugins)" ?
<lifeless> jam: for BTreeIndexBuilder, I suggest we create a bloom when inserting keys into it. We can choose a pretty big bloom size.
<lifeless> jam: and when we spill, we only probe fallback indices for keys if the big bloom says the key might be preesent in the index at all
<lifeless> SamB: BZR_PLUGIN_PATH=/dev/null bzr --selftest
<lifeless> I think
<SamB> or that, + tests for a given plugin?
<SamB> oh ... but without skipping the loading of plugins
<lifeless> yelly: it probably means that you have multipl copies of plugins
<lifeless> yelly: it probably means that you have multipl copies of **python**
<yelly> lifeless: how would I find out?
<lifeless> yelly: are you using the dmg installer?
<SamB> (you may want to see whether the plugins you have installed break the plain bzr tests without actually running their own tests, no?)
<jam> lifeless: so you are thinking to create an in-memory only bloom?
<yelly> yeah
<jam> you need ~1 byte per object to have a decent bloom hit rate
<jam> so for 100k keys, that is 100-200kB in memory
<lifeless> yelly: I'm not sure; I don't have a macos X box
<jam> not too bad
<lifeless> jam: right, way <<< 20bytes or 200
<jam> for 500k keys (launchpad currently) that is about 1MB
<jam> still "decent"
<yelly> although, come to think of it, i prob should be logging out before i start worrying ;)
<yelly> sometimes your so tired you forget the basics
<yelly> I'll get back if it doesn't work out
<yelly> thanks all
<lifeless> yelly: file a bug in the bug tracker or something if you don't get an answer once you are awake :)
<jam> lifeless: I'll also note that in my testing, resizing a bloom "works", but is inefficient, so you sort of want to pre-allocate a large size
<lifeless> jam: its a concept; if you want to play with it and see if it flies
<lifeless> right, I was thinking to start by testing with just a 10MB fixed size thing
<lifeless> or even 1MB
<lifeless> if you avoid probing until you have most of the keys in, the remainder shouldn't be able to thrash the cache or whatever it is that they are doing
<lifeless> [I'm separately analysing that issue, I have a lsprof generating data now... its quite a large dataset
<lifeless> the index build has been running since about 10am
<lifeless> its now midnight
<lifeless> jam: I wouldn't resize; I'd cascade
<lifeless> jam: start with size N; if it gets too dirty, create a Y-scaled up bloom; when thats dirty, YYN, etc
<jam> lifeless: are you saying insert all the keys from scratch?
<lifeless> jam: no
<lifeless> jam: insert into the new bloom new keys
<lifeless> when being asked for a key, check all the blooms
<lifeless> jam: anyhooo, way past bedtime
<lifeless> jam: just felt it was a fairly useful insight into our needs here that we could test easil
<lifeless> y
<lifeless> hope it helps
<SamB> what do I do with a merge directive to get it into bzr.dev (hopefully)?
<SamB> is there a pyrex-less "buildbot" (or whatever you use to do automated tests)?
<spiv> SamB: post it to the list in an attachment, in a subject starting with [MERGE]
<spiv> SamB: HACKING.txt in the source tree should describe the process in detail
<spiv> SamB: we don't use buildbot, but we do have a PQM instance that runs the full test suite (including pyrex extensions) before allowing a commit to the trunk.
<spiv> jam: that was a wacky gc problem
<spiv> jam: I'm about to go to bed, but I'm inclined to think it's a bug in Python
<SamB> spiv: maybe you should also test *without* pyrex installed ?
<SamB> (if you're going to let people install that way, anyway)
<jam> SamB: all of our dual implementations are meant to have thorough implementation tests
<jam> which are run whether pyrex has been run or not
<SamB> hmm.
<jam> If we are missing a test, then we are missing a test
<jam> but you shouldn't have to run everything as a bzr command to test an interface
<spiv> SamB: we write the unit tests in such a way that the pure python implementations are always tested with the exact same tests that are applied to the pyrex implementations.
 * SamB got a lot of output from the test suite though
<spiv> SamB: it's always possible there are gaps in the coverage :)
<SamB> does that include running the blackbox tests with the pyrex variants not being loaded?
<spiv> SamB: but I don't think we've had much trouble with bugs like "X only works with pyrex bits built"
<spiv> SamB: no
<SamB> well, see, that's the sort of thing I mean
<SamB> run ALL tests with NO pyrex bits, too
<spiv> SamB: the point of running the same unit test suite for the two implementations is so that we can confidently then run other tests like blackbox with just one implementation, because they are the same.
<spiv> SamB: *proven* to be the same, thanks to the tests...
<SamB> well, if the tests proved that, that would be fine ;-)
<spiv> SamB: the potential gap is if the automatic "use pyrex, else use plain python" logic fails.
<SamB> but I happen to know some mathematics
<spiv> (Or just a vanilla gap in the unit tests)
<SamB> and I don't think that's how proofs work ;-)
<spiv> Ok, "proven" is too strong a word.
<SamB> well, yes, that would be a "vanilla gap"
<spiv> But "very high confidence"
<SamB> the unit tests can't prove that everything uses the tested interface ;-)
<SamB> the problems I'm thinking you might miss are perhaps more likely to be in the other tests than anywhere else ;-)
<spiv> So far, this strategy has worked very well; it hasn't let much (any?) bugs of the sort you are worried about slip through, and it doesn't require running large fractions of our test suite twice just to exercise a tiny fraction of the code.
<SamB> I'm seeing stuff like:
<jam> SamB: any time you have multiple implementations, there is a temptation to run higher level tests against all implementations.
<jam> However, we have 10 repository formats, 5 branch formats, 5 transports, etc
<jam> so you get into running the tests 10*5*5*xxx times
<jam> so we rely on having good interface tests
<spiv> I think this is because the unit tests are pretty good, and because the "use pyrex if available, otherwise use plain python fallback" logic is pretty simple, so the risks of it failing are pretty small... and if it does, then it fails in a very straighforward way.
<SamB> well, yes, I'm not worried about that logic
<SamB> if it fails, I'll know
<jam> SamB: Also, in at least some of the permutations of pyrex I test, I also test that the abstraction function is correct
<jam> Specifically, I do stuff like:
<jam> if pyrex_is_available: self.assertIs(function, pyrex_function)
<jam> To now that the logic that is permuting is at least getting the right one on this test run
<jam> admitedly that doesn't test both halves of the possibility during test time
 * SamB woners why he gets this:
<SamB> ERROR: blackbox.test_branch.TestRemoteBranch.test_branch_local_remote
<SamB>     'str' object has no attribute 'get'
<spiv> jam: I suppose we could temporarily muck with sys.modules if we really wanted too...
<jam> spiv: yeah, but then you have to re-import everything/ run bzr in a subprocess, etc.
<spiv> jam: you don't *have* to
<jam> SamB: if you could pastebin a full traceback, it makes it easier
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<SamB> jam: how do I get selftest to give full tracebacks ?
<spiv> jam: but it's a bit fiddly, yeah.
<jam> SamB: when it finishes, it does
<spiv> SamB: it reports them when the run finishes
<jam> spiv: I guess you could nuke the module under test, right?
<SamB> oh. that could take a while!
<spiv> SamB: You can run just one test by doing "bzr selftest TEST_NAME"
<jam> SamB: that specific error looks like something is getting a string when we are expecting a dict
<spiv> SamB: (you can even use a regex, plus other fancy stuff)
<spiv> SamB: you can even do that while another bzr selftest is running, we isolate our tests properly :)
<jam> SamB: btw, when I run that exact test here, it succeeds with or without the extensions built...
<SamB> http://paste.ubuntu.com/152835/
<SamB> hmm
<SamB> jam: what plugins do you have ?
<SamB> wait, that doesn't seem to be it
<jam> SamB: that directly points to a bug in the bzr-svn plugin
<SamB> oh it does ?
<jam> /home/naesten/.bazaar/plugins/svn/transport.py
<jam> line 78
<SamB> oh, yeah, now I see it
<jam> jelmer: ^^ didn't the credential handling change a bit recently?
<SamB> maybe I'm using the wrong branch
<SamB> hmm. this message doesn't wrap nicely.
<exarkun> SamB: that's because it's so short
<exarkun> SamB: it doesn't need to wrap
<exarkun> len("hmm. this message doesn't wrap nicely.") == 38; who has a terminal that narrow?
<SamB> exarkun: not THAT one
<exarkun> SamB: Oh.
<SamB> the branches-have-diverged one, with my additions
<SamB> where should I add a \n ...
<ehazlett> is there a way to dump a bzr repo to svn?
<igc1> night all
<vila> igc1: good night !
<ronny> lifeless: i decided not to put any further efford into subunit, hope you find someone that cares enough to enhance the nose plugin
<ehazlett> is there a way to dump a bzr repo to svn?
<jelmer> SamB: please update your instance of bzr-svn
<jelmer> SamB: You should at least get a different error these days
<jelmer> ehazlett: bzr push
<ehazlett> jelmer: thx
<ehazlett> jelmer:  do i have to specify any arguments; it just created a new branch
<ehazlett> jelmer: nvmd... :)
<ehazlett> what i'm trying to do is import the bzr branch into hg -- the only way i can see to do it is to dump to svn...  anyone have any other ideas?
<hsn_> !cvs import
<ubottu> Sorry, I don't know anything about cvs import
<hsn_> !cvs migration
<ubottu> Sorry, I don't know anything about cvs migration
<jelmer> ehazlett: have you tried tailor?
<jelmer> ehazlett: also, the mercurial folks might have better ideas about this
<ehazlett> jelmer: no i will try it -- yeah, i can't seem to get an answer...
<jelmer> SamB: ?
<Seablade> Quick question if I can.  Can bzr maintain hard links between the source and repo?  Is this possible without the bazaar server running(IE. push/pull/merge with another individual, or to an FTP server?)  I am looking for a solution to maintain audio sessions where the session files are plain text, but the audio files I only want to commit once due to time constraints and the software would hard link to those files as it uses them.
<vila> jam: ping, quick feedback about conversion to dev6,
<vila> even with xml8 patched same time, same memory consumption....
<vila> ...argh, of course since I ran with the same *unpatched* bzr >-/ time for some vacations really :-(
<quicksilver> I'm being stupid today
<quicksilver> what's the bzr command to see the diff between two branches?
<quicksilver> bzr diff foo-a foo-b # gives ERROR: Files are in different branches
<quicksilver> do I have to run the merge speculatively and examine the diff?
<vila> quicksilver: bzr diff --old <old-branch> --new <new-branch>
<vila> both are optional
<vila> quicksilver: or you can use 'bzr merge --preview'
<quicksilver> vila++
<vila> quicksilver: of course redirecting 'bzr merge --preview' in an emacs buffer and issuing M-x diff-mode there....
<vila> ...is a pretty good cherry-picker :)
<quicksilver> yes of course
<quicksilver> you didn't think I was considering doing this outside emacs, I hope?
<quicksilver> what kind of man do you take me for?
<vila> no of course :-)
<blfgomes> lifeless: I've filed a bug report regarding that authentication issue
<maco> is it possible to use bzr with Python 2.3.4?
<LarstiQ> I don't think so.
<maco> bleh. ok. i need to figure out svn or something then.
<maco> thanks
<nekohayo> LarstiQ: any news for the etiquette guide on http://bazaar-vcs.org/Scenarios ?
<nekohayo> (just checking randomly)
<LarstiQ> nekohayo: no sorry, no progress
<nekohayo> ok
<LarstiQ> item 45 on my todo list fwiw
<nekohayo> oh you have an ordered todo list
<nekohayo> is that a particular app?
<LarstiQ> nekohayo: I use yagtd
<LpSolit> is it possible to get a single file with bzr (I'm only interested in a specific file, and I don't want to do a whole checkout of a branch)?
<fullermd> Yes, with export.
<LarstiQ> or cat
<LpSolit> export? what would be the command?
<fullermd> Oh yeah.  I was probably thinking of cat...
<fullermd> Though a glance at the help suggests it won't actually work...
<LpSolit> can the file be on a remote server?
<fullermd> No way to tell it to use some branch other than one you're in.  Export should be able to do it though.
<fullermd> Though I don't know how the output will look for a single file...
<fullermd> I would guess it will end up looking like the tree with everything but that file (and its containing dirs) deleted, but...
<LarstiQ> fullermd: I remember fixing remote cat bugs
<LarstiQ> (just lp: that doesn't take it)
<fullermd> Oh, I guess it does.  The help is very unclear on that though.  You'd never know other than by trying.
<LarstiQ> yeah, bzr cat sftp://host/path/to/branch/path/to/file worked
<LpSolit> bzr cat bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_session.tbzr: ERROR: u'bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_session.t' is not present in revision lpsolit@gmail.com-20090415114310-63op6fa1unrk58xf
<LpSolit> what does it mean? :)
<LpSolit> oh, typo
<LpSolit> pfff
<fullermd> ls can help you catch that:
<fullermd> % bzr ls bzr://bzr.bugzilla.org/selenium/3.4/ | grep test_sudo_session
<fullermd> bzr://bzr.bugzilla.org/selenium/3.4/t/test_sudo_sessions.t
<LpSolit> yes, I forgot the final s
<LpSolit> is there a way to redirect it to a file rather than my screen?
<LpSolit> cat --file or something?
<LarstiQ> cat > file?
<fullermd> Well, generally with the shell...
<fullermd> Though I guess it probably should grow a -o.
<LpSolit> yes, I had > file in mind, but I wondered if there was an argument for cat ;)
<LpSolit> anyway, this is working great, thanks a lot :)
<LpSolit> last question: can I download 2 files at once using cat?
<LpSolit> or should I loop over each file I want?
<Peng_> LpSolit: Try it and see. :D
<LpSolit> haha
<Peng_> LpSolit: It should be possible; it shouldn't need a write lock or anything.
<LpSolit> when someone knows, it's so much faster ;)
<LpSolit> ok, I think I have all the information I need. Thanks again! Very helpful! :)
 * LarstiQ thought trying was faster than asking
<Peng_> Well, if someone answers immediately, that's probably faster.
<LarstiQ> hmja, if you're already in your irc client and don't have /exec
<fullermd> Well, y'never know.  He might be an emacs user, and so unable to fit anything else on the machine unless he exits it...
<LarstiQ> tsk :P
<lifeless> ronny: fair enough, thanks
<ronny> lifeless: i'll either go for py.test extensions or wire something up that can be feed directly into a shell
<lifeless> ronny: sure
<lifeless> jam: around?
<Peng_> jelmer: ping
#bzr 2009-04-18
<Peng_> jelmer: Or never mind.
<jelmer> Peng_: pong
<jelmer> Peng_: hmm?
<Peng_> Hmm, several levels of dÃ©jÃ  vu.
<Peng_> jelmer: I've been having problems with bzr-svn 0.6 and Google Code recently: it asks for HTTP auth on the .bzr control files. But "svn+http" works, so never mind. :D
<jelmer> Peng_: see the recent thread on the mailing list
<Peng_> jelmer: Ehh. Which one?
<Peng_> I'm a week behind on mail, so that'd be great if thre was only one new thread on the entire list, but... :P
<Peng_> jelmer: Oh, the fork thread?
<jelmer> Peng_: yeah
<jelmer> Peng_: the short summary is
<jelmer> Peng_: bzr sends a POST request to see if the remote server provides a bzr smart server
<jelmer> Peng_: But GOogle code responds to POSTs with a 401 Auth required reply
<jelmer> and that triggers a username prompt on the bzr side
<Peng_> jelmer: Ahh, okay. Thanks.
<SamB> is it just me or is the bundle-buggy web UI down ?
<jam> SamB: it seems to be down
 * SamB wonders if jelmer will vote for his http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/56734
<Peng_> What's the mailing list's message size limit?
<Peng_> I wonder if that's why my message hasn't gone through. I think.
<ub3rst4r> does anyone what the url is to mirror a branch thats hosted on sourceforge on to launchpad?
<Peng_> ub3rst4r: https://code.launchpad.net/+code-imports/+new
<Peng_> ub3rst4r: Oh, never mind. Ignore me. Go with what you're being told in #launchpad.
<BasicOSX> BundleBuggy have troubles tonight?
<Peng_> BasicOSX: Seems that way.
<BasicOSX> figures :-)
<BasicOSX> http://downforeveryoneorjustme.com/bundlebuggy.aaronbentley.com
<BasicOSX> Going to make confirming merge request for 1.14rc2 fun(?)
<Peng_> Nice.
<BasicOSX> Need some assistance in where do I get a bug fix, when status = "Fix Committed" but  no branch is associated with the bug. I'm looking to merge bug 355280 but don't know where the fix is located
<ubottu> Launchpad bug 355280 in bzr "eol content filters are never loaded and thus never applied" [Critical,Fix committed] https://launchpad.net/bugs/355280
<Stavros> hello
<Stavros> i am trying to unshelve something and get "bzr: ERROR: The file id "magnifyingglass.png-20090417233633-s6z8t2odk0omj4yo-1" is not present in the tree <Inventory object at [...]"
<Stavros> any idea what that's about? i really need my shelved changes back :/
<Stavros> anyone?
<Stavros> does bzr just lose data like that?
<Stavros> can anyone help me recover my lost data?
<SamB> Stavros: well, I'd save a copy of the directory before proceeding
<Stavros> SamB: which directory do you mean?
<SamB> Stavros: well, any relevant directories that have .bzr subdirectories
<Stavros> i have nothing to proceed to, so not much danger there
<Stavros> it just ate my work
<Stavros> does anyone know how bzr works and what i can do about it?
<cody-somerville> Stavros, what do you mean? :)
<james_w> Stavros: that's odd, did you shelve the addition of a directory?
<james_w> or any additions for that matter?
<Stavros> james_w: i think it shelved a file, yes
<james_w> ok
<james_w> are there confidential things in this project?
<Stavros> sadly, yes
<Stavros> i don't need the file
<Stavros> i need the other changes
<Stavros> can i override a line of code?
<james_w> if you look at .bzr/checkout/shelf/shelf-n
<james_w> for the largest n in that dir
<james_w> then you will see your changes
<james_w> it would have been good if you could attach that to a bug report, but I guess you can't?
<james_w> anyway, a bit of surgery should allow you to recover from that file
<Stavros> i just made some changes (one of which was an added file), shelved them all, and committed a few revisions
<Stavros> ah hmm, my changes are indeed there
<Stavros> can i comment out the code that checks for files?
<james_w> if it's hard to recover from that, then an alternative would be trying to come up with a way to reproduce in a new branch
<Stavros> so bzr applies them?
<james_w> then we can try and fix the bug
<Stavros> how do you mean?
<james_w> I doubt it's a simple as that
<Stavros> hmm
<james_w> cd /tmp; bzr init test
<james_w> then try and do something similar with dummy files, and see if you can trigger the error
<Stavros> hmm, let me check
<Stavros> damn, i can't reproduce it
<Stavros> nope, nothing
<Stavros> is there a way for me to edit the pack file?
<Stavros> oh damn, i actually do need the file in there
<Stavros> oh, there it is
<Stavros> i did a revert and now it breaks
<james_w> the revert breaks? or the revert causes unshelve to break?
<Stavros> the latter
<james_w> so you have a minimal testcase?
<Stavros> yes
<james_w> cool, please open a bug and include it, and I'll take a look
<Stavros> https://bugs.launchpad.net/bzr/+bug/363444
<ubottu> Ubuntu bug 363444 in bzr "unshelve crashes if there is a revert and file shelve." [Undecided,New]
<Stavros> this should work
<Stavros> can you take a look and tell me what's going on? i really need those changes :/
<Stavros> does it reproduce it for you?
<james_w> Stavros: I was more looking for instructions
<james_w> I'd like to know the steps that lead up to it, as well as see the final situation
<Stavros> oh
<Stavros> let me try again
<Stavros> try now
<Stavros> basically, shelve a file add and revert
<Stavros> unshelve will fail
<james_w> "bzr version"?
<Stavros> 1.14rc1, but even trunk fails
<james_w> nice, thanks
<Stavros> np
<Stavros> can you see what's wrong with it?
<james_w> does it have to be two files shelved?
<Stavros> james_w: i am not sure, i only tried with two actually
<Stavros> it seems to work with one file
<Stavros> yes, it only happens with two
<james_w> three?
<Stavros> shelvaw
<Stavros> aw
<Stavros> with three files, revert doesn't work
<Stavros> it crashes
<james_w> not for me
<Stavros> actually
<Stavros> bzr init, shelve a file add, revert, crash
<james_w> that sounds like a separate bug, would you report that one too?
<Stavros> sure
<james_w> thanks
<Stavros> any luck on the first bug? :/
<james_w> ok, so it requires two or more file adds shelved, and any sort of revert after crashes it
<james_w> ah
<Stavros> no, just the unshelve after the revert
<james_w> doesn't even need a revert
<Stavros> hmm
<Stavros> it needed for me
<james_w> #!/bin/bash
<james_w> set -e
<james_w> rm -rf test
<james_w> bzr init test
<james_w> (cd test && bzr ci -m "Commit." --unchanged && touch test2 test3 && bzr add && bzr shelve --all && bzr unshelve)
<james_w> that's my minimal testcase
<james_w> not doing the first commit seems to trigger another bug
<Stavros> ah
<Stavros> can you see why?
<james_w> not yet
<james_w> patience please
<Stavros> okay
<james_w> http://paste.ubuntu.com/153608/
<Stavros> hmm, what is that?
<james_w> that's the difference between a one added file shelve and a two added file shelve
<james_w> so it's clearly to do with that line
<james_w> unfortunately I have no idea what that line means :-)
<Stavros> haha
<Stavros> so basically shelving two files crashes it?
<james_w> looks like it
<Stavros> do you think the shelf is corrupt?
<james_w> _id_numberi3e18
<james_w> v.s. _id_numberi2e18
<james_w> then the extra new-239:test3-20090418182952-p5wbhmyzknaaa14q-2e9
<Stavros> it seems to be the same error as this https://bugs.launchpad.net/bzr/+bug/253806
<ubottu> Ubuntu bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Medium,Fix released]
<james_w> then something like new-15:test2
<james_w> nah, not really
<Stavros> the same error message, i mean
<james_w> what we're seeing is just a generic "foo is not in bar" error
<james_w> ah, yeah, the cause is completely different I bet
<Stavros> ah
<Stavros> are you james westby?
<james_w> yeah
<Stavros> so you know about that bug
<james_w> yup :-)
<Stavros> hmm
<Stavros> i have no idea what could be going on
<Stavros> i'm not really familiar with the internals...
<james_w> so we just seem to have some things repeated in the file, which would be expected
<Stavros> what you pasted looks normal to me
<Stavros> if it's saving the file IDs...
<james_w> you can look at bzrlib/transform.py if you like
<james_w> serialize and deserialize in there will help explain the format of that file
<Stavros> ah
<james_w> ok, so it's bencoded
<Stavros> the error happens after the second deserialization
<james_w> ok, adding debugging prints to serialize and deserialize helps us to see what is going on in there
<james_w> http://paste.ubuntu.com/153611/
<Stavros> they look identical
<james_w> oh, and running bzr with "-Derror" will get you a full traceback so you can see where it is failing
<james_w> yeah, I wouldn't expect that the serialization itself was the problem
<james_w> it's writing out bad data
<Stavros> so it tries to merge and doesn't find a file id to merge with?
<james_w> an unshelve operation is a merge
<Stavros> does it store a pack and then merge it?
<james_w> it stores a serialized TreeTransform, which is something internally used in merge
<james_w> and then tries to apply it by doing a merge
<Stavros> right right
<james_w> it applies the transform on the old tree (hence saving the revision id) to get a new tree, and then merges that new tree with your working tree
<Stavros> ah
<Stavros> which stage do you think is failing?
<james_w> but it shouldn't be asking the working tree for the kind of these files, as they aren't in the working tree
<Stavros> true
<james_w> well it's crashing in the last stage, but I don't know what's at fault
<Stavros> hmm
<Stavros> there aren't many things that would cause it to crash with two files and not with two, i assume...
<Stavros> err, one
<james_w> no
<Stavros> oops
<Stavros> test
<Stavros> hmm
<Stavros> i should redo my changes, i guess...
<zanaga> is there an easy way of getting bzr in to a postmortem debug?
<LarstiQ> zanaga: depending on what you mean with that, if you `BZR_PDB=1 bzr <command>` it will drop into pdb on error
<zanaga> that's exactly what i want =)
<zanaga> thanks
<LarstiQ> ^\ is also useful to break into pdb
<Stavros> damn, so much work lost...
<LarstiQ> Stavros: you should be able to salvage them from the shelf
<Stavros> LarstiQ: there's a png in there i don't know how to get :/
<LarstiQ> Stavros: in a test with adding a png and then shelving, editing the shelf-1 file gives me back my png
<Stavros> LarstiQ: how did you edit it?
<Stavros> i managed to get the other changes
<LarstiQ> Stavros: just a sec
<LarstiQ> Stavros: it looks roughly like http://rafb.net/p/HaZbYo46.html
<Stavros> yes
<Stavros> but won't editing it discard the binary data?
<LarstiQ> Stavros: I deleted everything up to and including the 'i 10\n' line
<Stavros> actually let me open it with a hex editor
<LarstiQ> Stavros: then I deleted everything from and including the 'E' at the end
<LarstiQ> Stavros: I edited it with vim
<Stavros> oh good
<Stavros> let me do that then
<LarstiQ> Stavros: and then used hexedit to remove the final newline
<LarstiQ> after that, cmp between shelf-1 and the original png I copied reported no differences
<Stavros> interesting, that looks lke it worked
<Stavros> i'll reexport in photoshop to make sure
<Stavros> thank you for your help
<LarstiQ> Stavros: np, I hope you got all your data out correctly.
<LarstiQ> Stavros: and thanks for reporting the bug, shelve needs some bugsquashing
<Stavros> looks like it :/
<Stavros> most of the data was text so i got it out, looks like this png was the last
<Stavros> it seems to work fine now, thank you very much!
<Stavros> should i delete the shelf file?
<LarstiQ> Stavros: I'm not entirely sure how that works
<LarstiQ> Stavros: but shelve --destroy should work
<Stavros> ah, thanks
<Stavros> that tried to shelve changes again
<Stavros> actually that selectively reverts changs
<LarstiQ> Stavros: hokay
<LarstiQ> evening lamont
<BasicPRO> boo on thunderstorms
<james_w> wow
<james_w> it does seem to be lost in the serialization
<james_w> two files are recorded, but only one comes back out it seems
<Stavros> that's interesting
<james_w> and when you do it with three, still only the first one comes back out
<Stavros> hmm
<james_w> but I must go eat
<james_w> Stavros: I assume this isn't urgent anymore, you have recovered the things you needed to?
<Stavros> james_w: indeed i have, thank you
<james_w> excellent
<Peng_> lifeless: ping
<james_w> ah, it's multiple empty files that mess it up
<james_w> when you serialize an empty file addition you get no body, so the reader gets thrown off
<lifeless> pasky: ?
<lifeless> bah sorry pasky , tab completion fail
<lifeless> Peng_: ?
<Peng_> lifeless: Oh hi. Um. Do you have access to the queue of messages being held for approval by the mailing list software? I think one I sent might be being held.
<lifeless> for the main list? yes, though right now I can't surf
<lifeless> small matter of only irc working because its not actually on my machine :)
<lifeless> everything else is thrashing insanely
<Peng_> Oh.
<Peng_> Why?
<lifeless> writing a full scale test index
<Peng_> Oh.
<lifeless> to get a perf trace on index writing
<lifeless> and its uhm, well
<Peng_> I wanted to check the mailing list archive again before asking you about this, but Firefox crashed as I was writing. :D
<lifeless> I have 2G of memory
<lifeless> its vss is3G
<Peng_> Ouch.
<Peng_> Boy, I remember the days when I thought getting 1 GB of RAM felt a little excessive.
<lifeless> 'room for optimisation'
<lifeless> Peng_: the index have > 8000000 keys
#bzr 2009-04-19
<eka> hi al
<eka> all
<eka> I'm trying to serve bzr trhu http... but instead of using Apache of FastCGI I would like to use cherrypy... but I tried some code and don't have a clue... does anyone made it work with cherrypy?
<bob2> bzr will happily work over plain http
<eka> bob2: what I want to do is to use a standalone app to serve trhu http without the need of an apache or so...
<eka> bob2: maybe i'm missing something
<fullermd> If you're going to run standalone anyway, why not just use bzr:// ?
<bob2> that's fine, just serve it as a regular directory
<eka> bob2: trhu http?
<bob2> if you wnat to serve it via http (rather than bzr://) yes
<eka> bob2, sorry dont follow... i just use bzr server PATH ? and that will serve over http?
<Peng_> lifeless: Well, once you stop swapping, could you check the mailing list queue for me?
<lifeless> Peng_: if its held you geta mail saying so
<lifeless> Peng_: have you had one ?
<Peng_> lifeless: Oh, really? No, I didn't. It just vanished and I was guessing that might be why.
 * Peng_ looks at his mail host.
 * Peng_ sends again. :D
<Peng_> Hmm, I can send the email to myself, but maybe not my Gmail account.
<Peng_> Yay, Gmail got it.
<Peng_> lifeless: Do you know how large messages have to be before they need to be approved?
<Peng_> I wish I was sending something *worth* all of this inconvenience. :\ It's just the ConfigObj thing.
<Peng_> lifeless: Could you check the queue anyway? Because if it's not that, I have no idea where the messages are going. :\
<thewrath> hey is anyone home
<Peng_> Maybe.
<thewrath> perfect
<thewrath> i am using it for checkin and chekcout in a way to modify my code. that my issue is when i commit it it says for notes, fixed bugs, and author. when i put stuff in fixed bugs i get unrecognized bug  ...... commite refused. it has to be in 'tag:id' which i am confused about
<thewrath> i am wanting to push everything to launchpad
<thewrath> but i am just committing my code right now
<thewrath> i have entered this in 'LP:363538' and recieved:> bzr: ERROR: Unrecognized bug 'LP:363538'. Commit refused.
<james_w> lp:363538
<thewrath> so like this: lp:363538 lp:363537 lp:363534 lp:363520?
<thewrath> perfect tahnk you
<james_w> --fixes before each
<thewrath> ?
<Peng_> "--fixes lp:363538 --fixes lp:363537 --fixes lp:363534 --fixes lp:363520"
<thewrath> what does the --fixes do
<james_w> are you using a GUI tool?
<thewrath> yes and no
<thewrath> yes for that
<thewrath> for updating hte branch i am using command line
<CaMason> hi guys. Wondering if this is possible. In my bzr project, I've got a sub-folder. I now want to make this a standalone bzr project. Is it possible to do this whilst carrying the history?
<james_w> thewrath:try your line then
<CaMason> its `/myapp/plugins/myplugin` . I want to maintain 'myplugin' as a seperate project now
<thewrath> when i do that james_w is it supposed to auto update the status to fix released?
<james_w> nope
<james_w> not yet at least
<thewrath> ok
<Peng_> CaMason: You can use "bzr split" (probably). It really will keep the *full* history though, not just the history from /myapp/plugins/myplugin.
<CaMason> Peng_ that's no problem really. I just want to have it as standalone
<CaMason> is it possible to have a bzr project within a bzr project tree? i.e. if I added `myapp/plugins/myplugin` to bzrignore, and then had a branch in the plugins folder
<Peng_> CaMason: I think it'll automatically be ignored. You don't have to use .bzrignore.
<CaMason> ok. I've just read about split/join. Are those new features?
<LarstiQ> CaMason: see http://bazaar-vcs.org/NestedTreeProgress
<CaMason> right - so it works?
<CaMason> I see I need to bzr upgrade. Any idea which type I need?
<Peng_> CaMason: Note that you won't be able to go back after upgrading. And everybody else who has a copy of your branch will have to as well.
<Peng_> CaMason: Which format are you using now?
<CaMason> Pack 0.92
<thewrath> james_w: is that something that they are looking at
<james_w> yep
<Peng_> CaMason: Then you should probably upgrade to rich-root-pack.
<LarstiQ> CaMason: alternatively, you could use lp:bzr-scmproj, or version symlinks
<Peng_> CaMason: You might need pack-0.92-subtree, which is still considered kinda experimental.
<CaMason> whoa info overkill
<CaMason> what's lp:bzr-scmproj ?
<LarstiQ> CaMason: https://launchpad.net/bzr-scmproj
<LarstiQ> CaMason: a tool to combine branches
<CaMason> all I'm really trying to do is have a facility like svn:externals
<CaMason> the split/join method seemed like common sense
<CaMason> LarstiQ, that SCM Project looks like it may be overkill for me
<CaMason> perhap I just symlink and add the link to .bzrignore?
<LarstiQ> CaMason: that's possible
<LarstiQ> CaMason: join --reference would be the thing to do, yes. But it's not finished.
<LarstiQ> heya phanatic
<phanatic> hey LarstiQ
<CaMason> I just tried `bzr split myapp/plugins/myplugin` and it's thrown up `bzr: ERROR: No WorkingTree exists for /myapp/plugins/myplugin/.bzr/checkout/`
<LarstiQ> CaMason: hmm
<CaMason> I've removed the created .bzr folder, and commited some uncommited changes (oops)
<CaMason> and re-done the split
<CaMason> both 'sides' of the split now show the other half as being removed, when using `bzr st`
<CaMason> ok well, that seems to have worked :o
<clemente> Hi; I backed up in a hurry only the .bzr/ of a repository I wanted. Can I still check out the branches from there?
<Peng_> clemente: Yes. It's slightly complicated, though.
<LarstiQ> with help from `bzr heads`
<Peng_> clemente: Install the bzrtools plugin. Run "bzr heads" (or maybe "bzr heads --tips"?) to get the tip revision IDs of all of your branches. "bzr init" an empty branch, cd to it, "bzr pull . -r revid:<id>", then do the same for the other branches, or (probably) "bzr branch abranch -r revid:<id>".
<LarstiQ> some branches might not be on tips in the dag, that would then be harder
<Peng_> Good point.
<LarstiQ> clemente: but basically, if you know the revision (bzr heads helps to find those), you can restore a branch
<clemente> Peng_: heads --all, it is. I'm trying what you suggested
<Peng_> I don't remember, what's a dead head? *checks*
<Peng_> Ok, it doesn't say. :P
<clemente> This worked except for branches which don't show in âbzr heads --allâ
<clemente> But I suppose I can find it somewhere inside .bzr/
<joh> Hi, how do I undo a push?
<LarstiQ> joh: by using push --overwrite in combination with a revision you prefer
<LarstiQ> joh: say, `bzr push --overwrite -r -2` or `bzr uncommit; bzr push --overwrite`
<joh> LarstiQ: Ah, thanks!
 * SamB wonders why bzr-svn's cache for http://svn.webkit.org/repository/webkit is so big for him ...
<Peng_> Isn't WebKit really gigantic?
<SamB> I only checked out a little piece though!
<SamB> just http://svn.webkit.org/repository/webkit/trunk/JavaScriptCore/pcre/
<LarstiQ> SamB: my uneducated guess would be that it needs more than just that to determine the branch identity.
<LarstiQ> SamB: but maybe it does more than it needs to
<SamB> It does it again after I delete the cache, too, apparantly ...
<LarstiQ> SamB: that's what I'd expect :)
<SamB> jelmer: branching just http://svn.webkit.org/repository/webkit/trunk/JavaScriptCore/pcre/ ate about 183 MB!
<SamB> in ~/.bazaar/svn-cache alone
<Stavros> hello
<Stavros> is it acceptable to create a new branch just by copying an existing one?
<beuno> Stavros, yes
<LarstiQ> Stavros: cp -a wise? Yes.
<Stavros> ah, thank you
<Stavros> LarstiQ: what's -a?
<LarstiQ> Stavros: archive, implies -dpR
<Stavros> ah, the os x copy doesn't have that
<LarstiQ> Stavros: if the source branch uses a shared repositroy, it's best to have the destination remain in the shared repository (otherwise it can't find the revisions it depends on without handwork)
<LarstiQ> and some other differences in execution, but copying is a valid way of branching
<Stavros> what's a shared repository?
<LarstiQ> Stavros: the result of `bzr init-repo`
<Stavros> hmm
<LarstiQ> Stavros: if `bzr info` says something like:   shared repository: /home/larstiq/src/bzr
<LarstiQ> Stavros: then the branch is using one
<LarstiQ> heya pygi
<pygi> hi hi LarstiQ :)
<pygi> how goes it?
<LarstiQ> pygi: busy busy busy
 * LarstiQ relaxes on sunday with #bzr :)
<pygi> LarstiQ, ha, I know the feeling!
<pygi> heh, no relaxing here :(
<pygi> I have to design a new system ... deadline in two days
<pygi> and I can't really learn about it from anywhere, cause its a rather new thing :(
<LarstiQ> what kind of system?
<lampliter1> are there any Python IDE's that integrate well with bzr?
<LarstiQ> lampliter1: http://bazaar-vcs.org/IDEIntegration
<LarstiQ> lampliter1: I personally use vim
<LarstiQ> lampliter1: other than that, I'd suggest looking at pida
<lampliter1> I generally use Emacs but making it work with speech recognition is getting increasingly tedious.  Additionally my development environment is so messed up, I'm trying to restore it to sanity
<pygi> LarstiQ, a security one :)
<LarstiQ> lampliter1: possibly off topic, but are you aware of http://code.google.com/p/dragonfly/ ?
<pygi> LarstiQ, sorry, you need to say my name so xchat would light up :P
<LarstiQ> pygi: did you say something? I only get highlights when people don't use my name ;P
<pygi> LarstiQ, :P
<pygi> LarstiQ, do I shoot you now or what? :D
<lampliter1> dragonfly annoys me.  We have already three of those frameworks.  It's worse than Python web frameworks for replication of effort.  Of course my Python web framework is aimed at  handicapped people (Universal design principles) so that's okay.  :-)
<lampliter1> but yet, when you're disabled, you go through some really nasty hoops to do work.
<lampliter1>  bloody speech recognition...
<lampliter1> I've been speech recognition on a Windows guest virtual machine.  My host OS is linux and acts as a file server two all my virtual machines.
<lampliter1> And I do work on remote machines.
<lampliter1> The fundamental question is, how can I access all of these environments through various security hoops and barriers while still using speech recognition to drive whatever IDE I use
<lampliter1> the best I've come up with is to run the IDE on Linux, drag it into Windows via X11, use fam to trigger rsync to update the remote machine
<lampliter1> and if I can keep my bzr branch local, it solves a bunch of problems
<lampliter1> either I bored you or I scared you.  Sorry about either case
<LarstiQ> no, just occupied
<LarstiQ> lampliter1: I'm not active in the same area, but I'm not aware of competing libraries for Dragonfly?
<lampliter1> there is the raw natlink, then on top of that, we have vocola and unimacro
<LarstiQ> hmm
<lampliter1> I find that natlink is the most flexible since you  implement your grammar actionsin Python but it is a lot of work. vocola make simple things easy, medium things complicated, and complicated things almost impossible.  unimacro is something that takes quite a while to cross the learning curve and may be worth it but, it still doesn't make simple things easy to release the doesn't make difficult things hard
<lampliter1> just noticed one thing about dragonfly.  Looking through the code, the is a lot of the misspelled words with caps and concatenation of said fragments.
<lampliter1> Do you have any idea how bloody hard it is to dictate those symbols?  I mean, wouldn't you think that someone writing a macro package for speech recognition users write a package that could be dictated by speech recognition users
<lampliter1> symbols should be nothing but lowercase words concatenated or joined by underscores
<lampliter1> the stupid capitalization for classes etc. sets up a nasty situation where if you use the code, you are at greater risk to ruining your vocal track on top of your damaged hands
<LarstiQ> I'll pass it on.
<lampliter1> sorry but it's incredibly frustrating for me.  I have more ideas in my head than I can write code for.  Then add to that dictating stuff by voice, debugging hard to see errors introduced by dictation and general frustration with computers that aren't meant to be used by disabled people
<lampliter1> I get really cranky sometimes
<LarstiQ> lampliter1: I get that.
<lampliter1> I've got one project that's almost 10 years old that I haven't been able to release because I can't write enough code to get it done.  Damn frustrating
<lampliter1> LarstiQ: thanks.  Not a lot of people do
<lampliter1> what I need is a smart coding monkey that will listen to what I say, ignore me, and do the right things to get what I want done done.  :-)
<lampliter1> unfortunately the MIT programmers assistant Project hasn't moved forward
<LarstiQ> lampliter1: that, would be useful to more people than just you ;)
<lampliter1> Hell, a good program and by voice IDE would save so many people so much pain and return a lot of disabled programmers to productive life
<Peng_> Hmm, Google CADIE could do it, I bet. :D
 * Peng_ hides
 * lampliter1 tosses corned beef sandwich with sauerkraut and nice mustard in Peng_ direction
<lampliter1> but seriously, the biggest impediment we have is editing.  The features needed aren't very complex (ha) but the problem is, we can't get anyone interested in helping in doing the work that is burning our hands
 * LarstiQ nods at lampliter1 
<lampliter1> anyway, I should go eat lunch then walk the dog.  It's a gorgeous day out here near Boston and dog walking helps restore my sanity after my hands go poof
<LarstiQ> lampliter1: issues not shared by the majority often don't even register in their heads.
<LarstiQ> lampliter1: ok, have a good walk.
<lampliter1> I know.  I know.  Here's an ironic that a friend of mine who is the head of development at Dragon Systems pooh-poohed the need for a speech recognition driven environment.  Guess what, his hands are toast and now he can't build the environment....
<lampliter1> not enough market share...
<lampliter1> that should be "who was the head of development"
<LarstiQ> no longer because of his hands now?
<lampliter1> is/was/can/can't/... are all suspect.  :-)
<lampliter1> yes, his hands are bad.  Maybe worse than mine
<lampliter1> what we both need is a way to edit code by voice.  Code creation is not wonderful but we can do it
<lampliter1> we need to be able to identify things like predicates arguments array indices and then be able to modify them simply by voice
<lampliter1> for example, "change the second argument" should allow me to do more detailed editing on the second argument found on the current line.
<lampliter1> The basic principle is known as disambiguation vocal commands through reduction of scope.  Most the time disambiguation is by increasing the specificity of the command but if you're smart, as you dictate you can reduce scope dynamically by using what you dictated to identify what you're going to work on
<lampliter1> I should probably stop now because otherwise I will give you a two credit seminar in speech user interfaces
<lampliter1> lunch calls... oh, and by the way, thanks for the advice on the IDE.
 * LarstiQ tries to parse the sentence on scope again
<LarstiQ> and unfortunately still don't see concretely how that works
<LarstiQ> I get increasing the specifity of the command
<lampliter1>  sorry.
<lampliter1> First principle with speech recognition commands as you try to reduce ambiguity in order to increase accuracy and recognition
<lampliter1> there should be accuracy in recognition
<lampliter1> kind of proves my point.  :-)
<lampliter1> most of the time you reduce ambiguity by making the command more specific.  For example, set font color green
<lampliter1> "move to end of line"
<lampliter1> but you can also reduce ambiguity to reducing the scope of what you're working on.
<lampliter1> You can also reduce ambiguity by reducing the scope of what you're working on
<lampliter1> for example, editing a line of code (let me get one)
<lampliter1> grammar = Grammar("notepad_example", context=grammar_context)
<lampliter1> editing this is a bit tricky especially with select and say
<lampliter1> so let's try to change grammar_context to grandpa_context
<lampliter1> you'd couldn't just say change grandma to grandpa because there are multiple occurrences on this line and, in fact, there probably are multiple occurrences through the body of the code (method, class, file)
<lampliter1> so if you said change grandma to grandpa, you have an ambiguous command because you don't know the scope of what you're operating over
<lampliter1> if you said "edit second argument" you could reduce your scope to just that one argument
<LarstiQ> right
<lampliter1> all your environment would see is: context = grandma_context
<lampliter1> now obviously it is a further ambiguity here but I'm going to dodge that for the moment
<lampliter1> at this point you could say replace drama grandma with grandpa and everything should work okay
<lampliter1> but if you want to change context, a more specific command could reduce ambiguity by saying something like change first context or change its second context
<lampliter1> there's no need to do anything fancy when you're done because you really do a specific command or one that refers to the greater context of lines or methods
<lampliter1> it gets interesting when you have a partially formed expression.  But, if you do things right with template driven code creation, you never have a partially formed expression.
<lampliter1> The beauty of this technique is you can also use a variety of visual cues such as colors with high transparency highlighting what it thinks its operating on and indicators for where it sees arguments etc..  But that's really hard
<lampliter1> like I said, a two credit seminar :-)
<lampliter1> lunchtime
<mwhudson> Peng, Peng_: hello?
#bzr 2010-04-19
<spiv> rhkfin: perhaps you want the 'bzr-upload' plugin?
<Manganeez> mathrick: the problem does indeed seem to be the back-port commits into the 2.7.1 tag in my scenario. I'm having trouble thinking of a way around it.
<mathrick> Manganeez: I don't think any exists
<mathrick> backports are indistinguishable from conflicting edits
<Manganeez> In dreamland, where I live, I'm imagining somehow backing out all of the backport commits by rolling back to the rev when the tag was originally created, then merging to the new tag.
<mathrick> that might be possible
<mathrick> though it'd likely be somewhat involved
<Manganeez> Seems like that falls into the "rewriting history" category, though
<mathrick> Manganeez: yes, but it might be possible to coerce pipes / rebase into doing just that somehow
<mathrick> I'm not exactly sure, though, I don't have a very good grasp of how pipes work
<mathrick> I just know they somehow result in rewritten history without actually having done that
<mathrick> Manganeez: http://wiki.bazaar.canonical.com/BzrPipeline <-- maintaining patches on top of upstream branches is one of the listed use-cases
<Manganeez> Reading that now... :P
<Manganeez> also hadn't heard of bzr-pipes. Like I said, <-- n00b
<mathrick> since it works even with tarballs, which have 0 history, svn should be handled with no problems :)
<mathrick> Manganeez: pipes are hot new tech, I don't understand it myself yet
<Manganeez> the stacking seems a bit like loom, another thing I don't quite get
<mathrick> yes, looms are similar
<igc> morning
<lifeless> morning igc
<igc> hi lifeless
 * mwhudson is amused to note that hosting weave branches on launchpad has been really broken for a long, long time
<mwhudson> or any all-in-one format
<Manganeez> <-- n00b still catches himself thinking subversiony
<Manganeez> mathrick (if you're still there): based on experimentation, it's really seeming like the easiest way to track vendor svn development is to *not* have bzr-svn installed. Instead, just have a hybrid repo where you svn sw & bzr commit. Branch from that for customization branches.
<Manganeez> If it's installed, bzr-svn intercepts and prevents that from working.
<Manganeez> for centralized repo, branch from mirror to create the centralized, and branch from *that* for customization work.
<Manganeez> never push back to vendor mirror
<Manganeez> It just seems like, in spirit, bzr-svn should provide a way that's *easier*, not step on existing possibilities to make it *harder*
<Manganeez> anyone: is there a way to get a diff between the current branch and the parent branch? Which I think is the same as asking for the diff that would be applied if I pushed?
<spiv> Manganeez: "bzr diff :parent", although if the branches have diverged then "bzr diff -rancestor::parent" is probably more helpful.
<spiv> You may also find "bzr merge --preview" to be helpful
<Manganeez> ah, thanks spiv. I also just figured out how to do it with "--old"
<spiv> :parent is a location alias, "bzr help location-alias" or http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/location-alias-help.html
<Manganeez> "bzr diff :parent" produced no output. I think the old/new logic is just reversed from what I was looking for (parent had no missing changed for me, only the other way around). "bzr diff --old :parent" works.
<Manganeez> Basically, I want to see my customizations vs. my parent vendor-tracking mirror.
<lifeless> spiv: spm: https://code.edge.launchpad.net/~gz/bzr/kindness_to_FAT_and_other_utime_stories_epilogue/+merge/23545
<lifeless> merged by pqm, zaroo email involved
<lifeless> note the bug at the end :P
<igc> back
<lifeless> front!
 * joyer 
<joyer> is there new plan to boost bzr's first time clone's low speed & memory exhausted?
<joyer> every time a clone emacs repo...The whole system hung up(386M memory unbuntu).
<mwhudson> joyer: i filed a but about that last week
<mwhudson> bug
<mwhudson> joyer: https://bugs.edge.launchpad.net/bzr/+bug/562666
<ubottu> Launchpad bug 562666 in bzr "2a fetch is very cpu intensive" [High,Confirmed]
<lifeless> joyer: this is cloning over the network or locally ?
<igc> lifeless: :-)
<rhkfin> spiv: bzr-upload, will check, thanks!
<joyer> lifeless: over network.
<lifeless> joyer: from which host ?
<joyer> 'v no idea. I'm from asia... and type this `bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk'
<lifeless> ok, bzr.savannah.gnu.org - thats running plain http
<lifeless> so will be slow and use a lot of memory.
<joyer> than my CPU will be drain out by bzr for 5 hours or so.
<lifeless> This is a) expected, b) a fix will eventually be deployed, but its a configuration issue not a bzr bug
<joyer> I see. there may be some storage architectur diff between git/hg/bzr...
<joyer> but bzr seems need alot more memory
<lifeless> joyer: all three performan suboptimally over plain http; they need a server side component to perform best
<lifeless> joyer: try 'bzr branch lp:emacs'
<poolie> hi lifeless
<lifeless> joyer: its a mirror of the savannah branch, and should be faster and use less memory
<lifeless> poolie: hihi
<poolie> how's pqm?
<lifeless> poolie: pretty good; launchpadlib is very very very slow; I have fixes for the UI for when spm gets back from a out-of-house thingy
<poolie> ok
<poolie> and other stuff?
<lifeless> its happily merging from launchpad though
<lifeless> which is great. One small glitch to wrap up and then its can be forgotten about - its not reporting quite right.
<joyer> lifeless: i can tolerate the slowness. but memory consume too much.. why not cache out to disk??
<lifeless> various bugs looked at.
<lifeless> joyer: caching out to disk happens via swap, naturally.
<joyer> mwhudson: didn't notice it . i'wll check it .
<lifeless> joyer: we dont' caching the bulk of the content. Because you're using HTTP though, more is being kept in memory than if you use a smart server url - like the bzr+ssh://bazaar.launchpad.net/~vcs-imports/emacs/trunk
<lifeless> joyer: the bug mwhudson referenced isn't what you're suffering.
<joyer> lifeless: I'm behand a big firewall~
<lifeless> joyer: do you have ssh access ?
<joyer> lifeless: ok.. I'll take a look.
<joyer> lifeless: no.  a guess alot people at work are behind FW.
<joyer> lifeless: I still hope bzr can run politely on low memory machine (like mine). I'll try hack on the source code, and write a patch.(that will be not short)
<lifeless> joyer: we are working to reduce memory use
<lifeless> joyer: but emacs is a very large repository
<lifeless> joyer: how much memory do you have?
<joyer> 386Mb
<lifeless> that is a very small amount.
<joyer> lifeless: emacs isn't the biggest repo..mozilla is bigger.. also linux kernel.
<joyer> lifeless: bzr should scale up..
<lifeless> joyer: there are folk using bazaar on both of those as I understand it
<lifeless> joyer: heck, current GNOME uses 300 MB or so just booting.
<lifeless> joyer: We would like to be leaner on memory use, and there is some work going on.
<joyer> lifeless: thanks for the info.. I'll check the source code to gain some prove..
<poolie> lifeless: maybe i should try that idea of dumping gc usage into apport
<poolie> though maybe apport won't fit
<lifeless> poolie: if we get apport MemoryError exceptions, then apport probably will
<lifeless> OTOH by the time the exception handler runs, a lot of the memory may have been freed
<vila> hi all
<lifeless> eoding, time to pack
<poolie> cheerio
<poolie> hi vila
 * joyerh 
<napster> 'bzr lp:pull panther' returns 'permission denied public key' error :-( what to do?
<spm> napster: wild guess, but did you perhaps mean: bzr pull lp:panther?
<napster> spm, That what I meant, sorry for mistake :)
<spm> heh, is cool.
<C2H5OH> hi, is it possible to mix centralized and distributed workflow?
<C2H5OH> for example, my work colleages all use bzr in a centralized manner (with checkouts) but I would like to use it as branches
<fullermd> Sure.
<fullermd> What you do in your workspace has no relation to what they do in theirs (and vice versa).
<fullermd> 's kinda the basis of distributed right there   ;)
<C2H5OH> ok, so if I have a different branch and take care of merge myself, then it does not conflict with their linear histori, correct?
<C2H5OH> ok, I found it
<C2H5OH> unbind and bind might do the trick for me
<fullermd> I'd avoid that, myself.  It's coloring a bit outside the lines.
<fullermd> I'm not really sure what you mean by 'conflict with their linear history', but work is work.
<fullermd> They have to 'update' when they get a rev behind, or two revs.  Or 50 revs.  It doesn't much matter whether those revs are all on the mainline, or some of them are off to the right.
<C2H5OH> I mean, centralized manner forces linear history
<C2H5OH> (without merge commits)
<C2H5OH> but I've read that bzr log hides merge commits by default
<spiv> Right.
<fullermd> Oh, not really.  If you work purely in checkouts without ever using other branches, you won't (aside from some special cases) ever get any right-hand parents.
<spiv> Also, the presence of merge commits on the mainline won't interfere at all with someone that is using "bzr up" etc.
<fullermd> But that...  what spiv said.
<C2H5OH> ok, so then I should not be afraid of that
<spiv> (And if they ever do "bzr commit --local" then they will in generate merge commits, i.e. commits with multiple parent revisions, anyway)
<spiv> Definitely no need to be afraid.
<C2H5OH> I'll have to read more docs
<C2H5OH> in order to get familiar with the terms
<C2H5OH> coming from git/mercurial does not make it easy
<fullermd> It certainly presents different challenges than coming from CVS.
<C2H5OH> back to work then
<C2H5OH> thank you very much for your help
<C2H5OH> ;-)
<spiv> You're welcome!
<bialix> hmm, C2H5OH perhaps russian guy
<millun> hi
<millun> how can i list files commited between revisions #3 and #15?
<bialix> millun: bzr st -r3..15
<millun> thanks
<sven_sandberg> hi #bzr! i have a source tree with changes in two files, file1 and file2. i want to commit the changes in two different changesets: cs1 with changes in file1 and cs2 with changes in file2. i have ran 'bzr gci' and typed changeset comments for both files. but when i de-select file2 and commit only file1, the changeset comments for file2 are lost.
<sven_sandberg> since we now have the nice feature that changeset comments can be saved when a commit is cancelled, would it be possible that we could save the comments also when a file is not included in the commit?
<maxb> Sounds like cause for bug to be filed against bzr-gtk
<sven_sandberg> maxb, thanks for confirming that. should bzr-gtk bugs be filed at https://bugs.launchpad.net/bzr/+filebug too?
<maxb> I'd imagine it would be better to file against bzr-gtk not bzr
<maxb> though that's driven by my _assumption_ that the existing commit comment saving is presumably in bzr-gtk
<jelmer> maxb: it's in both bzr-gtk and qbzr
<sven_sandberg> maxb, jelmer, iirc, before this was in any official versions, i had to use custom versions of *both* bzr and bzr-gtk in order to save commit comments. i'm not sure which one of them would need to be patched for this to work
<sven_sandberg> ok, is it ok if i report it as a bzr-gtk bug?
<jelmer> sven_sandberg: I really think the commit message saving should be moved into bzr core
<sven_sandberg> jelmer, ok, so i'll report a bzr bug?
<nitian> mathrick: i was merging this http://pastebin.com/95Hj6QTP and now it has continued merging again from the last data stored till now!
<nitian> now i have got : Read from remote host bazaar.launchpad.net: Connection timed outnserting stream
<jelmer> sven_sandberg: against bzr-gtk for now
<sven_sandberg> jelmer, ok, will do
<mathrick> nitian: looks like your network is hosed
<nitian> mathrick: so should i cancel/kill the bzr merge
<mathrick> nitian: dunno, didn't it error out?
<nitian> mathrick: no it is still fetching revisions!
<mathrick> then probably let it do that
<mathrick> I don't understand why it'd be so slow, I get almost 2M/s here
<nitian> mathrick: but i guess it has gone way beyond the original download size!
<mathrick> nitian: then kill it?
<mathrick> huh, that thing's large
<vila> jelmer: ping, regarding https://code.edge.launchpad.net/~jelmer/bzr/more-colo/+merge/23592 , it seems this mp has already changed from this morning
<vila> jelmer: there are conflicts currently, still some None args (which I suspect are name=None)
<vila> jelmer: I'd like to review it but given the above... I'm not sure it is stable :)
<vila> jelmer: And I saw a branch_name instead of just name.. take your pick :)
<nitian> mathrick: i did this   http://pastebin.com/HxWTzx3b   but i am getting this error: Read from remote host bazaar.launchpad.net: No route to host
<MvG> vila: I've just replied to your review at https://code.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 and I'm here in case you want to comment. I'd be particularly interested in whether there was a misunderstanding with that cache remark of yours.
<jelmer> vila: thanks for the comments, I'll have a look
<vila> jelmer: k
<vila> MvG: looking
<vila> MvG: Wow, indeed, I misread
<MvG> I realize I might have avoided a bit of spam to the LP merge tool by trying IRC first and writing the mail afterwards, but it's too late for that now...
<MvG> vila: Glad that's solved then. I assume you now approve, so I'll wait for another approval. Thanks!
<vila> MvG: wait :)
<MvG> Sure.
<MvG> After all, what else can I do instead of waiting... :-) But I'll stay tuned here as well.
<vila> MvG: my remark still reflects a lack of docstring I think, it's a bit weird to have a parameter ignored like that and ISTM that specifying --author on the command line should take precedence above whatever default the log formatter is using
<vila> MvG: may be we don't have the right infrastructure to handle that yet,
<vila> MvG: but at least you should document that (a comment or a docstring is fine)
<MvG> vila: Please expand ISTM
<vila> It Seems To Me
<MvG> If the command line wouldn't take precedence, there'd be little point in that whole patch.
<vila> MvG: I'm downloading your branch to review it in place, obviously I miss some context here
<reyman> hello
<MvG> vila: My idea is that there are multiple facets to logs: one is general format, another is authors list, and others (maybe to be implemented in future) might include a distinction between real name, email or account name, or might include a choice between bug URLs, bug numbers or no bug references at all. You surely can think of many other ways to fine-tune any log.
<vila> MvG: ooooh yes I can :-/
<MvG> vila: So I want --format to choose the format, --authors to choose whom to list as authors, and so on. That way I can tune the format to match my needs, without having to implement a new format for every combination of these aspects.
<reyman> i'm starting a project with milestone on launchpad (ex lp:~sproject/1.0/1.0start for first milestone), i don't understand how i can push my code on this milestone, i try "push lp:~reyman64/sproject/1.0/1.0start" but bzr say : "bzr: ERROR: Permission denied: "Cannot create '1.0start'. Only Bazaar branches are allowed.""
<vila> MvG: authors should be an option to the format
<vila> MvG: bug we can't do that right now
<MvG> reyman: Push to ~user/project/name and then register name as the branch for that series. Milestones don't have their own branches.
<vila> MvG: you don't want every format to reimplement the author logic right ?
<MvG> vila: Look at line 60 of the diff: I made it an option to the format.
<vila> MvG: we're in agreement then
<reyman> MvG, ok i try
<MvG> vila: And no, I don't want to reimplement anything, that's why I want the logic in the base class and all derived classes inheriting from it.
<reyman> so MvG i have only one branch for one serie ... i cannot register multiple branche for one serie, isn't it?
<MvG> reyman: You're correct. You can have any number of branches associated with the project, and many might be closely related to a specific series on the content level, but only one of them is the official branch for the series as launchpad lists it.
<MvG> reyman: By the way: when you reach the milestone, you might want to tag it in bzr. That way users have easy access to it even when the series moves on towards the next milestone/release.
<vila> MvG: yet, ShortLogFormatter use short_author which force who to be 'first', so ISTM that doing bzr log --short --authors=all won't work no ?
<vila> MvG: Your test cheats to achieve that I think
<MvG> vila: the authors method ignores the who if -authors is specified. I'm pretty sure I even tested this on the command line.
<vila> MvG: Ha, right, damn I keep getting this backwards, please add a comment there !
<MvG> vila: Currently writing... :-)
<vila> or may be just reverse the code so it's more obvious that 'who' is relevant only if _author_list_handler is None
<reyman> So if i understand MvG , for example if i have 3 milestone for serie 1 : a, b , c . I have three branch 1a 1b 1c or only one branch 1 with tag for release a b c?
<vila> MvG: sorry for the late comments...
<MvG> reyman: The second one is the preferred setup, I guess. The first one is very svn-style, and might cause confusion in some cases.
<MvG> reyman: Of course, you could also have a single branch "trunk", configured as the main branch for all your series... There are a million ways, but some are more common than others.
<vila> MvG: bug one more thing: we try to always use keyword arguments as such, and the way to decide if an argument is a keyword one or a positional one is mostly based on whether it has a default value
<MvG> vila: Is use of ReST-style ``name`` to mark identifiers in docstrings good practice?
<vila> MvG: so, can you use short=Ture and sep=', ' in the short_author call
<MvG> Sure.
<vila> MvG: yes, not enforced but I think we are leading towards it, to be honest I think I use 'name' myself though
<reyman> Mvg, i'm trying to have a layout like bzr :) So you have only one trunk branch for each serie , and you tag it . Which name you associate with trunk of each serie ?
<vila> MvG: except when you use the :param name: construct where it's already clear that you're referring the parameter
<vila> reyman: we use the series itself: lp:bzr/2.2
<vila> reyman: series is always plural (don't ask me why, I'm not a native english speaker :-)
<MvG> reyman: The term "trunk" normally is per project, not per series.
<MvG> reyman: Looking at https://code.launchpad.net/bzr and looking at the link targets as your browser displays them, you'll see that the 2.2 series branch is in fact lp:~bzr-pqm/bzr/2.2, i.e. belongs to user ~bzr-pqm, project bzr, branch name 2.2.
<MvG> vila: pushing.
<MvG> reyman: The user is of course called bzr-pqm, not ~bzr-pqm. Sorry there.
<reyman> ok thks :) one other question (the last), when lp:bzr/2.2 is ok , all bugs fixed (:p ), you merge it into trunk ? or in fact bzr/2.2 have trunk for parent, and milestone are only for bugs correction ? In this case, you merge bug correction into trunk  AND bzr/2.2 ?
<MvG> reyman: I'm not too involved with how the bzr project handles things, but I personally found the following useful for my own, smaller projects: start with a branch "trunk", and a series "1.0" using trunk as its main branch. Work on it, do milestones and releases numbered 1.0.x, improve the code, until things become reasonably stable.
<MvG> reyman: Then when I want to work on a feature that might break that stability, I branch: I create a 1.0 branch off current trunk, and make that the main branch for the 1.0 series. I also start an 1.1 series having trunk as its main branch. New features go into trunk. Bug fixes should be written against 1.0 if possible, and I can merge the 1.0 branch into trunk from time to time.
<MvG> In the past, I've created the new branch starting with the first release of a series. That caused a lot of troubles, though: people submit fixes against trunk, and it takes more work to get them into the release series. This is the reason why I suggest splitting stable and trunk branches only when you actually introduce new features.
<MvG> vila: Have you read the new docsting and comments? Things better now?
<vila> MvG: yup
<reyman> ok MvG thx a lot for your help :)
<MvG> lifeless: As you already did a review of its predecessor, would you like to review https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 as well?
 * MvG is afk for a while.
<seeg> hello
<seeg> i have a small problem
<seeg> sometimes when i push a repo, the transfer stops because of some reason. when i try to push again i get file locks and the repo becomes dirty
<seeg> how to clean this mess up?
<seeg> i mean other than removing the repo and branching it anew
<maxb> I seem to remember that that error message actually *tells* you how to clear the locsk
<mathrick> seeg: bzr break-lock
<seeg> ah, this is what i needed :)
<seeg> mathrick, thanks ;)
<mathrick> you're welcome
<mkanat> spm: ping -- did you see my most recent request for info relating to the last two traces posted to the codebrowse hang bug?
<blueyed> what should I do with http://pastebin.com/S4psCNhi ?
<maxb> blueyed: line 9, "bzr: interrupted" - you Ctrl-C-ed it or it did that all by itself?
<blueyed> maxb:  I did it.
<blueyed> but that should just revert to previous state.
<blueyed> it feels like "bzr revert" deleting my files!
<maxb> Did you do it because the 'bzr up' was taking far too long, or would it be worth moving aside the pending-deletion directory and trying 'bzr update' again?
<seeg> what is this error:
<seeg> bzr update
<seeg> bzr: ERROR: Permission denied: "/home/przemek/Programming/Python/.bzr/branch-format": [Errno 13] Permission denied: u'/home/przemek/Programming/Python/.bzr/branch-format'
<seeg> ah, ok, i got it :)
<maxb> seeg: "Permission denied" of course.
<seeg> yeah, i try to create a branch of files on my disk on a remote computer
<seeg> somehow it's difficult
<seeg> i do bzr branch xxx@xxx/path
<seeg> but this doesn't create a working tree on the remote server
<maxb> seeg: Please, don't obfuscate your commands. (I suspect you've changed the meaning of that one by over-obfuscation)
<seeg> well, from my local machine i did bzr branch sftp://login@host/path/to/branch
<midichlor> i am getting this error while $bzr add: bzr: ERROR: Could not acquire lock "/home/mid/project/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable')
<midichlor> i think i accidently edited som file in .bzr
<midichlor> what should i do?
<blueyed> maxb: I will move it away and try again - but this is distracting / causing data-loss-fear.
<maxb> blueyed: Well then, why not just back up your changes via a 'bzr diff' first, and be unfearful?
<blueyed> maxb: done so. point remains: why doesn't ctrl-c revert/break the "bzr up"?
<blueyed> why do I have to cleanup to dirs after that?
<maxb> I am not aware of whether that is supposed to be necessary or not
<blueyed> Also: "Conflict adding file blogs/rsc/js/debug.js.  Moved existing file to blogs/rsc/js/debug.js.moved." is no conflict, if the file has the same content IMHO? new bug? reported already?
<blueyed> maxb: me neither, but common sense is :D
<blueyed> I'll file a new bug about the conflict when adding the same file, ok?
<midichlor> maxb: could you help me too?
<maxb> midichlor: Are you using Windows?
<midichlor> maxb: no, ubuntu 9.10
<maxb> hmm
<maxb> What does "lsof /home/mid/project/.bzr/checkout/dirstate" print?
<maxb> Is NFS or Samba or anything like that involved?
<midichlor> maxb: no. i havent been dealing with any of the above
<midichlor> maxb: http://pastebin.com/KWnk4LfF
<maxb> Find and close both of those processes (one "bzr" and one "editor")
<midichlor> maxb: as in kill 15225 ?
<maxb> If necessary, but better would be to find the open editor session and quit it cleanly, if you can
<RumblePure_> hi lifeless.
<blueyed> Hi
<wilx> Hi.
<wilx> I am slightly confused about Bazaar. Is each working copy a branch effectivelly or does it some concept closer to Subversion branches?
<lifeless> wilx: each time you run 'branch' or 'push' you're making a branch (or updating a branch)
<LeoNerd> Hrm... I just 'rebase'd in the wrong direction...
<LeoNerd> I don't suppose there's any nice easy way to fix that, is there?
<LeoNerd> Ah. OK.. managed to fix by some cunning branch/replays... probably broken its hash now but I doubt anyone (else) has it checked out
<lifeless> LeoNerd: bzr heads --dead; bzr pull . -rrevid:oldhead
<LeoNerd> Ahyes, that would have done it too
#bzr 2010-04-20
<igc> morning
<poolie> spiv, hi
<poolie> igc, spiv, so in looking at the codebrowse stats it's interesting that the tags file is very hot
<poolie> we may be accessing it too much over plain http
<spiv> Huh, that is interesting.
<spiv> Separately, I've noticed the get_tags_bytes RPC sometimes gets called more than is strictly necessary, perhaps due to the same root cause.
<poolie> probably
<poolie> while i was at the hospital cafe the other day i started adding the test-factory concept
<poolie> i might call it test subjects to avoid touching any sore points about lp test factories
<luke-jr> jelmer: my bzr-svn problem seems to be rooted in it deciding old-old paths are not branches
<luke-jr> is it possible to tell it *tags* are tags and anything else is a branch? :/
<mwhudson> luke-jr: you can set up a custom layout in ~/.bazaar/subversion.conf
<luke-jr> mwhudson: bzr-svn doesn't like it
<luke-jr> branches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*
<luke-jr> tags = armagetronad/tags/*/armagetronad;armagetron/tags/*;armagetronad/tags/*;armagetronad/armagetronad/tags/*
<mwhudson> ah i see you're ahead of me then :-)
<lifeless> poolie: so what are you and igc hacking on ?
<lifeless> poolie: re test-factories, I wish you could explain better what you mean there.
<igc> lifeless: a few things ... poolie is helping me get lp running in a chroot
<lifeless> igc: I found a VM was much easier
<lifeless> FWIW
<igc> lifeless: and we're hoping to clean out the loggerhead merge queue as well
<poolie> lifeless: there was a thread from about september last year
<poolie> 'rfc testfactory' or something like that
<lifeless> poolie: yes, I remember that thread
<poolie> basically i was going to get around to doing the consensus position from that
<lifeless> ah, I didn't remember a consensus other than 'caring about test quality matters'
<poolie> which was to make setup of test data "shorter, standardized and declarative"
<poolie> i think that was aaron's description
<igc> lifeless: and poolie's explaining hydrazine and the nice work you're doing on improving lp-pqm integration - sounds really promising IMO
<lifeless> igc: its fixes some process bugs for us
<lifeless> should let us add more committers more easily
<lifeless> and makes it easier to migrate to tarmac if/when we do that
<igc> lifeless: right. I'd like to leverage all the above to make it easier to land stuff from Explorer
<poolie> lifeless: where does the failure message go to?
<lifeless> poolie: subunit-filter -> lp merge proposal
<lifeless> poolie: bugs filed about getting binary safe attachments on mp's
<igc> lifeless: IIUIC, if a user can toggle the status of a MP from inside Explorer via launchpadlib, then your magic will take care of landing the associated branch from there?
<poolie> k
<poolie> igc, yes, it should
<poolie> and it should be trivial to set it
<poolie> finding the right mp may be slightly harder
<igc> poolie: for a given repository, I'll simply list the MPs for the matching lp project in a panel
<igc> with some action buttons next to each one say
<lifeless> igc: yes
<lifeless> finding the right mp is pretty easy.
<lifeless> you can crib from pqm/queue/lp.py - take you ~ 5 minutes
<lifeless> listing all the mp's makes sense though, to let them choose the branch
<lifeless> igc: one [important] thing is to show the diff, because NEWS in particular will often require a manual fixup before PQM submission, to move entries to the right stanza
<igc> lifeless: good point
<lifeless> this is a significant sticking point on using MP's to control things
<lifeless> we kindof end up having to:
<lifeless> make a new branch
<lifeless> fixup
<lifeless> submit that as an mp
<lifeless> self approve as 'fixup for xxx'
<lifeless> queue
<igc> lifeless: so having an integration branch remains a part of the workflow puzzle
<lifeless> igc: when releases happen, or things sit for a while, yes.
 * igc lunch
<lifeless> spiv: btw your branch is pretty certain to be erroring, its just blowing up in the exception handler handler
<lifeless> spiv: I think its fixed [reporting] now - this run should do better
<mkanat> mwhudson: Hey hey. Any chance of getting the logs that I wanted?
<mwhudson> mkanat: do you have the times to hand?
<mkanat> mwhudson: They're in the attachment, I could go find them.
<mwhudson> i guess i can too
<mwhudson> yay i think the times in the attachment are in NZST
<lifeless> rot12 is fun ? :)
<mwhudson> ah, actually not
<luke-jr> hmm, one-liner patch to svn-bzr likely to get in as a bugfix? :p
<luke-jr> lp:~luke-jr/bzr-svn/bzr-svn-longest-branch-path
<lifeless> luke-jr: submit that via launchpad ;)
<luke-jr> any way to go back and add parent revids to revisions?
<luke-jr> I can add revprops on the svn end if needed, I think
<lifeless> http://bouillon.math.usu.ru/articles/ctre.pdf
<lifeless> ^- rev ctrl geek alert
<lifeless> luke-jr: in general, no.
<luke-jr> :/
<lifeless> you could rebase/rewrite
<mwhudson> mkanat: i commented on the bug report
<mkanat> mwhudson: Thanks.
<mwhudson> mkanat: i hope it's useful
<luke-jr> lifeless: I don't want to rebase or write anything
<luke-jr> just add missing metadata
<lifeless> luke-jr: so bzr revisions are immutable
<luke-jr> lifeless: why?
<luke-jr> I'm going to have to change all the file-ids sometime too
<lifeless> why?
<poolie> spiv, thanks for the tribunal mp
<poolie> how did it work aside from that?
<luke-jr> lifeless: to maintain compatibility with existing branches if possible
<lifeless> luke-jr: but existing branches will have the current file ids
<lifeless> luke-jr: so I don't follow
<luke-jr> lifeless: the existing branches are all based on a bzr-svn screwup
<luke-jr> I am trying to recreate our Bazaar HEADs properly
<lifeless> ah
<luke-jr> so we can actually merge between stable and trunk
<luke-jr> and useful things like that
<luke-jr> right now, the Bazaar HEADs start revision 1 at the import to Subversion
<luke-jr> rather than at the original import into CVS
<luke-jr> also, side note: I will need to ensure I can repeat this again later, since Bazaar STILL can't mirror Subversion losslessly at the moment :/
<luke-jr> so a third import will be needed when Bazaar *can* losslessly contain the history
<spiv> poolie: it's pretty slow when fed a full test run from bzr
<spiv> poolie: I haven't got to the point of profiling
<spiv> poolie: I've got some other changes in https://code.edge.launchpad.net/~spiv/tribunal/experimental that I'm less certain about, but made it a little nicer for me
<poolie> yeah it does seem a bit slow
<poolie> or like it gets stuck
<spiv> poolie: io_add_watch seems to basically be a wrapper around poll(2) on an fd, and so feeding it a file doesn't really work well because they always report as ready for reading
<poolie> for me it works to give it a plain file but not a pipe atm
<spiv> poolie: So I ripped that out (although it might be more appropriate for reading from a pipe?), and also used add_idle or something instead of timeout_add(1, ...)
<poolie> folding together "neither success nor failure" probably makes sense
<spiv> poolie: and borrowed some progress code from subunit2gtk to give more info in the statusbar
<poolie> i see
<poolie> that looks nice
<spiv> Oh, and changed it to filter xfails with skips
<poolie> right that's what i meant about folding them together
<spiv> And added a separate filter for unknowns (which in my use were just flickering on/off as tests loaded)
<poolie> mm
<spiv> Although I don't think that's a great change.
<poolie> that actually needs to be handled a different way i think
<spiv> But it did prove I knew how the ui.glade file worked :)
<poolie> i mean if we're really getting unknown test results that's one thing
 * luke-jr mutters.
<poolie> but the case of a test just being in progress is different
<spiv> It's really "incomplete" in this case, rather than "unknown"
<spiv> Right.
<poolie> you know there is a gui for glade? :)
<spiv> I do :)
<poolie> i guess i'd be surprised but happy if the input code can be as simple as you have it
<spiv> But it seemed quicker & easier to do this change via XML hacking, and I think I was right :)
<spiv> I'm not sure that the input code as I have it will cope well with a pipe that hasn't got the full stream ready to read yet.
<spiv> One effect of removing the timeout_add calls is that Ctrl-C on the console now works as expected.
<lifeless> poolie: in case it wasn't clear, its safe to merge: approve in email/the web ui
<lifeless> poolie: pqm looks for merge: queue, not merge: approve
<poolie> that's what i understood now, but i think this is not clear to everybody
<poolie> or whether that's going to start happening in the future
<lifeless> poolie: I'm going to update the merge docs once the glitches are gone
<lifeless> poolie: for now I want to keep email as the 'official' way to submit stuff
<poolie> ok
<poolie> that makes sense
<lifeless> poolie: so https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
<lifeless> poolie: looking at it, I made it in progress because vila had decided to hand the writing of the tests back to INADA; I was following suit but setting the metadata
<vila> hi all !
<fullermd> Eek!
 * fullermd hides.
<poolie> hi vila
<poolie> lifeless, vila, so basically i think if someone has half a patch and doesn't seem to be getting the tests (or cleanups or whatever) finished
<poolie> we should actively help them
<poolie> if necessary by writing the tests
<lifeless> I think we should only do that after discussing with them unless we particularly want the patch
<vila> poolie: sure, I will look at it today (and to brian's append_revisions_only one)
<lifeless> poolie: particularly as you seem to mean this to apply to non-staff contributions [or something, I'm unclear what the heuristic you use is]
<vila> lifeless: you seem to be patch piloting quite well so far, do you intend to make it official ? :)
<lifeless> vila: I'm not patch piloting; if I was I'd be implementing stuff as needed; thats part of the pp definition atm
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.1 is out
<vila> was worth a try :)
<lifeless> vila: I'd be happy to if I wasn't moving house this weekend
<vila> lifeless: thanks for the cleanup anyway !
<vila> lifeless: tada ! Happy moving !
<lifeless> parthm: we could use tempfile.mkstemp to make .bzr.log perhaps
<igc> hi vila!
<vila> lifeless: I would have help if I wasn't that far :0)
<poolie> lifeless: if somebody's done some work on a patch, and it has value, and we think they won't finish it off themselves, we should finish it
<poolie> you can get an idea from someone's history of whether they can/will finish it
<vila> poolie: fully apply to brian's one, I'm a bit less comfortable with naoki's one but I think it's still a step in the right direction
<poolie> fully apply?
<lifeless> poolie: I kindof agree, but I think your dials are overly sensitive, or something.
<vila> poolie: your comment " it has value"
<parthm> lifeless: i thought of that earlier. rename is guaranteed to work on posix but not on windows (IIRC it errors on windows) so the update from martin_gz seemed good to me.
<vila> fully applies ?
<poolie> i see what you mean
<lifeless> parthm: oh, right, we can't specify the full name. Ignore my suggestion :)
<poolie> yes, we have a difference of opinion as to what's worth doing
<vila> lifeless: Are there updates to your feed-pqm branch ? What is the consensus around it ?
<lifeless> poolie: I want to help folk over a hump they can't get over when any of a few conditions are true: they are likely to come back and do more; they are struggling and pointers won't be enough; we would be working on teh patch anyhow
<parthm> lifeless: thanks for the review of bug #529930 mp. i have updated the testcase to use user_encoding.
<ubottu> Launchpad bug 529930 in bzr "bzr aliases don't support unicode characters" [Medium,In progress] https://launchpad.net/bugs/529930
 * parthm is new to unicode but dislikes unicode errors
<poolie> join the club
<lifeless> that was incredibly bad reception - or transmission, can't tell
<lifeless> I had 3 bars
<poolie> srsly
<lifeless> yes, except more like
<lifeless> ssy
<lifeless> poolie: I'm thinking of either: changing the behaviour of pull --remember when there is a locations.conf, to remove configuration from locations.conf if it would override the --remember, or to have branch.conf win for local branches
<lifeless> ditto push --remember
<vila> lifeless, poolie : Where are we with https://code.edge.launchpad.net/~lifeless/hydrazine/cron/+merge/23213 ?
<poolie> sounds good
<lifeless> vila: you can use it to submit things to pqm
<vila> lifeless: I now I can, I'd like to know if I *should* :-)
<poolie> heh, the last commit on the cron branch is "remove cron mode?"
<vila> s/now/know/
<lifeless> vila: sure; its merging robustly, but it has issues showing errors
<lifeless> vila: debugging is a long winded thing (need a LP instance to talk to yada yada), so its high latency, even though its not high-staff-time
<poolie> issues meaning it can't show them at all? :)
<lifeless> vila: once the quirks are gone, I'm thinking to put the changes into bzrlib.plugins.launchpad
<lifeless> vila: and have hydrazine call into that on a per-branch basis
<vila> Is it the 44M mail spiv was referring to ?
<lifeless> poolie: some of the time :(
<lifeless> vila: no
<vila> lifeless: that would be lovely for my use case :)
<lifeless> vila: thats subunit
<poolie> vila: it gives you something like "IndexError: None"
<lifeless> poolie: thats on success ;)
<lifeless> poolie: but is, I think, fixed.
<poolie> if that's success i'd hate to see failure :)
<poolie> :)
<lifeless> poolie: indeed. Failure was spmdo tail pqm.log
<vila> lifeless: I had failures last week and never got any mail, we tried to diagnose it with Chex, but never concluded, in the end I fixed the problem and sucessfully merged
<lifeless> which is very suboptimal
<lifeless> vila: that would be the 44M email
<vila> lifeless: do you which server is blocking that ?
<lifeless> vila: thats fixed, but the fix isn't robust yet; have just had spm rollout a pqm to gather the output and let us analyze for the reason of teh failure
<parthm> does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
<ubottu> Launchpad bug 564605 in bzr "bzr should ignore java class files by default" [Undecided,New] https://launchpad.net/bugs/564605
<vila> lifeless: ok cool
<lifeless> poolie: yes, --cron became obsolete with pqm.queue.lp
<poolie> lifeless: so atm i think i should merge that branch but give you a choice of two commands
<poolie> 'queue by email' and 'queue in launchpad'
<poolie> since you do in fact have these two options now
<spm> you should have a third : "queue by sheer awesomeness"
<lifeless> poolie: ok, I can reinstate a separate command, but I'm not really game to try and eliminate all the cruft
<lifeless> poolie: by which I mean there will be duplicate code
<vila> lifeless: mark it as deprecated :-P
<vila> lifeless: and spam the users about the alternative
<poolie> i'll try
<lifeless> vila: no, thats not reasonable when we're still supporting email submission
<poolie> two commands in one program seems better than two branches
<lifeless> poolie: I know what I changed, I'm happy to do it
<lifeless> poolie: it would be nice to have hydrazine look at the conflicts list too
<lifeless> what I need is the self user id from launchpadlib
<parthm> poolie: does it seem reasonable to ignore java class files by default? if so i could try to create a merge proposal for bug #564605
<ubottu> Launchpad bug 564605 in bzr "bzr should ignore java class files by default" [Undecided,New] https://launchpad.net/bugs/564605
<poolie> lifeless: so in short, in case we don't catch up
<poolie> i do want you to adjust that knob upwards
<lifeless> poolie: hydrazine 'e' command added and pushed to the cron branch.
<poolie> ok thanks
<lifeless> poolie: I want to discuss that with you; I'm pretty sure we will not be doing as best we can for the project by doing that
<poolie> happy to discuss it but please also just do it for now
<vila> lifeless: lifeless missing ':' line 182
<lifeless> vila: bah, thanks
<poolie> great, thanks
<lifeless> vila: pushed
<vila> lifeless: pulled
<lifeless> jelmer: what should format.open(name='xxx') raise on a non-supporting colocated-things format ?
<speakman> morning folks
<james_w> lifeless: how did this bzr-builddeb change work???
<james_w> I even think we've discussed this change before
<lifeless> james_w: does it not work for you ?
<lifeless> james_w: oh right, global scope commands. bah
<lifeless> clearly I have '' in my path inappropriately
<jelmer> lifeless: NoColocatedBranchSupport
<lifeless> jelmer: and name!=None is thr right condition ?
<lifeless> well, is not
<MvG> lifeless: wrt bug #560030, what exactly are you proposing? Should we get all major distros to provide a bzr-bash-completion package before we drop stuff from the bzr main tree?
<ubottu> Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/560030
<lifeless> MvG: debian and redhat certainly
<jelmer> lifeless: yeah
<lifeless> MvG: not necessarily wait for them to be done, but have the maintainer ack and be prepared
<MvG> lifeless: Do you want to contact them? If I do, it might seem like I'd simply trying to maneuver for a larger audience for my plugin. If you say that's the future, they are more likely to take it serious.
<lifeless> MvG: the bug and review feedback are pretty clear
<lifeless> MvG: I think they will take you seriously ;)
<MvG> OK, got a point there.
<lifeless> I'd just say something like
<lifeless> 'hi, this is a heads up, we're about to merge a branch deleting xxx, there are replacement, better, scripts at yyyy, we wanted to make sure that this is known now, rather than at the last minute'
<MvG> Do you have contact addresses for maintainers of the RedHat package?
<lifeless> he hangs out here :P
<lifeless> don't remember the name offhand
<james_w> abadger1999 will at least know who it is if it is no longer him
<spiv> Ooh, I think my shiny new news_merge logic is working.  The prototype doesn't blow up in manual testing at least...
<MvG> jelmer: How about Debian? Should I write to pkg-bazaar-maint@lists.alioth, or is it enough that you read the above?
<lifeless> spiv: cool
<lifeless> spiv: hey
<lifeless> spiv: I have a further Commands cleanup issue
<spiv> Time to write some proper automated tests for it, but right now it's dinner time :)
<lifeless> spiv: subclasses  - super().
<lifeless> spiv: food for thought.
<spiv> Super-duper.
<speakman> I've got yet another workflow question comming. Hold on. :-)
<spiv> lifeless: I guess the current answer is "don't upcall"?
<lifeless> spiv: Not entirely sausagefestfactory
<MvG> By the way, I've got another merge request for which I'd like comments here: https://code.launchpad.net/~gagern/bzr/bug387117/+merge/23750 about ListOption(..., param_name=...) which is currently broken.
<spiv> Anyway, food time.
<spiv> lifeless: btw, the better-news-merge branch, while still rather messy, can read a template file from a configurable location (rather than using the hard-coded list).
<lifeless> spiv: sounds nice
<spiv> lifeless: as well as having a more capable parser
<speakman> Me and my coworker are about to make a facelift to one of our application. The current stable version is in trunk, and we suppose all facelift work should be done in a separate branch of trunk. But how do we work together on this branch in best practice? Beside our own workstations we also have a bzr smart server set up on a dedicated server machine. Any recommendation how to proceed?
<lifeless> speakman: just do it ?
<MvG> speakman: I'd say create a branch off trunk on the smart server, and let contributors decide whether they want to check it out or branch from it.
<jelmer> MvG: Sorry, I think I missed the context :-)
<speakman> We're only two working on this, but we will be working with overlapping things i guess.
<MvG> speakman: In terms of http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html you two either use the centralized approach (with or without local commits) or the decentralized with shared mainline. In both cases, mainline would be the facelift branch, not trunk.
<MvG> jelmer: Bug #560030 plans dropping bash completion scripts, and lifeless wants distros made aware of this upcoming change up front.
<ubottu> Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/560030
<speakman> So the preffered workflow in this scenarios is the centralized (SVN) type?
<jelmer> lifeless: still around?
<lifeless> very
<MvG> speakman: Depends on your personal preference. In particular whether you want to resolve possible merge conflicts and share your changes at almost every commit, or whether you'd rather keep your stuff to yourself until you decide it's ready for sharing.
<MvG> jelmer: So I'd still like to know whether the people maintaining bzr for debian are now sufficiently aware of the fact that bash completions are about to go, and that there is my bzr-bash-completion plugin as suggested and superior solution. If not, I'd write a mail about it.
<speakman> I don't actually have any preference, and every time I just choose one workflow, I always hit issues one way or another :)
<speakman> That's why I'm asking the pro's before starting the facelift project :)
<lifeless> speakman: don't don't choose one workflow - use many :)
<lifeless> speakman: seriously, different strokes for different issues
<lifeless> speakman: clearly you want a facelift branch; make one, work on it.
<MvG> speakman: In that case I assume that your edits overlap in a way that is bound to cause extra work unless you strictly serialize them. Might be an indication of bad code design or bad task assignments.
<speakman> Earlier I think I've seen something where each user had their own branches on the smart server, like /srv/bzr/ourproject/mybranch and /srv/bzr/ourproject/coworkerbranch
<lifeless> If you are getting lots of big conflicts, merge more often with each other (the ultimate example of that is per-commti)
<speakman> lifeless: but we will be two working on the same "feature" :-/
<lifeless> speakman: so ? I don't see why you feel that make a difference
<MvG> lifeless: "don't choose one workflow" might apply to bzr usage in general, but for working on one specific task I'd prefer not to change workflow too often... :-P
<speakman> MvG: You're hitting the spot; it's *very* bad code design, but the facelife project is the last resort for that codebase though :)
<speakman> lifeless: but if we're supposed to merge often - then the checkout/centralized workflow is pretty much it?
<MvG> speakman: If edits overlap so often, then as lifeless points out, you might want to merge for almost every commit, in which case the centralized svn-stype approach would indeed be best.
<lifeless> speakman: the more often you merge, the smaller conflicts are; dial-up the number of merges you do to match the work you're doing.
<speakman> I think the centralized workflow will be it then. Thanks :-)
<speakman> And then - how "often" should one commit? Are there any rules of thumb?
<lifeless> speakman: often
<mathrick> speakman: merging doesn't necessarily imply a centralised workflow
<mathrick> you can just cross-merge from each other's branch
<lifeless> speakman: ifyou're using centralised to avoid conflicts, you want to be committing a lot, otherwise you're no different than just merging every now and then
<mathrick> speakman: how many people will *not* be working on the facelift?
<speakman> lifeless: ok, thanks alot!
<speakman> mathrick: not working? :-)
<lifeless> by a lot, I mean multiple times an hour
<mathrick> yeah, how many developers are there who don't participate in the facelift?
<speakman> mathrick: we're just two programmers, and both will be working on the facelift :)
<mathrick> oh
<mathrick> speakman: then you just do bzr branch stable facelift; bzr branch facelift facelift-speakman; bzr branch facelift facelift-coworker
<jelmer> MvG, lifeless: I'm not exactly sure what's expected of me here
<mathrick> and then facelift becomes your integration branch, with stable still being there in case you need it
<jelmer> MvG, lifeless: Does removing this completion script cause shell completion to break for existing users?
<lifeless> jelmer: a decision about what to do in debian when bzr drops its included completion scripts; ideally package up the rplacement.
<lifeless> jelmer: it depends, how do we deploy them at the moment?
<lifeless> like, do users have it on by default, or do they source it, or copy it, or ...
<mathrick> lifeless: wouldn't making their personal branches bound to the main facelift branch be best for merging here? This way they'll always be sure to have a single codebase
<MvG> bzr deploys them in contrib, debian places them in /etc/bash_completion.d/ , from there on I'm less than sure.
<MvG> But I'd assume there is some kind of framework for selecting thise completion scripts you want to enable on a per-user basis.
<lifeless> mathrick: doesn't really make any difference; regular merges are regular merges
<mathrick> yeah, I mean just for code hygiene and not forgetting to push
<lifeless> mathrick: whatever works for the individuals involved
<lifeless> mathrick: I don't think there is a gold standard 'best' here
<mathrick> lifeless: the decision about completions is usually global, you either enable it and then get all installed completions, or not and then you don't.
<lifeless> jelmer: ^
<mathrick> lifeless: fair enough
<MvG> In that case I wonder why Debian installs BOTH bash completion scripts, bzr and bzr.simple... :-/
<lifeless> jelmer: ideally we'd have replacement packaged and recommended: on by the bzr package
<MvG> I don't have a Debian/Ubuntu at my fingertips just now, otherwise I'd investigate this more thoroughly.
<mathrick> speakman: anyway, you can make your personal branches checkouts, this way every commit you do locally will be instantly mirrored on the integration branch. And ideally, you want to sit next to each other and inform clearly what you are about to commit and what you'll be working on next
<speakman> mathrick: that's pretty much how it works practically. We're sitting next to each other, and due to the (lack of) code design we really need to work tight on this.
<mathrick> right
<speakman> final conclusion; bzr branch bzr://smartserver/ourproject/trunk bzr://smartserver/ourproject/facelift, and then "bzr checkout bzr://smartserver/ourproject/facelift" on each of our workstations.
<speakman> Then go buy intercom :)
<jelmer> MvG, lifeless: ok, thanks
<mathrick> speakman: yup; you might also consider tagging the starting point of the facelift
<jelmer> MvG, lifeless: I'll file a RFP when I do the next upload
<MvG> jelmer: Please expand RFP.
<lifeless> request for package
<MvG> Thx.
<MvG> Debian done, Ubuntu by inheritance hopefully done as well. RedHat maintainer still unknown. I haven't even found a redHat package database online, only one for Fedora. https://admin.fedoraproject.org/pkgdb/acls/name/bzr lists 3 users with commit privileges, one of them the owner.
<jelmer> MvG: abadger1999 is (one of?) the Fedora maintainer
<mathrick> MvG: I thought RH doesn't have a non-fedora package list anymore, given how RH is basically fedora + support + very long release cycle
<lifeless> MvG: redhat is fedora as far as we're concerned
<MvG> So we'll wait for abadger1999 to react.
<MvG> In the meantime I'll go for lunch.
<speakman> mathrick: hm... I don't get it - why tagging when working in a branch..?
<mathrick> speakman: to have an easy reference to the starting point
<mathrick> speakman: otherwise you'll have to remember the first revision you branched from
<speakman> oh yes, you're absolutely right! thanks!
<lifeless> mathrick: I don't get the tag either
<lifeless> mathrick: whats it for ?
<speakman> Hm looking at the commit history my coworker seems to have commited with wrong email address (login@machine). Is there any way to change that retrospectively?
<mathrick> lifeless: seeing the full extent of what you've done for example
<mathrick> speakman: no
<speakman> ok :(
<mathrick> other than fast-replay
<mathrick> err, fast-import
<mathrick> but it'll be a different repository then
<lifeless> or rewrite (in principle)
<speakman> ok, it's okey as is :)
<speakman> about tagging; when working explicitly in the facelift branch you can easily see which commit was the first in the new feature branch. I guess?
<mathrick> lifeless: in general I find having a clear idea of where I started useful. And if the trunk moves in the meantime (because of a critical bugfix say), you won't have any easy way to say "where I started"
<lifeless> mathrick: well, bzr knows
<mathrick> speakman: depends, how do you define "first in the feature branch"? Revisions don't belong to any branch, branches contain them
<mathrick> lifeless: howso?
<lifeless> mathrick: revisions in your branch not in trunk
<mathrick> unless you backport / merge
<speakman> About trunk changing - is "merging" considered default about "rebase" in bzr?
<lifeless> mathrick: the topologically oldest of them, has a single parent, the starting point.
<speakman> about/above
<mathrick> lifeless: and how do you say that?
<lifeless> mathrick: bzr missing --mine-only etc, I'm not sure there is a query for that rev at the moment
<mathrick> lifeless: but that's potentially a moving target. Tags by definition aren't
<mathrick> and they're easy to spell as revspecs too
<lifeless> mathrick: sure, if you're happy great. I've just never ever needed it ;P
<speakman> We all learn something each day :)
<speakman> Each time I need to reach my smart server I have to type "bzr://servername.local/project/trunk" -- is there an easy way to make a alias, like "ss:project/trunk" (like launchpad "lp:") ?
<lifeless> speakman: instal bzr-bookmarks
<lifeless> vila: ping
<lifeless> vila: do you remember, does WeaveMerger write BASE files now ?
<lifeless> it does
<vila> lifeless: sorry, had lunch
<lifeless> vila: tsk, eating now. What next? Breathing?
<vila> or sleeping :)
<speakman> I currently did a merge from trunk into a feature branch. Now "bzr missing" tells me that the merge commit is missing in trunk. How will this show in history when the feature branch is finally merged into trunk?
<lifeless> speakman: have a look at the bzr trunk log
<speakman> lifeless: bzr trunk log..? the log of my trunk branch?
<bialix> no, lp:bzr
<millun> hi
<millun> i am a noob. working on a project (colocated branch) and would like to create a copy of this project so i could have 2 repos and be working on both
<speakman> lifeless: changeset 5153?
<millun> i guess i could 'cp -R stuff' and then delete .bzr dir?
<speakman> why not branch and work on both?
<speakman> what more specifically are you trying to do?
<MvG1> abadger1999: ping?
<millun> speakman: just be able to separate 2 projects and then work on both without mixing anything
<MvG> millun: Just because branches were made from a common ancestor doesn't mean you'll HAVE to mix anything in the future.
<MvG> millun: And doing a branch now will preserve full history for both new projects, which should be a good thing to have
<millun> ok
<abadger1999> MvG: pong
<MvG> abadger1999: you're maintaining the bzr package for Fedora, right?
<abadger1999> abadger1999 == toshio in the Fedora pkgdb btw
<abadger1999> MvG: I am comainaining it -- hno handles the day-to-day these days.
<abadger1999> MvG: What's up?
<MvG> abadger1999: In response to bug #560030 we're gonna drop the bash completion script, and suggest the bzr-bash-completion plugin as replacement.
<ubottu> Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/560030
<MvG> So we'd like distros to provide a package for it, be ready for the time when the scripts disappear from the bzr source releases.
<abadger1999> MvG: Okay.  No chance of getting that plugin into core?
<MvG> Not up to me, I'm only developing the plugin and offering the off fix for inclusion.
<MvG> I'd be happy to see it in core, but lifeless didn't exactly jump to that offer.
<MvG> And I can think of a million places where bzr would be required but bash completion not, so it might make sense to keep things distinct.
<abadger1999> Hmm... bzr-bash-completion doesn't need bash completion installed, though?  It just generates the script that would be used by bash completion?
<MvG> abadger1999: Correct. but it does ship a lazy.sh that can be installed as bash completion script and generates the full completion function upon first invocation.
<MvG> So that's file is what I'd suggest as a replacement, in cases where the plugin is installed.
<abadger1999> Ah.  Okay, we'd drop that into place without making a hard requirement on bash-completion so it wouldn't matter if it was in bzr core.
<MvG> abadger1999: I was a bit imprecise: the script assumes that the plugin is installed. It is intended for cases where the plugin is installed, but doesn't check if that actually is the case, but will fail noisily if it isn't.
<abadger1999> MvG: <nod>  I'm talking -- if it was in Core, bzr still wouldn't need to suck in a bash completion package.
<abadger1999> MvG: A few years ago poolie wasa interested in getting more plugins into core.
<MvG> Agreed. So suggestion would be for bzr to suggest but not require bzr-bash-completion, and for bzr-bash-completion to suggest but not require bash-completion, and for bzr-bash-completion to install lazy.sh under a file name that was provided by bzr so far.
<abadger1999> I ask this because there's only two of us packagers who are interested in bzr in Fedora... so additional packages kinda suck.
<abadger1999> Which is why we don't have bisect, pipelines, or a lot of other bzr plugins packaged :-(
<MvG> abadger1999: I understand, but my package shouldn't be too complicated: simple distutils from proper release tarball, and the lazy.sh file installed via custom install command copied from the bzr package spec.
<MvG> And if there is anything I can do to make life easier for you downstream, let me know.
<MvG> abadger1999: BTW, is hno occasionally here on irc as well, and if so, using what nick?
<abadger1999> MvG: <nod>  Yeah... but maintaining packages is the problem... The front end load is fairly simple, when free time > 0: create new package from template, submit for review, have bzr comaintainer review, commit to package SCM, build and release.
<abadger1999> MvG: The maintainance is the problem: When New upstream release || new Fedora release || bug reported: stop other work to work on issue (minimal for updating package, much more for fixing bugs); submit patches upstream, build new packages, push to all relevant Fedora branches.
<abadger1999> MvG: his nick is hno, so he's easy to spot
<abadger1999> MvG: He's almost always on #fedora-devel if you need him.
<MvG> abadger1999: bzr-bash-completion should in no scenario be mission-critical, so nothing should be urgent. For the "bug reported" case, I'd suggest reporting upstream first, waiting some amount of time for me to come up with a fix and release it (the benefit of independent package is that I can have short and independent release cycles), then simply bump the fedora package.
<abadger1999> MvG: Hehe -- true.  I like to be an active packager that helps out, rather than just a packager that demands fixes, though :-)
<MvG> I guess I'll include a comment in the bug report, stating that you are now aware of the situation, but not entirely happy with it, and see if that makes core devs reconsider the core inclusion.
<MvG> abadger1999: And I'd welcome you to be, but I'd rather have a packager demanding fixes than no packager at all due to lack of time. :-)
<abadger1999> yeah -- Just mention that getting more plugins into core will make bzr look better when people are comparing the features that bzr vs $OTHER_SCM has within a distro.
<abadger1999> MvG: :-)  Thanks!
<abadger1999> I'll try to get hno to package/maintain this as I use zsh rather than bash (or maybe I'll take a look at your plugin and try adding a zsh output as well).
<MvG> abadger1999: zsh does ship a completion script for bzr. It's prety outdated as well, but not as much as the one in the bzr source tree.
<MvG> I've had a look at it as well, and wondered whether augmenting my script might be feasible.
<abadger1999> <nod>
<abadger1999> The thing I miss most in the zsh script is no support for plugins -- a lot of commands from bzrtools don't have completions.
<MvG> For lists of options it should be easy. For registry option values it should be feasible. For help strings it might at times become difficult. For arbitrary argument type completions there isn't enough information in the bzr classes to provide completions the way the hardcoded zsh script currently does.
<MvG> In other words: all versions of bash completion currently complete option names and registry values, but leave everything else to standard file name completion. All versions of zsh completion try to be clever and complete much more, like revision numbers, versioned and unversioned files, and so on. The latter is diffiocult to do generically.
<MvG> And expensive in terms of performance as well.
<abadger1999> Okay.  That summary gives me a head start on what work would need doing, at least.
<MvG> So if I were using zsh, I'd drop most of the zsh cleverness, and instead have it do what the bash script does, except for perhaps a few more help messages. But I'd need a regular zsh user to work with me on that.
<abadger1999> <nod>
<abadger1999> MvG: Could you link to your plugin in the bug?  it'll make it easier for people to tell what they need to be packaging.
<MvG> Will do. For you it's here: https://launchpad.net/bzr-bash-completion and http://pypi.python.org/pypi/bzr-bash-completion
<abadger1999> Thanks!
<MvG> abadger1999: In case you really wanna tweak the bzr-bash-completion plugin towards zsh, have a look at http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=history;f=Completion/Unix/Command/_bzr or your local installed copy of it. The format doesn't look too complicated.
<MvG> abadger1999: I've just commented on bug #560030; maybe you and/or hno want to subscribe, so you stay in the loop.
<ubottu> Launchpad bug 560030 in bzr "Shell completion scripts outdated" [Medium,Confirmed] https://launchpad.net/bugs/560030
<abadger1999> MvG: Yeah -- hno hasn't responded to me yet -- waiting to see if he'll take the package.
<millun> can i set "/home/millun/work/bzr" as my default push directory for more projects?
<millun> oops. i obviously can't :)
<MvG> millun: It should be possible, though I'm not sure it would make a lot of sense, as you'd have diverging branches preventing pushes for all projects except one.
<vila> I need help from a losa
<vila> lifeless: A funny one for you: pqm is looping...
<vila> lifeless: I submitted with feed-pqm, got a failure (reported on lp, not by mail) but nothing to give me a clue about why
<vila> lifeless: so I submitted by mail
<vila> lifeless: no it appears that pqm is still failing but it keeps trying to process the same submission...
<Chex> vila: hi there, what do you need help with?
<vila> Chex: as explained above, it seems pqm is looping on the same submission and doesn't give me *any* hint about what is failing
<vila> Chex: AIUI lifeless and spm have been working on pqm since last week, so be aware that things may have changed there
<Chex> vila: ok, let me check the logs for you
<vila> Chex: the urgency here is to kill this submission so that the other ones can be processed
<Chex> vila: ah ok, thats easy, hang on
<Chex> vila: ok, I have cleared out your submission, and cleared the pqm-bzr procs, should restart now on a new submission
<vila> Chex: any hint of *what* was failing ?
<vila> Chex: http://pqm.bazaar-vcs.org/ says 503
<Chex> vila: sorry, try now
<vila> Chex: ok, it now says 0 scripts
<vila> Chex: any hint about why my submission failed ?
<vila> Chex: I briefly saw a summary saying 1 error but no details
<Chex> vila: right,  that is what I am seeing in the pqm.log file, too.. let me pastebin for you
<Chex> vila: https://pastebin.canonical.com/30964/
<vila> Chex: and nothing after that ? There is not even an error mentioned there :-/
<Chex> I know.. nothing
<Chex> vila: I think we may want to try to turn on more logging, if possible to see whats going on
<Chex> vila: but I am not sure how to go about doing that
<vila> Chex: Isn't there a log file for each submission ?
<vila> Chex: at least the other submissions are being processed right now...
<Chex> vila: yes there are indiv. log files, but they dont seem to get created until the job is finished..
<Chex> vila: and for some reason, your patches aren't.
<vila> Chex: AIUI, my submission has been run 3 times, you killed the last one
<vila> Chex: ooooh, if it's only mine, then .. fine, I'll  talk with pqm :)
<Chex> vila: talk with.. pqm? you guys have a special friendship?
<vila> Chex: joke aside, the first submission was from the lp queue while the second (and the others) came from a direct mail
<Chex> vila: aha, ok, I see.
<lfaraone> Can I get a remote branch's history without branching it?
<vila> come to think of it, I wonder if the mail one didn't trigger *3* (and not 2) runs
<vila> lfaraone: branching *is* getting the remote history
<lfaraone> vila: sorry, I just want the log.
<vila> Chex: doesn't the log mention several submissions for this patch ?
<vila> lfaraone: bzr log should accept remote urls
<vila> lfaraone: 'bzr log lp:bzr' works
<lfaraone> vila: okay. that will work without using SSH, right?
<vila> lfaraone: it depends on what protocol you're using to access the branch... http ?
<MvG1> lp uses ssh if it knows a login name, http otherwise.
<lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
<lfaraone> looks like it works with http too, I just su'd to nobody, and it worked.
<lfaraone> If I have a lp: URI, how should I pass that to bzrlibb.branch.Branch in the way it expects it? ("a = bzrlib.branch.Branch('lp:ubuntu/lucid/gnome-do')" gives me an error()
<vila> lfaraone: use Branch.open_containing()
<vila> lfaraone: as a general rule: looking into bzrlib.builtins.py will give you many hints
<donri> How can I add to the last commit?
<maxb> donri: By 'bzr uncommit'ing and then committing your modified commit
<donri> uncommit wont touch my non-committed changes since the last commit?
<maxb> correct
<donri> Thanks.
<Boingo> Hello all.  I have done a bit of searching, but not a lot of finding.  I am having some very slow commits over FTP.  Even a single character change in a single file, with a fresh commit to a remote repo over FTP can take 30+ minutes.  Is there something I am doing wrong?
<jam> Boingo: using FTP
<jam> especially if your server doesn't support APPE (append to an existing file)
<Boingo> My only real option is FTP in this case.
<Boingo> I think.
<Boingo> godaddy hosting.
<Boingo> Why does editing even a simple small file take that long though?
<dash> Boingo: one reason is that bzr uses compressed files to store version history, so updating via ftp can involve replacing an entire file
<dash> Boingo: which can be a good bit bigger than the one you edited
<Boingo> Oh.
<Boingo> That makes sense.
<Boingo> Is there anything I can do then?
<dash> the easy thing to do is use some other host for your bzr repo, like launchpad or sourceforge or something :)
<Boingo> I need something that is private.
<Boingo> Can lp do that?
<Boingo> Would sftp or ssh speed it up?
<jpds> Boingo: Yes, Launchpad offers commerical subscriptions.
<jpds> Boingo: https://launchpad.net/+tour/join-launchpad#commercial - not sure if it's what you want though.
<Boingo> I am reasonably happy with what we have, minus the abysmal speed for commits.
<Boingo> Will sftp or ssh speed it up?
<dash> sftp might, ssh definitely will, if bzr is installed on the remote server
<Boingo> It would not be.
<Boingo> Well, at least not in the current context.
<dash> well if you can ssh there you can install it
<lifeless> vila: to stop it looping, you just unqueue it from launchpad
<lifeless> vila: go to the merge proposal, click on the edit icon beside 'queued' and change to 'approved'
#bzr 2010-04-21
<igc> morning
<spiv> Hmm, I could add a post-commit hook to the better-news-merge branch that warns if you are committing a NEWS file that isn't in the canonical format (non-alphabetical bullets, etc)
<spiv> Er, or pre-commit even.
<lifeless> with code ?
<lifeless> spiv: are you asking 'what hook to use' ?
<lifeless> oh ignore me, I misread 'I could' as 'how do I'
<spiv> Right.
<spiv> I'm just musing out loud.
<lifeless> <- thwack
<lifeless> spiv: you could do a start commit one instead, that just fixes it.
<spiv> I just realised I have most of the code already, and it would help devs catch "oops I forgot to put the bullet in the right spot"
<spiv> That'd be neat too.
<lifeless> spiv: or even a filter :>
<spiv> Perhaps we could have a merge-hook that is configured on the PQM instance to merge a detached NEWS entry into its final home (i.e. into the appropriate section of whatever the current release is).
<spiv> To avoid the "I wrote the NEWS entry before the 2.1.1 release, but my change landed after 2.1.1 was released" problem
<lifeless> spiv: as long as it doesn't break 2.1->2.2 and similar merges
<spiv> *nod*
<lifeless> I think its worth heading towards
<spiv> There's also the Twisted-style solution: build up a directory of newsfiles/$bugnumber.$kind, e.g. newsfiles/1234.feature or newsfiles/2345.bug
<poolie> that could be better
<poolie> spiv does it run in pqm yet?
<poolie> that could be a good next step
<poolie> though perhaps pqm is being tortured enough right at the moment
<lifeless> I find the directory approach a bit ugly tbh
<lifeless> I don't see that its really any easier or better
<spiv> And only build them into a single file at either release time or maybe build time.
<poolie> it is a kind of a workaround for an insufficiently good tool
<poolie> there's also the issue of how to represent the DAG of releases
<poolie> that 2.2b2 includes 2.0.6 etc
<spiv> Yes.
<lifeless> I think that we're heading into diminishing returns for now
<spiv> As a reader of the NEWS file, I'd like to see the 2.0.6 entries repeated under the appropriate 2.2 release.
<spiv> But as a developer I find it a PITA :)
<poolie> spiv, so for me the most useful thing at the moment would be a mechanism/document for how to do your own merge code
<poolie> eg how to call an arbitrary shell command to merge them
<poolie> oh, or the thing of making some files always conflict
<poolie> but for today i'm going to look at the loggerhead mp queue
<poolie> igc: the top refererer to loggerhead was this blog post:
<poolie> http://www.outflux.net/blog/archives/2010/02/18/data-mining-for-nx-bit/2/18Q
<poolie> and it is pretty interesting
<poolie>  http://www.outflux.net/blog/archives/2010/02/18/data-mining-for-nx-bit/
<lifeless> ok, pqm is currently executing with bzrlib 1.17
<lifeless> so we'll need a potentially risky upgrade to do news-merge; will look at it with spm probably next week
<poolie> it's probably not urgent then
<poolie> perhaps we should defer until after the lucid release and uds
<lifeless> I think we should do it as time permits
<lifeless> if folk are busy, defer, otherwise do.
<lifeless> I guess I mean that if make it clear to the losas that its not high priority they can guide us as to their stress levels and fit it in accordingly
<poolie> ok; i think we should let them know to expect some fallout
<poolie> well, they probably would already
<lifeless> right - potentially risky as I say :)
<lifeless> after thats in place we can look at turning on news merge for it
<lifeless> we should also look at turning on news merge on lp
<lifeless> for mp reviews
<lifeless> poolie: the code in
<lifeless> https://code.launchpad.net/~salgado/launchpad/meliae-librarian/+merge/23771 might be interesting
<poolie> ooh
<jrmorrisnc> hi I need to present a comparison of bazaar versus CVS to my team at work. Any good resources?
<spiv> jrmorrisnc: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html and http://wiki.bazaar.canonical.com/BzrForCVSUsers
<spiv> jrmorrisnc: there are probably others too, but not at my fingertips :)
<jrmorrisnc> ty
<mkanat> spm: Hey. How long does the loggerhead check wait until it assumes that codebrowse has failed to respond?
<spm> mkanat: hey max; 3 tries of ~ 10 secs each
<mkanat> spm: Ahh.
<mkanat> spm: You might want to up that to 15 seconds.
<spm> mkanat: I *believe* that's not technically possible. nature of how the beast is assembled across all the servers....
<mkanat> spm: Ahh.
<spm> I think we can increase to 5 tries tho.
<spm> which'll have the same effect.
<mkanat> spm: Well, no, that might make it worse.
<spm> oh?
<spm> too much repeated polling?
<mkanat> spm: Yeah, the problem is that sometimes loggerhead gets slow, and you're asking it to do something that might be slow.
<mkanat> spm: So if you ask multiple times when it's not completed, at the least it's making the problem worse.
<spm> excellent
<mkanat> spm: Is it the sort of checker that looks for a string in the page, or just tests for a 200 response?
<spm> I think both. lemme verify...
<mkanat> spm: Okay.
<spm> mkanat: /usr/lib/nagios/plugins/check_http -H bazaar.launchpad.net -u /~vcs-imports/busybox/main/changes -e " 200 OK"
<mkanat> spm: Okay, so it's just a 200 check.
<mkanat> spm: There's not also a string checker?
<spm> istr the -e bit is to ensure we catch 3xx's & 4xx's as fatal
<spm> not on that one, no. we do on some other services.
<mkanat> spm: Okay.
 * spiv -> food
<spm> spiv: get a 2400 baud odem while you're at too eh?
<mkanat> spm: Ah ha. So sometimes, the checker is getting a 500.
<spm> mkanat: that... that sounds about right - relying on my memory
<mkanat> spm: Ah, okay.
<mkanat> spm: So this is more a crash than a hang, in a way. But effectively loggerhead is non-responsive.
<spm> sounds a fair description :-)
<mkanat> spm: Oh, okay, I found an actual hang in the log.
<spm> mkanat: ah! so we are getting real hangs? I was somewhat in a context free zone responding to that bug report. and it showed. ;-)
<mkanat> spm: That's OK. I think we might actually be getting multiple different hangs and other bugs.
<mkanat> spm: I suspect there are at least two hang bugs, maybe three. And then there's a bug that causes loggerhead to throw a bunch of KeyErrors.
<spm> luveryly
<mkanat> spm: The problem is that I can't reproduce *any* of the hangs locally.
<mkanat> spm: So I'm totally dependent upon reading logs in detail and looking at the stack traces that I get from y'all.
<spm> mkanat: :-) and more importantly: is "y'all" the correct spelling? I've been doing "ya'll".... but not being a native of the USA....
<dash> spm: it's a contraction of "you all"
<mkanat> spm: Yeah, it'd be y'all, because "you" is contracted.
<dash> and the only sensible plural of "you" that I know of :)
<mkanat> dash: Agreed. I'm not living in the South anymore, but I still use it as the second person plural from time to time.
<spm> ha. I thought it was one of those phrases like 'crikey' that is only used in the piss-taking sense.
<fullermd> But... y'all is singular.
<fullermd> "all y'all" is the plural.
<dash> fullermd: die in a fire, etc
<fullermd> 8-}
<dash> spm: no, i say it pretty consistently
<spm> dash: I may never look at you the same way again. :-P
<spm> Naturally, this is coming from the perspective of "Teasing Americans being an Australian National Sport" perspective... so.....
 * spm also notes the reaction to fullermd's "all y'all" sugegstion and takes additional notes for later abuse
 * fullermd is a helper!
<lifeless> -> food
<mkanat> fullermd: lol
<lifeless> you're missing the 'now
<lifeless> y'all die in a fire, now
<mkanat> lol
<mkanat> Where does tuned_gzip come from? I see people import it from bzrlib but I don't see a definition in bzrlib/__init__.py.
<mkanat> Oh, nevermind.
<mkanat> Haha. Found it. Duh.
<lifeless>  mkanat ;)
<mkanat> lifeless: Is there any known thread-unsafety inside of the btree_index pyx stuff?
<lifeless> the usual about sharing objects
<mkanat> lifeless: Like sharing a repository object between two threads and then attempting to call the btree_index methods on it? But that should normally be prevented by...oh, no, it wouldn't be by two read locks.
<lifeless> mkanat: at a high level, yes.
 * mkanat nods.
<lifeless> the lru cache bug we had was a global with the same issue
<mkanat> lifeless: Specifically an issue with the btree_index, or just a thread-safety issue with the pyx code?
<lifeless> mkanat: neither, just a data structure being updated without a thread mutex around it
<mkanat> lifeless: Ah, okay.
<lifeless> mkanat: and because the chk_map module has a global cache object
<mkanat> lifeless: Ah, okay.
<lifeless> mkanat: calls from different repos were interacting with the global cache, and *boom*
<lifeless> loggerhead told us about it :P
<vila> hi all !
<poolie> hi vila
<vila> lifeless: what's the status on pqm ? I still see some of the merges that were queued yesterday :-/
<vila> hi poolie :)
<vila> lifeless: having *no* feedback on failures is really frustrating :-(
<fullermd> You mean "hi y'all"   O:->
<poolie> yeah, john complained about this too
<lifeless> vila: its extremely frustrating
<igc> hi vila
<lifeless> vila: I'm polling losas hourly to find new exceptions and have two bugs in launchpadlib/launchpad that are affecting us:
<igc> hi fullermd, mkanat
<vila> fullermd: I tried to decipher the discussion about that but coudnn't make sense of it (apart from spm teasing americans people that is :)
<poolie> is it true that if you submit by mail you get a reply in the regular way?
<lifeless> vila: a 110 timeout error with no obvious reason - you might be able to help with that
<lifeless> vila: as its ssl related
<vila> poolie: not my case yesterday
<spm> vila: glad you understood the important part. ;-)
<lifeless> vila: and a 502 gateway error which is apparently backend flakiness + launchpadlib not retrying
<poolie> lifeless: can we reevert whatever broke that?
<lifeless> we can disable the lp api usage entirely by removing the config option./
<vila> lifeless: logs ? tracebacks ? Anything I can chew ?
<lifeless> https://bugs.edge.launchpad.net/launchpadlib/+bug/380504 is the 502 one
<ubottu> Launchpad bug 380504 in launchpadlib "Handle HTTP Error 502: Bad Gateway automatically" [High,Triaged]
<poolie> there's no easy way to just take it out of the codepath of non-api-based merges?
<lifeless> poolie: no
<poolie> :/
<lifeless> poolie: they dovetail, same code
<vila> lifeless: so, bad gateway is the one I see when lp is down or performing really badly
<lifeless> vila: yes, and we're hitting it unpleasantly often
<lifeless> oh thats a fun bug
<lifeless> search for 110 in a bug tracker search - takes you to the bug directly.
<lifeless> <fail>
<lifeless> https://bugs.edge.launchpad.net/launchpadlib/+bug/567180
<ubottu> Launchpad bug 567180 in launchpadlib "timeout submitting request - can't tell if its lplib or lp" [Undecided,New]
<lifeless> thats the ssl related one
<lifeless> poolie: I'm happy to rollback if you want; we have solved many of the issues but I know at least one remaining - there is diagnostic code in production that should enable it to be fixed when it next triggers
<poolie> john seemed to be about +0.8 on rolling back
<poolie> i'm about +0.1 but only because i haven't submitted yet this week :)
<poolie> how about you, igc, vila and spiv?
<lifeless> poolie: I don't think we should rollback today
<lifeless> tomorrow afternoon if its still gltiching we should, because I'm going to be off friday
<poolie> ok, wfm
<poolie> before you fly and before the anz holiday
<vila> Unless there are ways to reproduce the actual bugs in a separate instance, I'd prefer to endure the pain *now* than postponing it :)
<vila> *BUT* gimme me feedback on my failures so I can see if the problem is on my side or not
<vila> lifeless: the parthm chown one has just failed (I've seen 6 failures mentioned by the progress report on http://pqm.bazaar-vcs.org/), did you get some feedback there ? (for example)
<spiv> vila, lifeless: maybe PQM is still not allowed to send the large failure emails?
<lifeless> vila: yes, its blowing up truncating the 44MB error output
<lifeless> spiv: no, see the exception spm pasted
<vila> lifeless: you see that on the host running pqm or from your laptop ?
<spiv> lifeless: link?  There have been so many conversations about pqm lately.
<lifeless> spiv: https://pastebin.canonical.com/31025/
<spiv> ta
<lifeless> spiv: are you in #launchpad-code ? :P
<lifeless> vila: ^
<spiv> lifeless: I am, but don't follow it closely
<vila> ValueError: invalid literal for int() with base 16: '' rings some bell....
<lifeless> vila: however there are no text streams in play here
<lifeless> so I think its definitely a pqm bug
<lifeless> but perhaps subunit
<spiv> lifeless: I don't know enough to make much sense of that exception, although wouldn't gzipping be a better option than truncating if this is just to get the email to a reasonable size?
<lifeless> spiv: we're attaching it to the merge proposal.
<lifeless> but they don't permit 'attachments' at the moment (bug iz open), so it will be a comment.
<spiv> Oh, bleagh :(
<vila> 44MB in a comment ? pfew
<lifeless> spiv: thus I want it to be as useful as possible. Besides which, if pqm can't filter it, neither can a user.
<lifeless> so I need to fix the bug. fixing the subunit fragility is one route
<spiv> lifeless: so you're filtering out successes?
<lifeless> eys
<spiv> and xfails? :)
<poolie> and time markers?
<lifeless> time markers yes
<lifeless> xfails I don't know
<vila> Do I see a pattern about filtering just the failures and the errors here ? :-P
<gour> morning
<lifeless> I'm using a default TestResultFilter at the moment, I can change that easily.
 * vila runs
<gour> using bzr with git repos fails with stuff like http://dpaste.com/186054/
<vila> gour: I'm pretty sure it's a known bug about github returning some invalid URLs
<gour> vila: thank you...any workaround?
<vila> gour: are you using the latest bzr-git version ?
<gour> vila: no. will try to pull
<vila> lifeless: both bug #567180 and bug #380504 are as obscure as pqm failures to me :-/ sorry
<ubottu> Launchpad bug 567180 in launchpadlib "timeout submitting request - can't tell if its lplib or lp" [Undecided,New] https://launchpad.net/bugs/567180
<ubottu> Launchpad bug 380504 in launchpadlib "Handle HTTP Error 502: Bad Gateway automatically" [High,Triaged] https://launchpad.net/bugs/380504
<lifeless> vila: no idea what would cause the first one ? the second is well analyzed
<vila> they look like timeouts on the server side to me
<vila> errr, server taking too long I mean
<vila> timeouts on the client
<vila> I never encountered the ssl one though
<vila> lifeless: any reason to suspect they don't share the same cause ?
 * gour is encountering some problems updating bzr-git...need to do it manually
<gour> vila: i've updated bzr-git, but now i get: bzr: ERROR: Unsupported protocol for url...also with non-github urls
<lifeless> vila: non reason to suspect either for or against
<vila> gour: file a bug, with any luck lp will show you the relevant one, I don't remember the details, but I'm pretty sure the subject was discussed there
<gour> vila: ok
<vila> lifeless: both fail to get an answer, the only difference I see is one is using http and the other https. The http one went a bit farther and get a 502, but that may just be a reflect of the different servers involved, it's hard to tell from here :-/
<lifeless> vila: all api calls are https
<lifeless> at the moment anyhow
<vila> hmm, and involve the same servers ?
<lifeless> vila: what I find odd is that the ssl one is timing out on *write*
<lifeless> vila: yes, launchpad apis
<vila> lifeless: wild guess: the timeouts on the client and the server are close and one fire before the other ...
<lifeless> vila: interesting
<lifeless> I think I'm going to have to take wild guesses
<vila> in both cases, I'll check server logs...
<lifeless> spm: ^
<gour> hmm...something is wrong here...i pulled the dulwich from the the trunk and i get: "bzr: ERROR: Unsupported protocol for url "git://github.com/maxlapshin/mysql2postgres.git": Unable to import library "dulwich": bzr-git: Dulwich is too old; at least 0.5.1 is required"
<poolie> maybe it's finding a different one on your pythonpath
<vila> lifeless: but... but... my submission from yesterday (avoid zombies) landed ??? Now I'm ever more confused :-(
<vila> lifeless: can I still use pqm-submit directly ?
<lifeless> yes, but I would not expect any difference if there is an MP for what you are submitting
<vila> lifeless: it's for a trivial patch without MP so far
<vila> lifeless: test import cleanups
<lifeless> vila: you can just do it
<vila> lifeless: cool
<lifeless> it will jump the queue, too
<vila> lifeless: I'll try to wait for it to be empty
<lifeless> why?
<vila> lifeless: just to avoid random problems
<lifeless> ok
<vila> lifeless: and about my landed mp ? I've seen the progress report mentioning 1 error, where did it go ?
<lifeless> what error?
<vila> lifeless: stop teasing me :-) That's the whole point: I have no idea what the error was !
<vila> at one point I saw: Running [ xx% nnnnn test(s), 1 error ]  (or something similar)
<lifeless> presumably transient then
<vila> scary
<vila> lifeless: I also feel that pqm is slower these days, is the host under more load ?
<lifeless> I think I have a fix for the reporting
<lifeless> vila: launchpadlib is slow
<lifeless> vila: I can't answer about load. spm can ?
<vila> lifeless: that shouldn't reflect on the time to run the test suite which is where my feeling of slowness is
<lifeless> spm: ^
<spm> i wonder if we log ballenys load anywhere you guys can see...
<vila> spm: no worries, just give me root access, I'll find my way from there
<spm> vila: ha! misconception 1. *I* don't have root access....
<vila> spm: see ? That's why it's so hard for you :)
<spm> heh
<vila> spm: Anyway, I didn't imply that you have root access, I know you're far too responsible to use that, but just give it to me, ok ?
<lifeless> vila: FYI, pqm error blow up was because stdout and stderr were being combined
<lifeless> vila: *and*
<lifeless> vila: we still have crap on stderr
<spm> vila: something like that.....
<lifeless> that will break most any serialisation you care to think about
<lifeless> vila: if you wanted to review my adhoc fix, its pqm's most recent commit
<vila> lifeless: argh
<lifeless> ok, EOD time
<vila> lifeless: will this commit be deployed ?
<gour> cool...pulling dulwich from the trunk resolved bzr-git issue(s)
<lifeless> vila: Tomorrow morning
<vila> lifeless: ok
<lifeless> vila: so if its crap, I can fix
<vila> lifeless: nothing caught my eyes, but I have a poor context here :-/
<vila> lifeless: I'd use from cStringIO import StringIO , but... detail
<vila> lifeless: grrr, lp:~jameinel/bzr/2.0.6-peak-commit-mem lp:bzr/2.0 is looping like my submission from yesterday :-(
<vila> spm: still around ? ^
<spm> vila: not really - in post cleanup from a major librarian crash
<vila> spm: ok
<vila> Any other LOSA around ?
<vila> lifeless: wow, I set https://code.edge.launchpad.net/~jameinel/bzr/2.0.6-peak-commit-mem/+merge/23718 status to 'Approved' (from 'Queued') and it went out of pqm instantly (pqm had just started processing it again...) ?
<mthaddon> vila: o/
<vila> mthaddon: I just broke the loop apparently, stay tuned but nothing needed immediately :)
<mthaddon> k
<lifeless> vila: it hasn't gone from pqm really
<lifeless> vila: the webui and the cron job only have a tenuous connection to each other
<lifeless> vila: the next time it refreshes the list though, it won't find it
<lifeless> vila: you might like to get mthaddon to look at the bzr pqm log and tell you the patch it most recently started playing from that; and if its jam's branch shut all of the bzr --cron processes down (set a stop.patch and wait)
<vila> lifeless: but I saw: Running [ 0% 1 test(s) ] for jam's branch, went to the mp page, switched the status, came back to pqm page, it was gone, does that make sense ?
<vila> lifeless: or rather,
<lifeless> vila: yes, as I said, the web ui and the cron daemon are only tenuously linked
<vila> lifeless: is the pqm web UI lagging so much ?
<lifeless> no
<lifeless> its reading from lp
<lifeless> change the lp status, change what it sees
<lifeless> doesn't change the behaviour of the *already running* pqm cron instance
<vila> lifeless: that's my point, the pqm run appeared to stop while the web UI was reporting Running [ 0% 1 test(s) ]
<lifeless> however, the cron instance loops around all the items queued
<lifeless> vila: it didn't.
<vila> lifeless: I'm talking about seconds between my actions, not even minutes
<lifeless> one of the bugs stops failing proposals being set back to approved
<lifeless> vila: yes, I understand.
<lifeless> nevertheless.
<lifeless> Not Possible.
<lifeless> the 'current playing' entry in the queue is total lies
<vila> lifeless: pfew, so I'm not dreaming
<lifeless> read the code - in particular pqm/queue/lp.py 'next_script' and compare with pqm/ui/twisted.py
<lifeless> the status region is accurate
<lifeless> the claimed patch will be more accurate once the bugs preventing lp updates are fixed
<lifeless> but even then, if you dequeue the active thing, it will take a full pqm run to sync up again
<lifeless> not something worth fixing
<vila> lifeless: ok, that matches my expectations... now where should I look to find reliable info about what is running...
<lifeless> ask-a-losa *if* it matters
<lifeless> the thing to remember is that pqm won't loop on one patch
<lifeless> it will loop on all patches
<vila> lifeless: right
<lifeless> the web page will look like its looping on the first; its not.
<lifeless> every time it hits the end, it will refresh from lp
<vila> https://code.edge.launchpad.net/bzr/+merges?field.status=QUEUED&field.status-empty-marker=1 is the only reliable source then
<lifeless> and go around again, if there are unmerged things.
<lifeless> vila: uhm, thats == the pqm web ui
<lifeless> so its equally inaccurate
<vila> lifeless: it's the source that pqm read no ?
<lifeless> vila: when it refreshes the queue, yes. Which it only does after trying everything it knew about.
<lifeless> the web ui refreshes every 30 seconds
<lifeless> so the web ui == the launchpad page, in terms of being totally wrong about what merge the cron job is actually processnig
<vila> oh that, yes, I realize
<vila> but in terms of accessible info, that's all I have
<lifeless> the pqm web  ui tells you a little more
<lifeless> test_permissions.TestPermissions.test_new_files                  OK      545ms
<lifeless> ...permissions.TestPermissions.test_new_files_group_sticky_bit   OK      185ms
<lifeless> ...
<lifeless> etc
<vila> argh:
<lifeless> anyhow, I think you dequeued the wrong thing :P
<vila> bzrlib.tests.blackbox.test_branch.TestBranchStacked.test_branch_stacked_from_smart_server is leaking threads among 2449 leaking tests.
<vila> make: *** [check-nodocs] Error 1
<lifeless> I'm pretty sure the Oo flag thing is the broken thing
<vila> for support_OO flag
<lifeless> vila: you ran locally ?
<vila> lifeless: no
<lifeless> babune?
<vila> lifeless: just copied from pqm.b.o
<lifeless> vila: see the comments I put in parthm's merge; that I said were odd ....
<vila> lifeless: babune needs love
<vila> lifeless: where did you get these failures  ? ... pfff, nm,
<vila> lifeless: wait, I dequeued the wrong thing ? How comes ? I dequeued the first mp in the list...
<vila> lifeless: the order reported is a lie too ?
 * vila stops refreshing pqm web page, 30 seconds man !
<mwhudson> jelmer: hi
<jelmer> mwhudson: hi
<jelmer> mwhudson: otp
<mwhudson> jelmer: we cherry picked the bzr-git import and it failed on kernel import with a keyerror
<mwhudson> jelmer: should we just delete the import and start again?
<spm> mwhudson: \o/
<jelmer> mwhudson: re
<jelmer> mwhudson: what's the keyerror?
<jelmer> mwhudson: still there?
<mwhudson> jelmer: https://code.edge.launchpad.net/~kiko/linux/2.6.31
<jelmer> mwhudson: is the fetch interval 1k revisions or 5k ?
<mwhudson> jelmer: 10k
<jelmer> mwhudson: but yeah, restarting it would probably be a good idea
<parthm> lifeless: i responded to you on no-chown-if-bzrlog-exists about 30min ago but somehow my response hasn't shown up on the merge proposal
 * mwhudson starts https://code.staging.launchpad.net/~vcs-imports/linux/trunk again
<parthm> lifeless: i ran all the failed tests and didn't see any issues. its weird.
<lifeless> parthm: ok, its not your branches issue; however it is failing somehow on pqm; have you run all the tests?
<mwhudson> except, not on stagin
<parthm> lifeless: i usually run bb and a subset of bt as results get lost in "error: can't start new thread". those were passing. i am running the full suite now. nothing suspicious yet.
<lifeless> parthm: if you do
<lifeless> bzr selftest --list-tests
<lifeless> partition that list into (say) 10
<lifeless> and use --load-list to load each partition in series, you may have more luck
<lifeless> parthm: what OS are you on ?
<parthm> lifeless: yes. that might work. because when i ran failed (memory/new thread error) tests individually they tend to pass.
<parthm> lifeless: i am on ubuntu 9.10. 1GB memory.
<lifeless> interesting, I wouldn't have expected isues there
<lifeless> parthm: you could also try
<lifeless> selftest --parallel=fork
<lifeless> but you might not have enough cpu's to get a large enough partition to avoid the thread issue
<parthm> lifeless: i am already using --parallel=fork. i have 2 cpus ... maybe it time to upgrade :)
<vila> parthm, lifeless : indeed 2 is often not enough to work around the thread/socket leaks
<parthm> vila: i have taken the results of --list-only as suggested by lifeless. that seems to be working out ok but i think it will take some time to run :)
<vila> I should find that script I wrote long ago selftest-run-by...
<parthm> vila: sounds useful. for now i just used my vimfu + regex to make a simple sh with one line for one test class. maybe your script can go in bzr/contrib?
<vila> parthm: selfest-by-n: http://paste.ubuntu.com/419750/
<lifeless> vila: so what is this thread leaking thing
<vila> lifeless: basically python SocketServer is not safe to run in the same process as the client
<lifeless> why not
<vila> lifeless: ha !
<vila> lifeless: something related to the way python polls for socket
<vila> sockets
<spiv> Last time I tried digging into it tests using the smart server seemed to be at least part of the issue, at least judging from the concurrent access to log file warnings.
<spiv> But I might be wrong.
<vila> spiv: *any* server test using SocketServer
<lifeless> vila: this is interfering with various people; others don't see it.
<lifeless> specifically I've never seen it, and PQM seems immune.
<spiv> vila: the smart server code doesn't use SocketServer
<spiv> lifeless: FWIW, I see it :(
<lifeless> so I am curious whether the analysis is actually complete
 * spiv -> afk
<vila> lifeless: well, feel free to dig yourself, but I've digged it enough to be sure
<lifeless> vila: I don't see it
<lifeless> vila: hard to dig when you don't suffer it at all.
<vila> lifeless: sure
<lifeless> vila: do you think you could create a synthetic cause-the-problem example ?
<vila> no
<lifeless> like a tiny test case that starts a server, does a get, stops it, and we populate 10000 of the same test case into one suite
<vila> but forcing the test servers to shutdown were making it more obvious last time I worked on the subject
<vila> OSX, FreeBSD, gentoo reproduce it with reasonable success
<vila> so to speak
<vila> years ago we were retrying operations on socket not available in the http server, same root cause
<vila> lifeless: see bugs #392117 and bug #405745
<ubottu> Launchpad bug 392117 in ubuntu "The application Run Command Interface (krunner) crashed and caused the signal 6 (SIGABRT)." [Undecided,New] https://launchpad.net/bugs/392117
<ubottu> Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745
<vila> bah bug #392127
<ubottu> Launchpad bug 392127 in bzr "selftest fails with "can't start new thread"" [High,In progress] https://launchpad.net/bugs/392127
<vila> lifeless: also lp:~vila/bzr/405745-http-hangs    and  lp:~vila/bzr/392127-thread-leak for some wip
<vila> lifeless: common symtoms include: test server hangs, uncaught exceptions in server threads
<vila> lifeless: next try will be to start with wrapping threads to propagate/report/catch exceptions
<jelmer> mwhudson: I think disabling the fetching in batches for git would actually be possible now
<jelmer> mwhudson: and improve performance significantly
<mwhudson> jelmer: memory usage doesn't grow?
<jelmer> mwhudson: nope
<mwhudson> jelmer: anyway, file a bug maybe?
<jelmer> mwhudson: sure
<mwhudson> i'm going back to the hotel now, might be biab if the internet is working there tonight
<jelmer> mwhudson: sorry about this, I realise you've put quite some work into the incremental fetching
<jelmer> mwhudson: I just didn't expect bzr-git fetch to get so much better this quickly
<lifeless> vila: what I'd most like is something that is dedicated to provoking it
<lifeless> vila: if it is a python upstream issue that will let us file a bug
<mwhudson> jelmer: :-)
<lifeless> vila: if its not, then its something that I can hopefully trigger the issue with and help fix it
<vila> lifeless: I've never been able to track it down (or reduce it) to test simple enough to point a finger at python
<vila> lifeless: I suspected it for a long time, but I'm now convinced that the problem is more in a bad use of SocketServer (except for spiv remark above for which I don't have a good explanation, but I haven't dug that yet)
<parthm> vila: i can't seem to get the script command right. "./selftest-by-n.py --in-tmp ~/tmp --number 20 --starting-with tests.txt" ?
<parthm> vila: tests.txt is the list of tests e.g. bzrlib.tests.blackbox.TestXXX.test_foo etc.
<vila> lifeless: basically, there is no guarantee that the socket state is coherent (inside the same process) between a server and a client (I don't remember the exact details from the top of my head)
<vila> parthm: hmm, let me see
<vila> parthm: my .bash_history says: selftest-by-n.py --load-list --number 1000 all.tests
<vila> parthm: where all.tests has been produced by a previous 'bzr selftest --list >all.tests'
<vila> parthm: BZR_PLUGIN_PATH=-site may be needed too
<parthm> vila: weird. it prints out ": No such file or directory"
<vila> parthm: and 'selftest-by-n.py -n 1000 all.tests' ?
<parthm> vila: that produces "ERROR: Unkown test runner". i think its looking for --starting-with option.
<vila> parthm: selftest-by-n.py --load-list --number 1000 all.tests seems to work here
<parthm> vila: weird. I get ": No such file or directory". i will try some more. I also did a sys.path.append with my bzr branch near FIXME in the script. same error with/without it.
<vila> no such file for what ?
<lifeless> vila: but there are separate fds for each end of the socket
<lifeless> vila: and the OS is what keeps things coherent
<vila> the sys.path.append shouldn't be needed, we call './bzr' in a subprocess anyway
<lifeless> vila: we really do a 'make it happen' script.
<vila> lifeless: geee, of course, I've fought for that since the beginning !
<lifeless> vila: since you can make it happen, try:
<vila> ENOTYET :-(
<lifeless> def load_test(tests, _, _):
<a212901390231901> sorry parthm, seems my screwup got blamed on your branch
<lifeless>     return TestSuite([tests[0]]*1000)
<lifeless> class breaks(TestCaseWithTransport):
<lifeless>     def test_hurts(self):
<lifeless>         self.transport_server = http
<parthm> vila: got it. all.tests needed a little preprocessing. basically removed (.*) from end of --list-only names and ran through uniq
<parthm> vila: works nicely. thanks.
<lifeless>     get_transport(self.get_url('')).has('something')
<lifeless> -done-
<parthm> a212901390231901: np :)
<vila> lifeless: I really can't work on that *now*, but as far as I recall, the lp:~vila/bzr/405745-http-hang was failing with python2.4, you may be able to reproduce from there
<vila> lifeless: on Ubuntu that is
<cody-somerville> wtf. bzr diff is giving a completely incorrect patch
<fullermd> It's just seeing if you're paying attention.
<cody-somerville> lol
<cody-somerville> lifeless, any clue why bzr would be doing that?
<vila> cody-somerville: your hints are a bit sparse... a pastebin maybe ?
<fullermd> Shucks, you broke my concentration; I was getting my clairvoyance all fired up.
<vila> sorry
<cody-somerville> vila, I can't seem to browse the branch on launchpad so I can't prove to you the patch is incorrect.
<vila> cody-somerville: I don't ask for proof (yet :) just evidence to understand *what* is incorrect, different file, path mangled, wrong diff content, et
<vila> etc
<cody-somerville> wrong diff content
<vila> cody-somerville: plain 'bzr diff' or with some option ?
<spiv> cody-somerville: wrong in what way?
<cody-somerville> just bzr diff
<vila> cody-somerville: standalone branch, checkout ?
<vila> cody-somerville: is 'bzr st' wrong too ?
<cody-somerville> binded branch
<vila> no 'run bzr update' warning ?
<cody-somerville> and the diff is hard to describe why its wrong. Its adding lines that were already there and the context in the patch would result in the patch not apply anyhow.
<cody-somerville> *applying
<cody-somerville> nothing is instructing me to run bzr update, if thats your question
<vila> cody-somerville: do 'bzr revno' and 'bzr revno --tree' agree ?
<cody-somerville> vila, yes
<vila> bzr missing ?
<fullermd> May want an explicit `missing :bound`...
<cody-somerville> I'm afraid if I run more bzr commands, what ever state bzr is in to cause this error will be resolved
<vila> cody-somerville: yeah, on the othe hand, that's the point :)
<cody-somerville> I'd rather get the debug info needed for the bug to be fixed.
<vila> Well, I don't have enough info yet to say whether it's a bug or not :-/
<spiv> cody-somerville: make a tarball (including .bzr/repository, .bzr/branch, .bzr/checkout, and the actual workingtree)?
<vila> ensuring you get the repo if it's shared
<cody-somerville> interesting, bzr export gives me a directory that the patch would apply against
<cody-somerville> holy crap
<spiv> Sounds like the issue isn't with 'diff' per se, but with the branch you are working on not having the contents you think it does?
<lifeless> cody-somerville: the problem with 'wrong' is that there are many ways something can be wrong, and usually only one way something can be right
<lifeless> cody-somerville: so when you say 'wrong', we have -no- idea which of the many forms of wrong has occured.
<cody-somerville> loggerhead shows different content for the file
<cody-somerville> but if I download the file by clicking 'download file', I get the content I expect
<spiv> URL?
<vila> spiv: tsk, you spoil then fun
<cody-somerville> spiv, Sent you the URL via PM
<cody-somerville> lifeless, Indeed. Unfortunately this isn't an easy case of 'wrong' to articulate. The branch in question being Canonical confidential doesn't help.
<cody-somerville> However, in the case of loggerhead, the last line of the file is missing (but isn't when I download the file).
<lifeless> is the last line missing a \n ?
<cody-somerville> lifeless, yes
<lifeless> please file a bug
<cody-somerville> lifeless, on the loggerhead issue?
<lifeless> yes
<cody-somerville> lifeless, actually, there is a newline.
<lifeless> cody-somerville: in both versions?
<cody-somerville> holy crap
<cody-somerville> this is weird.
<cody-somerville> If I save the file to disk, I get what bzr is saying the file is
<cody-somerville> if I open it in firefox and look at the source, I see what I expect
<lifeless> ah
<lifeless> try less
<lifeless> and also remember that browsers have defined eol markers in html docs which are not necessarily whats sent on the wire
<cody-somerville> I sorta see what I expect except there is a ^M where I expect a newline at the end of the second to last line.
<lifeless> yup
<lifeless> in which case, I think there isn't a bug
<lifeless> you've just got a crap file
<cody-somerville> I think there clearly is a bug.
<lifeless> perhaps in the http/html specs
<lifeless> gotta run
<cody-somerville> The file was fine though. I dunno how this happened.
<cody-somerville> and changing "I'm sorry. You're not authorized to access this page." to "You're not authorized to access this page." seems very odd for a EOL marker issue to cause
<MvG> Hi there! trying to understand bug #370710, I would like to know what consequences can be expected from a call to WorkingTree.set_root_id.
<MvG> Am I correct to assume that the root ID is stored in the branch, even if I set it via the working tree? What information is associated with that ID, which might break when changing the ID?
<MvG> Is there a particular reason an upgrade chooses a fixed root id? Wouldn't it be preferable to calculate a hopefully unique ID e.g. based on the revid of the revision with revno 1 or some such? That would give the same id for all branches, and still give different IDs for independent branches.
<ubottu> Launchpad bug 370710 in bzr "bzr: ERROR: File id {TREE_ROOT} already exists" [Medium,Confirmed] https://launchpad.net/bugs/370710
<cody-somerville> lifeless, I got rid of the ^M and bzr is still giving me the incorrect diff
<cody-somerville> vila, Are you still around to help?
<vila> cody-somerville: a bit but I need meat to chew
<cody-somerville> vila, https://pastebin.canonical.com/31047/
<cody-somerville> vila, https://pastebin.canonical.com/31050/ <-- actual current content of file in tree
<vila> cody-somerville: both have a final newline right ?
<cody-somerville> vila, as far as I can tell, yes.
<vila> so, given the current content of the file and the diff, I need that content of the file in the branch tip
<cody-somerville> vila, Sent you link
<cody-somerville> vila, What I noticed is loggerhead does not show last line of file
<vila> cody-somerville: urgh, yes
<cody-somerville> vila, IF you download file and open in firefox, and then click show source the file looks as expected
<vila> cody-somerville: so at least file a bug against loggerhead
<vila> but the diff is weird, it shows the '{% endif %}' *before* the text
<lifeless> cody-somerville: ^M is CR as opposed to LF, IIRC.
<cody-somerville> vila, if You download and save to disk, it looks like bzr sees it if you cat the file. If you less it, it looks like how I expect except for an ^M instead of a new line at the end of the second to last line.
<lifeless> cody-somerville: the line is there, it just looks missing
<vila> cody-somerville: isn't there a CR somehwere
<spiv> cody-somerville: try 'cat -v', not 'cat'
<cody-somerville> spiv, That gets me what I see with less
<vila> cody-somerville: there is a litteral '^M' there
<vila> that triggers various display bugs...
<spiv> vila: odd use of the term literal, don't you mean there is a CR byte?
<lifeless> vila: features :P it is after all how our progress bars work.
<cody-somerville> I fixed that issue in the branch tree
<cody-somerville> and I still have the issue
<lifeless> cody-somerville: and you've committed ?
<cody-somerville> no
<spiv> cody-somerville: pipe the diff through 'cat -v'?
<vila> spiv: yeah, I meant there literraly is a CR there. Is that more correct ?
<cody-somerville> spiv, that completely changes the output of the patch
<spiv> vila: well, it at least doesn't sound like you are saying there is a ^ followed by a M ;)
<vila> lifeless: I agree, it's a feature
<lifeless> vila: literaly can be a superlative, or used when there is doubt that one speaks seriously.
<vila> spiv: oh, ok
<cody-somerville> spiv, https://pastebin.canonical.com/31051/
<lifeless> vila: I wouldn't use literaly in this context, it was clear you were serious, and literally is a literally terrible superlative :)
<vila> lifeless: lol,, ok,
<vila> cody-somerville: yeah, this last diff is correct, so blame the diff viewer you were using ?
 * fullermd literally checks for an XKCD ref...
<spiv> cody-somerville: so the change according to that diff is that a CR got changed to a LF
<cody-somerville> It might be a bug in the xfce4 terminal
<lifeless> cody-somerville: its a feature, all the bits operating as intended. How you got the \r there is a mystery but the rest is totally explicable
<spiv> Well, CR is generally meant to be interpreted by terminals as "move the cursor back to the start of the line", i.e. "carriage return"
<vila> cody-somerville: yes and no, CR *must* be interpreted as: go to the beginning of line in some contexts
<vila> blam, stereo effect :)
<cody-somerville> So bzr should probably do what ever the -v does to cat to its output
<vila> cody-somerville: vade retro satanas, it's not bzr job
<spiv> Well, AFAIK that's the correct diff output; that's the sequence of bytes you'd need to feed to GNU patch to reproduce that change.
<cody-somerville> hmmm
<cody-somerville> there has to be a way to provide a better user experience in this case.
<lifeless> cody-somerville: I'm still not sure what went wrong; it sounds like you tried to apply a patch to a file you got from your browser, but it didn't work from bzr ?
<spiv> Well, loggerhead seems to have a bug, which doesn't help.
<vila> yes, use the right viewer, mine displays ^M and don't interpret it in that case
<lifeless> or something like that
<lifeless> spiv: it does ?
<cody-somerville> lifeless, nope
<vila> cody-somerville: but loggerhead should certainly be fixed
<lifeless> spiv: are you aware that browsers munge \r and \n together ?
<spiv> Perhaps a graphical diff tool like "bzr qdiff" or "bzr gdiff" would show tht more clearly.
<lifeless> deliberately
<cody-somerville> lifeless, I think it might be a bug in gedit
<spiv> lifeless: not really, but I don't see how that explains the absence of the final "{% endif %}" text in loggerhead's annotate view
<lifeless> spiv: I thought cody was saying that it shows in loggerhead ?
<lifeless>  /ETIRED
<lifeless> tomrrow
<lifeless> cody-somerville: if loggerhead or bzr hid the content, please file bugs.
<spiv> lifeless: no, in loggerhead the final line seems to be missing in the annotate view
<lifeless> we don't want to mangle stuff, and cat really needs to show the canonical content [by default]
<lifeless> but we can record that you had an issue
<spiv> lifeless: at a glance perhaps because the final line doesn't have a newline
<lifeless> ah, 'perfect storm' :P
<lifeless> gnight
<salgado> I've just got a merge conflict but this time around I was left with just the .BASE and .OTHER files and no original file with inline conflict markers
<salgado> has anything changed recently?
<salgado> I'm using 2.1.1, btw
<vila> salgado: no recent change, what does 'bzr conflicts' says ?
<salgado> Contents conflict in cronscripts/branch-scanner.py
<salgado> Contents conflict in lib/lp/codehosting/scanner/branch_scanner.py
<salgado> vila, I use --lca by default, btw
<salgado> renamed:
<salgado>   cronscripts/branch-scanner.py => cronscripts/branch-scanner.py.THIS
<salgado> unknown:
<salgado>   cronscripts/branch-scanner.py.BASE
<vila> so you should have a  cronscripts/branch-scanner.py.THIS file
<salgado> I do, yes
<salgado> I said OTHER but I meant THIS
<vila> silly me, of course :-P
<vila> salgado: so, presumably the branch you're merging from has deleted these files
<vila> but they have been modified locally, hence the conflict
<vila> salgado: to resolve you need to either delete the file OR keep it with its modifications
<salgado> yeah, I assumed it'd be that but when I checked it was still there
<salgado> of course, I checked on the wrong branch
<vila> pfew, I had a wtf moment...
<salgado> vila, yeah, so did I when I saw the file was still there.  anyway, thanks for the help
<cody-somerville> loggerhead bug appears to already be reported: lp ##387225
<vila> bug #387225
<ubottu> Launchpad bug 387225 in loggerhead "\r line endings poorly handled" [Medium,Confirmed] https://launchpad.net/bugs/387225
<vila> cody-somerville: well done, did you click the me-too ?
<vila> cody-somerville: oh yeah, even added a tag
<vila> naoki^, bialix: Can you test an alternative fix for bug #523746 from lp:~vila/bzr/523746-difftool-file-names ?
<ubottu> Launchpad bug 523746 in bzr "crash with winmerge in cp932 japanese character" [Undecided,In progress] https://launchpad.net/bugs/523746
<cobalt_mike> Does anyone have experience building on bzrlib directly? I have a few questions....
<maxb> cobalt_mike: Better to just ask them
<cobalt_mike> Alright, for example, if I want to implement checkout, but I want a hook for every file that's created, am I better off starting with the cmd_checkout class from builtins, or building up equivalent functionality with lower-level primitives like Branch, etc.
<cobalt_mike> I'm guessing I'm going to have to add some hooks somewhere, as well...
<lfaraone> How can I include a folder with a git repo in a bzr repository? I'm developing some software to work with git repos (among other VCSs), but when "bzr add"ding the .git/ folder I get "    ... chl = debian_bundle.changelog.Changelog(file=open(os.path.join(test_folder, 'debian', 'changelog'), 'r').read())".
<lfaraone>     ... chl.full_version
<lfaraone> oops, I mean "bzr: ERROR: No WorkingTree exists for "/home/lfaraone/Projects/ubuntu-dev-tools/trunk/uvs-tests/git-test-1/gitrepo/.git/"."
<cobalt_mike> lfaraone: Not a direct answer to your problem, but I've had to include SCM repositories for testing in SCM repositories before, and I've found it was just easier to store it as a zip or tarball and have the test fixture extract it
<ctrlsoft> lifeless: do you perhaps have bzr-git installed?
<lfaraone> cobalt_mike: yes, I do.
<lfaraone> * ctrlsoft
<ctrlsoft> lfaraone: that would explain it, that will attempt to use the .git directory
<lfaraone> ctrlsoft: okay. How can I disable the plugin for this repository?
<ctrlsoft> lfaraone: if the .git directory doesn't have a working tree I would recommend changing it into a bare repository
<ctrlsoft> lfaraone: you can uninstall the plugin or use --disable-plugins
<lfaraone> ctrlsoft: it does have a working tree as far as I can tell, I just created and committed a few changes into it.
<cobalt_mike> Another question re: bzrlib - what's the right way to initialize a repository? The documentation seems to indicate I should use BzrDir.create, but the builtins use BzrDir.format_registry.make_bzrdir
<ctrlsoft> cobalt_mike: the first actually creates a BzrDir, the latter creates a format object
<ctrlsoft> lfaraone: as far as bazaar is concerned this is a nested tree, so it's trying to add it that way
<ctrlsoft> lfaraone: I think the only real workaround is to remove bzr-git for now
<cobalt_mike> ctrlsoft: errr, right =)... why would I want to create the format object over just building the directory directly? BzrDir.create takes an optional format param
<ctrlsoft> cobalt_mike: right, so if you want to biuld a repository with a specific format you'd use BzrDir.format_registry.make_bzrdir first
<ctrlsoft> cobalt_mike: and then pass what it returned into BzrDir.create()'s format argument
<ctrlsoft> cobalt_mike: if you just want the default format, use BzrDir.create() without specifying the format argument
<cobalt_mike> thanks!
<cobalt_mike> maybe I'll eventually compile my notes into a wiki page about using bzrlib =)
<jannn> hey, how to I tell bzr checkout to ignore invalid certificates instead of just erroring out?
<cbz> does anyone here use subversion from bzr? i'm just wondering why the revision numbers in bzr are a lot lower than the revno in subversion
<ctrlsoft> cbz: bzr revision numbers are per-branch, in subversion they are per-repository
<ctrlsoft> cbz: if you have bzr-svn installed then "bzr log" should show both
<cbz> okay - but i assumed after an initial bzr branch command the numbers would match, as at least initially each svn revid would have a bzr revision it maps to
<ctrlsoft> cbz: subversion doesn't have revision ids
<ctrlsoft> cbz: it only has revision numbers, and those do indeed map to bzr revids
<ctrlsoft> cbz: the bzr revno's differ per branch
<ctrlsoft> cbz: if you e.g. look at "bzr log /trunk" and "bzr log /branches/foo" then revno X may refer to different revisions in both outputs, but the svn revno will be the same
<cbz> Yeah, but i haven't created any more branches. All i've done is a bzr branch svn+repurl
<cbz> And i've got things like revno: 2932
<cbz> svn revno: 14362 (on /core/trunk)
<ctrlsoft> cbz: right, so you have more branches in the svn repo
<ctrlsoft> cbz: unless /core/trunk is the only branch that exists?
<cbz> oh yeah - i see what you mean.
<cbz> Thanks.
<ctrlsoft> np
<cobalt_mike> ok, next question: I'd like to add hooks to bzrlib to fire whenever a file is created or updated during a checkout/update
<cobalt_mike> any pointers on where to start looking?
<ctrlsoft> cobalt_mike: I don't think there are any hooks that you could use for that yet
<ctrlsoft> cobalt_mike: see the output of 'bzr hooks'
<cobalt_mike> right, I want to add them at the library level (and hopefully contrib back)
<ctrlsoft> cobalt_mike: jam or vila are probably the best people to talk to about this
<jam> cobalt_mike: is there a particular difference to what you want to do, vs using a content filter?
<cobalt_mike> ah, hadn't seen content filters.... reading....
<cobalt_mike> well for one, I'm not actually modifying the file, I essentially need to post-process it, but not in-place
<cobalt_mike> so I guess I could make a no-op filter that what I needed
<cobalt_mike> that ^did
<jam> cobalt_mike: I think it would be a potential hook point for what you need, but if you have a clear idea of what you would like to see added, I'd be happy to discuss it
<servilio> hi all! is it possible to move a branch into a shared repository and take advantage of the sharing?
<servilio> I've googled a little bit, but haven't a way to do it so far
<jam> servilio: 'bzr reconfigure --use-shared'
<servilio> jam: :O great! thanks!
<servilio> jam: so I only need to "mv branch repo/" then "bzr reconfigure --use-shared"?
<servilio> seems to have worked, thanks!
<ccxCZ> how do I check for uncommitted changes in WorkingTree using bzrlib?
<jam> ccxCZ: tree.has_changes() ?
<jam> or do you need the specific changes
<ccxCZ> jam: that's it, thanks
<jam> is there a losa around that can take a look at pqm?
<jam> I just tried to submit something, and I'm now seeing a webserver traceback on http
<a212901390231901> erk, hope it's not still my screwup
<jam> well, it may have been a race, as now doing a refresh shows things as ok
<jam> I saved the html just to be sure
<jam> of course, it isn't *telling* me that my request succeeded / failed
<a212901390231901> also,
<a212901390231901> Definitions of losa on the Web:
<a212901390231901> The nuraghe Losa (in Sardinia, close to the village of Abbasanta) is a complex prehistoric building in the shape of a tholos tomb.
<a212901390231901> losa?
<jam> a212901390231901: It's a launchpad sysadmin
<jam> not sure the exact acronym
<Chex> jam: ill be with you in a moment
<jam> thanks Chex
<Chex> jam: few minutes
<jam> Chex: so no big rush, I filed a bug about the traceback, and it seems to be running. Though it should have given me a "failure" message from the first submission.
<rephormat> greetings everyone.
<rephormat> I am attempting to compile bzr-2.1.0 with python setup.py install, but am getting a gcc failed with exit status 1
<jam> rephormat: do you have zlib1-devel ?
<jam> and other such python devel packages?
<jam> (also win32/mac/linux ?)
<Chex> jam: ok, I can try to look for you now
<jam> Chex: so the first submission seemed to fail without telling me. If you can check the log to see why it didn't send a failure email, I would appreciate it.
<rephormat> sorry I'm on linux
<Chex> jam: can you give me the subject line of your submit? makes it easier to find in the logs
<rephormat> I install python-devel
<jam> Chex:  '(jam) Reduce peak memory usage by 1 compressed text copy during 	commit in 2a formats.'
<jam> though I re-submitted that again with a correct url
<jam> which seems to be running successfully now
<jam> rephormat: you probably also need to install zlib1g-devel or something along those lines
<jam> I don't remember the exact name of the package
<jam> zlib and -dev at least :)
<rephormat> THANK YOU VERY MUCH!~
<rephormat> Thast what it was
<rephormat> ok now for second question
<rephormat> what is a good web frontend for bazaar version control system that allows bug reporting?
<jam> rephormat: Launchpad ?
<jam> there is loggerhead to view the branch history, there is some integration with trac
<rephormat> oh yes of course I love that web interface, but I was hoping for something that I could setup and admin internally
<rephormat> I have tried bzr-trac, but it requires me to start from scratch
<rephormat> which is kinda strange
<jam> rephormat: well launchpad is open source, other than needing to rebrand it, you can use it
<jam> rephormat: 'start from scratch' ?
<rephormat> I was unable to find a download for launchpad
<rephormat> I thought you had to use their service
<jam> https://dev.launchpad.net/
<jam> big link for "Get the source code"
<jam> AFAIK it is a fairly large bit of software to set up
<jam> and the images are trademarked
<jam> however
<jam> I see both:
<jam> https://edge.launchpad.net/bzr-trac
<jam> and
<jam> https://edge.launchpad.net/trac-bzr
<jam> the former being a "complete rewrite" of the latter
<rephormat> I'm not sure which of those I used...
<jam> the latter is the only one I actually knew about
<rephormat> but one of them was relatively complex to admin
<mkanat> jam: The trademark guidelines forbid anybody but Canonical from using the images at all?
<jam> mkanat: I don't really know. I'm not deep in that discussion, its just something I've seen mentioned.
<jam> I'm certainly not a lawyer
<jam> my personal impression, is that if you used it in-house only, then you'd probably be fine
<jam> but once you put it on the web
<jam> then you are serving images you don't own
<jam> https://dev.launchpad.net/Getting has some discussion on it
<jam> "The images/icons are still copyrighted traditionally, to protect  Launchpad's visual identity.  But they're shipped with the code and are  fine to use for development and testing purposes.  Just if you launch a  production server, it needs to look different -- and have a different  name, of course, as "Launchpad" is a trademark.  From our point of view,  we're doing this to improve our hosted service. "
<mkanat> jam: Okay. I don't see any Trademark Guidelines for "Launchpad".
<mkanat> jam: Uuuusually that means that anybody could put up a version of the system and call it Launchpad, as long as they didn't put up some *different* system and call it Launchpad.
<mkanat> jam: For example, Mozilla and GNOME customize the hell out of Bugzilla, and still call it Bugzilla.
<mkanat> jam: That could just be because we don't enforce the trademark, though. :-)
<edgimar> If I've made a commit, and then made additional changes I wanted in that commit, what do I do to get them in there?  Is there a way to 'collapse' commits together?
<jam> edgimar: are you sure it *really* matters?
<jam> but anyway
<jam> bzr uncommit; bzr commit
<jam> bzr uncommit = >remove the last commit from this branch's history, but leave the WT unchanged
<edgimar> jam, ok - I wasn't clear on what uncommit would do to the WT.
<jam> edgimar: right, it exists to do this sort of thing :)
<jam> bzr uncommit && bzr revert if you really want it all gone
<edgimar> you mean all changes since the tip-1 commit, right?
<jam> edgimar: bzr revert reverts all changes vs the current tip
<jam> not just the ones you had uncommitted
<jam> if you want just those gone
<jam> bzr merge . -r -1..-2; bzr uncommit
<a212901390231901> jam: is it worth submitting a merge req. shaving four bytes off chk_map.LeafNode? I poked it while doing something else, but don't know if enough are ever created to make much of saving.
<jam> a212901390231901: there are a fair number created sometimes
<jam> it would probably be worth reviewing
<SimonK> Has any work been done on any plugins that might support tagging files with labels?
<a212901390231901> thanks!
<mkanat> spm: Hey hey. What version of pygments is installed on the codebrowse server?
<edgimar> one other question: is there an equivalent to mercurial's 'hg incoming' for bzr?  (shows differences between two branches -- i.e. what commits are in one that aren't in another)
<krisives-gearbox> edgimar: doesn't `bzr missing` do that/
<edgimar> krisives-gearbox: indeed it appears to.  Thanks - I hadn't noticed it before.
<krisives-gearbox> edgimar: np, feel free to read my list http://santiance.com/2010/04/a-bazaar-list-of-things/)
<krisives-gearbox> err URL paste fail http://santiance.com/2010/04/a-bazaar-list-of-things
<edgimar> ok another question: if I wanted, say, to change something about commit rev -3 (in fact I do -- forgot to change my 'whoami' setting), what's the way to do that?
<jam> Chex: any luck? I just submitted another revision, and I don't know whether it succeeded or failed
<jam> no email
<jam> no movement on the pqm branch tip
<Chex> jam: I have 3 patch logs matching that submit subject
<Chex> you want to see them?
<jam> Chex: sure
<Chex> k hang on
<edgimar> so, I take it there's no easy way to edit an arbitrary commit (i.e. just to change some metadata)?
<cbz> I don't really understand repositories. What does the last sentence in this mean:
<cbz> "It is a good idea to create a repository whenever you might create more than one branch of a project. This is true for both working areas where you are doing the development, and any server areas that you use for hosting projects. In the latter case, it is common to want branches without working trees. Since the files in the branch will not be edited directly there is no need to use up disk space for a working tree."
<eric_f> Is there a good way to do nested trees? Looking to have a top-level project which part of it comes form a separate sub-project.
<edgimar> Will 'bzr re-sign' change the username used for a commit?
<Chex> jam: chinstrap:~stasik/isd/
<Chex> jam: 1st 2 patches that failed are in there, the 3 patch is giving me an error, empty file for some reason.. , checking on the status of bzr-pqm for you now
<jam> Chex: so patch.1271877495.log just say "no such file patch.1271877495"
<jam> are you sure that's right?
<Chex> jam:
<Chex> jam: erm, let me see
<Chex> jam: yes it is.. so both the 2nd and 3rd patch logfile errored out that way..
<Chex> jam: and theres nothing exciting in the general pqm.log, either..
<jam> k
<Chex> lifeless: when you are available, please ping us losas, the update we did yesterday seemed to cause issues with ubunet pqm
<mkanat> Huh, I wonder if pygments is not threadsafe.
<mwhudson> !/
<mwhudson> !?, rather
<mwhudson> i guess it's possible
<mkanat> mwhudson: I'm doing a really thorough log analysis, so far there's a vague indication that pygments may indeed be the culprit. But I will let you know when it's fully complete, and I'll post it to the bug.
<mwhudson> heh, i time "!?, rather" and ubottu sends me a private message
<mwhudson> type!
<mwhudson> mkanat: ok
<jam> !?
<jam> doesn't seem to if you don't get more verbose
<mkanat> mwhudson: As a side note, the hung-thread killer needs to be way more aggressive.
<mwhudson> mkanat: yeah, probably
<mkanat> mwhudson: In this log it only kills threads after they haven't responded for like 3-5 minutes.
<mkanat> (Or sometimes 5-10 minutes.)
<lifeless> Chex: -> lp-code
<Chex> lifeless: great, thank you
<krisives-gearbox> edgimar: You can do that by `bzr revert -r 3 myFile` then edit the file and do another `bzr commit`
<igc> morning
#bzr 2010-04-22
<mkanat> mwhudson: What version of pygments is installed on codebrowse?
<mwhudson> mkanat: whatever's in hardy i guess
<mkanat> mwhudson: Okay.
<mwhudson> mkanat: 0.9-2
<mkanat> mwhudson: Thanks! :-)
 * igc building Windows installers for 2.2b2 today
<blueyed> krisives-gearbox: well, the old commit would still be there.. you're creating only a new one. I would go with several "uncommits", fix the one in question, then redo the latter ones. edgimar ^^
<igc> spiv, bug 496813 has landed into 2.1 now right?
<ubottu> Launchpad bug 496813 in bzr/2.1 "until_no_eintr used on unrestartable IO, and cannot address all cases of EINTR." [High,In progress] https://launchpad.net/bugs/496813
<poolie> hi all
<spiv> igc: yes, thanks, bug updated
<igc> spiv: thanks
<poolie> lifeless (if any), I was thinking last night
<poolie> perhaps we could test pqm in the real environment but on a different branch
<poolie> so that it doesn't block development like bug 568100
<ubottu> Launchpad bug 568100 in bzr "PQM broken for bzr/2.0" [High,Confirmed] https://launchpad.net/bugs/568100
<lifeless> poolie: so thats not pqm itself; thats the subunit version in the chroot
<poolie> because it changed recently and 2.0 is incompatible?
<poolie> ok, but even beyond that specific bug
<lifeless> the lack of feedback is hopefully fixed at this point, or at least, one less cause removed
<lifeless> poolie: an edge/testing environment would be good
<lifeless> I'm not dismissing that
<poolie> needing to test it in the deployed environment seems not to be quite the same as needing it to be tested within our main workflow
<lifeless> just noting the details of that particular problem
<poolie> so we need to land a change to 2.0 that makes it pass with current subunit?
<lifeless> yes
<poolie> i see
<lifeless> I've commented with a reasonable pointer in the bug
<lifeless> I think an edge/staging environment for our CI stuff would be great
<lifeless> that way when we move to tarmac, or whatever changes we want, we can be more confident before making changes.
<poolie> so that would be i guess a different mail address and a different destination branch?
<lifeless> and different test chroot
<lifeless> and different pqm tree
<lifeless> possibly even a different machine [perhaps a UEC vm] as there are dependencies involved like launchpadlib version
<igc> hi poolie. Trip back to the big smoke all go ok?
<poolie> it was fine
<poolie> i really liked seeing brisbane again
<jbowtie> Hi, does anyone have any pointers on integrating NTLM support?  I've been using python-ntlm and urllib2 directly in my TFS plugin and would like to switch to using the HTTP transport.
<poolie> and seeing you
<igc> poolie: we even put on some rain for you :-)
<igc> poolie: ditto
<rephormat1> greetings everyone.
<rephormat1> I was wondering if anyone would have some time to discuss the workflow for a standard bazaar development environment
<poolie> lifeless: is it possible at all that pqm could put the failures on its own webserver and just post a link to the mp?
<jbowtie> Mostly I want to make sure I interact correctly with the credentials support so I can prompt for a password; should I just look at the urllib2 wrapper stuff?
<poolie> jbowtie: it sounds good; you probably want to come in through the bzr authentication layer
<rephormat1> I have successfully used bazaar in both a local and bzr+ssh fashion, but when I use the bzr+ssh fashion it always commits to the server rather than locally.
<poolie> but ntlm has an intimate connection to http so it may be complex
<poolie> j: vila knows the most about this but he may be asleep
<mkanat> lifeless (or whoever): The lru_cache thread fix is in 2.1.0, right?
<mkanat> (That's what the bug says, I just want to be sure it's right.)
<jbowtie> poolie: I was hoping I could just plug in the urllib2 provider that python-ntlm provides, but since all that stuff appears to be wrapped I was unsure how straightforward it was going to be.
<jbowtie> rephormat1: I usually create a branch locally, commit there, then push to the remote server.
<jbowtie> If we get NTLM support integrated I can publish my bzr-tfs plugin, that's really the only missing piece.
 * igc out for a few hours
<igc> (2.2b2 builds for windows kicked off)
<rephormat1> j: does that mean you would do a bzr checkout bzr+ssh://server/project/
<rephormat1> J: make changes to the code, test, commit
<rephormat1> j: then do a bzr push?
<jbowtie> rephormat1: Well, I would do a bzr branch; if I did a bzr checkout I wouldn't need to push (bound branches commit to both the server AND the local branch)
<rephormat1> ahhh
<rephormat1> jbowtie: so I would do a bzr branch bzr+ssh://server/path/project ~/project
<rephormat1> jbowtie: make my changes, test, commit, then bzr push?
<jbowtie> rephormat1: Yes - with that workflow everything stays locally until you push to the server.
<mwhudson> mkanat: +1 to working on bug 420738
<ubottu> Launchpad bug 420738 in loggerhead "LRUCache.cleanup raises KeyError" [Critical,Confirmed] https://launchpad.net/bugs/420738
<rephormat1> EXCELLENT!
<rephormat1> jbowtie: What happens if I make changes to the same file as one of my other editors?
<rephormat1> jbowtie: just tell me if I'm being lazy and I'll try to make sense of the documentation again.
<mkanat> mwhudson: Thanks. :-)
<jbowtie> rephormat1: Usually that stuff just merges seamlessly. If there was a merge conflict I imagine you'd have to pull down the server changes, resolve the conflicts locally, then push again.
<rephormat1> jbowtie: Thank you very much for your help, jbowtie. I appreciate it. Trying to get my programming group at our university to switch to bazaar
<jbowtie> rephormat1: I have Subversion habits so I usually pull just before pushing as a safety precaution, but bzr has never bitten me.
<rephormat1> Now all I have to do is find a bug tracking web gui for bazaar
<jbowtie> rephormat1: No worries, doing the same at work which is why I'm working on a TFS plugin.
<mkanat> rephormat1: Bug-tracking and version-control are unrelated....
<rephormat1> I can't do it on launchpad.. at least not right now as all this code is inhouse and can't be public
<rephormat1> TFS?
<jbowtie> TFS = Team Foundation Server. Horrible Microsoft proprietary thing.
<rephormat1> mkanat: my apologies. What I meant was being able to reference a bug ticket like you can when doing a commit with launchpad.
<rephormat1> jbowtie: DUDE! I feel for you man.
<mkanat> rephormat1: Ahhh. bzr can do that with Bugzilla out of the box.
<rephormat1> jbowtie: I finally got my group AWAY from SHAREPOINT!!!!!!
<rephormat1> mkanat: YOU ARE AWESOME!!!!
<rephormat1> Now if only I can kill off the microsoft group. LOL!!
<mkanat> rephormat1: Although I don't currently know of any integration within Bugzilla for bzr.
<jbowtie> rephormat1: That might be my next project after this.
<rephormat1> mkanat: I don't understand. Your saying it works out of th box, but that there is no integration?
<mkanat> rephormat1: bzr supports noting that a particular commit is associated with a particular bug in Bugzilla.
<jbowtie> rephormat1: I think Trac is also well supported; there's a bzr plugin IIRC.
<mkanat> rephormat1: It's a feature in bzr.
<rephormat1> Can you imagine.. a primarily open-systems group using SHAREPOINT!!!
<rephormat1> so I showed them the light with Mediawiki
<rephormat1> LMAO!!
<rephormat1> jbowtie: yeah I was looking at bzr-trac at launchpad. The only thing I didn't like about it was that it required a directory to be completely empty to create a "trac"d branch
<rephormat1> mkanat: I'm going to have to research that. Do you know if bugzilla can be downloaded and setup as a local private bug reporting system?
<rephormat1> just curious..
<mkanat> rephormat1: Yes, for sure.
<rephormat1> mkanat: I TRIED to install a local private setup of launchpad... MAN that was a pain in the a$$..
<mkanat> rephormat1: I can imagine.
<rephormat1> mkanat: so I gave up... I'm a quitter.. I know... lol
<rephormat1> but both of you have just peaked my curiousity and made my convincing arguement that much easier
<mkanat> Okay, I have spent six hours reading this effing log, it's time to take a break.
<rephormat1> mkanat: What log?
<mkanat> rephormat1: Unrelated to our conversation.
<mkanat> rephormat1: Related to loggerhead work I'm doing.
<rephormat1> mkanat: excellent
<zeroseven0183> Hi
<zeroseven0183> I need help
<zeroseven0183> I was trying to download the Ubuntu Manual project files
<zeroseven0183> via bzr branch lp:ubuntu-manual last night
<zeroseven0183> I was able to start it, but in the middle of the download, I decided to cancel (since I'm going to bed already)
<zeroseven0183> Now, when retrying to download it gives me "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
<zeroseven0183> How do I correct this?
<zeroseven0183> I've tried with different directory/folder (with the same name, and with a different name), but still the same error
<jbowtie> zeroseven0183: So you're trying to branch it again?
<zeroseven0183> Yes, correct
<zeroseven0183> "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
<jbowtie> zeroseven0183: OK, I seem to be branching it without a problem. Can I assume you've checked your connectivity?
<zeroseven0183> Yes, I did and it's working fine
<jbowtie> zeroseven0183: Can you branch other projects from launchpad?  For example, lp:quickly?
<zeroseven0183> On the same directory?
<zeroseven0183> Ok, wait
<zeroseven0183> Sadly, now
<zeroseven0183> Same error "Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist."
<jbowtie> Hmmm...does bzr info output anything?
<zeroseven0183> bzr: ERROR: Not a branch: "/home/tutdek/Quickly/".
<jbowtie> zeroseven0183: OK - is there a .bzr subdirectory in that directory?
<zeroseven0183> No, there is no .bzr
<zeroseven0183> But what I see in my /home folder is .bazaar
<jbowtie> zeroseven0183: Well if there's no .bzr directory then it's not even getting far enough to start creating the branch. The other possibility is permissions; maybe send off an email to the launchpad admins?
<zeroseven0183> Alright but how come I was able to do that last night?
<zeroseven0183> Something to do with my Public Key
<zeroseven0183> I already generated and reposted my public key twice this morning
<jbowtie> zeroseven0183: I don't know - at this point I'm speculating (note that the error message does say 'Permission denied' ).
<zeroseven0183> Yup
<jbowtie> zeroseven0183: Best bet is to  contact the admins, they can probably tell you what's going on; maybe some spammer got your ISP subnet blacklisted.
<fullermd> The error means it's not succeeding at key auth.  Which probably means the key you're using locally and the key on LP are different.
<fullermd> Try just connecting manually with ssh, and sprinkle on -v's to taste to see what key it's expecting to use.
<zeroseven0183> I have two SSH keys in my Launchpad account
<zeroseven0183> Are they both being scanned when branching?
<fullermd> I'd imagine.
<fullermd> But don't guess.  See what ssh says.
<zeroseven0183> Never thought the efects of cancelling that download would be harder
<zeroseven0183> Alright, fullermd, how do I do the ssh -v thing?
<zeroseven0183> Sorry I'm not good in command lines
<spiv> zeroseven0183: "ssh -v bazaar.launchpad.net"
<spiv> zeroseven0183: and see which keys it tries
<zeroseven0183> The last line still says Permission denied (publickey)
<fullermd> May need a couple (-vv or -vvv) to see all the details; I don't know offhand what levels reports everything you need.
<spiv> zeroseven0183: right, but hopefully the other lines will give you some information about which keys ssh is trying to use
<zeroseven0183> Ok. Here's what I got http://pastebin.com/i17EkVBB
<zeroseven0183> http://pastebin.com/raw.php?i=i17EkVBB
<spiv> zeroseven0183: oh, I forget
<spiv> zeroseven0183: you should also explicitly use your launchpad username with "ssh -v"
<spiv> zeroseven0183: e.g. "ssh -vv bazaar.launchpad.net -l zeroseven0183" or whatever
<spiv> (Unless your Launchpad username is tutdek?)
<zeroseven0183> Nope
<spiv> Otherwise that debug output just tells us that none of your local keys match the public key on launchpad for 'tutdek' :)
<zeroseven0183> Here's the changes http://pastebin.com/raw.php?i=bEWWMRAd
<zeroseven0183> Just added -l zeroseven0183
<spiv> Ok, then none of the keys you have locally in .ssh match any of the ones on your Launchpad account.
<spiv> It says it is trying 3 different keys in your .ssh directory, but none of them are right.
<spiv> zeroseven0183: take a look at your .ssh/id_rsa.pub file, does it match one of the ones at https://edge.launchpad.net/~zeroseven0183/+sshkeys ?
<zeroseven0183> Now that's a lot of characters! :-)
<zeroseven0183> Yes, I think they're match
<spiv> Hmm!  Then I'm not sure why it would fail :(
<zeroseven0183> Wait
<zeroseven0183> I have two keys in edge.launchpad.net
<spiv> Yes.  That's fine.
<zeroseven0183> The last one matched with what's in the .pub
<spiv> You can have twenty if you like ;)
<zeroseven0183> Hmmm... I wish I was more patient last night
<zeroseven0183> The download was just 50% when I cancelled it
<spiv> I don't know why that key would have stopped working overnight.
<mkanat> This is the second time that a loggerhead bug has taken me weeks or months to track down and ended up being a tiny, tiny fix.
<spiv> mkanat: heh
<zeroseven0183> spiv: I guess I should go and e-mail the Launchpad admins?
<spiv> zeroseven0183: at this point I only have increasingly unlikely theories, e.g. that the permissions on your .ssh directory or the .ssh/id_rsa file are wrong, but I'd expect ssh to warn if that's the case.
<spiv> ("ls -ld ~/.ssh" should show "drwx------", and "ls -l ~/.ssh/id_rsa" should show "-rw-------")
<spiv> Hmm: "debug2: we did not send a packet, disable method" is odd
<zeroseven0183> :-(
<spiv> It should have lines like "Offering public key: /home/andrew/.ssh/id_rsa", but it doesn't.
<zeroseven0183> OK wait... I think I'm seeing some light
<spiv> It definitely shows signs of being a local configuration problem, but I don't know what.
<zeroseven0183> You mentioned the ls -l ~/.ssh/id_rsa
<zeroseven0183> being in the ~/.ssh directory
<zeroseven0183> I don't have that
<spiv> Oh!  I see.
<zeroseven0183> So I moved the id_rsa and id_rsa.pub on that directory
<spiv> I guess that's what the "((nil))" parts mean.
<zeroseven0183> Actually, the filename was originally idko and idko.pub
<zeroseven0183> then ran bzr branch lp:ubuntu-manual
 * fullermd blinks.
<spiv> You can set the filename in your .ssh/config.
<spiv> Not that there's much reason to use anything other than the default if you only have one key on that system.
<zeroseven0183> And now it's trying to fetch the revisions
<zeroseven0183> Yup
<spiv> Ah good.  Glad I could help!
<zeroseven0183> I think I can breathe now
<zeroseven0183> Sure
<zeroseven0183> Everyone who chatted with me here were very helpful
<zeroseven0183> What a learning experience
<zeroseven0183> Thank you very much, people
<spiv> Well, you've reminded me of some details of how to interpret ssh -vv output :)
<zeroseven0183> And now for the most exciting part of the day... LUNCH!
<zeroseven0183> I'm off now, guys
<zeroseven0183> Thank you very very much!
<zeroseven0183> You did very well in helping me
<zeroseven0183> See you around next time
<zeroseven0183> :-)
<mkanat> mwhudson: Okay, MP: https://code.launchpad.net/~mkanat/loggerhead/limit-pygments/+merge/23900
<mwhudson> mkanat: if (): looks like C :)
<mkanat> mwhudson: Oh, right. I'm sleepy. :-)
 * spiv -> lunch
 * man_in_work waves
<man_in_work> i'm trying to branch a bzr repo and i'm getting "No repository present"
<man_in_work> using command: bzr branch sftp://user@server/path/to/branch/
<man_in_work> /path/to/branch exists as an absolute path on the server, and includes a .bzr directory
<man_in_work> inside that, there is a file "branch-format", which reads: Bazaar-NG meta directory, format 1
<man_in_work> my bzr --version reads: Bazaar (bzr) 2.1.1
<fullermd> The whole output would be helpful.  Also an 'info' of that URL.
<man_in_work> bzr: ERROR: No repository present: "sftp://user@server/path/to/branch/"
<man_in_work> ^^ whole output
<man_in_work> what do you mean by info?
<fullermd> bzr info $URL
<man_in_work> same output
<fullermd> What all is in the .bzr?
<man_in_work> branch-lock, branch directories, branch-format and README files
<man_in_work> is bzr-ng a different tool to bzr 2.x?
<fullermd> bazaar-ng is bzr.  I'm not sure what bzr-ng is.
<fullermd> What about in /path/to and /path?  That doesn't list a repository.
<man_in_work> there is a .bzr in the 2nd-level directory in /path/to
<fullermd> Does the user have access to it?
<man_in_work> perms are 755 on directories and 644 on files
<man_in_work> so, yes
<fullermd> Well, bzr is telling you that for some reason it can't get its hands on it.
<fullermd> Maybe .bzr.log says something?  There's some -D flag to get it to tell more about what it's doing...
<fullermd> -Dsftp maybe?  Though I suspect that talks more about the interaction with sshd itself than the activity happening over it.
<fullermd> I thought there was a -Dtransport or something, but I don't see it in the docs.
<man_in_work>   File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 684, in find_repository
<man_in_work>     raise errors.NoRepositoryPresent(self)
<man_in_work> ^^ that's the end of the backtrace in the log
<fullermd> If you've got bzr on the server, bzr+ssh has some more options (and is a better all around choice anyway)
<fullermd> Yeah, but that doesn't tell us where it {was looking,had looked}.
<man_in_work> some smart fellow decided to use a bzr repo on a server that doesn't have bzr installed
<man_in_work> don't ask me why
<fullermd> Well, you could try pretending to be bzr.  Use sftp(1) yourself to go in as that user and poke around, make sure you can reach into the repo.
<fullermd> spiv: ^^ am I missing a -D option to tell what files it's trying to look up?
<man_in_work> don't see any problems
<man_in_work> with direct sftp access
<man_in_work> i don't see -D on the manpage anywhere
<man_in_work> is it a flag to bzr or to branch?
<fullermd> To bzr.
<fullermd> `bzr help debug-flags`
<poolie> igc, source is properly frozen now
<poolie> https://edge.launchpad.net/bzr/2.2/2.2b2
<fullermd> poolie: Oh, you're around to bug instead of spiv    :)
<igc> poolie: thanks. I'll check the installer builds now
<fullermd> poolie: Am I misremembering that there used to be a -Dtransport or the like?
<poolie> not for much longer  :)
<poolie> fullermd: there is log+sftp:// etc
<poolie> i would like a debug option that puts this onto all transports but i don't think it exists yet
<fullermd> Ooh, maybe that's what I'm trying to think of.
<fullermd> man_in_work: Try that  ^^^
<man_in_work> got some useful info
<man_in_work> No such file: '/path/to/branch/.bzr/checkout/format': [Errno 2] No such file
<fullermd> Probably irrelevant.  'branch' doesn't really do anything meaningful with that.
<man_in_work> what about repository/format?
<fullermd> That's more what we're be looking for.
<man_in_work> well, that also doesn't exist
<man_in_work> there's no repository directory
<man_in_work> i see a repository.backup in an ancestor directory's .bzr
<man_in_work> looks like someone's been screwing around
<man_in_work> fullermd: thanks for your help
<naoki> ping: vila
<vila> naoki: yeah ! pong
<naoki> vila: https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
<vila> naoki: yup, can you break it ?
<naoki> vila: bzr uses win32utils.get_unicode_argv. So bzr recieve args by unicode
<vila> naoki: meh
<bialix> _o/
<bialix> _o|
<bialix> _o/
<naoki> Please wait some minutes. (I'l
<naoki> I'll test your branch from now.
<naoki> I'm using Japanese WinXP.
<naoki> add new file in Chinese name. commit, and modify it.
<naoki> vila: http://paste.ubuntu.com/420255/
<naoki> This is your fix.
<vila> naoki: great, can you send me a tarball of the wt/branch/repo
<vila> what is cp932 ?
<naoki> Japanese codepage. It's Shift_JIS + some extra chars.
<vila> is the filename valid in this encoding ?
<naoki> No. It isn't.
<vila> then we have a far larger problem
<naoki> But I can add that file name from TortoiseBZR, qbzr, etc.
<naoki> Because bzr recieves args by unicode.
<bignose> I'm trying to convert a repository stored on a remote server to which I have only SSH and SFTP access; it doesn't have Bazaar installed.
<bignose> $ bzr check sftp://bzr@fs/~/
<bignose> Format RepositoryFormatKnit3() for sftp://bzr@fs/~/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<vila> naoki: from the command line ?
<bignose> $ bzr upgrade sftp://bzr@fs/~/
<bignose> bzr: ERROR: Cannot convert from format RepositoryFormatKnit3() to format RepositoryFormat2a().    Does not support nested trees
<bignose> am I correct in thinking that current Bazaar 2.1 should be able to convert any previous Bazaar repository format to 2a?
<bignose> if not, what are the limits? if so, why is this not working?
<naoki> vila: I'ts very difficult. I can't input chinese from keyboard. But I can copy&paste the filename.
<naoki> vila: I can do diff in cmd.exe http://paste.ubuntu.com/420255/
<maxb> bignose: Knit3 is dirstate-with-subtree, you can only convert it to other formats which also support -subtree. That's what the "Does not support nested trees" is about
<vila> naoki: 'bzr diff' alone works right ?
<naoki> vila: filename is broken. But others are all right.
<vila> naoki: I smell something wrong about bzr receiving unicode...
<vila> naoki: broken how ?
<vila> naoki: is GetCommandLineW documented somewhere ? My feeling is that this function handle the conversion from the input encoding to unicode
<naoki> vila: This is how to reproduce http://paste.ubuntu.com/420255/
<vila> naoki: well, almost, I don't have winmerge nor your branch :-/
<naoki> vila: No. On Windows, filenames and commandline arguments are unicode internally.
<naoki> vila: So, sys.argv is encoded string. Not original.
<vila> naoki: yes, in bzr too, yet there are encoded.edecoded at appropriate times
<vila> you mean decoded ?
<vila> python use decode to go from one encoding to unicode and encode to go from unicode to one encoding
<bignose> maxb: okay. so what current format could I convert this repository to?
<naoki> vila: I means Python's default sys.argv. It is from main(int argc, char *argv[]). And argv is encoded.
<naoki> (Python3's sys.argv is from main(int argc, wchar *argv[]). So it's native unicode)
<bignose> âbzr help current-formatsâ doesn't mention subtree anywhere in its list.
<bignose> is there any currently-supported format that supports subtree?
<vila> naoki: AFAIK you can't *type* unicode on the command line, you always use the user encoding *then* python decodes it into unicode
<naoki> vila: Windows command prompt is based on unicode. So I can use unicode on command line.
 * vila scratches head
<bignose> naoki: it's important to realise that âencoded stringâ is *not* Unicode. Those are two different data types.
<bignose> either you have an encoded string, which is not unicode
<naoki> vila: And win32utils.get_unicode_argv() recieves command line by unicode.
<bignose> or you have unicode, which is not an encoded string.
<bignose> you need to be clear about which you have at any given moment.
<vila> naoki:  win32utils.get_unicode_argv() relies on GetCommandLineW and I suspect the later handles the decoding, where is it documented ?
<naoki> vila: commandline is UTF-16 in Windows. GetCommandLineW gets the commandline without encoding/decoding.
 * vila blinks
<vila> naoki: there are several places in bzr where we use osutils.get_user_encoding() even on win32 (see win32utils), I'd really like to understand what is happening here
<vila> bialix: can you help here ?
<naoki> bzr uses that encoding when output to console.
<naoki> And then, console decode it to utf-16 and show.
<naoki> On windows API, everything is Unicode based. And encoded string is used for compatibility to ascii based application.
<vila> naoki: no, we use different encodings for: use, terminal and file system
<vila> http://stackoverflow.com/questions/846850/how-to-read-unicode-characters-from-command-line-arguments-in-python-on-windows seems to imply that GetCommandLineW is indeed decoding into unicode
<vila> naoki: i.e. the command-line itself is not in unicode, it's decoded by GetCommandLineW
<naoki> vila: GetCommandLineW doesn't decode anything. commmandline is unicode and GetCommandLineW pass it.
<vila> naoki: why does python needs GetCommandLineW then ?
<naoki> vila: sys.argv is **encoded** arguments. So it may be broken.
<naoki> vila: It is why we should use GetCommandLineW to get unicode arguments.
<vila> naoki: ok, so we disagree on that, you say the command line is unicode, I say it's encoded in user encoding, what code can you use to decide on that ?
<vila> naoki: 'sys.argv is **encoded**' by who ?
<vila> naoki: and how ? That's what we need to find to be able to replicate around subprocess.Popen
<naoki> vila: MSVCRT encode arguments and pass it to main()
<vila> naoki: then Popen most probably will do the same
<naoki> vila: Python3's subprocess module uses CreateProcessW. So it can pass unicode arguments to child process.
<naoki> vila: But Python2's subprocess can't handle unicode.
<vila> haaaaa, but we are stuck with python2 so far
<vila> naoki: can we trick it into accepting utf8 encoding ?
<naoki> vila: So, there are 2 ways: 1. Use CreateProcessW manually like GetCommandLineW.
<bialix> vila: on Windows command line is unicode
<naoki> vila: 2. replace chars that doesn't represent in user_encoding.
<vila> bialix: meh, when is the user encoding used then ?
<vila> naoki: 1) sounds better,
<bialix> vila: internal Windows API is unicode (functions end with W), but there is also ANSI API (functions end with A), under the hood A functions do encoding on the fly, IIUC
<vila> naoki: about 2) replacing chars means losing some info, what are we trynig to preserve here and can't we switch to a purely arbitrary name with ascii only chars ?
<bialix> python uses A
<bialix> I guess for Windows 98 compatibility
<MvG> Hi guys! I've just offered the bzr-bash-completion plugin for merging into bzr.dev, as distro packagers as well as users mostly prefer this over an independent plugin. https://code.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 open for comments. I'll be around.
<vila> bialix, naoki: Sorry to sound dense, but how to you guys can be sure that the command line is unicode ? The fact windows *internally* uses a unicode API doesn't guarantee that the command line itself doesn't respect the user encoding
<vila> otherwise what's the point of the user encoding ? Why do we use it in win32utils.get_appdata_location() for example ?
<bialix> vila: it depends on how program is launched
<vila> bialix: all right, let's focus to subprocess.Popen then since that's where the bug seems to be actually
<bialix> user encoding? what's wrong with user encoding?
<bialix> vila: subprocess.Popen can't use unicode API
<bialix> there is some code in subprocess.py explicitly disabled unicode on Windows.
<vila> bialix: nothing wrong with user encoding, my question is why do we use it to *decode* some data if it's already unicode ?
<bialix> vila: lemme look at get_appdata...blah-blah-blah
<bialix> vila: I don't see there user_encoding
<vila> naoki: to be clear, I'm not saying you're wrong, just that I don't understand the logic here :)
<vila> bialix: wtf
<bialix> vila: os.environ holds data as plain strings
<vila> bialix: oh, it's in the docstring
<bialix> Mark Hammond said it's actually should be 'mbcs' encoding
<vila> bialix: hmm, mbcs is the file system encoding right ?
<bialix> well, mbcs it's a ... mbcs!
<bialix> file system encoding depends on file system. AFAIK NTFS s unicode
<vila> bialix: ha, look at _ensure_unicode which call get_user_encoding
<bialix> I'm not quite understand internals of mbcs, but it's a very strange thing
<bialix> vila: yep
<bialix> vila: on my Russian system mbcs == cp1251
<bialix> cp1251 is also russian
<bialix> maybe on Japanese/Chinese systems mbcs means something different, I really don't know
<naoki> 'mbcs' is an alias. It is set by site.py
<bialix> I suspect something like that
<naoki> spawn is easier than CreateProcess: http://paste.ubuntu.com/420255/
<vila> naoki: I just pushed a new revision (forcing mbcs for subprocess.Popen), can you re-try
<vila> naoki: that's still the same url you've been pasting for the third time, is this intended ?
<naoki> miss. http://paste.ubuntu.com/420272/
<vila> naoki: that one is about spawn
<naoki> spawnw uses unicode.
<naoki> So I think we can use it instead of subprocess.call
<naoki> AFK, sorry.
<vila> naoki: you mean _wspanlp uses unicode, ok, but what was 'miss' referring to ?
<lifeless> its kindof sad shutting down my persistent IRC server
<spiv> Heh.
<spiv> Try to think of it as liberating!
<lifeless> sure
 * lifeless tries
<spiv> Just etch "/win" on your glasses and you won't miss a thing.
<lifeless> rotfl
 * igc dinner
<naoki> I'm back.
<naoki> http://paste.ubuntu.com/420312/
<naoki> I find that subprocess can use pywin32's CreateProcess.
<naoki> I confirm that changeing if 0: => if 1: fixes this problem.
<naoki> So, win32utils can replace some subprocess attributes with pywin32.
<naoki> Or, we can just copy subprocess.py into bzrlib and fix that.
<cbz> When i have a branch inside a repository, and i've deleted branches inside that shared repository, is there a way of getting that repository t throw away the stuff it doesn't need any more?
<AfC> cbz: the bullet-proof way is to make a new repository, branch the branches you like from under the old repository to locations within the new one, then ta-da, remove the old repository & all its branches.
<AfC> cbz: there is a "garbage collector" floating around somewhere, too
<cbz> Okay. If I choose the first option, is bazaar able to work out the rlationships between the branches and store things effectively?
<spiv> Yes.
<cbz> I assumed the shared repository only really worked because you were branching within it, and so bazaar kept track of the relationships between versions that way
<spiv> Even if you branch from somewhere outside the shared repo into the shared repo, bazaar will avoid storing duplicate records.
<cbz> Okay.
<spiv> (Mostly; the small amount of redundancy that can occur will be continually tidied up by the regular autopacking that occurs as new data is added to a repo.)
<MvG> I assume that branching everything over into a new repo will still loose non-versioned data like parent branches, push branches, merge branches and so on, right?
<AfC> MvG: yes
<AfC> (good point)
<cbz> so the best thing is probably to get to the point where every project has one branch and then just branch that to the new location and then rebind?
<cbz> (I'm tracking remote subversion repositories)
<MvG> Copying .bzr/branch/branch.conf files might work as well.
<MvG> I'd suggest one repo per project in any case, as there is little point in sharing a repo between branches with no common history.
<MvG> lifeless: are you around?
<vila> naoki: sorry, just noticed you're back
<vila> naoki: yeah, I've seen the if 0 in subprocess too, since that's part of python standard lib, it's... a problem to touch it, and I thought you said we needed CreateProcessW not CreateProcess (whatever the correct spelling is)
<naoki> pywin's CreateProcess uses CreateProcessW
<vila> naoki: re-reading your patch, I see you also use 'mbcs' encoding so my last patch should work no ? (the tests should fail though)
<lifeless> MvG: a little; last stages of house packup before moving country
<MvG> lifeless: You're moving, too? Funny, I'm amidst boxes as well.
<MvG> lifeless: Anyway, I was wondering whether you could review https://code.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 as you reviewed its predecessor.
<naoki> vila: Maybe, getfilesystemencoding() is better on non-win32
<lifeless> MvG: realistically, not until tuesday/wednesday
<naoki> vila: because _subprocess module uses filesystemencoding.
<lifeless> MvG: has vila reviewed it ?
<vila> naoki: no, getfilesystemencoding should be used only when dealing with file system directly
<lifeless> naoki: python trunk using fsencoding for subprocess module on win32
<lifeless> fwiw
<MvG> lifeless: Yes, he has, and I'v eadded some buts of documentation and minor style fixes in response.
<vila> lifeless: I did, but it needs a second review
<lifeless> vila: can you mention it to John then ?
<lifeless> MvG: in 12 hours a team of packers arrives to pack - a drop-dead deadline ;)
<lifeless> we've still got ~ 3 cubic metres of recycling and landfile to deal with and other similar things
<lifeless> or I'd be delighted to review it for you
<MvG> lifeless: I understand. I've got more like 44h before I've got to start loading things.
<naoki> lifeless: I'm wrong. not _subprocess. posixmodule.execv uses Py_FileSystemDefaultEncoding
<MvG> There is no real urgent need, but I'd like to get stuff off my head nevertheless, so I'm bugging people to review my requests.
<naoki> So, subprocess.call in posix uses filesystem encoding if it is available.
<naoki> But I think there are no need to encode by hand on non-win32 platform
<lifeless> vila: alternatively you could make a call that its small enough vs the predecessor and just land it
<lifeless> if the predecessor had 2 conditional +1s
<naoki> This is a monkey patch to force subprocess uses pywin32's CreateProcess http://paste.ubuntu.com/420337/
<vila> lifeless: it didn't, you're the only one that has reviewed it
<lifeless> ah
<lifeless> well if you can point John at it, it would be good to get MvG the feedback he needs
<lifeless> MvG: if I can, I will, but I'd like to make other primary arrangemetns for you
<MvG> lifeless: Thanks!
<vila> lifeless: what is the status of pqm at this hour ?
<lifeless> vila: it should be working
<lifeless> vila: its generally landing things that should land, and we ahven't had it blow up for bzr today, at all
<a`> DCC SEND "XXXXXXXXXXXXXXXXXXXXXXXXXX" 0 0 0
<LeoNerd> *slow handclap*
<vila> naoki: brr, monkey-patching such a large part without any tests is scary
<vila> naoki: :-(
<vila> naoki: I feel I'm not helping as I should here, maybe I should just decline to review this patch, I miss some windows knowledge to be really effective I'm afraid :-(
<cbz> whats the equivalent of hg incoming on bazaar?
<spiv> bzr missing
<spiv> Hmm, "bzr missing --theirs-only" is probably a more exact equivalent.
<lifeless> vila: its generally landing things that should land, and we ahven't had it blow up for bzr today, at all
<vila> lifeless: I did a pqm-submit ~30 minutes ago and it doesn't seem to be processed so far :-/
<maxb> Can I suppress bzr's default ignore patterns on a per-branch basis?
<lifeless> maxb: you can use negative matches, or edit your ~/.bazaar/ignores
<lifeless> maxb: bzr doesn't have any hard coded defaults at all
<lifeless> maxb: instead it writes to ~/.bazar/ignores, IFF it does not exist
<lifeless> oh yay, firefox fail just lost one windows worth of tabs ><
<vila> lifeless: look into history -> Recently closed {tabs|windows}
<vila> lifeless: should I ping a losa for pqm, it seems stucked to me
<vila> lifeless: what did change from yesterday ?
<lifeless> vila: untangled stdout, stderr
<lifeless> vila: it looks like it thinkgs it just finished aaron's merge
<lifeless> PQM is not currently processing additional requests
<lifeless> it has a stop.patch present
<vila> lifeless: ha yes, the patch you mentioned, so how was that last submission ... yeah, but that was long ago no ?
<lifeless> losa ping: please remove stop.patch from bzr's pqm queue
<vila> >-/
<MvG> Some bzr selftests related to pycurl seem to fail when curl is built against GnuTLS.
<MvG> Is this known, or should I report a bug?
<james_w> I've not seen a bug on it
<MvG> OK, then I'll report once my selftest is through and I can actually scroll around and mark the whole message without the progress bar update interfering.
<vila> MvG: that rings a bell, any more info ?
<vila> I seem to remember some certificate issues around that but that's from some years ago
<MvG> vila: got pycurl error: 56, GnuTLS recv error (-9): A TLS packet with unexpected length was received., (56, 'GnuTLS recv error (-9): A TLS packet with unexpected length was received.')
<vila> MvG: hmm, so that's a CURLE_RECV_ERROR that we are supposed to trap and raise errors.ConnectionReset
<vila> MvG: does that help ?
<MvG> Not immediately.
<vila> MvG: and what is your context (why GnuTLS) ?
<MvG> Because I can.
<vila> LOL
<MvG> Using Gentoo Linux, and been using GnuTLS for a while for most apps that support it.
<MvG> It's caused problems before, but usually it's because apps depend on things they shouldn't.
<vila> ha, gentoo, that's the keyword I wanted :)
<vila> Any LOSA around ?
<vila> LOSa LOsa Losa losa one of them should match ;)
<MvG> vila: http://paste.ubuntu.com/420380/ has the selftest output.
<vila> MvG: So, at first glance, I'd say GnuTLS is lying or reporting things in a strange way, the test is about an unknown file, so we expect a 404
<MvG> Who is implementing the https server? Where is the certificate private key? Maybe I can snoop on the traffic to shed some light.
<vila> MvG: look at bzrlib/tests/https_server.py and...
<vila> MvG: into bzrlib/tests/ssl_certs
<vila> MvG: now, that's a self-signed certificate and maybe GnuTLS barfs on that
<MvG> vila: Shouldn't, but I'll have a look.
<MvG> After lunch...
<vila> oooh, lunch, 14:00 good idea !
<Chex> vila: good morning there
<vila> Chex: Yeah ! Hi !
<vila> Chex: previously on this channel: <lifeless> losa ping: please remove stop.patch from bzr's pqm queue
<vila> Chex: don't ask me what it means, except that it seems to be involved in pqm being currently stucked
<Chex> vila: i understand, fixing now
<Chex> vila: removed, should be able to process now
<vila> Chex: thanks
<Chex> vila: no worries
<SamB_web> hmm, there's something wrong with the wiki ... see http://wiki.bazaar.canonical.com/HelpOnMoinWikiSyntax#Smileys%20and%20Icons
<siks> 7away gone
<siks> whoops
<vila> SamB_web: it's a wiki, just update it... err wait
<vila> SamB_web: It's a serious wiki who needs simleys ???
<vila> SamB_web: seriously, just file a bug :)
<[1]reggie> hey gang
<[1]reggie> any idea what would be keeping bzr 2.0.4 qcomit from sending commit emails when used inside virtualbox on windows 7 x64?
<[1]reggie> works fine on host machine
<jave> I'm trying to clone a branch from launchpad, but nothing seems to happen
<michaelforrest> what's the quickest way to get the last revision any particular file changed?
<vila> michaelforrest: bzr qblame file
<michaelforrest> vila: is there any way to get more of a concise output do you know? I just want the number
<michaelforrest> bzr [?] file.png
<michaelforrest> > 14
<vila> no
<vila> well, not that concise
<michaelforrest> I'm trying to see where the source browsing bit of launchpad gets it
<james_w> bzr log file.png?
<james_w> bzr log file.png --limit 1
<michaelforrest> limit 1 isn't too bad
<michaelforrest> or if I could get a list of all the files in a repo / folder with their last-updated revnos
<vila> michaelforrest: what's the use case ?
<michaelforrest> vila: quite complicated :S
<michaelforrest> I am making a website that pulls files from a repository and I want it to show the last revision number of each file
<vila> michaelforrest: nothing available from the command-line for that, but if you cmd_inventory in bzrlib.builtins.py should be a good starting point
<vila> s/you/& look at/
<krisives-gearbox> michaelforrest: I just made an update system with Bazaar that keeps 90 client sites in sync
<krisives-gearbox> bzr revno file would work, right?
<krisives-gearbox> I do: `bzr revno `bzr ls -VR`` kinda (but for TAR)
<michaelforrest> krisives-gearbox: that's what I thought it would be yeah
<michaelforrest> but it doesn't seem to work for me
<krisives-gearbox> What are you executing / getting in response?
<michaelforrest> well - yeah - it doesn't give a file-specific revno
<krisives-gearbox> Ah indeed `bzr revno` only gives the branch version, my bad
<jam> krisives-gearbox: 'bzr revision-info --tree' might be what you want
<krisives-gearbox> jam, that's for michaelforrest
<mkanat> igc: I actually need somebody to do my merges; I'm not in the appropriate group, I'm pretty sure.
<mkanat> igc: (This is in relation to the loggerhead pygments fix.)
<jam> mkanat: can you link me to the merge proposal, I can do it
<mkanat> jam: Sure.
<mkanat> jam: https://code.edge.launchpad.net/~mkanat/loggerhead/limit-pygments/+merge/23900
<mkanat> jam: It probably also needs a status update.
<jam> mkanat: just a thought, why map(cgi.escape) rather than cgi.escape(text).split() ?
<jam> so it doesn't escape the '\n' ?
<jam> and doesn't text.split('\n') strip the final \n ?
<mkanat> jam: That's how loggerhead does it currently.
<mkanat> jam: Outside of this code. I don't think it would matter, though.
<mkanat> jam: I could do it the other way--it'd probably be slightly faster.
<jam> mkanat: I don't know the details of cgi.escape
<jam> so either way
<mkanat> jam: Nor do I, I was cargo-culting because I wanted to maintain exact behavior.
<jam> if you've tested this way, then I think it is worth just landing, can be tweaked later
<mkanat> jam: Okay.
<jam> ah, you know what... I *don't* have access rights
<jam> I thought I did, but the commit failed
<mkanat> jam: Ah, okay. I'll wait for mwhudson or igc.
<jam> oh well, we'll poke igc for it tonight :)
<chx> given the state of the bundle buggy I am not exactly sure i want to use it. is there another merge tool for the human gatekeeper workflow?
<mkanat> I imagine spm will want to update codebrowse after we commit it, too.
<MFen> hello
<MFen> someone gave me this page/branch to look at .. https://code.launchpad.net/~washort/pymeta/matched-sequences
<MFen> dash gave it to me actually. maybe he can answer :)
<MFen> what's an easy way to diff that against the branch it's derived from
<dash> MFen: hi again :)
<MFen> howdy
<dash> the general answer is that you can use "ancestor:somebranchurl" as a revision specifier
<dash> to indicate the revision where the current branch diverged from the ancestor
<dash> so in this case:
<MFen> so hg diff -rancestor:lp:pymeta
<dash> bzr diff -rancestor:lp:pymeta lp:~washort/pymeta/matched-sequences
<MFen> err bzr
<dash> right. you can leave the second url off if you're doing it froma working copy. :)
<MFen> aha. that worked. thanks :)
<cbz> anyone else using bzr-svn to use bazaar with a subversion repository?
<dash> cbz: every day
<jam> igc: are you around?
<igc> morning
<igc> hi jam
<jam> morning igc
<jam> just wanted to discuss some of the loggerhead changes I want to do
<jam> igc: I don't have a lot of time, but if you have 5-10 minutes could we chat?
<igc> jam: that would be great
<igc> jam: irc or skype?
<jam> skype might be the fastest
<igc> jam: cool. I'm on
<jam> not according to my skype
#bzr 2010-04-23
<mwhudson> jam: i wonder if we should just add ~bzr to ~loggerhead-team ?
<mwhudson> dunno what implications that would have for mail spam
<spiv> It's great having so many contributors, but why are so many of them named Martin?
<mwhudson> or at the very least M*
<mwhudson> jelmer: hey
<mwhudson> jelmer: want to fix https://bugs.edge.launchpad.net/bzr-svn/+bug/525571 ?
<ubottu> Ubuntu bug 525571 in bzr-svn "bzr svn-import fails when invoked concurrently" [Medium,Triaged]
 * mwhudson adds affects launchpad-code
<poolie> good morning
<lifeless> poolie: hey
<lifeless> poolie: its like a bombshell went off here :P
<poolie> oh, meaning your house, not the channel :)
<lifeless> yes!
<mlh> you packing ... or unpacking?
<spiv> I believe his home repository is being packed *and* garbage-collected.
<fullermd> Both of them are such a pain.  That's why I have stuff still packed from a decade+ ago.
<mlh> eek.  indeed.
<mlh> same.
<mkanat> spm: The fix for bug 513044 is committed now, so you might want to update codebrowse.
<ubottu> Launchpad bug 513044 in loggerhead "loggerhead (codebrowse) hangs occasionally on launchpad" [Critical,Fix committed] https://launchpad.net/bugs/513044
<poolie> spiv :)
<spm> mkanat: I shall draw the attention of those who can make that call :-)
<mkanat> spm: Okay. :-)
<igc> hi poolie, spiv, spm, mkanat, lifeless, fullermd
<spm> hey there igc!
<mkanat> Hey igc. :-)
 * fullermd waves at igc.
<igc> mkanat: thanks for the patch for 513044
<mkanat> igc: Yeah, welcome. :-)
<igc> mkanat: well done on tracking that down!
<mkanat> igc: Thanks. It was several months of work, and yesterday alone, seven hours of log anaylsis.
<igc> mkanat: btw, the production branch is lp:~loggerhead-pqm/loggerhead/devel, not the trunk per se
<mkanat> igc: Ah, okay.
<igc> mkanat: so I'll find out from mwhudson and/or lifeless as to how best get it merged there
<mkanat> igc: Okay.
<mkanat> igc: Next I'm on to bug 420738.
<ubottu> Launchpad bug 420738 in loggerhead "LRUCache.cleanup raises KeyError" [Critical,Confirmed] https://launchpad.net/bugs/420738
<igc> mkanat: cool
<mkanat> Why does loggerhead possibly instantiate the graph_cache in four or five places?
<igc> mkanat: I haven't looked into the caching yet but jam has studied it in some detail. Try and catch him to chat about his plans for making it better
<mkanat> Okay.
<chrispitzer> do I want to roll back to a commit someone else made.  it's 21.1.191 ... how do I do that...?
<chrispitzer> i think I should be able to just "bzr checkout -r 21.1.191" ...but that doesn't work...
<chrispitzer> s/do/so/
<fullermd> What do you mean by "roll back"?
<fullermd> Do you want to just make a new rev reversing the change, or do you want to excise it totally from the history?
<spiv> chrispitzer: depending on exactly what you mean by "roll back" you probably want either "bzr revert -r ..." or "bzr update -r ..."
<spiv> fullermd: it could also mean "give me a working tree at that rev so I can look at it etc"
<fullermd> Oh, I missed the "to".
<fullermd> Yes, 'update -r' is probably the answer.
<chrispitzer> spiv: thanks
<mkanat> Does bzr or loggerhead already have some sort of ReadWriteLock implementation?
<poolie> in memory or on disk?
<mkanat> poolie: In memory.
<mkanat> poolie: Like a threading.Lock sort of lock.
<poolie> between threads?
<poolie> not in bzrlib afaik
<poolie> could look at countedloc
<poolie> lock*
<mkanat> poolie: Yeah, in bzrlib.
<mkanat> poolie: Oh, that looks like it might do what I need.
<poolie> you'll need to tell it to stack on a threading lock
<mkanat> poolie: Yeah.
<poolie> probabyl not hard
<mkanat> poolie: Thanks. :-)
<lifeless> home server powered off; internet going soon. noooo.
<igc> have a good trip lifeless
 * fullermd steals all the internet and holds it for ransom.
 * igc out for a few hours
<lifeless> igc: thanks
<lifeless> fullermd: just hold onto the porn for me
<mkanat> poolie: Okay, yeah, counted_lock isn't going to do what I need. :-(
<mkanat> poolie: It requires underlying locks that can already do read/write locks.
<lifeless> mkanat: wht do you need ?
<mkanat> lifeless: I need a ReadWriteLock for threads.
<mkanat> lifeless: I need to synchronize access to an lru_cache.
<lifeless> to avoid confusion
<lifeless> I'd like you to describe that that means to you
<mkanat> lifeless: Infinite numbers of threads can read the data structure at once, but only one can write, and if one is writing, none can read.
<lifeless> mkanat: reading mutates it
<mkanat> lifeless: Oh really?
<mkanat> Well, that sucks for me.
<lifeless> mkanat: I'm not at all sure that reading is safe across N threads
<lifeless> mkanat: yes, its a lrU cache
<mkanat> Ah, right.
<mkanat> Okay. Well, I guess I can put a dumb lock on it and see how bad performance gets.
<mwhudson> it'll probably be ok, i don't think anything should hold the lock for too long
<lifeless> mkanat: we have a similar situation in chk_map
<lifeless> mkanat: I would copy what we do there, for protecting the lru cache it has
<mkanat> mwhudson: Yeah, but actually acquiring and releasing locks takes time.
<lifeless> mkanat: no time at all compared to python :P
<mkanat> lifeless: Okay, I'll take a look.
<lifeless> seriously, python's write-on-read behaviour is hugely destructive of performance
<mwhudson> mkanat: btw, https://code.edge.launchpad.net/~vcs-imports/bugzilla/main is a cvs import and still lp:bugzilla
<mwhudson> mkanat: that's a bit stale, right?
<lifeless>  I wouldn't worry at all about using locks; the python locking primitive on linux hits the futex code paths
<mkanat> mwhudson: Yeah, but if we replaced it, it would break file ids.
<mkanat> mwhudson: For anybody who checked out from it.
<mwhudson> mkanat: yeah
<Kilroo> I'm having an interesting time trying to figure out what DVCS is going to be the best choice for me to push for at work.
<spiv> It seems "no valid commands given" is the new way PQM mails me to say "success".
<mkanat> lifeless: Oh, I see, you used threading.local().
<mkanat> lifeless: That wouldn't work for us; we definitely need threads to share the cache. I'll just use an RLock.
<Kilroo> Based on my research up to this point, it's starting to look like it comes down to a face-off between the superiority of HgEclipse to either of the Eclipse plugins for bzr against bzr-svn's advantages over HgSubversion...and if I could get the powers that be to reconsider whether svn is the best choice, that might make mercurial the unchallenged frontrunner.
<lifeless> mkanat: oh I forgot we did that ;P
<Kilroo> ...I really oughta learn python and java and try to contribute to bzr-eclipse.
<spiv> Kilroo: that'd be wonderful :)
<Kilroo> spiv: Indeed it would, unfortunately it is not something I consider especially likely to happen. I don't get to work on projects I like often enough at work to have the programming energy to feel like doing any more once I get home.
<Kilroo> If I did, I would have actually attempted to get Lua web applications to work on Google App Engine via LuaJ by now.
<Kilroo> It's a shame Codebeamer picked Hg over bzr in that respect. Apparently they pretty much decided HgEclipse wasn't good enough yet and they were gonna do something about it.
<Kilroo> Based on what I've read, that seems to have taken Mercurial's Eclipse plugin from -arguably- the best (out of hg, bzr, and git) to almost -inarguably- the best, and they seem to be planning on both improving it further and adding a Mylyn team support plugin for it by...I think the end of June.
<Kilroo> bzr is still my favorite of the three, but the fact that bzr makes you jump through the fewest hoops to work with subversion is the only one of its advantages that I currently see as beinga significant factor in the ease of adoption by the rest of the team.
<Kilroo> I'm gonna stop yacking about it now though.
<Kilroo> At least here.
<mkanat> igc: Okay, I just submitted an MP that should do it.
<mkanat> igc: That would close the last Critical bug in Loggerhead; would be nice. :-)
<jbowtie> Is there doco for PQM anywhere?  I see odd mentions of it but no actual details.
<jbowtie> Sorry, lapsed into slang - by "doco" I mean "documentation".
<spiv> jbowtie: I don't know of any beyond what is in the tarball.  The README file gives a terse overview.
<spiv> jbowtie: you may also be interested in the bzr-pqm plugin for bzr, which adds a "bzr pqm-submit" command.
<jbowtie> spiv: I'll have a look in there, then. I want to figure out whether or not I want to try setting one up for my project or not, but I'm not even sure what it does.
<spiv> jbowtie: it automates "checkout $trunk; merge $proposed_branch; run pre-commit checks (e.g. test suite); commit"
<spiv> jbowtie: so for Bazaar, none of the developers has direct access to the trunk or release branches.  Instead we instruct PQM (currently via the email interface) to merge changes on our behalf, and it will run our test suite and only allow commit changes that pass the test suite.
<jbowtie> spiv: OK, that's helpful to know. It does sound like the sort of thing I'd want to hook to our continuous integration server.
<spiv> Yeah, we find it very useful.  It's great to be able to trust that trunk is very likely to be in a sound, probably even releaseable, state.  (Depending on the effectiveness of your test suite, of course.)
<spiv> The other common approach is to use something like buildbot to find out after the commit happened that something broke.  You can combine the two approaches as well (e.g. pre-commit test on one platform, post-commit monitor the buildbot for all the other interesting platforms.)
<GungaDin> Is there a way to create a branch and push it at the same time?
<spiv> Do you mean create locally or create remotely?
<GungaDin> create remotely so I can check it out locally
<GungaDin> 'cuz right now I branch locally, push, delete and checkout
<spiv> You could branch remotely: "bzr branch local_branch remote_url", then check that out.
<GungaDin> ah cool
<GungaDin> thx
<spiv> Or convert the branch you made locally into a bound branch/checkout rather than delete it and recreate it as a checkout.
<spiv> e.g. bzr reconfigure --checkout
<GungaDin> cool
<GungaDin> thx
<igc> back
<eydaimon> how I can see what files are kept under control?
<mwhudson> eydaimon: not sure what you mean, maybe bzr ls --versioned --recursive ?
<eydaimon> yes, that works, thank you
<eydaimon> (mercurial has hg locate)
<vila> hi all
 * fullermd waves vila around.
<vila> _0/
<parthm> trunk seems to be missing tag for 2.2b2. should the tag be in place?
<parthm> as per NEWS 2.2b2 was on 2010-04-16
<cbz> dash: do you find you have to do a rebase rather than a pull in order to avoid blatting svn's history/blame?
<millun> what should i do to export stuff ?
<millun> branch?
<LeoNerd> Or   bzr export   perhaps?
<jannn> Hey. Is it somehow possible to clone a complete repository with all its branches without having to find out / specify each branch individualy?
<maxb> no (bug 316729)
<ubottu> Launchpad bug 316729 in bzr "bzr clone should be able to clone a repo, not just be an alias to branch" [Wishlist,Confirmed] https://launchpad.net/bugs/316729
<fullermd> Not as such.  I think there are some plugins that automate the find/specify-individually process, but that just hides it from you.
<mkanat> jannn: Although you could use rsync.
<fullermd> Of course there are options like rsync/cp/tar/etc.
<mkanat> jannn: But that might be troublesome if it changes mid-stream.
<jannn> ok, thanks for the comprehensive answers :)
<laurenty> hey guys
<laurenty> coming from svn, bzr looks really cool, but also kinda confusing...
<LeoNerd> Really? It's supposed to look-and-feel really really similar
<LeoNerd> bzr co URL; bzr di -r123; bzr ci -m "Here are my changes"; ...
<maxb> laurenty: Any elements in particular you're having trouble with?
<maxb> LeoNerd: Yesssss.... but only if you stick exclusively to the bound-branch workflow, and even then, branching is quite different
<laurenty> LeoNerd: yes a lot of the stuff is very similar, but the distributed repository stuff can get confusing when you're used to having a central repo
<LeoNerd> Ahyes
<laurenty> maxb: pull, push, bind, merge...
<laurenty> svn had merge that was it
<maxb> Perhaps you should start with some tutorials: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/index.html
<laurenty> maxb: I read the 5 minute version, I'll have to spend some time with the full tutorial
<vila> and some basic vocabulary: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<rephormat> greetings fellow coders
<rephormat> How is everyone doing this afternoon?
<damiro> can anyone help me with the following error message: "aborting commit write group: MemoryError()" and next line was "bzr: out of memory". this happened on a local initial commit with many files. the project is about 2 GB with some larger binary files.
<ikus060> Hi, I'm evaluating Bazaar and have a quick question. I'm wondering is the .bzr directory will grow as I add more file in the repository and if yes, how much ?
<ikus060> I'm concern because with SVN, the .svn directory contain a copy of the original file. So it's double the space required on the disk.
<damiro> hi.. i'm also new to bzr. but afaik the directory will grow on commits
<damiro> for each change a delta will be stored
<ikus060> the delta is stored locally in .bzr directory ?
<damiro> look at http://doc.bazaar.canonical.com/bzr-0.9/tutorial.html
<damiro> chapter "creating branch"
<ikus060> damiro : I know how to create a branch. It's not the point. I'm questioning the internal of bazaar
<ikus060> whats does .bzr directory contains ?
<rephormat> What do you mean what does it contain?
<damiro> hmmm.  it seems to be the only place that will be used for all data
<damiro> but i'm not sure about that
<damiro> i seems we are currently the only ones who are active here...
<damiro> i found this: http://ddaa.net/blog/bzr/repository-branch-tree
<rephormat> nice find damiro
<ikus060> Hi, I want to know is bazaar can handle a 20Gig repository
<Peng> Um. Maybe. Having a good 20 GB of RAM would help.
<ikus060> What ?!
<Peng> Bazaar likes to hold entire copies of things in memory.
<ikus060> ouch
<mkanat> Peng: Sometimes three or four copies of them.
<Peng> Yah.
<Peng> You should need your largest file * 2 or 3.
<Peng> mkanat: Recent releases with 2a repos are better than that.
<mkanat> Peng: For most things, yeah. I think annotate is still bad.
<Peng> A 20 GB repository created by tons of branches with small files should be fine, though, except maybe if it needs to do a large pack (or, god forbid, reconcile).
<Peng> mkanat: Eh. Who uses that? :P
<ikus060> Peng : Do you have another VCS to recommend me If I want to manage a big repository of 20Gig
<mkanat> Peng: Hahahaha. This funny little program called "loggerhead", mostly. :-)
<ikus060> As an example. One branch is 20Gig
<Peng> :D
<mkanat> ikus060: What's so large? Do you have a lot of binary files in it?
<Peng> ikus060: Sorry, I don't. The awful, obtuse proprietary ones are the best at it, but I don't know a thing abotu them.
<ikus060> mkanat : I have a lot of stuff including binary, xml, text, java and others
<mkanat> ikus060: In some ways, bzr is going to be really good for you, because you're going to get a lot of disk-space savings from the repository system.
<mkanat> ikus060: I think that in terms of handling large binary objects, though, bzr still needs improvement, last time I heard anything about it.
<ikus060> mkanat : ok .. but I will run out of memory ?
<mkanat> ikus060: Well, what's the largest single file?
<mkanat> ikus060: (In the whole branch's history, not just in the current tip.)
<ikus060> the largest file is binary 12Gig
<mkanat> ikus060: Yes, you will run out of memory.
<ikus060> :S
<mkanat> ikus060: But I do have to ask--why are you storing a 12G binary in your VCS?
<ikus060> will have a look at Git than
<ikus060> mkanat : You should ask my CBC
<mkanat> ikus060: You do realize that in most VCSes, every time you revision that 12G binary, your repository will grow by 12G?
<rephormat> eww...
<mkanat> Unless they have a binary delta algorithm and store binary deltas.
<ikus060> mkanat : we currectly use ClearCase (IBM product)
<ikus060> ans it's not a problem
<ikus060> *and
<xnox> I'm a bit crazy tonight. I just had a thought. Brisbane-core is nice and all that but git-blobs are still more efficient spacewise. Does it make sence to create yet another git native format based on git-blobs with additional revprops and file-ids we use?
<xnox> Or will that not fit into bzr model?
<Peng> xnox: See what bzr-git + dulwich do.
<Peng> xnox: I don't think git is always more efficient.
<Peng> 90% of the time, but... :D
<xnox> Peng, I use that but it still feels slow. Cause I think there is still roundtrip to foreign
<xnox> Peng, well have you tried branching lp:gcc or lp:emacs?
<Peng> xnox: God no.
<xnox> Peng, well downloading packs is fine
<Peng> Actually, I think I have emacs somewhere.
<xnox> but it takes ages to build working tree
<xnox> (well in lp:gcc anyhow)
<xnox> where is git-svn clone is two eye blinks to get working tree
<Peng> Would git's format help with that?
<xnox> I don't know. I would think so. Although I think the bottleneck is the inventory / file-ids extraction
<xnox> cause during lp:gcc tree checkout it was looping at 100% CPU and generating inventory / file-id list
<xnox> maybe that's why git is fast since it doesn't track file-ids at all
<Peng> I imagine there are lots of reasons git is fast.
<Peng> Which mostly center around it being written in C by really clever people/
<xnox> Peng, well kernel hackers are out-of this world people ;-) who really do know their C =)
<Peng> And who really know how to get the best performance on Linux.
<damiro> can anyone help me with the following error message: "aborting commit write group: MemoryError()" and next line was "bzr: out of memory". this happened on a local initial commit with many files. the project is about 2 GB with some larger binary files.
<Peng> damiro: There's not much to say. How much RAM do you have? What version of bzr? What repo format?
<damiro> on a winxp32 box 4GB ram, version is latest stable, format is default
<Peng> damiro: Which version is that?
<xnox> damiro, there was a bug about that. And a switch / flag to limit the memory usage
<damiro> v2.1.1, i don't used any flags like this
<xnox> Bug #109114
<ubottu> Launchpad bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Medium,Confirmed] https://launchpad.net/bugs/109114
<damiro> ahhh... thanks :-)
<xnox> damiro, your welcome although it doesn't solve the problem =)
<xnox> I would suggest to use multiple commits to get your tree
<xnox> and then create a new branch and do
<xnox> $ bzr merge --force ../incremental-commits-branch
<xnox> that way in this new branch you will have just revno 1 - [merge] initial commit
<xnox> this way your history will look clean ;-)
<damiro> ok, sounds good. i will try it out.
#bzr 2010-04-24
<ScislaC> I have a branch I committed and pushed to not knowing a change happened prior to committing (I almost always do a pull prior to the process, but forgot to this time). Anyway, I did a bzr revert, it got my local copy mostly back in shape, but it's trying to force me to do a merge. Is that trying to do it locally or on lp?
<ScislaC> Okay... apparently the push went into limbo and I could uncommit and then push.
<magcius> huh
<magcius> I just spent 20 minutes trying to understand why it wasn't pulling new revisions when I figured out that it doesn't track when the "lp:foobar" shortname updates
<magcius> is there any reason why bzr couldn't, when I say, "bzr get lp:mything", store the literal "lp:mything", and not the resolved URL?
<thumper> magcius: i think there is a bug somewhere for that
<thumper> magcius: I think it should record locally both the translated and untranslated path
<thumper> magcius: that way bzr could give you some more meaningful error messages
<magcius> thumper: there's some other problems with bzr I have.
<thumper> magcius: ask and maybe I can help
<magcius> thumper: one is the progress bar. I was trying to branch a repo, and it was stuck on what looked like 0% for the longest time
<Peng_> Or we can dismiss you completely, but at least you tried. :D
<magcius> thumper: and it had this large number "1546588" but no end goal
<magcius> thumper: this wasn't a Launchpad repo
<Peng_> magcius: One situation that causes is that is known/in progress/fixed. Not sure which.
<Peng_> magcius: Uh, dunno about the large number, tho.
<thumper> magcius: a local repo?
<magcius> thumper: Savannah
<thumper> magcius: ah
<thumper> magcius: as far as I'm aware, Savannah doesn't yet have a smart server
<thumper> magcius: so it is using a dumb network transport
<magcius> thumper: why do you need a smart server?
<thumper> magcius: I know that they are looking into this
<Peng_> magcius: So performance doesn't suck.
<magcius> thumper: shouldn't Content-Length be all you need?
<thumper> magcius: you don't need one, but it makes it much faster
<magcius> thumper: alright
<thumper> magcius: the way that the 2a format works makes it pretty inefficient over dumb network transports
<magcius> thumper: another: I tried to do "bzr up" (was still in svn mode) and it said "Tree is up to date." until I realized I was supposed to pull
<magcius> thumper: I think "bzr up" with no arguments, if up to date, should say "(maybe you meant to bzr pull?)"
<magcius> or something similar
<thumper> magcius: for a bound branch that makes sense
<magcius> thumper: okay
<magcius> and the last three gripes I have are all Loggerhead ones
<Peng_> Heh.
<thumper> magcius: have you filed the gripes as bugs on lp:loggerhead?
<magcius> thumper: not yet
<magcius> one, please put a lefthand margin on the code viewer. It's impossible to read code with no indentation levels
<thumper> magcius: please do, we are starting to get some more traction on loggerhead
<magcius> thumper: I will
<magcius> two, please don't put ":" in your URLs. They make this horrible "%3F"
<Peng_> Heh.
<Peng_> I forget, where is that done?
<magcius> and for some reason, Loggerhead doesn't handle the double encoding that some awful browsers do which turn "%3F" in a URL into "%253F"
<magcius> So it's impossible to paste a link without hand-editing it
<magcius> third, don't change between this "tree" link and the "file" link. Nice URLs should be hand-editable, if I'm linked to a file, the first instinct for me to get the directory is delete the filename portion
<magcius> And that's all
<magcius> What I would do for the third one is set up a soft redirect like cgit does
<magcius> Otherwise, great work!
<Peng_> Please file bugs.
<magcius> Peng_: I feel sort of bratty about filing 4 or 5 bugs at once
<Peng_> magcius: Heh, I do too when I do that, but as kind of a Loggerhead developer, I don't mind. Your bugs sound good.
<Peng_> s/do too/feel the same way/
<cbz> this is very strange, bzr works on one machine to import svn repositories, on the other any attempt to create branches ends in errors of some kind or another
<Peng_> cbz: You'll have to be more specific than "some kind or another".
<cbz> the branch will work up to a point, and then i'll get an error saying "bzr: error: [error 145] the directory is not empty: u'" with a path inside the shared repositoriy i'm using
<cbz> it's not consistently the same path
<cbz> I tried creating it without a shared repository and got that error once, and got this once bzr: ERROR: [Error 5] Access is denied
<cbz> The only consistent thing is that there is some indications from the various mailing lists that some kind of locking may be involved at least in some cases
<cbz> In which case i can't figure out why it should work fine on one machine and not on the other
<Peng_> cbz: Got some weird file system? A network file syste,?
<cbz> no - both are on virtually identically specced windows machines, using the same install image and using local disks
<cbz> svn is working on both machines too - so it isn't that
<jelmer> mwhudson: hey
<jelmer> mwhudson: it'd be great if you contributed a patch for bug 525571 !
<ubottu> Launchpad bug 525571 in launchpad-code "bzr svn-import fails when invoked concurrently" [High,Triaged] https://launchpad.net/bugs/525571
<james_w> hey jelmer
<james_w> back home now?
<jelmer> james_w: hey
<jelmer> james_w: yeah, it was nice to see a bit of Lisbon though, wasn't all bad :-)
<james_w> good
<Peng_> jam: ping
<Peng_> Darn. Now I have to do research! :P
<mwhudson> jelmer: i guess
<cbz> gah
<cbz> another Error 5
<Peng_> jam: Never mind about the ping. FYI, I just made it impossible to do Container._set_property for attributes that start with an underscore. Hope you don't mind, but it was the easiest way to fix a nasty bug.
<cbz> curiouser and curiouser - everything appears to have worked properly *APART* from populating the working tree
<cbz> i'm pretty sure at least some of my troubles are coming from bugs within subvertpy - or at least the version bundled in bazaar2-.1.1
<jelmer> cbz: what are you trying to do exactly?
<cbz> just branch from a fairly large subversion repository - on one machine it works flawlessly, on the other i get an Error 5 or an Error 145 for identical commands
<cbz> The latter appears to be possibly locking related
<cbz> The former appears to be this https://bugs.launchpad.net/subversion/+bug/347334
<ubottu> Ubuntu bug 347334 in subversion "bzr: ERROR: [Errno 5] Can't open 'C:\tmp\tempfile.tmp': Zugriff verweigert ("Permission denied")" [Medium,Triaged]
<luke-jr> so I hacked bzr-svn up enough to get it working with my svn repo finally, but now it only works pre-bzr-svn :/
<luke-jr> that is, the first bazaar commit on svn breaks it
<luke-jr> presumably from the root dir properties
<luke-jr> is there a way to get bzr-svn to ignore that subset of the properties yet still read the revid/author/etc info?
<cbz> i found i had to use rebase rather than pull - no idea if that is your issue
<cbz> Separate issue - is it safe to delete obsolete_packs?
<jelmer> luke-jr: you can remove those properties from the repository manually
<jelmer> luke-jr: alternatively you could hack bzr-svn to ignore them, your copy of bzr-svn would already break very badly when interoperating with other versions of bzr-svn
<luke-jr> jelmer: impossible without recreating the svn repo
<luke-jr> jelmer: right now, my copy is a bugfix ;)
<jelmer> luke-jr: I disagree it's a bugfix
<luke-jr> jelmer: you saw the diff?
<jelmer> luke-jr: anyway, we've had this discussion before :-)
<jelmer> luke-jr: no, but I assume it's what we talked about earlier?
<luke-jr> unlikely
<luke-jr> it's a simple fix
<jelmer> do you have the diff up somewhere?
<luke-jr> http://bazaar.launchpad.net/~luke-jr/bzr-svn/bzr-svn-longest-branch-path/revision/3250
<luke-jr> beyond that change, it
<luke-jr> it's mere configuration
<luke-jr> another approach that would fix it even better is assuming (correctly) that any/all parents of a branch are also a branch :p
<jelmer> luke-jr: So you're basically considering branches/ to be a branch as well?
<luke-jr> jelmer: the code repository has had many various layouts over the years
<luke-jr> branches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*;private/*/*/armagetronad
<luke-jr> this lists all of them (I think)
<luke-jr> originally it was armagetron/{trunk,tags,branches}, then armagetronad/{trunk,tags,branches}, then armagetronad/{trunk,tags,branches}/armagetronad
<luke-jr> etc
<jelmer> ah, I think I understand what you're trying to do now
<luke-jr> bzr-svn sees the parent branch using a different layout and assumes it's not a branch, so cuts the branch short
<luke-jr> so with that patch, plus the config, I can access the older revisions fine
<luke-jr> but commits from misconfigured/unpatched bzr-svn are messing me up now
<jelmer> luke-jr: I don't see how that could be a problem, the commits' revision ids contain the branch path
<cbz> can i set whoami on a per repository basis?
<luke-jr> well, part of it was the bzr:revision-id:v3-list-QlpoOTFBWSZTWZvbKhsAAAdRgAAQABK6798QIABURMgAAaeoNT1TxT1DQbKaeobXKiyAmlWT7Y5MkdJOtXDtB7w7DOGFBHiOBxaUIu7HQyyQSvxdyRThQkJvbKhs property
<jelmer> cbz: yes
<luke-jr> the first column tells bzr-svn what the bzr-revno is
<luke-jr> and is now wrong
<luke-jr> by 1933 revisions
<jelmer> luke-jr: that
<luke-jr> if I recreate the svn repo with that modified, bzr log shows adjusted revnos, but still cuts history short
<jelmer> 's a bug in your branch, it shouldn't generate different data from existing svn data
<luke-jr> so I'm missing something else as well
<luke-jr> jelmer: ???
<jelmer> luke-jr: your branch can generate other revisions than older versions of bzr-svn
<jelmer> luke-jr: but it should not generate different contents for revisions with the same revision id
 * luke-jr wants to keep compatibility with existing misconfigured-bzr-svn branches, btw
<luke-jr> anyhow, that's actually unrelated to my branch
<luke-jr> that's the difference between unconfigured and configured
<jelmer> luke-jr: from what you're saying I get the impression you've broken backwards compatibility somehow
<luke-jr> unconfigured bzr-svn cuts the history short when the repo changes layout
<jelmer> luke-jr: no
<luke-jr> configured bzr-svn continues the history back to the first commit
<jelmer> luke-jr: older versions of bzr-svn that used branching schemes did that, it's not true for newer versions (bzr-svn >= 0.4.x)
<luke-jr> 1.0.2 seems to still use branching schemes...
<jelmer> luke-jr: the layout doesn't influence the length of the history in any way
<luke-jr> o.O
<jelmer> luke-jr: 1.0.2 still supports branching schemes if you try to access a repository that uses them
<jelmer> luke-jr: but (unless you set 'mapping = v3' it won't write them)
<jelmer> anyway, gtg - back in an hour or 3
<luke-jr> :(
<luke-jr> jelmer: aha, I see.
<luke-jr> jelmer: any way to destroy the branching schemes stuff without losing actual commit info?
<luke-jr> ideally keeping revids compatible with existing branches? :)
<jelmer> luke-jr: no, there isn't a way to do that while keeping the revision ids
<jelmer> luke-jr: you would need branching schemes to do that
<luke-jr> how about with new revids?
<luke-jr> (keeping file-ids?)
<jelmer> IIRC the file ids shouldn't change anyway
<luke-jr> even if the files are now seen as being created in another revision?
<luke-jr> in any case, I still need a way to ignroe the v3 mapping data
<jelmer> luke-jr: the default file id generation algorithm doesn't use the revision id but just the svn revno in which the file was introduced, the path at that point and the repo uuid
<jelmer> luke-jr: ignoring the v3 mapping data can only really be done by stripping all the bzr: properties from those revisions
<luke-jr> but now that the full history is visible, it sees the *real* svn revno the files were introduced
<luke-jr> whereas the old data and now-real file-ids all "appeared" in the cutoff rev
<luke-jr> jelmer: these aren't revprops, so impossible :(
<jelmer> rikght, so those file ids would change
<luke-jr> no config setting to change the prop name perhaps?
<jelmer> luke-jr: no, that means the mapping is no longer deterministic (because dependent on a config variable)
<luke-jr> better than broken :/
<jelmer> luke-jr: unfortunately this really is a legacy problem with the v3 mappings
<luke-jr> what of the file-id issue?
<luke-jr> since it sounds like I'm going to need to re-write the Svn repo anyway, is there a revprop or root prop I can throw on svn-r1 to set file-ids to a specific string?
<jelmer> luke-jr: you can set the bzr:file-ids revprop on revision properties that introduce new files to force the file ids for certain paths
<luke-jr> it needs to be on the rev introducing the file?
<jelmer> yeah, or affecting the file somehow
<jelmer> (text modification, rename)
 * luke-jr ponders
<jelmer> luke-jr: I'm sorry you got bit by this as an early adopter of bzr-svn
<jelmer> luke-jr: we did get it right in the end imho, but that doesn't change your existing data of course..
<luke-jr> well, it'd probably be easiest to do a one-time conversion and just trash svn at the end IMO
<luke-jr> but that creates a different problem
<luke-jr> in fact, it might be something I need to consider now...
<luke-jr> I'm going to need to redo this process yet again someday, when Bazaar can do a lossless conversion
<luke-jr> will that again require new revids? :/
<jelmer> luke-jr: what do you mean with lossless conversion exactly?
<jelmer> luke-jr: svn:externals, svn:mime-type, that sort of thing?
<luke-jr> versioned/file properties and copy metadata, at least
<jelmer> luke-jr: but yeah, supporting any of those will require a mapping bump so new revids
<luke-jr> :(
<jelmer> luke-jr: I'm hoping to add support for them all at once
<luke-jr> even if we don't care to be compatible with other bzr-svn (because we throw away the Svn)?
<jelmer> luke-jr: what about the existing imports that have already been made of your svn repo with other versions of bzr-svn?
<luke-jr> well, by preserving the revid, those should be compatible? :)
<jelmer> luke-jr: bzr doesn't like multiple (different) revisions with the same revid
<luke-jr> if you mean the present-day problem, that's why I want to keep the file-ids
<luke-jr> i c
<jelmer> luke-jr: that's the whole reason bzr-svn is so careful about revids
<luke-jr> and bzr doesn't have timestamps so it can replace an old <revid> with a new <revid>?
<jelmer> luke-jr: timestamps of what exactly? When the revision was written to disk?
<luke-jr> hmm, good point
<luke-jr> last update?
<luke-jr> could probably be an integer version actually
<jelmer> the newest revision wasn't necessarily created by a "correct" version of bzr-svn
<jelmer> luke-jr: who determines that integer version? And what if converting from one to the other is not lossless?
<luke-jr> the human perhaps
<jelmer> luke-jr: bzr-svn isn't the only place where this problem arises - bzr itself has multiple storage formats, all with different capabilities
<jelmer> luke-jr: what do you consider the canonical version?
<luke-jr> any version that's lossless from the initial commit? :)
<jelmer> luke-jr: what's the initial commit in this case?
<luke-jr> in my case, a commit on CVS or Subversion
<jelmer> luke-jr: and what if somebody else bases a commit on a version-2 import of the svn revision
<jelmer> luke-jr: and then you try to merge their commit into your local repo where you have version-3 ?
<jelmer> luke-jr: bzr will need version-2 as well to be able to apply the deltas it has received
<luke-jr> lossless is lossless
<jelmer> luke-jr: if you only support lossless then this is pointless
<jelmer> luke-jr: since one version can't support nested trees while the other does
<jelmer> luke-jr: as lossless conversion between them is not possible
<luke-jr> CVS -> Subversion was possible <.<
<luke-jr> I guess I should be glad we didn't use cherry-picking in Svn
<luke-jr> then we'd have yet more functionality to wait for Bzr to supprot
<luke-jr> :/
<luke-jr> on that note, though... any idea why it's taking so long for these things (versioned file metadata and copying) to get spec'd? it's not like imports need bzr to act on it, just store it
<jelmer> luke-jr: CVS and Subversion both aren't centralised
<jelmer> luke-jr: versioned file metadata as such isn't on the agenda afaik
<jelmer> luke-jr: just individual things, e.g. keywords, line endings, etc
<jelmer> luke-jr: copy metadata needs a decision on what to do about merges
<jelmer> luke-jr: the worry is that storing that information and not using it will cause invalid data to be recorded
<luke-jr> for now, a merge involving a copy could easily just throw an unsupportederror
<jelmer> luke-jr: I'm not sure if I agree with that last part, I'd like it to actually be stored myself and perhaps just used for log/annotate. I don't really care about merge atm
<luke-jr> how is that disagreeing with it? :p
<jelmer> luke-jr: throwing an unsupportederror seems like a bad idea to me, that means everything that involves copying is unmergeable
<luke-jr> well, there's various possibilities
<luke-jr> it could just conflict every time and let the human handle it
<jelmer> luke-jr: I'm disagreeing that we should support merge for copies when we introduce copy tracking support.
<jelmer> luke-jr: I think just supporting it for annotate/log and roundtripping for e.g. bzr-svn/bzr-git is a step forward.
<luke-jr> git doesn't support copies anyway
<luke-jr> I really just want to finish migrating our project to Bazaar and leave Subversion historical
<jelmer> luke-jr: one of the problems with all of these is also that they require format changes in bzr itself
<jelmer> luke-jr: and that's something we're not fond of either
<jelmer> luke-jr: or would at least like to do in batches
<luke-jr> the sooner the better :p
#bzr 2010-04-25
<Prodi> i've got a bzr+ssh server running in centralized environment, and i want it to run a command after anyone does a push to the server
<Prodi> is there a hook i can use?
<Prodi> post_push seems to say it only runs on the client side, but i'm looking for something on the server side
<lifeless> thumper: so hows wikkid going ?
<thumper> it's coming along
<lifeless> cool
<thumper> getting distracted by the terrible movie
<lifeless> did you see my tweeted reply ?
<lifeless> about twisted?
<thumper> no
<lifeless> ah
<lifeless> so paste has no long poll supoprt
<lifeless> I think twisted would be best to stay with
<lifeless> use the twisted wsgi layer and use bits of paste in that
<lifeless> but don't change the main server lop
<thumper> I've not found any docs about twisted's wsgi layer
<lifeless> xhttp://jcalderone.livejournal.com/51888.html
<lifeless> http://jcalderone.livejournal.com/51888.html
<lifeless> back in a bit
<lornajane> I really can't figure out how to use bzr-svn, now wondering if in fact I'm expecting it to do something it doesn't actually do :)
<lornajane> so I used bzr-svn to check out from subversion, branched that and worked on the branch
<lornajane> when I came to commit back to the branch that was the subversion checkout, all my commits turned up in one individual merge commit
<lornajane> I can sort of understand that, because that's how bzr works, but is there any way to commit multiple times to bzr and have them sent to svn individually?
<james_w> hi lornajane
<lornajane> (because at this rate I'm going to end up using git-svn and I'd really like to avoid that!!)
<lornajane> hey james_w :)  Long time no see
<james_w> indeed
<james_w> so you branched and worked locally for a while?
<lornajane> james_w: yes, I do this when I'm travelling and am offline
<james_w> lornajane: how did you get those commits back to svn?
<lornajane> james_w: pushed them to the branch that I originally made from svn
<james_w> lornajane: odd, I would have expected that to do what you want
<james_w> so I guess I'm not going to be much help for you :-)
<lornajane> I committed several times before I pushed, and svn sees only a single merge commit in its log
<lornajane> the whole point is that when I spend 2 days on the train, my team don't have to deal with a monster svn commit of 8 things lornajane did in the last 2 days
<lornajane> now I'm giving a talk on source control at a big PHP conference and I'm quite determined to have as little git in it as possible, so I'm looking for information or pointers to places I should be looking for it
<lornajane> the PHP community are way too excited by git
<james_w> I know that there is a "dpush" command as well, but I thought it was for something else, not for solving this issue.
<lornajane> well I played around a bit and it seems like bzr squashes commits by default, but retains some metadata about which changes went into them
<lornajane> that's not part of the mainline history so it doesn't go across to svn, which does kind of make sense
<lornajane> it just isn't what I wanted to do :)  So either I'm missing something, or I have unrealistic expectations of how this works, and either seems entirely plausible
<james_w> right, if you do a "merge" at any point then you will get this behaviour for the revisions that you merged in
<james_w> but if you just "push" then I didn't think that would happen
<lornajane> ah, OK.  I'm playing some more now
<lornajane> james_w: magic!!  That's absolutely what I was looking for :)
<lornajane> I'll just play about with what happens when there are changes in svn while I'm developing etc but the simplest case was spot on - thanks so much!
<jelmer> lornajane: if there are changes in svn, you can rebase (rather than merge) to keep your changes on the mainline
<lornajane> jelmer: oh that's really helpful, I'm just trying to break things by making svn changes at the same time - because I know there probably will be when I do this in anger
<lornajane> jelmer: so how do I do that? (feel free to just point me at the right place where I can RTFM) - and am I rebasing my checkout or my feature branch?
<jelmer> lornajane: you would rebase your feature branch
<jelmer> lornajane: and then push those rebased revisions into the checkout or directly to svn
<lornajane> jelmer: this is making increasing amounts of sense :)
<jelmer> lornajane: since rebase keeps the revisions on mainline all revisions will appear as individual commits in svn
<goundy> hi
<goundy> guys, there's still no way to make bazaar deleting a branch from a shared repository ?
<goundy> rather than just deleting the branch folder
<lornajane> jelmer: I get unknown command rebase ... am I out of date with something?
<jelmer> lornajane: rebase is in a separate plugin, the bzr-rewrite plugin (originally named bzr-rebase)
<lornajane> jelmer: ah, thanks
<lornajane> jelmer: hey, that works beautifully.  Thanks so much for your assistance!
<jelmer> lornajane: yw :-)
<goundy> any idea where I can get a small private bzr branch for free guys ?c
<goundy> I ain't got no commercial project yet, it's just a currently closed source one I'd like to host somewhere
<goundy> launchpad asks for like 600$/year... a student like me can't pay that lol
<jelmer> goundy: I'm not aware of anything; SourceForge perhaps?
<goundy> jelmer, sourceforge doesn't have bazaar
<goundy> only svn am I wrong ?
<jelmer> goundy: it has bazaar (and git and mercurial) as well
<goundy> Ã´O
<goundy> gosh
<goundy> I really didn't know about that
<goundy> jelmer, am gonna check if they offer private hosting too. Thank you very much
<goundy> jelmer, FYI, SF doesn't offer private hosting ;)
<rlameiro> hello, is there some version control system only for my personal using?
<rlameiro> without using a remote server?
<rlameiro> or do i need to run a bz server on my desktop to use it?
<lornajane> rlameiro: you can use bzr on your computer without needing a remote server
<rlameiro> lornajane: thanks
<rlameiro> lornajane: do i install only bzr? or do i need to install a bzr server?
<lornajane> rlameiro: what platform do you use?
<rlameiro> ubuntu
<rlameiro> lornajane:
<lornajane> rlameiro: I think you only need the bzr package
<lornajane> rlameiro: I'm a bit of a newbie too though - but the user guide has helped me a lot!  Its here: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html
<jelmer> goundy: :-(
<goundy> jelmer, that's really unfortunate.. I can find svn private & free stuff but nothing for bazaar ^^
<jelmer> goundy: I'm not aware of anything else that might offer private hosting other than lp, perhaps ask on the bazaar list?
<a212901390231901> just use any free webspace.
<a212901390231901> don't need serverside bzr support.
<goundy> jelmer, the bzr list is the only place I've not asked yet
<goundy> a212901390231901, actually I'm aware I can use FTP mode
<goundy> but i want to have a source browser too
<goundy> and this is a problem
<a212901390231901> 's not all that useful for private projects in my experience, the people who have access have local branches anyway
<a212901390231901> and qbzr is better than loggerhead
<goundy> a212901390231901, even if it's a private project I really need the browsing possiblity
<goundy> qbzr ? am gonna check what it is
<goundy> oh interesting :)
<goundy> a212901390231901, have you ever used bazaar in FTP mode ?
<a212901390231901> yeah. it won't fly for a kernel-sized project, but it's fine for anything more typical.
<goundy> a212901390231901, I think am going to do this though
<goundy> thanks :)
<elmo> bah
<elmo> I have a staging and a production branch, I'm trying to push to staging from production
<elmo> but it's telling me production's diverged
<elmo> nm
<putrycy> hi! checkout otains snapshot (--lightweight) or complete branch. Is there a possiblity to get a 'havy' checkout but containng just few revisions back? Let's assume we have a long term project (for example OS;]) - we really don't need all revisions starting from the first.
<putrycy> And second question: Is it possible to checkout/branch/whatever just a subdirectory instead of a hole branch?
<awilkins> putrycy, http://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_sparse_checkout
<awilkins> putrycy, and   the --depth option on clone
<putrycy> and another one question: Why do I have to be up to date with a branch to commit changes in local directory? Will it be fixed in a next bzr version?
<putrycy> awilkins: thanks for replay
<awilkins> putrycy, damn, wrong channel
<awilkins> putrycy, Errrm, not sure bzr does sparse checkouts yet
<putrycy> :)
<putrycy> I'm starting to read... git? what's going on?:)
<awilkins> putrycy, You don't have to be up to date to commit, unless it's a checkout
<putrycy> awilkins: I'm talking about checkout...
<awilkins> You can still commit locally, with an option
<awilkins> But you then must be prepared to merge at some point
<putrycy> OK
<putrycy> the second manner - is it slow?
<awilkins> putrycy, The same speed as a normal commit ; you're effectively deciding to make your local checkout a branch instead
<putrycy> so, instead of checkout I could use branch that I merge every time I do some changes, right?
<luke-jr> jelmer: so if I'm not allowed to simply ignore the bzr:revision-id:v3-list-*, what is the supported way to do this? :P
<luke-jr> alternate idea: in rewriting the Svn repo, can I easily redo the bzr-to-svn for bzr-side revs?
<luke-jr> I was thinking fast-export|fast-import, but bzr doesn't seem to support the latter sanely
<jelmer> luke-jr: supported way to do what?
<luke-jr> jelmer: ignoring the v3 branch layout screwup data while keeping the bzr rev info (committer, etc)
<jelmer> luke-jr: hmm
<jelmer> luke-jr: I would say this isn't really supported :-)
<jelmer> luke-jr: fastexport/fastimport won't read the bzr-svn metadata
<luke-jr> that was another approach I thought of
<jelmer> luke-jr: I would recommend redoing the svn repo (svnadmin dump)
<jelmer> luke-jr: and then generating new bzr-svn revprops (v4)
<luke-jr> jelmer: redoing the svn repo how? :)
<jelmer> luke-jr: svnadmin dumping it, editing the stream then reimporting
<luke-jr> there was a number of months with overlapping svn/bzr commits
<luke-jr> jelmer: how can I generate new svn revisions for the bzr commits?
<putrycy>  It seems to be an answer to my question: As explained in later chapters, Bazaar also has support for lightweight checkouts of a branch, i.e. working trees with no local storage of history. Of course, disconnected usage is not available then but thatâs a tradeoff you can decide to make if local disk space is really tight for you. Support for limited lookback into history - history horizons - is currently under development as well.
<jelmer> luke-jr: you wouldn't generate new revisions, just modify the existing ones
<putrycy> i.e. mainly the last sentence
<luke-jr> jelmer: fabricate new v4 revprops from where?
<jelmer> luke-jr: manually
<luke-jr> in any case, it appears the script doing the bzr-to-svn imports was modifying stuff in the commit msg and such
<luke-jr> is the v4 format documented?
<luke-jr> my thought was to fudge a new svn repo with the svn-only history, then write a script to look at each subsequent revision; if svn-side, load the svndump; if bzr-side, rebase/fe-fi and push from present bzr-svn...
<luke-jr> but fast-import seems to want to wipe all history and start over with the import
<jelmer> luke-jr: the v4 format is documented in bzr-svn trunk
<jelmer> luke-jr: yeah, that's true afaik (wrt fastimport)
<luke-jr> jelmer: so there's no good way to move a bzr revision from one repo to another? :/
<jelmer> luke-jr: you can push it, but that means the ancestry has to be in common as well obviously
<luke-jr> yeah, which defeats the point
<luke-jr> I just want to change the ancestor, nothing else at all
<jelmer> luke-jr: if you're not pushing the ancestry then by definition it is not the same revision
<luke-jr> semantics
<awilkins> They are rather the core semantics of DVCS though
<luke-jr> but they don't change what I want to do :)
<luke-jr> if it's technically a new revision, fine, but I want it the same except ancestry :p
<luke-jr> :/
<putrycy> If I merge two branches then does current branch contain information about revision from merged branch? If no then is there a possiblity to merge a snapshot to branch?
<luke-jr> jelmer: no way to put file-ids in revprops, is there? :\
<luke-jr> putrycy: yes; see: bzr log -n0
<thumper> beuno: ping
#bzr 2011-04-18
* 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: jelmer
<poolie_> i'm going to finish a coupel of the pending ones though
<lifeless> poolie_: btw, the subtree detection stuff would mean that adding files in a subtree will require changes to status to support it.
<poolie_> true
<lifeless> (no opinion on desirability, just flagging the impact)
<poolie_> i'm not going to do it now
<poolie_> it will need some careful testing
<poolie_> today after piloting some stalled bzr things i hope to work on the incoming mail feature flag for dkim configuration
<lifeless> cool
<spiv> Good morning folks
<poolie_> hi spiv
<bradm> poolie_: removing the hardy chroot on pqm slipped until today, removing it now unless I hear screaming otherwise. :)
 * poolie_ does not scream
<poolie_> oh for interest, i submitted back-to-back merges the other day and the run time was pretty stable at 40m
<evanton> I have a bzr repo retrieved by "bzr branch" command. How to I change the working directory to a certain revision? Doing bzr checkout -r x yields a file exists error for .bzr
<poolie__> evanton: 'bzr update -r whatever'
<evanton> oh, it's update in bzr
<evanton> poolie__: thanks, I'll read the help for update now
<poolie__> checkout makes a new checkout
<poolie__> update updates an existing working tree from the repositoyr
<evanton> poolie__: I'm just used to switch revisions using checkout in another DVCS
<poolie> i'm going to look at https://bugs.launchpad.net/bzr/+bug/764188
<ubot5> Ubuntu bug 764188 in Bazaar "test_report_bug_legacy fails on trunk" [Critical,Confirmed]
<poolie> hopefully shallow
<poolie> ok
<poolie> doctestmatchers really do kind of suck
<poolie> i think it was broken by wordwrapping
<spiv> Wow, that's a difficult error to parse
<poolie> that's another bad thing about it
<poolie> launchpad wrapping it again is not helping
<poolie> how are you?
<spiv> Pretty good.  I've got a touch of the cold V had, but so far only a touch of it.
<spiv> I've got to the point of having some failing tests for the pack concurrent writes
<poolie> oh, nice
<spiv> Oh, and http://twistedmatrix.com/trac/ticket/5011 has gone through another round of review and improvements.
<poolie> hopefully clean non-thread-based tests?
<spiv> Yes :)
<poolie> review pls? https://code.launchpad.net/~mbp/bzr/754188-apport-test/+merge/58064
<spiv> Reviewed (and approved)
<poolie> almost needs a tag +should-have-known-better
<poolie> spiv i thought there was a function to raise knownfailure when a particular assertion fails
<poolie> but i can't find it
<poolie> oh maybe in testtools
<poolie> yes it is
<poolie> hm so bellany running make check is about twice as slow as a buildd building the whole binary package (including make check and other stuff)
<poolie> maxb: i added some stuff to http://wiki.bazaar.canonical.com/DailyPpaStatus#preview and i think fixed the trunk builds
<jam> hi poolie
<jam> poolie: so the buildd is significantly faster than our pqm... interesting
<jam> so we should be submitting it to buildd first
<jam> :)
<poolie> :)
<poolie> there is a drawback that you may wait quite a while to actually _get_ to build on the buildd
<poolie> if you include that, it's probably slower
<poolie> anyhow, it broke a little bit and i think now it's ok again
<poolie> did you ever touch the rules code?
<spiv> I've touched it very slightly.
<poolie> it seems like we need a better api than an iterator of every relevant value
<poolie> surely you normally just want one?
<poolie> i think i'll take a detour to do it
<rom1> Hi all
<rom1> Is there a way to ignore tabs and spaces conflicts while merging ?
<jam> rom1: not that I know of. Though if there were conflicts, what would you put in the output?
<rom1> jam: well, in fact, it is to avoid that it produces conflicts (for instance in java or c programs). I have noticed some reported conflicts with bzr-builder from spaces versus tab.
<rom1> But i will have a look at the content-filters i guess
<jam> rom1: sure, I understand the concern, but what do you actually put since they disagree on what the content would be
<jam> rom1: using content filters you can help enforce the form stored in the repository. However, merging is done on the repository form, AIUI
<jam> so existing content won't be helped
<rom1> in my idea, i keep lines from OTHER
<jam> rom1: I know you can create a custom merge function, too
<rom1> thx jam, i gonna have a look at that
<cheater> hey guys
<cheater> how can i check out only a specific subdir of a repo?
<rom1> cheater : you cannot. You can only checkout the whole repository
<cheater> hmm
<rom1> Revisions are revisions of repository and not revisions of files as in svn or cvs
<cheater> gotcha
<fullermd> s/repository/branch/ to be precise.
<cheater> that's fine with me, i just want the file system to only have just that subdir
<fullermd> There exist 'views', which are a primitive that could be used toward building such a thing.  But nobody's done it.
<cheater> i wish bzr would keep the whole repository just in .bzr somewhere
<cheater> fullermd: aha
<briandealwis> Greetings.  Does anybody know of a way to rename a pipeline?
<jelmer> briandealwis: pipes basically work by setting next_pipe / prev_pipe in branch.conf
<briandealwis> ah, thanks jelmer â I hadn't started poking
<jelmer> briandealwis: so if you rename the branch dir and update those settings in the previous and next pipe you /should/ be fine (I haven't tried)
<briandealwis> jelmer: yup, that seemed to work.  Thanks!
<jelmer> jam: having fun with trees and inventories too ?
<gypsymauro> hi, how can I tell bzr to exclude some extensions?
<jelmer> gypsymauro: you can uninstall them or set the BZR_DISABLE_PLUGINS env variable
<jelmer> gypsymauro: why do you want to disable some plugins?
<gypsymauro> I mean file extensions for example I qant to forgive .log or .ini files
<briandealwis> gypsymauro: read up on the .bzrignore file
<gypsymauro> tanx briandealwis :D
<ablmf333> I'm using bzr to work with svn repository.  Today suddenly I found I can not correctly update it by "bzr update"
<jelmer> ablmf333: can you elaborate?
<ablmf333> When I try to commit, I got " bzr: ERROR: Bound branch BzrBranch7(file:///home/peter/Work/repo/cms/) is out of date with master branch SvnBranch('svn+ssh://peter.cai@svn_repo/sites/svn/cms/site/branches/sprints/V000006').
<ablmf333> But when I run "bzr update", I got "Tree is up to date at revision 296 of branch svn+ssh://peter.cai@svn_repo/sites/svn/cms/site/branches/sprints/V000006"
<ablmf333> I found similar problem this afternoon, so I removed local repo and re-checked out the code.
<ablmf333> But again, I met this problem.
<ablmf333> svn works fine.
<jelmer> ablmf333: what version of bzr-svn are you using?
<jelmer> ablmf333: what does "bzr missing" report?
<ablmf333> bzr missing says "bzr: ERROR: No peer location known or specified."
<jelmer> ablmf333: and with the master branch specified?
<ablmf333> bzr-svn version : svn 1.0.5dev
<ablmf333>    Support for Subversion branches
<ablmf333> bzr missing .
<ablmf333> Branches are up to date.
<jelmer> ablmf333: did you commit any merges recently?
<ablmf333> Yeah, I pushed some changes.  Then I got found local repo could not correctly update.  So I re-checked out.
<ablmf333> So my earlier commits messed up the repo on svn?
<jelmer> ablmf333: you did "bzr push" to push changes, rather than committing to the checkout?
<jelmer> did any of those involve merges?
<ablmf333> Yeah, it used to work fine.
<ablmf333> Yeah, I remembered I merged from trunk.
<ablmf333> Did some revision on branch.
<ablmf333> Push
<jelmer> that's probably what triggered it. Recent versions of bzr-svn should cope with this better.
<ablmf333> Then I found local repo can't update anymore.
<jelmer> Is there any reason you're using an snapshot rather than a release?
<ablmf333> You mean bzr-svn?
<jelmer> ablmf333: yeah
<ablmf333> Can't really remember.
<ablmf333> I will try a release version then.
<jelmer> I don't think a release will work better, the related fixes are only in newer snapshots
<ablmf333> jelmer: So should I try a snapshot of bzr-svn?
<jelmer> ablmf333: you're already running a snapshot, but a fairly outdated one.
<jelmer> ("dev" in the version string indicates it's a snapshot rather than a release)
<ablmf333> k, I will try to find a newer snapshot
<ablmf333> jelmer: I checked out bzr-svn by "bzr co lp:bzr-svn"
<ablmf333> Is that right?
<jelmer> ablmf333: yep
<ablmf333> then I coped it to "/home/peter/.bazaar/plugins/"
<ablmf333> but "bzr plugins" still tell me it's 1.0.5dev
<jelmer> it should say 1.1.0dev
<jelmer> ablmf333: you need to rename it 'svn' rather than 'bzr-svn'
<ablmf333> jelmer: thanks. I got it, but new problem: cannot import name CommittedQueue
<ablmf333> Unable to load plugin 'svn' from '/home/peter/.bazaar/plugins'
<jelmer> ablmf333: what version of subvertpy does ~/.bzr.log say you have?
<ablmf333> let me check
<ablmf333> In [2]: subvertpy.__version__
<ablmf333> Out[2]: (0, 7, 5)
<jelmer> ablmf333: that's too old; the newer bzr-svn requires subvertpy 0.8.0. It should warn about this, I'll check why it doesn't.
<ablmf333> jelmer:  0.8.0 of subvertpy reports "Unable to load subvertpy extensions: No module named client"
<ablmf333> jelmer: Oh, I see, that's because I am still in subverpy source code dir
<jelmer> ablmf333: subvertpy has a C extensions that need to be built
<ablmf333> jelmer: opos, svn plugin crashes : http://pastebin.com/TtG9MRyR
<jelmer> ablmf333: that's because your subvertpy is too old
<jelmer> hi poolies :)
<poolie> hi jelmer :)
<poolie> how are you?
<poolie> thanks for the review
<poolie> i'm going to try to finish off sergei's patch today
<poolie> a full version with tests and docs will be a bit more than 5 lines or whatever it was
<jelmer> poolie: very well, thanks :)
<jelmer> poolie: is that his patch related to diff ?
<poolie> yes, to showing the function name
<poolie> you're pp this week btw
<poolie> i should read vila's patches too...
<jelmer> poolie: Yep
<knighthawk> I'm trying to break a lock but I seem to be doing something wrong. when I try to run bzr pull on a svn-import
<knighthawk> i'm getting
<jelmer> ablmf333: lp:bzr-svn should now warn properly on older versions of subvertpy
<ablmf333> jelmer: Ah, now the problem seems to be bzr is too old
<jelmer> ablmf333: what error are you getting?
<knighthawk> Unable to obtain lock file:
<ablmf333> http://pastebin.com/C2mK7cBP
<jelmer> ablmf333: I've pushed a fix, can you try again?
<ablmf333> jelmer: k
<knighthawk> I think I may have figured it out.
<ablmf333> jelmer: k, the plugin work.  But it doesn't solve my original problem - I can't commit
<ablmf333> It asks me to update, but when I update, it says my repo is up to date.
<knighthawk> I think I'm missing a step when working with a central svn server.
<sven_oostenbrink> Question.. Whenever I have 2 repos with a shared history, they are synced, and then I modify file "a" in repo "a" and file "b" in repo "b".. Now, when I want to pull repo "a" into "b", I have to perform a merge.. Since different files were modified, it basically could have been like file "a" and file "b" were modified in repo "b".. Isn't it possible to make push/pull like this that merge without problem just possible without having to merge? and only
<sven_oostenbrink> in case that there is a conflict, that a merge is required? it would shave off some of the needed work...
<jelmer> ablmf333: do you have any pending merges?
<fullermd> sven_oostenbrink: No, because you don't merge files; you merge revisions.  And you have new revisions in both sides.
<ablmf333> jelmer: Yes.
<jelmer> ablmf333: (the last few lines of "bzr status" should show you)
<ablmf333> I have some pending merges
<ablmf333> that's why I need to commit
<jelmer> ablmf333: is your current head the same as the head of the master branch, or is the pending merge the current master branch?
<knighthawk> So far I've been able to do a svn-import and create a branch. Next I was able to pull from the central svn repo into my local repo (where I don't have a working tree) next I guess I want to my branch with the repo ( my head isn't getting how to do that without a working tree). But where i'm *most* confused with is how do I push back up (assuming I did all my actual work in my branch wich points to the repo)
<ablmf333> jelmer: thx, but I will use svn for this now.  It already wasted me too much time.
<jelmer> knighthawk: you can either create a working tree in the branch that was created by "bzr svn-import", or you can create a clone of that branch with a working tree
<jelmer> knighthawk: you can use "bzr push" to push your changes made in the local branch back to svn
<knighthawk> jelmer when I ran bzr branch did it create a clone of the branch in the repo or do I need to use a different command to have my pushes go up?
<jelmer> ablmf333: It'd be great if we can narrow it down a bit so I can fix the bug in bzr-svn
<jelmer> knighthawk: I'm not sure I follow, what sort of "bzr branch" command did you run?
<ablmf333> jelmer: I've delete the repo folder.  But I still have another one that couldn't update correctly.
<ablmf333> That one when I run update, it says it's up to date.
<ablmf333> but it's different from what is on svn
<ablmf333> jelmer: What do u want to know?
<jelmer> ablmf333: so "bzr up" doesn't update to the actual last revision in svn?
<ablmf333> yes.
<jelmer> ablmf333: are there any merges involved?
<knighthawk> jelmer so after I did the init bzr svn-import (I didn't really want a big working tree in that dir) I ran 'bzr branch ' into another dir. I've been calling that my working tree. I've been doing my work their. Then thought the workflow I needed was to update my "working tree" to what's in the svn repo to go into my local repo(created for svn-import) then run a pull there and merge that with my branch with my working tree
<ablmf333> jelmer:  The story is : 1) i merged trunk to branch.  2) work on branch 3) push back to trunk.  4) trunk couldn't update anymore.
<jelmer> knighthawk: you should be able to just run "bzr push <svn-url>" from wherever you've been working
<knighthawk> ah thanks jelmer
<ablmf333> jelmer: That makes me can't not fetch some reversions on server.
<jelmer> knighthawk: is the trunk you're trying to update a svn working copy or a bzr checkout?
<knighthawk> I'm going to say a svn working copy.
<jelmer> knighthawk: sorry, that was for ablmf333
<knighthawk> ah
<jelmer> ablmf333: is the trunk you're trying to update a svn working copy or a bzr checkout? (iow, does it have a .svn or a .bzr dir?)
<ablmf333> jelmer: It's a bzr checkout.  I used 'bzr co svn_ssh://....."  to check out.
<jelmer> ablmf333: thanks
<jelmer> ablmf333: what do you mean with push back to trunk exactly? "bzr push svn+ssh://.../trunk" ?
<ablmf333> jelmer: No, I created a branch by `bzr branch trunk_dir branch_dir`
<jelmer> ablmf333: you mentioned you push the work you did on the branch back to trunk; what did you do to do that exactly ?
<ablmf333> in 'branch_dir' I run 'bzr push :parent'
<ablmf333> Apparently, those changes I made on branch is committed to svn.
<ablmf333> But the problem is, after that, the trunk is not able to synchronize to svn server anymore.
<jelmer> ablmf333: thanks, I think I've narrowed it down
<jelmer> ablmf333: so "bzr log" doesn't show the revision that was pushed?
<knighthawk> Is this a fix everyone is going to need? (he asks just before pushing to his svn trunk)
<jelmer> knighthawk: which fix?
<knighthawk> what's going on with ablmf333, when you said you' narrowed it down it sounded like you were fixing something. but I see now that may not have been how you meant it.
<jelmer> ablmf333: sorry, "bzr log" in the trunk doesn't show the revision that was pushed?
<jelmer> knighthawk: no, that's related to "bzr push" to a branch bound to a svn branch
<jelmer> knighthawk: you're not using bound branches at all
<knighthawk> k thanks
<ablmf333> jelmer: bzr log show the are pushed.  But one single file is different to svn sever, even if bzr tells me the working copy has not changed.
<jelmer> ablmf333: different as in not yet updated?
<ablmf333> jelmer:  Yeah.  I can't update that file to its newest version.
<ablmf333> I can not see one svn reversion someone else made.
<jelmer> ablmf333: revisions that have happened on the svn trunk since the push of your revisions ?
<ablmf333> jelmer: I can't really tell because I've removed the bzr repo.
<ablmf333> jelmer: but let me check.
<ablmf333> jelmer: maybe I can find it by svn
<ablmf333> jelmer: It's a reversion before I pushed.
<ablmf333> I should have merged it to my bzr branch this morning.
<ablmf333> But somehow it was lost.
<ablmf333> And I can never get it back anymore
<jelmer> ablmf333: thanks, that helps
<jelmer> ablmf333: I think I've also reproduced the commit issue
<ablmf333> jelmer:  Great, at least my bad luck might help someone else.
<ablmf333> jelmer: Is there anyway to avoid this problem?
<ablmf333> jelmer:  Should I avoid using push on svn?
<jelmer> ablmf333: the commit issue is something I'm looking at fixing now
<sven_oostenbrink> fullermd: I know I merge revisions, not files.. But wouldn't it be nice if.. bzr could recognize that the revisions could be merged without problem? And then just pull, merge automatically, and commit... just with bzr pull?
<jelmer> ablmf333: the second one is already fixed (between 1.0.5dev and 1.1.0dev) and can be avoided by fetching into a clean bzr repository from svn
<ablmf333> jelmer: k, I will try it tomorrow and let u know the result.
#bzr 2011-04-19
<maxb> Hrm. bzr-svn seems to be doing a lot more work fetching tags now than it used to
<jelmer> maxb: yes, consistent with bzr itself it now fetches all revisions referenced by tags, not just those in the branch tip ancestry
<maxb> jelmer: unfortunately, on my largish work repository, this is the difference between bzr pull working, and taking so long that I give up and Ctrl-C it
<maxb> wait.... all revisions referenced by tags? Doesn't that mean, given svn tags are not per-branch, that branching any branch of a svn repository has to walk and fetch the revisions on any branch which has been tagged?
<jelmer> maxb: any relevant tag
<jelmer> maxb: it doesn't fetch the branch tips, just the tags that would be in the branch that's fetched
<jelmer> maxb: IOW for the 'ant' project in Apache SVN it would only fetch the revisions referenced by ant tags
<jelmer> there has been some discussion about whether it's a good idea to fetch all revisions referenced by tags; perhaps it's something useful to bring up on the list
<maxb> jelmer: but, consider some experimental branch that has tags - if the tags are bounded by project, branching trunk will now need to also pull in that experimental branch
<maxb> For native bzr, it just about makes sense, because tags are per-branch
<jelmer> maxb: it will only bring it in until the last revision that is tagged
<maxb> which could still be a LOT of extra data transfer and processing time
<jelmer> maxb: what about a svn tag that is based off a revision on the current branch but makes one additional modification?
<maxb> hrm :-/
<jelmer> maxb: I don't think this problem is specific enough to bzr-svn
<jelmer> I had some unrelated tags on one of my bzr branches and also ended up fetching a lot of unrelated revisions
<mgz> jelmer/maxb: if you notice any new plugin test failures with the latest bzr.dev please subscribe me to the bug
<mgz> I changed the run_bzr args semantics a little and lots of the plugins' test suites use it.
<jelmer> maxb: Suggestions on how to better handle tags on non-tip-ancestry revisions welcome
<jelmer> mgz: ok
<spiv> Good morning.
<poolie> hi there spiv
<poolie> like clockwork :)
<spiv> :)
<poolie> how are you, spiv?
<spiv> Good, I seem to have escaped the worst of the cold going around this household.
<poolie> you guys seem to have had a really bad run with that
<poolie> over the last year or so i mean
<spiv> Yeah.  Aside from the last week we'd been pretty good for maybe 2 months finally.
<lifeless> EBABY
<spiv> We think V picked this one up from another baby's 1st birthday rather than daycare for once.
<poolie> itym fork() != 0
<lifeless> len(pgroup)
<lifeless> perhaps
<poolie> i wish bug 456418 were fixed
<ubot5> Launchpad bug 456418 in Launchpad itself "merge proposal status info should reflect status of prerequisite branch" [Medium,Triaged] https://launchpad.net/bugs/456418
 * poolie tries to work out which of vila's patches comes first
<poolie> jelmer: hooray for more tariff tests
<poolie> jelmer, did you want to talk about the config mps or point me to any of them in particular?
<poolie> spiv do you use selftest --subunit regularly?
<poolie> i seem to have a bug where partway through the tests, the stream starts going to stderr
<lifeless> wow
<lifeless> poolie: do you say that because you've captured it, or because you start seeing the raw stream?
<poolie> i am piping it into tribunal and part way through tribunal stops seeing updates and i get it in my terminal
<poolie> it may well be a bzr test doing something weird with global state
<poolie> just trying to narrow it down
<lifeless> my guess would be a print statement (or debug statment) printing to stdout and not puttingn a \n on the statement
<poolie> ah, yuck
<poolie> and then the subunit libraries and tribunal are printing it out
<poolie> i'd forgotten about that
<poolie> that's easy to test with a simple redirection
<spiv> poolie: I don't, although I use --parallel regularly, which does something similar I assue
<spiv> *assume
<lifeless> yup, --parallel does subunit for each core
<poolie> it's probably a tribunal bug
<poolie> too many yaks
<poolie> maxb, hi
<poolie> we might as well cease building for karmic in the daily ppa, hey?
<maxb> poolie: hah
<maxb> I was just finishing off an email proposing that before responding to your bing
<jam> morning poolie
<poolie> hello?
<poolie> hi jam
<jam> just saying hi
<spiv> jam: hi :)
<poolie> hi spiv
<jam> hey spiv
<spiv> Hmm, webnumbr seems to have stopped being able to fetch from launchpad :(
<poolie> is there any indication why?
<spiv> poolie: not that I can see.  Trying to create a new webnumbr against lp eventually just gives me a blank page, which suggests a problem on webnumbr's end
<poolie> good night all
<jelmer> g'night poolie
<jelmer> jam: Do you know what the difference between Inventory._get_mutable_inventory and Inventory.copy is ?
<jam> jelmer: CHKInventory._get_mutable_inventory() returns an Inventory() instead of a CHKInventory
<jelmer> jam: I knew there was something I was missing. Thanks.
<spiv> I wonder how many uses of _get_mutable_inventory are left.
<spiv> We mostly just use explicit deltas now.
<jelmer> I'm about to remove one, that leaves two uses
<jelmer> one in a test, and one in MutableTree.update_basis_by_delta
<jam> jelmer: talk about chasing the rabbit down the hole. Fixing iter_changes caused bugs to show up for WT.inventory which causes more test failures...
<jam> we actually have some tests that we *don't* auto-detect nested trees (probably for performance reasons?)
<jam> anyway, still chasing
<jelmer> jam: ugh :-/
<jam> jelmer: I think our tree-reference implementation is pretty incomplete, and basically it is 'just enough' to get the test suite to pass
<jam> but alter one detail...
<jelmer> jam: I can see how that's frustrating.. One of these days we should JF finish tree references..
 * jelmer lunches
<ablmf333> jelmer:  Morning.  Have u fixed the commit problem of bzr-svn?
<jelmer> ablmf333: no, not yet
<jelmer> ablmf333: https://bugs.launchpad.net/bzr-svn/+bug/765286
<ubot5> Ubuntu bug 765286 in Bazaar Subversion Plugin "commit to checkout with pending merges breaks" [High,Triaged]
<ablmf333> jelmer: Then, is there anyway to completely remove bzr info in svn repo, so I would be able to get a fresh check out that I can commit?
<ablmf333> I deleted all the bzr:xxx properties
<ablmf333> But I still couldn't commit
<ablmf333> bzr still complains that I need to update before commit
<jelmer> ablmf333: If you remove the bzr: properties you need to remove your bzr-svn cache and do a clean checkout
<jelmer> ablmf333:
<ablmf333> jelmer:  Where is the bzr-svn cache?
<jelmer> ablmf333: usually ~/.cache/bazaar/svn/<uuid>
<jelmer> jam: Nice work on the status improvements!
<jam> jelmer: it could be better, I still don't get the improvement I wanted for 'bzr status' after 'bzr co', but I'm getting there
<ablmf333> jelmer: How do I know which uuid should I delete?
<jam> ah, I'm missing symlinks
<jelmer> ablmf333: "svn info <url>" should display the UUID
<jelmer> ablmf333: are these revision properties or file properties?
<jam> (the tree I'm testing has a symlink in it, and we don't cache symlink targets on initial create, and it gets updated during first status)
<ablmf333> jelmer: I just deleted every bzr:xxx on the trunk directory on svn server
<jelmer> ablmf333: That won't help
<ablmf333> jelmer: k, then how do I delete revision properties?
<jelmer> ablmf333: That's not the point; removing *any* properties won't help with this issue.
<ablmf333> jelmer: I don't get it.  What else could make bzr-svn thinks that my local branch is out of date?
<jelmer> ablmf333: it's a bug that's got to do with your pending merges and its analysis of the revision graph
<ablmf333> jelmer: No, no, I've committed the merge with svn.  Now I just want bzr-svn works on a fresh new checkout.
<jelmer> ablmf333: so what's not updating exactly?
<ablmf333> jelmer: I use `bzr co svn://....` to get a new checkout. Made some test modification and tried to commit, bzr tells me that the local is out of date.
<ablmf333> jelmer: I just removed bzr-svn's local cache.  Hope that will help.
<jelmer> ablmf333: what sort of changes are you committing, a merge?
<ablmf333> jelmer: No, just a line of comment.
<ablmf333> jelmer: bzr: ERROR: This operation requires storing bzr-svn metadata in Subversion file properties. These file properties may cause spurious conflicts for other Subversion users during merges. To allow this, set `allow_metadata_in_file_properties = True` in your configuration and try again.
<ablmf333> jelmer: Should I do that?
<jelmer> ablmf333: yep (it's consistent with what bzr-svn did for you previously)
<ablmf333> jelmer: Thanks!  Finally I could use bzr-svn to work again.  Is there anything I should avoid in the future when using bzr-svn?
<jelmer> ablmf333: not really, this is just a bug that's been fixed recently
<jelmer> ablmf333: I would recommend /not/ removing file properties, that just breaks your bzr-svn cache and makes it slower
<ablmf333> jelmer: k.  Thanks, hope u can fix the bug soon.
<maxb> jelmer: FYI I have changed the dulwich-daily recipe to use ~vcs-imports/dulwich/trunk instead of ~dulwich/dulwich/trunk, because I think that will avoid the BzrCheckError
<knighthawk> okay guys sorry for all the newbie questions but I'm lost again and RTFM hasn't helped me yet. So again I created a bzr repo using svn-import (no working tree) then I used 'bzr branch' to create a branch from the repo. Now from my brach (working tree) I'm trying to run 'bzr pull' from the svn repo. but I get 'bzr: ERROR: These branches have diverged. Use the missing command to see how.' it looks like I'm only one revision away from being able to do this
<knighthawk>  (according to 'bzr missing') so It *seems* to me that I should run a merge then I should be able to pull only how do I merge a working tree with a none working tree?
<knighthawk> btw if I got any of the terminology wrong please point it out. I'm trying to use it so I can get it right the terms all seem similar to svn but I'm thinking it may not be quite the same.
<poolie> hi all
 * fullermd waves at poolie.
<fullermd> knighthawk: It's not quite clear what you're wanting or expecting...
<fullermd> knighthawk: So you've got a branch from svn-import; call it A
<fullermd> knighthawk: And a branch you made from A; call it B.
<fullermd> Now you're wanting to...   pull from SVN into B?
#bzr 2011-04-20
<jelmer> hey poolie, fullermd
<j1mc> hi - is there a bzr equivalent to 'git pull --rebase'?
<LeoNerd> Possibly  bzr rebase ?
<LeoNerd> Though not knowing quite what that  git pull --rebase  does I'm not sure
<j1mc> git pull --rebase allows you to update your branch with the current commits before you push your own commits
<j1mc> LeoNerd: unfortunately, there doesn't appear to be a bzr rebase command
<LeoNerd> Well, the usual way to do that in bzr would be to merge trunk into your branch first
<poolie> j1mc: the equivalent is 'bzr rewrite'
<LeoNerd> You -can- rebase, but that's somewhat rude as it rewrites history
<poolie> from the bzr-rewrite plugin
<poolie> i don't know if there is a specific one-shot command to do that
<LeoNerd> It's generally much nicer to merge from the trunk into the branch, so that branch merges back into the trunk afterwards
<LeoNerd> It doesn't involve any history-rewriting that way
<LeoNerd> But still, if you want rebase, you'll find it in the  bzr-rewrite  plugin
<jelmer> j1mc: "bzr rebase" does the same thing as "git pull --rebase"
<jelmer> as LeoNerd and poolie point out, that command requires the bzr-rewrite plugin
<j1mc> thanks for your help, all. i will give the bzr-rewrite plugin a try.
<maxb> jelmer: Hi. I have been bitten by the broken not-quite-dpushed commits in dulwich again.
<maxb> I would like to suggest deleting lp:~dulwich/dulwich/trunk from existence so that they cannot propagate further
<maxb> I am currently wondering if I should manually recommit the recent history of the dulwich bzr-ppa branches for hardy/jaunty/karmic to excise them
<poolie> hi maxb
<maxb> hello
 * maxb hugs the lp api and lpshell
<maxb> having just been able to do a loop over all ~bzr recipes calling r.distroseries.remove(karmic) on them all
<maxb> hm
<maxb> but it doesn't seem to have taken effect
 * maxb is less impressed now
<jelmer> poolie: Thanks for also looking at Vincent's config patches
<jelmer> maxb: The same commits or different ones?
<poolie> that's ok
<poolie> do you want to talk about it?
<poolie> i'm wondering if we should in fact do per-file configuration on the way i discussed in the overall mp
<jelmer> maxb: please note that that branch is just a mirror of another one
<maxb> jelmer: same ones causing problems in new scenarios
<jelmer> maxb: So it's all old stuff?
<maxb> jelmer: OK, let's delete all branches in the world with the dodgy commits :-)
<knighthawk> I'm thinking a work around may be to just to add a working tree to A
<knighthawk> but yeah fullermd that's my situation.
<maxb> jelmer: 2011-01-14 is the most recent problem revision
<jelmer> maxb: if it's all old commits I'm happy to delete and repush those branches, if there are new commits involved as well we should probably investigate further
<jelmer> maxb: That's old enough for me :)
<jelmer> poolie: I think the idea of mixing config and rules is interesting
<poolie> if they're going to stay separate, i'd like to have a clear idea of why they're separate
<poolie> beyond just 'rules are per-file'
<maxb> I'm currently trying to decide whether it would be quicker to manually recommit the history for the bzr-ppa branches, vs. hack up reconcile with "where you see this text parent, change it to that one" logic
<maxb> knighthawk: If you'd followed the exact sequence of commands you mentioned earlier, I don't see how you could have diverged branches
<jelmer> poolie: My impression of it is that rules are things that could potentially apply to everybody accessing a particular branch
<jelmer> whereas config is specific to a specific machine or user
<jelmer> That's how I think of them at least, not sure if it necessarily makes sense.
<maxb> knighthawk: Perhaps a pastebin of your console session would explain things best
<knighthawk> maxb I did do a commit of new code in my branch before trying to do the pull from svn
<poolie> that is true
<jelmer> poolie: I realize that doesn't entirely match our current use, as we don't currently allow you to declare "doc/en/release-notes/*.txt" as changelog files that should be processed with the custom changelog merger
<poolie> but perhaps they should just be different layers that stack together
<maxb> knighthawk: In that case I think you misunderstand the nature of "pull"
<poolie> perhaps it's too confusing if some are trusted and some not
<maxb> knighthawk: "pull" is for making a local branch be identical to some remote one. Once you've committed stuff locally, that's no longer possible. You want to merge, I guess, instead.
<knighthawk> maxb quite possible, I went ahead and created a working tree in 'A' now I'm going to try to merge 'A' and 'B'
<jelmer> poolie: yeah, trust is indeed an interesting thing in this too
<knighthawk> maxb I guess what I want to do is like a update of the local branch to the central repo before I try to commit my changes back into svn.
<maxb> knighthawk: Right. "bzr merge svn+ssh://my.svn.server/svn/repository/project/trunk" for example
<knighthawk> maxb can I just merge to a svn repo? (I don't know why but I assumed I couldln't do that)
<maxb> No, because you can only merge into a working copy
<knighthawk> ah. okay I just merged my changed from B into A so now I want to merge from the svn repo into A then do a commit (I think)
<jelmer> poolie: food for thought :)
 * jelmer gets some sleep
<poolie> :) sleep well
<spiv> jelmer: I'd like to update news_merge to use rules, actually
<poolie> hi there spiv
<poolie> so spiv, what do you think of unifying them?
<stewart> help help! "permission denied" using 'bzr switch' ? http://paste.drizzle.org/show/481/
<poolie> hi stewart
<stewart> poolie, hi!
<poolie> the eperm is a distraction just meaning you don't have a /var/crash or something
<poolie> looks like https://bugs.launchpad.net/bzr/+bug/623152
<ubot5> Ubuntu bug 623152 in Bazaar "ValueError: need more than 1 value to unpack in _last_revision_info" [Undecided,Expired]
<stewart> huh...
<poolie> > That traceback suggests the .bzr/branch/last-revision file is corrupt, probably blank. What does it contain?
<stewart> poolie, it's 0 bytes long
<stewart> poolie, so probably something that wasn't written out during one of the "damn laptop hung... probably due to intel wireless drivers" events last week
<poolie> sorry, yeah
<poolie> we should almost just fsync everything, except that would make things pretty slow for people whose machine aren't crashing
<poolie> can you see if 'bzr reset-dirstate' fixes it?
<stewart> poolie, unknown command... some plugin i'm missing?
<poolie> ah it might only be in bzr 2.4
<stewart> ahh.. .and i'm 2.3.1
<poolie> do you have a lot of uncommitted work?
<poolie> it might be faster to just make a new tree
<stewart> poolie, no.
<stewart> poolie, wiping away the checkout is fine.
<poolie> i will update that bug to say there should be an easier way to recover
<teratorn> does the windows installer support bzr+ssh urls out of the box?
<teratorn> tortoisebzr?
<poolie> teratorn: i think so yes
<stewart> poolie, i have no problems with it fsyncing such things. nooo problem with that at all :)
<poolie> maybe at least an option would be good
<poolie> in fact an option that just globally fsync'd on close could be good
<spiv> poolie: my understanding of the purpose of rules is the same as jelmer's
<poolie> at least as 'fool me twice' prevention
<poolie> that's my understanding too
<spiv> well, versioned-in-tree config about that tree
<poolie> however, i'm not sure we need a separate and somewhat parallel api to get it
<spiv> It definitely has a lot in common with other kinds of config
<spiv> We have perhaps slightly different concerns about versioning the format of rules vs configs, but in terms of API it sounds reasonable to have as much commonality as possible.
<stewart> poolie, attempted new lightweight checkout for my working dir... http://paste.drizzle.org/show/482/
<spiv> There is also a difference that in practice rules are used for per-file stuff, or at least 'per-thing in tree as matched by globs', and mostly other configs don't do that.
<poolie> stewart ah the problem is actually in the branch not the tree
<stewart> poolie, oh yeah, last-revision is empty there too
<poolie> if that's your trunk, delete the branch directory
<poolie> and pull from the server again
<stewart> poolie, i have a mirror of it on lp...
<stewart> (of that branch)
<poolie> it's actually lost its idea of what the tip is
<poolie> you don't need to delete the repo, only the branch
<poolie> so it should be quite fast to fetch
<stewart> yep. branch going away.
<stewart> poolie, FYI it left the lightweight checkout dir in an odd state...just wiping it and trying again
<stewart> poolie, question, is there any efficiency in packing binary data in the repo apart from simple compression? e.g. if we had X number of 10MB files that were *mostly* the same, would we get anything better than X*10MB disk usage?
<poolie> yes you would
<stewart> poolie, I'm wanting to have various InnoDB data files in the tree for backwards compatibility testing.
<stewart> without having people whine at me that the repo is now 400MB :)
<poolie> one caveat is that compression only hppens within pack files
<poolie> so if you successively commit 10 additions of those files, you will have 10 pack files each ~10MB
<stewart> poolie, i can deal with that. (i gather a repack would reclaim a lot of space)
<poolie> however, the compression on the 10th commit should shrink them all into one pack somewhat less than 100MB
<poolie> right
<stewart> 10x10MB files with only about 1MB difference should be closer to 20MB on disk than 100MB
<lifeless> stewart: yes, thats right. Do an experiment :)
<stewart> nice :)
<stewart> we were discussing if we would gzip these in tree or not, rather convinced we should just store them in there now.
<stewart> it turns out some people care not to have to sql dump and restore their database :)
<poolie> bzr will be able to compress them better if they're not individuall gzipped
<poolie> which will hide any similarities
<lifeless> lp stores a SQL dump of some MBs of data in tree
<lifeless> it compresses pretty well
<lifeless> its a tad fugly, but if you need it you need it.
<lifeless> I would suggest having it in a dedicated tree perhaps
<poolie> that sounds like a good idea
<poolie> <jam> This fixes a bug that Mark Shuttleworth pointed out to me (bug #765881)
<poolie> nice
<ubot5> Launchpad bug 765881 in Bazaar "newly added files always trigger IN_MEMORY_MODIFIED" [High,In progress] https://launchpad.net/bugs/765881
 * spiv gives his wireless router a kick
<poolie> stewart also https://bugs.launchpad.net/bzr/+bug/766735
<ubot5> Ubuntu bug 766735 in Bazaar "people get confused by apport messages" [Medium,Confirmed]
<poolie> spiv do you have any ideas about https://bugs.launchpad.net/bzr/+bug/721163
<ubot5> Ubuntu bug 721163 in Bazaar "bzr crashed with ErrorFromSmartServer: ('error', 'bytes must be a string')" [Undecided,New]
<spiv> poolie: hmm, no
<spiv> poolie: I think we need the server-side log
<spiv> I can't think of any likely causes, and I don't think any hooks are triggered by insert_stream so it's unlikely to be a buggy plugin
<poolie> so can you say so?
<spiv> Sure.
<johnf> Is it possible to find all the dangling revisions in a repository created by uncommit?
<lifeless> bzr heads --all
<KombuchaKip> Is there any way to setup a post commit hook for bzr to send an email when using it with Launchpad?
<johnf> lifeless: cheers
<lifeless> KombuchaKip: if your branch is on launchpad you can just click on subscribe in the UI
<poolie> KombuchaKip: the people interested in the branch can just subscribe to it in lp
<poolie> or you can use bzr-email
<poolie> o/ johnf
<lifeless> KombuchaKip: if you want the mail sent to a list, you can subscribe a team with a contact address of the mailing list (or the team itself if its a launchpad hosted list) and LP will mail that directly.
<KombuchaKip> poolie: I'd like to use bzr-email, but not sure if you can use that with launchpad since you won't have access to server?
<KombuchaKip> lifeless: Thanks. I think that's what I will do.
<poolie> it runs on the client
<poolie> sending it from lp seems easier
<KombuchaKip> poolie: Thanks.
<KombuchaKip> This is always a friendly and helpful channel.
<poolie> thanks
<maxb> poolie: Thanks for the pointer to deryck's bzr issue. As it turned out, it was actually a launchpad-specific bzr plugin that was at fault, so no problem for us on the #bzr side of things :-)
<poolie> o/ bialix
<poolie> hooray
<poolie> spiv, jelmer, jam, hi?
<jam> hi poolie
<jam> "Are you ready to Muuuummblllllllllleee" ?
<jam> (said w/ a WWE announcer voice)
<poolie> :) :)
<poolie> be back in a sce
 * jelmer is still setting up
<spiv> poolie, jelmer, jam: damn, forgot what day it was
<poolie> np, want to join us now?
<spiv> Ok
<jam> spiv: pack retry attacked back
<jam> poolie: this one? https://wiki.canonical.com/Bazaar/Plan/2011
<jam> spiv: yeah, we don't hear you
<poolie> jam re bug 746237 i was just going to check if there's a new bug
<ubot5> Launchpad bug 746237 in Bazaar "Documentation markup bugs" [High,In progress] https://launchpad.net/bugs/746237
<jam> poolie: sure
<jam> I don't think there is a new one
<poolie> i'll do a pass over all of ~mbp inprogress today or tomorrow
<jam> poolie: what is our current 'bug fix' policy
<jam> it should always target 2.3?
<jam> or 2.2?
<jam> or ...?
<jam> I have a fairly trivial fix for bug #760152 which I can backport as far as we want
<ubot5> Launchpad bug 760152 in Bazaar "bzr merge --pull --preview BRANCH does not always honor the --preview option" [High,In progress] https://launchpad.net/bugs/760152
<jam> the main issue is just how much effort do we want to spend merging-up
<poolie> serious bugs with safe fixes in 2.1
<poolie> bugs worth fixing with safe fixes in 2.3
<poolie> i guess
<poolie> 2.0 basically dead except by request
<poolie> iow i think the safety bar is equally high
<poolie> but, merging into 2.1 is a bit more work, so we should only do it when we specifically think it'll please someone
<jam> poolie: sure. I guess my issue here is how to handle the merge-up and the RELEASE NOTES
<poolie> on lts
<poolie> right
<jam> Yay, closing a 4-digit bug
<jam> bug #5135
<jam> I tested it, and it works fine here
<ubot5> Launchpad bug 5135 in Bazaar "bzr diff -r X..Y path/to/branch fails if path/to/branch is a symbolic link" [Medium,Fix released] https://launchpad.net/bugs/5135
<jam> ubot5: you're getting slow, man
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<poolie> way to go!
<poolie> if there were badges, you would get at least a silver one
<jam> poolie: well, closed because it has already been fixed. But still feels good.
<jelmer> :)
<poolie> maybe we should just make a web page with badges if we can't do it automaticaly
<spiv> poolie: or a greasemonkey script?
<jelmer> spiv: if you're still around and interested, we're having a udd meeting #ubuntu-meeting
<jelmer> *in
<poolie> jam: hi?
<mrevell-lunch> Morning/nick mrevell
<mrevell-lunch> sorry
<mrevell> :)
<jkakar> Hi ntoll! :)
<ntoll> hi jkakar
<ntoll> fancy seeing you in here ;-)
<jkakar> ntoll and I have discovered something funky in our branches...
<jkakar> We have trunk, staging and production branches, each of which is meant to be older than the last (and we're careful with merges).
<jkakar> We have a situation where production doesn't contain content in a file that, after carefully analyzing the logs, we think should be there.
<jkakar> So I ran 'bzr check' and got this:
<jkakar>   3838 revisions
<jkakar>   1360 file-ids
<jkakar>      3 inconsistent parents
<jkakar> I'm wondering what '3 inconsistent parents' means...?
<jkakar> Could it be that some flummox in merging could have removed the content we expect...
<jkakar> For example, I seem to remember reverting a revision could produce strange results when you merged it back...?
<jkakar> abentley: ^^ Any ideas?
<abentley> jkakar: No, inconsistent parents are mostly harmless.  They are usually due to ghost revisions or bzr bugs.
<jkakar> abentley: Okay, thanks. :)
<jkakar> abentley: I guess bzr bugs are mostly harmless? ;b
<jkakar> abentley: Anyway, I think we figured out the issue is an EPEBKAC error. :)
<abentley> Ah, okay.
<jkakar> abentley: Thanks for your feedback, much appreciated... these kinds of "WTF?" moments are always a bit scary. :)
<abentley> jkakar: no problem.
<fullermd> I think 'reconcile' will often fix inconsistent parents.
<jkakar> fullermd: Yeah, I was wondering about it... but 'bzr help reconcile' says, "You should only need to run this command if 'bzr check' or a bzr developer advises you to run it."
<jkakar> fullermd: Neither of those things happened so I didn't run it.
<maxb> What exactly is an "inconsistent parent"? Is this described anywhere?
<jkakar> maxb: I was wondering the same... I couldn't easily find anything about it.
<maxb> I gather it's something to do with consistency between the overall revision graph and the ancestry attributed to individual files
<jkakar> maxb: I gathered the same, yeah.
<diwic> What do I do about this: "bzr bd" gives error "Unable to determine the previous upload for --package-merge"?
<james_w> diwic,  "bzr branch lp:bzr-builddeb /tmp/builddeb; BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr bd"
<diwic> james_w, iow this is a known bug that is fixed in trunk?
<james_w> diwic, indeed
<diwic> thanks!
<knighthawk> I've seen a few places that mention rebase. perhaps as a solution to my problem committing to svn. But when I try to run 'bzr rebase' or 'bzr help rebase' it says it doesn't exist. am I doing something wrong?
<niemeyer> Hey there
<knighthawk> looks like I'm running bzr 2.1.1-4
<jelmer> knighthawk: rebase is in the bzr-rewrite plugin
<niemeyer> Getting some issues with bzr-fastimport related to an AttributeError on _find_ancestors
<knighthawk> jelmer thanks
<niemeyer> On natty, specifically
<niemeyer> Is that a known issue?
<jelmer> hi Gustavo
<jelmer> niemeyer: it sounds vaguely familiar - can you pastebin the backtrace?
<niemeyer> jelmer: Hi!
<niemeyer> Sure
<niemeyer> jelmer: http://pastebin.ubuntu.com/596621/
<jelmer> niemeyer: thanks
<jelmer> niemeyer: it's indeed something I've seen before
<jelmer> https://bugs.launchpad.net/bzr-fastimport/+bug/541626
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed]
<jelmer> I'm not too familiar with the index code, perhaps John can comment on it tomorrow.
<jelmer> it looks shallow
<niemeyer> jelmer: Cool, thanks
<mgz> jelmer, did you have a branch that had some code doing isinstance(revision_id, basestring) up for review? I now can't find the mp and think I may have imagined it.
<jelmer> mgz: perhaps the branch that forbade using None as alias for "null:" in Branch.set_last_revision_info() ?
<mgz> maybe. do you have a link? I meant to ask whether said variable should actually be bytes or unicode.
<jelmer> mgz: that was inspired by some other code in bzrlib.revision that did the same thing IIRC
<mgz> I thought it was one of the ones removing the inventory stuff and switching a param to be a tree or something instead
<jelmer> tjatlp:~jelmer/bzr/testament-tree ?
<jelmer> that's lp:~jelmer/bzr/testament-tree ?
<jelmer> bzrlib.revision.is_reserved_id() checks against basestring
<jelmer> mgz: it happens in more places, e.g. Repository._iter_revisions
<mgz> must have confused two different diffs. I've not been keeping up with for coding. :)
<ironmagma> does bzr require you to download the whole repository history, like git/hg do?
<Odd_Bloke> ironmagma: You can use lightweight checkouts, which do not.
<knighthawk> svn users aren't too happy with me right now, somehow I blew away the svn history for a few days with my push. is this because in my ~/.bazaar/suvbersion.conf I added append_revision_only = False?
<lifeless> push shouldn't even be destructive, unless you used --overwrite
<lifeless> s/even/ever/
<knighthawk> did *not* use overwrite
<lifeless> jelmer: ^ around ?
<knighthawk> I did a bzr merge to merge my working tree to what was supposed to be the latest version of the svn repo (only it seems it wasn't) then I commited my changes and tried to do a push that didn't work until I added append_revision_only = False but then it seems I blew up some stuff. I've since installed bzr-rewrite and now I'm trying rebase instead of append_revision_only = False. but since I'm not *sure* that's what created the problem I'm not sure if I'm
<knighthawk>  going to do it again.
<lifeless> yeah, I can understand that
<lifeless> sadly, I've only used bzr svn a very few times myself, so I don't really have a clue about whats up there
<jelmer> re
<jelmer> hi lifeless, knighthawk
<knighthawk> hey jelmer
<jelmer> knighthawk: yes, if you set "append_revisions_only = False" that means bzr-svn will push even if that removes existing revisions from the mainline (the revisions are still in the repository, just not in the mainline of the branch)
<jelmer> knighthawk: The default of append_revisions_only=True is intended to prevent you from shooting yourself in the foot
<knighthawk> jelmer, okay it *sounds* like now that I have bzr-rewrite working I can use rebase and don't need append_revision_only=False anymore (I think)
<jelmer> knighthawk: you can restore the old mainline using either "svn cp -r ..." or "bzr push --overwrite ..."
<jelmer> knighthawk: right, rebase will preserve the upstream branch mainline
<knighthawk> jelmer sorry I'm not sure what is meant by mainline is that the trunk?
<jelmer> knighthawk: mainline are basically the revisions shown by "bzr log -n1"
<jelmer> knighthawk: non-mainline revisions will be shown too if you use "bzr log -n0"
<knighthawk> thanks jelmer that clears up a lot. but now did I just destroy my changes of restoring the mainline by running rebase?
<jelmer> knighthawk: it depends on what exactly you rebased
#bzr 2011-04-21
<poolie> hi all
<jelmer> hellÃ¸!
<poolie> hi jelmer
<knighthawk> jelmer are you still here?
<jelmer> knighthawk: yeah, though not for much longer
<knighthawk> In my bzr branch I ran 'bzr rebase'
<knighthawk> it was pointing to my svn repo
<knighthawk> but this was *after* I did the push with append_revisions_only = False
<knighthawk> so I'm worried now that I can't recover the history in svn with --overwrite. Also mind you several other people have made commits to the svn repo since I did all this.
<knighthawk> so I'm thinking that history might just be lost.
<jelmer> knighthawk: the history is still there - see 'svn log <repos-history>'
<jelmer> knighthawk: it will be tricky to get both the old revisions and the new revisions though
<knighthawk> k jelmer thanks I'll try to figure it out.
<spiv> Morning.
<jelmer> hey spiv, how's your morning?
<spiv> Pretty good considering V woke up at least 4 times last night!
<poolie> hi spiv, ocuh
<poolie> *ouch
<spiv> We think it's his molars coming through
<spiv> Well, we can see that they are, but we're guessing that's why he's waking up so often.
<poolie> hm, we probably need jubany to be upgraded to something with 2.6 if we require that in 2.5
<poolie> bzr *2.4
<jelmer> spiv: :-/
<mgz> what's the planned release date for bzr 2.4?
<poolie> for the final one?
<mgz> yup.
<poolie> lp currently has 4 august
<poolie> the general thing is, about 2 months before the ubuntu release
<poolie> it can be flexible
<spiv> Regarding jam's comment on https://bugs.launchpad.net/bugs/267296, I wonder if we should have a "needs-piloting" tag?  Patch pilots could search for that bug tag in addition to scanning the +activereviews page.
<ubot5> Ubuntu bug 267296 in Bazaar "utf16 file detected as binary file" [Medium,Confirmed]
<spiv> Ideally LP would have some way of bringing partial work to our attention, but that might be an ok workaround.
<poolie> spiv, well, that's kind of what the 'has patch' thing is meant to track
<poolie> but it is not a very good match for a few reasons
<poolie> well, not a perfect match
<spiv> Right
<spiv> I suppose that particular branch can been seen on https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev/+merges?field.status=WORK_IN_PROGRESS too
<spiv> It'd be nice to see that list of w-i-p branches ordered by the importance of the bug they are linked to (if any).
<spiv> (Or perhaps if advanced bug search could specify âshow only bugs with linked merge proposals with status Xâ)
<poolie> mm
<poolie> i don't think i touched any code yesterday
<poolie> hope to do better today
<poolie> spiv is it possible that bug 390745 would be covered by your repack refactoring?
<ubot5> Error: Launchpad bug 390745 could not be found
<spiv> poolie: hmm!
<poolie> i realize it's a bit hard to say since we don't know exactly what leads up to it
<spiv> poolie: it might, but it's hard to be certain
<spiv> It's probably the best hypothesis we have so far
<lifeless> poolie: bug 664242 may not be one you want closed
<ubot5> Launchpad bug 664242 in Bazaar "want a way to locally mirror many branches, similar to source packages" [Medium,Expired] https://launchpad.net/bugs/664242
<poolie> thanks
<poolie> i wonder how it even got incomplete
<lifeless> you filed it that way
<poolie> mm so it seems
<poolie> i don't normally do that
<poolie> did launchpad just decide to start catching up on expiry?
<lifeless> we just fixed a bug
<poolie> oh a bug was fixed that was blocking it?
<lifeless> yeah
<poolie> jolly good
<lifeless> thats why it worked for a week or so
<lifeless> then broke
<lifeless> the bug is fixed
<lifeless> the bug that stopped us knowing is also fixed.
<poolie> oh, lifeless, is the maverick-proposed bzr working out ok?
<poolie> i didn't hear any screaming
<lifeless> i've had one of those days
<poolie> with no code?
<poolie> sorry to hear that
<poolie> let me know if anything does break
<lifeless> 6am starts make me a little slow
<lifeless> I spent a ridiculous chunk of time tracking down some test failures in my branch to store INCOMPLETE_WITH_RESPONSE in the db
<lifeless> culminating with finding that we expire bugs to which the user has replied - https://help.launchpad.net/Bugs/Expiry#Old, unattended and incomplete?
<poolie> ouch
<lifeless> I had naively assumed that replying prevents expiry
<poolie> i would have too
<poolie> hi jam!
<gour> morning
<gour> there is no bzr-svn for bzr-2.3?
<poolie> hi gour
<poolie> i think there is
<gour> but not released?
<poolie> 1.0.3?
<gour> "1.0.4 (works with Bazaar 2.2)"
<gour> http://wiki.bazaar.canonical.com/ForeignBranches/Subversion#releases
<poolie> ah, yes
<poolie> it is 1.0.4 and it is not released yet
<poolie> i think jelmer is planning to make one soon, but he should be online in a bit
<poolie> ok, good night
<gour> 'night poolie
<jelmer> hi jam
<jam> hi jelmer
<jam> by the way, I was agreeing with you on bug #317357
<ubot5> Launchpad bug 317357 in Bazaar "pointless commit message now ugly" [Low,Confirmed] https://launchpad.net/bugs/317357
<jam> I was just also letting Federico know that his patch had landed
<jelmer> jam: Ah, thanks. I read the emails out of order, that must be what confused me.
<Bersam> Hi everybody! how can i get an old version from bzr? "$bzr co lp:appname1.0" wont work!
<jelmer> Bersam: you can use tags - "bzr branch -rtag:bzr-1.0 lp:bzr bzr-1.0"
<Bersam> jelmer: thanks :)
<Jordan_U_work> Whenever I try to "bzr branch" from one of the branches I recently created it creates a branch without any checkout and I need to run "bzr checkout" to actually work with the files. Why is this happening but when I for instance "bzr branch lp:grub2" I get a branch with a checkout?
<maxb> Jordan_U: Please could you run "bzr info" within the problem branch and pastebin the result?
<Jordan_U> maxb: http://pastebin.com/ymzLpshR
<maxb> Jordan_U: A shared repository, amongst other things, contains a flag to set whether new branches default to having working trees or not
<maxb> As your info shows you are indeed within a shared repository, I imagine that that setting is to not create trees at present
<Jordan_U> maxb: Ahh, indeed I always use shared repositories. How can I change this flag?
<maxb> bzr reconfigure --with-trees / --with-no-trees
<Jordan_U> maxb: Thank you.
<maxb> The odd thing is the default is with trees, so something or someone must have switched it off explicitly
<Jordan_U> I only installed bzr on this machine recently, from Ubuntu 10.10 repositories. I don't remember ever changing this setting. It's possible I had bzr installed some months / years ago and removed it again but these repositories and branches were all created recently.
<fullermd> At one time init-repo defaulted to no-trees.
<fullermd> That was a loong time ago though.
<fullermd> grep of release notes says it went --trees in 0.15.
<fullermd> (i.e., 4 years and a month ago)
<Jordan_U> Maybe I do remember specifying --no-trees, though i can't remember why.
<fullermd> A little deforestation is good for the soul.
<Jordan_U> Ahh, I was in a hurry and just followed the example in "bzr help init-repo" which uses --no-trees.
<jelmer> moin
<magcius> oh man
<magcius> you know what I *love* about bzr?
<magcius> "bzr: ERROR: Unable to create symlink 'standard_test_template.py' on this platform"
<magcius> so instead of doing the sane thing, you just fail. And leave me with a .bzr dir.
<maxb> Patches gratefully accepted? :-)
<magcius> hasn't NTFS supported symlinks since like 1994?
<jelmer> magcius: That support isn't exposed in the Python API IIRC
<mgz> or in windows.
<mgz> the failure mode sucks, but so do most of the reasons people version symlinks.
<magcius> You can just copy the file instead of leaving me with ".bzr", though
<mgz> I would if I could, magcius.
<mgz> checking out from within cygwin is the best workaround I've found.
#bzr 2011-04-22
<magcius> mgz, http://msdn.microsoft.com/en-us/library/aa363866%28v=vs.85%29.aspx
<magcius> mgz, also, ctypes
<mgz> also need to be running as an administrator
<mgz> which is just what stopped happening by default in the release that api was made available.
<magcius> in Windows 7, users have the "Create symbolic link" permission by default
<magcius> but meh
<magcius> not worth it
<magcius> it would help if you guys just wouldn't *fail*
<mgz> I agree.
<mgz> what's your source on the symlink cap being for everyone under 7?
<mgz> I thought I'd read the opposite.
<magcius> personal experience
<magcius> I don't have the permission, and mklink works for me
<Jordan_U> How can i ignore mode changes? I'm working on a project locally (on my Ubuntu machine) and on a Windows machine accessed via CIFS and I don't want bzr diff or my commit history to be cluttered with mode changes.
<mgz> good question.
<mgz> Jordan_U: ask on the mailing list if no one pops up here with an answer.
<KombuchaKip> I have a commit I'd like to make to a repository I don't have write access to. How can my commit be sent as an email to the project maintainer?
<KombuchaKip> How can I generate a diff for my local working copy when it contains binary files that I added? Right now the binary data isn't generated in bzr diff output.
<cody-somerville> KombuchaKip, bzr send
<KombuchaKip> cody-somerville: I tried. I get a "ERROR: No submit branch known or specified"
<cody-somerville> KombuchaKip, 'bzr help send' to see which arguments it expects and how to use it
<KombuchaKip> cody-somerville: I used "bzr send -o ~/Desktop/Kip.diff" which is what the docs say.
<cody-somerville> You need to pass as the second argument the branch you wish to submit your changes to
<KombuchaKip> cody-somerville: How do I find that out?
<cody-somerville> KombuchaKip, Not sure I understand your question.
<KombuchaKip> cody-somerville: How do I know what the second argument is? I checked out my code from a URL at bzr://blah
<cody-somerville> KombuchaKip, thats the second argument
<KombuchaKip> cody-somerville: Right. But do I have to commit my changes locally first?
<KombuchaKip> cody-somerville: I was reluctant to do that in case the commit isn't accepted upstream or needs changing.
<cody-somerville> yes, you need to commit locally
<KombuchaKip> cody-somerville: But what happens if the commit isn't accepted upstream? Doesn't that cause headaches at my end because now the repos are not in sync?
<cody-somerville> KombuchaKip, You'd merge in any changes from them, make the changes they've requested of you, and then resubmit.
<KombuchaKip> cody-somerville: Is there not simply a way I can generate a current diff, including the binary files as well?
<cody-somerville> KombuchaKip, You could commit, then push your branch to somewhere they can access, and then ask them to merge your branch in
<KombuchaKip> cody-somerville: I think I'd prefer to just generate a diff, like I am used to with svn. How do I get bzr diff to generate binary diffs also?
<cody-somerville> KombuchaKip, You can't do that with svn. However, you can install bsdiff which is a program for generating and applying a patch between two binary files and tell bzr to use that via the --using argument to bzr diff.
<KombuchaKip> cody-somerville: That's possible, but convoluted. I guess they call it bazaar for a reason.
<cody-somerville> Just sharing your branch with them is much easier.
<cody-somerville> KombuchaKip, It has nothing to do with bzr - patches aren't optimal for representing changes to binary files since binary files aren't human readable and patches are intended to be.
<KombuchaKip> cody-somerville: Not quite. base64 is perfectly valid data for in a patch. Sometimes its necessary for non-plain text files that changed.
<bialix> good evening dear #bzr
<fullermd> Evening already?!  I've barely had lunch   :(
<bialix> my evening is your lunch :-D
 * bialix waves at fullermd
 * mgz waves at bialix
<bialix> hey Martin!
<magcius> is there a way I can get 'git add' like semantics?
<magcius> i made changes to a CSS file that I don't want to commit
<bialix> magcius: bzr shelve allows you git stash your changes; bzr view allows you to specify subset of the tree you work on
<magcius> bialix, bzr shelve doesn't allow me to pick out specific parts.
<magcius> It says "yes or no", and I want half of it.
<bialix> setup editor and then you'll be able to do so
<magcius> just $EDITOR?
<bialix> in bazaar.conf add to DEFAULT section:
<bialix> change_editor = vimdiff -fo @new_path @old_path
<bialix> or adjust the command line for your favorite editor
<bialix> magcius: ^
<magcius> emacsclient -e '(diff "@old_path" "@new_path")'
<magcius> yay
<bialix> in the shelve prompt press 'e' now
<magcius> why doesn't ^C work?
<magcius> now, when I press "y", I'm telling it to stash it?
<magcius> put it away for later?
<bialix> yep
<magcius> and how can I get it back?
<bialix> magcius: bzr unshelve
<magcius> ok, thanks!
<bialix> :-)
<ablmf333> I've 2 branch, 'svn' is a bzr checkout of svn branch, 'bzr' is branched from 'svn' by `bzr branch'.  Now 'svn' switched to a new branch, And I got lots of conflict when I try to merge 'bzr' to 'svn'.
<ablmf333>  I guess that's because the new svn branch is created later than those changes in 'bzr'
<ablmf333> Is there nice way to handle this?
#bzr 2011-04-23
<KombuchaKip> I'd like to get the last date of revision in my current working copy to be used in a Makefile. What is the recommended way to do that?
<fullermd> Look at version-info
<KombuchaKip> fullermd: Is that a bzr command?
<KombuchaKip> fullermd: It's pretty slow to run. Thanks though. I'll look into it.
<nealmcb> How do I get the logs for a file that is no longer visible?  bzr log password.c
<nealmcb> gives me : bzr: ERROR: Path unknown at end or start of revision range: libmysql/password.c
<jelmer> hi nealmcb
<jelmer> have you tried specifying a revision in which the file still exists ?
<nealmcb> jelmer: Howdy!
<nealmcb> well the first issue is figuring out when that would be
<nealmcb> jelmer: And I did try bzr log -r tag:mysql-4.0.1 password.c  which should have it, but got no result
<jelmer> nealmcb: shouldn't that be bzr log -r tag:mysql-4.0.1  libmysql/password.c ?
<nealmcb> well, I'm in that directory now, thought that was enough
<jelmer> yeah, it should be
 * jelmer tries to remember how the per file log logic works
<nealmcb> I also tried looking at a revision and later: bzr log -r tag:mysql-4.0.1.. password.c
<nealmcb> and got bzr: ERROR: Start revision not found in left-hand history of end revision
<nealmcb> jelmer: but this helps find where it still existed:  bzr ls -r tag:mysql-4.0.1
<nealmcb> ....if I do that for previous revisions with boolean search....
<jelmer> nealmcb: alternatively, it should be possible to just do "bzr log -v | less" and search for libmysql/password.c
<nealmcb> jelmer: useful trick - I thought about that before with just a grep, but then I wouldn't necessarily get all the context I wanted, which could be very big...
<nealmcb> it's also pretty slow to go thru the whole log....
<jelmer> Yeah; we should improve log to do the right thing.
<jelmer> It's not entirely trivial as there may have been multiple different files that have had that particular name over the course of history
<nealmcb> odd - the first hit was on revno 2 - so no log of the deletion??
<jelmer> nealmcb: there should be
<jelmer> nealmcb: perhaps its parent directory was renamed at some point before it was deleted?
<nealmcb> Ahh - https://bugs.launchpad.net/bzr/+bug/181520
<ubot5> Ubuntu bug 181520 in Bazaar "bzr log FILE don't show revisions where file was removed" [High,Confirmed]
<nealmcb> 3 years old....
<nealmcb> Got any handy scripts to do binary search on the "ls" command?  I can't think of anything better right now....
<jelmer> nealmcb: you're not using "bzr log FILE" now though are you?
<nealmcb> jelmer: Nope - bzr log -v |less
<jelmer> another thing you might try is "bzr log -r2.. libmysql/password.c"
<nealmcb> using Bazaar (bzr) 2.2.4
<nealmcb> I get bzr: ERROR: Path unknown at end or start of revision range: libmysql/libmysql/password.c
<nealmcb> Oh - removing libmysql/ since I'm in the directory -- and I get nothing
<nealmcb> (no error message, no log beyond what I see in revno 2)
<jelmer> this is in a standard mysql tree?
<nealmcb> oops - I had switched to look in a branch of an old revision....  now I'm getting logs
<nealmcb> jelmer: Ahh - good - this even shows me the removal:  bzr log -v -r2.. password.c
<nealmcb> when I use the right tree....
<nealmcb> but it sure would be nice to be able to find out the last time the file was removed.
<nealmcb> jelmer: thanks!
<jelmer> nealmcb: np
<jelmer> nealmcb: It would indeed be nice to have some way to refer to removed files, not just to files in the start or end tree.
<lifeless> bzr search can do some of that FWIW
<jelmer> ah, that's good to know
<nealmcb> lifeless:  No help could be found for 'search'
<jelmer> nealmcb: it's a separate plugin - lp:bzr-search
<nealmcb> lifeless: after install, bzr help search refers to a mysterious "QUERY" argument - where does one find more?
<lifeless> nealmcb: run bzr index
<lifeless> nealmcb: then bzr search libmysql/libmysql/password.c
<lifeless> hmm, I may not have wired it up; it certainly knows the path
<lifeless> nealmcb: I was mainly mentioning it to jelmer, in case he is looking at ways to address finding deleted files in core
<nealmcb> lifeless: Re: 'This locates documents in bzr at a given url and creates a search index for that url'
<nealmcb> I'm still puzzled - are documents just any sort of file?  url would typically be a local path (needs to be a file:// url or not?)
<nealmcb> is it a full-text index?  of all previous revisions?  If it is too big is there a way to delete the index?
<lifeless> its a full text index
<lifeless> paths, deltas to files etc
<lifeless> its stored in .bzr/bzr-search
<lifeless> you can just rm that dir
<lifeless> by url it means any location you can pass to bzr for e.g. info/log etc
<nealmcb> can I just index a directory?  I try   bzr index .   and it says that isn't a branch.
<nealmcb> would it return a hit for every revision, or summarize them somehow?
<nealmcb> (sorry to pester you with questions....)
<lifeless> nealmcb: you can only index a branch, though indexing a subdir of a branch is an interesting question its not been implemented
<lifeless> bzr index $(bzr root)
<lifeless> will find the root of your branch for you
<lifeless> I just did
<lifeless> bzr search socket timeout
<lifeless> in bzr
<lifeless> http://pastebin.com/NtsULbNn
<lifeless> is the output
<lifeless> its a little geekish
<lifeless> the revisions can be passed to other commands like log though - via '-r revid:$therevision'
<lifeless> or show in annotate with --show-ids, that sort of thing
<nealmcb> lifeless: Thanks for the tips, and the code!
<lifeless> my pleasure
<lifeless> if you wanted to file a bug on including/excluding paths to index, that would be cool.
 * lifeless afks
#bzr 2011-04-24
<lifeless> :( search selftest is failing
<lifeless> jelmer: AttributeError: '_LeafNode' object has no attribute 'items'
<jelmer> lifeless: :-( IIRC it was passing a couple of weeks ago, I did a Debian upload early March
<jelmer> lifeless: what version of bzr are you using? It passes here with bzr.dev
<lifeless> 2.2.4-0ubuntu1
<jelmer> hmm
<jelmer> the error looks vaguely familiar; it's likely somebody fix it in bzr.dev but I don't see any relevant NEWS items
<jelmer> Given your comment about commitfromnews I guess you might have been doing the same thing..
<lifeless> I looked up whether you use oo or Ã¶ for your name in bzr's NEWS
<lifeless> and noticed it was in multiple files now
<lifeless> which is wh I mentioned commitfromnews
<jelmer> ah
<jelmer> lifeless: thanks for the review and merge
<lifeless> my copy of bzr.dev does this:
<lifeless>  ~/source/baz/bzr.dev/bzr selftest plugins.search
<lifeless> 'module' object has no attribute '_parse_into_chk'
<lifeless> I'll pull in a sec
<lifeless> https://bugs.launchpad.net/bzr/+bug/707075/comments/27
<ubot5> Ubuntu bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New]
<glyph> So, the very first time I try to integrate bzr into an official process for Twisted: https://bugs.launchpad.net/bzr/+bug/769973
<ubot5> Ubuntu bug 769973 in Bazaar "bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Undecided,New]
<glyph> getting the branch works normally, just not in my shared repository.
<mgz> bug 485601?
<ubot5> Launchpad bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [High,In progress] https://launchpad.net/bugs/485601
<mgz> poke jelmer for more info.
<mgz> comment #25 there may be useful to you.
<mgz> ...and comment #26 is from you.
<glyph> Does 'in progress' mean that he figured out the cause?
<mgz> it sort of implies it, but I don't know more.
<jelmer> hi glyph, mgz
<jelmer> Yes, I have figured out the cause. It's basically the thing I'll be working on next week.
<jelmer> it's the blocker for bzr-svn 1.1.0
 * jelmer hops on a train
<glyph> excellent! thanks, jelmer
<glyph> Okay, now https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/769992 is gumming up the same process.
<ubot5> Ubuntu bug 769992 in bzr-svn (Ubuntu) "bzr: ERROR: exceptions.KeyError: 'No such TDB entry' " [Undecided,New]
<lifeless> jelmer:  bzr st
<lifeless> 'module' object has no attribute '_parse_into_chk'
<lifeless> 'module' object has no attribute '_parse_into_chk'
<lifeless> /home/robertc/.bazaar/plugins/loom/formats.py:57: DeprecationWarning: __builtin__.type.register_format was deprecated in version 2.4.0.
<lifeless>   map(_mod_branch.BranchFormat.register_format, branch_formats)
<lifeless> type object 'BzrDirFormat' has no attribute 'register_control_format'
<lifeless> 'module' object has no attribute '_parse_into_chk'
<lifeless> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_parse_into_chk'
<lifeless> jelmer: tip bzr.dev
<jelmer> lifeless: that should be fixed with newer revisions of bzr-loom
<jelmer> lifeless, the deprecation warning / 'register_control_format' thing I mean
<jelmer> I'm not sure about _parse_into_chk
<jelmer> lifeless: Can you reproduce this with --no-plugins as well?
<lifeless> yes
<lifeless> and after doing a make clean
<lifeless>   File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/btree_index.py", line 1596, in <module>
<lifeless>     _gcchk_factory = _btree_serializer._parse_into_chk
<lifeless> AttributeError: 'module' object has no attribute '_parse_into_chk'
<lifeless> bzr 2.4.0dev2 on python 2.6.6 (Linux-2.6.35-28-generic-x86_64-with-
<lifeless>     Ubuntu-10.10-maverick)
<lifeless> arguments: ['/home/robertc/bin/bzr', 'st', '--no-plugins']
<lifeless> ah
<lifeless> wrong dir
<jelmer> I can't reproduce it, neither with nor without compiled extensions and current tip
<jelmer> ah
<lifeless> I was rebuilding bzr.dev, but running from bzr-test-fixes
<lifeless> doh ;)
<lifeless> jelmer: robertc@lifeless-64:~/source/baz/plugins/loom/trunk$ bzr st
<lifeless> type object 'BzrDirFormat' has no attribute 'register_control_format'
<lifeless> remaining fallout
<lifeless> ah
<lifeless> cvs
<lifeless> done
<jelmer> great
<lifeless> jelmer: did my review of your fixup branch make sense ?
<lifeless> jelmer: also I meant to suggest, but forgot, that perhaps some folk would want to add in ids via a regex
<jelmer> lifeless, yes, thanks
<jelmer> I'll make a few improvements
<lifeless> jelmer: though thats clearly a future enhancement
<jelmer> yeah, I had that in mind too. That's what Samba does at the moment.
<jelmer> train arriving.. back later
<mgz> jelmer: the twisted guys also filed bug 769992 if you were off for that bit of the chat.
<ubot5> Launchpad bug 769992 in bzr-svn (Ubuntu) "bzr: ERROR: exceptions.KeyError: 'No such TDB entry' (dup-of: 664085)" [Undecided,New] https://launchpad.net/bugs/769992
<ubot5> Launchpad bug 664085 in bzr-svn (Ubuntu) "bzr crashed with KeyError in get_revision_paths() on running update from subversion repo" [Undecided,New] https://launchpad.net/bugs/664085
<lifeless> mgz: whats the story for py3 and you ?
<mgz> I have a build of their trunk around, but don't use it for day to day programming.
<lifeless> mgz: I'd like to talk about subunit, unicode and bytes.
<mgz> surething.
<lifeless> this branch
<lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/subunit/py3
<lifeless> has tres initial work fixed up and additional work from me
<lifeless> we have code like this
<lifeless> :
<lifeless> -        protocol.readFrom(StringIO(output))
<lifeless> which I'm proposing to change to
<lifeless> -        protocol.readFrom(BytesIO(output))
<lifeless> because subunit defines a byte protocol not a string protocol; it shouldn't crash if someone shoves crap into it
<lifeless> which any decode-before-processing approach would do
<lifeless> do you see any interactions with windows code pages etc if I do this?
<mgz> yeah, the meaning of StringIO has shifted a bit
<lifeless> on 2.6 BytesIO will be StringIO
<lifeless> on 3 io.BytesIO
<mgz> I've always used it more as a file-like bytestream more than a text stream, in fact I don't think cStringIO does unicode at all
<lifeless> https://code.launchpad.net/~lifeless/testtools/misc/ adds that to testtools
<lifeless> cStringIO does unicode, but has a wonderful bug if you do cStringIO.StringIO(u"foooo")
<lifeless> you then get to read the octets back out
<mgz> the only real pain on windows is when the pipe happens to be pointing at a console
<mgz> which generally it won't be for subunit
<lifeless> in or out? or either ?
<lifeless> also I'm again feeling motivated to bitch about the lack of startswith etc on bytes.
<lifeless> WTF were they thinking/.
<mgz> potentially both. there's a wide api that can be used, but generic code uses a bytes-only approach that does mbcs transcoding
<lifeless> mgz: so, GIGO applies; if we get some pastiche of uncide + a jpeg or whatever in
<lifeless> we should preserve it in subunit-filter
<lifeless> mgz: I'm planning on saying 'we serialise by utf8 for backtraces'
<mgz> I can't imagine many people will expect typing in a subunit stream to work at all, and printing junk to the console is just an annoyance.
<lifeless> mgz: and for passing old-style backtraces (the [...] encoding) do a decode(error=replace) for things that need to be passed to python code
<mgz> well, did subunit previously do anything special for non-ascii in tracebacks?
<lifeless> it didn't matter
<lifeless> py2
<lifeless> you could pass ascii around and yawn
<mgz> ah, so you just got whatever bytes you had anyway, and if it was junk it was junk.
<lifeless> but remember all the headaches you had on testtools ?
<mgz> yeah, I just wondered if you encoded anything
<lifeless> I'm trying to fit in nicely with that :)
<lifeless> theres some primitive stuff
<mgz> so, just using utf-8 consistently will be like a bugfix, no?
<lifeless> I think I can make that case
<mgz> before you might get non-ascii in a traceback and not know what it is.
<mgz> now with py3 it'll be utf-8 all the time.
<lifeless> once I get over this rage about having to workaround useful functions being removed.
<mgz> I wouldn't mind a pretty serious cut down of string methods if python had a good alternative for bytes-wrangling
<mgz> but when I have to deal with microlanguages is one of the few times I find myself pining for perl
<mgz> it's annoying how much python needs to be written to do something as basic as interpret a particular http header field correctly.
<lifeless> yeah
<mgz> the diff of the last few revs in that subunit branch looks fine to me.
<lifeless> yeah, thats the easy mechanical
<lifeless> now I'm into
<lifeless>   File "/home/robertc/source/unittest/subunit/working/python/subunit/__init__.py", line 215, in lineReceived
<lifeless>     cmd = cmd.rstrip(':')
<lifeless> TypeError: Type str doesn't support the buffer API
<mgz> you got split still?
<mgz> that's a workable alternative idiom
 * mgz checks
<mgz> hm, that's just a confusing error message.
<mgz> cmd = cmd.rstrip(_b(':')) would work, but maybe rearranging is preferable.
<lifeless> yeah
<lifeless> I've just tweeted all that ;)
<lifeless> I really think the balance is wrong.
<mgz> I think the py3k approach to strings is a bit last-decade.
<mgz> ...or even two decades.
<mgz> unicode-by-default was the motivating factor for the windows switch to 'wide' apis
<LeoNerd> Except they did it in UCS-2
<mgz> using typing to avoid injection attacks and limit transcoding seems more trendy these days.
<mgz> ^so does Python, LeoNerd. or (in some ways) worse, UTF32
<LeoNerd> UTF-32 / UCS-4 is fine
<mgz> which is part of the complaint about extra overhead from some applications looking at porting currently.
<LeoNerd> It gives constant-width lookup to any codepoint in the string.
<LeoNerd> It's UTF-16 that's the killer.. all the bad points about UCS-4 (uses null bytes, inefficient for ASCII) combined with all the bad points about UTF-8 (variable-width encoding)
<mgz> lots of things are just about moving bytes around, not doing much parsing on them, and the extra allocation hurts.
<mgz> utf-16 most people don't handle astral characters properly anyway, so there's no extra parsing overhead
<mgz> it's just sometimes, in ways nearly no one will notice, incorrect.
 * maxb lols at "astral characters"
<maxb> very apt. I like it
<lifeless> python's build on ubuntu is 4-byte chars
<lifeless> its -terrible-=
<lifeless> want to know why bzr uses so much memory? dingdingdingding
<mgz> yeah, and there aren't handy ways of using more compact data structures in python when that's what you want.
<LeoNerd> maxb: You've never heard them called the Astral planes, before?
<lifeless> the common case for /some/ apps will be a bunch of kanji or whatever; but the common case for bzr is ascii strings - so we pay 300% overhead for the common case
<LeoNerd> I was talking about Planes of Unicode on #perl a while ago.. someone made a joke wondering if there's any snakes on them
<maxb> First time I've heard that particular pun
<LeoNerd> Turns out, yes.. there's two: CJK RADICAL SNAKE and COMBINING SNAKE. :)
<lifeless> awesome
<LeoNerd> U+2E92
<lifeless> \o/ test engine completes now
<lifeless> time to fix the tests
<lifeless> mgz:   File "/home/robertc/source/unittest/subunit/working/python/subunit/__init__.py", line 1141, in _make_stream_binary
<lifeless>     _make_binary_on_windows(stream.fileno())
<lifeless> io.UnsupportedOperation: fileno
<mgz> heh.
<mgz> if we're lucky... they do that be default now.
<lifeless> mgz: I've pushed rev 145
<mgz> if we're unlucky, the rewriters decided people shouldn't be allowed to look at the underlying handles any more.
<lifeless> which triggers that error for me on Ubuntu
<lifeless> if you want to look at the windows path
<mgz> most likely, it'll just need a different spelling.
<mgz> `sys.stdout.buffer.raw.fileno()` looks like it'll do
<mgz> which is a bit daft just to get `1`
<lifeless>   File "/home/robertc/source/unittest/testtools/working/testtools/content.py", line 64, in __eq__
<lifeless>     _join_b(self.iter_bytes()) == _join_b(other.iter_bytes()))
<lifeless> TypeError: sequence item 0: expected bytes, str found
<lifeless> recursion, see under recursion
<mgz> hm, I remember frowning at that method before.
<lifeless> one of the content objects has a string the other a bytes
<lifeless> or possibly both
<mgz> yeah, and the way it's spelt doesn't tell you which or where.
<mgz> but I guess otherwise you're trying to compare lists with different length byte chunks in, which is also a pain
<mgz> okay, so the previous error was just their heirachy stuff means lots of things have fileno method that will just raise
<mgz> perhaps switching to `try:_make_binary_on_windows(stream.fileno());except (AttributeError, io.UnsupportedOperation):return;` would work but finding a compatible way to spell that may be hard
<mgz> `no_fileno = _is_py3k and io.UnsupportedOperation or AttributeError` in long form maybe.
<lifeless> I'm just chasing lower level things atm
<lifeless> I can try that in a bit
<lifeless> unless you have a ubuntu vm or something?
<mgz> sec, I'll try setting up here then can maybe give you a branch for some specific things.
<lifeless> hhhha
<lifeless> and after all the fuss about type safet
<lifeless> y
<lifeless>             if cmd in ('test', 'testing'):
<lifeless> guess what that doesn't do
<lifeless> if cmd is b'test'
<mgz> heh.
<lifeless>   File "/usr/lib/python3.1/unittest.py", line 1395, in startTest
<lifeless>     self.stream.write(self.getDescription(test))
<lifeless> TypeError: must be str, not bytes
<lifeless> >< >< ><
#bzr 2012-04-16
<jam> morning all
<LarstiQ> hei jam
<jam> morning LarstiQ
<jelmer> hey vila
<jam> vila: did you see the "jubany package importer stopped" email from stephanie?
<vila> jam: james_w and maxb know more about that, AIUI they both deployed stuff there that is leading to the actual problems
 * vila lunch bbl
<maxb> ah
<maxb> seen
<maxb> I can prod at that, but ultimately it seems to be fallout from the stormification
<maxb> I suppose we could roll back the use of storm.... but that might irk james_w a bit
<maxb> ( jam / vila bing ^ )
<jam> maxb: right, I think the big thing is working with james_w to either polish storm use, or nuke it
<maxb> I have nothing to do with the introduction of the problem, so from my perspective, james_w fixes soon, or we nuke
<vila> hmm, this went out a bit ambiguously, I didn't mean to throw stones (I rarely do ;), I meant I wasn't aware of the details but james_w and maxb were. So +1 on what jam and mabx said ;)
<maxb> I know nothing about storm myself, so it looks like james_w might have turned himself into a bit of a SPOF by introducing it :-/
<avalon_> Hi, using bzr in win7 and cant do a commit - bzr is treating all filenames as case sensitive - i think i can fix it if i delete a couple of files but i can only get an add option and no delete - any help available?
<LarstiQ> avalon_: what is commit complaining about?
<avalon_> LarstiQ: it says it cant open the files - there is no reason for that - all that happened was 2 files were renamed withl lower case from mixed
<LarstiQ> avalon_: does `bzr status` show them as missing, and then the renamed files as unknowns?
<avalon_> LarstiQ: yes
<LarstiQ> avalon_: I'm looking for an option to deal nicer with case-insensitive filesystems, but one thing you could do is `bzr mv --auto` to make it try and infer the move
<avalon_> LarstiQ: don't understand but i'll try - thanks for the help
<LarstiQ> avalon_: `bzr mv --auto` tries to automatically guess renames
<LarstiQ> ah..
<alexeiser> Any one available to provide advice about smart server jails? Specifically about how to have plugins make calls outside of the jail.
<jelmer> LarstiQ: hey, did you see my recent email about bzr package maintenance?
<gerard_> Hey all, want to do my brother a favor by participating in this survey? It's about the motivation of open source programmers and takes about 7 minutes: https://uleidenss.eu.qualtrics.com/SE/?SID=SV_8jgmLHsvuymV36s
<nDuff> Is there a way to take advantage of a local svnsync read-only mirror for purposes of populating bzr-svn's metadata cache??
<lifeless> nDuff: if it has the same repo guid
<lifeless> nDuff: then it will populate the same metadata cache
<nDuff> ...hmm. Is "bzr shelve" expected to work against a SvnWorkingTree (bzr 2.4.1, bzr-svn 1.1.0)?
<thomi> I'm getting a crash in lp-propose because for some reason bzr can't talk to gnome-keyring. Any idea how I fix that without rebooting? The bug is https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/728548 which is marked as a duplicate of #534326 , which is marked as fix-released, but it's still at large in precie
<ubot5> Ubuntu bug 534326 in Bazaar GTK+ Frontends "duplicate for #728548 bzr: ERROR: gnomekeyring.IOError:" [Medium,Fix released]
<jelmer> thomi: hi
<jelmer> thomi: that's not the bzr-gtk bug
<jelmer> nDuff: you probably want a newer version of bzr-svn for that
<jelmer> thomi: it's a bug in python-keyring, which launchpadlib uses
<thomi> jelmer: yeah, it looks like the 'duplicate bug' thing on lp is incorrect?
<jelmer> thomi: it's actually bug 885732
<ubot5> Launchpad bug 885732 in python-keyring (Ubuntu) "breaks application when Gtk3 is also used" [Undecided,Confirmed] https://launchpad.net/bugs/885732
<jelmer> I've fixed the dupe
<thomi> cheers
<nDuff> ...so, "svn info $URL" shows the same UUID for both the original repo and my svnsync mirror, but when I try to run "bzr info" against the original after populating the cache against the mirror, bzr-svn goes back and starts a refetch.
<nDuff> there's only one directory in ~/.cache/bazaar/svn/, so it's not reading the UUIDs as different...
<nDuff> ...perhaps does it not bother populating the cache for local repos?
<jelmer> nDuff: it doesn't populate the cache for local repositories
<nDuff> ahh!
<nDuff> is there a way to force contrary behavior?
<jelmer> IIRC you can set "use-cache = True" for the relevant repository in ~/.bazaar/subversion.conf
<nDuff> that did it; thanks!
#bzr 2012-04-17
<thomi> bzr pipelines are awesome!
<thomi> one thing though: when I do 'lp-propose' from within a pipeline, it sets the target to something really strange. Seems like an unrelated branch on the same project....
<thomi> ...when I specify the submit branch on the command line (to be 'lp:unity') I get this error:
<thomi> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/unity/" and relative path "../../../~anjali-team/anjali/unity/"
<thomi> O.0
<spiv> thomi: ah, heh, I'd guess that's a bug in bzr-pipeline
<thomi> :( Worth filing a bug for it?
<spiv> thomi: where it's assuming that all LP branches have URL paths like /~owner/proj/name
<spiv> (hence the ../../.. to get to the root of LP)
<thomi> hmmm I see
<spiv> I think so, I imagine abentley would know how to fix it icleanly
<thomi> ok
<thomi> hmm, also, if I exit $editor without making any changes after doing a 'lp-propose' I get a message that says "Commit message was not edited, use anyway? ([y]es, [n]o): ". If I pick "no", It still creates the merge proposal. Is this the intended behavior?
<thomi> I expected it to abort the MP
<spiv> thomi: well, that behaviour sounds surprising to me, so that makes two of us!
<spiv> thomi: so yes, please file a bug
<thomi> ok.
<thomi> BTW, first bug is here: https://bugs.launchpad.net/ubuntu/+source/bzr-pipeline/+bug/983576
<ubot5> Ubuntu bug 983576 in bzr-pipeline (Ubuntu) "pipelines assume ~ownder/project/branch_name format for submit branches" [Undecided,New]
<spiv> (You're welcome to file a bug even for issues you're not sure about; it doesn't take much effort to close them)
<thomi> I guess so. Thanks for your help
<astraljava> Hi gang, I just installed bzr 2.5.0 on Mac OS X Lion, and the sed for python mentioned in the wiki isn't needed anymore, the script already sets python2.6. Just thought I'd let you know so users won't be confused.
<astraljava> Thanks for making it possible to hack ubuntu even on a Mac! :)
<vila> astraljava: it's a wiki :) Give it a shot
<Merwin_> hi
<jelmer> hi Merwin_
<astraljava> vila: I figured it being under canonical's domain, I wouldn't have privileges to modify. I'll give it a shot, but it doesn't seem to authenticate me.
<vila> astraljava: even with a launchpad account ?
<astraljava> Ahh... finally let me in.
<vila> ha great
<astraljava> Sorry, it just took a long while.
<vila> no worries
<astraljava> It's randomly rather slow. Now it just won't find that page again after logging in.
<nDuff> Can more modern releases of bzr-svn resume where they left off when caching svn metadata is interrupted?
 * nDuff has yet to be able to get through his 146,000-revision history without *something* causing an interruption.
<jelmer> nDuff: yes, though older revisions should be able to, too
<nDuff> jelmer: ...hmm; On 1.1.x, I've yet to see that happen.
<abner> Hi there. Is there an easy way to push commits to a bzr repo/branch from a git tree?
<nDuff> abner: see http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html and/or http://wiki.bazaar.canonical.com/ForeignBranches/Git
<bj0> is there a way to revert part of a file or branch to a previous revision? (use merge somehow?)
<jelmer> bj0: bzr revert -rREV FILE
<jelmer> bj0: or indeed by using bzr merge -rNEWREV..OLDREV FILE
<bj0> cool
#bzr 2012-04-18
<vivekimsit> Hi, I just want some immidiate help :(
<vivekimsit> I have checkout one branch from launchpad
<vivekimsit> now I am on rev12 and my collegue is on rev19
<vivekimsit> how can I get my code updated?
<spiv> vivekimsit: 'bzr pull'
<vivekimsit> ok! I was really confused b/w pull and up, pls can u tell me something about up also and thanks
<spiv> (Or perhaps 'bzr update' if you used 'bzr checkout' rather than 'bzr branch' to get the branch; refer to the docs for the details if you want)
<spiv> In short: update updates a checkout to be current with the branch it is a check of.
<spiv> 'pull' updates a branch to be current with another branch (by default the branch it was branched from).
<vivekimsit> I used bzr co!
<vivekimsit> so I should use up?
<vivekimsit> I am getting an error while doing 'up'
<vivekimsit> bzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/
<vivekimsit> bzr: ERROR: No WorkingTree exists for "bzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/".
<fullermd> You sure you're just doing "bzr up", not putting stuff after it?
<vivekimsit> shit! I did this : bzr up lp:~synerpgy/synerpgy-projects/destock_dev
<vivekimsit> ok! how to undo my last commit ?
<LarstiQ> vivekimsit: so for the update do `bzr up` instead of `bzr  up lp:~synerpgy/synerpgy-projects/destock_dev`
<vivekimsit> ok
<LarstiQ> vivekimsit: then, if your question about commit is unrelated to that, use `bzr uncommit`
<LarstiQ> if it is related, maybe I should first figure out what exactly is going on
<vivekimsit> Ok! now some more small problem
<vivekimsit> I have done bzr up and now I am getting some weird things in my source !
<bob2> do you mean conflict markers?
<vivekimsit> <<<<<<< TREE, >>>>>>> MERGE-SOURCE
<bob2> == conflict markers
<vivekimsit> ya
<vivekimsit> So do I need to remove them manually?
<bob2> alas bound checkouts make this painful
<bob2> iirc
<vivekimsit> is there not any command line option to do it automatically
<bob2> ?
<bob2> the point is that bzr tried to merge automatically and failed, because both sides had touched the same lines of the file
<vivekimsit> its means no!
<bob2> same thing in every version control system
<vivekimsit> ok! can I undo my last update?
<bob2> it sounds a lot like you had uncommited changes?
<vivekimsit> No, its like I did bzr up, now I want to undo it
<bob2> but you did bzr up with uncommited changes?
<vivekimsit> yes!
<bob2> as far as I know, there's no easy way to get it back
<bob2> someone else may know an answer though
<bob2> (always commit before doing a thing!)
<vivekimsit> ok! the current scenario is I did 'up' and as you know there were some conflicts, and I now there is one more rev in remote branch so I need to do 'up' again. So, I am just afraid that do I need to fix my conflicts first or just do 'up' again and fix conflicts later!
<bob2> no, don't up again
<vivekimsit> so, what to do I have to make my code upto date!
<bob2> what you should have done is commited and done a bzr pull
<vivekimsit> actually I did was a co, there I had thought of options either revert it and do up again!
<vivekimsit> someone told me here that for co we do upo
<vivekimsit> up
<bob2> well yeah, but that does this, which is not very useful
<vivekimsit> ok! how to manually remove all conflicts?
<bob2> by editing the files with a text editor
<vivekimsit> so which lines should I remove ?b/w tree and ===
<Merwin_> hi
<vivekimsit> What is text conflicts?
<jave> hello
<bob2> == conflicts within the file
<jave> I get a weird "killed" message in the middle of merging from a remote repository. locks are left dangling
<jam> jave: is it taking a while? It sounds like something is killing your connection. So one option might be to branch locally and then do the merge.
<jave> jam: yes it takes quite a while
<jave> jam: but I'm not really sure what you mean with a local branch? I already have a branch that I would like to merge from uptstream
<jave> this is the Emacs repository btw. I'm using the Fedora 17 beta so maybe there is some issue with the bzr version they provide
<jave> Bazaar (bzr) 2.5.0
<LarstiQ> jave: jam's suggestion was to `bzr merge path/to/local/copy`, instead of `bzr merge remote/branch`
<jave> LarstiQ: okay
<nDuff> Hmm. During a "bzr commit" (to a lightweight svn checkout): SubversionException: ("'http://subversion.tigris.org/xmlns/dav/md5-checksum' was not present on the resource", 160013)
<wodemaye> Hi, I'm pretty new and trying to learn BZR, but before I invest too much effort into learning it, I want to know if I can essentially use it as a git client.  IE, I want to participate in a project on github.  What I've read tells me that I won't be able to "push" but I can't really figure out what this means.
<nDuff> wodemaye: "pushing", in this context, is sending changes you made back into the remote git repository.
<nDuff> wodemaye: ...that said, you _can_ use bzr dpush to put your changes from bzr into git, but it's not completely lossless in terms of metadata.
<nDuff> the metadata that's lost using dpush probably isn't critical -- things like rename info (which git just doesn't have as a concept)
<wodemaye> nDuff, so... I wouldn't lose any metadata on my local metadatabase, right?
<wodemaye> and the commit descriptions would go through.  and the updated state of the entire dir under bzr version control will be pushed up to github?
<wodemaye> as in all of my actual changes to the codebase would stay intact?
<nDuff> the changes themselves would stay intact, yes; the metadata... well, it wouldn't be _destroyed_ as such, but if you're working from the remote branch (which you'd want to do), you wouldn't still be working on the places it's attached to, so its continuing local existence is mostly just academic.
<nDuff> the other thing is that I haven't personally used the git foreign branch support, so I can't make promises about its stability
<wodemaye> nDuff, no worries. can you please elaborate on working on the remote branch? what does that mean? also, what sorts of metadata is it that gets lost?
<nDuff> wodemaye: as mentioned before -- renames, mostly; git refuses by design to think about directories as first-class objects, so it doesn't have any way to record operations on them.
<nDuff> wodemaye: ...re: "working on the remote branch" in that context -- presumably after you've pushed your changes, other folks will make other changes on top of them, and you'll want to check out and work from that version, rather than working from your local branch in bzr that still has full metadata attached.
<wodemaye> but they would still be reflected in the github version, right? if i branch a github repo, then rename oldname.txt to newname.txt, then dpush the repo back up, then someone else clones the repo with a real git client, they won't see oldname.txt anymore will they?  would it just appear as though i'd deleted oldname.txt and added a new file called newname.txt with coincidentally identical contents?
<wodemaye> nDuff, also, you say "things like" ... rename info.  what other things "like" it are lost?
<wodemaye> and thanks for answering my qs btw.
<jelmer> wodemaye: revision properties, like bug info
<jelmer> multiple authors, references to ghost revisions (which are unlikely to occur unless your project was ever imported from svn or baz)
<wodemaye> jelmer, k, thx.
#bzr 2012-04-19
<cpuchip> hello, I'm new to compiling from source, but I've been interested since I've stuck on ubuntu 9.04 on arm. I've been successfull at building bzr 2.50 from source, but I'd like to make it a deb package so I can distribute it to my friend who has the same setup. I don't see where the debian/control or changelog files can be found to make this possible, will have have to create them from scratch?
<spiv> cpuchip: why not grab them from the (current) ubuntu package sources?
<lifeless> cpuchip: add the bzr ppa, then do apt-get source bzr
<cpuchip> oh? the launchpad.net/bzr/+download? or is this a different location for the source?
<cpuchip> looking at https://launchpad.net/~bzr/+archive/ppa I don't see jaunty on the list. but I guess I can pull from those packages. anyway.
<cpuchip> lifeless, spiv: I think I found what I needed here: http://ppa.launchpad.net/bzr/ppa/ubuntu/pool/main/b/bzr/ but I'll have to backport from lucid to jaunty.
<lifeless> I'm pretty sure jaunty is entirely unsupported now ;)
<cpuchip> lifeless it is. but motorola decided to move forward with it on their Motorola Atrix phone for webtop (ubuntu 9.04) so I've been dealing with that, fortunately their later phone sport ubuntu 10.10, unfortunately I'm stuck with the atrix.
<cpuchip> I was able to compile from source bzr 2.5.0 orig and it work's just fine, I just didn't want to install it from source bypassing the package manager (apt-get)
<cpuchip> I might as well install from source on this one.. I'd have to migrade debhelper from 7.0.7 to 7.4.15 and that's proving to be no fun. thanks guys, I might try again tomorrow for fun again.
<Merwin_> Hi vila, could you give me some advices on how to handle upgrades and bug fixes in branches ? If you have time ;)
<vila> Merwin_: remind me about your setup ? Centralized branch and lightweight checkouts /
<vila> ?
<vila> or just regular branches and a public shared branch ?
<Merwin_> We have a dev branch we all branched/checkout from
<Merwin_> Developpers regulary push on it (either from their checkout or from a branch)
<vila> so, they merged their changes locally and then push ?
<Merwin_> We also have a "production" branch which is synchronised from the dev branch regulary
<Merwin_> Yes vila
<vila> ok, good
<vila> In this case, they are already working with so-called feature branches where the real work happen
<Merwin_> Sometimes my boss comes to me and tell me "Update all what X did today please, but not what Y and Z pushed a few moment ago"
<vila> ouch
<vila> so 'push --overwrite' ?
<Merwin_> update = merge into the production branch
<Merwin_> They, currently, I have to check the log, and take commits one by one, merging them with -c number of -rxxx..yyy if they follow.
<Merwin_> Then*
<vila> right, cherry-pick
<vila> that means that when you later try to merge th dev branch you may encounter conflicts
<Merwin_> But that's a nightmare to maintain, I have to commit after each merge (I can't do a commit after all commits I want have been merged)
<Merwin_> There is no other way to do this
<Merwin_> ?
<bob2> topic branches
<vila> well, you can use 'merge --force' but the commits at least give you a point you can revert to
<vila> and provide *some* readability for your production branch...
<vila> it
<Merwin_> Yeah, 15 commits named "Commit after merge" is not what I call readability lol :P
<vila> it's really a workflow issue you have here, all of you validated their additions to dev, cherry-picking them means you have to validate unknown mixes of changes
<vila> you can use better commit messages :) "cherry-pick feature A"
<Merwin_> vila, but the feature is dipatched in more than one commit :p
<Merwin_> vila, what workflow should I use then ? We are ready to change if it's for the better
<Merwin_> best*
<LarstiQ> Merwin_: develop the feature in its own topic branch as bob2 suggested
<vila> well, if you land intermixed changes on dev, you can't properly cherry-pick them :)
<bob2> note that it's at best a part-solution
<bob2> the real solution is to not write bugs!
<vila> so as bob2 said: use feature/topic branches and make sure they are complete *before* merging them to dev
<Merwin_> LarstiQ, bob2 : and merge from the branch regulary ?
<bob2> Merwin_, no
<vila> Merwin_: no, when you're ready to land on the dev branch,
<vila> get an up-to-date dev branch, merge your feature branch, make sure it works, commit, push
<vila> the gate-keeper model does that in an automated way relying on a test suite to "gate" changes
<Merwin_> And then on the production server I just have one commit to merge
<bob2> you don't do merges on production servers
<vila> I agree with bob2 :)
<Merwin_> bob2, ah ?
<vila> you validate the dev branch so that the production branch you can always pull from dev ;)
<Merwin_> Hum
<vila> s/branch you/branch/
<Merwin_> And if there are some bugs (because they always have)
<vila> the tool is not a magic bullet
<vila> it can help you organize your workflow though
<bob2> +1
<vila> in this case, you fix the bug in the feature branch and then your merge it again
<vila> It's a bit hard to explain without pictures, do some tests and look at the result with 'bzr qlog'
<vila> you can look at lp:bzr which use the gate-keeper workflow,
<Merwin_> You're welcome in France to show me how it works with pictures :)
<Merwin_> I'll take a look, thanks
<vila> Merwin_: you're welcome in Strasbourg to look :)
<vila> Merwin_: each commit on lp:bzr mainline is a merge
<vila> the merged branch can have one or several commits
<bob2> except for the first few dozen ;p
<vila> bob2: hehe, yeah, merge was implemented a bit later ;)
<Merwin_> hum ok
<vila> but pqm (our gate keeper) has been used for more than a couple of years now ;)
<Merwin_> Wand when you backport a bugfix into an old version, how do you do ?
<vila> Merwin_: in some cases, the same feature branch is merged repeatedly and qlog will show you that
<vila> ha, backport...
<vila> http://wiki.monotone.ca/DaggyFixes/
<vila> ideally you start fixing in the oldest version so you can merge 'up' into the newer ones
<bob2> hahaha
<vila> :)
<vila> hey, we're talking ideal workflows or not ? :)
<vila> the point is that daggy fixes are the easiest and give the cleanest history
<vila> backports now...
<Merwin_> Ok, that's the best way nobody uses ? :D
<vila> there are two main cases
<vila> no no no, I do daggy fixes as much as I can
<vila> 1) you can just cherry-pick the exact change and be done
<vila> you just have to merge up until dev where small conflicts (generally trivial) can occur
<vila> 2) you cannot cherry-pick because the fix is not compatible with the old version
<fullermd> The advantage of daggy fixes is that you never have to cherry-pick anything; the history is all fully connected.  The downside is that (a) you have to plan to do it, and (b) you can setup a lot of work if the LCA is a long ways back.
<vila> in that case you can sort-of start with the actual fix and make it work
<bob2> man, i haven't heard anyone say least-common-ancestor in forever
<vila> :)
<fullermd> Obviously, you don't hang out here enough  ;p
<Merwin_> ok, it's clearer thank you.
<vila> Merwin_: overall, keeping the shared history clean pays off big times
<fullermd> vila: Funnily enough, I accidentally looked at babune last week and have been meaning to corner you about those sphinx messages   ;p
<Merwin_> My bosses don't want to do branches. They all uses checkout because "it's simpler" : They don't need to commit nor merge.
<Merwin_> The thing is that it's not them who cherry-pick 20 commits because of "Put this in production now"
<fullermd> So, they want to create everything mashed together, and then for you to separate it all out later.  Luckily, they pay bonuses to you for doing it.
<Merwin_> fullermd, "luckily" :)
<vila> or said otherwise: sh** always go down, if you have to handle it, do so sooner rather than later
<fullermd> You should cook them a nice dinner to thank them.  Flank steak, mashed potatos, asparagus, minestrone.  Pumpkin pie for desert, say.
<fullermd> Of course, you'll make it by putting all the ingredients in one pot at the beginning, then subjecting the whole thing to each step of the preparation.
<fullermd> They can just separate out the bits themselves if they want to.
<vila> Merwin_: yes ;)
<Merwin_> hahaha nice idea :)
<Merwin_> vila, do you do training on bzr ? :D
<vila> Merwin_: canonical (my employer) does (I may be involved ;)
<Merwin_> Do you have a link or something to get an idea about prices, etc ?
<vila> http://www.ubuntu.com/contact-us
<fullermd> vila: So, you have an idea what's up with that TestTCPServer failure?  It seems consistent on the handful of runs I looked at, and passes every time for me (though occasionally dumping a thread warning)
<vila> fullermd: <shudder> don't start me on this topic
<vila> let say it's a known transient failure
<fullermd> Haha.  That's silly.  Surely there's no such thing.
<vila> haha
<vila> oh, and I have a fix for the sphinx failures, approved already, I should land it
<fullermd> Yah, I saw the MP.
<vila> oh, and I'm migrating away from vbox to kvm so expect hiccups on babune too ;)
<fullermd> Oooh, I see your strategy.  babune works -> fullermd looks at it -> fullermd bugs vila.  If we break the chain one place, we're safe everywhere   :p
<Merwin_> why do you migrate  to kvm?
<vila> . o O (rats, uncovered)
<fullermd> Obviously, so that the one slave I bother to look at stops working   :p
<vila> well, the slave is causing problems is... the windows one
<vila> I still have to address some networking issues but freebsd runs fine under kvm
<fullermd> Hey, if you know a fix for _that_, quit your job right now.  You can become a billionaire overnight.
<vila> Merwin_: in a nutshell, better support
<vila> fullermd: oh, there are a *ton* of different fixes ;)
<fullermd> And one of them starts and ends with 'u', right?   ;p
<vila> hehe
<vila> in fact, the first slave I tried migrating was freebsd, no idea why I chose this one first ;)
<fullermd> I'm kinda impressed.  I was under the impression that getting it running under KVM was a herculean task, and the result didn't work too well when you got it.
<fullermd> That might be from $YEARS ago though.
<vila> nah, I migrated the vbox disk with qemu-img and it just worked
<vila> the issue is it's nated in kvm and I was using the bridged mode in vbox, it looks like I should do the same with kvm even if this doesn't seem strictly required
<vivekimsit> Hii friends!
<vivekimsit> I have one problem!
<vivekimsit> I have co a branch from launchpad
<vivekimsit> now the branch at launchpad is at rev39 and I am at rev36!
<vivekimsit> Now how to sync the two branches?
<jelmer> vivekimsit: bzr up
<vivekimsit> thanks
<vivekimsit> :)
<hannie> Can anyone tell me how I start Qbzr (gui front end for Bazaar)?
<hannie> I have it installed, but when I type qbzr in the Dash (ubuntu 11.10) nothing happens
<jelmer> hannie: qbzr isn't a single application, it just provides extra GUI subcommands for bzr
<jelmer> hannie: e.g. "bzr qlog"
<hannie> ok, so instead of commit I use qcommit in the terminal
<hannie> I also tried Ground Control, but that does not work
<hannie> thanks jelmer I just tried qpull and it works :)
<jelmer> great
<santagada> bzr: ERROR: Cannot lock LockDir(chroot-83045520:///%2Bbranch/openerp-web/6.1/.bzr/branch/lock): Transport operation not possible: readonly transport
<santagada> when doing a bzr pull
<santagada> anyone know why?
<cpuchip> santagada, it looks like it's a readonly drive or something from the last two words, check your permissions on that file. is my only guess
<santagada> cpuchip: its my hard drive, and I set chmod santagada -R * on it
<cpuchip> did you add +w for user on it?
<santagada> cpuchip: no, will try it
<cpuchip> santagada, good luck I hope that helps, I'm not a veterine here,
<santagada> cpuchip: didn't work either
<cpuchip> so you do have read/write access to branch/openerp-web/6.1/.bzr/branch/lock?
<cpuchip> I'm not familiar with the chroot protocal. I'm familiar with chroot as a command.
<santagada> neither am I
<santagada> I'm not manually using chroot
<santagada> I'm using bzr+ssh
<santagada> somehow I think bzr is trying to lock the other side
<cpuchip> right that looks familiar
<santagada> why it is trying to do that I don't know
<cpuchip> that's okay if it's pushing, I'm not familiar with locking remote on a pull but it might.
<peteris> Hi people, what best to use for SSH support in Windows with bzr?
<cpuchip> putty/plink I believe
<peteris> cpuchip, I cant find any reference how to do this properly
<cpuchip> did you install tortoisebzr ? I thought that included plink for ssh.
<cpuchip> but it might not. I'm on linux and haven't had to install on windows in a while.
<cpuchip> peteris, let me look up our internal docs to see how we setup our windows dev machines
<cpuchip> peteris we install the standalone version: http://wiki.bazaar.canonical.com/WindowsDownloads
<cpuchip> peteris, then get putty from: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html download the windows installer that includes everything but puttyel
<cpuchip> I assume you'll want to setup ssh keys (it's less typing your password...) but after that you'll need to add a global environmental variable called BZR_SSH=plink
<cpuchip> make sure putty bin dir is in your path
<cpuchip> you'll then need to create a dir (assuming windows 7) to tell bzr what usrname to use:
<cpuchip> c:\Users\<username>\AppData\Roaming\bazaar\2.0\authentication.conf in it place the next two lines
<cpuchip> [DEFAULT]
<cpuchip> user=your.user.name
<cpuchip> though I think that's configurable in tortiosebzr's menu, we just found it easier to explane it that way.
<cpuchip> your.user.name is your ssh user name
<cpuchip> then bzr+ssh://path/to/your/repo/branch should work
<cpuchip> on a checkout/clone
<peteris> ok, will try that :)
<peteris> thanks
<cpuchip> peteris, good luck!
<peteris> cpuchip, it worked, thanks
#bzr 2012-04-20
<Merwin_> Is it possible to push with colo-branch in a specific branch ?
<Nachtschatten> hi
<Nachtschatten> I'm getting "Error 2" (apparently, some file couldn't be found) when I try to push to a github repository. Is there someone who could help me with that?
<jelmer> Nachtschatten: is this on windows?
<Nachtschatten> Yes, it is
<jelmer> Nachtschatten: it's probably unable to find ssh
<Nachtschatten> ah, interesting.
<Nachtschatten> I have putty installed here, I'll try that.
<jelmer> it looks for something called ssh IIRC
<Nachtschatten> What do you mean?
<Nachtschatten> Ok, I followed the instructions on using Puttygen/Pageant as closely as I could
<jelmer> I doubt putty will work, unless you rename plink.exe to ssh.exe and it is in your PATH
<jam> jelmer: how's it going today?
<Nachtschatten> hm
<jelmer> hey jam
<jam> Nachtschatten: you should be able to set "BZR_SSH=" the full path to plink.exe
<jelmer> jam: I'm doing alright, how are you?
<jelmer> jam: that won't work for dulwich (yet) though
<jam> jelmer: pretty good, getting ready to have a weekend off
<jam> jelmer: ah, dulwich
<jam> missed that part
<Nachtschatten> hehe, I'll try renaming it then. ;)
<jelmer> jam: ah, taking a trip somewhere?
<jam> jelmer: my mom is in town for a couple of weeks. This weekend is going to Keukenhoff
<jelmer> jam: sounds like fun. I hope the weather gets a bit better :-/
<jam> yeah, forecast looks like rain all week. I'm hoping it at least stays above 10C while we're there
<jam> the afternoons have been decent here
<jam> but 5C in the morning is pretty cold
<fullermd> Boy, that sounds nice...
<fullermd> We've been playing with the low 80's for a month.
<jam> fullermd: 80C, I feel very sorry for you :)
<Nachtschatten> ok, copy+rename worked, I can now push to github. Wow, thanks for the help :)
<fullermd> :p
<fullermd> I wouldn't have to mow the lawn near as often if it were 80C   :p
<jam> Nachtschatten: just be a little careful with plink, it doesn't always work just like an ssh. Like it isn't able to prompt for a password on the command line, etc.
<jam> It works, but not quite as well as say installing mingw ssh, or cygwin.
<jam> If it is working for you, though. Great
<Nachtschatten> Okay, I'll keep that in mind.
<Nachtschatten> Well, can you change the error message so it clearly says it can't find ssh?
<Nachtschatten> Anyway, bye everyone, and thanks again.
<Merwin_> Is it possible to push with colo-branch in a specific branch ?
<jelmer> Merwin_: do you mean colo-branch from the colo plugin?
<Merwin_> Yes
<jelmer> ah, I'm not sure in that case
 * nDuff glares at the "bzr log -p" instance running against one of his SVN working trees (currently taking >6GB of RSS and swapping heavily)
<jelmer> nDuff: iuf you have big trees you probably want to use a native bzr branch
#bzr 2012-04-21
<maxb> Stopping importer@jubany, looks locked up and broken to boot
<maxb> Seems happy after a restart
<maxb> Well, happy as it ever is these days
<dash> hi. is there a settings i can add to bazaar.conf so that 'bzr status' defaults to 'bzr status -S'?
<sagaci> l
<dOxxx> dash: I don't think so, but you can create an alias
<dash> aha. thanks
<maxb> argh. argh. argh.
<maxb> The stormified UDD importer has been writing data to the sqlite db as blobs where the prior code wrote it as strings
 * maxb is unhappy about this
<jelmer> maxb: I think it would make sense to revert that change for the moment
<maxb> concur
<maxb> unfortunatly the old code chokes on the data that has been written to the db by the new code
<maxb> am currently attempting to figure out how to convert it
<jelmer> maxb: ah, urgh
<maxb> Any preferences for "push current trunk to a new branchl; uncommit from the old trunk" vs. "commit a revert to the current trunk" ?
<jelmer> maxb: comitting a revert is what we would commonly do for this sort of thing I think
<maxb> works for me
<maxb> So it looks like the storm code has been arbitrarily writing some things as blobs rather than text. This suggests that conversion shouldn't be _too_ hard
 * maxb off to consider dinner, looks like I should be able to sort something out and get the importer up and running again on the old code later tonight
<lifeless> maxb: depends on the datatype of the object - str vs unicode
<maxb> Which is quite sensible really if you're working in Python 3 or starting your project from scratch.
<maxb> Less so if you retrofit Storm to an existing Python 2 project without being REALLY REALLY careful
<maxb> Does Storm have a "Hey, if I accidentally pass you a str, please raise an exception" option?
<marcovorg> hi ppl, how can I change last commit Commiter info? I've changed details with "whoami" and I'd like to update last commits... thanks
<maxb> You can change the very last commit quite easily by uncommitting it and committing again
<maxb> Changing multiple sequential commits is considerably more tricky, and I don't know of a convenient way
<marcovorg> but is there an option to change "Commiter" metadata anyway ? don't know some option....I didn't find anything around....
<marcovorg> ok thanks
#bzr 2012-04-22
<maxb> Hm.
<maxb> We have a bit of a silly bug in the UDD importer
<maxb> every 5 minutes, it checks for new source publications on launchpad published since the last publication it saw previously *minus 10 minutes fudge factor*
<maxb> Which means every 5 minutes it re-runs the import job for whatever package was most recently uploaded, plus any uploaded within 10 minutes of that
<maxb> Which would be why it's currently got some packages queued for 25 consecutive import jobs :-(
<fullermd> It never hurts to make double sure.  And triple sure is even better.  Which means quadruple sure is totally worth it.  Therefor...
<maxb> Insanity by induction :-)
<fullermd> Inducing insanity is just one of my skills.
 * maxb wonders if there are any SQL experts around
<maxb> UPDATE jobs j JOIN (SELECT MAX(id) maxid, package, COUNT(*) FROM jobs WHERE active AND type = 3 GROUP BY package HAVING COUNT(*) > 1) k ON j.package = k.package SET j.active = 0 WHERE active AND type = 3 AND j.id != k.maxid;
<maxb> Appears right to me to prune the UDD importer queue of duplicate entries in type 3 (new entry)
<maxb> Or I guess I could just let it chug through them for a few hours longer
#bzr 2013-04-15
<jelmer> moin bzrers
<superfly> Can anyone tell me if bzrlib will be ported to Python3
<Mo0O> Hi, I'm trying to branch from launchpad, but each time fail with a "killed" error
<Mo0O> somebody know why ?
<thumper> Mo0O: what are you trying to branch?
<LeoNerd> Mo0O: "Killed" may be OOM
#bzr 2013-04-16
<__marco> Hi, I don't understast how to use lp-propose-merge in my usual workflow. What I did: create a local branch, created a bug report on launchpad, fixed the bug, created a remote branch on launchpad and finally linked the branch at the bug report. Now normally I will propose the merge via the web interface. Which branch are going to be proposed with `bzr lp-propose-merge ` the local one? then some of the previous steps are unhelpful?
<jelmer> __marco: it will propose a merge of the remote branch (which it will find from the local branch)
<jelmer> simplest thing to do is to just try
<jelmer> you can always remove the merge proposal later
<__marco> jelmer: thanks. then all what I did is conceptually correct. right?
<jelmer> __marco: sounds like it, yes
<__marco> jelmer: thanks very much
<__marco> jelmer: thanks, worked as aspected. It had create a new keyring. Where it is located?
<jelmer> __marco: It depends on which keyring package it ends up using as its backend (gnome keyring, KDE keyring, etc)
<__marco> fluxbox on a debian stable
<__marco> I'll search
<Sebboh> I have followed some recipe to check out some source via bzr.  I issued the command bzr branch http://bzr.debian.org/pkg-samba/openchange/unstable .  That worked fine.  Now, I'd like to how/when code from upstream has been merged into here.  Mostly how...  In git, I can issue git config --list to get some configuration items, which include the URL of upstream (and/or peer) repos.  Is there something like that in bazaar?
<LeoNerd> well,  bzr info  will show the URLs
<Sebboh> Hm, it only shows "parent branch: http+urllib://anonscm.debian.org/bzr/pkg-samba/openchange/unstable/" (which is the same place I originally checked out (or branched?) even though the hostname is different.)
<jelmer> Sebboh: Note that the OpenChange Debian package has migrated to git
<jelmer> hey LeoNerd
<Sebboh> Oh, that's news to me.  And good news, at that, for me.  (I know more about git than bzr.)
<Sebboh> oh, it's in experimental, I'm only on unstable.  Cool.
<Sebboh> cheers and thanks, jelmer.
#bzr 2013-04-19
<mthaddon> can anyone explain what's going on here? http://paste.ubuntu.com/5720952/ - seems like bzr di --old --new isn't giving the right info
<fullermd> From a glance at the diff, it's suggesting that trunk has stuff memcached doesn't.  And trying to merge memcached into trunk shows nothing to do.  Which sounds sensible.  What are you expecting and not getting?
<fullermd> (you may want to check 'missing')
<mthaddon> I thought the two branches would have no diff
<mthaddon> but you're right, that does seem to be the case - checking
<mthaddon> sorry for the noise, my bad
 * fullermd takes the credit for fixing it.
<fullermd> (only 6 more, and I get a free lollipop!)
<mthaddon> heh
<Andy80> hi
<Andy80> I've a very newbie question. Suppose you have the "master" branch and "new-feature" branch (based on master). When I use git I can easily switch between the two branches doing "git checkout master / git checkout new-feature". How can I do it with Bazaar? Checkout seems to have a different meaning in bzr. Thanks!
<LeoNerd> Generally we don't bother switching between branches in a single working directory. Usually I keep different branches in different dirs
<LeoNerd> You can  bzr switch  if you want, though
<LeoNerd> But usually I find  cd  nicer :)
<maxb> Of course, that needlessly wastes diskspace if you have several branches, some fairly inactive
<LeoNerd> Wellyeah, depends on the use case. Usually I'm never working on things with multiple-gigabyte source trees :)
<Andy80> maxb: which approach? the switch one or having all in different folders?
<LeoNerd> Also my disk is far cheaper than my time is
<maxb> I tend to init-repo --no-trees a shared repository , have a bunch of branches in it, and a single checkout, which I switch
<Andy80> ~800Mb in my case :)
<Andy80> I think it's also useful (switch approach) when you want to temporary switch to an old revision, test some code and switch forward to the latest available, don't you think?
<Andy80> I got an internal error from bazr using switch :(
<Andy80> I get this http://pastebin.com/uSGyTzAa
<Andy80> I jut did: bzr switch -r 2797
<LarstiQ> Andy80: huu
<LarstiQ> Andy80: you didn't give it a branch to switch to?
<LarstiQ> ah hmm, that does seem to work here
<LarstiQ> Andy80: that traceback is incomplete, could you pastebin the full one from ~/.bzr.log?
<fullermd> I suspect you really want update rather than switch there anyway.
<Andy80> fullermd: update what?
<fullermd> bzr update -r2797
<Andy80> LarstiQ: gime me some minutes, I'm doing a different thing right now and cannot abandon it
<Andy80> fullermd: no... I just wanted to switch, execute some code with no modification and switch back...
<LarstiQ> Andy80: no worries
<Andy80> just like the git "checkout" command
<fullermd> As is usual for such things, there isn't a 1:1 mapping of command intentions and names among systems   :)
<fullermd> 'switch' is really geared toward "change this WT to be with another branch".  'update' is asking for "change this WT to a different rev in this branch".
<LarstiQ> and 'revert' would only change the WT contents
<fullermd> There's some overlap and ambiguity between the two, to be sure, but weird behavior is likely when you get into the offsides of clearer cases.
<LarstiQ> which for running some code imo is what you care about
<fullermd> No, you really only want revert when you're wanting to do things like "change individual file to state as of rev X".
<fullermd> When you want to do things more like "temporarily change the whole tree to state X, and I'll be going 'back' to 'now' later", update is a much better choice, since it knows what it's done.
<fullermd> That is, a sequence like "revert -rX, try some stuff, revert -rY, try stuff, revert -rZ, try stuff, OK, I'm doing, revert -rLATEST" is just thumbing your nose at Murphy.
<fullermd> update is much better suited for that, doubly so since it can do merges.
<LarstiQ> right
<fullermd> (e.g., "update -rX, make some changes, update -r-1, those changes are now merged forward as much as possible")
 * LarstiQ usually only does revert -rX; stuff; revert;
<LarstiQ> where stuff does not include making changes
<LarstiQ> fullermd: I'll see if I can get used to using update :)
<fullermd> As my rule, the overriding use case for revert is "discard {some,all} changes I've made since last commit", with the secondary use case being "change this file back to a previous state, I think I wanna dump some committed changes to it".
<fullermd> I figure "Let me try something on the whole tree at a previous rev" is solidly in 'update's baliwick.
<Andy80> so basically I need to do: bzr update -r 2797, I do my stuff, tests etc.... then I: bzr revert, right?
<fullermd> (actually, for the case of "let me try a quick experiment on a pristine old tree, then discard it all", I'm probably most likely to just make a throwaway branch for it.  Depending on size and environment, of course...)
<fullermd> You'd want update -r-1 (or maybe just 'update'; I don't recall offhand) to get back to the head of the branch.
<Andy80> ah cool
<fullermd> That revert would just wipe whatever changes you'd made relative to pristine r2797.
<fullermd> (revert fiddles with the working tree _files_, but not the working tree _state_.  update twiddles the state, then merges changes to the files relative to the previous state)
<fullermd> So if you start out with a clean tree at the head (call it r3000), running 'bzr diff' will show nothing (Since you have no changes)
<fullermd> After running a "update -r2797", doing a 'diff' will also show nothing (since you now have a tree just like r2797)
<fullermd> But if you'd done "revert -r2797", the diff would give you the output of "bzr diff -r3000..2797", since your files look like r2797, but your WT considers itself to be based at r3000.
<fullermd> So if you "update -r2797", then later do a "revert", you'll get a pristine r2797.  If you "revert -r-1", you'll get a tree with 3000's contents that considers itself based on '2797', so diff would show "bzr diff -r2797..3000"ish output.
<fullermd> Or, to make some attempt at handwavy comparisons (don't expect perfect correspondence, but it's closeish)
<fullermd> "git checkout $BRANCH" is like "bzr switch $BRANCH"
<fullermd> "git checkout $COMMIT" is more like "bzr update -r$COMMIT" (except that you're not really setup to commit based on it at that point)
<fullermd> "git checkout $PATH" is in "bzr revert $PATH" territory.
<Andy80> fullermd: and what happens if, for example, once I'm on r2797 I do some changes? Firtst question: how do I simply discharge them (if I want) and how do I keep them and merge/push to another new branch?
<fullermd> Well, if you did a "bzr update -r2797 ; <make changes> ; bzr revert", the result would be that you're back sitting at an unchanged r2797.
<Andy80> ok
<fullermd> If you decide you want to commit them, you'd have to make a branch to do them on.  If you expect that from the get-go, you might as well make the branch in the first place and work from there.
<fullermd> (e.g., "bzr branch -r2797 source newbranch ; cd newbranch ; <make changes>" etc.  Or something similar but different, if you're doing a shared-WT setup.
<Andy80> and what if I know only later that I want to have a new branch with my changes?
<fullermd> If it's only after the fact that you decide you want to make a new branch with those changes, you can make that newbranch at that point and use "merge --uncommitted" to pull over the changes from the WT.
<fullermd> (or, if you're using a common WT...   mmm....   I think you can do a "shelve ; switch ; unshelve" sequence?)
<LeoNerd> shelve/unshelve is useful for this sort of thing. Though sometimes I've wanted to be able to "unshelve-from" a different working tree
<LeoNerd> bzr unshelve-from ../foo.OTHERBRANCH  could be nice
<fullermd> e.g., "whoops, I want to make a branch with these" ; cd .. ; bzr branch -r2797 source newbranch ; cd newbranch ; bzr merge --uncommitted ../source ; bzr ci (those new changes on this new branch) ; cd ../source ; bzr revert (to clean up in source) ; bzr update (to get source back up to the head of the branch)
<LeoNerd> Oohyes... merge --uncommitted  is useful too
<LeoNerd> Is that quite a new thing? I often forget about that one
<fullermd> Not very...
<fullermd> A quick grep in release notes says it came in with 0.10.
<Andy80> fullermd: cool, nice example, thanks :)
<Andy80> are the bazaar location all hardcoded under .bzr/branch/location ? I've moved some branches I had under a different location and now I get this error: andrea@ultrabook ~/Documents/Glow/src/2798/andrea $ bzr status
<Andy80> bzr: ERROR: Not a branch: "/home/andrea/Documents/Glow/2798/andrea/".
<Andy80> I've tried to change the path inside that file but it's not working, I cannot fix it :(
#bzr 2013-04-20
<idnar> I have a bzr / bzr-svn repository that appears to be corrupt: http://pb.codehash.net/husanaug.txt
<idnar> should I bother trying to repair it? (and if so, how do I go about doing that?)
<PaulePanter> Hi.
<PaulePanter> In http://paste.debian.net/250738/ I want to revert to 4826.
<PaulePanter> $ bzr checkout -r 4826
<PaulePanter> bzr: ERROR: A control directory already exists: "file:///tmp/grub-ahci/".
<PaulePanter> Any idea how I can go back to tha revision?
#bzr 2014-04-17
<quotemstr> Say I have parent branch foo and child branch bar.
<quotemstr> How can I move all commits from bar to foo without the commit appearing as a merge commit?
<quotemstr> That is, I'd like each commit in bar to appear as a top-level commit in foo.
<spiv> quotemstr: sounds like you want the rebase plugin.
#bzr 2014-04-19
<asb> Hello
<asb> I cannot get the source code of firefox using bzr
<asb>  bzr branch lp:ubuntu/saucy/firefox
#bzr 2015-04-13
<sidi_> I forked a branch, added some commits into my own fork, and I now need to merge new commits from the original parent I forked. What would be the correct command to do this?
<fullermd> Just 'bzr merge' should do it.
<sidi_> fullermd, thanks! that did it
#bzr 2016-04-19
<ryan__> I have encountered an issue where profile_imports.py does not seem to support imports such as from . import foo or from .. import blah
<ryan__> how do I go about submitting a patch for this?
<vila> ryan__: hmmm, not sure what you mean, bzr /don't/ use relative imports
<vila> doesn't even
<ryan__> vila: are they not allowed in plugins either?
<vila> ryan__: well, I wouldn't say not allowed, I'd be pleasantly surprised if they work for plugins though, they are imported in a special way
<vila> ryan__: do you use them in a plugin ?
<ryan__> vila: I was playing around with writing one
<ryan__> works fine without --profile-imports but crashes with it
<vila> ryan__: hmm, the thing is... bzr went the 'from __future__ import absolute_import' route :-> I'm unclear about that topic...
<ryan__> vila: hm, is there some place I should reach out? mailing list? bug tracker? the change is very small
<vila> ryan__: so getting back to your initial question, https://bugs.launchpad.net/bzr/+filebug and propose a branc
<vila> h
<vila> ryan__: sorry, slow typing ;)
<ryan__> vila: thanks
<vila> ryan__: yw
#bzr 2016-04-21
<DarkFeather> Hello, all. I'm trying to commit a symlink to my repo, and bzr add <link> doesn't change the status in bzr status. Help?
<DarkFeather> Also, I'm looking for a way to create BranchReferences rather than symlinks, if I can....
<DarkFeather> Well, that's annoying. I can add it so long as the symlink doesn't point to a branch. ... Fine then.
<DarkFeather> Anyone know how to make BranchReferences?
#bzr 2016-04-22
<DarkFeather> Anyone know how to make BranchReferences?
<vila> DarkFeather: I'm pretty sure this is not supported properly across the board
<vila> DarkFeather: symlinks are supported though, the symlink name and the target that is, /not/ the content of the target
<DarkFeather> Yeah....
<DarkFeather> I'll probably move to git for read-only subtrees.
<DarkFeather> I got to have a good heart-to-heart in #archlinux and frankly git is more standard and more likely to have the features I'm looking for. The symlink workaround's not so great.
 * fullermd sneaks up behind vila and ties his shoelaces together.
<DarkFeather> That's not nice.
#bzr 2018-04-19
<RiXtEr> Hey all, any way to recover a 'paths are not versioned' issue?
