#bzr 2008-04-28
<Jeej> Hello
<Jeej> I have a question about Bazaar
<mwhudson> hi jearl
<mwhudson> Jeej, even
<Jeej> hi mwhudson
<mwhudson> Jeej: just ask your question
<Jeej> ah, well, i have just setup bazaar. I thoughed, i don't have to work in the bazaar dir, so i try it in the dir i want to use
<Jeej> oh, and i use windows
<mwhudson> there is a windows installer for bazaar i think
<mwhudson> (i do not use windows, however)
<Jeej> i found the Bazaar in five minuets document, but, now am i here: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#making-changes-to-your-files when i do bzr diff, it doesn't so anything
<Jeej> yep, windows installer :-)
<Jeej> So, i did bzr diff file.ex, but it gives an error: bzr: ERROR: Path(s) are not versioned: file.ex
<Jeej> but i have made some changes
<Odd_Bloke> Jeej: You need to have used 'bzr add' on the files, so that Bazaar knows that it should be versioning those files.
<Jeej> I have done that
<beuno> Jeej, how about bzr commit?
<Jeej> also done
<Odd_Bloke> Jeej: What does 'bzr ls --versioned' in that directory show?
<Jeej> Nothing :-/
<Odd_Bloke> What about 'bzr status'?
<Jeej> unknown: all the files in the dir
<Odd_Bloke> Jeej: And what does 'bzr log' show?
<thumper> Odd_Bloke: morning
<Odd_Bloke> thumper: o/
<Jeej> can i paste it here?
<Odd_Bloke> Jeej: A pastebin would be better.
<Jeej> http://pastebin.com/d4d713741
<Jeej> :-)
<Odd_Bloke> :D
<Odd_Bloke> OK, the evidence suggests that you didn't do a 'bzr add' before your first 'bzr commit'.
<Jeej> I have done that, it gave me a list of all the files in the dir
<Odd_Bloke> Well, bzr clearly doesn't know anything about them any more. :/
<Jeej> Would it perhapse help when i do it now?
<Odd_Bloke> Well, try it and paste the output somewhere.,
<Jeej> http://pastebin.com/dc6c1d85
<Odd_Bloke> Jeej: And what does 'bzr status' show now?
<Jeej> still nothing
<beuno> Jeej, well, are you trying to use file.ex
<beuno> instead of an actual file name?
<beuno> file.ex is an example name  :)
<Jeej> Nope, i didn't want to give you the name
<beuno> Jeej, ah, right
<beuno> well
<beuno> try changing a file now
<Jeej> But, later i though, it doesn't matter :-P
<beuno> and running bzr diff
 * Odd_Bloke is heading to bed.
<Odd_Bloke> Night all!
<Jeej> oh, bye
<beuno> night Odd_Bloke
<Jeej> Woei (hehe, Dutch), it works
<beuno> Jeej, :)
<Jeej> well, thank you :-D
<Jeej> i am also going to sleep
<Jeej> byebye
<igc> about to review abentley's PreviewTree patch now
<abentley> igc: cool
<igc> abentley: I'm doing that first because it's the oldest
<igc> is there something higher priority of yours you want done today?
<igc> either before or after that one?
<abentley> Well, for that one, spiv reviewed it, but didn't actually vote.
<abentley> He had some objections to the testing which I said I'd fix.
<igc> just noticed that
<igc> abentley: should I wait and do the fetch ones instead then?
<abentley> That would be good.
<igc> np
<abentley> lifeless: ping
<lifeless> pong
<abentley> I had to tweak Repository.add_revision to munge sha1s all the time.  It was only doing it when an inventory was supplied.
<abentley> When I did that, I broke bundle tests.
<abentley> on "/home/abentley/bzr/fetch1to2/bzrlib/bundle/bundle_data.py", line 274
<lifeless> I think that makes the api border stronger and is likely to prevent accidents; otoh perhaps asserting that the sha1 is correct when an inventory is not supplied would alter to current uses that interact badly
<abentley> Should I just remove this verification?
<lifeless> s/alter/alert
<lifeless> I think the verification is bogus, because its asserting that the storage in the target repository format is identical to the storage in the source, but thats only the case when the model&serialisers match
<abentley> Well, I think if we're going to alter sha1s in add_revision, we should expect it to happen whether or not an inventory is supplied.
<abentley> But I have no way of knowing what the source serializer was for formats 0.8 and 0.9
<abentley> So I can't make that test conditional on the serializer.
<lifeless> abentley: I'm completely cool with your change to add_revision; I was just making an observation that we'd catch current 'culprits' by erroring rather than just altering, when the sha1's are different
<lifeless> .
 * igc dentist
<abentley> Hmm.
<igc> (I'll finish reviewing poolie's and jml's LockTimeout patch when I get back)
<lifeless> abentley: I have no recommendation about whether altering or alerting is better.
<abentley> I think I'll take altering.
<lifeless> k
<lifeless> so, in the bundle_data.py test, I think that has to go.
<lifeless> because we don't know enough data about the origin, we can't determine what it should look like
<abentley> Cool.  It's only validating one field of the stored revision, which is a bit whack anyhow.
<lifeless> yeah, as the comment said
<poolie> hersonls: hi
<abentley> So if we were to stop exposing Revision.inventory_sha1, what would we replace it with?
<hersonls> poolie: hi
<poolie> hello lifeless, abentley
<abentley> poolie: hi
<hersonls> was planning on doing slackbuild for ï»¿bazaar 1.4rc, which feel about that?
<hersonls> for users-tests
<poolie> what do you mean by "for users-tests"
<lifeless> abentley: revision.validate() or repository.validate_revision(revid)
<poolie> do you mean so that users can test it?
<abentley> lifeless: Would we store new data in the repo?
<lifeless> abentley: I think we could in future but we could investigate whether the api would work now
<hersonls> poolie: yeah
<poolie> sure, that sounds good
<hersonls> :)
<abentley> lifeless: So we could actually stop exposing the attribute now, and just always ensure it matched its source repo.
<abentley> It would be easier doing it on Repository, because it wouldn't require the revision to know its source repository.  (and it may not have one)
<lifeless> abentley: exactly
<abentley> poolie: Sorry BB refused your vote.  Not sure why yet.
<poolie> abentley: i'm not sure precisely which email address i am registered with
<poolie> could you tell it to accept both @sourcefrog.net and @canonical?
<abentley> You've got a bunch: Submitter(id=u'Martin Pool <mbp@canonical.com>'), Submitter(id=u'Martin Pool <mbp@sourcefrog.net>'), Submitter(id=u'"Martin Pool" <mbp@sourcefrog.net>')
<abentley> But it looks like you don't have "Martin Pool" in quotation marks yet.
<abentley> Fixing that now.
<poolie> heh
<jamesh> abentley: perhaps you should extract the email address and match that?
<abentley> Maybe, but email addresses aren't always unique.
<abentley> poolie: I've just re-enqueued your vote.
<abentley> poolie: Well, it failed, but for a legitimate reason now.
<poolie> heh, what was that?
<abentley> You didn't reply to the original request.
<poolie> oh, replying to a reply won't do?
<abentley> Not at present.
<abentley> I'm trying to decide whether to use the References header, or actually record all the mail threads.
<lifeless> so
<lifeless> I like the current behaviour
<lifeless> because I can reply to a thread with a new patch
<lifeless> and there is no ambiguity
<poolie> sure, that's an important case, but i think in this case there is no ambiguity about what i was reviewing either
<poolie> abentley: well, at least now i know.
<spiv> It's not very elegant, but maybe a "bb:review-of:<msgid>" command for a down-thread review?
<poolie> spiv, at that point i think i'd just use the web ui...
<abentley> poolie: There would be ambiguity if it was a long thread and I used only the references header.
<spiv> Yeah, that's true.
<abentley> Because the thread could have two different merge requests.
<poolie> abentley: i guess i'd try using References and objecting if it's ambiguous
<poolie> i suppose if you record all the messages you would be able to determine which is the closest one
<abentley> Right.
<abentley> Unless someone actually managed to reply to two different messages at once, which RFC2822 permits :-)
<abentley> lifeless: I
<abentley> I'm not sure how changing the behavior would interfere with your use case.
<abentley> Perhaps you think the supersed marker is based on mail headers?  It's actually based on graph ancestry.
<poolie> i think an actual ambiguity of that type would be rare, to put it mildly
<poolie> were you asking me? i didn't think that.
<abentley> No, I was asking lifeless.
<poolie> jamesh: thanks for diagnosing the bzrtools ppa problem, i'll look at it now
<lifeless> abentley: well I was saying that without having the full graph it would be ambiguous; anyhow, you've done nice things with bb to date; I trust that any change you make will still be nice
<abentley> lifeless: I agree that voting would be ambiguous if I used the References header.  But creating new merge requests is never ambiguous.
<lifeless> abentley: right, thats what I meant :P
<lifeless> I wasn't meaning that new requests would be ambigous
<lifeless> but that they could cause voting ambiguity
<abentley> Ah, I misunderstood.
<marnanel> This is probably a pretty stupid question, but if I want to peruse a file's version history from my own (Python) program, there are public APIs for that, right?
<mwhudson> yes
<marnanel> oh, good-- thank you. are they supplied with bzr, or do I have to install them specially?
<jamesh> marnanel: the public API is provided by the bzrlib Python package, which the bzr command line executable is built on top of
<jamesh> so if you have bzr installed, you have bzrlib
<marnanel> jamesh: awesome! thank you
<marnanel> jamesh: I figured it was something like that, but I thought it couldn't hurt to ask
<igc> Oh BundleBuggy, where art thou dear BundleBuggy?
<igc> abentley: bb seems hung again :-(
<abentley> igc: Just seems slow to me.
<igc> abentley: ok - thanks for checking
<AfC> One of the things that we've been doing to improve the perceived responsiveness of Bazaar is to improve the feedback in progress bars.
<AfC> One place that I've noted that bzr still seems a bit wedged is when downloading monster larger packs.
<AfC> I can tell from the system monitor that the network connection is maxed out, and looking at the file size one can see the file growing, so I knew full well it was doing something, but > 5 minutes with no change in the feedback given to the user seems a bit long.
<AfC> Would it be wrong to give a wget style indication of the amount of data to be transferred and/or percent done (in bytes, rather than "0/2") ?
<AfC> and is such a thing even possible?
<AfC> (presumably if http:// as the transport it would be, I would have thought it would be with bzr:// too, but I'm not sure on which internals are relevant)
<mwhudson> i'm sure i've seen such things talked about
<AfC> mwhudson: yeah. I wasn't sure if anything specifically on that had been done during the 1.4 cycle.
<mwhudson> i don't think so
<AfC> if so, then I wouldn't have worried further about it, otherwise, when I start telling people about this repository I'll have to warn them in big letters not to freak out that it's taking so long with apparently no feedback.
<lifeless> AfC: I believe it is specifically a defect in the smart server stream handling
<lifeless> AfC: pack downloads do show a progress bar
<lifeless> AfC: I'm not aware of anyone actively working on the bug, but I pretty sure there is a bug open.
<AfC> lifeless: ... "pack downloads"; it did have a progress bar; it's just that "0/2" for ~ 300 seconds isn't terribly illuminating, that's all
<lifeless> AfC: what url
<AfC> lifeless: http://www.gnome.org/~afcowie/bzr/gtk+/trunk/
<lifeless> spiv: ^ can you tell if there is a smart server at that url ?
<lifeless> spiv: (I can, but it should be easier)
<AfC> lifeless: (I certainly didn't put one there, but I can ask Olav if necessary; I don't think he did anything fancy)
<AfC> (and, netstat on that server doesn't report anything on 4155)
<lifeless> AfC: we tunnel over http
<spiv> lifeless: judging from -Dhpss logging, no.
<AfC> lifeless: only if someone has configured mod_python etc to do so, right?
<spiv> Or mod_wsgi or whatever, yeah.
<lifeless> spiv: 'it should be easier' :P
<AfC> spiv: yeah
<spiv> lifeless: agreed. :)
<AfC> lifeless: anyway, there's no getting around the fact that that pack is ~180 MB (at least, not until shallow branches); I'm just angling at the first impression factor, that's all.
<lifeless> AfC: oh yeah
<lifeless> AfC: I think I know the problem;
<spiv> Huh, I just got a bzr: ERROR: Pack '346df6b9e93adebf6a24a2231b3eda8d' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x87b96cc> when pushing
<spiv> With current bzr.dev -- which apparently has the "Avoid pack name collisions when fetching all revisions" fix.
<lifeless> AfC: vila has the details, but I'm pretty sure there is a issue where http doesn't stream data to python
<lifeless> spiv: that fix is not needed for push/pull code paths; only for library api user.
<lifeless> AfC: so you end up with the 180 MB downloading between two lines of python code
<AfC> lifeless: yippee!
<AfC> That calls for a chocolate biscuit.
<vila> lifeless, AfC: I''ll have to check, but from memory, if you're using pycurl you get a bit less feedback (which, I realize, in your context, could mean *far* less feedback ;-)
<AfC> lifeless: one thing I was going to ask you about | suggest was that it's pretty common for people to deliberately or accidentally interrupt such a large transfer
<AfC> vila: I'm using... um, you mean, one isn't supposed to "use" curl?
<vila> and anyway, poolie filled a bug about using a progress bar at transport level and fixing *that* should give better feedback (with the some caveat for pycurl)
<vila> AfC: We have two http implementations: one based on pycurl, the other based on the python urllib2 module
<vila> pycurl is the default if installed
<AfC> lifeless: so while ordinarily reducing round trips, etc is a goal we strive for, resumeability & robustness are also important
<lifeless> AfC: well, its robust today while not being resumable
<AfC> lifeless: maybe an upper limit on pack size would be a good idea, ie, if I had to do 180 1 MB transfers, and am interrupted half way thought, resuming from there is a bit more palatable than re-transferring 100MB
<AfC> (or, of course, resuing partial downloads)
<lifeless> AfC: the size of source pack doesn't influce resumability
<AfC>  / "continuing" / whaver
<lifeless> AfC: its all about data insertion
<lifeless> a single insertion is atomic
<AfC> well, right now it's about downloading a 180MB file
<lifeless> a single insertion must meet topological ordering across the entire set being downloaded
<vila> poolie: ping, can *you* access to lp bug #183705 ?
<ubotu> Bug 183705 on http://launchpad.net/bugs/183705 is private
<AfC> (and all the usual patterns of download management that go with it, yeay `wget -c`)
<vila> poolie: and tell me if there is something I can do about it ?
<AfC> vila: ah, ok, so using pycurl is the preference. Good, that's the way things land here.
<vila> AfC: hehe, *my* preference is to use urllib2 :) But that doesn't verify ssl certificates otherwise that will be the default :)
<AfC> vila: [ah, I was wondering what the difference was]
<lifeless> vila: fixed
<lifeless> AfC: uhm, packs are not downloaded as a binary blob, desired hunks from it are grabbed with a readv
<vila> lifeless: thanks, I'd be interested in the explanation of why I couldn't access it and why I could *now* access it though :)
<lifeless> AfC: I appreciate the point that resuming is nice; but its simply not up there compared to the current performance issues we have.
<lifeless> AfC: and as its not dealing with static content, wget -c and other download managers like torrents are not good examples to draw from
<AfC> lifeless: interesting
<AfC> lifeless: so, speculating, if you know you need the entire content of pack, wouldn't it be cheaper to just fire off a thread and bring that back in, lock stock and barrel?
<AfC> but other than that, very interesting indeed.
<lifeless> AfC: we don't know if we need the entire content of a given pack a priori - ever
<AfC> really?
<AfC> weird.
<lifeless> we have to read the inventories from a revision X to know the text keys we want
<lifeless> not weird; its a DAG of data
<AfC> lifeless: yeah yeah, but I thought you had an index of inventory  to which pack contained the text you needed
<AfC> and vice versa
<lifeless> we have indices for accessing named data keys
<AfC> (the reverse indicating "yes, we need all of it")
<lifeless> and the file and revision graphs are cached in the index
<ubotu> New bug: #183705 in bzr "authentication.conf doesnt provide sftp login password" [Undecided,New] https://launchpad.net/bugs/183705
<lifeless> vila: it was embargoed
<lifeless> vila: so that only subscribers could look at it, and had only the security contact and filer as subscribers able to access it
<lifeless> AfC: over the smart protocol we can order data so that we can perform multiple small insertions if we want to
<vila> lifeless: So I'd say there is a workflow bug there since no-one answered it for 4 months :-/ I better understand codeslinger angryness (I'd call that mitigating circumstance :)
<lifeless> AfC: but over http doing that will give us many roundtrips
<lifeless> AfC: (more than just whatever fraction of 180MB we decide to split the download size into)
<lifeless> because of the need to maintain the local consistency at any insertion point
<jamesh> vila/lifeless: perhaps the security team should be a team, so that such bugs can be looked at by more than just poolie (the bzr security contact)
<jamesh> you'd want a restricted or moderated team, of course
<lifeless> makes sense to me
<lifeless> I'd use the bzr team myself
<jamesh> for real security vulnerabilities, does it make sense to expose them to that many people by default?
<jamesh> you can always expand the subscriber list of a bug, but it is harder to put secrets back in the box
<lifeless> jamesh: I have a simple view on trust.
<jamesh> lifeless: it isn't just you that matters though.
<jamesh> If I find a serious security bug in Bazaar, I might be a bit hesitant to use Launchpad and disclose it to that many people.
<lifeless> jamesh: well, make it a private team with hidden membership
<lifeless> jamesh: then you can't tell
<jamesh> except that we don't allow that ...
<lifeless> jamesh: just saying
<lifeless> bah
<lifeless> bzr: ERROR: Connection error: Couldn't resolve host 'bazaar-vcs.org' (-2, 'Name or service not known')
<lifeless> transient error
<lifeless> nothing else barfs on it :(
<lifeless> night all
<mr-rus1> Hi, I'm attempting to convert an svn repository with multiple branches to bazaar. and I have a few questions.
<mr-russ> does each branch become a separate bzr branch?
<mr-russ> how to svn tags fit into bzr and the possible branches?  eg branch 1.1 with tag 1.1.2
<bob2> 1) yes
<mr-russ> excellent, I'm beginning to understand this stuff.
 * igc dinner
<jamesh> mr-russ: I recently did a conversion using svn2bzr quite successfully
<jamesh> mr-russ: it creates branches for trunk, stuff in branches/ and tags/
<jamesh> (with appropriate relationships when copies occur)
<jamesh> I used a simple post-processing script to covert the branches in tags/ to bzr tags
<Odd_Bloke> Morning.
<poolie> hello
<mr-russ> jamesh: where would I get a post processing script that does svn tags -> bzr tags
<jamesh> mr-russ: http://people.ubuntu.com/~jamesh/add-tags.py
<jamesh> mr-russ: the first argument is the branch you want to apply tags to, and the second is the directory containing the tag branches
<mr-russ> I"ve tried to get a copy of svn2bzr, but I'm confused about how to get a working one.
<mr-russ> I downloaded your branch, but it doesn't seem to be working.
<jamesh> in what way?
<mr-russ> trunk/svn2bzr file:///home/mr-russ/dev/home/svn/civian/ civian-bzr-all
<mr-russ> what paste do we use?
<jamesh> mr-russ: svn2bzr tags a Subversion dump file as input
<mr-russ> svn2bzr [options] <dump file|svn-url> <output dir>
<mr-russ> usage says svn-url
<jamesh> hmm.  I'd recommend using svn2bzr from lp:~niemeyer/svn2bzr/trunk
<jamesh> it only works from dump files
<mr-russ> how does one know which branch to choose?
<jamesh> mr-russ: you need to use the --scheme option to tell it how your repo is laid out
<jamesh> you probably want --scheme=trunk or --scheme=project
<jamesh> the first is for use if you have a single-project repo with toplevel /trunk, /branches and /tags directories
<jamesh> the second is for use if you have a multi-project repo with project1/trunk, projcect1/branches, project1/tags, project2/trunk, project2/branches, project2/tags, etc
<jamesh> it will then have enough information to tell if a tree copy is creating a new branch/tag
<mr-russ> jamesh: I meant when downloading bzr branches from launchpad.  svn2bzr didn't have an obvious download to run the conversion.
<jamesh> mr-russ: ah. niemeyer hasn't set his branch as the default one
<jamesh> if he had, then it'd be marked as the development focus and you could just do "bzr branch lp:svn2bzr"
<jamesh> I'll remind him to fix it :)
<mr-russ> yeah, the trunk like is broken and very confusing when you link from the bazaar website.
<mr-russ> thanks.  it will help others I'm sure.
<asabil> anyone knows if bzr-git usable ?
<jelmer> asabil: not really
<jelmer> asabil: it allows you to use bzr viz / bzr log on git repositories
<asabil> I see
<jelmer> asabil: but that's it afaik
<asabil> thanks for the information
<devilsadvocate> hi. does bazaar leave a lot or randomly named files  in ~ ?
<james_w> it shouldn't do
<james_w> what names are you seeing?
<devilsadvocate> hm,. i see a lot of them, which started showing up areound the time i started using bazaar. wanted to make sure they werent related
<devilsadvocate> all have 6 characters, seem random, like a hash of some form
<devilsadvocate> like QIu2Xk
<james_w> I doubt they are from bzr, I've not seen them.
<spiv> Yeah, that doesn't sound like bzr.
<devilsadvocate> k, thanks
<spiv> I'd guess that something is using $HOME for $TMP
<james_w> lsof might tell you what owns them if they are still open.
<jelmer> jml: hi! Does tribunal support subunit yet?
<jml> jelmer: soon!
<ubotu> New bug: #223585 in bzr "Bzr crashes with MemoryError during branch on OS X" [Undecided,New] https://launchpad.net/bugs/223585
<semslie> I've just started trying out bzr-svn and made my first commit back to the svn repository. I've noticed that a number of properties (bzr:revision-info, etc.) are set on the parent branch directory in subversion. Are these required? I'm asking because the other developers on this project might not like loads of properties being set around the place. If that is the only property that will be set then it might not be such a problem.
<jelmer> semslie: yes, they're required - without them bzr wouldn't be able to do the right thing when you branch from svn
<semslie> jelmer: At first I thought they were on all committed files, but it looks like they are only set on the branch directory, so it might not be such a problem
<semslie> hopefully the extreme productivity boost from bzr will justify the extra info in trac :)
<jelmer> there is a trac option to hide certain properties
<asabil> devilsadvocate: using gedit ?
<devilsadvocate> asabil, no. kde / kate
<asabil> devilsadvocate: check the settings for kate then
<asabil> you will also get backup files if you use bzr revert
<ubotu> New bug: #223597 in bzr-loom ""record" is underdocumented" [Undecided,New] https://launchpad.net/bugs/223597
<semslie> jelmer: thanks. That might help
<ubotu> New bug: #223601 in bzr-loom "up-thread: ERROR: Revision {('',)} not present" [Undecided,New] https://launchpad.net/bugs/223601
<Odd_Bloke> abentley: BB seems to be having issues (specifically with looking at a merge request, but the problem may be more general).
<Odd_Bloke> abentley: The problem is more general (I know that now the front page has loaded :p).
<visit0r> hi, what's the current recommended way to send commit emails?
<visit0r> the server-side crontab script is buggy as hell
<onno> Bazaar refuses to take a folder in "bzr add foo" it says foo is ignored... yet its not in my .bzrignore list
<Odd_Bloke> onno: Using 'bzr ignored' will give you a list of files and the patterns that they match to be ignored.
<onno> yeah but its not in there. I found out it is in the repo but won't put it in my project when I do bzr update
<onno> I updated my system from 7.10  to 8.04 ubuntu yesterday... Could this be the cause?
<Odd_Bloke> onno: Could you paste the command you're using and the output you get somewhere?
<Stavros> hello
<onno> bzr update
<Stavros> how can i have bzr automatically replace version/revision tags in a file?
<onno> project/nieuwsbrief/templatetags/
<onno> I don't got any error messages
<onno> it simple not ther
<onno> I just did a new checkout all seems fine now
<Odd_Bloke> onno: OK, good.
<Odd_Bloke> Stavros: Do you mean in the same way CVS does with things in betweens $s?
<onno> still strange that I need to do this
<Stavros> Odd_Bloke: hmm, probably, i'm not sure about that
<Odd_Bloke> Stavros: Well, if so, it can't currently.
<Stavros> hmm
<Stavros> any idea why it's telling me that bzrlib doesn't match the bzr program? i'm on a mac
<Stavros> does anyone know where i can see my repo code on launchpad?  i can't find it :/
<Stavros> oh nm, browse code :/
<Stavros> hmm, how come pushing to launchpad doesn't ask me for a password?
<spiv> Stavros: SSH keys
<bimberi> Stavros: because you're using the ssh key you've specified to launchpad
<Stavros> ah, i didn't know it used the keys for login, thanks
<semslie> ï»¿another beginner bzr-svn question: I'm wanting to start using bazaar as transparently as possible with the other developers on my project. Right now I have a mirror checkout and a local branch of that which I've worked on. My changes are ready, so I've merged back to the mirror checkout and then I want to commit that back to the svn repo. Unfortunately this means that I think I will end up with the commit messages that were part of the fix in my local b
<Odd_Bloke> semslie: You got cut off after 'of the fix in my local'.
<semslie> long question :) here's the rest:
<semslie> "ï»¿... ï»¿fix in my local ï»¿branch, and an extra message along the lines of 'merged changes', which isn't as transparent as I would like at the moment. Is there a way for my to just have just those commit messages involved in the fix committed?"
<Odd_Bloke> semslie: Well, if you merge into the integration branch, you will only get a single commit in the mainline.
<Odd_Bloke> If you only want commits related to the fix you've made, then that should really have been done in its own integration branch.
<Odd_Bloke> Ack, it's own _feature_ branch.
<semslie> Odd_Bloke: So is it best to leave out the 'mirror checkout' in this case altogether?
<Stavros> isn't the bzr installer supposed to add a script to /usr/bin/bzr?
<Odd_Bloke> semslie: Well, the mirror checkout could double as your integration branch (i.e. you merge into that from your feature branch and then commit to SVN from there).
<Odd_Bloke> Stavros: Which bzr installer?
<Stavros> 1.4rc2
<Stavros> the .tar one
<Stavros> hmm, actually it copies it to /usr/local/bin/bzr
<Stavros> which is not in my path, for some reason
<Stavros> this is odd
<semslie> Odd_Bloke: cool, thats what I was going for. When I commit from the integration branch will it commit any merged changes as a single subversion commit?
<Stavros> nm, it works now that i restarted the shell
<Odd_Bloke> semslie: Yes, Subversion only sees the mainline commits.
<semslie> Odd_Bloke: that makes total sense now. Thanks!
<Odd_Bloke> semslie: No worries. :)
<Stavros> this is out of topic, but does anyone know how i can strip all html from a document with beautifulsoup?
<jam> morning
<Odd_Bloke> jam: Morning.
<Kbyte> hi!
<pekuja> Kbyte, are you a 1000 bytes or a 1024 bytes?
<Kbyte> pekuja: I'm a 1024 bytes. :)
<Kbyte> Damn, my boss want to buy ms team because bzr doesn't have a good frontend for windows. I'm so sad :(
<jelmer> Kbyte: Mark Hammond is working hard on getting that fixed (tortoisebzr)
<jelmer> Kbyte: Probably too late for you though
<pekuja> MS Team? that can't be a better option
<Kbyte> It isn't never too late :) tortoisebzr have the same features of olive-gtk? I looking for a tool that make easier to add files to repository, make commit, merge, ecc ecc...
<pekuja> EclipseBzr? :-P
<Odd_Bloke> Has anyone on the list seen my review of thumper's aliases stuff?  I can't see it yet, and am beginning to worry that my messages aren't getting through.
<pekuja> probably not if you don't use Eclipse
<Kbyte> They don't use eclipse. Only visual studio.
<abentley> Odd_Bloke: I see it.
 * korpios thinks the rest of the world also needs to move to OSX/Linux environments ^_^
<Odd_Bloke> abentley: Thanks. :)
<ubotu> New bug: #223666 in bzr "bzr: ERROR: exceptions.MemoryError after commit" [Undecided,New] https://launchpad.net/bugs/223666
<epsy> hi
<epsy> how does behave a central working copy?
<epsy> (the working copy of a centralized repo)
<epsy> can i set it so it only gets updated when i tell it to?
<jelmer> Odd_Bloke: yep, I saw your reply to his email
<Odd_Bloke> OK, good.
<Odd_Bloke> jelmer: Thanks. :)
<ubotu> New bug: #223720 in bzr "bzr switch prompts to decrypt ssh-key 4 times" [Undecided,New] https://launchpad.net/bugs/223720
<lamont> am I correct in understanding that bzr very strongly believes in the one-directory-per-branch model?
<lamont> that is, that it's painfully difficult to impossible to have multiple branches in one directory and bzr checkout to get between them?
<beuno> lamont, until we get nested branches, I think so, yes
<dato> lamont: I'd say "mildly" difficult
 * beuno stares at LarstiQ
<korpios> i.e., "git-style" branches
<dato> lamont: I pasted a mini-howto the other day to madduck, if you want I could dig it up, or you could read on `bzr switch`
<korpios> I did rather enjoy that part of git.
<lamont> korpios: exactly
<lamont> dato: I'll just stick with my current pain for now, instead of new and different pain
<dato> lamont: well, your choice. I'm just surprised you come looking for something, and say "I don't want to try it" when pointed at it :)
<dato> though maybe you have already, hm
<lamont> dato: it was more that you pointed at it as "mildly difficult" and sent me to read stuff... ETOOMUCHPAIN
<korpios> 'twould be nice to have a sort of init-repo that worked like that (a single WC, with "bzr switch") rather than the current style of init-repo and multiple branch-dirs
<lamont> on the bright side, I'm actually creating something in a bzr repo instead of just smashing it into git.  So I guess I'm embracing a certain amount of pain today already...
<lamont> but then, I do need to learn bzr more, so it's a good pain
<dato> lamont: k. feel free to come back when you feel adventureus again
<Odd_Bloke> thumper: So I'm having difficulty finding a landline you could call me on ATM.  My home phone has died, so I only have my mobile. :(
<korpios> Maybe a plugin that created a shared repo without trees, but kept it all stuffed in the root .bzr, and swapped out a single working copy there.  Hmm.
<Odd_Bloke> I'm going to attempt to borrow an office from someone, but it may be too late for me to catch anyone who can let me in...
<abentley> Odd_Bloke: "$ TZ=NZ date"
<Odd_Bloke> abentley: We've arranged to talk this evening, so I'm hoping he'll read scrollback including his name.
<abentley> lamont: A branch is always a directory.  But you can organize your branches however you like, and switch your checkout between them.
<takedown> hello, can anyone help with bzr and launchpad?
<beuno> takedown, sure, what's the problem?
<takedown> i try to upload some shell scripts to lp, everything seems works, revision history apply etc. but i dont see files on launchpad
<beuno> takedown, what do you mean you don't see the files on LP?  where are you looking?
<takedown> beuno: i click browse code on my branch
<beuno> takedown, link?
<takedown> beuno: http://bazaar.launchpad.net/~takedownz/+junk/virtualsheriff/files
<beuno> takedown, and did you add the files locally to the bzr repo  (ie, bzr add)
<takedown> beuno: sure
<takedown> i do step by step with guide
<beuno> takedown, I just branched it
<beuno> and it seems like you didn't
<beuno> it's empty
<beuno> try running:  bzr add
<beuno> and: bzr commit -m'Message'
<beuno> and pushing
<takedown> beuno: ok, here what i do: bzr init in directory with project, then bzr add, and then commit and push to lp
<beuno> takedown, that's correct
<beuno> and the scripts where in the folder?
<beuno> run:  bzr status
<takedown> beuno: in the same where i did bzr commands
<beuno> and see if it says if there are any unknown files
<takedown> beuno: before i try it and it says unknown files here, but now nothing
<beuno> takedown, what does: bzr revno
<beuno> say?
<takedown> beuno: two, i just wait when it apply on lp
<beuno> takedown, well, LP only has one
<beuno> try pushing again
<takedown> beuno: well, ip should apply immediately?
<takedown> because when i first commit i wait almost 20 minutes when it apply to lp
<beuno> takedown, it should be fairly fast, yes
<takedown> beuno: ok do it again
<takedown> beuno: alright, it works now
<takedown> beuno: thank you
<beuno> takedown, you're welcome  :)
<Vadi> Is it possible to embed some bzr commands into a C program?
<epsy> [mode=dumbHack]hmm, exec("bzr"); ?[/mode]
<andrea-bs> Vadi: you can use popen or the python C libs
<Vadi> Which is easiest to make & cross platform?
<Vadi> ï»¿epsy: that's sounding interesting. Can I get output from that though?
<Vadi> Like to confirm it worked or no?
<epsy> never tried that :P
<Odd_Bloke> You'd probably want to look into using the Python APIs from C.
<andrea-bs> Vadi: popen uses pipes so it will work only with Unix, so you should use Python libs
<Vadi> Yeh unfortunately 98% of the users are on windows. I'll look into this python thing then.
<andrea-bs> Vadi: this doc may be useful: http://docs.python.org/api/api.html
<Vadi> Thank you very much, was about to ask.
<ubotu> New bug: #223814 in bzr "bzr push always fails the first time and succeeds the second time" [Undecided,New] https://launchpad.net/bugs/223814
<Vadi> It
<Vadi> It's not possible to bzr push to a launchpad repository anonymously, is it?
<Odd_Bloke> No.
<Vadi> Oh, bah.
<frsk> That would be interesting, though. :-)
<sabdfl> hello all
<sabdfl> how's 1.4 coming on?
<abentley> sabdfl: Well, no one's reported any showstoppers with 1.4rc2.
<Vadi> ï»¿frsk: it's just my inability to get the curl ftp upload example to work that's causing the need for this, otherwise, not all that useful I support :)
<Vadi> *suppose
<sabdfl> abentley: looks like folks have been busy!
<frsk> Vadi: Hehe, no, it would most likely be a new place for kiddies to place their stuff
<abentley> sabdfl: Yeah, we've got plenty of pending merges ATM.
<sabdfl> abentley: for 1.4, or 1.5?
<abentley> For 1.5.  AFAIK, all that's left for 1.4 is to package and release it.
<thumper> Odd_Bloke: yes I read the scroll-back
<thumper> Odd_Bloke: can you skype?
<Odd_Bloke> thumper: I don't have a headset ATM, and realised that my landline was down (and that this would adversely affect your phoning me >.<) about 15 minutes after all the shops that sell them closed. :(
<thumper> Odd_Bloke: ok, we could do IRC in about an hour if you are around
<thumper> Odd_Bloke: gotta get the girls breakfast and myself coffee
<Odd_Bloke> thumper: Yeah, that'll suit me fine.
<thumper> ok
<schierbeck> hey guys
<schierbeck> any of y'all using bzr-gtk?
<jelmer> hey Daniel
<schierbeck> (i'm hoping yes)
<schierbeck> oh, hi j-man!
<schierbeck> jelmer: i'm fishing for some input on my latest iteration of the changes page. i'll never quit!
<Odd_Bloke> schierbeck: I use it occasionally, when I need more than just a diff (for which I use 'cdiff | less -R'), a 'bzr status', or 'bzr commit'.
<Odd_Bloke> So mostly viz.
<abentley> Have you guys noticed that viz doesn't work at all on bzr.dev?
<schierbeck> abentley: yeah, i saw it today
<schierbeck> not sure what the issue is
<abentley> I suspect it's incorrect ghost handling.
<schierbeck> abentley: if you could provide some details and possible solutions in a bug report, you'd be the man of the week :)
<abentley> By the time I know that much, I might as well fix the bug, too.
<Vadi> Is it possible to get a link to a file in bzr at it's latest revision? (so if the revision changes, the link is still valid at least)
<james_w> lifeless: hi
<schierbeck> abentley: that'd make you the man of the month! :)
<schierbeck> jelmer: i know you're not a fan of the changes page, but i'd still really love some feedback: lp:~dasch/bzr-gtk/changes-page
<schierbeck> i've made it fit in with the bugs and signature pages
<schierbeck> but it's still very rough
<thumper> Odd_Bloke: we were going to talk PQM
<thumper> Odd_Bloke: when are you looking at starting to work on this?
<Odd_Bloke> thumper: Well, term doesn't finish until the 30th of June, with exams finishing a week or so earlier than that.
<thumper> Odd_Bloke: so not until after that?
<Odd_Bloke> Probably not in any depth, no.
<thumper> Odd_Bloke: ah ok, that should be fine then
<thumper> I'm guessing that all my major bits in PQM should be done by then
<Odd_Bloke> What're you working on ATM?
<thumper> lots of stuff
<thumper> but with respect to PQM, getting it to talk to Launchpad
<thumper> so Launchpad can be the queue rather than emailing PQM
<Odd_Bloke> Oh, cool.
<thumper> Odd_Bloke: also I heard rumours about you working on PQM accepting merge directives
<thumper> Odd_Bloke: I know that abentley had done some work in this area a while ago
<thumper> Odd_Bloke: but I don't know what state it is in
<Odd_Bloke> ATM it's not altogether clear what I will actually work on.
<Odd_Bloke> XMLRPC rather than (or in addition to) email was one thing, though that may overlap with talking-to-Launchpad?
<Odd_Bloke> Certainly accepting merge directives would be something that might happen.
<Odd_Bloke> http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-f2678f1f3acd54a5199c577538301a91be6f7915-2 was the list of pet hates we got at the sprint.
<Odd_Bloke> Reading that now, I'm reminded that removing the VCS abstraction that currently exists in there and making it a bzr-only tool (with use by other VCSes via bzr-svn/-hg/-git etc.).
<Odd_Bloke> ...was going to be a focus as well.
<abentley> schierbeck: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C481641EB.4090901%40aaronbentley.com%3E
<schierbeck> abentley: man of the month! i'll review it right away!
<IsoSchiz> So... I've got some general questions about how bzr works in terms of handling distributed merges/patches.
<IsoSchiz> I can't seem to find any good documentation on this anywhere, but if I'm just being dumb and there is some, perhaps someone could point me in the right direction?
<james_w> hi IsoSchiz
<james_w> can you explain what you are looking for please?
<IsoSchiz> My question specifically is how does bzr handle/track merges across several distributed branches? Example: Devs A and B each take a private branch of the current 'head', and develop their own features. Dev B wants to build his feature on top of dev A's feature, so he syncs his branch to Dev A's branch (is this possible? Or does he have to actually take a patch file and apply that to his branch?) Then Dev B uploads his feature (built
<IsoSchiz> And if that doesn't make sense, I can try to clarify some more. :-)
<IsoSchiz> My interest really stems from the VCS we use at work, which is mostly centralised, and doesn't actually cope with this sort of thing very well at all, resulting in frequent merge conflicts and lost time.
<mwhudson> IsoSchiz: your first line got cut off
<beuno> IsoSchiz, if all devs branched from the same branch, then anyone can pull in changes from the others
<IsoSchiz> Oh, sorry, broken down into smaller chunks:
<IsoSchiz> My question specifically is how does bzr handle/track merges across several distributed branches? xample: Devs A and B each take a private branch of the current 'head', and develop their own features.
<IsoSchiz> Dev B wants to build his feature on top of dev A's feature, so he syncs his branch to Dev A's branch (is this possible? Or does he have to actually take a patch file and apply that to his branch?) Then Dev B uploads his feature (built on top of A's feature) back to the 'head'.
<IsoSchiz> Dev A does some more work on his feature, and then uploads. How does bzr minimise conflicts in this instance (i.e. half of A's code is already in the repository)?
<mwhudson> IsoSchiz: how much do you know about revision control in the abstract sene?
<NfNitLoop> yes, B can continually merge from A.
<mwhudson> sense?
<james_w> IsoSchiz: just to say that that is *exactly* the sort of situation distributed revision control is designed to deal with.
<IsoSchiz> beuno: Right, but how does bzr deal with the potential merge conflicts when teh distributed versions (which may have cross synced) remerge?
<NfNitLoop> and when A pushes changes, bzr only pushes things that have changed sine his last push.
<IsoSchiz> mwhudson: Quite a bit.
<NfNitLoop> IsoSchiz: it remembers all of the cros-syncs.
<NfNitLoop> each revision has its own unique hash ID.
<beuno> IsoSchiz, it tells you there are conflicts, and asks you to manually resolve them
<NfNitLoop> so every branch knows which revisions have been merged in.
<IsoSchiz> NfNitLoop: So there are per-branch versions?
<NfNitLoop> what do you mean?
<IsoSchiz> Well, in my example, Devs A and B can keep committing to their private branches.
<NfNitLoop> Yes.
<IsoSchiz> Then as A pushes his changes to B, B's repo knows that it last synced from 'A version x'
<NfNitLoop> You should probably see:  http://bazaar-vcs.org/Workflows
<IsoSchiz> And also synced from 'head version y'
<NfNitLoop> IsoSchiz: Don't think of it as version x or version y.
<NfNitLoop> think of it as "I have merged in changes x y and z."
<NfNitLoop> it doesn't matter which branch they came from.
<IsoSchiz> hmmmm, and in what form does it remember the changes then? As a patchfile?
<NfNitLoop> a bzr-specific changeset.
<NfNitLoop> I don't know the details.
<NfNitLoop> You don't have to.  That's the nice bit. : )
<NfNitLoop> but that changeset is uniquely identifiable across all branches.
<NfNitLoop> so any branch will know if it has merged in change X.
<mwhudson> conceptually a revision is a snapshot of tree state
<IsoSchiz> Right, ok, so in my example A makes 2 changesets (say X and Y), and B makes one (say Z). When B uploads his changeset (into which he has synced X from A), the main repo knows it has both Z and X, right?
<NfNitLoop> yup.
<IsoSchiz> So when A tries to upload X and Y, it knows it already has X and only merges in Y (and doesn't try to merge in X again)?
<NfNitLoop> right.
<hmeland_> The Z revision will have X and Y among its ancestors.
<hmeland_> Sorry, only X.
<NfNitLoop> Yeah, I think that's details beyond Iso's point...
<NfNitLoop> he mostly sounds worried about whether each tree knows what's been merged in.
<IsoSchiz> So when you do a peer sync, you actually sync more than just the current state, you sync at least some of the history of your branch as well?
<IsoSchiz> That is very clever. :-)
<NfNitLoop> IsoSchiz: Yes.  If you pull or merge from a peer's branch...
<NfNitLoop> you get ALL of the history.
<NfNitLoop> history is kept across all branches.
<NfNitLoop> which makes for neat graphs with bzr visualize and such. : 0
<NfNitLoop> :)
<IsoSchiz> Does this make bzr much slower then...? :-)
<hmeland_> It depends.
<IsoSchiz> (for network operations)
<NfNitLoop> depends on how divergent your branches are.
<NfNitLoop> So if you have to fetch lots of changesets, it can take a bit.  BUT...
<NfNitLoop> then they're all loally cached.
<NfNitLoop> and any further merges only grab what's changed.
<NfNitLoop> and then you can unplug your laptop and go develop at a coffee shop. :p
<IsoSchiz> Yes, I'd personally sacrifice performance for greater merge stability.
<NfNitLoop> IsoSchiz: What SCM systems do you use now?
<NfNitLoop> I came to bzr after CVS & SVN...  bzr makes it so easy to merge, it's easy to see why people so rarely bother with it in CVS & SVN. :p
<IsoSchiz> At work we use a proprietary system based on ClearCase; and personally I've used both CVS and SVN quite a bit.
<IsoSchiz> Right, the work system is actually pretty good at simple syncs/merges between branches, but falls down if you try to do anything slightly clever like I was describing above.
<mwhudson> bzr _can_ get confused if you have criss-cross merges
<mwhudson> though the new-ish 'lca' merge algorithm is much better at those
<IsoSchiz> Is there a description of how the algorithm works anywhere?
<mwhudson> for lca, i'm not sure
<IsoSchiz> Well, anyway, thanks guys, this has been really interesting and useful!
<mwhudson> IsoSchiz: http://revctrl.org/ThreeWayMerge is an interesting starting point
<NfNitLoop> I guess I haven't had merges that complex...
 * NfNitLoop reads up. 
<abentley> mwhudson, IsoSchiz: LCA merge is described here: http://doc.bazaar-vcs.org/latest/developers/lca-merge.html
<IsoSchiz> abentley: Thanks. :-)
<igc> morning
<poolie> hello all
<mwhudson> hi poolfool
<mwhudson> argh
<mwhudson> hi poolie
<poolie> ??
<abentley> lifeless: ping
<poolie> mwhudson: what was that?
<mwhudson> poolie: errant tab completion
<jam> morning poolie
<Odd_Bloke> 'Morning' all.
<Odd_Bloke> Well, igc and poolie. :p
<igc> hi Odd_Bloke - how's things?
<poolie> oh i see
<poolie> hello
<Odd_Bloke> Not bad, not really doing as much revision as I should be.
<Odd_Bloke> I've spent the majority of this evening learning Elvish, rather than actually doing something useful. >.<
<poolfool> mwhudson: hello
<NfNitLoop> Odd_Bloke: Learn Esperanto instead!  :D
<LeoNerd> EO is lovely
<LeoNerd> Makes you realise how odd and annoying English is
 * NfNitLoop akordas.  ;)  
<NfNitLoop> #bzr & ##esperanto are why I'm on this irc server.  :p
<Odd_Bloke> Esperanto is more useless than geeky... :p
<NfNitLoop> Suit yourself.  :)
 * mbt actually wants to learn Esperanto, but hasn't had the time.
<radix> esperanto? come on, that's not nearly useless enough. Now *Lojban*.
<NfNitLoop> I actually looked into Lojban.
<NfNitLoop> I had a friend who was very into it and talked about it all the time...
<NfNitLoop> but when asked, couldn't actually *say* anything in it.  :p
<radix> heh
<Odd_Bloke> To be fair, all I'm learning is how to write English using the Elvish Tengwa, not a whole new language.
<NfNitLoop> Odd_Bloke: aah, that's always fun.
<NfNitLoop> I've done the same w/ esperanto and hiragana. :p
<jam> radix: you beat me to bringing up Lojban
<jam> not that I know it :)
<radix> :-)
#bzr 2008-04-29
<NfNitLoop> there are a few others.  Glosi, volapuk, ido, interlingua...
<NfNitLoop> Klingon. ;)
<jam> I was thinking you should learn Arabic, because then people can't pretend that they can read what you write
<jam> Or have the characters installed on their system (yet)
<Odd_Bloke> Pfft, Elvish is just as good for that.
<jam> Odd_Bloke: can you type it in chat, so I can see?
<Odd_Bloke> No, because neither of us have the appropriate fonts installed (and I'm using irssi). :p
<jam> Odd_Bloke: well, I probably have the right fonts installed, irssi might get tricky
<Odd_Bloke> Well, http://www.kevnet.com:9000/LOTR%20TEXT/images/tengwar.jpg has an example of some of the characters.
<jam> Ø¹Ø±Ø§Ø¨Ù
<Odd_Bloke> But those are all consonants, because the vowels in a word are expressed using what are essentially accents.
<jam> Odd_Bloke: that is the system used in Arabic
<jam> Only they *usually* leave the accents off
<jam> (Except for in super special texts like the Qur'an)
<Odd_Bloke> http://www.geocities.com/tengwar2001/pubs.htm has font packs for the Tengwar at the bottom.
<Odd_Bloke> And examples of its use above that.
<Odd_Bloke> Anyhow, I'm going to return to watching Doctor Who.
<NfNitLoop> does Tengwar have a unicode character mapping? : )
<NfNitLoop> last I heard, fonts for it just mapped to ascii (english) letters.
<Odd_Bloke> NfNitLoop: I don't know anything more than the abstracts of a Google search told me, but its not in the official standard. </lying about watching Doctor Who>
<NfNitLoop> Esperanto characters are within the Latin-3 charset. (and thus, unicode, too.)  And I think I read that Klingon speakers have an unofficial unicode range.
<mbt> Last I knew, Klingon used the private use area of Unicode in fonts that support it.
<NfNitLoop> ah, that's right, "private use area".
<NfNitLoop> my unicode knowledge is a bit rusty. :)
<spiv> jam: oh, and thanks for all those reviews
<jam> spiv: happy to, sorry I didn't get to all of them.
<jam> I'm off for the night, *babytime*, see you all around
<Odd_Bloke> Stop!  *babytime*
<dberkholz> i'd like to merge two repositories that were totally independent. trying bzr merge asked for a base, and i'm not really sure what it's getting at
<james_w> hi dberkholz
<james_w> bzr merge -r0..-1 will allow you to do that, it specifies that you want revision 0 as the base, i.e. the null revision that all branches have in common.
<james_w> and with that I'm off to bed. Night all.
<poolie> night james
<lifeless> abentley: pong
<lifeless> james_w: hi
<poolie> hello lifeless
<Odd_Bloke> Man, cliffhangers suck.
<dberkholz> james_w: thanks!
<abentley> lifeless: I'd like to make an optimized fetcher for pack-0.92 to rich-root-pack.
<abentley> Can you suggest an approach?
<abentley> Pack.pack seems a little too granular...
<lifeless> abentley: I think VersionedFiles will correct the performance of plain to rich roots with packs
<abentley> Okay.  You're planning to get that in this cycle anyhow, right?
<lifeless> yes
<lifeless> this week I hope
<abentley> Okay, so I'll reassess whether that's necessary then.
<lifeless> if you do want to do one, I would subclass Packer
<lifeless> you'd need to change the main driver function
<lifeless> as you won't be able to copy the revisions blind, nor the inventories
<igc> bbiab
<lifeless> poolie: one_five is missing
<poolie> just add it if you want to use it...
<lifeless> ok
<lifeless> poolie: abentley: jam: think its tasteful to expose the transactional ability of a repository?
<lifeless> e.g. packs can safely request unordered streams
<lifeless> but knit repos need ordered streams
<abentley> lifeless: My gut reaction is that it's not tasteful, but I could be convinced.
<lifeless> ok
<lifeless> so in requesting from a smart server
<lifeless> unordered will perform better because it can linear-scan the pack files into the stream
<lifeless> but unordered requires much more IO and buffering when inserting into a knit style repository
<lifeless> also with direct access the same difference will show up
<lifeless> abentley: so the problem I need to solve is how to get the right ordering flag in the requests
<lifeless> abentley: without duplicating all the fetch logic
<abentley> For what purpose?  Not fetch?
<abentley> It has to be insertion, or else atomicity or the lack of it in the target is irrelevant.
<abentley> Which in most cases is fetch.  So I don't understand what "without duplicating all the fetch logic" means.
<lifeless> for fetch
<lifeless> well
<lifeless> for the same model/serialisation fetching between two repositories
<lifeless> if both are knits/weaves we need topological ordering
<lifeless> if the target is packs we want unordered
<lifeless> which lets the source optimise reads
<jam> lifeless: I'm willing to break abstractions when necessary
<jam> as long as there are tangible benefits
<lifeless> jam: I've been thinking about find_difference
<lifeless> jam: I think a profitable avenue is to consider reframing the halting problem as 'determine the relative graph height'
<jam> lifeless: well, I have code now that performs fairly reasonable on bzr.dev
<jam> for find_unique, talking <100ms for all merge nodes
<jam> well, on average
<lifeless> jam: that seems slow to me
<lifeless> jam: and I bet it is doing more work than needed if it is essentially tracking all the nodes independently
<jam> lifeless: only interesting tips
<jam> but sure
<jam> I can't say that there is a lot less you could genuinely do
<abentley> lifeless: I understand the benefit of optimizing read order.  I don't understand the problem with doing that via Interrepository.
<lifeless> abentley: RemoteRepository
<lifeless> abentley: for pushing into a RemoteRepository the selected RemoteRepository will be the same regardless of the actual disk format
<abentley> gotcha.
<abentley> Well, like I said, it was a gut instinct.  If that's the most practical way to proceed, go ahead.
<abentley> But the way RemoteRepository masks the real repository is a continuing problem.
 * AfC waves to jam
<lifeless> abentley: my instinct isn't to do so either; but I do need to solve the problem eventually; using topological ordering everywhere will impair pack performance
<lifeless> ok full test run with join() out of use
<abentley> Well, we could just always do unordered and make the luddites suffer :-)
<lifeless> I seriously considered that
<lifeless> however the pathological cases for that really are pathological
<igc> reviewing abentley's patches now
<lifeless> spiv: my versioned_files branch on lp/puc
<spiv> lifeless: ta
<lifeless> puc will obviously be more up to date
 * mtaylor is away: I'm not here right now
<poolie> lifeless: hi, want to talk when you're done?
<lifeless> lets talk now
<lifeless> night all
<jave> hello
<jave> I'm new to bazaar
<jave> I have made a local copy of the emacs bzr repos and made some changes
<jave> how do I get the diff between my local branch and the emacs repos?
<jave> I tried for instance: bzr diff --old HEAD --new emacs-winprop
<james_w> jave: does "bzr diff -r submit:" do what you want?
<jave> ill try, its rather slow
<jave> I'm using bzr 1.3.1 dsitributed with fc8
<Kinnison> Hi, I'm about to embark on some Linux kernel development work and I need to revision control it. While 'git' is the obvious choice, I'd prefer bzr if possible since i'm used to it. How well does bzr cope with linux-kernel size trees and will loom cope with it too?
<jave> james_w: submit: seems to do the thing, Thanks !
<james_w> hi Kinnison
<james_w> I've never tried bzr on a kernel size tree, so I can't say for sure I'm afraid.
<Kinnison> :-(
<Kinnison> I hate git
<spiv> Kinnison: well, people have imported emacs and openoffice into bzr, so it at least doesn't explode out-right.
<spiv> I don't have any actual numbers for you though.
<james_w> do the autotest tests include the kernel?
<igc> james_w: the usertest ones do (if that's what you mean)
<james_w> hi igc
<igc> hi
<james_w> yes, that's what I meant.
<igc> Kinnison: we currently include a snapshot of the kernel in our performance testing but it's a historyless repo
<igc> Kinnison: if you get a copy of the kernel (with history) imported into Bazaar, please let us know and we'll then start including that in the testing we do
<igc> for details on the tests I run, see the bzr-usertest plugin
<igc> you should also find bzr-fastimport useful for doing the migration, though it might be have a few bugs
<igc> james_w: have did your OpenWeek session go?
<igc> s/have/how/
<james_w> it was ok thanks. Not many questions though.
<Kinnison> igc: I don't care about the kernel's history, it's more for managing a series of patches I need to write
<Kinnison> igc: I figured loom made sense for that
<james_w> Kinnison: I would imagine that bzr add in the tarball and then loom would probably be ok.
<Kinnison> james_w: That's what I'm hoping, but I'm making a copy of the git repo just in case
<Kinnison> One thing git has going for it is that it filled my 10Mbps pipe
<Kinnison> I've never seen bzr manage that
<james_w> igc's usertest results show all tested commands taking under a minute, with only 4 taking over 30 seconds, and only 5 over 11 seconds.
<Kinnison> Well, I have a crappy slow HDD so we'll see :-)
<Kinnison> OTOH, 4GiB of RAM helps
<Kinnison> Hmm, if bzr st takes too long I'll have to remove it from my prompt
<spiv> 4GiB will definitely help with bzr st...
<semslie> http://domscripting.com/blog/display/41
<Kinnison> It's merrily committing and thus chewwwing all my CPU and disk :-(
<Kinnison> Oh, updatedb is running
<Kinnison> grr, that took 5 minutes, thanks updatedb
<Kinnison> otoh, bzt st takes around 1.5s, so kudos to the team
<Kinnison> Okay, can I reconfigure a branch into a repository, or do I have to pull/branch it into one?
<mwhudson_> i think maybe bzr.dev can reconfigure it
<mwhudson_> i can't remember if that bit landed
 * Kinnison updates then, my bzr.dev mirror is at r3334
<igc> night all
<fbond> Hi, any opinions or work-arounds for https://bugs.launchpad.net/bzr/+bug/214894 ?
<jam> bug #214894
<jam> Where is ubotu?
<jam> fbond: you can do "bzr pull . --overwrite"
<jam> and after that "bzr push" should work
<fbond> jam: and a fix is forthcoming?
<fbond> jam: have my repos/branches suffered any permanent damage (I assume not)?
<jam> fbond: nothing serious, you just used an older version of bzr (probably a *long* time ago)
<jam> which allowed the history to wander
<jam> see bug #177855
<jam> https://bugs.edge.launchpad.net/bzr/+bug/177855
<fbond> jam: So is it enough to run bzr check on the remote branch and then push to it again?
<jam> fbond: you shouldn't need to run bzr check even
<jam> upgrading the remote branch would also fix it, though.
<fbond> jam: Okay, `bzr pull . --overwrite' should be run on the remote branch, then?
<jam> fbond: I think so
<jam> It has been a while since I worked on this
<jam> if you want, please post your results to bug #177855
<fbond> I assume that `bzr pull . --overwrite' just rewrites the branch's revision history...
<jam> fbond: correct
<jam> it just needs to be regenerated so that it is "canonical"
<fbond> jam: Hmm, that didn't seem to work.  I'm trying `bzr reconcile' (as is mentioned in #177855).
<fbond> Or maybe I need to be running these on the local branch (not the remote one)...
<jam> fbond: just as a help, can you run "bzr info" on both branches and pastebin the results?
<fbond> Which pastebin?
<fbond> jam: Should I use pastebin.ubuntu.com?
<jam> fbond: that is fine
<fbond> http://pastebin.ubuntu.com/8758/
<fbond> jam: I cleansed some URLs and paths and things, hopefully I didn't screw that up.
<fbond> So the remote branch is bzr+ssh://user1@host1/home/user1/project/
<jam> fbond: yeah, no problems with the urls
<jam> I wanted to see the other info
<jam> namely the "format:" lines
<fbond> jam: That's what I figured.
<jam> fbond: just a sec, phone call
<fbond> jam: Take your time.
<abentley> jam: AFAIK, reconcile doesn't currently adjust revision history.
<jam> abentley: no it doesn't, I was going to work on that right now
<jam> :)
<jam> Since we have 4+ bugs reporting the same thing
<abentley> Cool
<jam> we probably need to fix it
<abentley> your bug comment about reconcile is a bit misleading, though.
<jam> abentley: well I thought I wrote "we need to do X"
<jam> not that "X" works
<jam> abentley: but I can see how my comment is misleading
<jam> I'll post a followup
<jam> abentley: where do tests for "check" go? There isn't a 'test_check.py'
<jam> or maybe this is a branch impl test?
<abentley> I don't know.
<jam> I haven't worked in the check/reconcile code for a while
<jam> And I know Odd_Bloke was sticking his fingers in there recently
<Peng> jam: You don't actually advocate forbidding http://host/branch/subbranch, right?
<jam> Peng: I actually *like* it, but if you are going to forbid "http://host/repo" being a branch, then it seems the other should be gone as well
<fbond> jam: Hmm, so I guess I can just push over sftp:// and things will work, eh?  (`bzr pull . --overwrite' doesn't seem to do anything useful for me).
<jam> fbond: can you do "bzr push --overwrite" and see if that works?
<jam> I'm thinking the code path may not anymore
<fbond> jam: Sure thing...
<jam> The problem is it detects "nothing changed" and then doesn't actually fix things up
<jam> abentley: "knit or dirstate" is Branch5, right?
<jam> Branch6 would report "dirstate-tags"
<jam> IIRC
<fbond> jam: I get the same AssertionError with push --overwrite
<abentley> Right.
<Peng> jam: Well, I think having "http://host/repo" be a branch makes it hard to discover when you're just browsing the web server, but there's no need to bother banning it, especially at the cost of nested branches.
<jam> fbond: you're on a Linux machine, right?
<fbond> jam: yep, RHEL on the server, Hardy on my workstation.
<jam> Peng: mostly just for "consistency", if people want to disallow nesting branches, etc
<jam> fbond: ok, I'll give you a snippet of code that will get things working again, and then I'll go try to fix reconcile and check
<fbond> jam: okay, thanks!
<fbond> lifeless: BTW, I am holding off on any loom workflow docs until some enhanced automation is in place to support the "quilt replacement"-style workflow.
<fbond> lifeless: It would just feel a little silly to recommend that people do so much manual work to move around the loom after committing new changes to a low thread.
<fbond> lifeless: So, please do keep my posted if anything changes with this, and I'll be happy to document how I use things.
<jam> fbond: http://pastebin.ubuntu.com/8766/
<jam> save it as a "cleanup.py"
<jam> and then run it in your local branch
<jam> afterwards, bzr push should work
<jam> fbond: let me know if it works/doesn't work
<jam> we can attach it to the bug as a current workaround
<fbond> jam: no, didn't do anything (and didn't produce any output)...
<jam> fbond: hmm....
<jam> fbond: just to make sure things are valid: from bzrlib import branch  b = branch.Branch.open('.') b.lock_read() try:   orig_revno, last_rev = b.last_revision_info()   real_revno = len(list(b.repository.iter_reverse_revision_history(last_rev)))   if orig_revno != real_revno:     print "Changing revno from %s => %s" % (orig_revno, real_revno)     b.set_last_revision_info(real_revno, last_rev) finally:   b.unlock()
<jam> sorry
<jam> http://pastebin.ubuntu.com/8768/
<jam> fbond: also, can you try running that and replacing '.' with the url of the branch you are pushing to?
<fbond> jam: local: not changing revno, both match at 404
<jam> fbond: ok, that is a bit odd
<jam> fbond: and 'bzr push' still fails with the assertion error?
<fbond> jam: remote: not changing revno, both match at 381
<jam> fbond: ah, at least local and remote disagree on the revno
<jam> something weird is happening, though
<fbond> jam: yep, push gives: AssertionError: 403 != 404
<jam> ok, that is, at least, a little bit different
<fbond> jam: local and remote disagree because I have ~20 revisions I'm trying to push out :)
<jam> fbond: any chance I could see these branches directly?
<fbond> They are not publicly accessible at the moment (and contain some amount of proprietary code).
<fbond> I don't think folks would be happy with me if I shared them.
<jam> fbond: well, something weird is happening, I guess I can write some more python code for it
<jam> (I certainly wouldn't ask for making them public, just personal access)
<jam> but I won't push
<fbond> jam: Yeah, I follow you.
<jam> support by remote is just a pain
<fbond> jam: I've done it myself, I know what you're talking about..
<jam> fbond: I just realized I was lock_read() the branch, the set_last_revision_info would fail anyway :)
<fbond> jam: Ah.
<jam> that wasn't the problem, but it would have been
<jam> fbond: http://pastebin.ubuntu.com/8775/
<jam> fbond: give that a shot, and tell me what it spits out
<fbond> jam: okay, I'm dealing with an unrelated crisis, be right back with you ;)
<jam> fbond: np
<fbond> jam: I get bzrlib.errors.NotBranchError; it complains about the parent branch (which differs from the push branch).
<jam> fbond: ah, I noticed that, I thought it was a bit weird that one had a '.' and the other had a '-'
<fbond> Looks like this:
<jam> fbond: change the line "get_parent()" to "get_push_location()"
<fbond> Okay, that's what I thought.
<fbond> jam: it's running; I'll let you know when it finishes.
<fbond> jam: Now I'm getting LockContention
<jam> fbond: ...? can you paste the traceback
<jam> that seems weird
<jam> fbond: but you can change the "lock_write()" to "lock_read()"
<jam> since I don't actually mutate any data
<fbond> jam: okie dokie
<fbond> jam: It ran for a while before reporting this.
 * mtaylor is back (gone 10:47:19)
<jam> welcome back mtaylor
<mtaylor> jam: thanks!
<fbond> jam: now I only see No handlers could be found for logger "bzr" (no other output)
<fbond> jam: This was running the script against my local branch.
<fbond> If it modified the branch, it would've printed something, right?
<jam> fbond: I think so, you might try adding a "from bzrlib import trace; trace.enable_default_logging()" at the top
<jam> just to see what it wants to log
<jam> fbond: otherwise I'm pretty confused. It seems the two repositories disagree on something, but so far I haven't found anything that they disagree on :)
<fbond> jam: That makes me think that the two repositories don't disagree so much as 1.3.1 may be backwards incompatible with the remote server or repository.
<fbond> Is it possible?
<david_kofsky> How do I merge two branches with no shared history?
<jam> david_kofsky: generally " bzr merge -r 0..-1 ../other/branch"
<jam> it sort of depends what you are trying to do, but that at least forces the merge to finish
<fbond> jam: would it help to have the repositories to look at?
<fbond> jam: they are each >200M (I assume they can't be compressed much)
<jam> fbond: well, simple ssh access would be sufficient
<jam> you can even run 'screen' so that you can track everything I do
<jam> It would make things a bit easier for me to debug.
<fbond> jam: Which screen feature allows that?
<jam> fbond: me being on the same screen page as you
<jam> -x
<jam> allows multiple connections to the same screen
<jam> You can even follow along as I go
<fbond> Hang on.  I'll admit I'm uncomfortable with the idea; nothing personal, of course.  Using screen doesn't prevent you from opening another connection, of course.
<fbond> In any case, give me just a minute...
<jam> fbond: of course
<jam> though you can set up ssh so that I can only connect to "screen -xRR"
<jam> or something
<jam> I believe you can do:
<fbond> jam: yeah, that's what I figured.
<jam> command="/usr/bin/screen -xRR" ssh-rsa ...
<jam> in the .ssh/authorized_keys file
<jam> You can use my public keys from launchpad, and then remove access when we're done
<jam> or whatever
<jam> Just letting you know what makes it easiest for me
<jam> We can try to keep going back and forth, but certainly something weird is going no
<jam> on
<jam> fbond: I did put together a branch which implements 'bzr reconcile' in case you want to try it
<jam> I would ask that you start from bzr.dev and then bzr pull --overwrite from http://bzr.arbash-meinel.com/branches/bzr/1.5-dev/reconcile_rev_history_177855
<mathrick> hmm, why exactly doesn't bzr revert ask for confirmation?
<jam> mathrick: in general, you can't lose modifications with revert
<mathrick> howso?
<jam> as it saves backups for files which are modified
<mathrick> ah
<mathrick> I didn't know that
<jam> ~ files
<jam> It doesn't do it for all files, if it believes you could regenerate it.
<jam> So, for example, if you 'bzr merge ../other/branch; bzr revert'
<jam> it will just revert without a backup
<jam> because it assumes you can just merge again
<mathrick> jam: but if the files had any other changes besides the merge, it'll back up?
<jam> mathrick: yes
<mathrick> jam: also, as I'm working on that script for syncing, I have two questions: 1) it does fast_host.push(mainline), shouldn't it also push in the other direction?
<mathrick> jam: and 2) do you want copyright on the initial code you gave me? (I will be publishing it once it's a bit more mature and featureful)
<jam> mathrick: not a big deal
<mathrick> ok, cool
<jam> you probably want to "fast_host.pull()"
<jam> Just because there are assumptions about which side is "fast" to access
<mathrick> jam: yeah, but I was right about it being only a one-way sync?
<jam> push only syncs in one direction, yes
<mathrick> are there any specific recommendations as to which should go first (push or pull)?
<jam> mathrick: shouldn't really matter. I would tend to favor the one you expect to change the most
<mathrick> jam: hmm, actually, pull will only incorporate changes that can be committed directly onto the current tip, which means that _any_ situations in which there are independent commits on both between syncs results in a conflict, no?
<mathrick> jam: do you recon it'd be beneficial to have it attempt a merge automatically?
<mathrick> or just resolve every such case manually?
<mathrick> I intend it to run every 5 or so minutes, so I don't really expect the periods between syncs to be very long, but it could still happen
<jam> push and pull will both error for diverged branches, yes
<jam> the only problem is if one side is technically a merge of the other
<jam> but I wouldn't expect that to be a specific problem for you
<jam> as you sort of *want* that to happen :)
<mathrick> yeah, manually or not, I still need the tree to be merged in the end :)
<jam> mathrick: as for auto-merging....
<jam> you need an actually tree on disk to do a merge
<jam> actual
<mathrick> I just need to work out which of them is "the" tree
<mathrick> jam: yeah, that might be a problem
<jam> and it seems like these are mostly just branches in a repository
<jam> you could always create one in /tmp, tec.
<jam> etc.
<jam> I'm not a huge fan of auto-merging
<mathrick> okay, so I won't do that for now at least, and will decide how to tackle that later
<jam> and you'll still need to 'bzr pull' on the client
<mathrick> yeah
<mathrick> the issue of having a canonical tree is kinda icky, let's not think about it just yet :)
<mathrick> jam: btw, here's a sort-of current snapshot of it at work: http://sei.meidokon.net/ :)
<mathrick> I'm currently reworking the table weaver to yield more aesthetically pleasing results
<jam> mathrick: pretty, planning on releasing this publicly?
<mathrick> jam: yep
<mathrick> that's why I asked about copyrights
<jam> heck, if you want to give me credit, go ahead
<mathrick> :D
<jam> But for something like this, I don't really care
<mathrick> okay, I will credit you in AUTHORS
<mathrick> btw, taking LogFormatter and making it into something that can output multiple-column HTML tables is not exactly trivial
<mathrick> it might make sense to release HtmlTableWeaver as a separate plugin on its own
<SeWPKiP> hi all!
<SeWPKiP> would someone be able to help me out with a weird problem?
<SeWPKiP> I played around with pagaent today and can't get my windows box to connect anymore .. to any bzr location
<SeWPKiP> re-installing bzr and clearing away all files in ..my profile/application/data/bazaar also didn't help
<mathrick> SeWPKiP: did you clear pageant's files?
<mathrick> in particular, stored keys / locations?
<mathrick> also, did you try connecting to any locations manually (ie. with putty)?
<SeWPKiP> mathrick: that's for responding!
<SeWPKiP> i didn't know i had to. any idea where those files are?
<mathrick> SeWPKiP: I dunno if you have to, but that's what I'd suspect off-hand
<mathrick> SeWPKiP: look in my profile/application/data/pageant or similar
<mathrick> possibly in my profile/ssh or so
<SeWPKiP> still looking but can't find anything like that
<mathrick> SeWPKiP: okay, do you still have pageant running?
<SeWPKiP> no i don't
<SeWPKiP> also, restarted the computer
<mathrick> SeWPKiP: did it help?
<SeWPKiP> well, i tried all that before coming here
<mathrick> ah
<mathrick> well then, try launching pageant again, and see if it has any keys remembered
<SeWPKiP> nope,didn't work either
<SeWPKiP> it hasn't remembered a thing
<SeWPKiP> i'm just guessing that pageant is the problem - because that's the most recent thing i did
<mathrick> SeWPKiP: hmm, odd, and yeah, it seems so
<SeWPKiP> well, that and branching between local folders
<mathrick> SeWPKiP: try connecting with putty first
<SeWPKiP> that works
<SeWPKiP> plink works as well
<mathrick> SeWPKiP: okay, does bzr give you any error?
<SeWPKiP> yep
<SeWPKiP> it's ERROR: Conection Closed: please check connectivity and permissions
<mathrick> ah
<SeWPKiP> and try -Dhpss if further diagnosis is required
<SeWPKiP> so, pulled up the log
<mathrick> SeWPKiP: okay, open cmd.exe, and do what it tells you to
<SeWPKiP> ok
<mathrick> ie. run bzr -Dhpss ls ssh://foo@bar/baz/
<SeWPKiP> i sent you the result
<SeWPKiP> oops
<SeWPKiP> i sent you the result
<mathrick> huh
<mathrick> SeWPKiP: yeah, I got it
<mathrick> it *should* work
<mathrick> SeWPKiP: please give me the exact line you gave it
<SeWPKiP> bzr -Dhpss ln bzr+ssh://name@location/foo
<SeWPKiP> just ssh:// wouldn't work
<mathrick> ah, right
<mathrick> SeWPKiP: is the location public?
<SeWPKiP> no it isn't ..
<SeWPKiP> but other people can access it, no problem
<mathrick> SeWPKiP: I meant I wanted to try precisely the line you used, to see why it was complaining about bad arguments
<SeWPKiP> thanks for that, but that's not possible
<mathrick> bzr -Dhpss ls bzr+ssh://bzrserve@megumi.local/home/bzrserve/repo/faktoid/ <-- that works just fine for me
<mathrick> (and no, it's not public either)
<mathrick> SeWPKiP: hmm, is what you pasted me *all* it outputs?
<SeWPKiP> yes, it's not helpful at all
<mathrick> ah, I guess not, you quit with excess flood
<mathrick> SeWPKiP: please use pastebin.com or similar
<mathrick> to make sure I can see it all
<SeWPKiP> ok, brb
<SeWPKiP> trying to use the --serve comand now
<SeWPKiP> to pinpoint ssh as the problem
<SeWPKiP> yeah it clearly is ssh .. i mean, just using --serve works
<SeWPKiP> really really odd
<mathrick> SeWPKiP: okay, what happens if you uninstall pageant?
<SeWPKiP> that's not an option
<SeWPKiP> it's just a single binary
<SeWPKiP> seems like there are some weird ssh certificates lying around or something.. just can't find them
<SeWPKiP> and bzr won't tell me what it's doing
<abadger1999> abentley: Do you still know how the trac-bzr plugin works or have you purged all knowledge from your memory?
<abentley> abadger1999: I have some foggy recollections.
<tro> is bzr-svn compatible with bzr 0.4?
<tro> i mean ... the latest bzr? 1.4?
<abadger1999> abentley: In class BzrRepository(versioncontrol.Repository) there are some references to self.repo
<abadger1999> but I dont see that self.repo is created anywhere.
<abadger1999> Do you remember what was going on with that?
<abentley> abadger1999: No, I don't remember.  I had a look at the file and I couldn't see how it would have worked.
<abadger1999> abentley: Okay.  At least I don't feel like I'm missing some special trick  :-/
<abadger1999> Thanks for looking.
<abentley> You're thinking of the line in parse_rev?
<abentley> That line is probably a fossil-- it was introduced by Marien Zwart, which was before I worked on it.
<abadger1999> yeah, parse_rev(), next_rev(), and rev_older_than()
<abadger1999> Okay.  I'll just cut that logic out of parse_rev().
<tro> i'm trying to push a bzr branch into an svn repo with the bzr-svn plugin, but i need to be able to specify the username to use in svn. is that possible?
<bob2> put it in the url?
 * tro headdesks
<tro> of course!
<tro> thanks
<poolie> hello
<beuno> morning poolie
<poolie> hello beuno
<igc> morning all
<beuno> mornin' igc
<lifeless> >hate my isp atm<
<beuno> aaaaand good morning lifeless   :)
<beuno> javierder, ping
<igc> abentley: bb is down again for me - 550 Internal Server Error
#bzr 2008-04-30
<abentley> igc: restarted
<javierder> bueno, yoh!
<beuno> javierder, hey. I see you've been keeping up the work on bzr-gedit  :)   Do you have an ETA for the next release?
<javierder> beuno, yes, next friday
<beuno> I'm flirting with the idea of packaging it, but I'd like to get rid of the bzr-gtk dependencies before I do
<beuno> is that close by on the roadmap?
<javierder> that's actually not in the roadmap. but i don't think much code is needed. I'll check it now.
<beuno> javierder, cool  :)   I think that if it's packaged, you might get more users testing it
<javierder> ok, greta
<javierder> *great
<beuno> no real hurry, just wanted to check in to see what the situation was
<javierder> beuno, check it now if you want :)
<beuno> javierder, looks good. Did you test it withough bzr-gtk installed?
<javierder> beuno, not exactly, but i tested it changing the module it tries to import. if the plugin can't find bzrlib.plugins.gtk some commands won't work.
<beuno> javierder, good enough. I'll look into packaging it then
<javierder> ok, great!
<lifeless> fbond: I'd really like docs for what you do today; such things will help clarify what automation is most useful.
<fbond> lifeless: Okay, I'll put something brief together.
<lifeless> fbond: it doesn't have to be hugely polished
<fbond> lifeless: Being temporary documentation, I wouldn't think so :)
<fbond> lifeless: I guess it's all temporary documentation, though.
<lifeless> :)
<abentley> lifeless: In my pull change, there will be no error if the specified revision id is in the target, but not the source.  This doesn't cause any tests to fail.
<lifeless> abentley: ok, land it then
 * igc lunch
<lifeless> woo
<lifeless> looks like this will be it
<lifeless> taking a short break while this test tests
<awmcclain> Has anyone configured bzr-email to work with gmail? I have the gmail-branch, but it's not sending and I'm not seeing any errors in .bzr.log
<lifeless> abentley: around ?
<abentley> lifeless: Yup
<lifeless> abentley: I am about to start rewriting fetch.py for VersionedFiles; I am hoping you can get your rich-root conversion fixing patch landed asap :)
<lifeless> so that I can layer on your work
<abentley> I hope so too.  It's in igc's hands now.
<igc> abentley: I approved that an hour or so ago I think
<igc> make that 30 minutes :-)
<igc> just some comment tweaks and all good now
<abentley> Okay.
<lifeless> I'm submitting my new streaming api for review too
<lifeless> it may textually collide with your patch I think, but in a trivial fashion
<lifeless> the next phase will be more...dramatic
<abentley> lifeless, igc: Cool.  I'll do that now.
<abentley> lifeless: It's in progress.
<abentley> lifeless, poolie: I have just added a "My Todo" tab to Bundle Buggy.  It lists all your merge requests that haven't been merged or rejected.
<lifeless> nice, thanks
<abentley> You're welcome.
<abentley> It should list everything that's gotten a resubmit, or is pending review, or has been approved.
<abentley> Let me know what you think.
<abentley> lifeless: Will your work have a significant impact on the reconcile code?
<lifeless> abentley: I'll be leaving a thunk behind
<lifeless> abentley: but ideally, yes, I will be touching everything
<abentley> Reconcile is the remaining piece of this inventory_sha1 stuff.
<lifeless> yeah
<abentley> I've started on tests, but perhaps the fix should wait.
<lifeless> I think we won't collide
<lifeless> I can leave reconcile till last
<abentley> Okay.
<fullermd> Is 1.4 blocked on something, or are we just waiting out RC testing still?
<fullermd> That knit-related thing jam had, maybe?
<igc> bbl - out for a medical appointment
<spiv> fullermd: I'm not the release manager, but I would like to see jam's fix in 1.4
<fullermd> Yeah.  If it's worth a 1.3 point release, surely it should go into releases that don't yet exist   :)
 * mtaylor is away: going to sleep... very tired
<emgent> Unable to obtain lock lp--1227538260:///lock
<emgent> held by emgent@bazaar.launchpad.net on host vostok [process #23990]
<emgent> locked 13 minutes, 9 seconds ago
<emgent> Will continue to try until 10:12:37
<emgent> some idea to unlock ?
<bob2> break-lock might work
<emgent> cool.
<fullermd> Mmm.  'viz' seems to have picked up a bug in showing Children on the Relations tab.  It's only showing 2nd (and later) children...
 * Peng hits bzr.
<Peng> .bzr.backup does not survive a round-trip through "bzr add" and "bzr revert" very well.
<poolie> Peng: oh, i can imagine
 * AfC is a bit vague why someone would want to `bzr add .bzr.backup`
<Odd_Bloke> We should probably add it to the default ignores...
<awilkins_> Maybe make it \.bzr.*/
<bob2> \.o./
<Peng> I didn't *want* to add it.. I did "bzr add", forgetting it was there.
<Odd_Bloke> Well, there was/is a patch to change it to .backup.bzr, so that wouldn't cover that case.
<Peng> It's "backup.bzr" now.
<Peng> This .bzr.backup dir is just really old.
<Odd_Bloke> So I think specifying it explicitly will ensure that it doesn't get missed in later changes.
<Peng> AfC: I didn't *want* to add it.. I did "bzr add", forgetting it was there.
<AfC> Peng: ah.
<AfC> Peng: that would certainly seem a bug then - I don't think one should be able to add such a thing.
<spiv> It might make sense to have backup.bzr on the default ignore list.
<igc> spiv: I think that makes a lot of sense
<igc> time for sleep - night all
<spiv> G'night.
<Odd_Bloke> igc: I'll make those changes and push them to LP, so as to make your merging of it easier.
<Odd_Bloke> 'It' being the hooks stuff.
<Peng> Hey, my ~/.bazaar/ignore file had its first birthday Monday. :D
<jsled> I've a source file that bzr (reasonably) thought was binary.  I've removed those characters.  How to tell bzr that it's now safe to consider it a text file?
<luks> it will do that automatically if it can't find any null bytes
<luks> bzr doesn't really make difference between text and binary files, internally
<bob2> I'm pretty sure bzr only considers that for display (e.g. diff) and does it at display time rather than storing it like cvs
<jsled> after removing the bytes, `bzr diff` still calls at least one of the files binary; committing did the trick.
<jsled> thanks.
<gumpa> Howdy. {$bzr commit} opens $EDITOR, but issues {bzr: ERROR: empty commit message specified}
<luks> did you save the file?
<abentley> gumpa: You mean it does this before you have a chance to enter a message?
<gumpa> yes, before editing
<gumpa> saving leaves bzr_log.adslf
<abentley> Your editor is forking probably off and giving control back before it's finished editing.
<gumpa> Ah, so it's GVim configuration?
<abentley> Editors can often be configured not to do this.  For example, "gvim -f" prevents this in gvim.
<abentley> So yeah, either set EDITOR or BZR_EDITOR to "gvim -f"
<abentley> Though personally, I prefer plain vim for that task.
<gumpa> OK, changing $EDITOR to vim = working, I'll put that in the bzr conf
<gumpa> thx
<abentley> np
<muszek> hi
<muszek> I'm in dir /a, I have ran 'bzr init b', co I have /a/b/.bzr.  now, I'm trying to bind it to another repo, but I'm still in /a... I issue a command: 'bzr bind bzr+ssh://host/dir b' and I get an error: "bzr: ERROR: extra argument to command bind: b"
<muszek> is there any way around it?
<muszek> the thing is that these commands are issued from a script that's located in /a
<muszek> n/m... I figured it out 5 seconds after I asked the question
<abentley> bind only affects the current directory at the moment.  Some of our other commands do accept -d to specify an arbitrary directory.
<LeoNerd> I don't suppose there's an  ununcommit command, is there? :)
<LeoNerd> I got a bit overzealous accidentally... uncommitted too much
<james_w> LeoNerd: pull can get you back
<Odd_Bloke> igc: https://code.launchpad.net/~daniel-thewatkins/bzr/hooks
<jelmer> does anybody know what the current plans are wrt 1.4?
<cr3> is there a way for bzr to purge .pyc files when .py files are removed?
<james_w> cr3: I don't know of one, sorry.
<cr3> james_w: there's probably a hook mechanism I could use, that'd be neat
<james_w> cr3: you could add a few hooks I expect, but there's not one for whenever a file is removed I don't think.
 * Mez yawns
<Mez> hmm, when starting a new branch, and adding lots of files  -  what annoys me most is that you have to wait twice for it to go through all the files
 * Mez has been waiting for about 5 mins now for bzr ci to get to the editor
<jam> Mez: "bzr add -q" "bzr commit -q"
<jam> and, of course, "bzr commit -m 'I dont need no stinkin editor'" :)
<Mez> yeah, but it still has to do the work
<Mez> and I know of -m - but need multi lines
<jam> Mez: multiple lines works fine here
<jam> depends on your shell
<jam> It doesn't seem to work for Win32 and .bat files
<jam> which makes me sad
<jam> Since I always use it everywhere else
<jam> and don't realize it is broken until I do "bzr log" and wonder where my message went.
<nekohayo> jelmer: does this (https://bugs.launchpad.net/bzr/+bug/177874) mean that I should now be able to merge a bzr-svn imported branch into a regular pack-0.92 branch, by any chance?
<jelmer> nekohayo: it means you can now upgrade the pack-0.92 branch to rich-root-pack without problems
<jelmer> nekohayo, and after that, merging shouldn't be a problem
<nekohayo> jelmer: but what about merging? such as https://bugs.launchpad.net/bzr/+bug/202884
<abentley> nekohayo: You will never be able to merge pack-0.92 into rich-root-pack.  pack-0.92 cannot represent the data in rich-root-pack.
<abentley> sorry,
<abentley> you will never be able to merge *rich-root-pack* into *pack-0.92*
<nekohayo> means rich root pack is superior? I don't quite remember if it was supposed to be the next default, or if it was some other format
<abentley> nekohayo: Yes, it is superior, and I hope to make it the next default format.
<abentley> But at present, you should only use it if you need interoperability with bzr-svn data.
<nekohayo> not stable yet?
<abentley> It is stable, but it is incompatible with 0.92.  So if my project uses 0.92, and you use rich-root-pack, then I can't merge your changes.
<nekohayo> when do you plan to make it the default then?
<Odd_Bloke> nekohayo: 1.5, I think.
<nekohayo> Odd_Bloke: o_o I see a mailing list post about bzr 1.5 dated february 2006, I'm somehow scared
<fullermd> You probably see a post about baz 1.5   :p
<nekohayo> baz != bazaar?
<fullermd> Yes and No and Sorta and Once-Upon-A-Time.
<fullermd> bazaar was baz, and is now bzr.  Discontinuity.
<nekohayo> headache ensues?
<fullermd> Well.  Only if you try to use baz   ;)
<mwhudson> do not look into the light
<nekohayo> hm. can I get bzr from bzr, and run it in place (without installing it)?
<fullermd> For the latter, you just need to run the 'bzr' in that dir; the rest will Just Work.  The simplest way is to make a symlink somewhere in $PATH (I use ~/bin) pointing at it.
<jam> nekohayo: and we recommend that you run "make"
<jam> it isn't strictly required, but it allows you to use the compiled forms of a few key functions
<jam> (we have pure python fallbacks for everything)
<nekohayo> jam so it won't confuse itself with the systemwide-installed bzr?
<jam> nekohayo: shouldn't
<nekohayo> ok
<jam> I run from ~/bin/bzr all the time
<jam> => dev/bzr/bzr.dev/bzr
<jam> And I still have a sys-installed one.
<jam> Only real difference is that running from source may not find the system installed plugins.
<nekohayo> jam it takes a helluva long time to bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev, is there a way to get just the latest?
<nekohayo> it's a pretty huge filesize too
<nekohayo> bzr checkout --lightweight I guess
<jam> nekohayo: sure, I'll also put up a tarball if you give me a couple seconds
<nekohayo> jam oh why not :)
<jam> nekohayo: http://bazaar-vcs.org/releases/dev-snapshots/
<jam> There is a bzr.dev-3394-tree-only.tar.bz2 there for you
<nekohayo> thank you
<jam> there is also a full snapshot with history (73MB, though)
<nekohayo> and to think it's bzipped o_O
<jam> nekohayo: well pack files are already gzipped
<jam> bziping that doesn't help much
<jam> unzipped is 96MB, though
<jam> so it helped more than I though
<jam> thought
<jam> You know what, though, that also includes .pyc files
<jam> as I didn't clean the tree first.
<Mez> hmm, file operations seem to be a bit slow with lots of files in the branch
<Mez> oh, no, just my PC running slow
<nekohayo> urgh, I have a big question for you folks, I'm totally confused :) http://ecchi.ca:8000/bzr-question-spiced-ham.htm
<nekohayo> I wrote it condensed into a small html page to avoid spamming the channel
<igc> thanks Odd_Bloke
<poolie> good morning
<igc> morning poolie
<vila> hi guys, can someone have a look at pqm site, it seems... slow ?
<vila> It lloks like it always display the same tests (endind with 'tests passed') even when refreshing
<jam> vila: what tests do you see? I see "LaunchpdaServiceTests"
<jam> And a final "tests passed"
<vila> some here
<vila> same here :)
<jam> I wonder if it is gearing up for running the ascii only versions
<vila> I think I first saw that more than 15 minutes ago (at least), how long does it take to merge one request on average ?
<jam> Well, there is also something funny on the PQM machine.
<jam> Specifically I see:
<jam> ...ServiceTests.test_environment_overrides_default   OK                 118ms
<jam> running here on my (very new) laptop on Windows I see:
<jam> ...lp_service.LaunchpadServiceTests.test_environment_overrides_default   OK                   3ms
<jam> I don't know what is turning a 3ms test into a 118ms one
<jam> but it isn't good
#bzr 2008-05-01
<nekohayo> hmm any ideas?
<jam> nekohayo: something about that machine
<jam> and I don't think I have access to it
<vila> jam: wow, you're damn right, on my Ubuntu box I see:
<jam> lifeless, pool?
<jam> poolie: ?
<vila> ...vice.LaunchpadServiceTests.test_unknown_service   OK                   0ms
<nekohayo> jam, what machine?
<jam> nekohayo: the PQM machine
<jam> things seem to run fine locally, but running very slow on our merge bot
<jam> https://pqm.bazaar-vcs.org/
<nekohayo> no I meant for http://ecchi.ca:8000/bzr-question-spiced-ham.htm :)
<nekohayo> (unless this is related?)
<jam> nekohayo: sorry, completely unrelated, I didn't see your IRC post at all
<poolie> jam, hi
<vila> hi poolie
<nekohayo> (that is a big question that I wrote as a html page to avoid spamming :)
<poolie> nekohayo: can you post it to the list instead, it looks like it will take some thinking about
<jam> nekohayo: what do you mean by "specto used cvs, svn, and bazaar, all with branches that lost history between the switches"
<jam> ?
<nekohayo> jam, I mean that specto, across its lifetime as a project, used 3 different version control systems
<nekohayo> and each time, we did not keep the history
<jam> nekohayo: converting from svn and converting from CVS do not generate conversions that are compatible
<jam> hence why you saw the big set of conflicts.
<nekohayo> jam: uh? but the merge of the bzr-svn branch into the cvs one only created 4 minor conflicts (I think)
<vila> jam, poolie: A new request arrived on pqm, but that's the only change, still at the same test... puzzling
<jam> nekohayo: well, if you can post to the list, I agree with poolie, it is going to take a bit of thinking
<nekohayo> merging the specto-woutc bzr branch into the new cvs+svn branch did the big conflicts though
<nekohayo> ok
<jam> if you can give some details about what is *in* the different branches, it would help.
<jam> we have a phone call right now
<jam> vila: different processes
<vila> jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :)
<lifeless> jam: ?
<keithy> Hi, I was using bzr ftp://
<keithy> and it seams to use directories relative tot he root of the file system
<poolie> i don't have any great ideas about pqm performance
<poolie> i am seeing some tests failing inside pycurl
<poolie> this is odd
<keithy> but how does it manage that , when I login using ftp myself I dont see the root of the file system
<bob2> keithy: can you cd / when you login using a ftp client?
<keithy> ah.. it it appears so
<keithy> duh
<poolie> keithy: i think you can use //host/~/foo
<poolie> if you wish
<poolie> hello bob2
<keithy> ty
<spiv> jam: I have a test for your bug, sending it to the list
<lifeless> the machine is not dedicated solely to bzr
<lifeless> its possible there is some other load
<jam> lifeless: I was wondering if you would have an idea why the PQM machine is taking 100+ ms for a test that runs here in <3ms
<jam> lifeless: further, pqm seems a bit wedged
<jam> It has been showing the same step of Vincent's patch for ~1hr
<jam> spiv: thanks
<poolie> spiv, i feel like we ought to have a coding standard about isinstance vs type etc
<poolie> if only to avoid it being rehashed in every review
<poolie> maybe also to document which one is fastest
<jam> spiv: bb:approve
<spiv> poolie: That sounds good to me.
<lifeless> top - 00:48:14 up 220 days,  4:25,  1 user,  load average: 0.07, 0.06, 0.07
<poolie> jeez firefox is flakey recently
<poolie> lifeless: that's pqm?
<lifeless> yes
<lifeless> its running just the bzr test at the moment, no other things interfering
<TFKyle> hmm, bb over IRC, interesting
<abentley> TFKyle: please no
<poolie> lifeless: so it seems like the test must be wasting time if it's running but the load avg is so low, like it's blocking on io or sleeping a lot
<lifeless> yes
<elmo> the machine's entirely idle; it's not blocking on io
<elmo>  1  0   5392 122888 130552 1489500    0    0     0     0  102    22  0  0 100  0
<elmo>  1  0   5392 122888 130552 1489500    0    0     0     0  103    26  0  0 100  0
<elmo> ^-- vmstat output
<poolie> thanks elmo
<poolie> that's a bit fucked then...
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr 1.4rc2 up for testing, 1.4final today
<lifeless> spiv: ping
<poolie> could either of you maybe strace the process to get some idea of what it is doing?
<lifeless> spiv: I would like you to be the reviewer for http://bundlebuggy.aaronbentley.com/request/%3C1209531548.29242.542.camel%40lifeless-64%3E if you would
<spiv> lifeless: ah-hah.  I was just looking over that code yesterday to get a sense for what was coming :)
<spiv> lifeless: So I'm happy to review that.
<elmo> poolie: strace says it's in a futex and not much more
<keithy> hello, can I break a lock on a repo?
<spiv> Yep, "bzr break-lock PATH"
<keithy> ty
<poolie> elmo: thanks
 * igc food
<poolie> has anyone else seen bug 225020?
<spiv> poolie: I have
<spiv> poolie: I spent a while digging into without making much progress (except that I suspect libcurl is doing dumb things, like confusing actual errors with notifications about the exceptfds you can pass to select)
<spiv> poolie: at the time, no-one else seemed to have heard of it, so I just assumed that my freshly-upgraded hardy system had something strange going on.
<spiv> (I only upgraded to hardy a month ago)
<spiv> poolie: "echo raise ImportError > pycurl.py" in the root of your bzr checkout is a workaround, of sorts.
<poolie> :/
<poolie> also, why didn't the robot link that bug, i wonder?
<spiv> Is the robot in the channel?
<spiv> I see ubuntulog, but not ubotu or whatever it is called.
<poolie> ubugtu?
<bimberi> ubotu is currently gone, I think that work is being done on replacements.
<bimberi> Ref: https://lists.ubuntu.com/archives/ubuntu-irc/2008-April/000443.html
<poolie> spiv, btw last night i started work on deprecating LockableFiles from a different direction and it went quite well
<poolie> it may be i just haven't got to the hard part yet
<spiv> poolie: oh, great!
<poolie> bimberi: thanks for the reference, that's kind of unfortunate though
<bimberi> poolie: np. And yes it is.  I've noticed an 'ubottu' in some other channels.  I guess #ubuntu-ops would be a good place to ask.
<poolie> i don't know many of the people in that thread but it's an unfortunate sounding situation
<poolie> spiv, maybe it only happens with -Werror and it actually reflects an error in the server code?
<abentley> poolie: where do we stand with bzr 1.4?
<poolie> it looks like we want to merge #214894 into it, i'm reading that and will do final today with only that change?
<spiv> poolie: I think I saw the pycurl problem without -Werror.  I used strace and didn't see any sign of a problem on the server side, IIRC.
<spiv> Ah, I think I still have the straces somewhere.
<spiv> The straces also showed no error return from poll(2) either, IIRC.
<abentley> "Should be represented as XXX"?
<spiv> poolie: http://rafb.net/p/dlbvkD76.html
<spiv> abentley: d'oh.
<spiv> poolie: that paste is part of an strace of a test run.  Straight after that it starts re-reading .py files to build the traceback for the exception raised by pycurl.
<poolie> abentley: what are you quoting?
<spiv> poolie: but the server behaved correctly (and as expected), that test server does not allow POST
<abentley> poolie: I'm quoting a comment from spiv's patch for #214894
<spiv> My test had a half-written comment.
<poolie> oh ok
<poolie> abentley: pqm seems unreasonably slow today for unclear reasons
<poolie> not sure if you saw before
<poolie> :/
<abentley> No, I wasn't sure what you guys were stracing.
<poolie> i was going to put this text at the head of the release
<poolie> http://rafb.net/p/JNXf7H59.html
<poolie> spiv, my shelves turned up so after i send off this merge i will head to hornsby if that suits you
<poolie> will probably lunch here first
<spiv> abentley: I've fixed the XXX in the docstring in my branch, and thanks to PQM being so slow the corrected version will be merged.
<spiv> poolie: sounds good
<abentley> spiv: heh!
<spiv> abentley: thanks for catching that :)
<abentley> spiv: no problem.
<abentley> I wish I'd had the option a few days ago when I accidentally merged the wrong branch.
<spiv> Hmm, PQM isn't so much slow as wedged, AFAICS.
<lifeless> poolie: ping
<poolie> pong
<poolie> lifeless: pong
<lifeless> I'm trying to figure out store url escaping
<poolie> k
<lifeless> I seem to be getting double escaping
<poolie> ok
<poolie> sorry to interrupt you but pqm seems to be barely making progress at all
<poolie> it is according to the web still working on the same job it was when i started this morning
<lifeless> its hung on a futex
<poolie> oh, hung as opposed to just spending lots of time in futexes?
<lifeless> pqm@balleny:~$ strace -p 16075
<lifeless> Process 16075 attached - interrupt to quit
<lifeless> futex(0x1a30e90, FUTEX_WAIT, 0, NULL <unfinished ...>
<lifeless> Process 16075 detached
<poolie> maybe we should kill it and let the next job through then?
<lifeless> done
<poolie> thanks
<poolie> so back to your escapism
<lifeless> test_escaped_store
<lifeless> has a test_weave in it
<lifeless> as far as I can tell, it should be double escaping with bzr.dev
<poolie> not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...?
<igc> lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix?
<lifeless> because its not atomic
<poolie> igc, it means "don't do the rename-into-place thing"
<poolie> people reading the file may see it half-written
<poolie> could be good to put that in the developer guide
<igc> poolie, lifeless: ah - ok
<igc> the wt.put_file_bytes_non_atomic docstring refers to the MutableTree one but the latter doesn't exist
<igc> I'll add it
<lifeless> poolie: I'm trying to figure out what is going on
<lifeless> poolie: e.g. store.filename(' ') -> '88/%2520'
<lifeless> poolie: but the test looks for '88/%20' successfully
<lifeless> my replacement mapper code returns the same result from filename
<lifeless> but the test fails (because the file on disk is 88/%2520.weave)
<lifeless> ah I think I have found it
<LaserJock> is there a recommended way to use bzr to track a cvs repo? would cvsps work?
<LaserJock> most of the tools I've seen seem to be made for one shot conversion, where I want to be able to track a CVS repo
<lifeless> launchpad
<lifeless> or cscvs which is what launchpad uses
<LaserJock> well, yeah, launchpad could work if it was up-to-date
<lifeless> it tries hard to handle just about any stupidity people do to cvs
<LaserJock> but it frequently lags
<LaserJock> maybe the best would be to just keep a close eye on the LP import and keep poking
 * igc food
<mwhudson> LaserJock: which import?
<LaserJock> the one I want to track is about 5 months behind or so :/
<LaserJock> mwhudson: https://code.launchpad.net/~vcs-imports/gchemutils/trunk
<LaserJock> it's just difficult to have to keep track of LP
<LaserJock> I end up tacking the CVS anyway just to make sure I'm not missing stuff
<mwhudson> oh and gah, we lost all the code imports log files earlier on today
 * mwhudson gives the import a kick
<LaserJock> although in looking at the 4 imports that I'd use on a daily basis gchemutils is the only one that's not up-to-date
<LaserJock> it's also the only one that is CVS, which may explain it
<mwhudson> LaserJock: it's https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/120977 :(
<mwhudson> so it's not going to start working again until we get some time to fix that
<mwhudson> (or someone else fixes it, cscvs is open source after all, but people who know enough about cvs are probably a bit thin on the ground)
<LaserJock> bummer :/
<mwhudson> yar
<LaserJock> that's the one I especially would love to work with in bzr
<LaserJock> as I can't make head or tails of CVS to save my life
<LaserJock> but the project is very important to me
<LaserJock> so I struggle on ;-)
<LaserJock> right now I'm using git-cvs to track it
<LaserJock> which works pretty well, but I'm trying to convert all my git stuff to bzr
<LaserJock> mwhudson: is it possible to just start the import later?
<mwhudson> LaserJock: if you run cscvs by hand maaaybe
<LaserJock> this is one thing I keep running into with DVCS
<LaserJock> I would verrrry rarely need to go to revision 1
<LaserJock> but often times if something breaks somewhere in history the whole thing is screwed
<LaserJock> it would be nice to just say "gimme the stuff from the last year"
<LaserJock> if that makes any sense :-)
<LaserJock> mwhudson: is there a way for users to see if a vcsimport is out of sync without having to get the original repo?
<LaserJock> mwhudson: I think the value of LP code hosting goes way down if users can't be assured that they're getting the latest revision
<mwhudson> LaserJock: well, the "Last imported: 28 weeks ago" on https://code.edge.launchpad.net/gchemutils/trunk is a pretty large clue
<LaserJock> yeah, for that one sure
<LaserJock> but there's nothing like a failure flag or something?
<mwhudson> this should, and soon-ish will be, on the branch page
<mwhudson> hm, no
<mwhudson> probably should be though
<mwhudson> LaserJock: file a bug about that?
<LaserJock> ok
<LaserJock> I'm just concerned
<LaserJock> because when somebody says "are you building from HEAD?" I need to be able to confidently reply
<LaserJock> not, "well let me go poke around to make sure LP is up-to-date"
<LaserJock> I guess it's good enough for users
<mwhudson> well, i can't really see how you can be sure
<LaserJock> but if you're hacking on irc with fellow developers it's not really gonna work
<mwhudson> i mean, the imports lag by a few hours on average
<LaserJock> well, that's sort of my point
<mwhudson> well, how can launchpad know it's out of date?
<LaserJock> well
<LaserJock> it can't exactly
<mwhudson> there is a sort of plan floating around where launchpad should be able to subscribe to a commits mailing list
<mwhudson> and will update whenever it receives a mail
<LaserJock> but I wonder if you could somehow give a time since last import
<mwhudson> but i don't think it's even written down, never mind scheduled
<mwhudson> https://edge.launchpad.net/drupal/main -> "Last imported: 28 minutes ago"
<LaserJock> bottom line though, LP vcsimports are not really designed for developers methinks
<poolie> lifeless: hi, are transactions meant to be getting removed?
<poolie> ie the control_files.get_transaction and so on?
<lifeless> yah
<lifeless> I didn't break api but I stopped their use in stores in 1.4
<lifeless>  branch may still use them
<poolie> ok
<poolie> as i may have said yesterday
<poolie> i think removing LockableFiles is becoming more important, to enable improvements in Remote
<poolie> so if less stuff uses them, and we can either just delete them or at least have less to update
<poolie> all the better
<spiv> mwhudson: if launchpad had an API for "please mirror now", a 3rd-party could arrange for that to happen for themselves without waiting for the launchpad feature.
<mwhudson> spiv: yes
<mwhudson> spiv: it's on the cards
<LaserJock> mwhudson: bug filed
<awmcclain> Hey all... are there docs somewhere about how to log to .bzr.log? I'm trying to debug bzr-email.
<spiv> awmcclain: "from bzrlib.trace import mutter; mutter('this goes to the log file')"
<spiv> awmcclain: see the bzrlib.trace module in general
<lifeless> poolie: I think having less stuff use them is good
<poolie> lifeless: i want to bounce a testing idea off you
<poolie> that is that we should make use of the lock taken/released events to assert that less than N locks are acquired in the blackbox test for push
<poolie> eventually we want similar assertions on smaller levels
<lifeless> such tests are one of the things I had in mind with the lock hooks
<poolie> but since people sometimes add "oh and also" code to the cmd_ it might be good to cover it at a high level
<poolie> me too
<poolie> great
<poolie> lifeless, was that actually merged yet?
<poolie> abentley: BB is down :?
<lifeless> poolie: dunno
<bimberi> \o/
<bimberi> bug 225020
<ubottu> Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [Undecided,New] https://launchpad.net/bugs/225020
<lifeless> spiv: how did my branch look?
<spiv> lifeless: Haven't looked yet, I've been pairing with poolie
<spiv> lifeless: I expect to do it tonight and first thing tomorrow, though.
<lifeless> cool
<lifeless> poolie: I have the mapping code looking good; was rather confused by the apparent double-escaping
<lifeless> poolie: turns out we return urls not paths from the public interface, even though it talks paths. This will get cleared up by my following work
<lifeless> and with that, its halt() time for me. See you tomorrow.
<lifeless> hi sabdf1, bye sabdfl :)
<sabdf1> night lifeless
<james_w> If I'm creating ghosts as part of an import I just add extra parents when needed correct? I don't need to add ghost records of any sort?
<james_w> Also, just generating a new random revid is fine, as I can just look up the needed revid when I come to create the ghost later?
<spiv> james_w: I think so.
<james_w> spiv: thanks.
<lamby> jelmer: I've just packaged (and pushed) bzr-gtk 0.94.0rc1 but the shiny log is now broken (and I don't know how to fix it) :'(
<jelmer> lamby: Thanks!
<lamby> jelmer: I did manage to patch a few other problems, which almost certainly need to go upstream.
<jelmer> lamby: Shiny log being "bzr viz" ? :-)
<lamby> Indeed. To be clear, it only breaks when you load it via olive-gtk.
<jelmer> ahh, ok. I don't use olive so that must be why I've missed it
<lamby> The other patches are in debian/patches on our alioth repo. Enjoy o/
<jelmer> lamby: Cool, thanks again :-)
<awilkins> jelmer: Confirm that "bzr viz" doesn't work via olive
<awilkins> jelmer: I meant to put a bug up for it...
<awilkins> What is abentley doing to the main BB server? It's always down...
<abentley> awilkins: I'm trying to fix it.
<awilkins> I suppose that's logical ;-)
<abentley> Unfortunately, there appear to be bugs in the visitor tracking part of Turbogears that are threading bugs that I can't reproduce locally.
<jelmer> abentley: btw, do you have any idea what could cause this: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C9a9b41cb0804111344p82ce7d5o6f819346e9eb4349@mail.gmail.com%3E
<abentley> Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch.
<abentley> I ran into that a while back, but I can't remember whether I fixed it.
<abentley> jelmer: are you up-to-date with my changes?
<jelmer> I'm running my own branch, which has the RSS support but may not be up to date
 * jelmer checks for missing revs
<abentley> Looks like I fixed it in revno 242
<abentley> It would be a merge request *without* a patch, actually.
<jelmer> crap, updating actually broke bundlebuggy altogether
<abentley> jelmer: I've changed the way mail is handled in BB, to deal with the fact that BB's been unstable.
<abentley> Now procmail delivers mail to a mail_queue directory, and BB checks for new mail there.
<abentley> jelmer: But it looks as if your problem is you haven't updated the database schema.
<abentley> The migrate script should do that for you.
<jelmer> abentley, thanks
<abentley> jelmer: np
<vila> abentley: do you have access to the pqm machine ? It looks like my last submission make it hang again >-/ (It did this morning lifeless killed it I guess)
<abentley> vila: No, sorry.
<vila> too bad, do you  remember *how* it run the test suite ? And/Or what its config is, I'm totally puzzled about what can cause this...
<jelmer> abentley: Did you improve performance in bb by any chance?
<jelmer> it seems significantly faster to me
<abentley> jelmer: Yes, I have done some optimization.
<abentley> jelmer: Also, you should find that your hacks to place BB's root at a sub-url are no longer necessary.  Please let me know if there's anything I've missed.
<jelmer> abentley: it still redirects to localhost:8089 after voting using the web interface
<abentley> jelmer: that uses the application root.  If you've got that configured correctly it should take you to the correct place.
<abentley> jelmer: try configuring server.webpath
<jelmer> abentley: it's the host name that it doesn't get right, the path in the request is fine
<jelmer> is there an option for that?
<abentley> yes.
<abentley> I use: base_url_filter.on = True
<abentley> base_url_filter.use_x_forwarded_host = True
<abentley> You can also specify the base url yourself.
<abentley> Are you running using dev.cfg or prod.cfg?
<Peng> Wait, when using bzr+ssh, autopacking isn't done by the server?
<abentley> Peng: Correct.
<beuno> Peng, no, autopacking is always done client-side, AFAIK
<Peng> Oh.
<Peng> I thought it was done by the server.
<Peng> Maybe someone said that it was a possibility (which it is), and I misinterpreted it.
<abentley> That's how we'd like it to work, not how it works right now.
<Peng> Yeah.
<Peng> Huh.
 * Peng leaves.
<vila> lifeless: If (and/or when) you look at pqm, can you try to have a look at *where* selftest is hanging, I really have no clue on how to debug this :-/
<vila> The only I can think about that can explain is a test order dependent bug since I changed the overall test suite order when merging in a single list the modules that were defining test_suite()  and those what were using LoadTestsFromModule...
<vila> s/only/ only cause/
<vila> Grr, I hate blind debugging :-(
<Peng> Ack, now push-and-update is getting DeprecationWarnings in bzr.dev.
<Peng> Thanks to install_hook.
<Peng> Think it's worth enabling the "bzr://" smart protocol on a server?
<ja1> Peng: push-and-update should be fixed for install_named_hook
<ja1> as should bzr-email
<jam> well, at least once my commit finishes
<Peng> Yay.
<Peng> Wait, when does push-and-update's hook come into effect?
<jam> Peng: it has to register itself at plugin load time
<jam> so it is calling install_hook all the time
<jam> the hook isn't being called, but it needs to be installed
<Peng> Yeah, but when does it actually do its thing? On every push?
<jam> Peng: on every push it checks if the remote has a working tree, if it does, it then does 'ssh host bzr update path'
<Peng> Huh.
<jam> Peng: so it won't create WTs that aren't there, but if there is one, it tries to keep it up to date
<Peng> I didn't know that.
<jam> I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT"
<Peng> Yes, you did.
<vila> jam: Do you know where I can find how pqm run the test suite ?
<jam> vila: make check
<jam> vila: so "Makefile" has the details
<vila> jam: grrr, thanks a lot ;-)
<jam> it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..."
<vila> lol,     import docutils
<vila> ImportError: No module named docutils
<vila> :-)
<vila> Bad vila
<metameme> I'm new to bzr and my organization is switching to it from svn.  When using a centralized workflow, is it possible to have a post-commit hook like bzr-email be set up entirely on the server side, with zero client configuration?
<jam> metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5
<jam> prior versions didn't quite have enough info
<jam> ATM, bzr-email is not directly able to do it, because the hook is newer
<metameme> jam: Okay, thanks.  It'll be a great feature to have.
<jam> metameme: I believe someone already put together code with the older format, which runs as a cron script
<jam> and just detects new revisions and emails them out
<jelmer> abentley, how do I know whether I'm using dev.cfg or prod.cfg?
<vila> jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view
<jam> vila: I don't think jelmer ever runs test-gtk, and I haven't done any hacking on it for a while
<jam> the bzr-gtk project is *not* TDD
<jam> bbiab
<vila> hmm, bad Jelmer :)
<vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
<abentley> jelmer: If you use the bundled init script or do start-bundlebuggy prod.cfg or run start-bundlebuggy for an installed copy, you are using prod.cfg.
<abentley> If you are getting lots of stuff spewed to the console, you are running dev.cfg.
<jelmer> abentley: Looks like I'm using dev.cfg then :-)
<jelmer> The base_url bits you mentioned seem to work, thanks!
<abentley> No problem.
<jelmer> it would be nice if these two settings were mentioned in the example dev.cfg for new bundlebuggy users..
<jelmer> vila: Well, GUI unit testing is kinda hard
<vila> jelmer: no worries, just joking, what about the other points ^
<jelmer> vila: Which ones?
<vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
<vila>  One test is failing: test_diff_view
<vila> and, about the po files, how are you handling them ?
<jelmer> abentley: Should mail_queue_location point to a mbox or maildir ?
<vila> I tried genpot.sh but it broke and seems old
<jelmer> vila: phanatic is handling all of the i18n stuff
<jelmer> vila: We still need a PQM to make sure we don't get regressions like that
<jelmer> lifeless, ping
<vila> phanaric: ping (arf, not even online :)
<vila> phanatic: ping (arf, not even online, but not a reason to typoed his nick :)
<abentley> jelmer: It should point to a directory, not a maildir in particular.
<abentley> You can point it at the maildir/new, if you like.
<lamby> jelmer: Heh, fastest upstream merge evarr. (Thanks)
<lifeless> jelmer: hi
<lifeless> jelmer: pqm right?
<jelmer> lifeless: you can read minds :-)
<vila> lifeless: read my mind too, you'll find pqm :-/
<lifeless> vila: no idea about your patch sorry
<vila> lifeless: how about an interrupt to at least have a starting point on where it hangs ?
<vila> Note that it is currently hanging for around 5 hours...
<lifeless> the hang I saw it was waiting on a futex
<lifeless> is it hung again?
<vila> yes
<lifeless> killed
<vila> first time I thought it may have been the pqm, but now I'm really... killed ? Ghaa, how can I hope to debug it then :-(
<lifeless> it runs within cron
<lifeless> I can't pdb it when it hangs
<vila> I see :(
<lifeless> I can gdb but that is fiddly and much less useful
<lifeless> it was waiting on futex
<lifeless> that means its probably a server shutdown or some such
<lifeless> this is your test-ids patch?
<vila> the one changing test_suite() to load_tests()
<vila> the only side-effect I see is that some tests are not run in the same order now, other than that....
<lifeless> thats entirely possible to cause such an effect
<lifeless> if we have an isolation bug
<vila> I tried running all tests in isolation (i.e. one by one with --load-list) and so far nothing serious popped out
<lifeless> I don't think you should ignore basic_tests ever
<vila> basic_tests ?
<lifeless> +    # since this module doesn't define tests, we ignore basic_tests
<lifeless>      suite = doctest.DocFileSuite(*scripts)
<lifeless> anyhow, assume that its ordering. You need to run two tests minimum to display an ordering problem
<lifeless> one easy way to show such a thing is to invert the entire test order
<lifeless> vila: also
<vila> hmmm, pqm is running make check, running make check is ok...
<lifeless> basic_tests is a suite
<lifeless> you don't ever have to do
<lifeless> suite = loader.suiteClass()
<lifeless> suite.addTests(basic_tests)
<lifeless> just use basic_tests directly.
<lifeless> bb:tweak  :)
<lifeless> you'll save lots of code
<vila> right, I will do that anyway, but if it fixes the problem, I'll be really surprised
<lifeless> this for loop
<lifeless> +    for test in tests.iter_suite_tests(standard_tests):
<lifeless> +        result.addTests(adapter.adapt(test))
<lifeless> seems to be cropping up multiple times
<vila> :-)
<vila> Yup, I didn't want to stretch the patch, but I noticed it
<lifeless> ok, I've read the patch end to end
<lifeless> those are my comments; I can't see anything to cause a random hang.
<lifeless> there are two causes i can think of:
<lifeless>  - test ordering
<lifeless>  - test parameterisation
<lifeless> if its an ordering bug, one would expect that running the entire test suite in opposite order would *probably* show it
<lifeless> so a simple patch that adds reversed(list(iter_suite_tests(test_suite))) to the end of bzrlib.test_suite()
<lifeless> or just before the runner
<lifeless> might be enough to trigger and show the problem
<vila> I'll try that. Can you elaborate on the parameterisation cause ?
<lifeless> test parameterisation - if the patch actually does change the semantics of one or more parameterised tests its possible that you're just causing a bug, but I didn't spot such a thing when I read the patch.
<vila> Since the branch had a long live, I was paranoid about each merge and always checked that I got the same number of tests (that was one reason to keep that last patch in its own loom thread)
<vila> Granted, number of tests was a simple metric, but
<vila> no but
<lifeless> :)
<lifeless> back in a few minutes, shave & breakfast
<vila> arf, arf, false hope:
<vila> FAIL: test_selftest.TestTestIdList.test_test_suite
<vila>     not equal:
<vila> a = ['bzrlib.tests.blackbox.test_branch.TestBranch.test_branch',
<vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
<vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
<vila>  'bzrlib.timestamp.format_highres_date']
<vila> b = ['bzrlib.timestamp.format_highres_date',
<vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
<vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
<vila>  'bzrlib.tests.blackbox.test_branch.TestBranch.test_branch']
<lifeless> spiv: when you arise, review ping
<mwhudson> spiv: me too!
<mwhudson> :)
<vila> lifeless: selftest reversed just complete, except for the one test whose failure is understandable, nothing.   I'll dig the basic_tests route a bit just to check but if you can provide me with some data on pam, that may helps too (os/python versions, plugins ?).
<lifeless> pam?
<lifeless> if you mean pqm, its running dapper
 * Peng looks at the topic.
<Peng> Today today? Cool.
<bob2> it said that yesterday, too ;)
<Peng> The topic was set 23 hours ago.
<vila> lifeless: s/azerty/qwerty/ :) yes pqm, python2.4 ?
#bzr 2008-05-02
<lifeless> 2.4.2
<ig1> morning
<vila> lifeless: bingo ! I can reproduce it with python-2.4.4
<lifeless> cool
<vila> not accpepting interrupts though :)
<lifeless> spiv: ping
<spiv> lifeless: hi, just about to dive into your review
<lifeless> spiv: thanks
<lifeless> I have an updated deprecations patch
<lifeless> and I missed a couple of trivial uses of vf.join()
<bob2> http://blog.red-bean.com/sussman/?p=90
<lifeless> spiv: if you want to talk about the branch I'm happy to do a clal
<igc> lifeless: thanks for the detailed response to my filtering brain dump
<lifeless> igc: eh, that was just a off the cuff :)
<igc> np - I'm reviewing jam's patch right now and I'll digest your wisdom after that :-)
<lifeless> igc: I haven't had time to give a proper analysis, but its a complex problem to do really well which is why I was so keen for us to layer it with the minimum
<igc> lifeless: Agreed. I'll move the conversation to the mailing list so others can chime in as well.
<poolie> igc, i think it may be ok to not worry right now about how to reapply all your filters to the tree
<poolie> perhaps it does need to be fixed before we really announce it
<igc> poolie: ok. I'll send an email anyway to give people time to think about it how it ought to work
<poolie> mm
<poolie> i should probably not think about it today, have too much more urgent stuff
<igc> poolie: np - I can't implement a solution till next Tues at the earliest anyway
<lifeless> poolie: igc: I think we need *a* method to reset a tree to the current filtered contents
<lifeless> if 'bzr revert' did nothing, it would be most frustrating for people :)
<poolie> i agree
<poolie> lifeless: but things like update that normally do a 3way merge will be more difficult - they don't have the output from the old filter to merge against afaics
<poolie> lifeless: re your patch
<poolie> removing deprecated code
<poolie> is there a current equivalent to MultipleRevisionSources?
<poolie> like if we wanted to fix the problem of missing doing a fetch, is that easy with the current apis?
<lifeless> poolie: 'update' should be fine as long as you reset the tree to match the filters before you update
<lifeless> poolie: because it will always be merging the canonical forms
<lifeless> poolie: MultipleRevisionSources is already unused
<lifeless> and deprecated
<lifeless> graph.ParentsProvider has cleaner functionality
<igc> lifeless, poolie: email sent to the list now on this topic
<igc> I need to focus on reviewing jam's patch right now so I'll digest everyone's input next week
<poolie> lifeless: yes i saw it was deprecated
<lifeless> spiv: updated patch sent; trivial changes
<spiv> lifeless: thanks
<lifeless> spiv: how is it looking ?
<spiv> Pretty good.
<spiv> No fundamental "wtf" issues :)
<spiv> So far, anyway ;)
* poolie changed the topic of #bzr to:  Bazaar version control system |
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ | bzr-1.4 out, May 2
<hersonls> poolie: New bazaar version now?
<hersonls> :D
<spiv> poolie: hooray!
<spiv> poolie: I'm about to head off to your place... should we meet for lunch?
<poolie> spiv, sure, call me when you get to the station
<poolie> hersonls: yes
<poolie> spiv, i may not be able to work on hpss right away but come on anyhow
<hersonls> poolie: Good :D
<spiv> poolie: ok
<lifeless> spiv: review is done ?
<spiv> lifeless: not yet, will continue on the train
<lifeless> ok
<abentley> lifeless: spent any time in Dunedin?
<lifeless> abentley: born and bred
<abentley> I'll be there on Sunday.  Anything I should see and/or do?
<lifeless> the city gardens are beautiful
<lifeless> they have some of the rare and endangered bird species there
<lifeless> mmm winter, won'y suggest sandfly bay
<poolie> abentley: when i was there i went out on the peninsula south of town
<lifeless> the albatross colony might be open though, thats well worth a visit; and if you like beaches head out to the spit
<abentley> Sandfly bay?  That sounds kinda ominous.
<poolie> they have penguin and albatross nests
<poolie> and giant sheep
<lifeless> poolie: thats NE of town :)
<poolie> maybe it moved :P
<abentley> Cool.  Thanks for the suggestions.
<lifeless> there are a number of nice lookouts, the one back of the quarry has a particularly good view of the city
<lifeless> heading up mt cargill can be nice too
<lifeless> its a uni town, I'm totally positive you'll be able to find an open mic as wlel
<abentley> Hehe.
<lifeless> really, I think its something like 10% population is floating students
<lifeless> the whole place ebbs and flows to the university holiday schedule
<mwhudson> it's like the last week of term i think
<mwhudson> (at least it is at massey)
<abentley> Hmm.  Yeah, I guess the only real university town I've been to is New Haven, Connecticut.  Toronto and Montreal have universities, but they're also big cities.
<lifeless> oh,if the mei wah fish and chip shop is open, or the golden sun beside it, try some. One if unforgettably terrible, and one unforgettably good (or was 12 years ago).
<lifeless> I won't tell you which is which :)
<abentley> poolie: congrats on the 1.4ness
<poolie> thanks, sorry for the delay
<poolie> now for pqm toil
<poolie> fortunately it is getting more automated each time - i just sent a patch deleting more steps from teh RM guide
<abentley> lifeless: I'm a bit surprised common_ancestor is deprecated.  I believe I'm still using it in graph-ancestry.
<lifeless> abentley: deprecated in 1.4
<abentley> Ah, I'm actually using node_distances and select_farthest.
<lifeless> :)
<poolie> abentley: have a good trip btw
<abentley> poolie: Thanks.
<poolie> abentley: if by any chance you're still here: what was the case with lp push or pull that was slow for you?
<lifeless> poolie: bzr branch <the code of launchpad itself>
<lifeless> poolie: over hpss
<lifeless> poolie: I think his mail didn't discriminate enough between using lp, and being lp :)
<lifeless> spiv and I are aware of this and have both done some analysis
<poolie> into an empty repo?
<lifeless> poolie: no repo
<lifeless> poolie: call ?
<poolie> ok
<abentley> poolie: It was branch
<abentley> poolie: I'm in the middle of repeating it for you.
<abentley> But the whole process takes > 1 hour
 * igc lunch and pick up kids -bbl
<abentley> lifeless: I'm a bit lost on how to change ReconcilePacker to update sha1s.
<lifeless> abentley: indeed
<lifeless> abentley: it needs to override the revision bulk copy and have it occur after the inventory copy; during the inventory copy you'll need to determine what the correct sha1s are
<lifeless> a subclass for the case where this is needed may be appropriate
<abentley> In order to update the sha1s, I need to know the correct serializer, so I need the repository.  Which seems like a layering violation.
<lifeless> well the repository chooses the reconciler etc
<lifeless> so it can pass in the serializer (though isn't the sha1 on disk always the correct one now ?)
<lifeless> oh! it needs the revision serialiser
<lifeless> I definitely think a subclass is appropriate here
<abentley> Though perhaps if I need the repo anyway, I should be using repo methods.
<abentley> lifeless: Is there any easy way of reading/writing fulltexts from a PackCollection?
<lifeless> yes
<lifeless> one sec
<lifeless> you instantiate a KnitVersionedFile on the pack and a GraphIndex (for revisions|signatures|inventories|knits)
<abentley> I can do that on a single pack, not the PackCollection?
<lifeless> to read the old revisions I would do use the existing repositories iter_revisions or whatever
<lifeless> you can, but there is no guarantee that you can read a given uncompressed text from a single pack
<lifeless> basis texts may well be in different packs
<lifeless> For reading revisions I would use the repositories methods
<lifeless> for writing them serialising and adding is probably cleanest (see the output_knit variable around line 1062)
<abentley> Not important for this case, since revisions are not (supposed to be) delta'd.
<lifeless> the existing reconcile code does 'repo.weave_store.get_weave(file_id, transaction) to read texts
<lifeless> that is by far the simplest way
<abentley> Okay, thanks.
<spiv> lifeless: review heading your way
<lifeless> thanks
<spiv> Hmm, or at least it will be once I sort out my mail delivery...
<lifeless> :P
<jrydberg> morning you hackers.
<lifeless> where, where?
<jrydberg> there, there.
<jrydberg> sup robert?
<lifeless> spiv: short story, is it tweak? bounce? approve?
<spiv> lifeless: tweak
<rockstar_> Morning?  It's 2300 here!  :)
<lifeless> jrydberg: VersionedFiles is taking shape
<lifeless> rockstar_: wait 46 minutes
<poolie> starting ppa rebuild of 1.4
<spiv> lifeless: but if you want to bounce up and down, I won't stop you ;)
<jrydberg> lifeless: Finally.
<lifeless> jrydberg: well, there was a bunch of prep work to do :)
<lifeless> jrydberg: how are you, haven't chatted in -ages-
<jrydberg> lifeless: hehe.
<jrydberg> lifeless: i'm fine, i'm fine.  just trying to use computers are little as possible in my spare time.  noticed that it helps my motivation at work.
<poolie> jrydberg: heh, me too :)
<poolie> or at least i am trying to be careful of that effect
<jrydberg> i've turned to photography instead.
<jrydberg> equally geeky, less computers.
<lifeless> well thats 8 hours poolie
<lifeless> poolie: so I'm calling it till Monday
<lifeless> jrydberg: this is my solution, to be self strict about work | hobby time
<spiv> lifeless: you should have that mail now
<spiv> abentley: thanks for that log
<abentley> spiv: No problem.
<lifeless> well, I'll reply first :)
<lifeless> then call the day
<poolie> lifeless: can you read this one mail i'm going to send first? :)
<poolie> about PPAs
<lifeless> I think beta is overkill
<lifeless> just use snapshot for betas
<lifeless> IMO
 * lifeless waves
<igc> night all - have a good weekend
<igc> back Tuesday for me
<vila> ok, I narrowed down my pqm hanging scenario, reproduced on gutsy with:
<vila> python2.4 bzr selftest bzrlib.tests.test_strace.TestStrace.test_strace_callable_is_called bzrlib.tests.test_strace.TestStrace.test_strace_callable_result bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_connect_to_bzr_ssh
<vila> any advice greatly appreciated while the diagnosis continues ;-)
 * fullermd has none whatosoever.
<vila> fullermd: thanks for the warm moral support :-P
 * fullermd is helpful like that   :]
<fullermd> strace does sound like a good candidate for twisting up a machine, though.
<vila> the puzzling bit is that I submitted a  patch that first glance has strictly nothing to do with strace :) Neither at second glance FWIW
<vila> and to make it funnier I can reproduce it on a single machine only while, still at first glance, the two are gutsy installs :)
<fullermd> With strace installed?
<fullermd> I know the tests skip without it (I don't have it installed)
<vila> fullermd: excellent idea ! But both have the same version installed
<vila> both says 'tests passed' (i.e. really late, nearly before exiting) but one hang after that
<fullermd> Well, maybe strace isn't standard-installed, but one has it chosen as additional.
<fullermd> I could believe that strace enables something that runs at cleanup time, so that could cause a late hang.
<fullermd> (of course, I'm in pure speculation mode here, so I could well be making it up as I go along too  :)
<vila> I don't remember if I installed them myself, but that was through synaptic anyway, so both installs should be correct, but looking at the code I suspect something related to 'import subprocess' since these tests use that, there may be some weird interaction
<vila> I think my patch just revealed a latent bug
<vila> test_bzr_connect_to_bzr_ssh has several 'XXX' anyway
<vila> spiv: are you still around by chance ?
<fullermd> Great, you broke him.
<vila> fullermd: damn :)
<fullermd> That's talent.  You exposed a latent bug in bzr _and_ spiv at the same time  ;)
<vila> fullermd: lol, I will meditate about that during lunch :)
<jsled> I've a shared repo, with a branch 'trunk'.  I've done `bzr branch trunk local`.  Now, I'd like to rename 'local' to something else.  Is it just "mv local something-else", or does bzr need to get involved, and if so, by what command?
<james_w> jsled: "mv local something-else" is fine
<james_w> jsled: bzr would need to get involved for something like "mv local /somewhere/else/entirely"
<james_w> as long as you stay within the shared repo you should be ok.
<jsled> thanks. :)
<james_w> (assuming you don't move something inside another branch, or a repo in repo or similar)
<visit0r> hi, is there someone using the bzr-hookless-email? for some reason it seems to hang and leak memory like crazy.
<visit0r>  File "/usr/lib/python2.5/site-packages/bzrlib/repository.py", line 1520, in deserialise_inventory
<visit0r> probably that's the hanging function
<jelmer> dato: ping
<jelmer> dato: your upload of bzr 1.3.1-1 doesn't appear to be in the bzr branch on alioth
<chadmiller> Hi all.  Has anyone tried reviewboard with Bazaar?  It seems to have gotten some of Bazaar support lately.
 * chadmiller doesn't know how deep it goes.
<jelmer> chadmiller: I think statik was the person who did most of the work on that
<jelmer> statik, ^
<chadmiller> From the log, "Patch from Henrik Hedberg to add basic support for the Bazaar SCM."
<chadmiller> That ain't statik.
<jelmer> hmm, must be another branch than https://code.launchpad.net/~statik/reviewboard/bazaarsupport then that got merged..
<chadmiller> A related question:  That patch has some questionable choices in it.  Instead of importing bzrlib, it runs "bzr" with arguments and catches stdout.  Is that as silly as I think it is?  Do you consider the internal bzr APIs stable?
<chadmiller> Or, rather, /is there/ a public API for bzr?
<jelmer> ah, ouch
<jelmer> there is a public API for bzr in Python (in which reviewboard is also written)
<jelmer> that does indeed seem like a very questionable choice
 * lamont struggles to remember how to import a cvs tree into bzr
<lamont> and finds it
<surfous> I've got a local branch that is a checkout of a branch hosted in Launchpad... I've just done a bzr upgrade to upgrade the format. What's the proper way to get my remote master branch upgraded as well? It still appears to be of format BzrBranch5
<beuno> surfous, bzr upgrade sftp://user@bazaar.lauchpad...
<beuno> upgrading it through sftp on LP
<beuno> but, be warned, it takes a while
<surfous> beuno: Thanks for the info - I fear it's sending me on a tail-chase, though...
<surfous> What prompted me to do this was trying to tag my branch. I got the following error:
<surfous> bzr: ERROR: Tags not supported by BzrBranch5('bzr+ssh://surf@bazaar.launchpad.net/%7Epyax/pyax/release/'); you may be able to use bzr upgrade --dirstate-tags.
<surfous> I did a bzr upgrade which brought my format up to pack-0.92
<surfous> local format, that is
<surfous> trying to upgrade the remote branch tells me: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<surfous> So one operation tells me I'm out of date, and the other tells me I'm up to date, when ultimately, I'm just confused.
<jelmer> surfous, try upgrading over sftp rather than bzr+ssh
<beuno> surfous, what does "bzr info -v" on the remote branch tell you?
<surfous> jelmer: Cool, that seems to be doing more than what I had before... I'll see where that lands me.
<surfous> beuno: surf@fischer:~/src/pyax/release$ bzr info -v bzr+ssh://surf@bazaar.launchpad.net/%7Epyax/pyax/trunk
<surfous> Standalone branch (format: unnamed)
<surfous> Location:
<surfous>   branch root: bzr+ssh://surf@bazaar.launchpad.net/%7Epyax/pyax/trunk/
<surfous> Format:
<surfous>        control: bzr remote bzrdir
<surfous>         branch: Remote BZR Branch
<surfous>     repository: bzr remote repository
<surfous> Branch history:
<surfous>         51 revisions
<surfous>          4 committers
<surfous>        371 days old
<surfous>    first revision: Thu 2007-04-26 10:50:37 -0700
<surfous>   latest revision: Thu 2008-05-01 14:17:23 -0700
<surfous> Repository:
<surfous>         63 revisions
<surfous>        324 KiB
<surfous> beuno: I know I referenced my release branch before, any this is on my trunk, but the problem was the same on each
<beuno> surfous, right, for some reason, that's very uninformative, but upgrading through sftp is the way to go
<surfous> beuno: And it does indeed take a while as you'd warned, but I've no problem waiting.
<surfous> Thanks a lot for your help, beuno and jelmer!
<beuno> surfous, :)
<jelmer> abentley, hi
<lamont> given a bzr 1.3.1 tree, bzr log says that the current revision is '47'.  is there any trivial way to get that out of bzr short of  resorting to perl/awk/sed/grep foolery?
<beuno> lamont, bzr revno?
<lamont> I knew there had to be something.  thanks
<beuno> :)
<lamont> "version" and "revision" didn't give me what I wanted, so I decided that asking would be quicker.  thanks again
<beuno> nothing better then taking advantage of random knowledge on IRC!
<beuno> *ignore me* #214825
<matkor_> Hi !. Is is possible to ignore all ".svn" dirs regardless how deep they are ?
<james_w> does "bzr ignore .svn" not work?
<matkor_> let me see ...
<matkor_> james_w: Works, thank you very much
<james_w> no problem
<trepca> i have two branches ... trunk and branch1, people commit to trunk and also tag commits
<trepca> how could i diff these two and only limit on tagged commits
<james_w> I'm not sure that's possible
<trepca> ok, thanks :)
<james_w> you want to diff two branches but only show the changes that were introduced in one by certain commits?
<trepca> trying to implement a code review
<trepca> when people close a bug, they commit with a tag containing the bug id
<trepca> laterz
<trepca> night
#bzr 2008-05-03
<dato> jelmer: oops, you're right. I guess I forgot to commit, and I can't find the branch now
<dato> jelmer: so, I guess I'll create a commit and merge it tomorrow. I don't think you should've pushed, though, but never mind.
<jelmer> dato: Well, it should be trivial to merge your commit into the current branch. I haven't uploaded anything yet
<jelmer> dato: Mind if I just import-dsc the 1.4.1 release?
<dato> so, a couple things
<dato> are you interested in dm-upload-allowed: yes maintain it?
<jelmer> dato: I'm interested in contributing to the maintainance of the bzr package
<jelmer> i.e. doing uploads now and then if I have the time and nobody else is doing it
<jelmer> not sure if that's what you're asking :-)
<dato> ok
<dato> so due to my fuck-up, I really think I should push --overwrite you... I would really dislike the idea of having a 1.4 in the branch that does not include the 1.3.1 changelog, what do you think?
<jelmer> dato: oh, yes - I agree
<dato> so it seems I've lost the commit, if it ever existed
<dato> so I'll create a 1.3.1 commit, and push --overwrite
<jelmer> k
<dato> jelmer: done, going to bed.
<jelmer> dato: thanks, goodnight
<dato> jelmer: so, I'll upload bzr 1.4; I'll add the dm-upload bit
<emgent> morning
<matkor> Hmm, recent repo olive-gtk:
<matkor>     from bzrlib.plugins.gtk import icon_path
<matkor> ImportError: cannot import name icon_path
<matkor> ?
<jelmer> dato: COol, thanks
<dato> jelmer: I'm in a conference, just need to find a spot to do it :)
<fullermd> jelmer: Are you working up to a bzr-gtk release?
<jelmer> dato: k :-)
<jelmer> fullermd, yep
<fullermd> jelmer: May want to look at https://bugs.launchpad.net/bzr-gtk/+bug/224914 for it.  Kinda sucks   :|
<ubottu> Launchpad bug 224914 in bzr-gtk "viz fails to show children properly" [Undecided,New]
<fullermd> Oh, hithere.
 * fullermd pets ubottu.
<fullermd> (it's a little more complicated than the desc; it seems to have weird interactions with the sort of children, whether direct or merge revs...   but anyway)
<jelmer> oh crap
<jelmer> we also have to other issues to fix before the release
<jelmer> so I guess we should delay it another week
<fullermd> Just doing my part to keep you from being bored   ;)
<jelmer> see, this is why I prefer working on vaporware. it doesn't have users and so it's a lot easier to pretend there are no bugs
<jelmer> :-P
<fullermd> Oooh, I didn't know you were working on bzr-sccs...
<bob2> haha
<hersonls> poolie: you be here?
<bob2> 2313 aest
<rexbron> Hello, will branches that have been created with a plugin, ie bzr-svn, use the same methods as regular bzr branches?
<rexbron> I am trying to integrate that functionality into a script one the branch has already been created
<rexbron> once rather
<jelmer> rexbron: yes
<rexbron> jelmer: ok, and will the .push() method just work for pushing to a remote bzr branch, right?
<hersonls> now the bazaar slackbuild has updated :D
<jelmer> rexbron: yep
<Kamping_Kaiser> hi all. i diffed two files, and one was (apparently) created 1970-01-01.  is this because it never existed?
<LeoNerd> diff uses that to say it's a new file
<Kamping_Kaiser> cool. thanks for confirming that
 * Peng gasps.
<Peng> bzr-svn uses old-style classes?
<jelmer> oldstyle being "class foo:" rather than "class foo(object):" ?
<Peng> Yeah.
<jelmer> I've fixed a bunch of them a couple of weeks ago
<jelmer> If you can still find any old-style classes in the 0.4 branch, please let me know :-)
<Peng> Connection and ConnectionPool in transport.py.
<jelmer> thanks. It's a bad habit..
<jelmer> (these were two classes I had added recently)
<Peng> ConnectionPool.connections could also be a dict/defaultdict. Probably not worth the effort though.
<Peng> Woah, pylint really doesn't like bzr-svn.
<jelmer> patches welcome :-)
<Peng> It's 3500 lines long!
<Peng> Heh, pylint triggers a DeprecationWarning of its own.
<Peng> jelmer: "Your code has been rated at 4.20/10" :D
<jelmer> :-/
<Peng> I've never used it before and didn't configure it.
<Peng> It's very whiny. Did you know one of your classes has "too many" instance attributes?
<jelmer> Peng: yeah - have you tried running it on bzr itself?
<Peng> Haha, no way.
<jelmer> It complains about any class that has more than 20 methods I think
<Peng> It's slow too.
<Peng> Something like that, yeah.
<Peng> It complains about lots of things like that. Too many args, etc.
<MattCampbell> Suppose I want to make a bzr branch from a given release of an open-source project that uses svn, e.g. Trac.  If I do "bzr branch http://svn.edgewall.org/repos/trac/tags/trac-0.10.4/", then make modifications to that branch, will someone then be able to merge those changes with a bzr branch made from svn trunk?
<MattCampbell> I wonder because I know that svn doesn't have the explicit concepts of branches and tags as bzr does; it uses cheap copies for both.
<Peng> You could try it, of course. :P bzr-svn should be smart enough to make the branches related, though.
<Peng> jelmer: When are you planning to release the next version of bzr-svn?
<MattCampbell> My main fear with version control systems is always that I'll do something wrong at the beginning of a project, with regard to tree organization and the like, and never be able to cleanly recover from the mistake.  That's why I asked that question.
<dato> jelmer: uploaded
<jelmer> dato: thanks!
<jelmer> Peng, tomorrow hopefully
<Peng> jelmer: Ok, cool.
<libwilliam> I am working on a Bazaar Plugin for Anjuta and I am wondering if there is C bindings for Bazaar. I haven't seen anything online but thought if anyone knew if someone was working on it you all would know.
<MattCampbell> A better idea would probably be to embed Python in Anjuta, write Python bindings for Anjuta's API's, and do the bzr integration from Python code running inside Anjuta.
<thatch> libwilliam: you can load libpython and call the apis directly
<MattCampbell> I suppose this will be a perceived disadvantage of bzr compared to svn for a while; since svn is a bunch of C libraries, it's probably more attractive to third-party IDE/tool developers who aren't using Python already.
<libwilliam> Alright I will look into that. I have never done something like that so unsure how easy it is, but gives me a good reason to learn.
<libwilliam> thatch: is this similar to what you were talking about? http://www.linuxjournal.com/article/8497
<thatch> libwilliam: yeah, that's what MattCaand I were suggesting
<libwilliam> alright thanks, I will mess around with it
<awmcclain> Anyone have any success compiling pycurl for leopard?
#bzr 2008-05-04
<fbond> lifeless: http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt
<fbond> lifeless: This is a pretty crude explanation of how I use loom.
<fbond> lifeless: It needs more detail added, but it is a start.
<fbond> I'll see if I can flesh things out a bit more.
<cybX> hello all
<cybX> anyone alive? good grief...I haven't irc'd in a year
<cybX> i feel like a newbie all over again
<cybX> yay
<cybX> alrighty then
<rexbron> hmm...
<rexbron> bzr: ERROR: Repository KnitPackRepository('file:///home/rexbron/packages/quassel/.bzr/repository/') is not compatible with repository SvnRepository('http://svn.quassel-irc.org')
<rexbron> is it not possible to use bzr-svn inside a repo?
<fullermd> Yes, but only if the repo uses a rich root capable format like bzr-svn requires.
<AfC> rexbron: yes it is, but you need to make the repository be of format "rich-root-pack"
<AfC> rexbron: (at least, that's what I had to use a month back)
<rexbron> ok
<fullermd> (which means you probably don't want to mix it with repos containing other stuff)
<AfC> fullermd: did they get that rich-root stuff into the default as of 1.4, or are they still faffing about?
<rexbron> thanks
<fullermd> It's not in 1.4 certainly.
<fullermd> abentley was fiddling.  At one point the next format would be default and rich root.  Last I heard, he was waffling toward switching defaulting rich-root-pack.
<AfC> rexbron: ... regarding what fullermd just said, if you follow a convention of having a directory (containing a repository) being the parent directory of a bunch of branches all related to the same project, then things work out rather well.
<AfC> rexbron: [I have
<AfC> ~/src/andrew/project1/branchN
<AfC> ~/src/andrew/project2/branchN
<AfC> ...
<AfC> and
<AfC> ~/src/otehr/project3/branchN
<AfC> other*
<AfC> where project3 has a different repo format
<AfC> but the real matter is that each of projectN has its own repo
<rexbron> AfC: that is how I approach it aswell
<AfC> rexbron: you'll be all set then
<AfC> just create a new project directory with
<AfC> $ bzr init-repo --rich-root-pack project3
<AfC> [or whatever the current recommended format is, {sigh}]
<mathrick> https://launchpad.net/~bzr/+archive <-- bzr debs are mislabelled
<mathrick> they all say ~hardy1, when the series listed is different
<mathrick> in fact, the whole thing confuses me
<mathrick> half of the builds have no corresponding .debs linked
<bimberi> mathrick: Launchpad build records remain even after a package is deleted.
<bimberi> *Launchpad *ppa*
<mathrick> ah
<bimberi> wrt the mislabelling, I'm guessing that the new LP feature allowing package copying was used.
<bimberi> ref: https://lists.ubuntu.com/archives/launchpad-users/2008-May/003665.html
<nick125> Hello
<nick125> I'm having a *small* issue with bzr ignore...for some reason, it isn't ignoring my pattern. In my .bzrignore file, I have *~ and *.pyc, but it's still adding those files. Am I doing something wrong?
<jelmer> nick125: Are you specifying the files explicitly perhaps?
<nick125> jelmer: Hmm...that's possible. I did a bzr add *..would that add ignored files?
<jelmer> nick125, yep it would
<jelmer> nick125, try "bzr add" if you want it to obey the ignores file
<nick125> neat..thanks!
<lifeless> fbond: thanks
#bzr 2009-04-27
<igc> morning all
<mwhudson> hello igc
<mwhudson> igc: did you see that bug i filed on bzr-historycache?
<igc> mwhudson: not yet, just logged on
<mwhudson> igc: ok :)
 * mwhudson holds off on the nagging
<spiv> igc: welcome back.
<spiv> igc: there's mail on the list from Greg Ward about bzr-fastimport you should look at, if you haven't already.
<igc> hi spiv
<igc> spiv: thanks for the tip - yet to get to email today but will soon
<mwhudson> wow, i have bzr revert exploding
<mwhudson> http://pastebin.ubuntu.com/158897/
<mwhudson> bah
<mwhudson> dulwich is requiring python 2.5 again :(
<mwhudson> and tests fail
<lifeless> spiv: If my patch from friday is unreviewed, I've nearly corrected the [small] fallout from it, would love a review.
<lifeless> spiv: '[MERGE] Reduce round trips pushing new branches substantially' is the subject
<spiv> lifeless: sure.  I'd love a review of the updated sink-side checking for missing parent inventories patch, btw.
<lifeless> yup
<lifeless> have some administrivia I've been deferring too long to finish
<spiv> Fair enough.
<lifeless> spiv: is bzrlib.tests.blackbox.test_push.TestPush.test_push_error_on_vfs_http failing for you ?
<spiv> lifeless: passing for me
<spiv> lifeless: (py2.6, jaunty)
<lifeless> _bah_
<lifeless> ah
<lifeless> its my removal of 'no host'
<lifeless> oh no its not
<lifeless> its because its not trying mkdir :)
<lifeless> its probing for a smart server
<lifeless> spiv: why do we have should_probe, rather than the medium probing for us ?
<awilkins> Is dulwich what comes after brisbane?
<lifeless> no
<lifeless> its a python implementation of git
<lifeless> used for bzr-git amongst aother things
<awilkins> Ah, yes
<spiv> lifeless: it was added because really only the HTTP medium needs to be probed, others know immediately if the transport can support smart requests or not.
<spiv> lifeless: that work could probably be pushed down into the medium rather than via should_probe, if that's what you're asking.
<spiv> There's probably a bit of extra awkwardness with the "probe" doubling as a weak version probe, I don't recall off the top of my head if that matters to anything.
<lifeless> spiv: indeed, I've added a block of code
<lifeless> are you subscribed to commits?
<lifeless> if so, one commit back has my 'fix tests' commit - could you review that too
<lifeless> then it can land
<spiv> I am, I'll take a look.
<spiv> lifeless: sent a reply to your review reply, looking at fix tests commit now.
<spiv> Then it's *really* lunch time :)
<lifeless> thanks!
<spiv> lifeless: that commit looks fine.
<lifeless> cool; in which case I'll land [using your tweak from before :P] - I've replied to your reply fwiw
<meoblast001> hi.. i just branched a project with bzr and i have no bazaar configuration directory
<lifeless> meoblast001: that sounds fine
<lifeless> meoblast001: but perhaps you mean something other than what you typed
<meoblast001> lifeless, but i need a bazaar configuration directory
<meoblast001> so i can set my whoami
<lifeless> 'bzr whoami --help'
<meoblast001> lifeless, is this the correct format Braden Walters <meoblast@aol.com>
<Peng_> meoblast001: Yes.
<meoblast001> ok thanks
<mwhudson> hmm\
<mwhudson> i just this the ssh user name thing
<lifeless> mwhudson: EPARSE
 * mwhudson tries again
<mwhudson> i just hit the ssh user name thing
<lifeless> mwhudson: please upgrade it to a bug then :)
 * spiv wonders why he hasn't
 * spiv has lunch
<lifeless> mwhudson: do you have an authentication.conf file?
<mwhudson> lifeless: yes, for launchpad stuff
<lifeless> ok, that rules out that theory :)
 * fullermd also has LP stuff in auth.conf.
<lifeless> I don't have one, was wondering if that was related
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/367726
<ubottu> Ubuntu bug 367726 in bzr "ssh usernames specified in .ssh/config are not honoured for bzr+ssh connections" [Undecided,New]
<lifeless> bah, pqm failure I can't reproduce
<lifeless> chilly day today
<AfC> I believe "bloody freezing" would be more apt.
<lifeless> yah
<mwhudson> AfC: i didn't think mainland australians were allowed to use phrases like that
<lifeless> mwhudson: canadians should know
<mwhudson> yes
<AfC> I am but an ex-pat, cast adrift upon a sea of strangeness and schooners.
<vila> hi all !
<Peng_> vila: Hello. :)
<lifeless> spiv: and its landed
<Peng_> Yay, "bzr pull" downloaded a reasonable amount of data instead of 5 MB.
<mwhudson> Peng_: working on launchpad, 5 megs is fairly reasonable! :)
<spiv> lifeless: yay
<lifeless> spiv: found another aliasing bug though, which I just fixed in transit
<spiv> I saw that commit; it looked reasonable.
<lifeless> yeah, I figured it was clearly correct :)
<AfC> Does someone have a branch of bzr-gtk handy (ie published somewhere) handy? The branch on Launchpad is stalling out.
<spiv> AfC: weird, I just branched lp:bzr-gtk with no trouble (47s, 3.7M repo)
<spiv> AfC: I can push it up somewhere for you but it sounds like something funny is going on...
<AfC> spiv: fair enough. I'll try again.
 * AfC hopes it realizes it already downloaded half of it
<AfC> [I am hoping to elucidate why `bzr viz` is claiming that pygtk is not installed]
<AfC> [I don't think it's bzr-gtk's fault, but a glitch in the (otherwise excellent) Python packaging on this distro. I recall a similar problem when I did Python 2.4 to 2.5]
<mwhudson> Jc2k: did you know dulwich trunk tests fail and it depends on python2.4 again?
<lifeless> mwhudson: do you mean 2.5?
<mwhudson> lifeless: i do
<mwhudson> clearly today has not been a good day for me to try to make sense
 * lifeless finishes off txaws.ec2
<garyvdm> Hi - I did:
<garyvdm> bzr mv lib/diff.py lib/diffwindow.py
<garyvdm> bzr mv lib/extdiff.py diff.py
<garyvdm> bzr commit
<flacoste> i get the following error when i bzr branch from lp:
<Peng_> diff.py or lib/diff.py?
<garyvdm> Ah
<garyvdm> Thanks
<garyvdm> Many eyes...
<flacoste> [francis@Huxley launchpad]$ bzr branch lp:~danilo/launchpad/ajax-textboxbzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
 * igc dinner
<Peng_> flacoste: Ah, lucky you. Known bug. It's been (or being) fixed. The simplest workaround is to not use the smart server, e.g. "bzr branch nosmart+bzr+ssh://bazaar.launchpad.net/~danilo/launchpad/ajax-textboxbzr".
<flacoste> ok, thanks!
<Peng_> (or sftp://)
<Peng_> flacoste: FWIW, the problem is that newer clients use new smart server methods that require more data to be on the server, and older clients didn't push that data when using stacked branches.
<flacoste> Peng_, thanks it worked fine :-)
<Peng_> Great. :)
<jdobrien> I keep getting the following error:
<jdobrien>  [unknown]
<jdobrien>   netrc_credential_store /usr/lib/python2.6/dist-packages/bzrlib/plugins/netrc_credential_store [unknown]
<james_w> that's an error?
<james_w> what are you doing to get that?
<james_w> is that just part of the output?
<lifeless> what does bzr plugins show jdobrien
<jdobrien> lifeless: actually I'm experiencing that bug #354036
<ubottu> Launchpad bug 354036 in bzr/1.13 "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036
<jdobrien> lifeless: the one our whole team is experiencing
<lifeless> jdobrien: have you applied the fix, run the fix script?
<lifeless> spiv has had the server fix approvd today, and I'm sure mwhudson will be keen to get it uploaded
 * jdobrien looks for the fix script
<jdobrien> lifeless: foo?
<lifeless> yes
<lifeless> and with the server side fix done we can start investigating other causes
<lifeless> its kindof a generic error
<jdobrien> as is the patch name :-)
<jdobrien> lifeless: bzrlib.errors.TransportNotPossible: Transport operation not possible: readonly transport
<lifeless> use a bzr+ssh url, not an lp url
<jdobrien> lifeless: i did: python foo.py  bzr+ssh://bazaar.launchpad.net/~gafton/ubunet/updown-fixtests
<jdobrien> i think many on our team just downgraded bzr...it keeps us moving but doen't help resolve the issue
<jdobrien> lifeless: oh wait... that's not my branch
<jdobrien> lifeless: i suspect it needs to be fixed by its owner
<lifeless> jdobrien: thats right
<lifeless> downgraded bzr will cause the problem for other people
<jdobrien> yeah...like me! I can't review anyone's branch now
<jdobrien> lifeless: hmm...that sounds like their problem ;)
<lifeless> you can use sftp:// urls as a workaround
<spiv> Or even prefix nosmart+ to the bzr+ssh:// URL... the bug description should have a comprehensive list of workarounds now.
<lllama1> Hello all. Simple question (can't quite find the right google words): how can I include (and have updated) the revid in my source files?
<rocky> has jelmer been around lately?
<lifeless> lllama1: see bzr --help version-info, and also the new (beta quality in 1.14) tree filters
<lllama1> lifeless: star. Many thanks.
<rocky> is there anyway to disable a plugin that has been installed just for one bzr request?
<knielsen> Hi, I made a tag with `bzr tag -rrevid:XXX` in a local branch. The tag works fine, but is there any way I can see it like other pending changes? It's nowhere to be seen in `bzr status`, `bzr diff`, or `bzr missing`
<beuno> knielsen, bzr tags
<beuno> it's not pending, because it's already applied to the branch
<knielsen> I assume it will be transfered as part of a `bzr push`, but it would be nice to see what tags are pending before pushing? But maybe that's not possible
<beuno> knielsen, sure, bzr tags-missing or something like that would be nice
<beuno> file a bug  :)
<knielsen> beuno: ok, thanks. So a tag is not part of a commit, I guess, bzr tag applies the tag immediately without waiting for a commit
<lifeless> knielsen: a tag of an existing rev is immediate, yes.
<knielsen> makes sense I guess, thanks for the help
<vila> BasicOSX: It looks like NEWS in bzr.dev is quite wrong. At least it mentions bug #256612 being fixed in 1.14rc2 where in fact the fix exists only in bzr.dev (AFAICS)
<ubottu> Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,Fix released] https://launchpad.net/bugs/256612
<LarstiQ> gah that wiki spam is irritating
<jam> LarstiQ: yeah, I got newz to disable their accounts
<jam> did you also realize they are attaching files with bad html
<jam> nasty stuff that uses javascript to rewrite the body
<jam> and encode the actual content in decimal
<LarstiQ> jam: haven't spotted that in the notifications
<jam> LarstiQ: Attachments don't generate emails
<jam> which is also a bad thing
<LarstiQ> ick
<jam> http://bazaar-vcs.org/Talks/NedovHobahit?action=AttachFile&do=view&target=skoal-cherry-smokeless-tobacco.txt
<jam> I opened an rt request about having attachments generate emails
<LarstiQ> jam: ah, I was wondering if the dribble might have been data in distributed network
<jam> LarstiQ: and even better, if you delete the *page* it *doesn't* delete the attachments
<LarstiQ> jam: great
<garyvdm> Hi - I'm hacking some new code for qbzr.
<garyvdm> I have a simple base class - and another class that inherits form that.
<garyvdm> When I lazy_import the base class - I get this error:
<garyvdm> bzr: ERROR: exceptions.TypeError: Error when calling the metaclass bases
<garyvdm>     metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
<garyvdm> When I don't lazy_import - It works fine.
<garyvdm> How come this is?
<LarstiQ> garyvdm: are you doing metaclass magic?
<garyvdm> LarstiQ: No
<garyvdm> This is the code and trace back
<garyvdm> http://python.pastebin.com/m7962071e
<garyvdm> The base class is in bzrlib.plugins.qbzr.lib.diff: http://python.pastebin.com/d18c07715 - line 38
<LarstiQ> garyvdm: that looks to me like it should work, my only guess is that the base class is being lazy_import proxied and clashes somewhere
<eggy_> It looks like the ScopeReplacer overloads __getattribute__, __call__ and __setattr__, and that doesn't work for subclassing
<LarstiQ> garyvdm: jam is much more knowledgeable about lazy_import, maybe he knows
<garyvdm> the inheriting class is in bzrlib.plugins.qbzr.lib.commands: http://python.pastebin.com/d597201ff - line 328
<jam> I know nothing :)
<eggy_> LarstiQ: I don't think you can possibly proxy out subclassing
 * LarstiQ hands over the stage to eggy_ ;)
<jam> garyvdm: if you are inheriting from a class lazy importing is worthless
<jam> so don't fret too much about it
<eggy_> You can't even proxy out use of operators like + and () with __getattribute__
<jam> I have the feeling that metaclasses get things messy
<garyvdm> jam: ok
<eggy_> jam: should this get documented? Like, "don't use this for classes you're going to subclass"
<jam> eggy_: if you want, it should be fairly obvious that using something during import that you 'lazily' imported, is just going to force the import
<jam> garyvdm: are you importing the class itself, or the module
<jam> in *general* i would only use lazy import to import modules
<eggy_> jam: ah yes, I just read it now. It does recommend to only lazy import modules
<garyvdm> jam: Just the class I think. I'm doing: from bzrlib.plugins.qbzr.lib.diff import DiffArgProvider
<rindolf> Hi all.
<rindolf> When doing:
<rindolf> bzr checkout 'svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/amarok/' amarok.trunk/
<rindolf> I'm getting:
<rindolf> bzr: ERROR: Not a branch: "/trunk/extragear/multimedia/amarok".
<rindolf> What can I do about it?
<LarstiQ> rindolf: I recall something about the kde repo layout being specified in the bzr-svn code
<LarstiQ> rindolf: which version of bzr-svn btw?
<rindolf> LarstiQ: bzr-svn-0.5.3-1 , bzr-1.13.0, MDV Cooker
<LarstiQ> MDV Cooker doesn't mean anything, but the others seem fine
<rindolf> LarstiQ: Mandriva Linux Cooker
<LarstiQ> ah
<LarstiQ> rindolf: does `bzr branch svn://anonsvn.kde.org/home/kde/trunk/extragear/` work? Ie, two levels higher
<rindolf> LarstiQ: let me see.
<rindolf> fetching svn revision info 57/960031
 * LarstiQ got that inspiration from bzr-svn layout.custom.KDELayout
<rindolf> Seems so.
<rindolf> Why "bzr branch" instead of "bzr checkout"?
<LarstiQ> rindolf: might want to file a bug that the layout doesn't work as smoothly for the extragear part of the KDE repo
<LarstiQ> rindolf: oh eh, you can use checkout if you want
 * LarstiQ normally doesn't so did not construct what he would do with that
<rindolf> LarstiQ: can I tweak the layout locally?
<LarstiQ> rindolf: I think so
<rindolf> LarstiQ: OK.
<LarstiQ> rindolf: see `bzr help svn-layout`
<rindolf> LarstiQ: where can I find layout.custom.KDELayout? I don't seem to have it.
<LarstiQ> rindolf: for me, the full path to the file is /home/larstiq/.bazaar/plugins/dev/svn/layout/custom.py
<rindolf> I see it's in /usr/lib/python2.6/site-packages/bzrlib/plugins/svn/layout/custom.py
<LarstiQ> rindolf: yeah, that makes sense for distro installed bzr-svn
<rindolf> LarstiQ: OK.
<rindolf> LarstiQ: is there anyway I can use it?
<rindolf> KDELayout, I mean.
<LarstiQ> rindolf: well, I think it is already being used, which is why it raises the NotABranch error
<rindolf> LarstiQ: ah.
<LarstiQ> rindolf: you could look in ~/.bzr.log or maybe `bzr info` to see what svn branching scheme is being used
<LarstiQ> rindolf: the thing is, it looks like the bzr-svn KDELayout is incomplete
<rindolf> LarstiQ: I see.
<LarstiQ> rindolf: you might be able to get what you want with the help from `bzr help svn-layout`, but additionally I think bzr-svn's KDELayout needs to be fixed.
<rindolf> LarstiQ: OK.
<rindolf> LarstiQ: I don't see KDELayout being used.
<rindolf> LarstiQ: and repository UUID matches.
<LarstiQ> rindolf: hmm.
<LarstiQ> rindolf: then I'm slightly out of my depth.
 * LarstiQ tries it locally
<rindolf> LarstiQ: at least I don't see it in the logs.
<rindolf> LarstiQ: but it may still be used
<BasicOSX> vila:  haven't looked, but I'm hoping it's a bad merge. Probably from the spiv branch where I was warned NEWS merge might be messy
<LarstiQ> rindolf: it's not mentioned when -Dsvn -Dtranport are supplied either
<rindolf> LarstiQ: ah.
 * LarstiQ ponders
<LarstiQ> rindolf: bzr svn-layout svn://anonsvn.kde.org/home/kde/
<LarstiQ> rindolf: gives me an inverse trunk1 layout
<xma> hi
<rindolf> LarstiQ: so what can I do?
<LarstiQ> rindolf: have you tried the suggestion from `bzr help svn-layout`?
<rindolf> LarstiQ: yes, I now added Â« branches = trunk/extragear/multimedia/amarok/ Â» and it seems to work.
<LarstiQ> rindolf: good to hear
<rindolf> It currently tries to fetch info on all 960059 revisions.
<rindolf> LarstiQ: can I used the history only starting from a certain revision?
<LarstiQ> rindolf: I don't believe so
<LarstiQ> but I'm just a user, so I could be wrong
 * LarstiQ goes to bed
<LarstiQ> rindolf: jelmer doesn't seem to be online, but if you file a question/bug on launchpad.net/bzr-svn he'll get to it
<rindolf> LarstiQ: OK.
<rocky> what version of bzr did bug #183559 get committed to (if any) ?
<ubottu> Launchpad bug 183559 in bzr "bzr switch should have a -r option" [Undecided,Fix committed] https://launchpad.net/bugs/183559
<kenichi> the hook that lp uses to comb "bugs" revprops... is that in the bzr source tree?
<jam> rocky: 'fix committed' means someone implemented it, not that it has been merged
<jam> looking at the bug, it seems Odd_Bloke did the work here: https://code.edge.launchpad.net/~daniel-thewatkins/bzr/183559-switch-r
#bzr 2009-04-28
<spiv> Hmm, entries in NEWS aren't being alphabetically sorted lately.
<igc> morning
<garyvdm> igc: evening ;-)
<lifeless> mwhudson: so
<lifeless> in idnars branch
<lifeless> check last-revision
<lifeless> and then iter_revision_history
<lifeless> loggerhead is thinking that they are equivalent
<mwhudson> lifeless: are they not?
<lifeless> try it on the branch in question
<lifeless> spiv: https://code.edge.launchpad.net/~txawsteam/txaws/trunk for your ec2 usage
<mwhudson> >>> b.repository.get_revision(b.revision_history()[0]).parent_ids
<mwhudson> ['mithrandi@mithrandi.net-20090320033718-jxiqtdpm4qru31x2']
<mwhudson> that's a big strange, isn't it?
<lifeless> spiv: bin/aws-status specifically
<lifeless> mwhudson: unusual, but we may see it with ghosts in arch conversions
<lifeless> mwhudson: so not _wrong_. But unexpected with a native originated branch yes
<mwhudson> lifeless: right, but i don't think that's what's happened here :)
<lifeless> mwhudson: I've explained what happened already :)
<mwhudson> oh right
<mwhudson> well, i still think it's _probably_ a bzr bug
<lifeless> our data structures permit it; we don't try to create it and its likely a bug that its being permitted
<mwhudson> lifeless: bzr log --short http://bazaar.launchpad.net/~txawsteam/txaws/trunk is quite funny
<lifeless> regardless, lp and loggerhead should agree about their links. and right now loggerhead *doesn't* agree with bzr about the revno.
<mwhudson> lifeless: *bzr* doesn't agree about the revnos
<mwhudson> lifeless: if you log --include-merges you get different revnos than if you log --short
<mwhudson> (and this more or less explains why the scanner and loggerhead disagree, in fact)
<lifeless> mwhudson: ugh
<lifeless> mwhudson: we need a bug about this
<mwhudson> lifeless: not going to disagree about that
<cody-somerville> What happens when you update a branch when pushing another branch that is using the former branch to stack off of?
<lifeless> cody-somerville: you update the branch
<cody-somerville> okay :)
 * igc offline for a few hours
<TheColonial> Hi guys. I've just installed bzr on my Vista32 box, and can't seem to find the location of bazaar.conf. it's not where it says in the docs.
<lifeless> it doesn't exist by default
<lifeless> bzr --version will list the path that bzr will be looking for it in
<TheColonial> lifeless: i see. so where does it store my user info when i use "bar whoami ..." ?
<TheColonial> lifeless: thanks that's helpful!
<lifeless> spiv: alive?
<spiv> lifeless: yep
<spiv> lifeless: just got a couple of vaccinations, so alive but with two sore arms :)
<lifeless> ouch
<lifeless> flu?
<TheColonial> how do i get the difftools plugin to point at my external diff tool?
<lifeless> TheColonial: I'm not sure sorry; is there a README in it? or perhaps bzr help difftools?
<TheColonial> bzr help difftools was what i was looking for. thanks again. sorry ffor the noob questions
<spiv> lifeless: yeah, and tetanus/whooping cough/diptheria.
<lifeless> the flu one had my arm sore for about 3 days, couldn't type one of them
<spiv> Interesting.  So far the tetanus arm is hurting more, but early days...
<wgrant> Tetanus always hurts most, IME.
<spiv> Yeah, that was my memory from 10 years ago.
<lifeless> is tetanus a live virus, or deactivated?
<lifeless> anyone know if PEP 383 considers normalisation issues?
<mwhudson> tetanus isn't a virus at all, is it?
<lifeless> Gram-positive, obligate anaerobic bacterium Clostridium tetani
<lifeless> ^ apparently
<spiv> This vaccine contains "tetanus toxoid".
<johnjosephbachir> 'ello
<johnjosephbachir> if i have A is a branch of B is a branch of C, and I want to make A a branch of C, how do I do that?
<SamB> you could do pull --remember C, I guess
<mwhudson> johnjosephbachir: i'm not really sure what that means
<mwhudson> johnjosephbachir: A is already a branch of C, in most reasonable definitions of the word
<lifeless> johnjosephbachir: if you want a direct relationship, as SamB says, pull --remember C  (or merge --remember C)
<johnjosephbachir> SamB, mwhudson, lifeless -- appologies, got pulled away for something -- will be back later, thanks for your answers
<lifeless> spiv: ping
<TheColonial> lifeless: I see you're an Aussie. Used to use internode myself, pretty nice ISP. Where you based?
<lifeless> I live in Sydney
<TheColonial> Did university there
<TheColonial> so what makes you a fan of bzr as compared to other dvcs?
<spiv> lifeless: pong
<lifeless> TheColonial: well, I'm one of the core developers/architects
<TheColonial> lifeless: didn't know that :) sorry.
<lifeless> TheColonial: nothing to be sorry about
<lifeless> but it means my answers are not typical :P
<TheColonial>  i noticed ;)
<TheColonial> lifeless: I've only played with it a little, and doday is the first time i've had a go. it certainly seems nice. output is certainly a lot easier to digest than in the likes of git and hg.
<johnjosephbachir> lifeless, SamB: after pull --remember, after the next time i push, will the parent branch for the remotely hosted branch also be changed?
<lifeless> johnjosephbachir: the parent branch won't, but it won't have a reference anyway
<lifeless> TheColonial: glad you're liking it
<lifeless> spiv: if you look at my most recent patch, I need to get the token for an already locked repo; I couldn't see an obvious api for that
<TheColonial> lifeless: me too :) So is bzr something you work on in your own time? of so,what do you do full time?
<lifeless> bzr is what I'm paid to work on at the moment
<spiv> lifeless: I think token = r.lock_write(); r.unlock() is all we have
<lifeless> spiv: thats ~= what I did ;). Anyhow - 9 round trips
<spiv> :)
<lifeless> spiv: also did you see the ec2 status gui I wrote?
<TheColonial> lifeless: excellent stuff. well i wish you good luck. thanks for the help. i shall continue to play with it.
<lifeless> TheColonial: thanks :). Just ask if you have any questions
<spiv> lifeless: no, sounds shiny though!
<TheColonial> lifeless: will do :)
<lifeless> spiv: we probably need to examine some of the other ACF reports
<lifeless> spiv: see if there are other causes
<spiv> lifeless: I've been looking at them as they come in, so far there's no solid evidence of other causes that I can see.
<spiv> But it's hard to rule out.
<spiv> These bugs where cause and symptom happen far apart are PITA to diagnose.
<BasicOSX> bzr tags works for anyone in r4307?
<SamB> crash early and often, I say!
<spiv> BasicOSX: seems to for me
<BasicOSX> I get nothing :-(
<spiv> Well, that's expected if you're running it on the bzr.dev branch (unfortunately).
<BasicOSX> just tried it on fresh check out of 1.14 too
<spiv> Yes, the PQM-managed branches don't have tags.
<spiv> I'm not sure why; it's a known issue that hasn't been tracked down yet.
<BasicOSX> oh!
<BasicOSX> I thought I really borked my local stuff :)
<BasicOSX> thanks for the quick answers
<fullermd> I blame Celine Dion, myself.
<SamB> lol
<SamB> that's a pretty strange person to blame
<fullermd> That's exactly why she thought she could get away with it!
<BasicOSX> spiv:  how do I check out 1.13.1 if there are no tags in PQM managed branches :-)
<spiv> If you can't blame a former winner of the Eurovision Song Contest who can you blame?
<BasicOSX> Well, if you are American, there is always the Republican Party
<fullermd> Yeah, but then the other guys feel all left out.  It's so much work being sure to balance the blame evenly all the time.
<SamB> I don't think the Republicans are smart enough to cause such a problem!
<SamB> democrats neither!
<spiv> BasicOSX: by reading the bzr log of the 1.13 branch I guess.
<BasicOSX> ok, that is what I was doing, thanks.
 * spiv -> lunch
<johnjosephbachir> lifeless: when i do bzr info <remote url>, it reports a parent branch. that parent branch is going to disappear from existence... shouldn't i change what it points to?
<fullermd> johnjosephbachir: Depends on why you want to change it.
<fullermd> The parent branch is mostly cosmetic.  It's used as the default for a few commands like 'pull'.
<johnjosephbachir> fullermd: well for one thing, it will be a bit meaningless/useless after that parent branch disappears
<johnjosephbachir> fullermd: well exactly, i want to change the default pull location : )
<fullermd> But it doesn't imply any deeper data-model-ish link between the branches.
<fullermd> Well, you just use --remember next time you pull there.
<johnjosephbachir> and for the rest of the life of the project? for years and years the default pull location won't exist?
<johnjosephbachir> seems like there should be a solution for this...
<fullermd> No, when you use --remember it'll be changed.
<johnjosephbachir> remotely?
 * fullermd suspects we're talking past each other.
<johnjosephbachir> i mean, for years and years, contributors for the project will have to change the default pull location...
<johnjosephbachir> haha
<johnjosephbachir> perha
<johnjosephbachir> ss
<fullermd> Huh?  No.
<fullermd> Pull locations are ENTIRELY local.  The pull location on $REMOTE_BRANCH is of meaning only to $REMOTE_BRANCH.  It doesn't mean anything to any other branches you make based on it.
<johnjosephbachir> fullermd: look at the output of: bzr info bzr+ssh://bazaar.launchpad.net/%7Ejohnjosephbachir/lyceum/trunk
<fullermd> So if you "cd $REMOTE_BRANCH ; bzr pull", the parent loc matters.  If you "bzr branch $REMOTE_BRANCH local ; cd local && bzr pull", the $R_B's "parent" doesn't mean anything.
<fullermd> Right, but you never ssh to launchpad, cd into that branch, and run 'bzr pull'.
<johnjosephbachir> ahh, okay
<johnjosephbachir> gotcha
<spiv> The parent location does not propagate.  e.g. When contributors branch from your branch (say lp:~johnjosephbachir/lyceum/trunk), then their branch will get lp:~johnjosephbachir/lyceum/trunk as their parent location.
<fullermd> How did it get a parent loc in the first place?
<fullermd> Oh, I see.  That's LP internal bits.
<johnjosephbachir> spiv: that's what i thought, but was also wondering what the meaning of parent branch was
<fullermd> I guess you COULD go in with sftp and edit the branch config file manually if you really wanted to.  But it wouldn't affect anything to you from the outside.
<fullermd> And LP may assign internal meaning to it, in which case it would probably be Bad(tm).
<mwhudson> pull -d lp:whatver whatever-else --remember would also change it, i guess
<mwhudson> fullermd: LP doesn't, for sure
 * johnjosephbachir nods
<fullermd> Well, I see a URL that starts "lp-hosted:///", I run the other direction from touching it  :)
<spiv> fullermd: it's actually just an accident of how LP publishes hosted branches, I think.
<fullermd> johnjosephbachir: Anyway.  In a technical sense, the parent branch only matters when you actually cd into that branch and do various ops.  You won't in this case, so there's no technical reason to change it.
<spiv> fullermd: to the extent that the owner of the branch can't edit the relevant branch.conf...
<johnjosephbachir> k
<fullermd> johnjosephbachir: You may WANT to change it for cosmetic reasons, but there's no in-bzr reason to.
<spiv> mwhudson: LP probably shouldn't be cluttering the branch info with that though.
<johnjosephbachir> fullermd: yeah, to avoid user confusion
<mwhudson> spiv: hey, launchpad is just calling .clone!
<johnjosephbachir> mwhudson: that command-- is that done on the server, or do you mean, i can do that remotely?
<mwhudson> johnjosephbachir: i think you can do it remotely
<spiv> mwhudson: sure.  The end result is still a bug though :P
<mwhudson> spiv: i guess
<mwhudson> spiv: want to file it?
<spiv> Sure.
 * fullermd stabbies all the progress bar fragments left on his terminal from that 'info'...
 * johnjosephbachir reads about the -d flag on pull
<johnjosephbachir> OIC
<johnjosephbachir> spiv, mwhudson: a bzr bug, or a launchpad bug?
<mwhudson> launchpad-bazaar i guess
<spiv> Filed: https://bugs.launchpad.net/launchpad-bazaar/+bug/368383
<ubottu> Ubuntu bug 368383 in launchpad-bazaar "Public copies of hosted branches have nonsense parent location" [Undecided,New]
<lifeless> mmmm, not sure I agree
<lifeless> still, worth noting it caused confusion
<johnjosephbachir> well, i know my newbie question was a good once, since it caused several veterans to embark on intense debate and file a bug report :-D
<johnjosephbachir> s/once/one
<lifeless> back soon, popping up to chemist
<vila> hi all
<lifeless> spiv: I'm done for the day; 3 patches up
<spiv> lifeless: :)
<BasicPRO> PQM 1.13.2, success, attempting to re-pull bzr.1.13 and I get this: http://pastebin.com/m61bd628c
<spiv> lifeless: I guess I should do more reviewing then :)
<lifeless> spiv: 9 rtt :)
<lifeless> spiv: and 15 for stacked
<spiv> BasicPRO: Hmm.  That command worked for me.
<BasicPRO>  bzr branch http://code.launchpad.net/~bzr/bzr/bzr.1.13  bzr-1.13.2 ?
<spiv> Right.
<BasicPRO> which version of bzr? :-)
<BasicPRO> $ bzr --version
<BasicPRO> Bazaar (bzr) 1.15dev
<BasicPRO>     revision: 4307
<spiv> BasicPRO: same
<BasicPRO> hmm, /usr/bin/python 2.5.2 ?
<lifeless> shared repo?
<spiv> Although I do notice that that branch has the AbsentContentFactory bug!
<BasicPRO> lifeless:  http://code.launchpad.net/~bzr/bzr/bzr.1.13
<BasicPRO> trying it on pristine hardy+updates
<spiv> BasicPRO: Python 2.6.2 (jaunty)
<spiv> BasicPRO: are you branching into a shared repo or standalone?
<BasicPRO> python revision should not have anything to do with it? standalone
<BasicPRO> issuing  bzr branch http://code.launchpad.net/~bzr/bzr/bzr.1.13   bzr-1.13.2 and bzr-.13.2 does not exist on local filesystem
<spiv> Yeah, python version should be irrelevant.
<lifeless> we need to get pqm running 1.14 final
<spiv> BasicPRO: is there a local shared repo?
<spiv> lifeless: yes please!
<lifeless> but thats not the issue
<lifeless> the issue is probably that lp's mirror-branch-pull makes bad branches
<lifeless> mwhudson: ^
<spiv> I think LP is planning to upgrade to 1.14 more-or-less as soon as its out.
<lifeless> for now foo.py on the 1.13 branch is probably a good idea
<davidstrauss> Is there a release date scheduled for 1.14 yet?
<BasicOSX> "soon" :-)
<davidstrauss> BasicOSX: Is there a listing of current blockers?
<BasicOSX> just 1, my time
<davidstrauss> BasicOSX: So there aren't any critical bugs left?
<BasicOSX> none that I know of, but that normally does not get revealed until I put the last call for merge for release to the mailing list
<davidstrauss> BasicOSX: lol
<lifeless> BasicOSX: Just Do It
<BasicOSX> lifeless:  ok, I'd like to get 1.13.2 out before switching gears
<davidstrauss> BasicOSX: I'm asking because I'm eager to use the new join support for vendor branching.
<spiv> BasicOSX: can you pastebin the traceback from your .bzr.log for that error?  (Or use -Derror)
<spiv> BasicOSX: it probably won't tell us much, but just in case...
<spiv> BasicOSX: (but don't let that stop you from doing the release!)
<BasicOSX> I opened bug report, it's all in there Bug 368418
<ubottu> Launchpad bug 368418 in bzr "ERROR: Revision X not present" [Undecided,New] https://launchpad.net/bugs/368418
<mtaylor> GAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<mtaylor> DAMMMMMMMMMMMIIIIIIIIIIIIIIIIIIIIIIIIITTTTTTTTTTTTTTTTTTTTTTTTT
<mtaylor> lifeless: why does revert with no arguments not present a warning?
<lifeless> mtaylor: because its safe?
 * wgrant points out that 'bzr revert' backs things up first.
<mtaylor> lifeless: um, no
<lifeless> mtaylor: it backs everything up
<mtaylor> it does?
<mtaylor> oh thank god
<wgrant> *.~N~
<lifeless> mtaylor: except for things that are unaltered
<wgrant> It's not like Subversion.
<mtaylor> how do I un-revert
<lifeless> mtaylor: thats a little harder, [its not automated]
<mtaylor> lifeless:  that's fine ... I just reverted about 3 hours of hacking
<lifeless> mtaylor: also, if you want it to be able to be configured to warn, like rm -rf can be, that would be fine
<mtaylor> in the wrong window
<lifeless> but it shouldn't be the default, its an unbreakme option :)
<mtaylor> lifeless: that would be nice... this is not the first time I've reverted
<mtaylor> agree
<lifeless> because, if it did ask, you'd hit Y by muscle memory and have the problem anyway
<mtaylor> so... are there docs somewhere as to how to un revert?
<lifeless> well you have the list of changes in the output from revert
<lifeless> just look for those backup files and put em back
<mtaylor> lifeless: gotcha. rock!
<mtaylor> lifeless, wgrant: you have saved my life (as usual)
<lifeless> anytime (that I'm awake :P)
<davidstrauss> reverts backups are so annoying
<davidstrauss> revert's*
<lifeless> you can configure it I think
<davidstrauss> lifeless: I guess I could alias to no-backup
<davidstrauss> lifeless: but i much prefer the shelve all workflow
<davidstrauss> lifeless: and then clearing the shelf
<bob2> wtf
<bob2> svn obliterates uncommited working tree changes on up
<BasicOSX> spiv:  1.14rc2 branches just fine, I don't feel comfortable releasing 1.13.2 (2nd regression) unless I can get some dev feed back that the issue is local to just me
<spiv> BasicOSX: I'm about to update the bug
<spiv> BasicOSX: I can reproduce too when I branch to a standalone branch.
<BasicOSX> ok, well, 3am, real job in 5h, so bed time for me, will work on it again tonight
<spiv> BasicOSX: ok, sleep well
<BasicOSX> yes, dreams of swine flu :-(
<spiv> BasicOSX: *oinksneeze*
<spiv> BasicOSX: ok, I've narrowed it down some, it's to do with that change I landed in bzr.dev today.
<lllama> Morning all. Anyone using bzr with trac? I'm having a weird problem where trac only shows me the files from my last checkin regardless of what branch I'm browsing.
<yogsototh> Hi all, I'm trying to push on a mounted webdavfs, unfortunately, I believe somethings goes wrong with the latency...
<yogsototh> Knowing rsync works correctly but not cp -R
<yogsototh> is there someone who managed to work with webdav?
<bob2> there's a webdav plugin for having bzr push via wedav
<yogsototh> I know, but there is a bug with iDisk
<yogsototh> And I can't use it
<yogsototh> This is why I tried to mount directly the webdav disk
<yogsototh> But with no more success :-(
<lifeless> BasicOSX: its not a problem with the tip, its the other ongoing issue we're debugging
<lifeless> BasicOSX: I suggest not blocking on it
<lifeless> night all
<cdecarlo> hey, I want to use trac with bzr, but I don't want to install the .deb b/c the package manager want to install alot of other packages, any idea how I can just install trac-bzr
<LeoNerd> Are they actual requirements, or just recommends?
<LeoNerd> IIRC apt now installs recommends by default.. you can ignore them
<mrbrocoli> does bzr support something like svn:external?
<Peng_> mrbrocoli: Not yet.
<Peng_> It's been sort of partially experimental since...1995?
<mrbrocoli> hehe
<beuno> mrbrocoli, abentley is working on finishing the implementation
<beuno> I hear that it will be widely available in the next release or two
<beuno> hi Peng_   :)
<Peng_> Hello. :)
<mrbrocoli> nice, thanks for the info!
<Peng_> Wait, "nosmart+lp" works? I totally didn't know that!
<dereine> whats the best way to work on 2 seperate features  at the same time
<Peng_> Two separate branches?
<dereine> ah never thought of this
<dereine> thx!
<Ng> say I had a branch for project/ and a separate branch for project/docs, with no common ancestor, is there any way to consume docs into the project branch without losing all the history?
<Peng_> Ng: "bzr join". You might have to upgrade to an experimental disk format, or you might not. I don't remember.
<Ng> interesting
<Ng> how experimental? will any puppies be endangered? ;)
<Ng> (and could the resulting branch merge back into a non-experimental one?)
<james_w> Ng: it would need to be rich-root version of a format, of which there are vegetarian varieties. However, they are a trap-door format (with good reason), so they couldn't be merged back
<james_w> there is a merge-into plugin that John wrote to do this
<james_w> it doesn't require a format bump, but works best at one-off conversions
<Ng> james_w: thanks :)
<Peng_> rich-root formats are not experimental. Everyone'll need to upgrade eventually anyway.
<Peng_> mwhudson: BTW, Loggerhead memory usage is staying far lower than it used to; like 60 MB. However, it still creeps up slightly over time. That may be okay or it may not; I dunno.
<Peng_> Running "bzr check" after upgrading bzrtools to rich-roots, there were 23 inconsistent parents there weren't before.
<mwhudson> Peng_: good to hear, thanks
<Peng_> :)
<mwhudson> BasicOSX: is 1.14 out yet? :)
<BasicOSX> mwhudson:  ran into bug with bzr.dev and ghosts which slowed me down, but lifeless  said don't let it block me, so working on it right now
<BasicOSX> bummer make dist-check fails, investigating
#bzr 2009-04-29
<davidstrauss> BasicOSX: So, 1.14 tonight?  8)
<lifeless> BasicOSX: yes, because whatever is going on is parallelisable fixable between spiv and I
<lifeless> BasicOSX: waiting on the release for it won't make it get fixed faster, and whatever the issue is 1.13 already has it
<BasicOSX> I'm working 1.13.2 and 1.14final in parallel
<awilkins> jelmer ?
<BasicOSX> bug 368932
<ubottu> Launchpad bug 368932 in bzr "FAIL: test_no_color (bzrlib.plugins.bzrtools.tests.shelf_tests.ShelfTests)" [Undecided,New] https://launchpad.net/bugs/368932
<lifeless> BasicOSX: WARNING Installed Bazaar version 1.13.2 is too old to be used with plugin
<lifeless> "Bzrtools" 1.14.0.
<BasicOSX> lifeless:  I said as much in the bug report, justl ooking for confirmation
<lifeless> BasicOSX: I've marked it invalid already :)
<BasicOSX> Just being extra careful ... doing 2 releases is hectic
<lifeless> BasicOSX: oh sure
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> how are you going on the ACF stuff
<lifeless> do you want me to jump in?
<spiv> lifeless: so the key problem seems to be distinguishing "ghost" from "missing-but-required" in the sink.
<spiv> Or I suppose "will cause ACF errors later" from "won't cause errors".
<SamB> ACF?
<lifeless> absent content factory
<lifeless> spiv: so the sink has two cases, stacked-without-basis and stacked-with-basis
<lifeless> spiv: in *both* cases we want to end up with the same behaviour
<lifeless> thats a likely bug at the moment
<spiv> The sink doesn't necessarily know if there is stacking, though.
<lifeless> right
<lifeless> stacked-without-basis won't 'know'
<lifeless> we will have to unwind some of the 'support' in knit.py for stacking to let the sink figure out it needs various inventories, or something along those lines
<lifeless> spiv: ok, case one, without basis
<lifeless> we'll see N revisions
<lifeless> thats what the user *wants* us to have
<lifeless> we want all adjacent inventories
<lifeless> inventories that we can't get are either corrupt branch symptoms, or ghosts
<SamB> what if you tried to access the branch a remote branch is stacked on ... but the url was only good over there ?
<mwhudson> SamB: stacking is a client side thing, basically
<lifeless> in the former, we will either be unable to reconstruct some inventories[existing checks should handle this], or we can reconstruct but the union of deltas for inventory will reference texts we can't access
<lifeless> SamB: I don't understand the question
<lifeless> so, if we have an inventory parent missing, can reconstruct the inventory, then we can do a delta against all the parents we *did* get, and check that every text added is available locally
<lifeless> thats basically the logic in find_file_ids_altered again
<spiv> Right.
<spiv> So basically requiring adjacent parents is too strict.  It's sufficient but not necessary.
<spiv> Each parent we have cuts down the set of texts that we require.
<spiv> We don't even *need* any parents for some inventory so long as we have every text referenced by that inventory.
<lifeless> right, though every parent we miss is more data we'll send
<spiv> Right.
<spiv> Ok, I think I know how to rework this.  It's a shame it's so complex.
<spiv> It'd be nice to have a nice helper object for tracking the set of "key A needs keys X, Y, Z", which I could just feed newly seen keys and their dependencies into...
<cody-somerville> ugh, this is weird
<cody-somerville> I do bzr add and nothing happens
<cody-somerville> bzr status shows the directory I'm trying to add as unknown
<cody-somerville> bzr 1.13.1
<spiv> cody-somerville: that does sound odd
<cody-somerville> aw, I see why from bzr.log
<mwhudson> cody-somerville: is it ignored
<mwhudson> ?
<cody-somerville> no
<cody-somerville> nested bzr tree
<spiv> mwhudson: "unknown" implies "not ignored"
<mwhudson> oh right, you said that already :)
<cody-somerville> removing the .bzr in the directory resolves the issue
<cody-somerville> However, its odd that bzr doesn't say something more meaningful than just nothing
<mwhudson> spiv: right
<spiv> cody-somerville: file a bug.  The nested tree stuff isn't fully mature yet.
<cody-somerville> will do
<lifeless> actually
<lifeless> its deliberate
<lifeless> we don't auto-add nested trees or child trees
<lifeless> there are separate commands for that
<cody-somerville> still a bug that no error is given when I specifically try to add it
<cody-somerville> In this case, I didn't intend for it to be a nested or child tree
<spiv> lifeless: oh?  Hmm, I guess I can see that.  Sounds like the current UI is confusing enough that we should do something differently, though.
<lifeless> cody-somerville: 'bzr add tree' will add *in that tree*
<cody-somerville> bzr help add doesn't mention that
<SamB> lifeless: should say SOMETHING if you explicitly mention one, though
<SamB> like "not adding nested tree blah blah blah because blah blah blah"
<SamB> or whatever
<lifeless> cody-somerville: its a bit of a theme in bzr that when you give it a path it acts on the tree the path is in
<lifeless> SamB: it *never* sees that its a nested tree
<lifeless> SamB: because its been given the root of a tree
<cody-somerville> Thats not quite what .bzr.log suggested
<SamB> lifeless: well, it should say that it's not doing anything
<cody-somerville> Let me add that to my bug report
<cody-somerville> oh wait
<cody-somerville> nvm
<lifeless> SamB: its the same as 'bzr add' isn't it?
<lifeless> SamB: that already says "
<lifeless> ignored 702 file(s).
<lifeless> If you wish to add some of these files, please add them by name.
<lifeless> "
<SamB> oh, wait, why does "bzr add tree" do an add in that tree ... that sounds pretty wierd
<lifeless> SamB: same reason that 'bzr commit /path/to/tree' commits in  that tree
<SamB> these commands are too context-dependent :-(
* BasicPRO changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14rc2 released 20 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Peng_> The question is, does 1.13.2 go before or after 1.14rc2 in NEWS?
<Peng_> And I bet I could find out in about 15 seconds. :P
<fullermd> Yes   :p
<SamB> hmm, so should NEWS be a directed graph instead of a linear history ?
<lifeless> no
<lifeless> its a flattened traversal of all releases done for convenience
<lifeless> 'trunk' has never been released
<lifeless> spiv: so if you're not needing help with acf stuff, I'll keep pushing round trips down
<fullermd> Trunk is not released.  It escapes.
 * SamB steals trunk
<spiv> lifeless: sure
<Peng_> SamB: Now you have to be PQM. :P
 * SamB puts the tags back in and lets trunk escape again
<xiaohui> I have make a local branch of trunk at rev 2376, then I committed with unchange , the revision goes to 2377. After I used *bzr rebase lp:project* , now the revision is 2467, anctually the revision of trunk is 2466 now. When I use *bzr push*, it shows * bzr: ERROR: These branches have diverged. Try using "merge" and then "push".*  How should I do now?
<lifeless> you have to use --force after rebasing
<lifeless> because rebasing looks to bzr like you have created new unrelated history
<xiaohui> when I  pushed the to my branch but not the trunk
<lifeless> thats right
<lifeless> if you want to rebase you'll have to --force always
<xiaohui> and some one told me use the *bzr rebase lp:mybranch* to have a try
<lifeless> because rebase breaks the links that let bzr know what you have done built on something you'd pushed earlier
<xiaohui> you mean I shoud use it like *bzr rebase --force*?
<SamB> xiaohui: maybe you just shouldn't use it ;-P
<SamB> it IS rather destructive
<SamB> have you read what Linus has to say about it?
<SamB> you probably should
<Kilroo> Out of curiosity, is it at all likely that when I installed 1.13 over an existing installation recently it either failed to overwrite my installation of bzr-svn or installed the wrong one...or did I probably just accidentally tell it not to include the core plugins?
<xiaohui> no, SamB
<xiaohui> SamB: what the Linus said?
<lifeless> Kilroo: I would guess you didn't tell it to include the plugins
<lifeless> xiaohui: 'rebase turns tested code into untested code' -- Linus
<Kilroo> I suspected as much.
<xiaohui> so ,lifeless  how should I do now.I have no idea
<lifeless> xiaohui: use --force when you push, or don't use rebase.
<xiaohui> so use the *bzr rebase lp:trunk*, and *bzr push --force * to my branch
<xiaohui> I see, thank you lifeless
<xiaohui> oh, it doesn't work
<SamB> xiaohui: this is what I meant: http://lwn.net/Articles/328438/
<SamB> it took me a while to find it again
<SamB> I wonder how I got to it the first time ...
<xiaohui> thanks ,SamB
<xiaohui> there are some more terrible problem *bzr: ERROR: Could not acquire lock "(remote lock)"*
<xiaohui> I use the * bzr break-lock lp-140409033803088:///~xiaohui/opencog/moses/.bzr/branch/lock * and it return the ERROR of *bzr: ERROR: Unsupported protocol for url "lp-140092643935568:///~xiaohui/opencog/moses/.bzr/branch/lock"*
<xiaohui> how to break the remot lock?
<lifeless> xiaohui: bzr break-lock lp:~xiaohui/opencog/moses
<xiaohui> :),
<garyvdm> ping igc1
<garyvdm> Sorry Ian - I got to run - I'll send my question in a mail.
<BasicPRO> Bug 304883 is fix released, but I do not see it in NEWS or find a log of it
<ubottu> Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883
<BasicOSX> but it is tagged 1.14
<BasicOSX> The other 2 bugs tagged for 1.14 have NEWS entries and I find them in the logs
<lifeless> wow, hadn't heard of it even
<BasicOSX> I've PQM'd 1.14 with bug 364900 and bug 358037 to keep the ball rolling
<ubottu> Launchpad bug 364900 in bzr "pure python Groupcompressor failure" [Critical,Fix committed] https://launchpad.net/bugs/364900
<ubottu> Launchpad bug 358037 in bzr "Revision not in bzrlib.groupcompress.GroupCompressVersionedFiles" [Undecided,Fix released] https://launchpad.net/bugs/358037
<BasicOSX> Looks like 358037 was in 1.14rc2, so but result is the same
<BasicOSX> lifeless:  advise on bug 304883? Wait on it or push 1.14 out the door?
<ubottu> Launchpad bug 304883 in bzr "Handling of carriage return character across platforms" [High,Fix released] https://launchpad.net/bugs/304883
<BasicOSX> lifeless:  or as RM my call? :-)
<lifeless> your call
<lifeless> I would get 1.14 out
<BasicOSX> brb, getting a coin
<spiv> BasicOSX: see also igc's reply to your mail on the list
<lifeless> later, all, started early this morning
<Peng_> Is "getting a coin" a slang term I don't know, or did you actually get a small amount of money?
<lifeless> Peng_: to flip
<Peng_> Ahhhh. Thanks. :)
<lifeless> one flips coins to make binary decisions
<fullermd> Y'know, 1d2   ;)
<Peng_> Yes, in the rock I've been living under we used a piece of bark.
<Peng_> Isn't there a virtual coin flip website?
<fullermd> Who trusts other people's entropy?
<lifeless> theres a sshkeygen website
<fullermd> There is?
<Peng_> They even encourage you to enter your username and hostname for the comment. It's brilliant.
<fullermd> Wow.
<fullermd> The internet has ruined my ability to take minor joy in imagining spectacularly bad ideas   :(
<Peng_> Where does the guy who runs it even get enough entropy? Maybe the website gives out the same keys every time.
<fullermd> Oh, that's easy.  Any amount of entropy automatically contains some unknown multiple of the amount of entropy it contains!
<lifeless> fullermd: http://www.sshkeygen.com/ <- :)
<Peng_> Oh! It defaults to 512-bit keys! WTF?
<Peng_> "upswing isodialuric overbray 92580" is a great suggested passphrase.
<fullermd> Crap.  Now I have to change all my keys...
<vila> hi all
<lifeless> vila: hi, your ssh fix, is it blocked?
<vila> lifeless: not reviewed so far AFAIK
<lifeless> vila: is the bug in 1.14?
<vila> as mentioned in the cover letter, no, only in bzr.dev
<vila> but the NEWS file is a bit misleading in that reagard
<vila> regard even
<fullermd> It works for me...
<vila> fullermd: what ? Changing all your ssh keys ?
<fullermd> That would be a slightly different definition of 'work'   ;)
<vila> fullermd: so, you mean you tested my patch ?
 * fullermd nods at vila.
<vila> fullermd: thanks
<fullermd> I now get "that's not a branch, wtf are you smoking" instead of "Password:            ] bzr+ssh <      0KB     0KB/s |"
<fullermd> Which actually might be a really good password, come to think of it, but...
<lifeless> jamesh: docs for gnome-keyring via python, where would I find?
<vila> BasicOSX: Dear RM, how about defining a 1.15 series and a 1.15rc1 milestone so that we can target bugs ? Thanks in advance :)
<jamesh> lifeless: I don't know if there are specific docs, but the module is gnomekeyring, and the API is almost identical to the C API
<jamesh> lifeless: with the exception that the async interfaces have not been wrapped
<lifeless> argh
<lifeless> I want a place to store a aws key id and secret  key
<lifeless> jamesh: but no async api means blocking the ui, doesn't it ?
<jamesh> lifeless: yes.
<lifeless> sadness
<jamesh> but it is usually pretty quick ...
<lifeless> is it trivial to wrap the async interface and simply laziness, or are there complications
<jamesh> provided it doesn't ask the user for authorisation before returning the data
<lifeless> jamesh: given I don't want to depend on something as complex to rebuild as pygnome, for now I'll used sync apis
<jamesh> wrapping the async interface involves lots of callback wrappers, so it probably is laziness
<lifeless> you've seen my ec2 client?
<jamesh> lifeless: nope.  How does it differ to pyboto?
<jamesh> python-boto, that is.
<lifeless> jamesh: two ways, its a gui, and its async
<lifeless> lp:txaws
<jamesh> it'd be really nice if twisted.defer was part of the Python standard library
<jamesh> I mean twisted.internet.defer
<lifeless> yes
<lifeless> someone should propose it
<lifeless> I hear people can commit stuff to python
<jamesh> then it wouldn't be controversial to wrap async APIs like gnome-keyring using deferred objects
<lifeless> jamesh: I wrote this because I spent 50% more than our monthly cap developing the bzr ec2 test support
<lifeless> jamesh: and I didn't want to accidentally leave an instance running overnight ;)
<jamesh> you could just set up a cron job to kill all ec2 instances on the hour.
<lifeless> kindof expensive
<lifeless> and nowhere near as useful
<jamesh> that'd also encourage test suites to take less than an hour to execute
<lifeless> bzr's is < 2 minutes if you throw enough instances at it :)
<lifeless> so its lp's
<lifeless> s/its/is/
<jamesh> having an easy API for deferred objects in C would also help
<jamesh> even if it is just a bunch of PyObject_CallMethod() wrappers
<lifeless> agreed
<lifeless> I have one I'm piecing together in libvfs
<lifeless> igc1: btw, you need to enlarge your 'open data format' stuff a _lot_ - last I read it it looked like handwaving : 'we' have spent a lot of time considering extension points for the core store and not found any that were satisfactory in the general case
<lifeless> igc1: [and a general mechanism is by definition the general case]
<igc1> lifeless: Can you point me to mailing list discussions that I ought to read/re-read?
<lifeless> igc: versioned properties discussions right from the start basically
<lifeless> igc: various challenges exist - consistency, updating, schema, validation, check, reconcile, propogation, merge,
<lifeless> indexing
<lifeless> and performance
<lifeless> igc: more broadly, one needs to consider how things will degrade for clients not supporting $extension, and if the answer is 'they do the wrong thing', then a repo with that extended data in it is broken for clients
<lifeless> which is arguably identical to our current behaviour
<lifeless> In general terms, I think the question is about 'is it possible' not 'how to make it happen', for a safe extensible format
<igc> lifeless: it's software - anything is possible :-) :-)
<igc> lifeless: seriously, I like your list
<igc> lifeless: I don't expect the core to solve every problem for every type of data
<igc> lifeless: I do expect it to provide plumbing where it can and delegate things it can't to the plugin/code registering the extended data
<lifeless> I'd be delighted to make sure fetch calls hooks to let people add data and recieve extended data
<igc> lifeless: there will be limitations but I don't believe that means we should throw the baby out with the bathwater and say "it can't be done"
<lifeless> I'm not at all sure that the _storage_ of said data should be in .bzr/repository
<lifeless> igc: I think there is a different between an extensible store, and hooks allowing plugins to do what they want to alongside core operations
<lifeless> igc: I argue that there isn't a difference at the user level, but there is a vast difference for the programming and performance implications we face
<lifeless> we consider very carefully where *our* data goes and what it implies; is it a column store or row store, how long does it take to do X, or Y.
<lifeless> someone storing a mime type per file could easily add 50% to the raw storage size of inventories
<lifeless> and writing a general purpose, high performance, tuning-free, self-maintaining database, while extremely interesting, isn't really what we're here to do
<lifeless> IMO
<lifeless> I hope I'm making sense
<igc> lifeless: you are and I agree with most of what you're saying
<igc> lifeless: but ewe need a better answer than "new format required" when code/a plugin wants a small amount of data managed for it
<lifeless> igc: I think plugins should maintain their own stores
<igc> lifeless: it one thing to say "one format only during the life of 2.0"
<lifeless> in db terms they should get their own shard, and do what they want with it
<igc> lifeless: it implies though that only people running the development format get to see any data-dependent new features until 3.0 is released
<lifeless> it comes back to definitions
<lifeless> I don't think replacing format with 'schema version' makes things better
<igc> lifeless: which, IMO, means 3.0 is back to "big bang" releasing with lower quality (as a rule)
<lifeless> if something is -truely- safe to add to the data existing code processes it can be added to an existing format with todays mechanisms
<lifeless> I think we're trying to cross the chasm at the moment
<lifeless> and fast incremental releases are giving our non early adopters problems
<igc> lifeless: but we seem to do that extremely rarely because format bumps are our only instrument for code-data alignment protection
<igc> lifeless: I think branch dpeendency rules will help here
<lifeless> we'll be having a sprint
<lifeless> I am not against achieving safe finer granularity; I'm against making the system more fragile,
<lifeless> and I think that adding more stores is a better approach than a single 'extensible' store, for a number of reasons
<lifeless> those above
<lifeless> plus separation of core and non core data
<lifeless> see for instance the long desired 'file graph is a cache' one
<igc> I like the multiple stores approach - it's what I was getting at with the baggage idea
<lifeless> bzr-search is an example of this
<lifeless> living breathing working without needing changes to bzr itself
<igc> lifeless: right, so we need the rules on how to do that better documented and explained
<lifeless> sure
<igc> lifeless: I need to head to dinner
<fullermd> And a lot more hooks, sounds like.
<igc> I'll copy-and-paste this conversation into the spec so it doesn't get lost
<lifeless> I sure
<lifeless> what else
<lifeless> oh, right - I disagree with one format, no schema changes implying big-bang
<lifeless> it just means we have more time spent stewing it in beta
<lifeless> and we should allow for that
 * igc dinner
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.13.2 released 28 April, 2009 | 1.14 released 29 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<fullermd> Yay!
 * fullermd watches the tarball trickle in from LP at 27 kBps.
<Peng_> BasicOSX: Congrats on the release. :)
<BasicOSX> ty
<spiv> BasicOSX: yes, congrats and thanks!
<davidstrauss> BasicOSX: woo hoo!
<BasicOSX> now the scary part, merge back to trunk
<BasicOSX> I need some assistance, "You should also merge (not pull) the release branch into lp:~bzr/bzr/current, so that branch contains the current released code at any time."
<BasicOSX> I keep getting "Transport operation not possible: readonly transport "
<BasicOSX> Can someone tell me the command I should be using? Or can verify I still have write access to that branch?
<spiv> BasicOSX: anyone in the ~bzr team should be able to, I think...
<spiv> BasicOSX: and you are, so that's a bit odd.  You have a checkout or branch of lp:~bzr/bzr/current that you're trying to merge into, and then getting that error when you push/commit that?
<BasicOSX> yes
<spiv> Maybe you haven't do "bzr launchpad-login tanner"?  Seems a bit unlikely though...
<BasicOSX> re-trying using 1.14/bzr vs bzr.dev/bzr
<spiv> I doubt that'll make a difference (I certainly hope it doesn't!)
<BasicOSX> 4:15am, I'm desperate :-)
<spiv> Which transport / URL is that error about?
<BasicOSX> lp:~bzr/bzr/current
<BasicOSX> I'm going http now
<BasicOSX> for branch
<spiv> That's an alias, not a URL, technically...
<BasicOSX> oh, ok, umm, https+urllib://code.launchpad.net/%7Ebzr/bzr/current/
<spiv> It translates to either http://... or bzr+ssh://... depending on if you did lp-login or not.
<spiv> Ah, right, so you *haven't* done "bzr launchpad-login" then.
<BasicOSX> I tried to  branch with lp, got dreaded AbsentContentFactory
<BasicOSX> I'm branching via http now, will do login and push next
<spiv> It doesn't matter how you branch (do whatever works), it's how you push that I'm interested in.
<BasicOSX> I'd like to branch via lp: seems faster, but routinely fails on most branches on lp
<spiv> Pretty much any stacked branch that has a merge, yeah :(
<spiv> Now that 1.13.2 is out that should be less of a problem.
<BasicOSX> I blame the Republicans
<BasicOSX> hmph, branch segfaulted!
<Peng_> BasicOSX: Use nosmart+lp: to still use bzr+ssh, but avoid AbsentContentFactory. (It uses the VFS, so it's basically equivalent to sftp.)
<BasicOSX> nice, I'll note that
<spiv> Peng_: oh, does the nosmart+ prefix survive the translation from lp: to bzr+ssh: ?  That's handy.
<BasicOSX> it worked for me, xfer much faster, still taked long time for inserts :-)
<Peng_> spiv: Surprising, huh? I only found out yesterday.
<BasicOSX> bah
<BasicOSX>  bzr branch nosmart+lp:~bzr/bzr/current
<BasicOSX> bzr: ERROR: Revision {[('john@arbash-meinel.com-20050711051006-2d11704675600e95',)]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), <bzrlib.knit._DirectPackAccess object at 0x875cfac>)".
<Peng_> I thiiink that's a known bug? Like when you branch --stacked either into a shared repo or a standalone repo?
<BasicOSX> standalone
<BasicOSX> going back to http
<spiv> BasicOSX: that's with bzr.dev?
<BasicOSX> yes
<spiv> BasicOSX: ok, known bug, introduced in r4307
<spiv> (bug 368418)
<ubottu> Launchpad bug 368418 in bzr "'Revision X not present': when branching from stacked branch with ghosts" [Critical,In progress] https://launchpad.net/bugs/368418
<spiv> Which you should recognise, because you reported it ;)
<Peng_> BasicOSX: This is random, but thanks for being the release manager. You've been doing a good job, and you've helped improve the release process for every future RM.
<spiv> I'm working on it right now.  I think I have a functioning fix, just crossing the "t"s and dotting the "i"s.
<spiv> (I certainly have a branch that works with the ghosts in bzr.dev)
<spiv> (Not sure why it's taking so long for you to branch though... don't you have a shared repo?)
<BasicOSX> I always do standalone
<BasicOSX> most of my work is done in a pbuilder chroot, so pristine enviro
<spiv> Oh, that's a shame.  Perhaps prime it from a more local branch to save time?
<BasicOSX> I read releasing doc as pull from LP each time, but that might have been my noob eyes first time I read it and dumb brain for not re-thinking it
<spiv> Yeah, that sounds like something that wastes a fair bit of time for not much gain.
<davidstrauss> BasicOSX: Fresh 1.14 RPMs for bzr and bzrtools: http://fourkitchens.com/blog/2009/04/29/bazaar-114-rpms-rhel-5-centos-5
<BasicOSX> not sure I wanna pollute my ubuntu system with rpms :-P
<davidstrauss> BasicOSX: They're not for Ubuntu ;-)
<davidstrauss> BasicOSX: Any objection to linking to my RPMs from the official download page?
<BasicOSX> I see someone found the 1.15rc1 milestone
<BasicOSX> davidstrauss:  not really my call
<BasicOSX> It is a wiki tho, so I'm sure the powers that grant edit access could let you maintain your own section
<spiv> davidstrauss: I'm pretty much done for the day, but if all else fails mail the list to let people know about them.
<mwhudson> jelmer_: hello, did you get my email?
<ronny> yo
<ronny> is there any specific reason why bzr < 1.14 doesnt seem to be installable via easy_install?
<ronny> lifeless: can you guys make it possible to easy-install older versions of bzr, too?
<beuno> jam, lifeless, vi, ping?
<beuno> vila even
<beuno> bzr just dies with a traceback
<beuno> and it's still streaming content
<jam> beuno: what's up?
<jam> (I'm not 100% here, but I can try to help)
<beuno> jam, hi
<beuno> still feeling sick?
<jam> beuno: yeah
<jam> mostly a bad cough
<beuno> :/
<beuno> well, I already killed the process
<beuno> but, bug 369242
<ubottu> Launchpad bug 369242 in bzr "bzr keeps streaming content after crashing" [Undecided,New] https://launchpad.net/bugs/369242
<beuno> never happened to me
<beuno> so I wasn't sure how to best debug it
<jam> beuno: so it sounds like the *local* client is dying, but it isn't killing the ssh process, and the remote server is stil sending data
<jam> however, I would be surprised if the local ssh client would buffer forever
<beuno> right, I waited for 5-10 minutes, and it was still chewing up all my bw
<beuno> maybe it would of died at some point, but it seemed excesive
<jam> well, 5-10 minutes of your whole bandwidth seems like a lot of data to me
<jam> I have to wonder where it all went
<beuno> I was wondering as well  :)
<jam> so.. you have "after crashing"
<jam> does that mean the bzr process was dead?
<beuno> yes
<jam> or just gave a traceback, but was still running?
<beuno> traceback
<jam> because after that you say "bzr streaming content"
<beuno> and I think the process was ssh
<beuno> may be the wrong wording
<beuno> jam, either way, bug reported, can be followed up at any time
<beuno> wanted to see if someone was interested in debugging it "live"
<beuno> go back to resting  :)
<beuno> thanks
<rocky> this is odd, trying to easy_install bzr 1.14 in jaunty and getting a problem with not being able to find zlib.h
<rocky> jelmer: i think you manage the download files for bzr-svn in too many locations... out of sync ;)
<rocky> does bzr 1.14 work ok on py2.6 or is it still not officially supported?
<beuno_> rocky, I think it does just fine?  I'm using jaunty with 2.6 with no problems
<jim6> Hi - I've just installed bzr, and am having trouble checking out through a http proxy. I have tried ; export http_proxy=www-proxy.<blah>:8080 ; bzr checkout <blah> . I'm getting connection refused. Can anyone help
<jim6> ?
<LarstiQ> jim6: http_proxy=http://ww-proxy.<blah>:8080
<LarstiQ> s/ww/www/
<jim6> LarstiQ: tried it, still no joy
<LarstiQ> jim6: try -Dtransport -Derror and pastebin the traceback?
<LarstiQ> that is, bzr checkout foo -Derror -Dtransport;
<jim6> LarstiQ: http://dpaste.com/39284/
<LarstiQ> jim6: does it differ if you try https_proxy instead of http_proxy?
<LarstiQ> it being a https url you are connecting to
 * LarstiQ knows very little of proxies, as you can see
<LarstiQ> jim6: also, I'm reminded this might be an xmlrpc problem, in which case you could try prepending nosmart_
<LarstiQ> nosmart+
<LarstiQ> jim6: so that would be `bzr checkout -v -rrevno:630 nosmart+https://launchpad.net/pybindgen`
<LarstiQ> jim6: alternatively, you could try via bzr+ssh:// instead of http(s) based
<jim6> LarstiQ: looks like https_proxy worked >_<
<jim6> thanks
<jim6> that was pretty obvious once you pointed it out ;)
<LarstiQ> jim6: ah, maybe you can do me a favour in kind then ;)
<LarstiQ> the text I'm reading on the relation between confidence intervals and hypothesis testing is _not_ making things clear :/
<jim6> I could give it a go ... ?
<LarstiQ> jim6: sections 1.7 and 1.8 in http://richtlijn.be/~larstiq/ProbStatII.pdf
<jim6> LarstiQ: over my head, sorry :-/
<LarstiQ> jim6: no worries, I'll get there eventually.
<LarstiQ> even if it is by skipping to parts that are less dense ;)
<jelmer_> abentley: hi
<abentley> jelmer_: hi.
<jelmer_> abentley: I'm trying out nested trees and noticed some rough edges, ones that aren't covered by your pending patches as far as I can tell. Should I send you an email about these issues or wait?
<abentley> jelmer_: please send me an email.  It might be stuff I haven't thought of.
<jelmer_> abentley: ok
<jelmer_> abentley: How does bzr know the canonical location of a reference-joined branch?
<jelmer_> abentley: (I've used "bzr join --reference <local-branch>" and that doesn't seem to update .bzr/branch/references)
<abentley> jelmer: It defaults to using the relative path to the tree.
<abentley> jelmer_: Quite possibly it should record it then.  I'm still mulling that issue over.
<davidstrauss> abentley: It would be immensely useful to join in a way that allows easy merging from the original sources.
<jelmer_> davidstrauss: Don't you mean for by-value nested branches?
<davidstrauss> abentley: (This would require tracking the origins and allowing a batch merge.)
<abentley> davidstrauss: Okay, are you assuming that the subtree is a checkout/lightweight checkout of the original sources?
<davidstrauss> abentley: The subtree still needs to allow commits of local changes.
<fullermd> Oooh, Ikarus is using bzr....
<abentley> davidstrauss: So merge in the subtree should still merge from the original sources.
<davidstrauss> abentley: yes
<davidstrauss> abentley: This would be for vendor branching
<abentley> davidstrauss: I mean, it does already.
<davidstrauss> abentley: It tracks the original branch URLs for merging?
<LarstiQ> fullermd: which Ikarus?
<abentley> davidstrauss: bzr branch tracks the original branch URLs for merging.
<fullermd> LarstiQ: http://www.ikarus-scheme.org/
<davidstrauss> abentley: and this is with a normal (non --by-reference) join?
<abentley> Oh, I misunderstood.
<davidstrauss> abentley: all the parent branch data is preserved?
<LarstiQ> fullermd: ah ok, not the Dutch person who'se nick is Ikarus and has a ~10 year shared history with myself and jelmer then ;)
<abentley> For vendor branches, --by-reference is recommended.
<davidstrauss> abentley: Is --by-reference stable?
<abentley> davidstrauss: No
<fullermd> Probably not  :p
<fullermd> But he probably compiles slower anyway...
<davidstrauss> abentley: --by-reference doesn't quite join it into the parent tree, right?
<abentley> davidstrauss: Right.  Inside the subtree, bzr will behave as though it's not joined.  In the containing tree, bzr will behave as though it is joined.
<davidstrauss> abentley: Does it do this by preserving the original branch and merely noting the join in the parent tree?
<abentley> davidstrauss: Right.
<davidstrauss> abentley: It seems kind of inconsistent and non-atomic to treat the by-reference join differently inside its subtree than outside
<davidstrauss> abentley: I'd rather just have the normal join and have the branch parents be an array
<davidstrauss> abentley: and have an option to step through branch parents and merge
<abentley> davidstrauss: It's a performance win, and it's not just about merge.  There should always be a way to treat a subtree as though it was not part of a larger tree.
<davidstrauss> abentley: ok
<abentley> davidstrauss: There will probably be a way to force commands to treat it as one large tree.
<abentley> even in subtrees.
<davidstrauss> abentley: I'm concerned that the abstraction is just good enough to make the behavior changes related to your working directory confusing
<davidstrauss> abentley: svn always commits from your w.d. below
<davidstrauss> abentley: but bzr commits the branch as a whole by default
<jelmer_> davidstrauss: The whole point of using a by-reference nested tree as opposed to a by-value nested tree is that you can use it both as part of the whole and separately
<davidstrauss> abentley: but you'd have to check to see if you're in a subtree first to know the behavior with the proposed by-reference join design
<abentley> davidstrauss: The idea is that your subtrees are somewhat independent entities, and it makes sense to commit to them individually.
<LarstiQ> davidstrauss: it might still make sense to make the workflow with by-value nested trees nicer though.
<abentley> I think that users won't find it hard to remember where the subtrees are, because they will be split at intuitive places.
<davidstrauss> abentley: Probably true
<davidstrauss> abentley: Will a subtree understand that it's a subtree, or will the referenced branch be naive of its status?
<abentley> Naive.
<abentley> davidstrauss: Note that branches may be used in multiple contexts, sometimes as subtrees.
<davidstrauss> abentley: So it would therefore be complex to warn the user that their commands are operating on a subtree?
<abentley> davidstrauss: It would be more expensive, and would involve only trees, not branches.
<davidstrauss> abentley: That makes sense
<abentley> But theoretically, you can try to open a containing tree, and then see if there's a tree-reference for the root's file-id.
<davidstrauss> abentley: Would it be flawed or expensive to always treat trees within trees as nested trees?
<davidstrauss> abentley: Repo layouts typically only put branches at leaves in the directory structure.
<abentley> davidstrauss: Opinions vary.
<LarstiQ> flawed, imo.
 * jelmer_ agrees; I think it would defeat the whole purpose of having nested trees in the first place
<LarstiQ> although you could argue what it means to be a nested tree
<abentley> davidstrauss: I think that having it done automatically would be bad.  Remember that you're normally required to "add" anything.  And I think that if users aren't expecting this behavior, they may be unpleasantly surprised.  Especially while it's beta.
<davidstrauss> abentley: Good point, though it means users might be confused whether to use add or join on subtrees.
<davidstrauss> abentley: Right now, you can do either with very different results that seem, at least superficially, the same.
<abentley> davidstrauss: At this point, I think maximum specificity is good.  When this feature is fully polished, I'd be willing to re-examine supporting "add".
<abentley> davidstrauss: You can't add a nested tree at present.
<abentley> davidstrauss: https://pastebin.canonical.com/17020/
<abentley> doh
<abentley> ubottu: !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<abentley> davidstrauss: http://paste.ubuntu.com/160792/
<davidstrauss> abentley: So adding it fails silently?
<jelmer_> abentley: I think bzr shouldn't silently ignore adds in that case though
<abentley> davidstrauss: yes.
<abentley> jelmer_: I'm really tired of debating the correct "add" ui :-(
<davidstrauss> abentley: But silence means success :-P
<abentley> davidstrauss: No, not to add.
<abentley> davidstrauss: add tells you what it added.
<abentley> davidstrauss: So silence is failure.
<davidstrauss> abentley: Or a no-op
<davidstrauss> abentley: My assumption as a user would be that there was nothing to add
<abentley> davidstrauss: That's true.
<davidstrauss> abentley: Sorry to bring up a debate that you hate, but this sort of stuff totally befuddles most users
<davidstrauss> abentley: If you can't add a subtree, add should throw a full-on error
<abentley> http://paste.ubuntu.com/160796/
<abentley> davidstrauss: It is interpreted as trying to add files to the subtree.
<abentley> davidstrauss: Of which there aren't any.
<jelmer_> ahh
<ZuLuuuuuu> Hello, I saw Mercurial is supported on more and more project hosting sites (lastly by Google Code) though I don't know any project hosting site other than Launchpad to support Bazaar. Is implementing support for Bazaar hard or something? Why are project hosting sites support Mercurial but not Bazaar? For example Savannah also has support for Mercurial and not for Bazaar.
<davidstrauss> abentley: But in your example, the subtree isn't joined, even by reference.
<abentley> davidstrauss: True.
<abentley> davidstrauss: Not sure what you're getting at.
<davidstrauss> abentley: Either subtrees should be always transparently nested or bzr should refuse to recurse into them.
<abentley> davidstrauss: I'm not sure how the fact that the subtree in my example isn't joined by reference is related to that point.
<jelmer_> davidstrauss: you don't have to be in a tree ($CWD) to version files in it
<davidstrauss> jelmer_: Yes, I understand
<jelmer_> ZuLuuuuuu: Bazaar code hosting doesn
<jelmer_> ZuLuuuuuu: Bazaar Code hosting will work fine for most situations with simple write access
<jelmer_> ZuLuuuuuu: e.g. no need for a smart server to be running
<davidstrauss> abentley: You're running "add" from cwd for branch/tree foo, but the command is actually using branch/tree bar without any feedback. I would expect bzr to do this if I had joined (by-reference) bar into foo, but not if bar is just in a subdirectory.
<ZuLuuuuuu> But hosting a project in project hosting site has some advantages
<ZuLuuuuuu> I would prefer a VCS with more support if I were a new user
<fullermd> SF does bzr now, doesn't it?
<abentley> davidstrauss: When you pass a directory location to "bzr add", it always opens the tree containing that directory and adds that directory and its children to it.
<abentley> davidstrauss: "cd..;bzr add foo" would add files to "foo", for example.
<davidstrauss> abentley: I've always considered "add" to add its argument to the tree/branch in the cwd, but that's clearly not the case.
<davidstrauss> :-/
<davidstrauss> abentley: The current semantics are troubling if you don't specify any arguments to add.
<ZuLuuuuuu> fullermd: yes it support bazaar, git, mercurial
<davidstrauss> abentley: http://paste.ubuntu.com/160802/
<davidstrauss> abentley: at least "stat" should show that something's a tree/branch
<davidstrauss> or maybe not
<davidstrauss> but it's totally unpredictable that add recurses and performs its add operations on the deepest tree
<davidstrauss> but commit doesn't unless the sub-trees have been joined
<abentley> davidstrauss: If you supply a path to commit, you should get the same "deepest-tree" behavior.
<davidstrauss> abentley: but if i don't supply a path, add and commit have different recursive behavior
<abentley> davidstrauss: I don't think so.  What do you mean?
<abentley> the deepest-tree behavior is only if you specify a path.
<davidstrauss> abentley: oh, indeed. hmm.
<davidstrauss> abentley: Really, this is the only effect I'm trying to avoid: http://paste.ubuntu.com/160810/
<abentley> I agree that situation is ugly.
<abentley> The simplest solution would be to include 'bar' in the list of ignored files.
<abentley> But I guess that doesn't work because it interprets what you're doing differently.
<davidstrauss> abentley: Yeah, you can explicitly add ignored items
<abentley> We have a message in "commit" saying where you're committing.  Putting one in "add" might help with "bzr add bar".
<davidstrauss> abentley: I wouldn't be opposed to dropping join and integrating its functionality into add
<abentley> davidstrauss: I would be.
<davidstrauss> abentley: but that would require changing how add works, fundamentally
<davidstrauss> abentley: A non-reference join is, from a user's perspective, a history-importing add
<jelmer_> davidstrauss: That would be a very bad idea imho
<jelmer_> davidstrauss: add makes a file versioned, it does not import history
<jelmer_> davidstrauss: What you are suggesting would make it import history
<davidstrauss> jelmer_: Currently, the docs define add as "Add specified files or directories." The distinction between making files versioned and merely joining a subtree with existing versioned files isn't made in the docs.
<davidstrauss> jelmer_: I'm not arguing we should make add behave the way I describe, I'm just throwing it out there.
<davidstrauss> jelmer_: Actually, the docs conflict with the behavior I demonstrated: "Therefore simply saying 'bzr add' will version all files that are currently unknown."
<davidstrauss> jelmer_: Though I guess that is the docs somewhat implying that the files aren't already versioned
<abentley> davidstrauss: It's previously been proposed that "add" would do "join --reference".
<pindonga> hi ppl . I am trying to build bzr-1.14, and I keep getting errors while building pyrex stuff... I don't know how to make them pass. I can build the extension using --allow-python-fallback, but when I do a build after that, I lose the prebuilt extension
<pindonga> how do I manage to build it completely? I am running centos 5 on a x86_64 arch
<jelmer_> pindonga: what errors are you getting?
<pindonga> when building bzr 1.14 using python2.5 setup.py build
<pindonga> I get 'Cannot build extension "bzrlib._chk_map_pyx"'
<pindonga> oh... I see the problem
<pindonga> I wasn't looking right
<pindonga> I am missing some dev headers (zlib.h)
<jelmer_> pindonga: installing the zlib development package should fix that
<pindonga> yes
<pindonga> thx
<Tak> he's like the third person today to ask about zlib.h
<pindonga> jelmer, it was just the missing lib, thx
<MattCampbell> Does anyone know what tools are required to build the Bazaar installer for Windows, and where to get the source file(s) specific to that installer?
<LarstiQ> MattCampbell: if http://bazaar-vcs.org/BzrWin32Installer is not up to date it should be adjusted (but I'll look around for something newer)
<Ddorda> hello. i want to use bzr with launchpad
<Ddorda> not sure how to login
<Ddorda> i did bzr launchpad-login Ddorda
<Ddorda> and got:
<Ddorda> bzr: ERROR: https://launchpad.net/%7EDdorda/%2Bsshkeys is permanently redirected to https://launchpad.net/~ddorda/+sshkeys
<beuno> Ddorda, have you uploaded your ssh key to launchpad?
<beuno> hrm
<Ddorda> i did
<beuno> abentley, any idea why bzr would do that?  ^
<Ddorda> but i think maybe i sent the worng data to the ssh key?
<abentley> beuno: Not offhand.
<abentley> Ddorda: Is your launchpad login actually Ddorda?
<Ddorda> right
<LarstiQ> instead of ddorda? (lower case)
<abentley> Ddorda: because it looks like it's 'ddorda'
<Ddorda> i will try it
<Ddorda> it's stuck on "B/s" when i do "ddorda"
<LarstiQ> Ddorda: it's not done? I'm expecting it to have returned you to the prompt.
<Ddorda> well, yea
<Ddorda> it done and write for me "B/s"
<Ddorda> weird
<Ddorda> and how do i check if i'm logged in?
<LarstiQ> Ddorda: `bzr launchpad-login` prints your launchpad login (username)
<Ddorda> great
<LarstiQ> Ddorda: I left a comment on bug #321935 about the leftover "B/s"
<ubottu> Launchpad bug 321935 in bzr "[master] Progress bar leaves artifacts in output" [High,Confirmed] https://launchpad.net/bugs/321935
<Ddorda> changed my status to affects me too
<Ddorda> well thanks for your help :D
<jelmer_> Tak: I think there was somebody working on noting the zlib dependency more prominently in NEWS
<beuno> mwhudson, feeling like a new release of Loggerhead?
<mwhudson> jelmer_: hi!
<jelmer_> mwhudson: Hi!
<mwhudson> beuno: mmm, yes, probably
<mwhudson> jelmer_: did you get my email?
<jelmer_> mwhudson: Yep
<jelmer_> mwhudson: I just got back from two weeks of travel so slowly catching up, expect a reply later tonight
<mwhudson> jelmer_: ok, great
<beuno> mwhudson, is there anything specific you want to hold off for?
<beuno> or should I start the machinery on the weekend?
<beuno> Peng?
<mwhudson> beuno: i'm not really sure, i can't think of anything
<jelmer_> beuno: Is start-loggerhead gone yet ? >-)
<mwhudson> beuno: perhaps scan the open bug list
<mwhudson> jelmer_: heh, no :/
<beuno> jelmer_, no  :(
<beuno> and it shouldn't be too hard to get rid of it
<mwhudson> beuno: i would like to wait a few days after 2.2.4 to see if the latest version helps much on launchpad
<beuno> I hate that I've hit a new record of "have no time"
<mwhudson> beuno: we should decide what version of bzr we target, test against that and rip out some of our compatibility code
<beuno> mwhudson, 1.14
<beuno> 1.13 was a bad one  :)
<beuno> would we break with previous versions?
<beuno> 1.13.2 is on the release PPA though
<mwhudson> beuno: well, i don't think we _probably_ mostly work back to 1.3 or something now
<beuno> so I don't know...
<mwhudson> uh!
<mwhudson> s/don't//
<beuno> 1.13 is is
<mwhudson> fair enough
<beuno> anything under that, unsupported
<mwhudson> there's definitely some crap we can remove
<beuno> yeah
<beuno> I added some of that  :)
<mwhudson> the "changes touching file" code, at least
<mwhudson> right :)
<beuno> was a fun first week of work
<LarstiQ> yay fun
<beuno> heya LarstiQ
<beuno> I realized today
<beuno> I can't bug you anymore about nested trees  :)
<beuno> after maybe 2 years
<beuno> big change for me!
<jdobrien> Anyone want to tackle this project killer: []
<jdobrien> Command failed!
<jdobrien> All lines of log output:["PQM Cannot merge between different VCSsystems. 'bzr+ssh://bazaar.ubunet/~jdobrien/ubunet/sms-valdate-new'(pqm.Baz1_1Handler) and 'bzr+ssh://bazaar.ubunet/~ubunet-pqm-team/ubunet/trunk'(pqm.Bazaar2Handler) are different."]
<LarstiQ> jdobrien: why is it using Baz1 handler?
<beuno> lifeless, up yet?  ^
<beuno> abentley?  ^
<jdobrien> LarstiQ: I am not
<Ddorda1> there is anyway to check if there's any updates automaticly?
<jdobrien> bzr115dev
<abentley> beuno: The baz1 handler is used if no bazaar branch can be opened.
<jdobrien> the branch exists
<abentley> jdobrien: What format is it in?
<jdobrien> 1.9
<abentley> Do its revisions show up in the LP UI?
 * jdobrien checks
<LarstiQ> Ddorda1: I'm not sure what you mean with automatically, are you thinking of something like `bzr missing` ?
<abentley> jdobrien: Are you sure bazaar.ubunet is a real domain?
<jdobrien> abentley: I've landed 4 branches using the same command (only branch name different) today
<abentley> jdobrien: But the branch name appears to be significant here.
<Ddorda1> i mean if there's any way to announce me when there is an update
<Ddorda1> to a bzr
<jdobrien> hmm
<jdobrien> abentley: I see version history in lp
<abentley> jdobrien: Are you sure that branch name is right?  bazaar.ubunet does not look like a real domain.
<jdobrien> abentley: what is it that appears incorrect?
<abentley> bazaar.ubunet
<jdobrien> abentley: it is correct...PQM had it in it's ssh config
<jdobrien> abentley: we are having issues with developers using different version of bzr on our project
<jdobrien> abentley: for example, some have had to use nosmart+ to pull branches
<abentley> jdobrien: What URL are you using to look at the LP history?
<LarstiQ> Ddorda1: the bazaar-announce mailing list gets mails for release candidates and final releases, as well as mail for bzrtools and others.
<LarstiQ> abentley: https://code.edge.launchpad.net/ubunet I suppose
<jdobrien> abentley: https://bazaar.launchpad.net/~jdobrien/ubunet/sms-validate-new/changes/1271?start_revid=1271
<Ddorda> abentley: and where can i subscribe to this?
<jdobrien> abentley: it is a private project
<LarstiQ> Ddorda: https://lists.ubuntu.com/mailman/listinfo/bazaar-announce
<abentley> jdobrien: given that it's hosted on Launchpad, I would recommend using its launchpad location.  But another problem is that you omitted the 'i' in validate.
<jdobrien> abentley: sorry to have wasted your time :-)
<Ddorda> if i change something in the code, does the bzr know how to edit the file without removing what i change?
<Ddorda> LarstiQ: but this will announce me when there's a new release of bazaar, no?
<Ddorda> i want to know if there's a option the the bzr will announce me about a project code update (not the bzr)
<LarstiQ> Ddorda: if you bzr pull it will merge the new file contents with your local changes
<LarstiQ> Ddorda: that mailing list is low traffic, only for new releases of bzr related software in practice
<Ddorda> "bzr pull" you say?
<LarstiQ> Ddorda: if that is not what you meant with `bzr know how to edit the file` I do not know what you had in mind
<Ddorda> okay. thanks
<jdobrien> statik: we have a crap load of people with dead status
<LarstiQ> jdobrien: swine flu?
<jdobrien> dang wrong window
<jdobrien> channel
<jdobrien> LarstiQ: :)
<jdobrien> i need to stop working 18 hour days
<mwhudson> spiv: have you fixed bzr.dev yet?
<BasicOSX> API mismatch is my fault
<abentley> BasicOSX: Are you bob tanner?
<BasicOSX> yes
<abentley> BasicOSX: Okay, correction to my email, 1.14 is *probably* the right setting.  lifeless probably has a clearer idea.
<beuno> BasicOSX, rockin' job at release management, btw  :)
<BasicOSX> beuno:  thanks
<BasicOSX> abentley:  I'll wait for clarification on it and will update release docs
<abentley> BasicOSX: The question is just what kind of API change makes it incompatible.  I miss the old API breaks section.  That made it clear whether API compatibility had been broken.
<BasicOSX> Compatibility Breaks section does not include API breaks?
<BasicOSX> I see in 1.14 API Changes section, but I would +1 your RFC for API breaks section :-)
<BasicOSX> Would make RM job easier
<abentley> BasicOSX: then again, bzr 1.14 requires Branch.open implementations to accept an "ignore_fallbacks" parameter, and that's not even mentioned in API changes.
<epsilon_0> i use bzr all the time with LP, and this morning i got this error when trying to bzr push:
<epsilon_0> Socket exception: Connection reset by peer (10054)
<epsilon_0> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10054, 'Connection reset by peer')
<beuno> epsilon_0, did you retry?
<epsilon_0> yes
<epsilon_0> 4 times
<beuno> epsilon_0, can you try by adding the -Dhpss flag?
<epsilon_0> whay does it do?
<epsilon_0> *what
<beuno> epsilon_0, it's a debug flag
<beuno> that will give us more information
<epsilon_0> ok
<epsilon_0> one second
<epsilon_0> says connected
<epsilon_0> then halts
<epsilon_0> now im waitin
<beuno> epsilon_0, ~/.bzr.log
<beuno> will have a lot of information
<epsilon_0> and in windows?
<beuno> uhm
<beuno> I don't know   :)
<epsilon_0> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10054, 'Connection reset by peer')
<epsilon_0> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x017EE5F0>
<epsilon_0> ill try to find .bzr
<thumper> epsilon_0: what else has changed on your machine?
<epsilon_0> ohh.. now i got u... .bzr in the local project dir
<epsilon_0> hm. i guess i didnt,
<epsilon_0> i can't find .bzr
<garyvdm> epsilon_0: .bzr.log is in My Documents on windows
<epsilon_0> ok
<epsilon_0> what do u want me to post
<beuno> epsilon_0, can you pastebin the last 20 lines?
<epsilon_0> ok
<epsilon_0> http://cl1p.net/i_want_bzr_back/
<beuno> interesting...
<beuno> lifeless, spiv, any ideas  ^
<epsilon_0> guys, i have to go, will u be around here tomorrow?\
<beuno> epsilon_0, sure
<beuno> you could file a bug
<beuno> with .bzr.log attached
<epsilon_0> : (
<epsilon_0> so i can't commit my project until the bug is fixed?
<garyvdm> epsilon_0: please pastebin the whole file. I don't think the bit you pasted is relevant
<epsilon_0> ok
<garyvdm> beuno: The log bit there is all from tbzr.
<beuno> garyvdm, ah
<beuno> :)
<epsilon_0> on sec
<epsilon_0> http://download.cl1p.net/i_want_bzr_back/?t=382895686&FILE=46755
<epsilon_0> there
<spiv> beuno, epsilon_0: "connection reset by peer" suggests that SSH is the problem, not, bzr.
<beuno> hi spiv
<epsilon_0> what could it be, i didn't changed a thing
<garyvdm> is pant? running
<epsilon_0> pant?
<garyvdm> can't remember what it's called
<epsilon_0> lol
<epsilon_0> pageant
<garyvdm> thats it
<spiv> epsilon_0: I see from the error code (10054) that you're on windows... how do you have ssh configured?
<epsilon_0> as usual with putty
<epsilon_0> its not the first time i commit, i commited 30 times before
<spiv> Huh, that traceback in the logfile suggests it's trying to use paramiko, not putty.
<epsilon_0> paramiko, i dont know what that it
<epsilon_0> bzr might me trying to use it :) not me
<spiv> :)
<spiv> epsilon_0: bzr uses putty if it can run 'plink -V' successfully.
<spiv> epsilon_0: if it can't, it will be falling back to putty.  I suspect a problem with your %PATH%
<epsilon_0> hmm
<spiv> You can set the BZR_SSH environment variable to 'plink' to force it to try use it, but if the autodetection can't find plink then that probably won't help.
<epsilon_0> plink is not recgninzed
<epsilon_0> should i add it to path?
<spiv> epsilon_0: yes, I think so.  I'm not an expert on configuring Windows though...
<spiv> mwhudson: no, I haven't.  Subscribe to the bug report :P
<epsilon_0> oh
<epsilon_0> i found the problem
<epsilon_0> it seems the bzr installation on Windows adds a shortcut called "start bzr in command prompt"
<mwhudson> spiv: pfft
<epsilon_0> which opens the shell with different env. vars.
<epsilon_0> i normally didnt use it
<spiv> epsilon_0: ah.
<epsilon_0> i did use it to open the shell this time
<epsilon_0> hmm, now i get somehthing else
<epsilon_0> but i think i can handle this on my on from here
<epsilon_0> thanks guys
<awilkins> putting plink on the path is helpful
#bzr 2009-04-30
<garyvdm> lp offline :-( - Good thing I can commit to my VCS localy :-)
<lifeless> beuno: lp is down?
<beuno> lifeless, yes, roll out, etc
<beuno> read only didn't work
<beuno> so it should down... 40min?
<lifeless> beuno: I know, you asked for ideas, I'm giving you one.
<beuno> lifeless, I did?
<beuno> it's been a long day
<lifeless> 08:03 < beuno> lifeless, spiv, any ideas  ^
<beuno> :)
<rconan> hello... why does bzr commit try to connect to a remote server?
<rconan> I thought commit was to update the local repository from the working tree
<beuno> rconan, you probably did a checkout?
<beuno> instead of a branch?
<rconan> ah...
<rconan> that makes sense
<beuno> you can --reconfigure it into a branch
<bob2> or bzr unbind
<rconan> I assuem that requires the remote repo to be there...
<bob2> no
<rconan> so how do I make it into a branch?
<bob2> checkouts are by default heavy (i.e. contain the entire branch history)
<rconan> $ bzr reconfigure --branch
<rconan> bzr: ERROR: Working tree "/home/conan/work/sysint/" has uncommitted changes.
<bob2> then commit them
<bob2> or shelve them
<beuno> well
<rconan> but... I can't commit because the remote repo isn't there
<bob2> commit --local
<rconan> ok I did reconfigure --branch now
<rconan> now it says no working tree exists...
<rconan> how do I create one?
<garyvdm> rconan: huh ^ - can you pastebin bzr info
<garyvdm> did you commit --local or shelve your changes?
<rconan> http://pastebin.com/f6e6fa4ef
<rconan> I shelved them
<garyvdm> ok - "bzr checkout" to recreate the working tree
<Peng_> beuno: Releasing Loggerhead sounds good to me. Hmm, should the Dozer memory profiling thing get in? Does it matter?
<rconan> $ bzr unshelve
<rconan> bzr: ERROR: No changes are shelved.
<rconan> hmm...
<rconan> what happened to them?
<beuno> Peng_, did it not get it?
<Peng_> beuno: It got approved, but nobody ever merged it.
<beuno> Peng_, can you?   :)
 * beuno abuses Peng_'s awesomeness
<Peng_> Heh, okay.
<Peng_> Although I never tested it since I don't have all of Dozer's dependencies installed.
<Peng_> And LP is down.
<garyvdm> rconan: I just tested - and reconfigure --branch causes the shelves to be lost
<beuno> Peng_, as long as LH runs, it's fine
<garyvdm> beuno, rconan: The command you were looking for is bzr unbind
<garyvdm> rconan: What fs are you using? any undelete options?
<rconan> garyvdm: doesn't matter
<rconan> I used the patch outputted from shelve to apply them again
<rconan> sorted now
<rconan> hoorah
<rconan> thanks for the help guys
<garyvdm> That could have been a lot worse....
<garyvdm> Why does reconfigure --branch kill the working tree?
<garyvdm> lp back up :-)
<spiv> garyvdm: because that's what it is defined to do, see "bzr help reconfigure"
<Peng_> Oh, LP is back up? Um, d'you mind if I don't take care of the Dozer thing for an hour or two?
<beuno> Peng_, any time is good
<beuno> thanks
<beuno> :)
<beuno> I'm off home now!
<spiv> garyvdm: bzr reconfigure --tree is probably what was wanted.
<spiv> (I don't much like the labels that reconfigure uses)
<garyvdm> spiv: reconfigure --branch should stop if there are shelves then.
<spiv> garyvdm: yeah, probably.  File a bug? :)
<lifeless> remove-tree should error too
<lifeless> without force
<lifeless> same root cause I imagine
<lifeless> spiv: 4 outstanding branches; I'm changing tracks while review catches up
<igc> morning
<Peng_> beuno: ping?
<Peng_> beuno: I was just working on merging dozer, and when I run with --memory-profile now, Ctrl+C doesn't cause the process to fully exit anymore, so I'm not going to merge it yet.
<mwhudson> how insane/hard would it be to access bazaar branches over the plain sftp protocol?
<mwhudson> (i.e. without ssh being involved)
<spiv> mwhudson: not so hard, probably.
<spiv> mwhudson: the bzr test suite may already do that?
<Peng_> mwhudson: Oh, hi! Can I bug you about Loggerhead? :)
<mwhudson> Peng_: sure
<Peng_> mwhudson: See above what I said about Dozer. Does it work for you? Do you still think it's okay to merge with that issue?
<Peng_> Especially since it's probably not a bug in Loggerhead.
<mwhudson> spiv: i'll have a look
<mwhudson> Peng_: mm, probably
<mwhudson> Peng_: i mean, i hope noone enables dozer in production :)
<Peng_> Heh.
<mwhudson> Peng_: it would be bad if this branch meant that you had to have dozer installed to run loggerhead at all
<Peng_> mwhudson: You only need Dozer installed to run with --memory-profile.
<mwhudson> Peng_: cool
<Peng_> mwhudson: So, you think I should still merge it?
<mwhudson> Peng_: yeah
<Peng_> OK.
<Peng_> Done.
<Peng_> Do you mind if I file a bug to follow up on my Ctrl+C issue?
<mwhudson> Peng_: that sounds like a good plan
<Peng_> OK.
 * igc offline for a few hours - bbl
<spiv> mwhudson: at a glance, you could make a subclass of SFTPTransport that overrides _create_connection to do something other than use "vendor = _get_ssh_vendor(); ... ; vendor.connect_sftp(...)"
<spiv> mwhudson: probably call it PlainSFTPTransport and register it as plainsftp:// or something?  Do you want it to talk via TCP or perhaps via pipes to a subprocess?
<mwhudson> spiv: tcp
<mwhudson> spiv: the motivation is wanting to run the bzr serve processes on a different box to that which stores the branches for launchpad
<mwhudson> spiv: so we can scale # of concurrent connections by plugging in more boxes
<jml> bzr 1.14 network performance is pretty schmick guys -- well done
<lifeless> good
 * jml tries some pushing experiments.
<jml> lifeless: no-op push to a stacked 1.9 branch is ~12s from here, ~5s for 'bzr ping'.
<spiv> no-op push has been pretty good for ages now :P
<spiv> Hmm, to a stacked branch though...
<jml> yeah.
<lifeless> jml: thats still kinda slow
<lifeless> spiv: likely opening the stacked on branch
<jml> lifeless: yeah, kind of slow -- 14hpss calls
<jml> lifeless: but a lot better than I recall.
<jml> and all the hpss numbers are small
<jml> hmm. HPSS calls: 66 in ~46s for pushing a new stacked-on branch.
<jml> stacked, rather.
<lifeless> jml: thats high
<lifeless> jml: lots of get_parent_map ?
<jml> yeah.
<jml> lifeless: only 4.
<lifeless> oh
<lifeless> any vfs calls?
<jml> lifeless: more stats & gets than I would have expected -- want a copy of the log?
<lifeless> jml: oh, lp is still running 1.13 right?
<jml> lifeless: nope.
<jml> lifeless: 1.14rc2
<jml> hmm.
<lifeless> yes, a log would be good then; I would have expected VFS free push
<lifeless> you have plugins that might be triggering vfs calls?
<jml> sent.
<jml> lifeless: bzrtools, imapclient, loom, ping, pqm, stats.
<lifeless> 11.029  hpss call:   'BzrDir.get_config_file',
<lifeless> '~jml/launchpad/has-linked-branch/'
<lifeless> 11.029               (to
<lifeless> bzr+ssh://bazaar.launchpad.net/%7Ejml/launchpad/has-linked-branch/)
<lifeless> 11.372     result:   ('UnknownMethod', 'BzrDir.get_config_file')
<lifeless> upgrade your server :)
<jml> lifeless: as in, you think our server is not running 1.14rc2 as advertised?
<lifeless> no
<lifeless> 1.15 removes more VFS
<jml> lifeless: ahh, ok.
<jml> lifeless: well, given that Bazaar hasn't quite managed to release 1.14 yet, I might wait a little before upgrading to 1.15 :)
<spiv> jml: huh?  1.14 is out.
<jml> oh, I must have missed the announcement to the mailing list.
<spiv> Yes, you must have.  :P
<spiv> (not to mention the topic in this very channel)
* jml changed the topic of #bzr to: Bazaar version control system | 1.14 released 29 April, 2009 | 1.13.2 released 28 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<jml> spiv: I can explain that!
<jml> spiv: my eyes stopped when I saw "1.13.2 released"
<nok5> i changed the path of a branch, when I do bzr pulling, it will say: Parent not accessible given base blah blah.., should I rebase or reconfigure the branch?
<lifeless> nok5: just give it the full url to pull from
<lifeless> and add --remember
<nok5> still the same error with url to pull
<lifeless> thats odd
<lifeless> can you run with -Derror and pastebin the output please
<nok5> even bzr info yields the same erro
<nok5> the output is here http://padfly.com/bzr
<lifeless> thats not for pull
<nok5> ok
<nok5> sorry, updated, please refresh
<lifeless> ok
<lifeless> definitely a bug
<lifeless> look in .bzr/branch/branch.conf
<lifeless> edit that file to give it the correct path
<lifeless> and I'll file a bug
<nok5> ok, thank you
<nok5> solved
<nok5> lifeless: the bug link pls
<lifeless> nok5: don't have it yet - i filed by email
<lifeless> https://bugs.edge.launchpad.net/bzr/ will have it soon
<nok5> roger that
<BullHorn> Hi there, Iá¸¿ new to bzr, I installed bzr on windows. I created a folder on external drive and want to check files into it from a folder on my c:. tortoise just allow checkout. Any Idea how to do this. Iá¸¿ only used to cvs & svn
<bob2> there's a tortoise thing for bzr, dunno how complete it is
<nok5> BullHorn: you mean only checkout is allowed in c:. tortoise ?
<BullHorn> Ok, I've a download folder on c:. I created a download folder on external. I initialized folder on the external drive and want to move or add the files from the c:/download to the external download. But want to use bzr for eas of use. I need to make space as I want to install linux on my laptop as well
<BullHorn> I thought it will be better to manage the folder with bzr that just to copy it across
<davidstrauss> BullHorn: TortoiseBzr works reasonably well
<BullHorn> how do I book/ add it to the repositry or do I need to copy it across and then just let TortoiseBzr init the folder?
<davidstrauss> BullHorn: I don't actually use it myself, but I'm pretty sure it just magically works on your checkouts and branches
<nok5> BullHorn: it seems what you want is just copy/sync files on C drive to your bzr repo on external drive. but i dont know how can it help to save the space. you may init the original folder as shared repo, then setup a branch on your external drive
<BullHorn> the idea is to have the external as the parent repositry. I only want to pull what I need. the rest I'll delete on my c:. BUT if someone else add a file/folder to that repositry I want to be able to see it. I know you're suppose to use it with source but sometimes one want to use it with any files. I'm trying to figure out how the distributed vcs model works.
<nok5> BullHorn: yes, you can cherrypick (see user guide) from external folder to your c drive
<lifeless> BullHorn: the way it works is that you have many branches
<lifeless> BullHorn: you can push or pull from each
<lifeless> BullHorn: what you want to do is to get up and running with your current folder in bzr, then *push* it to your external drive for backup
<lifeless> 'checkout' is for wrking like cvs or svnw here your branch is somewhere else, and every 'commit' is immediately propogated
<lifeless> spiv: ping
<lifeless> spiv: reviews plox
<lifeless> nok5: bu 369619
<lifeless> nok5: bug 369619
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/369619/+text)
<nok5> lifeless: i've already subscribed, thanks for your notice
<mwhudson> Source format does not support stacking, using format: 'Remote BZR Branch'
<mwhudson> not so good :)
<BullHorn> Iâm going to leave it for now. Iâm just frustrating myself even more on this windows platform while I want to move to Linux asap. Itâs not working like TortoiseSvn yet. By the way will bzr logs a directory that has been added?
<lifeless> yes
<spiv> lifeless: plox?
<spiv> (I can guess what you mean, but I'm curious to know precisely...)
<gotgenes> How does one list all files tracked by a bzr branch?
<thumper> `bzr ls` I think
<gotgenes> thumper: ah
<gotgenes> I was trying bzr list
<thumper> `bzr help ls` would help
<thumper> not recursive by default
<thumper> and -V for versioned files
<thumper> bzr ls -VR for all versioned files
<gotgenes> hmm, I'm not sure if I understand what a "Versioned" file is compared to what's output by default via bzr ls.
<lifeless> gotgenes: a versioned file is one that bzr is tracking
<lifeless> gotgenes: an unversioned file is one that bzr is not tracking
<gotgenes> lifeless: I see. So by default, bzr ls does, simply, ls?
<lifeless> roughly yes
<gotgenes> Hmm.
<lifeless> ls -RV will list all the versioned files in the tree recursively
<gotgenes> lifeless, thumper: Thanks.
<gotgenes> Okay, so next question. I have a symbolic link that I need to remove, but bzr remove gives "ERROR: Not a branch"
<gotgenes> It's following the symlink
<lifeless> just rm it
<lifeless> then bzr rm the path it had
<lifeless> we have a bug open on symlink friendliness
<gotgenes> lifeless: Indeed, some more clever searching got me to the trail of bugs on LP.
<gotgenes> Hmm, this could be more troublesome because I actually want to retain the symlink.
<gotgenes> And it's actually many symlinks
<gotgenes> I guess I should script this.
<lifeless> python -c 'import bzrlib.workingtree; t= bzlib.workingtree.WorkingTree.open(".").unversion(path)'
<lifeless> ^ workaround
<gotgenes> lifeless: No kidding? Ooh! Let me play with that.
<igc> back
<gotgenes> lifeless: Any suggestions on how to check whether or not the file is versioned in the first place using the WorkingTree?
<lifeless> gotgenes: tree.path2id(path) is None -> not versioned
<gotgenes> lifeless: sure enough
<gotgenes> Thanks
<gotgenes> Is there an os.walk equivalent in the WorkingTree, actually?
<gotgenes> Hmm, there's a WorkingTree._walkdirs()
<gotgenes> lifeless: ah, it seems unversion accepts file_ids, not paths.
<gotgenes> Ah, shoot, walkdirs() (sans underscore) does exactly what I want.
<lifeless> gotgenes: path2id will get you ids
<gotgenes> lifeless: yeah, it looks like walkdirs() will get me all I need to detect all symlinks and get their ids, actually
<gotgenes> the only problem is it's complaining the working tree is not locked
<gotgenes> hrumph
<lifeless> tree.lock_write()...finally: tree.unlock()
<gotgenes> lifeless: You're helpful and a half.
<gotgenes> lifeless: Your profile image on LP is amusing.
<lifeless> :>
<gotgenes> I actually saw it first
<Peng_> Hey, that's clever!
<gotgenes> then was like, "Why the hell... Oh, I wonder if he's in the Southern Hemisp..." Then I looked at the map.
<vila> hi all
<gotgenes> vila: Hello.
<lifeless> gotgenes: :)
<gotgenes> lifeless: How long have you lived in Sydney?
<lifeless> ~13 years
<gotgenes> lifeless: Wow, that's a good stretch.
<gotgenes> Were you previously in Australia?
<gotgenes> Also, thanks for taking a look at my bug report. Was poking around that part of the code and just wasn't sure, but figured a report wouldn't hurt.
<lifeless> no worries
<lifeless> I'm originally from NZ
<gotgenes> lifeless: Really?
<lifeless> yup
<gotgenes> lifeless: I must get out to that region of the globe some day
<gotgenes> let "some day" <= 4 years
<lifeless> :)
<gotgenes> lifeless: Do you work for Canonical now?
<lifeless> yes I do; I have since the start
<gotgenes> lifeless: start being graduation?
<gotgenes> or start of the company?
<Peng_> Since the start of TIME.
<gotgenes> Wow
<gotgenes> That's epic.
<gotgenes> That's like, Chrono Trigger epic.
<lifeless> technically since before incorporation - I was one of the first employees when Mark started on this venture
<gotgenes> lifeless: Neato. How did you get tapped or find out about it?
<lifeless> I was a significant contributor to GNU Arch
<bob2> and author of barch!
<lifeless> bob2: heh; that didn't go far - Tom's translation of larch to C met my porting needs
<gotgenes> I guess I don't know my history of Bazaar. I should search to find out if it existed before Canonical.
<gotgenes> Seems not.
<gotgenes> 2007 vs 2004
<bob2> canonical was founded in 2004
<bob2> bzr (aka bazaar-ng) in 2005
<lifeless> http://bazaar-vcs.org/HistoryOfBazaar
<lifeless> I like how john says I was 'probably the leader' :P
<lifeless> can be hard to tell in meritocracies ;)
<gotgenes> lifeless: Haha
<lifeless> Mark and I called the project Bazaar; I've probably got the IRC log of the decision somewhere
<lifeless> later all
<gotgenes> lifeless: night
<AntoineLafontain> I have a question about merging branches... is there anyone here that would have some time to spare? Thanks
<spiv> AntoineLafontain: sure, what's the question?
<AntoineLafontain> I have a question concerning merging a branch with a branch where files have been removed... is there a way to ignore some files from the parent branch so that no conflicts needs to be resolved on those removed files/folder. Or maybe someone could enlighten me on how I should think about this problem in order to solve my issue. I hope this is the right place to ask those kind of questions, thanks for your time.
<AntoineLafontain> and I have to say I have limited experience with versioning...
<bob2> you can't just fix the conflict after the merge, before the commit?
<spiv> AntoineLafontain: there's not really any way to ignore parts of a merge, but dealing with the conflicts shouldn't be hard.
<spiv> AntoineLafontain: the closest to ignoring parts is to do the merge and then selectively revert the files you didn't want to change.
<AntoineLafontain> it's not hard, but it's just all the same files all the time... it just feels redundant to do this every time I merge with the parent, since those files I removed voluntarily.
<AntoineLafontain> I see, there's no 'convenient' way to just have those 'auto resolve' or something... i'll just write a script to have those files always revert after a merge...
<AntoineLafontain> how do people go about when they branch from a remote project and then just want to work with a part of it, or remove part of it but still be able to merge back changes made to the remove repository back to the part they work with?
<AntoineLafontain> Maybe I'm thinking this the wrong way, but I feel this would be a pretty common thing.
<spiv> There's not (yet) support for breaking a tree into smaller trees.
<AntoineLafontain> this would be a convenient tool isn't it?
<spiv> Normally if you expect people to work on parts separately you'd make different branches for those parts.
<AntoineLafontain> I see
<spiv> Or, more usually, just not worry about it.  For many projects the wasted disk space and bandwidth is pretty insignificant.
<spiv> i.e. not delete the files at all.
<AntoineLafontain> I see. I'm more concerned about some files I do not want to upload when using bzr upload
<spiv> There's work to make this more convenient, part of something called "filtered views".
<spiv> Ah, sounds like a feature to add to bzr upload then.
<AntoineLafontain> That could also be a way to go
<spiv> bzr upload currently assumes you want to upload the whole tree I think, but an exclude list sounds like a reasonable feature for it.
<AntoineLafontain> if upload could keep a black list
<AntoineLafontain> yeah, I feel it basically would be better if a merge would consider the ignore list in the child branch...
<AntoineLafontain> then upload could be kept simple... upload all and it's all good
<spiv> The existing ignore list is purely about what "bzr status" and "bzr add" will do.
<AntoineLafontain> yeah, I've tried it a few times to 'experiment'
<spiv> It intentionally has no effect on files that are versioned (even if their file name matches).
<AntoineLafontain> or a an option when using remove to keep a special 'flag' if a user would set it to ignore a folder / files when set
<spiv> bzr upload is a pretty basic mechanism for code deployment, though.
<AntoineLafontain> well I wouldn't say I have a complete understanding of what versioning is all about, my background is more into design than coding, but for my own sanity, I would like to have some kind of way to do this and once done not have to think about it everytime I merge with the parent repository
<AntoineLafontain> but I have to say thanks for the insights, it does confirm that I wasn't completly off track when thinking there's no way to achieve this presently
<spiv> Yeah, you shouldn't need to repeat work.
<spiv> You're welcome, glad I could help.  I think a feature request for bzr-upload is probably the best option.
<spiv> (Or perhaps just use rsync?)
<AntoineLafontain> yeah, rsync i prefer over bzr upload... how can I use rsync to achieve what I want?
<AntoineLafontain> and sorry for my 'basic' questions :)
<spiv> Use the --exclude option
<AntoineLafontain> can eclude be used with a file listing the files/folders I want to exclude (only used the command line in the past for oomiting a file or two...)
<AntoineLafontain> hmm I think I'm starting to see a decent solution now...
<spiv> AntoineLafontain: yes, rsync has an --exclude-from=FILE option too
<spiv> AntoineLafontain: read the man page :)
<AntoineLafontain> yes, I just did it while writing...
<AntoineLafontain> thx for your patience... it's not often I have someone to just talk about those things around the office -designers hate command line based tools... I'm seen as a freak around the office...
<AntoineLafontain> thank you again for your time spiv.
<vila> AntoineLafontain: sorry for coming late in the game, but yes, bzr-upload should allow uploading a partial tree, this is a known limitation
<AntoineLafontain> should? shouldn't
<AntoineLafontain> ?
<vila> whether this will be achieve by using a filtered view or a by a mean specific to bzr-upload has not yet been decided :)
<AntoineLafontain> ah! okey, just read you better
<AntoineLafontain> well my own guts tell me, if possible, it would be 'cleaner' to be able to remove files in a branch and still be able to merge from the parent while ignoring some files/folders from the parent
<AntoineLafontain> then bzr-upload would just upload the filtered tree
<AntoineLafontain> maybe there's other considerations that I can't fathom...
<vila> AntoineLafontain: it's better to version a whole project and then upload only part of it.
<vila> For example, if you have tests, you may want to *not* upload them, yet, you *want* to version them in sync with the code you're testing
<AntoineLafontain> well the whole project is keep in the parent branch... the sub branch is my 'filtered' project... removing parts from the parent before publishing
<AntoineLafontain> allowinf to keep the core intact, complete, but making possible to update the child when the core is updated, modified, but only in the parts that are kept in the child... does this make sense?
<vila> AntoineLafontain: in that case, nested trees will be more appropriate than filtered views, both are actively being worked on at the momemt
<LarstiQ> AntoineLafontain: I fail to see why you would do that?
<vila> AntoineLafontain: yes, that makes sense
<AntoineLafontain> the core is a project that I do not maintain...
 * LarstiQ scrolls up for more context
<AntoineLafontain> so I just update it when there's updates to it and so on.
<AntoineLafontain> but I want to clean up some of the files from it, but want to be able to automate the update process for projects spawned from the core
<AntoineLafontain> vila> could I ask for a bit more insight on nested threes and filtered views?
<AntoineLafontain> or some links?
<vila> AntoineLafontain: hmm, so you want both a nested tree (for your sub branch) and a filtered view to upload only the relevant files
<AntoineLafontain> possibly... I'm not sure what is needed... but if possible I would like to have the workflow I described... or a good idea on a better workflow
<vila> AntoineLafontain: I think your description fully makes sense, as well as your workflow, but not all the bits are in place in bzr for your exacts needs :-/
<AntoineLafontain> the filtered view it seems I could manage with rsync --exlude-from and keeping a versioned exclude file for each projects
<LarstiQ> I'm glad vila sees it, because I don't :)
<AntoineLafontain> well sub-projects if I follow my own logic
<vila> LarstiQ: say you have a branch with 'web-site' as a nested tree and additionally 'web-site' contains some password file, you want to upload 'web-ste' minus passwd
<vila> AntoineLafontain: Is the above a correct approximation of your needs ?
<LarstiQ> vila: fair enough, but why can't that be done as a bzr-upload feature?
<vila> LarstiQ: Ooooh it can !
<LarstiQ> vila: and if you don't want it in your regular tree, why isn't `bzr rm; bzr ci; bzr merge` enough?
<AntoineLafontain> well simply put, it's to be able to work with the drupal project and then have a branch with a selection of contrib modules, then from that branch would spawn the real projects
<AntoineLafontain> but each project would not have all the same module selection, but for convenience and upgrade, I would like to keep all the main modules I use in one branch
<vila> LarstiQ: sounds a bit too much like reverting some decisions may be harder than it should
<AntoineLafontain> and keep my custom code in the 'projectX' branch
<AntoineLafontain> so updating core would meaning merging it in the module branch, then in all the sub projects
<AntoineLafontain> updating a module would mean only updating the projects
<AntoineLafontain> or I'm just making this just all too complicated for nothing...
<vila> AntoineLafontain: exactly what nested trees are about, using one of them for each module and composing higher level projects from them
<AntoineLafontain> thx vila, sounds like my reasoning wasn't too far fetched
<vila> AntoineLafontain: track http://bazaar-vcs.org/NestedTreeProgress
<LarstiQ> AntoineLafontain: right, that sounds like nested trees
<AntoineLafontain> and this is not yet supported?
<vila> AntoineLafontain: this is currently, actively, working on and should be available shortly
<LarstiQ> AntoineLafontain: the split and join commands exist, by-value trees have been in bzr for a long time, by reference is receiving active developement
<vila> AntoineLafontain: how many modules do you handle so far ?
<AntoineLafontain> humm, I'll say i have a selection of about 15 to 20?
<AntoineLafontain> which I do not use in all projects
<AntoineLafontain> now I basically keep those in a normal folder
<vila> ok
<AntoineLafontain> and cherry pick the ones I want for project X and those for project Y and so on
<AntoineLafontain> I'm actively trying to figure out a decent workflow using versioning and trying to automate many of those redundant tasks
<AntoineLafontain> and I have to say that bazaar as been impressively easy to pick up for the basics, but I got stumped when trying to achieve the pattern I'm talking right now
<vila> AntoineLafontain: right, so nested trees sounds like the silver bullet for that and filtered views (or a closely related mechanism) should address the upload part
<AntoineLafontain> I will try to take some time to read about those nested threes and see if I can wrap my head around those
<vila> roughly, in your case, it will mean updating your project and automatically get your modules updated
<AntoineLafontain> sounds like I get to eat the whole pie after all ;P
<AntoineLafontain> thanks for all your insights!
<vila> AntoineLafontain: you're welcome, don't hesitate to come back and share your experiments or other thoughts
<AntoineLafontain> will do.
<AntoineLafontain> vila> I hope you're still around.
 * igc dinner
<AntoineLafontain> I've read about split and was wondering If I got it right. Basically, using split, I can make a subfolder of a branch an independent branch on its own. What I'm wondering is, what will happen to the splitted branch if the original branch is merge to its parent branch, which is a remote branch... wouldn't this cause a conflict since the split doesn't exist in the parent branch?
<LarstiQ> AntoineLafontain: in the container where you split the subbranch out, everything in that subdir is deleted from that point on.
<dlee> bzr log --long shows timestamps with -0400, but I'm on US Eastern time, which is -0500 afaik.  The time is the correct local time.  Where should I look for the cause of this?
<LarstiQ> AntoineLafontain: so if you merge it into something else, you'll get a series of deletions merged.
<LarstiQ> dlee: looking through bzr.dev log, the timestamps vary.
<AntoineLafontain> larstiq> I'm not sure I understand the implication of this
<LarstiQ> dlee: so it seems more to do with the time of recording than displaying.
<LarstiQ> AntoineLafontain: if you can rule out merging it into the parent, that would make life simpler.
<LarstiQ> AntoineLafontain: that, or propagating the split to the parent.
<dlee> Not sure I understand.  The time shown is the correct commit time, shown as local time; but the -0400 makes it look like it was recorded with the wrong timezone.  Makes me think I should offset the time I see by an hour to get local time of commit, but that would actually be wrong.
<Kinnison> Is it doing that on fresh commits you're doing now?
<dlee> Yes.  I have v1.10 on this box though.  I can try in a later version on another box if that would help.
<AntoineLafontain> then... lets say theres a parent branch A, I make a local branch of it A'... I want to keep the ability to update A' with any changes made to A (using merge?) but I want to add some files inside a folder of A' and be able to maintain seperate threes of tose subfolders too (each folder is a module added to the core A project). Then I wan to be able to make a B project which will be based on A' plus a selection of modules put ins
<Kinnison> and if you type 'date' in at a terminal, does it show the right timezone?
<dlee> Just did: v1.13.1, on MacOS via MacPorts.  Time stamp of just-committed commit: "timestamp: Thu 2009-04-30 05:09:23 -0400"
<dlee> Current time: 5:10 EDT (-0500 I think).  I wonder if this is a daylight savings thing or somesuch.
<AntoineLafontain> In the nested three design document there's the 'Composite tree' description that would maybe suit what I want to achieve...
<LarstiQ> AntoineLafontain: truncated at 'of modules put ins'
<AntoineLafontain> a selection of modules put inside A' and some custom code/config files which are only related to B...
<AntoineLafontain> sorry
<dlee> date result on Mac: Thu Apr 30 05:11:44 EDT 2009
<LarstiQ> dlee: and `date -u`?
<dlee> date -u: Thu Apr 30 09:12:40 UTC 2009
<LarstiQ> dlee: it looks like the correct time to me.
<LarstiQ> dlee: you're at -4 at the moment.
<dlee> Then I'm probably being confused by Windows... Windows says we're five hours off of UTC.  Are we 4 hours off at this time of year maybe?  Hmm... I guess the Windows-displayed offset never changes.  Somehow I thought this one would embarrass me. :)
<gotgenes> lifeless: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html
<ronny> sup
<ronny> LarstiQ: who do i need to bug if i need a range of older bzr's to be easy-install-able a gain
<james_w> what makes them uninstallable?
<ronny> james_w: easy-install wont find any version but the latest, most likely due to missing links in the related http pages
<ronny> oh, and can someone please point me to a wiki page/documentation listing the api changes since bzr 1.0
<LarstiQ> ronny: I'd look at NEWS for that
<LarstiQ> ronny: the easy_install issue is that specific releases at pypi have no download link? Like, http://pypi.python.org/pypi/bzr/1.10
<james_w> ronny: which page?
<james_w> #  Download URL:   http://bazaar-vcs.org/Download
<james_w> is that the reason?
<ronny> james_w: i think so
<ronny> easy_install goes down there till it hits  http://www.bazaar-vcs.org/Download
<ronny> then fails
<james_w> presumably anyone listed as owner can edit the page
<LarstiQ> ronny: do you have an example command I could run to test if the changes have the desired effect?
 * LarstiQ stays away from setuptools mostly
<ronny> LarstiQ: make a virtualenv and and do an easy_install bzr==1.something within
<ronny> (using the virtualenvs easy_install)
 * LarstiQ tries out virtualenv
<ronny> virtualenv rocks
<LarstiQ> I've been meaning to look at it, and zc.buildout
<ronny> im currently setting up scripts to test anyvc against multiple versions of bzr, hg and subvertpy
<LarstiQ> right
<ronny> whats missing is to wire up py.test to aggregate the cobinations of testruns in virtualenvs propperly
<LarstiQ> ronny: so, `virtualenv test_env; source test_env/bin/activate; deactivate;` to make one, activate and quit again?
<ronny> LarstiQ: personnaly i would just directly invoke the bin/easy_install of the virtualenv, seems more simple
<LarstiQ> and now the easy_install fails, cool
<LarstiQ> ronny: I have no clue :)
 * LarstiQ digs a bit to see how it works under the hood
<LarstiQ> ronny: but at least I can reproduce and test now, thanks!
<ronny> LarstiQ: if you invoke test_env/bin/easy_install it will just do the right thing
 * LarstiQ nods
<LarstiQ> ronny: I'm a bit leary it won't mess up my system. Of course the point is that it doesn't, but I don't trust setuptools, at all.
<ronny> LarstiQ: well, you invoke it as user, so it wont rape ya too bad
<ronny> i hope virtualenv will get pip instead of easy_install soon
<LarstiQ> ronny: it hasn't grown exploit code yet? ;)
<LarstiQ> ronny: what's pip?
<ronny> LarstiQ: a sane python package installer by ian
<ronny> btw - in general code by pje seems to be made to cause eye-cancer on reading attepts
<LarstiQ> ronny: a first glance at pip seems much saner
<ronny> LarstiQ: it is, ian does quite reasonable and pragmatic things
<LarstiQ> yay ian :)
<ronny> LarstiQ: how long will fixing the easy_install stuff take?
<ronny> (ie the getting urls back)
<LarstiQ> ronny: I don't know, I don't have access. But I'll make work of it.
<LarstiQ> ronny: do you know if it is possible to include links in http://bazaar-vcs.org/Download that easy_install could find?
<ronny> i want the easy things off my todo so i dont have any more excuses for the hard things
<LarstiQ> right
<LarstiQ> ronny: since the Download page I _can_ change
<LarstiQ> there seems to be a 'find_links' method at least
<ronny> LarstiQ: im not sure if there is a way to delegate easy_install to a listing of older releases
<ronny> else one would require to put all the older links in
<ronny> and thats too much work to be worth it and probably confusing, too
<LarstiQ> ronny: I'm trying to get easy_install to accept https://edge.launchpad.net/bzr/+download
<LarstiQ> ronny: `easy_install -f https://launchpad.net/bzr/+download bzr==1.12 ` seems to work, although it is picking .zip over .tar.gz
<jelmer> ok, git in working trees works to some degree \o/
<jelmer> blegh
<jelmer> bzr in git working trees I mean
<Peng_> Congrats. :)
<jelmer> only things left to do are commit and ignores
<jelmer> thanks :-)
<jelmer> it's still a tad bit slow ('bzr st' in a samba tree takes a few seconds)
<james_w> nice
<james_w> thanks jelmer
<james_w> does it have any idea of things staged in the index?
<jelmer> yeah, it uses that to see what files are versioned and which aren't
<jelmer> 'bzr add' will also update the copy that's in the index
<james_w> cool, that kind of makes sense
<james_w> bzr would need some extension to be able to interact with it more fully though I guess?
<jelmer> james_w: yep, and same goes for colocated branches
<james_w> yeah
<jelmer> james_w: right now it "feels" to me like it's a native bzr branch except for the fact that it's a bit slower and reports ".git" as an unknown file :-)
<james_w> heh
<james_w> that's what I'd like, so it sounds great
<jelmer> james_w: btw, I've been meaning to ask you
<jelmer> james_w: how do you cope with parallel imports for UDD?
<james_w> would adding ".git" to the runtime ignores thing make sense?
<james_w> we tend to ignore it
<james_w> however, as we import most things we re-use file ids, so it tends to not be such a problem
<james_w> I also want to make it use Aaron's rename detection to improve that some
<jelmer> james_w: that doesn't work if you have e.g. an upstream that is in bzr though?
<jelmer> james_w: bzr relies on the fact that control directories are called '.bzr' in some places at the moment, I'd like to get rid of that
<james_w> ah, so you just make it see .git as the control directory
<james_w> that makes sense
<james_w> and you are right, it doesn't work when you have upstream in bzr
<james_w> when we get to a point where that will be an issue on the large scale then hopefully bzr will have the parallel imports case better addressed
<jelmer> james_w: Ah, ok
<jelmer> james_w: Perhaps this would be something useful to discuss during the sprint
<james_w> yeah
<james_w> at the recent sprint I learned what path tokens are, and they made sense to me
<jelmer> they're still magic to me
<james_w> I've no idea how to make them performant though
<jelmer> do you know how well Aaron's rename detection performs?
<james_w> pretty good as I understand it
<james_w> he tested by doing something like comparing bzr.dev with 1000 revisions back and it got 100%
<jelmer> but in terms of speed?
<jelmer> bzr-git doesn't support renames at the moment and rename detection is the only option I have
<james_w> ah
<james_w> not sure
<jelmer> mwhudson: hi
<james_w> it's an edge match of every added file against every removed file I guess
<james_w> perhaps with some shortcuts
<james_w> I think that wouldn't be too slow
<jelmer> Perhaps at the point somebody renames a top-level directory
<jelmer> with 1000s of files under it
<jelmer> (at that point git gives up on renames)
<james_w> yeah
<james_w> adding path based detection first would be good I think
<james_w> should handle that case well, and be quicker than detecting each individual rename
<jelmer> yeah, that'd make sense
<gioele> hello
<gioele> How come bzr 1.13.2 is packaged in PPA as bzr-1.13-2. Doesn't that version number mean bzr 1.13(.0), re-packaged for the second time?
<beuno> ah
<beuno> see
<beuno> that's why people aren't getting updates
<beuno> gioele, you're right
<gioele> can I complain about the lack of a 1.14 bzr package in PPA or is it too early? :)
<beuno> gioele, I think it's in a different PPA
<beuno> gioele, https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa
<LarstiQ> gioele: personally, I would be fine with publishing it in the main ppa
<gioele> beuno: I see, but it out of beta now
<beuno> gioele, I know. But I guess they chose to put 1.13.2 on the release one
<LarstiQ> gioele: if you can test the one in the beta-ppa, I'm willing to move it to the main one if you vouch for it ;)
<beuno> I agree though that 1.14 should go there
<LarstiQ> actually, johnf uploaded it yesterday to the beta ppa
<gioele> LarstiQ: I doubt I'll change my list of apt repositories ;)
<LarstiQ> gioele: you can wget one .deb file if you want. But I'll ask johnf what the policy is on moving to the main ppa.
<gioele> LarstiQ: seriously, I use bzr for stuff I care about. I'm fine using whatever comes from the official releases. But I have no means to "test" a release except running bzr self-test.
<gioele> basically I just trust you dev that what is in the PPA is safe and tested enough
<LarstiQ> aww, shucks.
 * LarstiQ wanted to recruit more testers.
<gioele> LarstiQ: if you give me another test suite to test I'll happily test any new bzr. But is there another non-"bzr selftest" test suite?
<LarstiQ> gioele: the idea with the beta ppa is to have a time of real world usage in addition to the automated tests.
<gioele> LarstiQ: but how can I test in real world. I see a catch 22 here. My real data is too precious to use it to test bzr. I could use fake data, or older data with fake commands, but that would not be really representative
<gioele> and anyway, the latter could be automated
<gioele> people could submit anonymized repositories and you could test on those, maybe with user supplied sequences of commands
<LarstiQ> gioele: right, that would exclude you from being a beta tester, which is fine.
<gioele> can someone despam http://bazaar-vcs.org/Talks/KeheduMujipul and http://bazaar-vcs.org/Talks/NedovHobahit?action=Despam
<gioele> I don't have enough rights to do that
<lifeless> gioele: its not enabled on that wiki
<phinze> survey: ideal commit message for a merge?
<vila> phinze, one that describe succintly while precisely  what is being merged
<phinze> when coming from a task branch it makes sense like "added feature, fixes issue #1234"
<phinze> but what about merging into a task branch updated code from shared branch
<phinze> i'm finding myself flipping between "Merged trunk"; "Merging trunk"; "Merged upstream" and the like
<SamB> "pulling from trunk"?
<phinze> wondering if i'm being redundant as that data is stored in metadata of the commit
<SamB> Well, who cares if you're a bit redundant?
<phinze> and then there's the question of present tense or past tense
<phinze> true
<phinze> and i realize this is totally and completely pedantic and overkill
<phinze> but just wondered if other people think about this stupid stuff too :)
<SamB> It's easier to see if it's in the commit message, if you're going down reading the commit messages ;-)
<phinze> true i like to keep --line nice and readable
<LarstiQ> phinze: 'Merge bzr.dev r1234'
<SamB> and it's not like you can leave it blank
<phinze> LarstiQ: yeah that's not bad...
<LarstiQ> phinze: that's a bit ambiguous, but I think it's clear enough that you merge bzr.dev inclusive.
<phinze> though it would show up as [merge] Merge bzr.dev...
<LarstiQ> otherwise I'd word it as 'cherry pick'
<LarstiQ> phinze: that's display dependant, but if you worry 'Sync up with' ?
<phinze> LarstiQ: yeah not a huge deal -- just wanting to be succinct but useful
 * LarstiQ nods
<LarstiQ> phinze: have a look at the bzr.dev merging for inspiration, is what I usually do ;)
<phinze> LarstiQ: hah, not a bad idea -- look to the logs for enlightenment
<LarstiQ> phinze: that's also how logs will be used often ime, vcs archeology, finding out when and why a change got introduced, etc.
<LarstiQ> phinze: for merging trunk that usually matters less, but it's good to keep in mind
<phinze> LarstiQ: yesh my thoughts exactly
<phinze> LarstiQ: nice phrase too: 'vcs archeology'
<vila> vcs *is* software archeology
<LarstiQ> vila: right, there is probably a better term than prefixing with the means
<vila> LarstiQ: you're right :)
<LarstiQ> (I just don't like software archeology)
<ja1> morning vila
<vila> hey jam !
<jam> how's it going?
<jam> I'm still a little under the weather, and probably not up for a phone call.
<jam> but we can chat here if you want
<vila> jam: sure, I'm finishing upgrading all my machines to jaunty, the pain being mainly migrating from parallels to virtualbox for my main WS and finding workarounds for silly bugs
<vila> including synergy not working anymore to share the mouse, the scrollwheel insisting that the right place to be is top left corner of main screen and otherwise the mouse jumping randomly all over the place
<jam> ooh, sounds fun
<vila> all of them being of course unheard by google itself
<vila> well, that was fun the first hour or so :-)
<jam> vila: In the past I came across an app that would hook into X's handling of your mouse.
<jam> Such that it could cause the mouse to "drift"
<jam> and "accelerate" etc
<jam> So when you stopped moving the physical mouse, the cursor would keep sliding for a bit
<jam> etc
<vila> hehe
<jam> It was a fun gag to play
<vila> I sort of had that one until I found the work around for synergy :)
<jam> but I'm sure would be horribly frustrating to use in practice.
<vila> A funny one to mention too:
<vila> virtualbox defines rigth-ctrl as the "host" key (to regain control of mouse/keyboard from guest)
<vila> but since synergy was acting, I used an old sun keyboard at one point *without* a right ctrl key...
<vila> and of course I realized that during a long blocking operation when the mouse wasn't usable anymore (captured by the guest) :-)
<vila> oh, and also the scrollwheel bug was specific to one mouse, not the old one I finally found under some dust...
<vila> oh, one last thing:
<vila> I finally found the way to work around the buggy virtualbox NAT (that gave me troubles in Brisbane) by... using the one installed by parallels :-)
<vila> (parallels installs a NAT handling background task at startup unlike vbox which try to handle it without being root and failed in some obscure corner cases...)
<vila> if ping and nfs can be called obscure that is :)
<abentley> jam: I want to introduce a new metadir format like development-subtree, except using branch format 8.  Should I create a new entry, or just change development-subtree?
<jam> W%rcR%ft21
<jam> oops
<jam> wrong window, and wrong entry anywy...
<jam> abentley: I think we need a new format, because otherwise anyone using dev-subtree *today* won't be able to migrate
<abentley> jam: They ought to be able to do "bzr upgrade --development-subtree"
<jam> abentley: because the individual objects would still be recognized?
<abentley> jam: Right.
<jam> so, IMO, --dev-subtree should be an alias
<jam> not a concrete format
<jam> so having it point at something new is fine
<abentley> jam: Right now, it's not.
<abentley> There's a comment explaining why that I don't understand.
<jam> let me check
<abentley> i.e. "it's not an alias".
<jam> abentley: so the comment is just that we didn't create a -dev6-subtree to aliase -dev-subtree to
<jam> so I would suggest...
<jam> create a --dev6-subtree (or -dev7
<jam> and change -dev-subtree to be an actual alias
<abentley> Okay.
<abentley> jam: I don't understand why aliases specify their component formats.  Seems brittle to me.
<jam> As for --dev6 / --dev7... I don't really care
<jam> abentley: I don't fully understand aliases either
<jam> I guess that aliases are just omitted from the 'info' listing?
<jam> I certainly would have thought that an alias designation would just copy info from whatever it was aliasing
<jam> yeah, it seems to do:
<jam>     non_aliases = set(bzrdir.format_registry.keys())
<jam>     non_aliases.difference_update(bzrdir.format_registry.aliases())
<jam> And nobody actually took the time to code up how we would really want  to use aliases
<abentley> jam: Just being able to construct them from the format they alias would be a good start.
<jam> abentley: like a "Format.create_alias()" function?
<abentley> jam: I was thinking of FormatRegistry.register_alias()
<jam> sure
<abentley> jam: Shouldn't development formats be hidden?
<jam> I would probably say yes by default, but I don't think there is a way to say "and give me the rest"...
<intellectronica> so, anybody knows how i make bzr on ubuntu not popup notifications for everything i do. the new notification dialog is nice, but this is a bit too much for my taste
<jam> intellectronica: well, the brute-force way is to uninstall bzr-gtk
<jam> Though I believe there *is* a way to just disable it
<jam> I just don't know it off hand
<intellectronica> jam: yeah, removing bzr-gtk seems to do the trick. thanks!
<SKArfaceGC> kfogel: Finally got around to writing a bit on permissions, since you expressed interest  http://www.baltdad.com/2009/04/bazaar-part-5-permissions/  nothing earth shattering but it was useful for me.
<kfogel> SKArfaceGC: cool!  will take a look
<kfogel> SKArfaceGC: oh, that's more about unix filesystem-level perms.  I think I was thinking about client/server access control.
<kfogel> like, who can branch what from where, who can push what to where, that sort of thing
<SKArfaceGC> I'm going to hit that next.  I've been crushed at work so I haven't had a ton of time to mess with it.
<SKArfaceGC> I really do want to be able to handle perms at the server level rather than at the fs level.  Would simplify some stuff in my env.
<SKArfaceGC> Though it strikes me that with a decent script and heavy abuse of /etc/groups I may be able to simulate some of the detailed control I want.  Just seems, well, a bit too hackish.
<matio> bazaar is written in python isn't it
<matio> ?
<jelmer> matio: yes
<kfogel> SKArfaceGC: yeah, I think doing access control via fs-level perms is not the wave of the future :)-.
<kfogel> oops
<kfogel> :-)
<matio> does the project need any help (that would be quite easy), I want to help open-source projects that use python
<jelmer> matio: yeah, there's always more things to do
<jelmer> matio: A good start is looking for the bugs tagged "easy" in the bug tracker
<matio> what could I help with? (thanks 4 reply)
<jelmer> matio: see https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=easy
<SKArfaceGC> are there any plugins for the smart server that deal with permissions already?
<matio> thjelmer: thanks, I was just looking at the blueprints for bazaar!
<LarstiQ> matio: easy, or trivial
<LarstiQ> matio: (which is then https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=trivial of course)
<matio> im not sure where i would start
<LarstiQ> matio: you could start by finding the patch mentioned in https://bugs.edge.launchpad.net/bzr/+bug/239523 , apply it, and see if that fixes the problem or not.
<ubottu> Launchpad bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed]
<LarstiQ> matio: if it doesn't fix the problem, it needs to be improved. If it _does_ fix the problem, it needs to be merged to bzr.dev
<LarstiQ> matio: in which case you'd need to find out why it isn't merged yet, possibly take care of points raised during review, get another review done, etc
<LarstiQ> matio: does that help?
<matio> LarstiQ: yes, thanks
<LarstiQ> matio: http://bundlebuggy.aaronbentley.com/project/bzr/request might be of help for finding the patch. If not, it should be in the mailing list archives.
<LarstiQ> matio: http://doc.bazaar-vcs.org/latest/developers/index.html might also come in handy
<matio>  LarstiQ: thanks for your help
<jelmer> jam: ping
<jelmer> jam: The parent keys specified to add_lines(), should that be a list or a tuple?
<jelmer> It seems like groupcompress bails out it if is a list and the other code bails out if it is a tuple
<jam> jelmer: individual keys must be a tuple, IIRC, but the overall group of parents should probably be either
<jam> Are you doing [(parent_1,), (parent2,)] ?
<jam> or (parent1, parent2)
<jam> Or ((parent1,), (parent2,))
<jam> the middle one is wrong
<jam> for sure
<jam> the first and third should be correct
<jam> (I *think*)
<jelmer> I'm doing the first but that triggers a test in add_lines() that makes sure the parents of a text don't change
<jelmer> bzrlib/groupcompress.py:1601
<jelmer> if the present nodes have a different type than what I'm specifying it raises the assertion
<jelmer> (Pdb) print keys[key][1]
<jelmer> ([('36620@8da58560-a4e7-4996-a0c2-a735b94b261c:trunk%2Fautodoc%2Fsource%2Fparser%2Fkernel%2Fx_parse.cxx', 'svn-v4:8da58560-a4e7-4996-a0c2-a735b94b261c:trunk:121227')],)
<jelmer> (Pdb) print node_refs
<jelmer> ((('36620@8da58560-a4e7-4996-a0c2-a735b94b261c:trunk%2Fautodoc%2Fsource%2Fparser%2Fkernel%2Fx_parse.cxx', 'svn-v4:8da58560-a4e7-4996-a0c2-a735b94b261c:trunk:121227'),),)
<jam> jelmer: so where does it fail if it is a tuple? (#3)
<jelmer> and afaik I changed to using [] in the first place because another part of the code required that
<jelmer> s/afaik/iirc/
<jelmer> I think the dupe check code of knits
<jam> so failing because it is a list vs tuple doesn't seem valuable at that point
<jam> I would have thought _get_entries() would always return tuples at this point
<jam> but certainly it could have returned either at different times
<jelmer> ok, tuples it is
<jam> jelmer: either way, I wouldn't mind if the check was updated to cast them specifically
<jam> since I don't think we care about the time of the container at that point
<SKArfaceGC> where is documentation for a project on launchpad normally kept?  Blueprints/Answers/Overview do not seem to be the place to look.
<LarstiQ> ronny: https://lists.ubuntu.com/archives/bazaar/2009q2/057805.html
<jfroy> jelmer: updated 364416 with the NoSuchRevision backtrace
<jelmer> jfroy: is this a repo with mixed svn-v3 / svn-v4 revisions ?
<jfroy> yeah
<beuno> SKArfaceGC, there is no such place, for now
<ronny> LarstiQ: thanks
<LarstiQ> ronny: thanks for getting me finally to start with virtualenv :)
<ronny> LarstiQ: np, always happy to beat people with cool things
<LarstiQ> hihi
<mwhudson> jelmer: hello
<abentley> jam: Do you have a minute to chat?  I need some advice on nested pull.
<jelmer> mwhudson: hi!
<BasicOSX> Who would have thought RMS had a sense of humor. Sent myself and mbp "condolences" for the 1.13.2 release :-)
<beuno> BasicOSX, HI!
<beuno> what do you think of updating the release PPA with 1.14?
<beuno> instead of 1.13.2?  :)
<BasicOSX> beuno:  I don't do the PPA part, just source tar/zip, but I think it's a great idea :-)
<beuno> BasicOSX, oh?   now I have to find someone else to bug!
<LarstiQ> beuno: I've sent johnf (who does the ppa bits for bzr) a mail about that.
<beuno> LarstiQ, thanks  :)
<LarstiQ> beuno: he's in the .au/.nz timezone afaik
<beuno> we should also get an SRU for Jaunty
<jelmer> beuno: did 1.14 end up in Jaunty?
<beuno> jelmer, no  :(
<beuno> 1.13
<jelmer> ah, good
<jelmer> otherwise we'd have heaps of broken plugins there..
<beuno> jelmer, well, now we have heeps of broken branches...  :)
<abentley> beuno: Do you mean the stacking issues or the new formats?
<beuno> abentley, stacking
<abentley> beuno: AIUI, we're putting bzr 1.13.2 into jaunty-updates.
<beuno> abentley, has someone filed that?
<beuno> that would be lovely  :)
<abentley> beuno: Ask spiv
 * beuno looks at spiv 
<jelmer> mwhudson: is that etckeeper mirror still visible somewhere?
<mwhudson> jelmer: o
<mwhudson> o
<mwhudson> aargh!
<mwhudson> no!
<mwhudson> jelmer: the usual staging effect
<mwhudson> jelmer: but the import took like 10 seconds
<jelmer> mwhudson: that sounds about right
<jelmer> mwhudson: speaking of 10 seconds.. launchpad-bazaar seems to be choking on openoffice
<jelmer> https://edge.launchpad.net/~jelmer/openoffice/hosted
<mwhudson> jelmer: gosh
<mwhudson> jelmer: that mean 15 minutes without a progress report :/
 * mwhudson goes to look at the codehost's disk space graph
<jelmer> yeah, it's large
<jelmer> about 200k revs at this point
<jelmer> mwhudson: any idea?
<mwhudson> jelmer: probably getting a LOSA to do the initial pull by hand
<mwhudson> jelmer: unless you want to fix bzr's progress reporting?
<jelmer> mwhudson: there's lots of things I want to do
<mwhudson> jelmer: i know that feelig
<mwhudson> jelmer: i'll get spm to kick it when he starts work
<jelmer> so this is just because bzr doesn't give any output, in which case lp assumes it's stalled?
<mwhudson> right
<mwhudson> we hook into the progress bar machinery
<LarstiQ> calling bzr via bzrlib.. ah
<LarstiQ> mwhudson: what version of bzr is that with?
<mwhudson> (useful for mirrored branches really, the mirror puller sometimes got stuck for daaaays)
<mwhudson> LarstiQ: 1.14rc2
<LarstiQ> mwhudson: and the progress isn't sufficient? Hmmm.
<mwhudson> jelmer: what format is the branch?
<LarstiQ> for being alive I'd expect the transport progress to really have helped.
<mwhudson> jelmer: if i have bzr-git in ~/repos/bzr-git/trunk how can i run the tests?
<mwhudson> jelmer: symlink from ~/.bazaar/plugins/gtk, bzr selftest git ?
<mwhudson> LarstiQ: don't think the localtransport participates in that?
<LarstiQ> mwhudson: oooh, fair enough
<LarstiQ> yeah, that sucks
<jelmer> mwhudson: development6
<jelmer> mwhudson: "make check" in the bzr-git directory should do it
<jelmer> mwhudson: but what you suggested should work too
<mwhudson> jelmer: oh right
<mwhudson> hmm
<mwhudson> ProgrammingError: You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings.
<mwhudson> jelmer: sqlite version fun or something?
<jelmer> mwhudson: do you have bzr-git 0.2.1?
<mwhudson> jelmer: bzr-git trunk
<mwhudson> i guess i should branch the tag
<mwhudson> and hey, maybe lp isn't up to date
<mwhudson> ah, it's a hosted branch
<ronny> LarstiQ: btw, http://moinmo.in/SectionParser might be something to help with making things invisible
<mwhudson> jelmer: happens with tag:bzr-git-0.2.1 too
<LarstiQ> ronny: that seems like it should work, thanks
<jelmer> mwhudson: sorry, it looks like I forgot to actually merge my python2.4 fixes for bzr-git
<kirkland> so i found the color coding pretty cool, interesting in 'bzr shelve' ... is there any way to get bzr diff to work the same way, color coded and in a pager (besides dumping to file and opening in vim?)
<jelmer> mwhudson: Is it ok if I just push or would you rather see a 0.2.2?
<ronny> LarstiQ: {{{#!wiki comment
<mwhudson> jelmer: this happens with python2.6 too
<LarstiQ> kirkland: that happens because you have bzrtools installed, which also provides cdiff
<mwhudson> jelmer: a tag would be nice, no need to bother with a release
<LarstiQ> kirkland: pager/vim wise, I usually | vim -
<LarstiQ> ronny: that being standard supported?
<mwhudson> kirkland: also less -R works
 * LarstiQ falls asleep, ciao
<kirkland> thanks guys
<luks> bzr-pages can do that automatically for you
<luks> *bzr-pager
<ronny> LarstiQ: yes, im not sure since what version tho
<jelmer> mwhudson: pushed, tagged as bzr-git-0.2.1a
<mwhudson> jelmer: ta
<mwhudson> oh wow, bzr tags -r branch:lp:bzr-git goes bang in a spectacular way
<mwhudson> ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mwh/canonical/repos/bzr-git/release-0.2.1/.bzr/branch/)
<mwhudson> i guess i should file a bug or something
<mwhudson> jelmer: pushed where?
<jelmer> lp:~bzr/bzr-git/trunk
<mwhudson> jelmer: really?
<mwhudson> oh wow, yes, really
<mwhudson> jelmer: thanks happier now
<jelmer> cool
 * mwhudson just experienced svn's conflict handling for the first time in a few years
<mwhudson> it's .... different ow
<mwhudson> now
<jelmer> yeah, it's been improved
<mwhudson> svn resolve --accept working <file> is pretty awkward though
<mwhudson> and i don't really want to be asked questions during 'up'
<mwhudson> ah well
<jelmer> mwhudson: what are you using svn for anyway now that you have bzr-svn ? >-)
<mwhudson> jelmer: it's codespeak :)
<jelmer> ahh :-)
<mwhudson> speaking of which, i have a repo dump here...
<enigma> jelmer: I'm having a strange bzr-svn error when you have a second.  bzr: ERROR: exceptions.AttributeError: 'SubversionPushResult' object has no attribute 'old_revno'
<enigma> jelmer: "bzr missing" and "bzr pull" work just fine. It's just "bzr push" that has issues.
<jelmer> enigma: with which version?
<enigma> bzr-svn 0.5.4 with bzr 1.14
<mwhudson> jelmer: while you're here, python 2.4, bzr 1.14, subvertpy 0.6.5 and bzr-svn 0.5.4 should all get along reasonably happily?
<jelmer> mwhudson: yes
<mwhudson> jelmer: cool
<mwhudson> jelmer: i'll be asking you a similar question in a month, i guess :)
 * mwhudson stabs combinator
<mwhudson> uh!
<mwhudson> the subvertpy tests just segfaulted on me
<jelmer> uh?
<mwhudson> jelmer: subvertpy.tests.test_client.TestClient.test_get_config segfaults for me
<mwhudson> with python 2.4, 2.5 and 2.6
<mwhudson> on jaunty
<jelmer> mwhudson: subvertpy tip?
<mwhudson> jelmer: release-0.6.5
<jelmer> mwhudson: That one is actually fixed since 0.6.5
 * jelmer should probably release 0.6.6
<mwhudson> jelmer: yes, trunk seems happier
<mwhudson> apart from subvertpy.tests.test_properties.TestProperties.test_time_from_cstring
<mwhudson>     self.assertEquals(1225704780716938L, properties.time_from_cstring("2008-11-03T09:33:00.716938Z"))
<mwhudson> exceptions.AssertionError: 1225704780716938L != 1225701180716938L
<jelmer> mwhudson: export TZ=CET ;-)
<jelmer> but yeah, that's a bug too
<mwhudson> jelmer: ehhh
<mwhudson> a bug in the tests, or in subertpy?
<jelmer> mwhudson: that's a bug in the tests
<mwhudson> ok
<mwhudson> jelmer: i get this sort of thing when i try to run bzr-svn tests with python2.4 http://pastebin.ubuntu.com/161709/
<mwhudson> jelmer: does that make any sense to you?
<mwhudson> ah, the message is actually
<mwhudson> ImportError: subvertpy/client.so: undefined symbol: Py_InitModule4_64
<mwhudson> oh i see, i wasn't actually running the tests with trial
<mwhudson> jelmer: subvertpy doesn't actually seem to work with python2.4
<jelmer> mwhudson: Tests seem to work fine here
<jelmer> mwhudson: did you rebuild for python2.4?
<mwhudson> jelmer: yes
<mwhudson> at least, i tried :)
<jelmer> mwhudson: what exactly doesn't work?
<mwhudson> jelmer: importing the extensions
<mwhudson> hang on, three conversations at once going on here :)
<poolie> hello all
<jelmer> hey poolie
<poolie> i'm home again, yay
<mwhudson> jelmer: spm is pulling your oo branch by hand now
<spm> poolie: just in time for friday too! excellent timing! :-)
<mwhudson> jelmer: ok, python2.4 seems to be working now
<jelmer> mwhudson: cool - any source code changes necessary?
<mwhudson> jelmer: are you going to release a new subvertpy, or should i just use tip?
<mwhudson> jelmer: no
<mwhudson> jelmer: although you might want to fix the business about the error message when extensions fail to import
<sidnei> yo poolie!
<poolie> hello sidnei
<jelmer> mwhudson: if possible please just use the tip
<jelmer> mwhudson: I'd like to fix the timezone issue as well in 0.6.6
<mwhudson> jelmer: ok
<sidnei> poolie: im making good progress here. too bad it takes a hundred years to branch bzr on my connection :)
<mwhudson> (we're not actually using subvertpy/bzr-svn yet, but i would like to get a mutually compatible set of stuff in our tree)
<mwhudson> jelmer: argh, the bzr-svn tests segfaulted
 * jelmer thinks mwhudson has some bad karma
<jelmer> mwhudson: bzr-svn 0.5.4, subvertpy tip, bzr 1.14 ?
<mwhudson> jelmer: python 2.4, jaunty
<mwhudson> jelmer: pastebin will follow in a sec, on a call now
<mwhudson> jelmer: it's bzrlib.plugins.svn.tests.test_workingtree.TestWorkingTree.test_get_ignore_list_morelevel that segfaults
<lifeless> hi poolie
<poolie> hi lifeless
<poolie> i'm back, as you see
<poolie> i'll answer your mail about news from london
<poolie> i have a cold (hopefully not swine flu!)
<jelmer> mwhudson: do you have a gdb backtrace?
<fullermd> I have a solution to swine flu.  It involves eating a whole lot of bacon.  Who's with me?
<lifeless> fullermd: :)
<lifeless> fullermd: bacon explosion!
<mwhudson> jelmer: no
<jelmer> mwhudson: I'm really not sure what could cause this, nobody has reported a segfault in months
<mwhudson> jelmer: on the phone, one sec
<mwhudson> jelmer: http://pastebin.ubuntu.com/161741/
<jelmer> mwhudson: are you getting an actual segfault or an assertion? which svn version?
<mwhudson> jelmer: segfault
<mwhudson> 1.5.4dfsg1-1ubuntu3~launchpad0
<mwhudson> hmm
<mwhudson> that ~launchpad0 is a bit suspicious :)
<lifeless> mwhudson: probably a nochange rebuild for 2.4
<mwhudson> i hope so
<sidnei> lifeless, poolie: any idea where TortoiseOverlays can be found? the build instructions are broken where the link should be: http://bazaar-vcs.org/BzrWin32Installer
<lifeless> sidnei: no idea :(
<tyhicks> Question from a git user: It seems like bzr repositories are made up of branches that are contained in subdirectories.  In git, I tend to like that I can checkout a branch (with git-checkout) and not cd into a subdirectory.
<tyhicks> Am I missing something with bzr repos or will I just have to live with it? :)
<mwhudson> tyhicks: there has been vigorous debate about this :)
<mwhudson> tyhicks: one thing you can do in bzr is separate your trees from your branches and repository
<lifeless> tyhicks: you can create a checkout and use switch to switch between branches
<tyhicks> mwhudson: Ahh... I didn't mean to fuel the fire
<mwhudson> so you can have a repo in say ~/repos/project
<mwhudson> and branches  ~/repos/project/trunk ~/repos/project/feature-X
<mwhudson> and then a checkout in ~/checkouts/project
<mwhudson> then in ~/checkouts/project you can say "bzr switch trunk", "bzr switch feature-X"
<mwhudson> tyhicks: no worries, just wanted to say that you're not the first to ask this question :)
<tyhicks> mwhudson: I didn't know about bzr switch.  I think that will work for me.
<tyhicks> mwhudson: Thanks!
<sidnei> alright, gotta go. have a good weekend all!
#bzr 2009-05-01
<mwhudson> jelmer: http://bazaar.launchpad.net/~jelmer/openoffice/hosted/files
<lifeless> reasonably snappy in that view
<mwhudson> yeah, i'm pleasantly surprised
<jelmer> mwhudson: nice
<mwhudson> jelmer: the scanner is still choking on it if you try to look at the branch page :)
 * spiv yawns... he slept in!
<lifeless> spiv: ping
<lifeless> spiv: I vant reviews ;)
<spiv> lifeless: ok :)
<jelmer> lifeless: speaking of which... :-)
<lifeless> jelmer: right, push stuff?
<jelmer> lifeless: Yeah, InterBranch.pull()
<lifeless> I need to look at that in context with smart server pulls
<lifeless> I thought push would be sufficient, but it turns out it isn't
<mwhudson> jelmer: how large is that openoffice import btw?
<jelmer> mwhudson: ~4.5 Gb IIRC
<jelmer> lifeless: k
<mwhudson> jelmer: that's still pretty large!
<jelmer> lifeless: it now also looks like the InterBranch.pull / InterBranch.push code is necessary for svn nested trees support
<mwhudson> jml: can you explain in a short sentence what "Is there a way to get lp-reviews to participate on the list the way BB does" means?
<lifeless> jelmer: ?
<jml> mwhudson: let me try :)
<lifeless> mwhudson: BB acts like a member of the list; it responds to things on the list ([MERGE] mails, and responses to [MERGE] mails with review commands in them), it sends mail to the list (when something is merged, or someone votes through the webui)
<lifeless> mwhudson: you never need to go to the webui
<jml> mwhudson: "Watch the mailing list for specially flagged messages; when these messages appear, create a merge proposal, send a message to that thread and monitor the discussion as if it were taking place on Launchpad"
<mwhudson> lifeless: you never need to go to the webui for code reviews either
<lifeless> mwhudson: thats not the end goal; it would be a bit silly to have that as a goal.
<lifeless> the goal is to be inline with the list discussions
<mwhudson> jml: so the problem with code review as it is is that you have to send things to special addresses?
<jelmer> lifeless: bzr nested tree support has a local dictionary of where external trees can be found, by file id
<mwhudson> (merge@ for new proposal, mp+<id>@ for comments)
<lifeless> jelmer: in Branch8, yes.
<jelmer> lifeless: that seems like a reasonable thing to do, given that their location can move and that you'd also want the historical location to move
<jml> mwhudson: I think the problem is that Launchpad will send the email out again
<jelmer> lifeless: in svn, that location is tied to the tree
<jml> mwhudson: and yes, the special address
<jelmer> lifeless: so whatever default infrastructure there is at the moment I'll need to override for push and pull
<mwhudson> jml: mm, that too
<jml> mwhudson: I think abentley's last post on the thread nails the problems.
<jml> to the mast, like a flag.
<lifeless> mwhudson: bb *adds* to the discussions on the list; lp-reviews currently appears to want to own the discussion
<lifeless> participate vs being the forum
<mwhudson> right
<lifeless> python's code reviews happen separately to discussion; I find it very hard to have any internal zeitgeist about whats in the pipeline there
<abentley> lifeless: It sometimes feels like you guys want to use Code Review instead of Bundle Buggy, but want Code Review to be just like Bundle Buggy.
<lifeless> abentley: I love BB to bits; I think its soo close to Just Right that its not funny.
<jelmer> same here, except for the occasional downtime bb works really really well
<lifeless> abentley: I'd like to be using Code Review because it has all the admin stuff built in, uses the lp login rather than separate credentials, and is something other projects can trivially turn on
<abentley> lifeless: OpenID authentication, even LP team awareness would be possible if I thought it was worth the effort.
<lifeless> of course; I think its better to keep improving Code Review though
<jml> also, it'd be pretty awesome if Code Review (which is general purpose) became as good for you as the custom-tailored tool BB
<lifeless> jml: indeed
<jml> by "pretty awesome", I meant "pleasantly surprising"
<jml> except that I don't see a reason to aim for anything lower than that
<lifeless> for instance, bb has nicer email syntax; why can't code review have as nice a syntax?
<lifeless> (quoting Aaron about it being nicer)
<fullermd> Code review makes me sad because it suggests I'll have to dive back into the mess of figuring out how to deal with LP's emails  :|
<jml> I personally think the syntax should be: (review 'approve)
<jml> with options on (setq ok-to-merge-p (lambda () t))
<spiv> jml:  :set jml_is_trolling=yes
<lifeless> jml: (lisp allowed be YHWH) ?
<jml> man, forgot the quote.
<lifeless> an, forgot the h
<jml> lifeless: nice syntax is vague and a little bit subjective. have you filed bugs about it?
<lifeless> and the m. fail cold fingers
<lifeless> jml: I've asked Aaron when I get told by lp that I got it wrong
<lifeless> jml: bug filing when one isn't sure its a bug feels like makework
<jml> lifeless: on this, our feelings differ.
<lifeless> I have, do and will file bugs whenever I think its a bug, but won't, and it will stay like that in the absence of some reason to think it should change [repeated 'have you filed bugs?' questions are not sufficient or necessary].
<lifeless> bah missed the end of the phrase,
<jml> lifeless: ok
<lifeless> won't when I am not sure
<lifeless> so please, either tackle whatever issue you have head-on with me, or stop the somewhat snarky 'have you filed bugs' questions.
<jml> ok.
<lifeless> concretely, if you mean 'I think this is a bug, could you make sure there is one about this', thats fine - say that :)
<jml> lifeless: here's what I mean.
<jml> lifeless: I don't know what your difficulty with the launchpad mail review syntax was
<jml> lifeless: and I don't know how to find out what it is without asking you
<jml> lifeless: and until just now, I didn't know you had any issues at all.
<jml> lifeless: which makes it hard for me to participate (even silently) in discussions about making code review better for you.
<lifeless> thats all true
<lifeless> that said, every issue I've had I've brought with one or more developers of code review, at the time
<lifeless> when they say 'bug' I file a bug
<jml> which is great :)
<jml> but some things are open questions. it'd be good to have those discussed on some sort of asynchronous, stable medium.
<jml> whether the bug tracker (I'm very happy to say wontfix), or launchpad-users or something.
<lifeless> I'm not on lp-users; whats the SNR there like at the moment?
<jml> lifeless: there have been less than fifty threads this year. <5 are pure noise, the rest are divided about evenly between announcements, requests for help and suggestions
<poolie> lifeless: launchpad-users is excellent
<poolie> so low volume
<poolie> i get the impression not all devs read it, but jml does
<jml> poolie: hi, wb!
<lifeless> https://launchpad.net/~launchpad-users -> LP down try again message :(
<poolie> fwiw i rarely use the lp mail interface because signing is a slight hassle, but my miss rate when i do is no worse than BB
<jml> really? yikes.
<poolie> lifeless: yeah me too
<poolie> back now for me
<igc> morning
<lifeless> jml: two things
<lifeless> jml: I've forwarded you one discussion I had with Aaron to give you data.
<jml> lifeless: I saw that, thanks.
<lifeless> jml: but in general, I think its unreasonable to expect that every issue a user encounters of ones products *will* be in fora one is also in; one needs to deal with the discovery of issues that happened in the pasts by asking for that data, not by asking if the right thing was done
<lifeless> particularly when the right thing being done doesn't imply that you'd have had earlier access to that data.
<jml> lifeless: ok.
<lifeless> anyhoo; I'm on lp-users now; I won't guarantee to ask all questions there
<poolie> lifeless: btw i saw last week that launchpad echelon is somewhere near the planning horizon for that team
<poolie> by which i mean it may happen next year
<lifeless> if I have a review question and a faster/closer source is available, that source will be asked
<poolie> that feature name will give the fudsters something to chew on :)
<poolie> but, it means smarter two-way interaction with mailing lists, for instance telling bugs when they're being discussed
<lifeless> but when one isn't, I will ask lp users rather than private mail to a specific dev
<lifeless> jml: ^
<jml> lifeless: sweet, thanks.
<poolie> lifeless: so what's the bottom line as far as switching?
<jml> lifeless: the main thing for me is that if there's something left to do or to talk about further, we should get it written down somewhere.
<lifeless> poolie: Well, we can but try. I'm a little [lot] concerned that it partitions the list
<lifeless> the ui headaches are discussable
<lifeless> not having as clean an interface as bb is sad but not a deal breaker.
<lifeless> not getting the reviews into my bzr list folder is the biggest issue
<poolie> is that just a matter of having suitable headers for filtering?
<lifeless> I don't know
<lifeless> anyhow, I think the next step should be what I asked for on the list
<lifeless> someone that knows code review's design, how its meant to work etc, should update our developer docs
<lifeless> to say how we should do things to work with code reviews
<jml> +1
<lifeless> the exercise of doing that will beneficial in a few ways, and if it can't be done successfully that rather indicates that there is a showstopper :P
<lifeless> speaking of reviews
<lifeless> poolie: you resubmit:'d a patch of mine a while back, I disagreed, you went silent.
<poolie> which one?
<lifeless> poolie: I've updated the patch and sent it for review again; this time I want bb:approve, even though I haven't changed that part fo the code.
<lifeless> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1241072466.9565.45.camel%40lifeless-64%3E
<lifeless> concretely, -Dlock should only have a side effect while we fix up tests
<lifeless> once they are fixed the overload of using it to trigger error will go because the test suite will always error
<lifeless> so using a different variable really doesn't make sense to me, because you'll always with -Dlock -Dlock_check when testing during the transition fixup period
<lifeless> and -Dlock_check won't have any effect outside the test suite
<lifeless> poolie: jam has given tweak: but as you did 'resubmit' before I thought you'd appreciate the chance to see it again
<poolie> isn't this what -E is supposed to be for?
 * lifeless looks up -E
<lifeless> poolie: same thing
<lifeless> -Elock == -Dlock checked as the code does
<poolie> what do you mean?
<lifeless> oh, its not quite the same
<lifeless> anyhow, the point is - I want a temporary thing for a transition period only
<poolie> lifeless: aiui -E is for things that affect the running of the test suite
<poolie> whereas debug_flags is isolated per test so that we can test -D
<lifeless> -Dlock already exists and is ideal for doing this
<poolie> but won't it be masked off when each test runs?
<lifeless> no
<poolie> anyhow, looking at that patch without rereading my original mail i have no objection
<lifeless> ok thanks
<poolie> ^^ and with your explanation here
<poolie> igc, re the option naming thread
<poolie> i guess it's not a big deal but these threads seem kind of inefficient
<poolie> (i'm not complaining about your posts at all i'm just thinking aloud)
<poolie> there are some small things we want to fix, and they might be reflections of or connected to larger problems
<poolie> and we need to fix the big things but i have this nagging feeling the conversation always goes on to that at the expense of making incremental changes
<poolie> maybe it's ok and it's the only way we'll work up energy to do the big things
<lifeless> I think uncontentious small changes should just get done; and big things should be really carefully addressed - needs constraints, known lessons *before* putting solutions on the table
<igc> poolie: well even the big things usually end up being tackled a bit at a time
<lifeless> 'we're only as smart as the amount of time we spend before we come up with an answer'
<igc> poolie: the trick is making small changes along the right path
<poolie> mm
<poolie> i agree with both of you
<poolie> i guess, i'd like the small things discussed more in terms of "this is going down the right/wrong path" rather than "oh look at this big problem over there"
<igc> poolie: UI threads have a history of spinning out of control - everyone and their dog has an opinion :-)
<lifeless> poolie: that suggests we should have the sprint asap to determine the path
<poolie> right, and it's probably not worth squelching it
<poolie> agree
<igc> and that's a general comment - not just for bzr
<poolie> have to say i'm not feeling super keen on flying right at the moment
<poolie> so, 1-should we do it before UDS; and 2-where?
<lifeless> I don't think we have time
<poolie> 1 probably depends on whether we'll empty the brisbane core work queue
<lifeless> 2 weeks; several things to prep for allhands, network deltas needed, 1.15 to release, iter_changes to overhaul for commit
<igc> lifeless: I think you should do it at UDS and include me when you can
<poolie> oops i forgot there'll be no igc
<lifeless> I think after UDS is likely best
<igc> before UDS, I agree with Robert - let's keep focus on 1.15
<lifeless> bbc took the better part of a week for me to methodically aggregate our already learnt lessons and needs
<lifeless> its not a parallelisable task - more people doing it means more people have the aggregate state, but thats all
<igc> I for one are busy enough on nested tree reviews, tuning log dir performance and looking at branch-specific rules
<lifeless> heck, on nested trees I'm still deeply scared that we're basically going in the wrong direction
<lifeless> mmm, I should be more clear
<lifeless> on the planning sprint, I think we should do a bunch of analysis before hand
<lifeless> bbc is radically different to all the prior proposals
<lifeless> yet we'd talked about it at every sprint for the 3 or so years before
<lifeless> bbc is different because I took the time to really step back, clear head, and get to the root of the issues
<lifeless> someone needs to do the same thing for repository/branch management headache, inline-vs-checkouts and so on
<lifeless> on nested trees, what I mean is that having a lookaside datastructure and a composite tree really seems to drive complexity up to me, rather than having things that iterate choose to recurse when they want to
<lifeless> poolie: concretely, I think we should finish bbc; get commit fully fixed for it (someone needs to do iter_changes), get networking fully done (spiv and I are halfway through the delta representation, jelmer is reporting memory issues,...)
<lifeless> poolie: we should estimate when we'll get these things done (soon!) and plan a sprint in brisbane a few weeks after that
<lifeless> a few weeks to allow time to sit and think *before* we get together.
<igc> I think it's really import we keep focus on nailing networking & making bbc production strength right now
<mwhudson> spiv: does 'bzr serve' use a thread-per-request model?
<spiv> mwhudson: yes
<mwhudson> spiv: how do you think it would scale to 100 concurrent connections? :)
<spiv> mwhudson: depends on what the connnections do :)
<spiv> mwhudson: (I don't really have any basis to make a good guess about it)
<mwhudson> spiv: well, i'd be pretty confident that if it forked, it wouldn't do very well at 100 connections
<mwhudson> spiv: i guess if it only did vfs stuff, it wouldn't use much ram?
<spiv> Right.
<lifeless> you don't need to alter bzr at all to just do vfs stuff :P
<spiv> (there may be bugs with transferring large files, but if so we can fix those...)
<mwhudson> lifeless: i'm not sure what you're saying
<lifeless> mwhudson: I mean that the methods available are just in a dict
<lifeless> a plugin can strip them back to a 'I want these only' set
<mwhudson> yes, spiv already said as much in an email
<lifeless> cool
<lifeless> jelmer: is that packed?
<jelmer> lifeless: the memory usage thing?
<jelmer> lifeless: It was 4 packs, all around 1Gb
<lifeless> thumper: ^ it will shrink :P
<lifeless> jelmer: I suspect it will shrink massively if you pack it
<lifeless> jelmer: I was asking for disk space usage, not about the memory bug
<jelmer> ah
<lifeless> the memory thing you need to debug
<jelmer> lifeless: do I need to buy more memory first before I pack ? :-)
<lifeless> no
<lifeless> poolie: you've gone quiest
<poolie> silence indicated assent
<lifeless> cool
<poolie> also, sneezing my head off :)
<poolie> (thunk)
<lifeless> :(
<poolie> but seriously that did sound like a good plan
<lifeless> spiv: actually, jam has reviewed stuff; I just didn't see it because he didn't copy me/used the web ui
 * igc lunch
<poolie> lifeless: i think we should create a ~bazaar-reviews team, enable its mailing list feature, and subscribe it to reviews
<poolie> that should mean there's a single archive for all reviews, people can subscribe to just reviews if they wish, and they can read it through gmane etc
<lifeless> poolie: we already have a lsit of all devs
<lifeless> poolie: why create a new list?
<lifeless> poolie: nevertheless; I reiterate - updating our docs should be the next step.
<lifeless> we don't have to land the updated docs until we're happy, but we should be updating them before changing the workflow
<lifeless> because they are meant to be our reference manual
<poolie> lifeless: i'd create a new list just because avoiding mixing paint in lists seems to be a good guideline in launchpad
<poolie> you can always add ~bzr to that new team or vice versa
<poolie> cf problems with bialix not wanting the ppa spam sent to ~bzr
<lifeless> I actually mean bazaar@lists.canonical.com :)
<poolie> if that works properly that's fine
<poolie> so, actually i wonder about migrating our list there too
<lifeless> that might be nice
<poolie> mostly in the hope of getting less spam to deal with manually
<lifeless> I think the spam will be identical
<poolie> it seems like i'm the only person who moderates the list, it gets hundreds of spams per week, and it's either not possible or not a priority for IS to make the filtering better
<lifeless> what I want for reviews is for us to 1) update docs 2) search for solutions found doing that 3) trial, 4) mov
<poolie> um
<lifeless> e
<poolie> it looks like a broken filter to me
<poolie> i don't get nearly so many unfiltered spam in my own mail
<lifeless> if the docs end up saying  'join team A and join team B' then I think something is broken
<poolie> anyhow i agree with that plan, except that the stages can overlap
<lifeless> lp makes it hard to undo mistakes
<lifeless> but sure, I'm not against some overlap; I am against us forgetting to do one of these because we rush ahead; and I definitely want a clear separation between 'investigate how it works' and 'move'
<lifeless> I think broadly I'm being conservative because missed reviews are a pain, and we often have a backlog *anyway* so its worth a small number of people doing the analysis of a move before many people are affected
<lifeless> see for instances python's dvcs pep for a similar situation
<poolie> ok
<poolie> lifeless: btw my previous review for -Dlock did also mention updating the flag documentation
<poolie> if this is only transitional it may not be a big deal
<lifeless> poolie: right
<lifeless> its a bandaid until we can always be asserting
<lifeless> poolie: have I mentioned my little aws gui ?
<poolie> no
<lifeless> bzr branch lp:~lifeless/txaws/client; cd client; bin/aws-status
<Kilroo> Well, I gotta say, I'm considerably happier with my Bazaar experience since this morning when I figured out that the bzr-eclipse plugin apparently chokes on spaces in paths.
<lifeless> heh :(
<Kilroo> Now it's just a question of exactly how I'm going to use it.
<helebek> hi all, anybody using bzr on windows? I need some help, please.
<lifeless> helebek: ask your question :)
<sidnei_> helebek: ask, and an answer you shall receive.
<lifeless> poolie: let me know what you thnk of the aws gui
<helebek> I installed the windows binaries from the bazaar website successfully. Everything I do local works fine, when I try sftp I get an error from a python script. If I use bzr+ssh I get a connection closed error. Any ideas?
<helebek> thank you, btw
<sidnei_> helebek: can you connect to the host with putty?
<helebek> yes I can connect with putty and plink
<helebek> With sftp://python script giving the error is transport.py (line 213). It says "AttributeError: 'str' object has no attribute 'get' "
<sidnei_> oh, yikes. might be a known issue. lifeless?
<helebek> With bzr+ssh it asks for the password and then says authentication is successful. Then buff "bzr: ERROR: Connection closed: please check connectivity and permissions"
<poolie> Kilroo: that kind of sucks, can you file a bug please? javierder is working on it quite actively
<Kilroo> I think there's already a bug on it, actually.
<poolie> lifeless/others, rfc, i'm cleaning up the ui stuff and am thinking of merging all of bzrlib/ui/*py into just one ui.py
<poolie> it may marginally improve load time
<poolie> and some of the files are getting small
<poolie> any conceptual objections, and also
<Kilroo> No, wait. That might have been for spaces in a url you're trying to pull from.
<Kilroo> I'll check, and either file or comment as appropriate
<lifeless> poolie: conceptual objection: its mixing paint :P.
<poolie> i vaguely recall implementation problems with python (pyc files?) when a directory module turns into a file
<lifeless> poolie: the other transform is a problem
<lifeless> foo.pyc is found before foo/__init__.pyc
<Kilroo> but as long as you don't give the path any spaces to turn into %20's, you don't run into situations where bzr-eclipse can't find your working tree because there's no such place as My%20Documents.
<poolie> so you want the base class separate from the text version?
<poolie> Kilroo: the rule is this (modulo bugs): if it's a URL, it should be escaped as %20; if it's a non-url filename it should not have those escapes
<lifeless> I think it is cleaner, particularly when we expect dramatically different implementations aorund
<lifeless> e.g. gtk
<lifeless> Kilroo: please be sure to file a bug on bzr-eclipse
<lifeless> poolie: "
<lifeless> poolie: "
<lifeless> Reporting suggestions through the bug tracker is fine, though if they're
<lifeless> likely to be controversial or require extensive discussion it's better
<lifeless> to go to the list.  (This one doesn't.)"
<lifeless> poolie: ^ thats why I want to keepreviews on the list :)
<poolie> lifeless: so the subdirectory is a nonissue you think?
<poolie> why?
<poolie> well, actually
<poolie> there are a few related issues
<poolie> aiui the objections to discussing features in the bug tracker are: new designs may not break down into clear separate actionable bugs at first
<poolie> some people may want to be involved but not subscribed to all bugs
<poolie> bugs are just linear unthreaded and not so good for long conversations
<poolie> and it's good for a bug to just contain a summary of what needs to be done not the full discussion
<poolie> personally i mostly agree with most of them
<poolie> the third doesn't apply to code reviews which are threaded (though they may be inferior to mail in other ways)
<poolie> regarding the first and last, i would agree that general discussion should be separate from discussing a particular patch
<poolie> but that's true on the list as well
<lifeless> the existence of code isn't a reliable separator for those things
<lifeless> how often do we have a thread turn into a patch, or vice verca
<Kilroo> I find that question moderately intriguing.
<lifeless> bad quotes from other channels: "It was once said a Black man would be President when pigs fly.Indeed 100 days into Obama's presidency,swine flu."
<lifeless> back shortly, lunchy style break time
<lifeless> poolie: did you give aws-status a spin?
<poolie> ew
<poolie> lifeless: not yet, are you really keen that i do?
<poolie> i guess so or you wouldn't be asking... :)
<lifeless> well, I know that activation energy is the large thing usually
<lifeless> my theory is if I nag you past that, you'll give it a spin and it will be there thereafter if you want to play more :)
<poolie> it may work better if i'm already in aws-mode
<poolie> at the moment i've been in email mode striving for finishing-ui-mode
<lifeless> :)
<poolie> now interrupted by shops-mode
<poolie> and, i may not return this afternoon actually
<poolie> so have a good weekend if i don't see you
<lifeless> you too
<poolie> bug me about it again
<lifeless> you can be sure of that :)
<lifeless> did you fly in this morning?
<jml> if any of have a spare moment, could you please take a look at https://bugs.edge.launchpad.net/launchpad-code/+bug/310347
<ubottu> Launchpad bug 310347 in launchpad-code "Temporary "Could not install revisions" error" [High,Triaged]
<spiv> jml: added a spare comment ;)
<jml> spiv: thanks :)
<lifeless> hmm, evo quit by itsself. fun
<lifeless> wish me luck, that batch of hpss patches is wending its way up to pqm now
<jml> lifeless: good luck.
<jml> spiv: I just sent a patch to the mailing list that you might approve of.
<lifeless> jml: bazaar ?
<jml> lifeless: yeah.
<jml> lifeless, spiv: can one of you two please land that for me?
<jml> I wonder if I should try to get pqm privs for bzr.
<spiv> jml: I can do that now, sure.
<jml> spiv: thanks.
<spiv> jml: I only held off because I wondered if perhaps you already had privs :)
<jml> spiv: I'm pretty sure I don't. (Is there a way to find out, other than submitting?)
<spiv> jml: ask lifeless (or equiv. pqm admin)
<lifeless> jml: ask spm
<lifeless> night all
<jml> ok. thanks.
<jml> lifeless: g'night.
<spm> lifeless: too late I'm not here.... oops.
<spm> damn. shouldn't have responded.
<spm> jml: actually - that is something best sent via rt. if only so that we have the audit trail if you ken.
<lifeless> spm: asking *about* != asking for
<jml> spm: yeah, although right now I'm only interested in finding out whether I have permissions.
<jml> spm: and I'd rather just submit a branch than file an RT to figure that one out :)
<spm> jml: :-) and no, you dont have access
<jml> spm: ta
<lifeless> and it landed, woo
<spiv> jml: pqm got a conflict, presumably with what lifeless just landed, resolving and firing again.
<jml> spiv: thanks.
<lifeless> spm: presumably :P
<lifeless> bah
<lifeless> spiv: ^
<lifeless> spiv: also, way less roundtrips. We're under 9!
<spiv> lifeless: Nice.  Very nice!
<lifeless> not stacked sadly
<lifeless> anyhoo next week I want us to pair
<lifeless> and figure out sketches for getting the rest down
 * igc dinner
<gnomefreak> is there a way to rename a branch or just push revision with new name?
<Peng_> gnomefreak: Just...rename the directory with your standard "mv" or whatever.
<gnomefreak> Peng_: that would consit of sshing into launchpad right? if so how
<Peng_> gnomefreak: Oooh, Launchpad. Can't you do it from the web UI?
<gnomefreak> checking
<gnomefreak> under change details is what i want i think
<gnomefreak> Peng_: thanks it worked
<Peng_> :)
<wgrant> Hmmm. 'bzr revert' doesn't seem to back changes up if the file is involved in a conflict caused during a pull.
<wgrant> Is that because it tries to avoid backing up changes during merges, and assumes that a conflict could only result from a merge onto a clean tree?
<RAOF> Hm.  bzr-git is now at 10 minutes CPU time and 2GiB RAM useage, but it looks like it's a-workin.
 * RAOF thanks jml for the extra GB of ram.
<RAOF> On the plus side, the ram usage is steadily decreasing.
<bac> hi, is there a PPA for bzr-gtk?
<lifeless> wgrant: we record the hash of files output during merge
<wgrant> bac: https://edge.launchpad.net/ubuntu/+ppas?name_filter=bzr-gtk suggests that there are several official-looking ones.
<lifeless> wgrant: so we can revert cleanly without backups then
<wgrant> lifeless: Right, I've since looked through that code thoroughly.
<bac> thank wgrant
<wgrant> lifeless: Bug #370334
<ubottu> Launchpad bug 370334 in bzr "Reverting a file conflicted from a pull loses changes" [Undecided,New] https://launchpad.net/bugs/370334
<wgrant> lifeless: But you can't revert to the files immediately before the merge.
<wgrant> lifeless: Because they were uncommitted changes.
<lifeless> wgrant: mark it confirmed high :)
<bac> wgrant: doesn't look like any of those support bzr 1.14.
<wgrant> lifeless: Thanks!
<wgrant> lifeless: Er, but I have no bzr Importance privileges.
<lifeless> wgrant: join the team :P
<lifeless> or remind me tomorrow; its late here
<wgrant> lifeless: I was quite surprised to see you around at this hour, yes...
<wgrant> abentley: Thanks.
<abentley> wgrant: np.  Of course, this means I have no plausible deniability when people ask why this bug isn't fixed. :-)
<wgrant> abentley: Heh.
<Kamping_Kaiser> hm... Woudl be nice if bzr fell back to LC_CTYPE=C if nothing else was set :/
<Peng_> What does it do instead?
<GaryvdM> I broke my windows installation, and I'm having some difficulty getting ssh working . Putty is setup, PageANT is running with a new private key, I've uploaded the new public key.
<GaryvdM> But I get bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions
<GaryvdM> How can I debug this?
<Kamping_Kaiser> Peng_, crashes. (this is 0.8, its possible it Just Works in the current release)
<Peng_> Kamping_Kaiser: 0.8 is *incredibly* old.
<Kamping_Kaiser> Peng_, yes, shipped in Ubuntu 6.06 (which this server is running) :/
<GaryvdM> Hmm: I just noticed this error: http://pastebin.com/d3fc9a661
<GaryvdM> Maybe I need to delete all my keys on lp and start over.
<Peng_> Kamping_Kaiser: The PPA might still support 6.06. https://launchpad.net~bzr/+archive
<Peng_> Err./
<Peng_> Kamping_Kaiser: https://launchpad.net/~bzr/+archive
<Peng_> I blame my Internet connection! :P
<Kamping_Kaiser> Peng_, i'll check, thanks.
<GaryvdM> Yhea - ssh working now. :-)
<LarstiQ> beuno: bzr 1.14 is in the non-beta ppa now.
<rockstar> abentley, hey.
<abentley> rockstar: hey
<rockstar> format_registry.aliases() returns a set with three strings in it.  What format strings are those for?  Repositories?
<abentley> rockstar: You're talking about the bzrdir format registry?
<rockstar> abentley, ah, that should make it obvious...
<jam> abentley: ping
<abentley> jam: pong
<jam> did you still want to chat about whatever it was yesterday?
<abentley> jam: sure.
<S11001001> rebase hackers: why is rebase trunk 1.13-compatible and 1.15-compatible, but not 1.14?
<LarstiQ> S11001001: because 1.14 has the same api as 1.13?
<LarstiQ> assuming it checks api compatibility, not bzr version
<S11001001> api
<LarstiQ> there you have it then :)
<S11001001> Unable to load plugin 'rebase'. It requested API version (1, 15, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 14, 0), and the maximum is (1, 14, 0)
<S11001001> and bzrlib/__init__.py has api_minimum_version = (1, 14, 0)
<LarstiQ> S11001001: right, that is a mistake and I'm expecting a 1.14.1 release for it
<S11001001> okay, thanks LarstiQ
<LarstiQ> S11001001: if you're willing, you can safely edit that (1, 14, 0) into (1, 13, 0)
<S11001001> sounds good
<S11001001> merci
<jonnydee1> Hi, I've just checked out (lightweight) the rebase trunk from http://people.samba.org/bzr/jelmer/bzr-rebase-old/trunk because the version available in Jaunty seems not to be compatible with bzr 1.14.
<jonnydee1> The last trunk's revision, however, seems not to be compatible with 1.14, either, because it already requires bzr 1.15. So I tried to get a previous revision using 'bzr pull -r -2' and got the following error message:
<jonnydee1> bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<jonnydee1> Anyone any idea?
<LarstiQ> BasicOSX: what are the 1.14.1 plans?
<LarstiQ> jonnydee1: the error you get because in a lightweight checkout, 'pull' goes to what you're bound to, being http://people.samba.org/.., which is not writable.
<LarstiQ> jonnydee1: you can use `bzr revert` instead to make the tree state be the same as in a prior revision.
<jonnydee1> So a pull is not a readonly operation?
<LarstiQ> jonnydee1: however, bzr 1.14 shoud have api compatility 1.13, instead of the 1.14 it has
<jonnydee1> @LarstiQ: Thanx for your hint
<LarstiQ> jonnydee1: so you can change bzrlib/__init__.py, (1, 14, 0) -> (1, 13, 0)
<LarstiQ> jonnydee1: if pull was a readonly operation, how would it help you? :)
<jonnydee1> I mean readonly in terms of "do not modify the repository I pull from"
<LarstiQ> jonnydee1: the point being that pull operates on the branch, which you don't have access to in this case.
<LarstiQ> jonnydee1: in general, I think it's a very bad idea to use lightweight checkouts over high latency links.
<BasicOSX> LarstiQ:  1.14.1 milestone created, plan? tag bugs to that milestone and discuss when devs happy with bug list for me to make a release?
<jonnydee1> BTW: "bzr revert -r -2" also gives me a bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<LarstiQ> BasicOSX: sounds good. My vote is for the list of changes to be just the api version, we can roll a 1.14.2 later
<LarstiQ> jonnydee1: ah hmm.
<BasicOSX> LarstiQ:  been out of loop for a couple days (real job stuff) 1.14.1 regression release?
<jonnydee1> ok, but I understood that a pull on a lightweight checkout tries to pull into the remot branch :) -- seems pretty logical regaring the fact that a lightweight checkout doesn't have history information...sorry, my fault
<LarstiQ> jonnydee1: I suggest you `bzr reconfigure --checkout`
<LarstiQ> BasicOSX: basically.
<BasicOSX> :-( I'm going to get another condolence email from RMS!
<LarstiQ> BasicOSX: practice makes perfect!
<jonnydee1> LarstiQ: This gives me a bzr: ERROR: KnitPackRepository('file:///home/jonnydee/.bazaar/plugins/rebase/.bzr/repository/') is not compatible with KnitPackRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/') different rich-root support
<jonnydee1> I will just re-checkout the branch
<LarstiQ> BasicOSX: and besides, dealing with issues is more important than never making a mistake.
<BasicOSX> I was joking, it's just funny to get email from RMS on regression releases that say "Condolences on the release"
<LarstiQ> :)
<BasicOSX> LarstiQ:  quick scan of ML doesn't show me the discussion of the regression, what should up? installing from source broken on Windows?
<LarstiQ> BasicOSX: let me check.
<BasicOSX> what should up = what showed up ?
<LarstiQ> BasicOSX: the api_minimum_version thread
<LarstiQ> BasicOSX: which is breaking plugins
<BasicOSX> oh? hmm, I remember that -and- it's my fault, 1.14 should have api of 1.13? 1.14?
 * LarstiQ applies qannotate to bzrlib/__init__.py
<BasicOSX> http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/57260 <- that thread, right LarstiQ  ?
<LarstiQ> BasicOSX: yup
<BasicOSX> Did a bug ever get opened for this issue?
<BasicOSX> does not look like it
<LarstiQ> I don't think we really need it, but that's my opinion.
<LarstiQ> BasicOSX: looking at the diff, between rc2 and final api version changed from (1, 13, 0) to (1, 14, 0). So yeah, roll it back to (1, 13, 0)
<jonnydee1> LarstiQ: Will that change 'rollback from (1, 13, 0) to (1, 14, 0)' be included in 1.14.1? Will it resolve the 'rebase' problem?
<LarstiQ> jonnydee1: yes.
<jonnydee1> LarstiQ: cool!!! :D  You guys are great!!! Thanx for your help!!!
<LarstiQ> jonnydee1: np :)
<jonnydee1> Sorry for annoying you, but I just tried out the new "bzr mv --auto" feature. I created an empty branch, added a text file to it and committed it to the branch. Then I created a new directory, and moved the text file into this new directoy. Afterwards, I did a "bzr mv --auto"...
<jonnydee1> Which resulted in a
<jonnydee1> => new
<jonnydee1> test.txt => new/filew.xml
<jonnydee1> then I did a 'bzr st' and got a traceback.
<jonnydee1> message: "bzr: ERROR: exceptions.IndexError: list index out of range"
<jonnydee1> I think it's because bazaar doesn't add the (still unversioned) directory first...
<jonnydee1> (btw: in my case the directory was called 'new')
<LarstiQ> jonnydee1: a bug report is not annoying :)
 * LarstiQ tries to reproduce
<jonnydee1> ok :)
<LarstiQ> jonnydee1: I believe I followed your recipe exactly, but no traceback.
 * LarstiQ is on bzr.dev
<jonnydee1> ok, I will redo my steps again -- just to make sure I can reproduce this behavior...
<GPHemsley> I just issued the command `bzr log -v -rthread:` to see what it did, and I got a Python traceback
<GPHemsley> Is this a known bug?
<LarstiQ> GPHemsley: looms?
<GPHemsley> LarstiQ: What about them
<GPHemsley> ?
<jonnydee1> LarstiQ: I can reproduce this behavior
<LarstiQ> GPHemsley: I'm not familiar with thread:
<LarstiQ> jonnydee1: can you capture it in a script that I could run?
<GPHemsley> LarstiQ: I'm not, either, but I definitely shouldn't be getting a Python traceback
<jonnydee1> Of course, I am just doing this...
<LarstiQ> GPHemsley: true, true :)
<LarstiQ> jonnydee1: cool
<LarstiQ> GPHemsley: when I run that, I get: No namespace registered for string: u'thread:'
<LarstiQ> GPHemsley: which is supotimal (and reported), but not a traceback
<GPHemsley> LarstiQ: What version?
<LarstiQ> GPHemsley: bzr.dev
 * GPHemsley is on 1.13.1
 * LarstiQ tries with 1.13
<GPHemsley> Perhaps it was fixed already?
<LarstiQ> doesn't happen there either.
<GPHemsley> hmm
<LarstiQ> GPHemsley: does the traceback show it happens in plugin code?
<GPHemsley> this is the error:
<GPHemsley> bzr: ERROR: exceptions.AttributeError: 'BzrBranch7' object has no attribute 'get_loom_state'
<GPHemsley> plugins/loom/revspec.py
<GPHemsley> lines 44 and 51
<GPHemsley> So, I think that's a yes
<jonnydee1> LarstiQ: Here is my script: "bzr init trunk && cd trunk && echo Hello World! > test.txt && bzr add && bzr ci -m "Import." && mkdir new && mv test.txt new/filew.xml && bzr mv --auto && bzr st"
<LarstiQ> jonnydee1: thanks, that does blow up on me.
<jonnydee1> np ;)
<LarstiQ> and I thought I did that manually, hmm.
<jonnydee1> should I report a bug?
<LarstiQ> jonnydee1: yes please :)
<jonnydee1> ok - thanks again for your feedback
<GPHemsley> LarstiQ: I filed a bug: https://bugs.launchpad.net/bzr/+bug/370545
<ubottu> Launchpad bug 370545 in bzr "`bzr log -v -rthread:` fails with AttributeError" [Undecided,New]
<LarstiQ> GPHemsley: I'm reassigning it to bzr-loom
<GPHemsley> LarstiQ: Already did :)
<LarstiQ> doh :)
<GPHemsley> So, what I really wanted was to filter log output for only specific files/directories
<GPHemsley> Is that feature not available?
<LarstiQ> GPHemsley: `bzr log file`?
<GPHemsley> well, more specifically, a specific directory and down
<LarstiQ> GPHemsley: there are some shortcomings, that might be one of them.
<LarstiQ> GPHemsley: Ian has been working on that lately iirc
<GPHemsley> if I do `bzr log .` or `bzr log ..`, I only gives me the results that specifically affected the directory itself... not all the files in it
<GPHemsley> s/I/it/
 * LarstiQ fails to find the relevant emacs page
<jonnydee1> LarstiQ: I've filed the "bzr mv --auto" bug: https://bugs.launchpad.net/bzr/+bug/370551
<ubottu> Launchpad bug 370551 in bzr ""bzr mv --auto" fails with "bzr: ERROR: exceptions.IndexError: list index out of range"" [Undecided,New]
<LarstiQ> jonnydee1: thanks
 * LarstiQ calls it a night
<jonnydee1> no problem :)
<LarstiQ> GPHemsley: I couldn't find a wiki page or bug concerning that atm, maybe Ian mentioned it on t elist.
<GPHemsley> k
<GPHemsley> thanks for your help
<GPHemsley> Is there a way to customize the colors used for bzr cdiff?
<jonnydee1> Hi, just an idea: wouldn't a "bzr-portable-1.xx-x.exe" be a better name than a "bzr-nonadmin-1.14-1.exe"? (Just to make clear it can also be installed on a USB stick.)
<jonnydee1> (erm, I wanted to write "bzr-nonadmin-1.xx-x.exe" instead of "bzr-nonadmin-1.14-1.exe")
<BasicOSX> darn it jam, stop hog'n PQM queue! :-P
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.14.1 released 01 May, 2009 | 1.13.2 released 28 April, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
#bzr 2009-05-02
<BasicOSX> How long is the delay between PQM play to showing up on code.launchpad.net/~bzr/ ?
<lifeless> that will depend on the mirror frequency
<lifeless> the place pqm pushes is http://bazaar-vcs.org/bzr/bzr.(dev|1.14)
<lifeless> and that should be immediate
<BasicOSX> lifeless:  PQM success at 6:23pm CDT merge lp:~tanner/bzr/bzr.1.14.1 http://bazaar-vcs.org/bzr/bzr.1.14, but https://code.launchpad.net/~bzr/bzr/bzr.1.14 still doesn't show the commit
<Peng_> BasicOSX: It was last mirrored 5 hours ago. Is 6:23pm CDT less than 5 hours ago?
<Peng_> BasicOSX: It'll be mirrored again in a few minutes.
<BasicOSX> Peng:  it's 9:56pm now
<BasicOSX> Just getting priv email about 1.14.1 and asking where it is, from what I can tell it's in there, just LP doesn't show it yet via log
<Peng_> BasicOSX: Well anyway it's been mirrored now. You should tell people to use the upstream branch if they want it to be up-to-the-minute.
<BasicOSX> still logs don't show the merge
<BasicOSX> heh
<BasicOSX> nm, helps if I refresh web page
<bob2> nice, bzr conflicts scans for conflict markers automagically
<fullermd> Y'know...   I'm sure S. Turnbull is a smart guy, and I'm willing to believe he's trying to add to a discussion rather than just troll, but sometimes...
<fullermd> Half his mails, I can't tell what he's trying to say, and the half I can figure out always seem to be talking about something totally unrelated to the thread it's posted on.
<davidstrauss> fullermd: totally agreed
<davidstrauss> fullermd: and it doesn't seem like he's putting a completely genuine effort into being knowledgeable on what he discusses
<vadi2> Hi. I upgraded my bzr from the ubuntu ppa, and all of the g* commands broke - it says gtk+ wants an api version of 1, 13, 0 while only 1, 14, 0 is available. But there are no upgrades available.
<vadi2> Is there a package available somewhere else?
<jonnydee1> vadi2: AFAIK this has been fixed in the already released bzr 1.14.1 version
<jonnydee1> but that release isn't available through the ppa repository yet. I guess, you have to wait a few days....
<vadi2> Alright.
<alf_> Hello, I am planning to start a new project using bzr and I was wondering what format is the best to use (for my case). As it won't be made public yet I was thinking of using 1.14-rich-root. Is 1.14-rich-root the format that will be used in bzr 2.0?
<Peng_> alf_: No, something better will be. (Probably --development6-rich-root (which is still experimental, so you shouldn't use it), or it might be modified further.)
<Peng_> alf_: Using 1.14-rich-root sounds okay to me. Although if it's a public project, I'd make the public branches use an older format to be friendly to people with old clients.
<alf_> Peng_: It will be made public at some point in the future, hopefully around the time bzr 2.0 comes out. At this time, I am more interested in forwards compatibility (being able to easily upgrade) so that when bzr 2.0 comes will be able to use the new format without problems.
<alf_> Note, that I don't plan to use svn so I am only going for rich-root because I guess the default will be rich-root in the future (or rather the only option).
<LarstiQ> alf_: for forwards compatibility 1.14-rich-root should be an ok choice (but so should almost all formats)
<LarstiQ> alf_: agreed.
<alf_> Another question: does launchpad currently support 1.14 formats?
<LarstiQ> alf_: 1.14 differs from 1.9 only in the workingtree afaik. And lp supports 1.9 repository/branch format.
<maxb> From the descriptions of the formats in "bzr help current-formats", it sounds like rich-root-pack would be equally as forward-compatible as 1.14-rich-root - is this not the case?
<LarstiQ> alf_: having said that 1.14 is really new. Unless you have reasons to use what it provides I would personally go for something that allows older clients to operate.
<LarstiQ> maxb: that is indeed the case.
<alf_> LarstiQ: eg 1.9?
<LarstiQ> alf_: that, or rich-root-pack for what I'd consider the lower limit.
<jonnydee1> Hi LarstiQ: Would it be possible for you to confirm bug https://bugs.launchpad.net/bzr/+bug/370551 and also classify it to some other 'Importance' state as 'Unknown'?
<ubottu> Launchpad bug 370551 in bzr ""bzr mv --auto" provokes traceback when auto detecting files that were moved to unversioned directories" [Undecided,New]
<jonnydee1> I think, because 'bzr mv --auto' is officially a new feature in bzr 1.14, this bug should be resolved in neear future. Otherwise, I think, 'bzr mv --auto' is unusable...
<LarstiQ> jonnydee1: done
 * LarstiQ goes grocery shopping
<jonnydee1> You're great!!! Thanks a lot :D
<LarstiQ> jonnydee1: still need to fix the bug though :)
<jonnydee1> yes, of course, but now tihs bug will not be "forgotten" :)
<Peng_> Never say never! :D
<LarstiQ> jonnydee1: it helps that you care about it
<jonnydee1> LarstiQ: cool :)
<jonnydee1> Peng_: Never, Never, Never, Never, Never, Never, Never... ;)
<ronny> anyone aware of bzr has a way to plug in "smarter" merge algorithms
<ronny> like take partial/subdir merges into account
<LarstiQ> spiv: if you could advise me on #250451 I'd appreciate it.
<xnox> Can I import pristine-tars into existing packaging branch? I want to get rid of my tarballs/ directory.
<james_w> xnox: not currently
<MattCampbell> Is there a written overview of Bazaar's current repository format, something like chapter 3 of Bryan O'Sullivan's Mercurial book?  I'd like to have some understanding of how files, revisions, and branches are represented.
<MattCampbell> Does Bazaar work with Python 2.6 yet?
 * AmanicA trying to figure out how the config is being reset when running blackbox tests, because I need to do that for rules based config too
<AmanicA> MattCambel: AFAIK it does, the tests pass
<AmanicA> and since I'm on jaunty it seems that I'm using python 2.6
<AmanicA> so it looks like its working
<LarstiQ> MattCampbell: afaik it has had patches to work on 2.7 even. Is there a specific reason you think it might not work on 2.6?
<MattCampbell> When I try to build bzr on Windows with Python 2.6 and Pyrex 0.9.3, I get a TypeError about the arguments to swig_sources
<MattCampbell> bzr 0.14.1
<LarstiQ> 1.14.1 I presume.
<LarstiQ> MattCampbell: did you see John's post about building on windows?
<MattCampbell> No
<TheDJACR> When using bzr distributed, as a team, which is the better choice in section 6.2.5 of the User Guide?
<LarstiQ> MattCampbell: https://lists.ubuntu.com/archives/bazaar/2009q2/057797.html
<LarstiQ> TheDJACR: could you give me a link? I haven't got the User Guide memorized :)
<TheDJACR> LarstiQ: Heh, sure :p. I was reading a paper copy
<TheDJACR> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#organizing-branches
<TheDJACR> Also, are there any Bazaar web portal/project management tools?
<LarstiQ> TheDJACR: it's a bit a matter of taste. If you are dilligently working in feature branches and only commit in trunk to merge them, I'd go with the checkout.
<LarstiQ> TheDJACR: you mean like trac? Redmine works with Bazaar.
<TheDJACR> Cool, thanks LarstiQ
<LarstiQ> (and there is support for trac, but the trac model doesn't mesh well with dvcs, there are users of trac bzr, YMMV)
<TheDJACR> LarstiQ: So I would checkout the trunk, and branch a feature/bugfix. I would update the trunk, merge with the feature and commit the trunk?
<LarstiQ> TheDJACR: merge the feature into trunk, yes
<TheDJACR> Sounds cool.
<TheDJACR> LarstiQ: How would you compare bzr to hg and git?
<LarstiQ> TheDJACR: I can't fairly do that having near zero recent experience with hg and git.
<LarstiQ> I know some things about them, but my knowledge might no longer be up to date.
<TheDJACR> Ok, thanks anyway.
<LarstiQ> TheDJACR: if you have a more specific question, I might be able to answer it.
<TheDJACR> Okay :)
<LarstiQ> TheDJACR: as an example, afaik, git still does (and probably always will) apply a heuristic to detect renames instead of tracking them explicitly.
<LarstiQ> wether that is an issue or not differs for people.
<LarstiQ> TheDJACR: another thing is of course that bzr and hg are mostly written in python. Git used to be shell, c, perl, and more, not sure where it's at now.
<cdecarlo> hi, I want to set up a bzr repository to work with the decentralized workflow, but the docs have me guessing if I create the repos as shown in the solo workflow or the centralized workflow, what should I do?
<LarstiQ> cdecarlo: I'd assume the setup is (nearly) the same. Could you point me at the specific (parts of) documentation that is unclear?
<cdecarlo> LarstiQ, I think what's got me confused is the terminology, here's an example http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id60
<gotgenes> Is there a way to pop off a series of revisions similar to `git reset --hard REVNO`?
<LarstiQ> gotgenes: you'll have to explain what that git command does.
<cdecarlo> LarstiQ, the bzr branch sftp://central... , so I'm understanding that centralhost/srv/bzr/PROJECT/trunk is where all the code is, right?
<LarstiQ> gotgenes: it could be revert, uncommit or pull depending on what reset --hard means.
<gotgenes> LarstiQ: You're at revision 14. You want to go back to revision 11, and you want to remove all commit information from 12, 13 and 14. In this case, you do `git reset --hard 11`
<gotgenes> now you have commit info for revisions 1 through 11
<gotgenes> and 12-14 no longer "exist"
<LarstiQ> gotgenes: `bzr pull -r 11 --overwrite` I'd say.
<cdecarlo> LarstiQ, so on the server, do I first create the project and all it's code in /srv/bzr/PROJECT/trunk?
<LarstiQ> cdecarlo: I would start locally, and then push to the server.
<LarstiQ> cdecarlo: the repository layout on the server would be the same as locally, although without working trees, and having the complete set of interesting branches.
<LarstiQ> gotgenes: `bzr revert -r 11` would be for just making the working tree state be that of revision 11.
<cdecarlo> LarstiQ, ah, so /srv/bzr/PROJECT and /srv/bzr/PROJECT/trunk wouldn't need to exist first on the server
 * LarstiQ slaps self
<cdecarlo> ?
<LarstiQ> gotgenes: sorry, `bzr uncommit -r 11` is more natural.
<gotgenes> LarstiQ: That does get the tree state to r11 but it doesn't remove the commit information
<LarstiQ> gotgenes: correct.
<gotgenes> LarstiQ: Ah
<gotgenes> Yes, that's it, I think
<LarstiQ> cdecarlo: correct.
<cdecarlo> LarstiQ, weird, for some reason I find that unsettling
<cdecarlo> :)
<LarstiQ> cdecarlo: there is nothing technically special about the central server, it is on equal footing with your local branches. It is just easy for us humans to have a blessed central location.
<LarstiQ> cdecarlo: welcome to the world of decentralisation :)
#bzr 2009-05-03
<sveinung> Is author mapping supported in bazaar like it's in git? (for example map user name "fulln" to "full name full@name.com" when importing from svn)
<AmanicA> sveinung:
<AmanicA> I've not heard of it
<lifeless> its not in bzr-svn as that would prevent parallel conversions interoperating
<lifeless> you could in bzr-fast-import by filtering the stream
<AmanicA> interesting
<sveinung> lifeless: thanks
<spiv> LarstiQ: done
<jelmer> james_w, Jc2k: Have you seen this: http://hg-git.github.com/ ? Based on dulwich
<james_w> nice
<james_w> have you tried it?
<jelmer> no, not yet
<jelmer> unfortunately they include their own copy of dulwich
<james_w> a clean copy?
<jelmer> no, with patches
<LarstiQ> sounds useful
<james_w> ouch
<jelmer> I'll send them an email asking them if they're interested in cooperating more closely
<ronny> jelmer: i already bugged them about giving back
<poolie> hello
<mwhudson> poolie: hello
<jml> poolie: hello
<mwhudson> poolie: what's the release schedule for 1.15 looking like?
<poolie> mwhudson: from memory we should be about 3 weeks out
<poolie> jml, did you work out with basicosx if you're driving this one? or the next one?
<jml> poolie: so, start of UDS?
<jml> poolie: I thought I was 1.16 -- I'll double-check the email trail.
<mwhudson> hello
<mwhudson> does anyone know of any medium sized git repos i might test launchpad's new git import service with?
<mwhudson> i'
#bzr 2010-05-03
<thumper> how do I cat a file at a particular date in history
<thumper> where that file may not be in the branch now
<lifeless> bzr cat -r revspec filepath
<lifeless> you can use bzr ls -r revspec to find files present there
<lifeless> thumper: ^
<thumper> lifeless: thanks, I kinda figured that out on my own :)
<spiv> Good morning.
<poolie> thumper: cat -rdate:2010-01-01 file
<poolie> i think so?
<thumper> poolie: yeah, thansk got that
<poolie> sorry, i didn't see the scrollback
<poolie> thumper: export -r REV FILENAME may do it?
<thumper> I just used cat
<thumper> and ls to find the name of the file
<thumper> that had been remvoed
<meoblast001> hi
<meoblast001> i'm having a problem
<meoblast001> i'm trying to get the contents of a file named src/renderer.cpp at revision 30
<meoblast001> wait, hm, i think i just figured it out
<meoblast001> ah, nevermind, guess i was doing it right
<rubbs> meoblast001: if you still need help I'm here.
<meoblast001> ah, i had the file name wrong :P
<meoblast001> it was crenderer.cpp
<meoblast001> bzr cat src/crenderer.cpp -r30
<rubbs> cool :D
<poolie> lifeless: when you say "a rewrite rule for squid"
<poolie> this is a rule that says when squid gets request X, it should actually serve and cache the URL f(X)?
<lifeless> yes
<lifeless> this can take two forms
<lifeless> squid can return a 30x to the client, so the client makes a new request
<lifeless> squid can make the new request itself, and returns the result of that request
<lifeless> its the latter form I'm suggesting
<poolie> how will squid know which revid to request?
<lifeless> we'd write a small redirectory
<lifeless> s/y//
<lifeless> which would take urls in, and do the work to decide what url should be used instead
<poolie> ok, so this would be a subprocess of squid that knows how to interpret bzr branches?
<lifeless> yes
<lifeless> squid would run a few of them up
<poolie> hm
<poolie> why not just use an etag to let loggerhead verify the revno page still shows what squid has got cached?
<lifeless> because revno pages are less stable, by being revid keyed we can cache the output of diff/status etc operations for weeks or months with low risk
<lifeless> we may well use an etag *too*
<lifeless> but thats for a different problem
<poolie> hm
<poolie> this seems a bit duplicative
<poolie> between the redirect helper and what loggerhead does
<poolie> i think there is probably simpler fruit first
<poolie> such as just getting a squid at all :)
<lifeless> there is overlap
<lifeless> the benefit is that once a revno->revid mapping is established, no further hits will reach loggerhead for that revno for [mapping cache time]
<lifeless> and further, mapping and rendering are decoupled, so that we don't have expensive rendering logic happening much either
<poolie> hm
<poolie> if there's a cache time on this, isn't it just equivalent to saying that revno urls are simply cacheable for that period?
<poolie> well, i guess in the case where it misses we'd be doing a lookup in the branch to see if the mapping is still true
<lifeless> right
<lifeless> and the cache time is in squid
<lifeless> we can invalidate it by an api call when the branch has a revno change
<lifeless> [in principle; that might not be as no-brainer as the basic stuff]
<poolie> oh there's an external api to squid to say "drop X"?
<lifeless> eys
<poolie> ok
<lifeless> several
<poolie> i guess you need to determine all possible affected urls
<lifeless> but possibly not for the particular mapping we're talking about
<lifeless> theres also a lightweight 'is this still valid' api using a helper and rss stuff that yahoo built
<lifeless> I don't know if we've integrated that upstream properly yet.
<lifeless> the takeaway though is - some infrastructure in squid, policy in bzr, win.
<lifeless> :P
<lifeless> I'll reach st leonards on the 1:05 trani
<poolie> hm
<poolie> can you defer that
<poolie> i need to do some errands for stephane before i leave
<lifeless> the train? sure. or I can hack-in-sunshine if the deferral is minor.
<lifeless> I'm coming from mount colah, so outside the high frequency train zone
<lifeless> ok -> train
<poolie> nice mail there
<poolie> hi spiv?
<spiv> Hi poolie.
<parthm> I am thinking of landing the approved mp https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290 using ./feed-pqm
<parthm> is there anything i need to consider or is it simply a matter of running the ./feed-pqm command?
 * parthm hasn't done this before.
<spiv> parthm: are you asking about how to use feed-pqm, or about our policies about what proposals are ready to land?
<parthm> spiv: more about how to use feed-pqm. I am assuming that the proposals that show us as "ready to land" should be ok to land.
<spiv> Yeah, they should be, although some may need conflicts resolved.
<spiv> As far as using feed-pqm goes, run "./feed-pqm bzr"
<parthm> spiv: so the suggested method is that i try the merge manually on my system before submit?
<spiv> You can enter ? at the prompt to get help on the options
<parthm> spiv: sounds good.
<spiv> parthm: no, in fact if you look at the LP page for the proposal it'll mention if there are conflicts, and PQM will obviously fail to land conflicts anyway.
<parthm> spiv: one more question. whats the policy in moving reviewed mps to "ready to land". 2+ approves?
<spiv> So it's typically not worth the effort to do it locally.
<parthm> spiv: ok. that sounds easy enough. i will give it a shot with the documentation proposals.
<spiv> parthm: http://doc.bazaar.canonical.com/bzr.dev/developers/HACKING.html#the-code-review-process
<spiv> "ormally changes by core contributors are reviewed by one other core developer, and changes from other people are reviewed by two core developers. Use intelligent discretion if the patch is trivial."
<spiv> In case you're not already aware of it, you can see the PQM queue (and status of the current job) at http://pqm.bazaar-vcs.org/
<parthm> spiv: just curious. does the queue run tests on win, linunx and mac? or is it linux only?
<spiv> Just on linux (with Python 2.4).  vila has something that runs tests on some other platforms after landing, I don't have a URL for that handy though.
<parthm> spiv: thanks for your help. i will try feed-pqm now.
<lifeless> jelmer: is bug 551362  fixed ?
<ubottu> Launchpad bug 551362 in bzr-builddeb "support upstream/VERSION tags" [Medium,Triaged] https://launchpad.net/bugs/551362
<lifeless> hey
<lifeless> spiv: ping
<lifeless> mtaylor: you might like https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/24578 too
<lifeless> mtaylor: as I recall you struggling with pristine-tar transitions
<mtaylor> lifeless: sweet
<mtaylor> lifeless: I'm maintaining all of my packages using that process now, btw
<lifeless> mtaylor: cool
<lifeless> mtaylor: you should be able to just merge-upstream now; but if you find an old branch youhaven't fixed up yet - that should be much easier for you
<mtaylor> sweet
<mtaylor> lifeless: hey, you know things... any ideas on how I might actually sensibly use launchpadlib via jython in hudson?
<mtaylor> lifeless: I poked at it some today and did not get very far
<lifeless> mtaylor: offhand it should be compatible with jython; did the basics work ?
<lifeless> mtaylor: if they didn't (just doing a repl loop in netbeans or whatever) - file a bug
<mtaylor> lifeless: well, getting it going just basically was very hard
<mtaylor> lifeless: lucid ships python2.6 and doesn't have a 2.5 package anymore
<mtaylor> lifeless: also, lucid ships very old jython
<mtaylor> I installed recent (2.5) jython from python.org, but it does not understand .pth files or any of the places debian puts python files
<mtaylor> so really it's just one big giant mess
<lifeless> file a bug
<lifeless> its probably the mother of all bad ideas, setuptools, all over again.
<mtaylor> I started trying to build a pythonpath so that jython could find everything, but then I got eaten by the fact that python system libs were 2.6, which meant jython couldn't read the site.py
<mtaylor> yup
<mtaylor> very much setuptools, combined with python-support  let's add 7 more search directories
<mtaylor> my next thought was building a virtualenv and installing stuff into that, which I'm doing on a different machine :(
<lifeless> mtaylor: also #launchpad-dev
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/574236 - sorry for the delay; yak shaved by filing a bug on malone ;)
<ubottu> Launchpad bug 574236 in bzr "repository.refresh_data() cannot be called in a write group" [Wishlist,Confirmed]
<spiv> lifeless: heh :)
<poolie> hi there spiv
<vila> hi all !
 * vila crosses fingers after the repeated crashes in the last hours
<lifeless> hai
 * vila blesses its mail client for its autosave feature :-/
<lifeless> vila: s/its/his/
<vila> grr, lifeless: thanks :)
<lifeless> vila: its is for non gendered things ;)
<vila> lifeless: I blame the crashes that directly attacked my sanity :)
<parthm> hello. i am trying to feed-pqm proposal https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290
<parthm> it doesn't seem to be working. this is what i did. http://pastebin.com/pG7K4amn
<parthm> it doesn't show up in the queue and i didn't see any mails. should i be doing something differently?
<spiv> parthm: that looks ok to me.  PQM ought to send you a mail if it has rejected your request for some reason.
<lifeless> parthm: you're not authorised to send via PQM email, are you ?
<parthm> lifeless: i am not sure. i am just using feed-pqm.
<lifeless> parthm: if you haven't given your GPG key to the losas to install on balleny, you can't submit things to land.
<lifeless> parthm: this is something that the API based feed-bzr fixed, but we're disabling that.
<poolie> i think i did add his key previously
<poolie> perhaps not
<spiv> Either way, PQM ought to send a reply saying what happened.
 * spiv takes the opportunity to tweak the commit message on that merge proposal ;)
<poolie> according to my mail, that  key is authorized to commit
<lifeless> oh, ok
<lifeless> parthm: have you configured outbound email on your machine ?
<lifeless> is it perhaps stuck in a mail queue ?
<parthm> i tried it earlier today but nothing happened. so i tried it again right now (after doing an "approve" of mp just in case).
<lifeless> I don't see anything from the pqm cron server
<parthm> lifeless: i don't remember explicitly configuring outbound email. let me see.
<parthm> spiv: :)
<parthm> lifeless: outgoing mail isn't configured on my system. would that cause a problem?
<lifeless> feed-pqm is trying to send an email
<lifeless> I'm surprised you're not gettnig an exception
<parthm> lifeless: i will try to configure exim and try again.
<lifeless> parthm: you can just configure your normal SMTP server using bazaar.conf
<lifeless> parthm: see bzr help configuration
<poolie> iow you can ask bzr to send direct to your company's or isp's smtp server
<parthm> the patch seems to have gone to the queue http://pqm.bazaar-vcs.org/ but i haven't seen the mail yet. it will probably come. :)
 * parthm just configured thunderbird as the default mail client.
<parthm> spiv, lifeless, poolie: thanks for your help.
<lifeless> ok, EOD for me
<poolie> parthm: ok, it's running, you should get mail when it either succeeds or fails
<parthm> poolie: great. thanks.
<jelmer> lifeless: hi
<jelmer> lifeless: bug 551362 is fixed in bzr-builddbe trunk
<ubottu> Launchpad bug 551362 in bzr-builddeb "support upstream/VERSION tags" [Medium,Triaged] https://launchpad.net/bugs/551362
<MvG> Hi! Wrt https://code.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/+merge/23970 I'm looking for a suitable name for a function that does Branch.open if --directory is given, BzrDir.open_containing_tree_or_branch otherwise. Preferrably not too long. Opinions?
<bialix> heya
<MvG> vila suggested "_open_containing_tree_or_branch_for_directory" but to me that implies that --directory would find containing bas well, which is not what I implemented, so I'm looking for better alternatives. Listed a few in a comment on that merge request.
<MvG> hi bialix!
<bialix> MvG: hi
<bialix> MvG: I have a strange problem with my machine where trac and trac-bzr hosted
<bialix> MvG: it could be unrelated to trac-bzr of course, I just don't know how to track it
<bialix> every week I'm packing entire trac repo for archive reasons
<bialix> last weeks every time I do this I'm get disk error from inside branch metadata (often branch.conf)
<bialix> scandisk helps in those cases and fix the problem
<MvG> disk error? Sounds very hardware-ish.
<bialix> but I'm a bit worried of this
<bialix> not really disk error
<bialix> windows can't read the file, and then scandisk reports about fixing incorrect index entries (this is NTFS disk)
<MvG> Only thing I can imagine would be kept locks or similar.
<bialix> the disk itself is brand new, the other hardware is not
<bialix> MvG: is there any dangling branch references left inside trac-bzr when doing timeline with repository checkins?
<MvG> trac-bzr should perform read-only access to branch.conf at the most, I'd say.
<bialix> so it could be bzr server, oh well
<bialix> strange thing -- the errors often arised in the non-active branches
<bialix> that's why I'm not sure it's bzr serve
<MvG> bialix: You could enable the memory leak detection code in trac, see if that has anything to say about dangling references.
<bialix> how?
<MvG> bialix: http://trac.edgewall.org/browser/branches/0.11-stable/trac/web/main.py#L425
<bialix> 0.11 only?
<MvG> bialix: Dunno, guess newer ones should have it as well.
<poolie> MvG: open_directory_dwim?
<poolie> open_dash_d?
<bialix> MvG: thanks, I'll try to use it and see what it say
<MvG> poolie: Maybe. Problem is that there are other similar open thingies that require working trees.
<MvG> poolie: And that it does open even in cases where --directory wasn't given at all, in which cases it takes the argument into account.
<MvG> vila: Currently discussing function name alternatives for https://code.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/+merge/23970 as I'm not perfectly happy with your suggestion.
<MvG> poolie: So maybe open_branch_dash_d?
<poolie> it's not great, just an idea
<MvG> I tried _open_directory_or_containing_tree_or_branch and found that in that case I can keep to 80 cols with a single escaped line break. Anything lonmger maks the code really really ugly.
<vila> MvG: (hoping to avoid crashes), from your names I think I'd prefer (2) (sorry I'm still recovering from crash and I don't remember it more precisely)
<vila> MvG: But, I wonder if the issue is not a deeper one,
<MAfifi> Is there a way to list the branches in a bazaar repository?
<MvG> vila: I think I'm in favour of (2) as well. Thx. will push that and set state to needs-review.
<vila> roughly, we don't *require* the directory because we deduce it from the path and to achieve --dir support we may want to change that,
<vila> i.e. if the user tell us: here is my branch root, don't guess
<vila> then instead of *adding* a new funtion/method, you may want to inspect the existing open_containing_* ones and see if you could address that at this lower level
<vila> this would also means *less* tests since once you're happy with the tests in the open_containing_* methods, there is little point in testing all their call sites
<vila> MvG: does that make sense ?
<MvG> Doesn't feel right: the semantics here, with the --directory option, are specific to command line interface, while the underlying open methods are generic bzrlib, and clobbering them with command line special cases feels bad. So I'd prefer a function in builtins.py.
<MvG> And there is still the chance of commands doing funky things with their arguments besides opening a branch, as I experienced in the case of the added builtin.
<MvG> So the tests do make kind of sense, I fear.
<vila> well, the tendency should be to *reduce* the specifics in builtins.py since that smells like lack of feature in bzrlib
<MvG> vila: On the other hand, providing several different ways to achieve a goal is probably a good thing for a command line interface, where you want to support anything that users might naturally expect to work. For the API that kind of redundnancy would be bad design, I'd say.
<vila> yes, some commands may do fancy things, I view your work on the --directory option as the perfect occasion to unify our behavior here (but that doesn't mean you have to address all of them in your proposal)
<vila> MvG: Well, having an optional directory short-circuiting the branch root guess is not *that* bad, there are just different ways to find it
<vila> there are other part of the API that already do that kind of thing
<MvG> vila: OK, if you want it in the BzrDir.open_containing_tree_or_branch method, I can put it there. But in that case I guess I'd name it branch_location or similar, as the --directory option from the command line isn't exactly fitting, since remote URLs work just as well.
<vila> my feeling is that there are already too many open_containing_tree_or_branch_or_repo_or_whatever variations that may be simplified there
<vila> MvG: I don't have a strong feeling there, I'm thinking out loud (especially with the crashes I'm experimenting this morning, I haven't yet look at the code again)
<MvG> OK. Maybe we should land my branch first, and see about unifying stuff afterwards.
<vila> MvG: exactly what I was about to say
<MvG> The method I introduced starts with an _, so it should be easy to drop it without a compatibility stub when we have a better solution.
<MvG> s/method/function/
 * vila shudders with ease, yeah, leading '_' are *good*
<vila> it's far easier to drop one than to add one
<MvG> vila: OK, I pushed a function rename and a NEWS item, and would like to see the thing merged soon. I assume you'll want to recover from your crash first. And it seems LP is taking some time to update stuff today as well.
<vila> MvG: I'm reviewing right now
<vila> MvG: out of curiosity, are you using jam's update_copyright plugin ?
<MvG> vila: no, did that manually.
<vila> MvG: ok, you may want to give it a try then :)
<MvG> LP is taking really long today to update branches... :-(
<poolie> hm, you could tell them
<poolie> they changed something that's supposed to eliminated delays
<poolie> there may be some fallout
<MvG> poolie: OK, mentioned it in #launchpad.
<vila> MvG: hmm, "the --directory option from the command line isn't exactly fitting, since remote URLs work just as well."
<MvG> vila: Agreed. Do you think it should be renamed to --branch in these cases?
<MvG> vila: In bug #559998 poolie suggested reuse of the --directory option.
<ubottu> Launchpad bug 559998 in bzr "bzr cat should accept --directory" [Low,Confirmed] https://launchpad.net/bugs/559998
<vila> MvG: I think we had this kind of discussion in the past and 'location' has been used instead...
<vila> but...
<vila> sometimes it's used for tree so branch doesn't fit either, directory may be the best after all
<vila> and '-d' also has an history in other tools so...
<vila> --base c oming :(
<MvG> vila: So we keep --directory/-d for now, knowing that it is somewhat inaccurate?
<MvG> vila: Or do we introduce a location option, which has directory as an alias, and still uses -d for compatibility?
<MvG> vila: except that Option doesn't allow for aliases...
 * MvG just notices that vila has left the room... :-(
<vila> grr, add one more crash
<vila> MvG: so --base may be considered, but --directory still sounds like the best choice
<MvG> vila: I had addressed some lines to you while you were away. I'll repeat them below:
<MvG> vila: So we keep --directory/-d for now, knowing that it is somewhat inaccurate?
<MvG> vila: Or do we introduce a --location option, which has --directory as an alias, and still uses -d for compatibility?
<MvG> vila: except that Option doesn't allow for aliases...
<vila> MvG: my main hesitation comes from the compatibility issue, if we start with --directory we have to stick to that,
<lifeless> jelmer: then the status needs updating ;)
<MvG> vila: Yes, that has me somewhat worried as well.
<vila> having aliases just because we're not sure about the best name is asking for trouble down the road and just exposes our doubts.
<vila> Let me check where we use location
<MvG> vila: afaik only for args, not as an option...
<vila> MvG: and for config vars
<vila> I think the rationale there was because directory sounds like a local thing as opposed to a remote thing
<MvG> vila: There is a global --basis option registered, but it seems no command actually uses it.
<vila> --basis is for merge purposes AFAIK
<vila> MvG: So, I think --directory is fine, we may want to explain whether it applies to branch or tree for some commands but that should be all there is to it
 * vila blesses *his* mail client again, the review is not lost
<MvG> vila: One problem is that one globally registered option has one global help string to go with it.
<vila> MvG: the command help itself then ?
<vila> MvG: *in* the command help itself then ?
<MvG> vila: So if we had --base (-d) alongside --directory (-d), we could simply use different documentation for these as well, which is much more problematic with a single option.
<vila> nah, forget --base, it's as abstract as --directory but without history
<vila> MvG: Anyway, this is targeted at people who want to be explicit, it's not as if they didn't know what there are talking about
<MvG> vila: One could use custom_help for individual commands, but that would introduce quite a lot of redundancy.
<MvG> That's what http://bazaar.launchpad.net/~gagern/bzr/bug527878-directoryCommonOption/revision/5172 does to preserve current trunk behaviour.
<MvG> vila: One good argument for using --directory in all cases is that there might be cases where we require a working tree now but find a sensible application to remote branches in the future.
<vila> I'm sure we can find a way to describe the option intent around: paths given to command either deduce the branch/tree they are in or respect the --directory option
<vila> and in that case are relative to it
<vila> blah, in correct english :)
<MvG> Where would you put that help description?
 * vila reading revno 5172
<MvG> And it doesn't help users figure if remote branches are allowed for a given command or not.
<vila> MvG: I find revno 5172 very good, there may be a bit of duplication but I really don't care at that point, I don't have problems with duplication in doc, as long as it's kept consistant
<vila> MvG: I.e. custom_help looks like the perfect solution
<vila> so forget my remark about the generic definition or maybe just add a comment before the 'directory' definition in bzrlib.option explaining how it's intended to be customized
<MvG> OK. Then we might fine-tune the documentation in the future to convey more information as to where branches are acceptable.
<vila> MvG: yes. Keep in mind to check for cases where *two* --directory options may be needed (hopefully none)
<vila> MvG: 'bzr diff' comes to mind but we already have --old --new there
<vila> MvG: Approval sent, I'm ok with the actual submission (settling on --directory) most of the discussion above is for further work (and thanks again for working in on that ;)
<MvG> vila: thx for the review!
<vila> MvG: Will have a look to the bash completion one now
<MvG> Great!
 * MvG has got to go
<MvG> vila: in case there are questions about the bash completion merge request, please comment on the merge, and I'll deal with it in about two hours hopefully.
<vila> MvG: sure, near lunch time here anyway
<MvG> I guess we're the same time zone. :-)
<parthm> lifeless: looking at the trunk looks like the merge went through. however i noticed that https://code.launchpad.net/~jbowtie/bzr/fix-515660/+merge/24290 still shows status as "approved".
<vila> MvG: 12:30 here
<parthm> lifeless: i also got an empty message from pqm with the subject "no valid commands given".
<lifeless> parthm: thats a bug; the approved thing will depend on lp noticing
<parthm> lifeless: so will it eventually turn to "merged"? just a matter of time?
<lifeless> parthm: yes, a few days :)
<lifeless> parthm: lp is busy right now dealing with maverick
<parthm> lifeless: cool :) ... whats maverick?
<lifeless> the thing after lucid :)
<thumper> parthm: after lucid
<parthm> thumper: aah :) ... i just upgraded to lucid a few days back. look forward to it. thanks.
<rodrigo_> hi
<rodrigo_> I'm getting this message:
<rodrigo_> bzr: ERROR: KnitPackRepository('lp-67245712:///~vcs-imports/couchdb-glib/trunk/.bzr/repository')
<rodrigo_> is not compatible with
<rodrigo_> CHKInventoryRepository('lp-67245712:///~rodrigo-moya/couchdb-glib/optional-introspection/.bzr/repository')
<rodrigo_> different serializers
<rodrigo_> whenever I push a branch branched from a vcs import
<rodrigo_> bzr push again works, but it seems it pushes the whole branch, it takes much more time than when pushing other branches where I don't get those errors
<maxb> Ugh, yes, this is known and annoying
<rodrigo_> maxb, any solution?
<maxb> You can't stack a 2a format branch on a 1.x format branch, which is what's trying to happen here
<rodrigo_> ah, the vcs-import is 1.x, I guess?
<maxb> Unfortunately, since bzr 2.x defaults to using 2a, the workflow of "bzr init-repo; bzr branch" tends to lead people to unwittingly create their local branches in 2a format even when the remote trunk is 1.x
<rodrigo_> maxb, so, maybe I should get the vcs-import to move to 2a? is that possible? and how is it done?
<maxb> Ideally, yes, except that would break any existing branches stacked on it
<rodrigo_> you mean branches in active status? or all the previous branches that have already been merged?
<maxb> all of them
<maxb> Anyway, the solution for the moment is to not use 2a format for this project
<maxb> As for the migration, you should probably ask on #launchpad about this problem during UK working hours, or file a Launchpad question
<rodrigo_> ok, not a big problem though, so I guess I can keep pushing twice for no
<rodrigo_> w
<rodrigo_> maxb, another question, about bzr-git
<rodrigo_> do you know anything about it?
<Tiibiidii> hi, can someone help me? i'm trying to push to the same repository with 2 different users
<Tiibiidii> but one of the 2 constantly keeps creating files
<Tiibiidii> with its own permission
<Tiibiidii> (thus making the repository unusable for the other)
<Tiibiidii> (one of the culript files is .bzr/repository/pack-names ... but it isn't the only one)
<Tiibiidii> (i've already tried googling the problem to no avail)
<Tiibiidii> (in fact i've found that in this page: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial  it says that " When Bazaar writes to control files, it tries to make their permissions consistent with existing files." so this shouldn't be happening )
<Tiibiidii> (currently i don't have a shared repository... i'm using a normal repository and first tried with a lightweight checkout... thought that this may be the cause of the problem... then tried with a full branch...)
<Tiibiidii> (but by pushing from the branch the problem still happens)
<Tiibiidii> anyone?
<GaryvdM> Tiibiidii: what os?
<Tiibiidii> ubuntu
<Tiibiidii> (wait while i'll check the version)
<GaryvdM> thats odd
<Tiibiidii> karmic
<GaryvdM> What transport (file/ftp/sftp)?
<Tiibiidii> currently i'm trying directly through file
<Tiibiidii> (i'm connected via ssh with both users)
<Tiibiidii> GaryvdM, how do you usually setup your repository?
<Tiibiidii> i mean.... push, then ssh to the server, then chown .bzr to a common group between the users like i'm doing right now?
<GaryvdM> Tiibiidii: Yes
<Tiibiidii> ok
<Tiibiidii> where do you usually put your branch?
<Tiibiidii> could this make any difference?
<GaryvdM> I don't think so
<Tiibiidii> (i mean: external fs mounted somewhere... inside the home of some user)
<Tiibiidii> mhn
<GaryvdM> Tiibiidii:  why only chown the .bzr. I would chown the whole branch.
<Tiibiidii> uhm
<GaryvdM> Tiibiidii:  Normally just use sftp
<Tiibiidii> it should be chowned...
<Tiibiidii> i'll check if the whole branch is chowned ok
<Tiibiidii> yes, it is... the folder and all of the direct subfolders are chowned by the common group (with write permissions for the group)
<bialix> heya GaryvdM !!!
<GaryvdM> Hi bialix
<Tiibiidii> GaryvdM,
<Tiibiidii> i tried again
<Tiibiidii> pushed via sftp
<Tiibiidii> then branched locally (unfortunately i don't have the password of the other user... i'm testing while it's logged on)
<Tiibiidii> with the other user
<Tiibiidii> then touched an empty file, added and commited it
<Tiibiidii> but i can't push
<Tiibiidii> now it laments about a .bzr/branch/lock/tmp-something file
<GaryvdM> Tiibiidii: Please pastbin error.
<Tiibiidii> (i haven't tried yet to chown it... but it seems strange to be regarding a lock file)
<Tiibiidii> sure
<GaryvdM> Tiibiidii:  try chown first
<GaryvdM> The lock file would be the first file it would try write to
<Tiibiidii> mhn, but shouldn't a lock tmp file be erased at the end of every transaction?
<Tiibiidii> (now i'll try to chown as before)
<GaryvdM> Yes
<GaryvdM> Tiibiidii:  how is it going
<GaryvdM> I'm going home soon
<Tiibiidii> sorry
<Tiibiidii> for the delay
<Tiibiidii> you know:
<Tiibiidii> the guy who choose the folder/setup for the server
<Tiibiidii> chose to put everything in a /GeoIndex folder -_-
<Tiibiidii> even if this folder has the correct ownership and permissions
<Tiibiidii> it seems that this still causes some problems
<Tiibiidii> i tried it again
<Tiibiidii> by creating the repository on my home on the server (where i can liberally chmod and chown everything)
<Tiibiidii> and now everything's seems fine
<Tiibiidii> thanks anyhow
<mdmkolbe> Where is a good tutorial on the bzr API?  (e.g. if I wanted to write a web based front end to bzr)
<bialix> check this http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#learning-more
<TresEquis> mdmkolbe: and have a look at loggerhead:  https://launchpad.net/loggerhead
<Peng_> TresEquis: Why are you trying to hurt him? :(
<mdmkolbe> bialix: hmm, looks promising.  (but it looks like I'll have to dig to find a way to commit to a branch without checking out a working directory to the filesystem)
<bialix> mdmkolbe: there is preview tree and memory tree
<bialix> try to ask abentley or lifeless for more details
 * TresEquis quotes Santayana here
<TresEquis> "those who do not know history are condemned to repeat it"
<Christoph^> Hi!
<mdmkolbe> TresEquis: I'm not actually trying to create a BZR viewer.  I'm trying to use BZR as a light-weight, ACID, storage mechanism for my web app.
<Peng_> mdmkolbe: There's probably prior work in that area -- ikiwiki and such
<abentley> mdmkolbe, you may also be interested in https://edge.launchpad.net/wikkid/
<TresEquis> mdmkolbe: OIC
<Peng_> Took me a minute to see the pun there.
<Peng_> abentley: Neat. Thanks for the link. :)
<Christoph^> When I want two people to push code to a launchpad project, does that mean I have to create a team for those two people?
<Peng_> Christoph^: If you want them to push to the same branch? Yes.
<Christoph^> And you can't seem to push code directly to a project, only to your own id?
<Peng_> Christoph^: Branches must belong to a user or team.
<Christoph^> ok, thanks
<Christoph^> What would be the advantage of having one branch per person for the same project? (Up to now its only two people.)
<TresEquis> Christoph^: the "main line" branch can be shared, but each developer can push multiple feature / fix branches for the project
<TresEquis> e.g., to let the others review / approve
<TresEquis> for instance, the lp:zope.event branch is owned by ztk-steering-group
<TresEquis> but I have another branch where I was improviing docs:  lp:~tseaver/zope.event/new_style_docs
<TresEquis> which wasn't merged until this weekend.
<TresEquis> (the trunk there is actaully a mirror of the SVN trunk)
<Christoph^> What is the difference between pull and checkout?
<Peng_> One creates a branch, one creates a checkout.
<Peng_> Err, wait.
<Peng_> pull is to branch as update is to checkout.
<Christoph^> And practically? I mean, both gets me a local copy of some foreign branch that can be updated?
<Peng_> Christoph^: If by "pull" you meant "branch", yes.
<Christoph^> no, I meant pull
<Christoph^> ah, pull is to branch as update is to checkout
<Christoph^> ok
<Christoph^> but then there is no real difference between doing a branch and then pulling changes to doing a checkout and then updating changes?
<Peng_> There are differences between a branch and a checkout -- and, um, I'm terrible at explaining things, but there should be some nice documentation somewhere.
<Peng_> But either is sufficient for the requirements you described.
<fullermd> If you do a 'branch', you have two branches.  If you do a 'checkout', you have one branch.
<mdmkolbe> Does bzr handle non-overlapping merges at the server end or do those all have to be done at the client?
<mdmkolbe> (Specifically I'm wondering if I use bzrlib to directly access a repo and two different copies of my program (running at the same time) change two different files, then am I going to have to put logic in my program to do the merge or is that automatic?)
<lifeless> mdmkolbe: so the repo is just a cloud of data; if you change a tree stored in the repo, thats atomic; you'll need to use bzr's merge facilities to join your two changes together, or otherwise arrange them to end up on the same timeline
<lifeless> mdmkolbe: if you're wanting to have your changes appear as changes to a branch, then bzr will force you to be serialised anyway, so you won't need merge logic in your code
<mdmkolbe> lifeless: I'm not sure I understand you.  Is Bzr like Git in that merging two branches is just creating a new tree that happens to point to the two parent nodes (it was probably created via a tree-way merge but Git doesn't know that)?  Or is Bzr smarter about merges than that (the oposite extreme would be Darcs which is structured such that merges happen automatically)?
<james_w> mdmkolbe: like git in that sense
<james_w> the branch can only point to a single revision though
<james_w> so you can happily create new revisions in parallel, subject to locking constraints
<james_w> but if your application requires it then at some point there will have to be a new revisions that references the others if you want them to be tied in to the history of the branch
<james_w> and if both instances will be expecting to update the branch pointer when they add new revisions they will have to serialise and the second will have to merge if your app expects that
<mdmkolbe> james_w: thanks, that makes sense.  two questions though.  First, is there support in the bzrlib API for making doing that merge easy?  Second is there a good quick reference out there for the bzrlib repo format/object model (It would make it easier for me to figure out these things if there were)?
<james_w> mdmkolbe: you mean doing a three-way merge, or just creating a new tree with two parents?
<mdmkolbe> tree-way merge
<mdmkolbe> /tree/three/
<james_w> there are some helpers
<james_w> there's WorkingTree.merge_from_branch() and similar at one level
<james_w> then Merger.from_revision_ids or similar at a lower level
<lifeless> mdmkolbe: theres some object stuff on the wiki
<a212901390231901> is launchpad having issues?
<a212901390231901> https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev <- not updated
<lifeless> a212901390231901: yes
<lifeless> a212901390231901: we just made 20K branches
<fullermd> Ah, spring, that wondrous time of year when every young man's fancy turns to reproduction...
<fullermd> Though most aren't THAT prolific.
<a212901390231901> but it's okay to push new branches and suggest them for merging still?
<lifeless> a212901390231901: yup
<lifeless> james_w: what do you think is wrong with doing the fetch ?
<james_w> lifeless: excuse me?
<james_w> oh
<lifeless> nvm, I see what you meant
<james_w> it's not doing a fetch
<lifeless> I was going to put it in one place and changed my mind.
<lifeless> james_w: I'll get that additional test written today.
<james_w> thanks
<ovnicraft> hi folks, i have symlinks to folders in my repo i added them
<ovnicraft> bzr has any problem with this?
<Peng_> ovnicraft: If the OS supports symlinks, to.
<Peng_> Err, no*
<Peng_> ovnicraft: Checking the branch out on Windows will lead to pain unless you install a plugin to help.
<Peng_> That was a while ago. The situation may have improved.
<jam> hi Peng_
<Peng_> Hii
<jam> I just posted a review changing the History class to use bzr-history-db as the storage
<jam> some numbers, etc.
<Peng_> Ooh. I need to learn what bzr-history-db is. :D
<jam> Peng_: essentially a way to partition history data so that you can share it between branches
<jam> it takes more space initially
<jam> but if you are browsing 20 branches, it is ~1+changes, rather than 20*N
<jam> If I can get a chance, I'd like to discuss it with you, mwhudson, beuno, whoever would be interested.
<jam> I'd like to get some of my patches moving, but I'm not really sure how to do that.
<jam> On the plus side, you don't need to get rid of merge_points, since the db stores information to look it up reasonably efficiently
<a212901390231901> are you still doing a sqlite backend thing?
<Peng_> I'm good at the "bzr merge"ing, not so much at the discussing.
<jam> a212901390231901: roughly, yes
<a212901390231901> I've read what you've posted to the list but not followed very closely
<beuno> jam, I have them in my queue to review. I want to help you move them
<beuno> time has been lacking due to Lucid
<beuno> but should get better now
<jam> So I'm officially switching back to bzr + annotation stuff, but I'm sure that if you need me to do stuff to land it, I'll be happy to work on it.
<jam> just the primary push is done.
<ovnicraft> Peng, so i need a plug to have not problems with symlinks?
<ovnicraft> i need add them, dont want to replicate info in my disk
<jam> what would be *really* nice, is if I could find a way to get a Staging deployment of it, and then replay the requests that go to the regular site
<jam> and see what happens.
<beuno> jam, thanks a lot for all the work, I haven't been very verbose about it, but I'm thrilled you picked it up
<a212901390231901> ovincraft: really, you need the branch you're working on to not contain symlinks at all
<jam> stuff like "browsing 2 related branches" going from 13s down to <1s for the second branch is very nice, but I don't know how often that happens
<a212901390231901> the plugins have big problems, and doing everything through cygwin is a pain
<a212901390231901> symlinks just aren't a windows thing.
<Peng_> ovnicraft: This is only if you need to be able to check out the branch on OSes that don't support symlinks, of course.
<Peng_> Just reading the diff, not the code itself, is "self.get_revid_for_revno([revid])" in http://bazaar.launchpad.net/~jameinel/loggerhead/history_db/revision/415 right?
<ovnicraft> Peng, i am linux user, but trying to add a file inside a folder@ i get this error http://dpaste.com/190495/
<jam> Peng_: well, there are several revisions there. But yes, that is the final implementation.
<ovnicraft> as i see bzr has problems in linux adding symlinks folders
<Peng_> ovnicraft: What exactly are you trying to do?
<ovnicraft> add a file inside folder@
<Peng_> ovnicraft: Add a file inside a directory that is a symlink?
<ovnicraft> yes
<Peng_> Wow. lp:~jameinel/loggerhead/history_db changes a lot of code that I don't think I've ever even read.
<Peng_> ovnicraft: Yes, that sounds problematic.
<ovnicraft> yes but i need it, i want to know if bzr support that actions?
<ovnicraft> Peng_, so i ask you if its supported and maybe i understood wrong but i read that is a OS issue
<Peng_> ovnicraft: You can version symlinks 'til the cows come home, but files inside symlinks? That's just bizarre. I don't know if it's supposed to be supported, but I'm not surprised it fails.
<ovnicraft> i think must be, as example if you are django devel and you want to version an app in different projects that can help you :) BTW i'll fix it placing the info
<Peng_> jam: Hmm, your history_db branch used to have different revisions? "Bring back the small-cleanups branch and restore the removed changes.". What became of that?
 * Peng_ dozes off
<ovnicraft> and as i see my bus is being fixed https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/264275
<ubottu> Launchpad bug 264275 in bzr "bazaar internal error if adding file in a linked directory" [Undecided,In progress]
<jam> Peng_: I only see 4 revisions for lp:~jameinel/loggerhead/history_db, I'm not sure where you are getting that message
<ovnicraft> bug*
<jam> ah, I did do a push --overwrite
<jam> the old stuff was a test
<jam> I nuked it and started from scratch
<Peng_> Oh, good, I hadn't merged the old stuff anyway.
<jam> basically, the old branch was a dogpile of stuff I was working on, I split it out into a bunch of new branches and merge requests, and redid how bzr-history-db integrated
<jam> I'm pretty sure "small-cleanups" was proposed, and I think it was merged
<jam> 408 Ian Clatworthy    2010-04-22 [merge]
<jam>     Merge John's minor cleanups
<Peng_> OK. :)
<jam> anyway, end-of-day for me here, I'll see you all around tomorrow
<jam> Peng_: you may want to look at lp:~jameinel/loggerhead/integration, which is where I put all my stuff together to make sure I'm tuning the right code.
<Peng_> jam: Ah, thanks,
<a212901390231901> what's the right way of spelling "this test needs pywin32" in a test method?
<Peng_> jam: I'm running a few bits of it, but none of the major ones.
<a212901390231901> I currently have the first line as:
<a212901390231901> self.requireFeature(ModuleAvailableFeature("pywintypes"))
#bzr 2010-05-04
<flutherben> Hi all. Hope someone can help me here. I upgraded my box, and now I'm having trouble deploying. When I run "bzr revno http://mydomain/myrepos" I get a transport error
<flutherben> specifically: bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)
<flutherben> nevermind--this is a capistrano error
<lifeless> spiv: hai
<mkanat> Okay, if a merged merge proposal didn't fix an issue, do I submit a new one or just update the existing merge proposal?
<lifeless> new one
<lifeless> reference the old if discussion in it is still relevant
<mkanat> lifeless: Okay, thanks.
<awmcclain> I have a pending merge; I've bzr reverted a file because i needed to temporarily get rid of it. Is there a way to now fetch that file again from the other branch without checking in beforehand?
<lifeless> awmcclain: yesish
<awmcclain> oh, i like ish.
<lifeless> awmcclain: first, a note - if you want to temporarily get rid of things like that, use 'shelve'
<spiv> lifeless: hey
<lifeless> e.g. bzr shelve filename --all
<awmcclain> lifeless: Interesting. Even on a pending merge?
<lifeless> awmcclain: if the file on the other branch wasn't changed in your current branch, you can do 'bzr revert -r branch:pathtootherbranch filename'
<awmcclain> lifeless: That's correct. The file is a new file.
<awmcclain> Introduced by the merge
<lifeless> awmcclain: if it *was* changed in your branch, you can't trivially get the merge back, but donig the revert above and then looking at the diff would let you figure things out
<awmcclain> No, it wasn't changed. Just added. Ok. Great! Thanks
<lifeless> awmcclain: yes; shelve filename == revert filename, except you can get it back more easily.
<awmcclain>  good to know!
<lifeless> awmcclain: where shelve != revert, is when you just do 'bzr revert', because that discards the pendnig merge.
<awmcclain> Didn't shelve use to be a plugin?
<lifeless> awmcclain: yes
<awmcclain> And now is part of bzr?
<lifeless> yes
<awmcclain> Wonderful. Thank you!
<lifeless> spiv: fud ? early avo perhaps ?
<spiv> Hmm, could work.  Here or there?
<awmcclain> lifeless: That revert command worked perfectly. Thank you
<lifeless> spiv: sure
<lifeless> spiv: mt colah's food facilities are, uhm, limited ;)
<lifeless> awmcclain: my pleasure
<spiv> lifeless: ok, so Hornsby somewhere.  Maybe name a time to meet at the fountain?
<lifeless> spiv: looking @ train timetables
<lifeless> dear chityrail, your website is terrible
<lifeless> 1:30 ?
<spiv> Sounds good!
<lifeless> james_w: patch done
<lifeless> spiv: omw
<lifeless> be there in 10-15
<mkanat> mwhudson: https://code.edge.launchpad.net/~mkanat/loggerhead/synchronize-lru_cache/+merge/24651
<lifeless> spiv: do you need a review on that patch?
<spiv> Oh yeah.  Just a sec.
<spiv> lifeless: <https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653>
<lifeless> speaking of cameras
<lifeless> http://gizmodo.com/5529710/59-fiercely-focus-stacked-photos
<spiv> Cute!
<lifeless> spiv: reviewed.
<lifeless> I wants tweak.
<spiv> lifeless: ok
<lifeless> you may find (I hope not) that when you add the all_revision_ids call (and presumably one after or something :P) that it breaks.
<lifeless> spiv: I didn't say this in the review, but hopefully its obvious, that you'll want a commit already present, so actual data merging happens.
<spiv> Fair enough.
<spiv> I did consider constructing a more evil test where I make stream sink and source, and then arrange for refresh_data (and the concurrent fetch) to be done part-way through inserting the stream.
<spiv> But the effort involved didn't seem justified.
<lifeless> I don't expect that to be interesting
<lifeless> because the disk atomicity is well established
<lifeless> and the various bits are pretty well established
<lifeless> but still - nice thinking ;)
<spiv> Right :)
<vila> hi all
<spm> yo vila!
<kizzo> I get an error when trying to use bzr-git to branch the git repository found on here: http://sourceforge.net/projects/unison/develop
<kizzo> On that page, the git repo url is "git://unison.git.sourceforge.net/gitroot/unison/unison"
<kizzo> The command I try is "bzr branch git://unison.git.sourceforge.net/gitroot/unison/unison"
<kizzo> The error I get is "bzr: ERROR: exceptions.TypeError: expected string or buffer"
<lifeless> kizzo: file a bug at bugs.launchpad.net/bzr-git
<jelmer> kizzo: you need a newer version of bzr-git
<kizzo> [ there is more to the error message, but it just explains that it's an internal error, and how to file a bug.
<jelmer> kizzo: urllib's behaviour changed in a minor python release and broke bzr-git
<kizzo> Alrighty, I'll try and update things.
<kizzo> Hmm, I don't know how I would update that though - I ran aptitude update and aptitude safe-upgrade on my Ubuntu Lucid, but I'm already up to date.
<kizzo> I guess I'm going to have to grab the latest tarball from the main bzr-git site.
<lifeless> jelmer: what version fixes it ?
<jelmer> IIRC 0.5.0
<kizzo> I'm not sure - the latest is 0.5.0, and the one installed on my system is 0.4.3
<lifeless> jelmer: I suggest you put a SRU for bzr-git together _asap_ then.
<kizzo> Should I uninstall my version first, before doing "python setup.py install" for the new version?
<lifeless> kizzo: grab the deb package for bzr-git from debian
<kizzo> lifeless: I double-clicked the deb file to install it, but it says error: Error: Dependency is not satisfiable: python-dulwich (>= 0.5.0~)
<kizzo> Boo.
<lifeless> kizzo: that one too :P
<kizzo> Yeah I started figuring - dang.
<kizzo> Things are working now, thanks.
<kizzo> The command works now.
<jelmer> lifeless: I won't have time for that before UDS unfortunately.
<lifeless> jelmer: its actually pretty straight forward to start one - are you positive you don't have time ?
<lifeless> jelmer: how big is 0.4.3->0.5.0; is grabbing all of it feasible ?
<jelmer> lifeless: it's probably too big for a SRU
<lifeless> jelmer: is a backport of that fix feasible ?
<jelmer> lifeless: it's feasible, but nontrivial. The last SRU I did took me an hour or two that I don't have right now (on leave during the last days of the week).
<lifeless> sure
<lifeless> do you remember the bug number of the original report ? or a good search string ?
<lifeless> actually, bug 556968 is it
<ubottu> Launchpad bug 556968 in bzr-git "bzr branch crashes with "exceptions.TypeError: expected string or buffer" when cloning a git repository" [Undecided,Confirmed] https://launchpad.net/bugs/556968
<kizzo> Should I post my solution there?
<lifeless> no, I'll note that down.
<kizzo> Just to mention what I did to fix it.
<kizzo> Alrighty.
<lifeless> spiv: nb: bzr-git(ubuntu) bugs may not be visible to jelmer - you probably want to 'affects project' on them
<lifeless> spiv: I refer to https://bugs.edge.launchpad.net/ubuntu/+source/bzr-git/+bug/532192
<ubottu> Launchpad bug 532192 in bzr-git "bzr crashed with TypeError in open()" [Undecided,New]
<spiv> lifeless: ah right.
<lifeless> (which I've just done)
<spiv> I don't tend to look to closely at if a bug is filed on distro. vs. upstream
<lifeless> indeed
<lifeless> [me neither, not explicitly anyhow]
<spiv> Hmm, it's unfortunate that a test that does "tree = self.make_branch_and_tree('foo'); tree.commit('blah')" can't simply have self.make_branch_and_memory_tree substituted without adding a few lines of boilerplate.
<lifeless> spiv: agreed
<mtaylor> lifeless: can you think of any decent reason why I can't use bzrlib from jython?
<mtaylor> import bzrlib just worked
<lifeless> mtaylor: someone is working on it.
<lifeless> mtaylor: file bugs.
<mtaylor> lifeless: oh neat
<bialix> heya
<mtaylor> lifeless: as in "just try to use it normally and file bugs" or - go find the jython-bzr project and file bugs there?
<lifeless> mtaylor: file them on bzr itself
<mtaylor> cool
<mtaylor> now - to solve jython maven integration...
<lifeless> hi bialix
<bialix> vila: ping
<vila> bialix: pong
<bialix> bonjour vila
<bialix> I'm not quite understand your review
<vila> bialix: which part ?
<bialix> For all *files* you check that the *directory* is not a branch. <-- what do you mean?
<bialix> and I don't understand this: The correct way to do this would be to prune the directory and *all* of its content when it's first processed.
<bialix> at all
<vila> bialix: if you have a nested branch with thousands of files, they are all included in the list you're processing
<bialix> vila: no
<bialix> this is not correct
<vila> bialix: you rely on tree.extras() right ?
<bialix> only the directory with the branch will be in the list
<vila> bialix: no
<vila> at least I don't think so reading the code
<bialix> vila: I'm relying on what clean-tree do before
<vila> tree.extras() filters out all the files present in the inventory but walks the whole tree
<vila> bialix: I didn't say you didn't :)
<bialix> vila: http://pastebin.com/WHDxuCc9
<bialix> there is no entries from nested branch
<vila> bialix: re-read my review, I'm not saying your code is incorrect,
<bialix> vila: I don't see any reliable way to filter out files, other than using isdir() check
<vila> I say it will process too much
<bialix> it will process the list twice
<vila> bialix: once you know a dir is a branch, you don't need to even look at the dir content
<bialix> because actual delete code also checks for file/dir
<bialix> vila: there is no dir content in the deletables list
<bialix> only dir itself
<vila> bialix: ??? you mean if you have '.' you don't have './foo' ?
<bialix> http://pastebin.com/1SHdFxaW
<bialix> I mean if I have foo, I won't have foo/bar
<vila> bialix: even in deletables ?
<bialix> in my understanding bzr won't recurse into ignored/unknown
<vila> bialix: !
<bialix> ?
<vila> bialix: you're right !
<bialix> ok
<vila> bialix: sorry for the noise :)
<vila> bialix: may be worth a comment :)
<vila> bialix: ' bzr won't recurse into ignored/unknown' captures this right
<bialix> okay, will do
 * bialix updating the patch based on the review of vila and partm
<bialix> vila: what should I do for backporting the patch to 2.1 once it will be approved?
<bialix> who is in charge?
<spiv> bialix: there's no-one specifically in charge
<spiv> bialix: simplest is probably for you to make the backport and propose it for merging.
<bialix> so I just will need to file a mp against 2.1, that's all?
<bialix> ok
<spiv> Right.
<bialix> vila: ok, so there is still a problem
<bialix> if foo is unversioned, and foo/bzr is a branch then we happily remove it
<bialix> foo/bar
<bialix> (something strange in the fact that both a and z are so close on the keyboard)
<bialix> but I don't think we want to handle this due the performance as you say
<vila> bialix: it would have been better to start by targeting 2.1, releases branches are regularly (handwaving) merged into trunk
<bialix> I can rebase, perhaps
<vila> bialix: urgh :)
<bialix> :-)
<vila> bialix: kidding, yes, now, rebase is probably the easiest
<bialix> but I don't mind just cherrypick patch to 2.1
<spiv> I just cherrypick in that situation.
<vila> bialix: regarding branches 'hidden' below ignored or unversioned, a FIXME would be welcomed as well
<bialix> vila: http://pastebin.com/rg9h5F1k
<bialix> ?
<vila> bialix: won't skip is unclear, 'we will delete the nested branch' is more explicit
<bialix> http://pastebin.com/B3RhHxgh
<bialix> vila: should I add note about skipped bzrdirs as partm suggested?
<bialix> sorry, parthm
<vila> bialix: well, the second reviewer may have a different opinion but I'll land this proposal and make a new one for that instead...
<vila> bialix: except if it's really trivial to add
<GaryvdM> Hi all
<vila> hey GaryvdM !
<GaryvdM> I'm looking at https://code.edge.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
<vila> GaryvdM: great
<bialix> vila: the problem in the correct wording
<GaryvdM> Is there a guide anywhere to runing the test suit under wine?
<bialix> *is
<bialix> GaryvdM: heya!
<GaryvdM> Hi bialix
<GaryvdM> Hi vila
<vila> bialix: start with Martin's suggestion (was it bzr control component ?), that can be refined later or even tweaked based on the second review
<bialix> I've tested it manuall and I don't like how it mingle with the list of paths to delete
<bialix> lp is rwad-only, does it means I can't push my branch?
<bialix> lp is read-only, does it means I can't push my branch?
<GaryvdM> bialix: yes
<GaryvdM> Seem like we can't pull either
 * GaryvdM is running "wine c:\\python26\\python bzr selftest" :-)
 * bialix hopse GaryvdM has very fast hardware, otherwise he can go for lunch and maybe dinner
<GaryvdM> ah - with -s bzrlib.tests.test_diff
<funkyweasel> Good morning.  I recently upgraded to Ubuntu Karmic and bzr 2.0.2.  Unfortunately our repository server is stuck on Hardy / bzr 1.3.1.  I know find branching and status hellaciously slow.
<bialix> apt-get?
<GaryvdM> funkyweasel:  Are you running a bzr smart server on the Hardy server?
<funkyweasel> We're not able to upgrade the repo server at this time.  Is it a known issue that newer versions of bzr have difficulty with branches generated by older versions of bzr?
<funkyweasel> GaryvdM: No.  But it sounds like a good idea when we move the repo server to the new Ubuntu LTS.
<GaryvdM> funkyweasel:  Please tell us what repo formats the branch on the server is, and the branch on your pc is.
<GaryvdM> funkyweasel:  bzr info -v
<funkyweasel> GaryvdM: repo: Packs containing knits without subtree support, local: Knit repository format 1.  Noted that it took about a minute to count the revisions on local.
<bialix> funkyweasel: you have old format in local tree
<bialix> `bzr upgrade --pack-0.92` on local
<funkyweasel> bialax: Yes, I thought that too.  But if I upgrade using 2.0.2 it becomes incompatible with the repo server.  I can no longer commit.
<bialix> funkyweasel: I've wrote format1 plugin that force pack-0.92 as default
<funkyweasel> Now that I have not tried.
<bialix> funkyweasel:  upgrade --pack-0.92
<bialix> there is explicitly defined the format
<bialix> you have to avoid upgrade to anything newer than --pack-0.92
<bialix> or --rich-root-pack
<GaryvdM> funkyweasel:  -bialix: Please will you do me a favor:  Please run bzr selftest -s bzrlib.tests.test_diff.TestEncodedDiffFromTool in this branch: lp:~vila/bzr/523746-difftool-file-names
<GaryvdM> funkyweasel:  Sorry last msg not for you
<GaryvdM> bialix:  I get this error in wine: http://paste.ubuntu.com/427530/
<bialix> GaryvdM: codehosting is offline
<GaryvdM> bialix: oh forgot that.
<bialix> bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; (10061, 'Connection refused')
<GaryvdM> bialix: I'm not sure if it's wine specific
<bialix> once lp going back online, ping me
<GaryvdM> bialix:  thanks.
<GaryvdM> vila: any idea how to fik http://paste.ubuntu.com/427530/ ?
<GaryvdM> *fix
<vila> GaryvdM: let me check, but from memory the last commit in my branch was trying a different approach and didn't pass tests as I wanted some feedback first
<GaryvdM> vila: Tests work in ubuntu, but not wine.
<vila> oh, failure while *reporting* the failure, different bug, not sure this branch includes the related fix
<vila> GaryvdM: Hmm, I was thinking about reno 5163 on bzr.dev but the fix seems to be present :-/
<GaryvdM> vila: Ok - If don't know - let me debug a little
<GaryvdM> launchpad code hosting back up
<anddam> hello
<parthm> anddam: hi
<anddam> I'm trying to figure out the difference between checkout and branch
<anddam> I read "Core concepts"
<anddam> http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html#centralized says "They run bzr update to get their checkout up-to-date, then bzr commit" but step 1 is checkout
<anddam> is it done only once?
<parthm> anddam: checkout are similar to traditional svn checkout
<anddam> ok I'm fine with that
<anddam> a branch is a "ordered series of revisions", how does that make any difference?
<parthm> anddam: when you commit to a checkout, it is committed to the place from where you checked out. branch commit is local.
<anddam> so "branch" is like "my own branch"
<parthm> yes. branch is your own. checkout is more like central ... with the place from which you checkout being the center.
<anddam> while a commit to a checked out working dir would write on main development repository (or wherever the working dir has been checked out from)
<anddam> thanks
<parthm> yes.
<parthm> with checkout you also have the --lightweight option which is very close to svn/cvs
<parthm> with a branch you will need to either push, or merge into trunk/mainline. checkout commit goes to mainline by default.
<parthm> "bzr help checkouts"
<bialix> GaryvdM: I've ran the test; he same error here
<bialix> GaryvdM: I've ran the test; the same error here
<a212901390231901> <mtaylor> lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
<a212901390231901> now I'm off out.
<GaryvdM> bialix:  thanks.
<bialix> hi a212901390231901 Ð-)
<bialix> hi a212901390231901 :-)
<a212901390231901> that makes a pretty good monster smilie
<bialix> I'd say it was insects smilie
<bialix> in russian
<funkyweasel> bialax: This upgrade is taking an extremely long time.
<bialix> poor lp, it seems to be very heavy loaded
<bialix> funkyweasel: maybe you have a very big history?
<funkyweasel> bialax: I do.  But bzr 1.3.1 seemed to cope with it much better.
<a212901390231901> it's caught up with bzr.dev but not my branch for review yet
<bialix> sometimes it's much easier just to get the new branch from the server, because it seems you have it in decent format there?
<funkyweasel> Oh.
<funkyweasel> It's spent a while 'checking repository format'
<bialix> what?
<funkyweasel> That's the stage the upgrade is on.
<bialix> do you have local branch, not a checkout?
<a212901390231901> bialix, just to clarify on your ctypes-users question, cdll['foo'] code calls getattr which forwards to the same method that cdll.foo uses
<a212901390231901> and now I really have to go.
<bialix> ok
<funkyweasel> bialix: I branched from the local copy and set it upgrading to --pack-0.92 with the intention of then pushing it to the repo server, and binding to that version on the repo server.
<bialix> funkyweasel: how many revisions/files in the branch?
<funkyweasel> In the vague hope I'll get back the old performance I had a week ago on my hardy/bzr1.3.1 box
<funkyweasel> Sadly it's 3976 revisions.  It's an old tree.
<bialix> it's not very big, I think
<bialix> can you look into .bzr.log and see what it doing actually?
<funkyweasel> I'm quite frustrated at how the performance has plumeted since upgrade.
<bialix> vila: ^
<bialix> any hints?
<funkyweasel> bialax: Ah,  xxxx.yyy opening working tree '{branch path}'
<funkyweasel> xxxx is 3058, yyy is 536, both increasing rapidly.
<funkyweasel> I noticed that it seems to go really quick except for the last 900 or so revisions.
<bialix> xxxx.yyy is the timestamp
<funkyweasel> Not revision number?
<bialix> it seems there is multiple opening of working tree. strange. bug?
<funkyweasel> bialix: I don't know.  Is 2.0.2 buggy then?
<funkyweasel> Saddening.
<bialix> bzr has revno either NNN or NN.B.K
<bialix> there is 2.0.5 released
<funkyweasel> It's really impacting my work flow.
<bialix> can you upgrade from bzr PPA?
<funkyweasel> I don't know.  Can I?
<bialix> http://wiki.bazaar.canonical.com/DistroDownloads#Ubuntu
<funkyweasel> At the risk of sounding horribly plaintive - I'd rather like it to work like it used to please.  But progress, I imagine...
<funkyweasel> I'm on the latest for Karmic, my current distro on local box.
 * bialix is not Ubuntu expert, sorry
<funkyweasel> It's taken me nearly all morning to try and get a new branch.  This is highly inefficient.
<funkyweasel> And this checking process is consuming 100%.  Which is also nice.
<bialix> upgrade is one time operation
<funkyweasel> bialax: True.  And it's typically worth it.
<funkyweasel> It's odd how repo versions have broken between 1.3.1 and 2.0.2 though.
<bialix> I can't comment this
<bialix> 1.9 format is very nice
<funkyweasel> The latest one is that?
<jelmer> the latest format is 2a
<GaryvdM> No - 2a is the latest format, but it is a rich root format, and so you wont be able to push from a 2a format to the format on your server
<funkyweasel> Nice one.
<funkyweasel> I think a lot of our problems will be solved once we push our repo server up to the latest Ubuntu LTS and upgrading the branches there.  Trick is 1. waiting for the LTS to be post-launch stable and 2. finding time to upgrade our repo server.
<bialix> funkyweasel: are you upgrading standalone branch or branch in the sahred repo?
<funkyweasel> bialix: Made a local dev branch from the local trunk branch.  Upgrading the local dev branch.  Which is why I am surprised it's taking so long.
<funkyweasel> It's now taken over an hour on this upgrade.  Is this normal?
<GaryvdM> funkyweasel:  Are doing "bzr upgrade --pack-0.92" - Is this normal > think so. It's a one time operation. Go get lunch :-)
<funkyweasel> GaryvdM: Cheers man, and that's an excellent plan.  Unfortunately I have a script that does a mailout that needs to go out as soon as possible - it was due first thing this morning but the format was broken so we've delayed it til it can be fixed.  So... spending all morning trying to make bzr work at the speeds it used to has consumed the morning, pretty much.
<GaryvdM> funkyweasel:  Sorry man
<funkyweasel> No worries.  I should have known this would take a while and put up with the now-ball-crunching slowness of bzr2.0.2 on pre-RichRoot repos.
<GaryvdM> funkyweasel: If you want to stop it, it upgrade creates a backup which you can restor.
<GaryvdM> *restore
<GaryvdM> The outer thing you can try:
<funkyweasel> GaryvdM: True, but it's been going for so long that I don't want to quit it.  I've started working on the local copy of thetrunk so I can actually get something out soon.
<GaryvdM> mkdir temp
 * GaryvdM rather puts this into paste bin
<bialix> funkyweasel: may I ask to send your notes to bzr ML about your experience when it finished?
<bialix> feedback ftw
<GaryvdM> funkyweasel:  You can try this: http://paste.ubuntu.com/
<GaryvdM> bialix: Please check that for me ^
<bialix> GaryvdM: do you want me to pasteyou what?
<GaryvdM> Oh - sorry. This: http://paste.ubuntu.com/427580/
<GaryvdM> This will, rather than upgrade the local copy, just refetch from the server, in the same format as the server.
<GaryvdM> funkyweasel: ^
<funkyweasel> bialix: Sure thing.  Will filter out lightly-stressed incuded btching on my part. :)
<bialix> that's correct
<funkyweasel> GarvydM: That looks promising.
<GaryvdM> vila: could you please do a second review on https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483
<parthm> GaryvdM: thanks for the review.
<parthm> vila: just wanted to point out that line 64-65: unused "from bzrlib import tests" is now gone. i am waiting for branch refresh.
<vila> parthm: just for context, is there some progress bar shown in that case ?
<GaryvdM> vila: Yes, the progress bar shows bellow the message.
<parthm> vila: the message (may take time) is shown. and in the next line the usual progress bar 'fetching revisions' etc. is shown.
<vila> parthm: then I think the 'may take some time' is superfluous, do we use this elsewhere ?
<parthm> vila: i think the intent is that for the user "checkout" indicates a fast operation (unlike, branch). however as checkouts are heavyweight by default they take the same amount of time.
<parthm> vila: hence the message.
<GaryvdM> parthm: Maybe: 'Copying history to "test". To checkout with out copying history, use --lightweight'
<GaryvdM> *without
<vila> parthm: I like Gary's suggestion. My point was that the progress bar *should* tell the user that it will take some time, and after a few seconds he should even feel how much (better than "some")
<parthm> yes. thats fine by me. i will update and push.
<vila> parthm: you have pqm rights now, right ?
<vila> or did I goofed again ? :-D
<parthm> vila: yes. thats working fine :)
<GaryvdM> vila: :-)
<parthm> vila: thanks.
<vila> parthm: cool, so feel free to land
<vila> parthm: I've approved
<parthm> vila: sounds fine. i will update the user message and land it.
<parthm> vila, GaryvdM: thanks guys.
<sangi> when i try to do bzr push, getting an error like bzr: ERROR:parent directory of bzr+ssh:/the/path/of/remote/server/ does not exist
<sangi> can anyone give solution for this error
<GaryvdM> vila: Should I be going through the "Other reviews I am not actively reviewing" section of activereviews, or should I leave that?
<GaryvdM> sangi:  Create the parent dir manually.
<vila> sangi: --create-prefix
<sangi> GaryvdM, how to create parent dir
<vila> sangi: bzr help push, look for --create-prefix
<vila> GaryvdM: that would be nice
<sangi> vila, ok
<GaryvdM> vila: oh - I didnot know about --create-prefix
<vila> GaryvdM: haaa, too clikety-click GUI only guys :-P
<GaryvdM> vila: all of the mp's that I have looked in that section have a review request to a specific person (typically lifeless.)
<vila> GaryvdM: you're done then :-/ Or you can nudge lifeless  :-P
<GaryvdM> vila: Ah - found one that needs a second review
<vila> GaryvdM: don't forget to set the status to 'Approved' when you find (or make) one with 2 approved reviews
<GaryvdM> vila: Or just submit to pqm ?
<vila> GaryvdM: both :)
<GaryvdM> ok
<GaryvdM> vila: Don't you have a all hands this week?
<vila> GaryvdM: no
<vila> GaryvdM: there may be a some hands though :)
<sangi> after pushing the edited source to the remote server using bzr push, the changes are not getting effected in the source which is there in the remote server
<vila> sangi: yes, only the branch is updated, not the remote working tree, you want the push_and_update plugin
<sangi> vila, how can i install it
<GaryvdM> sangi: First, do you have ssh access to the remote server?
<vila> sangi: like all other plugins ?? No wait, what OS are you on, what bzr version are you using ?
<GaryvdM> push_and_update requires
<GaryvdM> push_and_update requires that..
<vila> sangi: and yes, Gary is right, do you have ssh access ?
<sangi> vila, yes i have ssh access
<sangi> bzr version is 1.1
<sangi> vila, using debian
<vila> sangi: 1.1 ??? wow, that's more than old, can't you find a more recent one ?
<GaryvdM> sangi: I dont think that there is a debian package, so the easiest way to install it is:
<sangi> vila ok i will install the latest
<GaryvdM> cd ~/.bazaar/plugins
<GaryvdM> bzr branch lp:bzr-push-and-update push-and-update
<vila> sangi: anyway, it's a unix, so :  bzr lp:bzr-push-and-update  ~/.bazaar/plugins/push_and_update
<vila> ghaaa, bzr *branch* of course
<sangi> GaryvdM, ok
<sangi> vila, ok
<vila> hmm, may be not the best time to use lp :-/
<vila> sangi: note the - and _
<sangi> vila, ok
<GaryvdM> ah - mine is wrong...
<vila> sangi: so, quickly reading the code, 1.1 may be supported, give it a try, you get a new push-and-update command, the regular push receives hook (*this* may require a newer bzr) that will trigger the update if a remote working tree exists
<vila> sangi: if all else fails, what this plugin does is: bzr push ; ssh <host> ; cd <right_place> ; bzr udpate
<bialix> vila: do I need second vote on clean-tree patch?
<bialix> thanks btw
<vila> sangi: and the reason we don't update remote working trees is that... you generally have no working trees there and performance will be bad for most protocols
<vila> bialix: ha, AFAIR you're still a core committer, based on that, no :-P
<sangi> vila, ok
<bialix> vila: yes, my retirement plan has failed.
 * vila evil laugh
<bialix> I hope you helps me to push it into pqm?
<bialix> *help
<GaryvdM> bialix: It's not to hard to setup pqm-submit
<GaryvdM> bialix: it is worth it to.
<GaryvdM> bialix: I can't see that it would be more difficult on windows.
<bialix> GaryvdM: when I was core committer I've sent pqm mails manually
<bialix> I'll delay installing pqm plugin till UDS
<bialix> so smart people will helps me with word and deed
<bialix> never mind my english
<GaryvdM> bialix: I guess you will be able to do submit through launchpad web interface soon...
<bialix> so I can procrastinate more ;-)
<funkyweasel> Goodness me.  That upgrade is *still* going, nearly 3 hours later.
<bialix> funkyweasel: it hurts to hear this
<funkyweasel> I *do* think there's something seriously wrong with this version of bzr and my set up.  There's no way even a point-version should break things this badly.
<a212901390231901> upgrade does take ages, when I upped bzr.dev it was a multi-hour thing
<funkyweasel> This is less than 4000 revisions.  And it did not take this long under 1.3.1.
<funkyweasel> Which, after all this, I am tempted to downgrade back to.
<bialix> funkyweasel: I'd recommend 1.9 at least
<bialix> but it doesnot matter much
<funkyweasel> I think this upgrade has failed.  Nothing is appearing in .bzr.log now, and it keeps spinning on 'checking repository format'.
<bialix> vila: I've set commit message: ``bzr clean-tree`` should not delete nested bzrdirs. (bialix, #572098)
<bialix> is it what you asking me?
<funkyweasel> Oh, but bzr is still consuming 100% cpu.  Which is nice.
<vila> bialix: exactly
<vila> funkyweasel: weird, what was the last thing mentioned in .bzr.log ?
<a212901390231901> I've not been setting commit messages 'cos I don't know if they get the (person) annotation added automatically or not
<a212901390231901> or if I should be adding them manually
<vila> a212901390231901: they do
<a212901390231901> but say, r5200 doesn't have any
<GaryvdM> Hmm - wonder why pqm does not set --author
<vila> a212901390231901: submitted by mail most probably, i.e. not using this field
<funkyweasel> vila: 13231.056  opening working tree '{branch location}', but that's in .bzr.log.old now.  No mention of the operation in the branch on .bzr.log which is as of 1200BST
<vila> >-/
<funkyweasel> {branch location} is actual location of branch, not literal.
<vila> funkyweasel: standalone branch ?
<vila> oh, 1.3.1... geee, what were the progress reporting then...
<funkyweasel> vila: Locally branched from a checkout from a repo running bzr 1.3.1
<vila> meh was
<funkyweasel> 2.0.2 locally.
<vila> and the repository is local or remote ?
<funkyweasel> remote server.
<vila> ouch
<GaryvdM> funkyweasel:  But arent' you upgradeing your local branch?
<vila> what protocol are you using to reach the server ?
<funkyweasel> GaryvdM:  Yes.
<funkyweasel> vila: upgrading locally.
<funkyweasel> to pack-0.92
<vila> hmm, are you sure you're not upgrading both locally and remotely ?
<funkyweasel> Pretty sure, yes.
<funkyweasel> I *think* I understand the problem.  bzr 2.0.2 is optimised for a different type of repo to 1.3.1 and performs inefficiently on the old version.  At least I hope that's what's happening.
<vila> nah, even tht should produce some meaningful output in .bzr.log
<vila> can you do a 'bzr info -v' in this branch and paste the output
<GaryvdM> vila: even while bzr upgrade is running?
<vila> GaryvdM: at worst we'll get a bzr locked error
<bialix> vila: oh, it was my mistake to merge from bzr.dev before doing cherrypick :-(
<bialix> backporting to 2.1
<vila> bialix: told you, should have targeted 2.1 from the start :-O
<vila> bialix: sorry to hear that :-/
<bialix> DaggyFixes, yeah
<bialix> bzr diff -rsubmit: <-- this produce the same patch as mp>?
<vila> bialix: indeed, we still need a good solution for the NEWS entries though
<vila> bialix: if your branch.conf is correct, yes
<bialix> aha, NEWS needs manual editing anyway
<vila> hmm, and will need editing again if you land in trunk, then in 2.1 and finally merge 2.1 in trunk
<vila> if you land 2.1 first, you're done
<vila> well, you have to wait for someone to merge 2.1 into trunk, but NEWS doesn't need to be edited in this case
<vila> funkyweasel: what OS are you on and how did you upgrade to bzr-2.0.2 ? Could that be an extension not compiled related slowness ?
<funkyweasel> ~bin
<funkyweasel> ~paste
<funkyweasel> Tch.
<bialix> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<funkyweasel> Station.
<vila> Station ? Is that an OS ? Nobody never tell me nothing !
<funkyweasel> Sorry, watched Bill & Ted's Bogus Journey again lately.
<funkyweasel> http://paste.ubuntu.com/427662/
<funkyweasel> I'm on Ubuntu Karmic, the distro prior to the recently released LTS version.
<vila> ok
<funkyweasel> Clean install.  using branches checked out from the repo server that's on bzr 1.3.1 results in branches which take an order of magnitude longer to complete basic tasks - diff, status.  Commit isn't noticeably worse, but trying upgrade operations takes longer than three hours.
<vila> hmm, weird, I wonder if the update is really still proceeding or has already complete... 'Packs containing knits without subtree support' *is* pack-0.92
<GaryvdM> vila: note that that pastebin shows new repo version. old repo version was...
<vila> funkyweasel: are the numbers of revisions (branch/repo) the ones you're expecting ?
<GaryvdM> vila: old repo version was Knit repository format 1
<vila> GaryvdM: yeah, so 'bzr info' finds the upgraded stuff apparently, which is why I'm wondering if the upgrade is already complete or not
<vila> I don't remember the upgrade to be that long for packs, I know why it takes longer for 2a but for packs...
<funkyweasel> vila: Sounds about right number of versions.  the upgrade completed, but spent a lot of time 'checking the repository'
<vila> funkyweasel: without displaying a progress bar ?
<funkyweasel> Yup.  Little spinning chap and everything.
<funkyweasel> I'm trying a bzr status on the branch.  Looks like it's still measured in minutes to complete.
<GaryvdM> funkyweasel:  That probably because you still have bzr upgrade running.
<funkyweasel> GaryvdM: Not that I can see in the process list.
<funkyweasel> I killed it after hour 3.
<GaryvdM> funkyweasel:  Oh
<vila> oh
<funkyweasel> But this is the problem.  Branches generated in 1.3.1 and checked out from a 1.3.1 server to local where I am using 2.0.2 seem to perform history-based operations *really* slowly.
<vila> funkyweasel: this 'bzr status' taking minutes, is it for the run after the upgrade or for any run ?
<funkyweasel> Any run.
<GaryvdM> funkyweasel:  Try run bzr status again
<funkyweasel> Same with diff.
<vila> funkyweasel: and what was it before the upgrade ?
<GaryvdM> vila: pack-0.92 did have dirstate right
<funkyweasel> Quickly now.
<vila> GaryvdM: wt6 yes
<funkyweasel> Did it need to generate some cache.
<funkyweasel> Aha.  So let it upgrade, then kill when it's completed but still "checking the repo"?
<vila> funkyweasel: yes, it's .bzr/checkout/dirstate
<GaryvdM> funkyweasel: Yes, thats why I want you to run bzr status again :-)
<funkyweasel> Now it is fast.
<funkyweasel> That is excellent.
<vila> funkyweasel: something happened that I can't explain, I'm tempted to suspect some weird stuff that may not be reproducible, so if it was me, I'll try to redo the upgrade in some scratch dir and see
<funkyweasel> This is most handy.
<funkyweasel> Now I need to see if I can push this *slightly* upgraded branch to the repo server, bind to the repo server and all will be well.
<vila> funkyweasel: packs-0.92 was introduced in... 0.92 so a 1.3.1 server ought to handle it fine
<funkyweasel> It works.  And it is once again the swiftness.  Outstanding!
<funkyweasel> Cheers folks!
<bialix> bzr miss
<bialix> vila: I've got error for https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669
<bialix> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.
<bialix> what I'm doing wrong?
<bialix> does lp:bzr/2.1 is wrong branch?
<GaryvdM> bialix:  It's maybe a launchpad issue. Maybe try resubmit.
<bialix> ah, my branch is not scanned yet: https://code.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir
<bialix> I'm not sure what I can do about this
<bialix> it's stacked on lp:bzr
<bialix> maybe there is problem?
<GaryvdM> bialix: I think just wait
<bialix> I should manually stack on lp:bzr/2.1?
<GaryvdM> I think thay are still creating lots of new branchs for ubuntu m
<GaryvdM> bialix: I would like to talk to you about something.
<bialix> sounds scary
<GaryvdM> bialix:  qlog search is broken in lucid
<bialix> indeed, scary
<bialix> what is qlog search
<GaryvdM> open qlog. type in search box?
<GaryvdM> bialix: It is due to a change in behaviour in fnmatch.translate
<bialix> hmm?
<bialix> python?
<GaryvdM> before fnmatch.translate('abc') = 'abc$'
<GaryvdM> now fnmatch.translate('abc') = 'abc\\Z(?ms)'
<bialix> wow
<bialix> what's it?
<GaryvdM> bialix:  Should we implement our own function
<bialix> that's my first thoughts
<GaryvdM> \Z = end of string
<bialix> (?ms)
<bialix> ?
<a212901390231901> sets flags I think.
<GaryvdM> I'm not sure why it's \\Z
<a212901390231901> because it's not a r"" string.
<GaryvdM> a212901390231901: Ah
<bialix> return fnmatch.translate(wildcard).rstrip('$')
<bialix> we can delete just \\Z(?ms)
<a212901390231901> yeah, re.M (multi-line), re.S (dot matches all)
<GaryvdM> a212901390231901: Do you know what the (?ms) is for?
<a212901390231901> they changed it so you can match newlines in the pattern I guess
<GaryvdM> a212901390231901: Thanks
<bialix> so, our search patterns are never multiline
<bialix> we can add workaround and remove either $ or \\Z(?ms)
<bialix> if this does not sound very ugly for you
<GaryvdM> or just \\Z
<a212901390231901> or add ".*" to the end before translate
<bialix> writing our own parser/translator is not fun, I guess. but we can just copy-paste old code from py2.5 libs
<a212901390231901> blah.*$ or blah.*\\Z will both work
<bialix> now I don't follow
<bialix> why there is required .*
<GaryvdM> a212901390231901:  fnmatch.translate('abc.*') == 'abc\\..*\\Z(?ms)'
<GaryvdM> :-(
<a212901390231901> okay, scratch that idea then.
<a212901390231901> just star? it's turning a glob-looking thing into a re-pattern?
<GaryvdM> ah yes
<bialix> just asterisk
<a212901390231901> bit confusing that it's using search() rather than match() so doesn't need a leading one
<GaryvdM> a212901390231901: We only use fnmatch.translate, and then call .search ourselves.
<a212901390231901> ah, well, if you use match instead, you'd need another star :)
<GaryvdM> yes
<vila> sorry was afk
<vila> bialix: probably lp being a bit slow, just wait
<bialix> okay
<GaryvdM> Is there a way to get public_branch from .bzr/branch/branch.conf to override public_branch from ~/.bazaar/locations.conf
<GaryvdM> ?
<jelmer> GaryvdM: not atm, lifeless was looking into that IIRC
<GaryvdM> jelmer: Ok
<GaryvdM> thanks
<GaryvdM> Will just comment locations.conf for now
<bialix> GaryvdM: so, what's the resolution for a problem with qlog?
<Peng_> jam: ping?
<jam> morning Peng_
<Peng_> Oh hi. :D I didn't really expect you to respond. :P
<Peng_> Wanted to ask about history_db.
<Peng_> Does it handle ghosts and stuff as well as the old code did?
<Peng_> I noticed KeyErrors in two branches, but one of them is most likely corrupt (old bzr-svn) and one of them is an old Arch import, so it's probably a bit funny too, though not corrupt.
<jam> Peng_: I've tested it against bzr itself, which has ghosts.
<jam> So I won't guarantee I've handled all the edge cases, but I should have handled most
<jam> if you have tracebacks, point them my way
<Peng_> The tracebacks are recorded in my gigantic log file; the trick is digging them out. :P
<Peng_> Here's one: http://paste.ubuntu.com/427731/
<jam>  /KeyError<enter>^b ^b ^b V kkkkkkkkk "+y :)
<GaryvdM> bialix: I think I'm going to add on * to the end  of everything.
<jam> ah, the old code just set revno = None for ghosts
<jam> the new one probably gets a KeyError.
<jam> Shouldn't be hard to fix
<Peng_> Oh oh, one of them is in bzr.dev too (one of your revisions, in fact :D ).
<Peng_> This one's caused by annotate_ui, but it's the same line of history.py.
<GaryvdM> Hi jam
<bialix> heya jam
<jam> morning all
<jam> Peng_: yeah, I have 2 revs in bzr.dev that are ghosts
<jam> it was before merge did fetch
<Peng_> Heh, nice.
<Peng_> jam: http://paste.ubuntu.com/427734/ too. KeyError in get_revno on Loggerhead's history.
<jam> Peng_: care to try updating to rev 420?
<jam> or you want the integration branch, just a sec
<jam> k, rev 419 of integration, or 420 of history_db
<jam> hmm.. seems to still be a problem
<jam> checking
<jam> yeah, silly typo
<GaryvdM> vila: would it be ok for me to set https://code.edge.launchpad.net/~spiv/bzr/repo-refresh-data-574236/+merge/24653 to Approved
<Peng_> Ah? Tell me when you've fixed the typo.
<jam> Peng_: 421 of history-d
<jam> pushing now
<Peng_> Got it.
<vila> GaryvdM: I think it's even Merged
<vila> GaryvdM: but yes, it's ok
<vila> GaryvdM: lp is slow these days but it should do this (set to Merged)
<Peng_> jam: Yup, all fixed. <3
<GaryvdM> Vila: I check - it is merged, so I have set it as such :-)
<vila> GaryvdM: thnks
<Peng_> jam: Oh, if you didn't see the email yet, I noticed another traceback too (History._rev_info AttributeError): https://code.edge.launchpad.net/~jameinel/loggerhead/history_db/+merge/24637/comments/61315
<Peng_> jam: Not to rush you or anything. Just sayin'.
<jam> Peng_: thanks for the heads up, always nice to have code poking at other code's private vars :)
<bialix> ~~~
<cobalt_mike> Good morning... has anyone gotten bzrlib to work under Jython? I worked around the requirement for tty/termios but now it needs fcntl or ctypes...
<jelmer> cobalt_mike: afaik we don't use ctypes anywhere...
<cobalt_mike> bzrlib/lock.py
<cobalt_mike> ... requires one of { fnctl, pywin32 or ctypes } for file locking, it seems
<a212901390231901> you need my branch
<a212901390231901> and it still doesn't work very well, partly java's fault, partly bazaar's
<Peng_> cobalt_mike: People occasionally work on making bzrlib fail less on alternate Python implementations. Not sure if they ever fully succeed, though.
<a212901390231901> https://code.launchpad.net/~gz/bzr/noncpython
<a212901390231901> also read this: https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
<cobalt_mike> thanks, reading
<a212901390231901> took me something like 5 months to get a one line fix in jython trunk, so I didn't see much chance of getting quick resolution to the various issues
<cobalt_mike> also, it is possible to build bzrlib such that it has no native os components? (eg., shared libraries)?
<cobalt_mike> wondering if it might be easier to just shell out to the bzr cmdline, now =/
<a212901390231901> for the moment, yes unfortunately.
<cobalt_mike> ugh
<cbz> is there anything that will pack and get rid of obsolete packs?
<a212901390231901> noting on the jython list that you want to use bazaar with it might still be useful though, there have been several people in the past week interested
<a212901390231901> and it might mean they'll actually look at it.
<jam> cbz: in the 2.2 series there is "bzr pack --clean-obsolete-packs"
<a212901390231901> (IronPython started worse off, but have been much more responsive to reported issues, despite not even taking patches)
<jam> but you can also do "bzr pack && rm .bzr/repository/obsolote_packs/*"
<cobalt_mike> a212901390231901: thanks for all the pointers, need to make some decisions now... sigh
<a212901390231901> what bits of bzrlib do you need exactly?
<a212901390231901> if you can skirt past bzrlib.chunk_writer and some other problem areas, I might be able to help
<cobalt_mike> right now, I need basic things: checkout, commit
<cobalt_mike> doing some examination of the working tree
<a212901390231901> well, could try my branch and see how far you get
<a212901390231901> I've got it merged up to trunk locally but haven't updated on lp as there's upstream mess
<cobalt_mike> alright, I'll give it a shot
<a212901390231901> I'm around so yell if you run into any problems
<cobalt_mike> cool, will do
<cobalt_mike> a212901390231901: well, compiled your branch and I've gotten farther than I did with the vanilla bzrlib.. I think I have a bug in my code now. Thanks!!
<cobalt_mike> has anyone used bzrlib with jepp instead of jython?
<kfogel> jam: ayt?
<jam> kfogel: yeah, just saw your message
<kfogel> jam: you mean my email?
<GaryvdM> Hi amanica
<jam> kfogel: yeah, your email
<jam> I responded
<kfogel> jam: cool, that's what I was pinging about.  Thanks.
<amanica> hi GarryvdM
<jam> Peng_: the last traceback you sent me has been fixed, but requires updating both loggerhead and bzr-history-db.
<mkanat> jam: Oh, so bzr-history-db is coming along now? :-)
<jam> mkanat: well, I've specifically integrated it into loggerhead, and I'm responding to fix requests
<mkanat> jam: Ah, okay. :-)
<mkanat> jam: As a loggerhead plugin?
<jam> mkanat: as changing the History class to use it for storage rather than the current sqlite backend
<mkanat> jam: Ahh, okay.
<mkanat> jam: Any reason you didn't use some sort of NoSQL DB instead of sqlite?
<dash> mkanat: that sounds like extra work for no benefit :)
<mkanat> dash: Well, I was mostly just thinking about the fact that the required WHERE conditions aren't that complex, and that it would get us distributed caching if we wanted it.
<mkanat> dash: Which would be useful for scaling loggerhead across several machines simply.
<mkanat> dash: Perhaps it would be simpler to make the loggerhead cache itself into a NoSQL DB or something, since it just has a get() and add() interface currently.
<Peng_> jam: Alright, thanks for the fixes.
<Peng_> jam: I can confirm it's fixed. :)
<jam> mkanat: well, sqlite3 is bundled with python 2.5+
<jam> I don't know of any NoSQL that can make that claim
<Peng_> ........bdb? :D
<jam> so the "no overhead to get loggerhead running on your trivial installation" checkbox is a lot easier to fill with sqlite
<Peng_> Or, no, um, gdbm or whatever the heck it's called.
<jam> Peng_: bsddb ? it is certainly NoSQL, but certainly not something I'd want to use :)
<Peng_> I still think it's interesting that bzr-svn supports tdb now.
<Peng_> Serializing complex things into a string key is almost as ugly as using SQL queries, though. :D
<jam> mkanat: Also, w/ sql it would be trivial to put it into postgres, or probably any other db back-end. Querier is meant to be the public bzr-history-db api
<jam> though I violate that in one place for expediency
<jam> I'll probably fix that eventually
<Kilroo> ...Huh.
<Peng_> Huh?
<Kilroo> Sweet, I just confused myself.
<Kilroo> I think I had some sort of harebrained idea of combining bzr-svn, bzr-hg, hg's convert extension, and...um...possibly some really stupid hooks somewhere to make an alternative to hgsubversion that would get the advantages in communicating with svn that bzr-svn provides with its custom metadata dooflotchies
<Kilroo> Then I tried to figure out what the heck I was smoking and lost my train of thought four times in a row.
<Peng_> Sorry, what'd you say? My brain shuts down when I hear multiple VCSes in the same sentence. ;-)
<Kilroo> Heh.
<Kilroo> Yeah, it drives me crazy too, especially given how we're using svn at work.
<Kilroo> At this point I think my best case scenario is convince them to switch from svn to hg.
<Kilroo> ...hg being chosen over bzr because the eclipse plugin may be critical in getting my boss to consider a change.
<lifeless> Peng_: so bzr-svn shuts you down immediately ?
<lifeless> Peng_: or do you have some actual tollerance :P
<Peng_> Does what shut me down?
<Peng_> :D
<lifeless> multiple vcs's in one sentence
#bzr 2010-05-05
<mtaylor> bzr rebase still occasionally spits this out at me: NoSuchRevision: CHKInventoryRepository('file:///home/mordred/src/drizzle/.bzr/repository/') has no revision ('mordred@inaugust.com-20100420210116-ldo67yidt8wbrs0l',)
<mtaylor> you know, for what it's worth
<lifeless> mtaylor: is there a bug open ?
<mtaylor> lifeless: I feel like I filed one like a year ago
<mtaylor> oh! I suppose I haven't
<mtaylor> there it is
<mtaylor> bug#446075
<lifeless> bug 446075
<ubottu> Launchpad bug 446075 in bzr-rewrite "NoSuchRevision in _iter_inventory_xmls running bzr rebase" [Undecided,New] https://launchpad.net/bugs/446075
<lifeless> heh
<lifeless> spiv: if you could review my stuff branch that would be great. Its all simple stuff. You'll need to merge locally as lp is still swamped :P
<a212901390231901> mtaylor, in case you missed it from this morning:
<a212901390231901> <mtaylor> lifeless: can you think of any decent reason why I can't use bzrlib from jython? <- see https://lists.ubuntu.com/archives/bazaar/2009q4/063999.html
<a212901390231901> and some of the rest of the log may be of interest to you.
<lifeless> a212901390231901: that nick really breaks my mind :)
<lifeless> can I call you ed209 ?
<a212901390231901> I'm happy with any random string of alphanumerics
<spiv> lifeless: Stuff branch?  Heh.  I'll take a look.
<lifeless> yeah its just stuff
<lifeless> anytime I need to read the bzr code to answer a question, I'm fixing docs up
<mtaylor> a212901390231901: neat
<lifeless> spiv: how did that review go?
<lifeless> oh, i see, gary got to it
<lifeless> spiv: however I've pushed more to it this morning already ;)
<spiv> lifeless: I just hit "Save comment" as it happens!
<lifeless> spiv: thanks!
<spiv> lifeless: also, check this out:
<spiv> http://paste.ubuntu.com/428000/
<lifeless> busy busy
<lifeless> spiv: teddy bear time ? [irc]
<spiv> lifeless: shoot
<lifeless> did you see my chat with james_w earlier?
<lifeless> it provides context
<spiv> lifeless: I skimmed it
<lifeless> ok
<lifeless> so, seems to me merge-upstream is /the/ place to put in detection for 'time to do something special'
<lifeless> for joining previously unassociated upstreams
<spiv> Sounds plausible to me :)
<lifeless> secondly, I'm proposing to jsut discard the old file ids
<lifeless> and not rewrite history
<lifeless> as a first-stage 'get things connected' tool
<lifeless> with some logic to handle variations on the theme of 'the distro content is different'
<spiv> Fair enough.
<lifeless> lastly
<lifeless> as a user
<lifeless> would you want a 'go run XXX' or a 'about to do XXX [y/n]', or a 'just did XXX' interaction with bzr
<spiv> It depends a bit on how easy it is to undo.
<mtaylor> lifeless:  'about to do XXX [y/n]'
<spiv> Although if the cost of making a mistake is low, then to some extent the choice doesn't matter.
<lifeless> spiv: uncommit; revert
<lifeless> spiv: as usual ;)
<spiv> In that case, 'about to do XXX [y/n]' sounds good because mtaylor likes it ;)
<spiv> I think that's definitely nicer than 'go run XXX'
<spiv> And probably the 'hey this is a bit unusual, you should know about this' is good.
<lifeless> spiv: btw my branch of hydrazine uses the same message format as pqm when its doing the generation
<lifeless> spiv: so I was confused when you said they were different the other day
<spiv> Hmm, I didn't know that.  I'm pretty sure it's been different at some point.
<spiv> Certainly if your branch is different to trunk, and some devs are using trunk, then that's a problem.
<spiv> (different in how it uses the commit message field, that is)
<lifeless> spiv: poolie was going to merge it, I thought
<spiv> Last I looked he hadn't, but I don't know why there's a delay.
<lifeless> spiv: ETIME probably
<parthm> hello, I sent two proposals (lp:~jbowtie/bzr/fix-555439 and lp:~doxxx/bzr/572092-ignore-dupes ) to queue using feed-pqm.
<parthm> is there supposed to be some time lag before they show up on http://pqm.bazaar-vcs.org/ ?
<spiv> There isn't supposed to be, but there is ;)
<lifeless> yes, 60 seconds
<parthm> spiv: :) i am just try to ensure my setup is fine. ... maybe i will wait for some more time.
<lifeless> plus mail processing time
<spiv> It's usually only a minute or so for emails to be noticed by PQM.
<lifeless> total time should be < 3 minutes worst case, unless your mail setup is terrible.
<parthm> lifeless: 60 sec. hmm ... maybe something is still wrong with setup.
<spiv> lifeless: as an example, notice the commit messages parthm has been setting -- they explicitly include the lp username of the proposer, so they aren't appropriate to use with your hydrazine branch.
<spiv> lifeless: basically, I'd like a time machine so we can skip over these awkward transitional phases ;)
<parthm> lifeless, spiv: i wasn't sure if i should be including lp username or if the queue adds it during commit. should i be doing that?
<parthm> i noticed that the patch i landed yesterday didn't have it so i explicitly put it in today.
<spiv> parthm: with current hydrazine trunk, I think you need to add that name manually.
<parthm> spiv: will do. thanks.
<spiv> parthm: lifeless has a branch that does it automatically
<lifeless> parthm: if you're using my branch, you don't need to add it.
<lifeless> but you use 'e' rather than 's' to send (e for email)
<spiv> It will be nice when that branch is merged into trunk and everyone is using that.
<parthm> lifeless: i am using trunk right now. yes, its sounds like a useful change to merge :)
<parthm> so for https://code.launchpad.net/~doxxx/bzr/572092-ignore-dupes/+merge/24543 i got a mail from pqm that merge failed, conflict in NEWS.
<parthm> its executing "star-merge". what exactly is that? any action on me from this?
<spiv> parthm: "star-merge" just PQM-speak for "bzr merge this branch, please"
<dash> now there's a term i haven't heard in a while
<parthm> spiv: to the right thing to do is to merge locally and push to branch? would i have write access to ~doxxx/bzr/572...?
<spiv> parthm: someone needs to resolve the NEWS conflict for PQM to be able to land it.
<spiv> You can either ask the original submitter to fix the conflict, or you can just do it yourself.
<spiv> You don't have write access to ~doxxx/..., but you can just make your own branch of that and send that to PQM.
<parthm> spiv: thanks for clarifying. i will do it myself. shouldn't be too much work.
<spiv> Unfortunately that's not particularly convenient using LP and hydrazine.  If I were doing it I'd resort to using 'bzr pqm-submit' from the bzr-pqm plugin.
<spiv> You could also do it by creating a new merge proposal on LP for it, I guess.
<parthm> spiv: yes. thats what i just though. a new lp proposal sounds like an overkill. i will try bzr pqm-submit. will the set message be retained?
<vila> hi all
<spiv> Hmm, I guess it would be nice if LP allowed someone from a project's review team to partially take over a merge proposal, i.e. to provide a tweaked version of the branch owned by someone else, but still considered a continuation the same proposal, with the same proposer etc.
<spiv> parthm: no, pqm-submit unfortunately can't get any details from LP.  You have to tell it the commit message and the target branch yourself.
<spiv> (the latter can have a default set in your config files, though)
<parthm> spiv: that would be idea.
<parthm> spiv: ok. thanks.
<spiv> If you use pqm-submit, be sure to use the --dry-run option first to check the result.
<lifeless> so the issue here is that 'review' and 'merge' are conflated.
<lifeless> I've opened a bug in launchpad-code about separating this; adding info to that or to john's existing one about other branch landings would be good
<parthm> spiv: will do.
<parthm> so for 'bzr pqm-submit --dry-run [LOCATION]' should the location be lp:bzr?
<parthm> for trunk
<MvG> vila: good morning to you!
<vila> MvG: _0/
<parthm> spiv: hmm. i am getting an error saying lp:bzr isn't local. am i doing something wrong? http://pastebin.com/DDvz2Pc6
<vila> parthm: your error error is that you don't know that the plugin doesn't allow lp: urls here, you have to use the resolved form (IIRC)
<spiv> parthm: LOCATION is the branch to submit (defaults to the branch in the current working directory)
<vila> s/error error/only error/
<MvG> vila: thanks for the approval!
<vila> MvG: thanks your work :)
<spiv> parthm: I think there's somewhere in the bzr HACKING doc that summarises this
<spiv> parthm: you probably want to set public_branch for your local dirs in your locations.conf.
<spiv> (you can override that as a one-off by passing --public-location to pqm-submit)
<spiv> parthm: e.g. when I run "bzr pqm-submit" in a directory called ~/code/bzr/foo, because of my locations.conf it will automatically know to tell PQM to merge lp:~spiv/bzr/foo, rather than file:///home/andrew/code/bzr/foo
<spiv> (this is the same setting that the builtin "bzr send" command uses)
<parthm> spiv: thanks. i will configure locations.conf.
<vila> MvG: lp:~gagern/bzr/bug560030-drop-completions is superseded by https://code.edge.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 right ?
<MvG> vila: right.
<parthm> spiv: so the public branch with be the trunk i.e. bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ?
<vila> MvG: ok, so can you mark the first rejected and fix the NEWS conflict in the second ? The later will allow anybody to land it (instead of fixing it locally)
<MvG> vila: Done.
<vila> MvG: Yeah ! Thanks !
 * parthm reading releasing.html for configuring pqm-submit
<parthm> vila: sorry to trouble you with so many questions. does this locations.conf seem right for this merge? http://pastebin.com/0Fg2FJPi
<vila> parthm: no trouble, thanks to you for landing stuff !
 * vila checks his own setup for trailing '/'
<vila> parthm: s/parent_branch/parent_location/
<vila> parthm: use http: not bzr+ssh for submit_branch (don't ask)
<parthm> vila: will do. thanks. the dry run seems to have gone through ok.  http://pastebin.com/fB3BkEeF
<vila> parthm: submit_to ? Did you mean post_commit_to ? Anyway it's irrelevant for pqm-submit I think
<parthm> vila: looks like it requires public_branch and not public_location. "bzr: ERROR: There is no public branch set for "/storage/parth/src/bzr.dev/572092-ignore-dupes/"
<parthm> vila: i took the config from http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#starting-a-cycle step 10
<vila> parthm: I said parent_location, public_branch is correct
<vila> parthm: this needs fixing then
<spiv> poolie: how's the other side of the world?
<poolie> lovely
<poolie> crisp and moderately clear
<vila> poolie: hey ! Welcome to my continent :)
<parthm> vila: this looks fine. time to do without the --dry-run.
<vila> winter is making its last attempt, there was snow in the south of France, not seen for... decades
<spiv> Ooh!  Hope it stays that way :)
<vila> spiv: taling to poolie or me ? :-P
<poolie> it was 3C when we landed
<vila> s/taling/talking/
<parthm> vila: nice. it showed up on http://pqm.bazaar-vcs.org/ ... thanks.
<vila> parthm: significant step !
<parthm> vila: :)
<vila> parthm: and compiling already ! Even better !
<MvG> vila: Do you have anyone to suggest as likely second approver of the bash completion plugin merge?
<vila> MvG: lifeless commented on the related one, but his pile is already huge... poolie maybe ? :->
<poolie> i might but i'm not going to be only online briefly/intermittently this wek
<vila> lifeless: can you give a shot at your review queue if only to abstain or nominate some other reviewer ?
<MvG> Because the bzr-bash-completion branch is already 3 revisions ahead of the merge request. Among them a generic ExecutableFeature class taking path into account, which I'd like to submit in a separate merge request once the first one has been landed.
<vila> MvG: You can use the pre-requisite branch attribute on the mp for that (there is a slight risk of divergence if you need to fix some issues on the pre-requisite itself though)
<MvG> vila: I know, but I fear that having too many interdependent merge requests open at the same time might cause confusion and result in all of them getting merged later than if I serialize them.
<vila> MvG: But generally starting new feature branches for stuff like that works better as you can then merge them into your other branches
<vila> MvG: yeah, YMMV :)
<MvG> YMMV?
<vila> MvG: Your Mileage May Vary
<lifeless> vila: my queue?
<lifeless> vila: I think there is only one waiting on me; more-colo
<vila> lifeless: far more
<lifeless> vila: what ?!
 * vila searches the simplest way to find the relevant mps
<GaryvdM> lifeless, vila: https://code.edge.launchpad.net/~lifeless/+activereviews
<lifeless> no, thats bogus
 * vila scratches head.... where are they gone...
<lifeless> I mean, I can abstain.
<lifeless> but in general I'll say if I want things to block, the default should be not to
<GaryvdM> lifeless: https://code.edge.launchpad.net/~amanica/bzr-notification/with_commit_hook/+merge/8166
<lifeless> GaryvdM: yes ?
<vila> lifeless: https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 you voted needs_fixing, I think it's good now
<lifeless> GaryvdM: I did a review on a project I'm tangetially interested in, to help out.
<lifeless> GaryvdM: I can't land stuff there
<lifeless> vila: then land it; if you agreed with my review *and* think the points are addressed.
<lifeless> i wish we still had tweak
<vila> https://code.edge.launchpad.net/~jelmer/bzr/split-subsegment/+merge/23611
<GaryvdM> lifeless: oh sorry. Thats the wrong one. I ment this one: https://code.edge.launchpad.net/~amanica/bzr/rm_dir_with_changed_emigrated_file-129880/+merge/23528
<GaryvdM> lifeless: I think that is ready, but someone has requested your review.
<lifeless> GaryvdM: no they haven't
<lifeless> GaryvdM: I *did* a review, and its been addressed.
<lifeless> vila: I need to look at jelmers updated one; or someone else could look at it.
<lifeless> vila: if you're patch pilot, do feel free to do reviews in such cases ;)
<vila> lifeless: that's the point, I've been piloting for the last two weeks and I'm not doing it this week
<lifeless> vila: ok
<lifeless> vila: anyhow, I don't think saying 'this needs fixing' makes you required to sign off on the final patch
<GaryvdM> lifeless: The reason I though that, is that there is still a date in the Date Requested col, but I now see that the date is before your last review. Sorry.
<GaryvdM> I'll land it :-)
<lifeless> GaryvdM: perhaps file a bug on launchpad-code, clearly that is confusing.
<vila> lifeless: well, voting Needs_fixing means you've invested time to do some analysis, no need to duplicate that effort
<lifeless> vila: but also no need to block
<lifeless> vila: and more eyeballs are good
<vila> lifeless: more eyeballs are good but upcasting a needs_fixing to approve is... subject to too many interpretations and possible abuses, that's why I'm very uncomfortable doing it
<jelmer> lifeless: SRU should probably be possible somewhere before the weekend
<lifeless> jelmer: oh, if you can that would rock; I did move the info around to be more accessible
<jelmer> lifeless: thanks
<vila> lifeless: anyhow, it looks like many reviews I thought were on your queue are not anymore, so I suspect they have been landed and I didn't realize it
<jelmer> in other news, roundtripping support in bzr-git is around the corner
<spiv> I've taken to saying explicitly "this is Needs Fixing, but once you address these issues consider my vote upgraded to Approved."
<vila> lifeless: I had ~8/10 in mind which was obviously wrong
<vila> spiv: yup, I've noticed that and do the same now
<vila> spiv: but it seems that people are still expecting an explicit approve :)
<vila> lifeless: which in turns shows that explicit is better than implicit for reviews too ;)
<lifeless> vila: thus why I want tweak.
<spiv> lifeless: "me too"
<lifeless> spiv: 'affects me' on the bug ?
<vila> lifeless, spiv: metoo, bug # ?
<lifeless> NFI
<lifeless> pretty sure there was one
<vila> MFI ?
<vila> NFI ?
<lifeless> no f* idea ;)
<vila> LOL, I found National Forest Inventory (Australia)
<spiv> vila: https://bugs.edge.launchpad.net/launchpad-code/+bug/373078
<ubottu> Launchpad bug 373078 in launchpad-code "no code review status for 'merge with some tweaks'" [Undecided,Incomplete]
<lifeless> vila: from that bug, quoting abentley: 'I'll give you one guess what *I* suggested we call "needs fixing" :-)'
<vila> lifeless: I was *just* reading that :)
<chx> hi. i would like to remove the changes introduced by revisions 15476-15479 inclusive both ends
<GaryvdM> chx: bzr merge . -r 15479..15476
<lifeless> GaryvdM: not quite - thats half-open
<GaryvdM> lifeless: ? The reverse merge?
<chx> 15475 isnt it
<chx> this does not seem to roll back 15476
<chx> (i will fire someone tomorrow for that commit but for now let's just roll it back)
<GaryvdM> chx: oh - right - sorry
<GaryvdM> lifeless: got it.
<lifeless> -> dinner
<GaryvdM> vila: Active review count = 16 :-)
<vila> GaryvdM: thanks !
<GaryvdM> vila: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669 has allready been reviewed, and just needs approval for 2.1. I'd rather abstain. Can you make a call.
<vila> GaryvdM: done
<GaryvdM> vila: Cool. There are some unlanded approved branches. I'm going to tackel that.
<vila> GaryvdM: excellent ! Stay in touch with parthm, I think he's doing the same
<bialix> heya
<GaryvdM> Hi
<parthm> GaryvdM: I have already landed the ones I was involved with. http://pqm.bazaar-vcs.org/ For https://code.launchpad.net/~parthm/bzr/563646-commit-unicode-message/+merge/23752
<parthm> i am waiting to hear for poolie as he has requested a review.
<GaryvdM> pathm: Ok, cool. I can also see on http://pqm.bazaar-vcs.org/ which ones have allready been submitted.
<spiv> parthm, GaryvdM: thanks!
<parthm> GaryvdM: i don't plan to submit anything today so i think we are good :)
<parthm> spiv: np :) its nice to see the queue become shorter ... thanks for your help getting pqm setup here.
<bialix> hi GaryvdM
<vila> bialix: \o_
<bialix> vila: \o/
 * spiv imagines TCP-over-semaphore-over-IRC
<bialix> what's "all stars party"?
<vila> spiv: :-P
<vila> bialix: at the end of the party, you see all stars
<vila> or something like that :)
<bialix> stars?
<vila> bialix: kidding, music event where all UDS members can play some instrument or another, or just watch, optionally dring some beer
<GaryvdM> bialix: http://daniel.holba.ch/blog/?p=633
<vila> well, drink first, then dring after a few ones
<GaryvdM> bialix: as in rock stars.
<bialix> will abentley rocks?
<jelmer> abentley already rocks
<bialix> ÑÑÑÐ´
<bialix> cool
<chx> gnight, thanks
<GaryvdM> bialix: Would you like me to submit your clean-tree  branches ?
<bialix> GaryvdM: many thanks!
<GaryvdM> Ok
<GaryvdM> Dose anyone have a script that deletes merged branches in a share repo?
<a212901390231901> I just do it manually ;)
<a212901390231901> I guess as you've been on a landing spree you might have a few more than me
<GaryvdM> Yip. Might try write a plugin later.
<bialix> bzr-colo ftw!
<parthm> GaryvdM: I just noticed that ~jbowtie/bzr/fix-555439 is in the queue twice. I am assuming the changes would already be merged after the first time so that 2nd time would be a no op. right?
<a212901390231901> yeah, might get a complaining email though
 * GaryvdM looks
<jelmer> lifeless: btw, I pushed a newer version of my segment url patch a couple of days ago
<GaryvdM> parthm: Thanks for catching that
<GaryvdM> I've got some time to try figure out how to cancel it.
<parthm> GaryvdM: is it required to be cancelled or its just a no op. i would guess bzr should say 'nothing to merge' the second time. but maybe someone who has used the queue more than me can comment.
<sproaty> is there a way to insert revision ID/last modified details etc to a file like svn rev ids?
<parthm> sproaty: bzr help version-info
<GaryvdM> parthm: I would prefer to try cancel it.
<sproaty> cheers, wasn't sure what term to be searching for
<parthm> GaryvdM: yup. even for a no op ... the tests might take time to run ;) ... unless there is a check for that.
 * parthm is interested in how to cancel too ... hasn't done that before.
<GaryvdM> vila: Is it possible to cancel a pqm submission?
<sproaty> parthm, but is there a way to insert the version-info into a file on commit?
<parthm> sproaty: maybe the keywords plugin will be helpful, though i haven't used it myself http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
<sproaty> thanks :)
<parthm> sproaty: alternatively, 'bzr help hooks'
<parthm> sproaty: http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html
<bialix> sproaty: no
<parthm> sproaty: just wondering. what are you trying to do. keywords is generally not considered to be a good idea.
<vila> GaryvdM: no you can't, the dirty trick, if you're fast enough is to push some garbage
<GaryvdM> vila: or delete the branch :-)
<vila> GaryvdM: right :)
<GaryvdM> Oh
<GaryvdM> Not my branch, so I can't :-(
<parthm> vila: what will happen if we just let the second request be? will it be a no-op .. because the changes are already in?
<vila> http://pqm.bazaar-vcs.org/ says Request for non-PQM managed branch.
<vila> GaryvdM: is that the one ?
<GaryvdM> vila: No Num 3
<vila> parthm: if you  try to merge the same branch twice, pqm will say: 'Nothing to merge'
<parthm> vila: will the tests be run?
<vila> GaryvdM: what's the problem there ?
<parthm> again.
<vila> parthm: no
<GaryvdM> vila: duplicate.
<parthm> vila: nice.
<vila> GaryvdM: as in 'sent twice' ?
<GaryvdM> vila: yes
<vila> GaryvdM: no worries then
<GaryvdM> vila: number 6 (Request for non-PQM managed branch) was for --submit-branch=lp:bzr/2.1
<vila> GaryvdM: you may get confusing mails about it, just update your bzr.dev branch to check
<vila> GaryvdM: weird, may be you don't have rights there ?
<GaryvdM> vila: Does pqm understand lp: urls?
<vila> GaryvdM: I don't remember the exact status here, it used to understand them but there were also bugs
<vila> I think that's why I use http: urls now
<GaryvdM> vila: Ok, i'll see what happens, and resubmit if it fails.
<vila> GaryvdM: ok, thanks again
<GaryvdM> vila: sure, np.
<GaryvdM> vila: thanks for the help
<sproaty> just thought it'd be nice to have my files auto have their last revision date stored
<quicksilver> I don't think bzr does RCS/CVS substs
<maxb> sproaty: ooi, why is that useful?
<sproaty> to other developers I guess
<maxb> I'm curious because some people at my work seem to think the same, but they've never really come up with a convincing argument why :-)
<quicksilver> well, it's quite nice to have last modification dates visible on documentation / on web pages
<sproaty> seen some code under svn that does it
<sproaty> or in the code itself :p
<maxb> The problem is that keywords only help you there if it's meaningful to consider the individual file in isolation
<sproaty> it's no big deal, really
<maxb> https://launchpad.net/bzr-keywords exists, but I still maintain that it's a feature people use because CVS had it, not because it's actually useful
 * jelmer thinks maxb has a point
<sproaty> probably not worth the effort
<LeoNerd> If you want to see the last mod. date on a web page, you'll be wanting some kind of web frontend to your VCS, which puts that information around it
<maxb> And moreover, you'll want info about the tree, not about a particular file
<sproaty> my code's only displayed in loggerhead
<maxb> heh, then you don't need keywords at all
<quicksilver> LeoNerd: that's not what I meant.
<sproaty> that damn css bugs where long commit messages overflow into the file list stops me from writing long (i.e meaningful)  commit messages
<quicksilver> LeoNerd: I meant some file or files from a tree might end up being deployed to a visible web page.
<quicksilver> for example, you might use bzr as the versioning system for your personal website, etc.
<Peng_> sproaty: I don't see that issue, but maybe it's just cuz I have a wide monitor.
<LeoNerd> quicksilver: Oh, I see.. Well, again, that's an issue for the surrounding context. My website engine puts last mod date in the page template. :)
<quicksilver> LeoNerd: sure, that's a valid solution but it doesn't mean it's the only solution.
<quicksilver> LeoNerd: there is no law again a plain static HTML websit eyou know
<LeoNerd> No, indeed.. but now you're heading down into really special-cased scenarios
<LeoNerd> It's already handled by a plugin in those corner-cases you need it
<Peng_> sproaty: I know I've read something about that bug, but I don't know if it's been fixed. And I'm officially AFK, so I don't want to check now. :P
<Peng_> sproaty: If you're not running Loggerhead's trunk (lp:loggerhead), it may have been fixed.
 * Peng_ shrugs
<sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/revision/253
<Peng_> Ooh, on the revision page.
<sproaty> sorry
<Peng_> Pah, I'm AFK, I'm AFK! I refuse to get drawn into work. Especially web design, yuck! :P
<sproaty> yeah :(
<sproaty> im pair programming with my boss
<Peng_> Wait...now I'm recompiling software for fun. I don't think this is working out how I intended. :P
<sproaty> so much for AFK :)
<GaryvdM> Hi amanica.
<amanica> Hi GaryvdM
<GaryvdM> amanica: I've finished that fix that I started at the release party.
<amanica> sweet
<GaryvdM> where if you run bzr qcommit . nothing is selected.
<amanica> GaryvdM: I pulled it now, and it seems to work perfectly now. Thanks!
<GaryvdM> amanica: Tell me again about that checkbox that you wanted to add to qcommit. What command line option should it add?
<amanica> its an option I add with my plugin
<amanica> but I've been wondering if commit can support a pre-commit registry
<amanica> then we can have a single --force
<amanica> which will work for all of these types of pre-commit checks
<GaryvdM> amanica:  Does the plugin raise an error if the option is maybe needed?
<amanica> yes if my validations fail, I raise an error
<amanica> thats how you can stop the commit from going through
<GaryvdM> amanica: Ok - I have an idea. Is it a public plugin?
<amanica> So I was thinking we can add a --force which will ignore errs thrown by the pre-commit-hook
<amanica> yes
<GaryvdM> Url?
<amanica> bzr+ssh://bazaar.launchpad.net/%7Eamanica/bzr-text-checker/trunk/
<GaryvdM> amanica: Cool - I'll take a look.
<GaryvdM> amanica: Bye - I'm off to coach at the rink.
<amanica> cool thanks, don't worry too much
<amanica> I think if the core can support it better, we can know better what I need in qbzr
<amanica> bye GaryvdM
<amanica> better url: https://edge.launchpad.net/bzr-text-checker
<Guest36545> i want to remove a subdir from bzr version control.  'bzr rm (.../subdir)' actually deletes the target.  not what i wanted :-/  how do i do it without deleting it?
<dash> bzr rm --keep
<Guest36545> same cmd, bur DELETE is the default?  dangerous ...
<amanica> Guest36545: it only deletes it if it can be done safely, i.e. it can be recoverd from the revision history
<Zathras> hi. what is best (and why): on a shared hosting server with ssh, python, no gcc: virtual python or the system's python? I want bazaar+webfrontend and preferably trac if possible
<Zathras> (hoster is awardspace.com (paid))
<Peng_> Zathras: Best is if you can convince your host to install all that stuff for you -- and keep it up-to-date.
<Peng_> Zathras: Bazaar and Loggerhead (not that it's easy to run in a shared hosting situation, but...) may be a moving target, but at the least they can install all the dependencies, Paste and simplejson and whatnot.
<Zathras> like 0 change a hoster will do that and take responsibility....
<Zathras> I looked at Git and Mercurial before. Although perl and python based I ran into trouble by not having a C compiler available
<Peng_> Git is mostly C,
<Peng_> Neither Bazaar and Mercurial require a C compiler; there are Python versions of all of the C bits.
<Zathras> Mercurial installer insisted on having a C compiler
<Zathras> I was a bit surprised
<Peng_> Zathras: You can pass an option so it doesn't.
<Peng_> Anyway this ain't #mercurial.
<Zathras> yup. Because it did not work for me I started looking at Bazaar. That's why I am asking
<Peng_> Heh, well, it should work in Mercurial. make local --pure or somesuch.
<Peng_> Although that requires make... Hm. setup.py can do it too.
<Zathras> ty
<Peng_> Note that Mercurial hasn't supported this forever, but it's been at least a few releases.
<NET||abuse> arrrg,,, can't remember how to push a new project up to my webserver
<NET||abuse> bzr push bzr+ssh://me@mydomain.com:/var/www/website/src/bzrdir/       does that not do it?
<bialix> where is pqm web-front page?
<bialix> NET||abuse: ater my.domain should be /
<bialix> no :
<Peng_> bialix: http://pqm.bazaar-vcs.org/ ?
<bialix> Peng_: yep,
<Peng_> NET||abuse: Bazaar uses HTTP-style URIs, not SSH or rsync or whatever.
<NET||abuse> aoh
<bialix> it's strange but pqm.bazaar.canonical.com does not work. yet?
<Peng_> Oh, I forgot about the "bazaar.canonical.com" thing.
<NET||abuse> yay, worked,, now how long will this take to push.......
<bialix> GaryvdM: can you send merge request for my 2.1 clean tree patch?
<Peng_> NET||abuse: Depends on your Internet connection, Bazaar version, repo format, and the size of the repo.
<NET||abuse> indeed.
<NET||abuse> slow enough connection. : )
<Peng_> :D
<NET||abuse> borrowed wifi from local cafe :)
<NET||abuse> 2Mbit if i'm lucky
<NET||abuse> hmm, Fetching revisions:Get stream source.... what does that mean?
<NET||abuse> it's been sitting on the above message for a good long while.
<NET||abuse> the .bzr directory is 58MB
<NET||abuse> should it take that long.
<NET||abuse> 37 MB of that is in 58 assets files, big gimp and inkscape drawings
<NET||abuse> large png's
<Peng_> Ah...
<Peng_> Yeah, I think that's been fixed.
<NET||abuse> arrg,, it just sat there for ages,,
<NET||abuse> done nothing
<NET||abuse> i canceld out of it, now it says it locked
<Peng_> NET||abuse: It wasn't doing nothing. It was waiting for the server to do a bunch of stuff and then start transferring data.
<Peng_> NET||abuse: bzr break-lock $the_url
<Peng_> NET||abuse: IIRC this has been improved, maybe just in lp:bzr.
<NET||abuse> yeh, that worked.
<NET||abuse> ah, no, it was actually just doing nothing before, now the push is working
<NET||abuse> it's actually Inserting.
<NET||abuse> or i hope it is :P
<NET||abuse> need a better connection :P
<NET||abuse> held up again, probably the assets this time.. it is alphabetical isn't it
<NET||abuse> oh shoot,, i have the cakephp docs pdf in there.. what was I doin with that.
<NET||abuse> maybe i should ignore assets
<Peng_> NET||abuse: How do you know it was doing nothing? Like I said, the server was doing stuff, and the client was waiting for it.
<Peng_> That's highly distinct from nothing.
<NET||abuse> the server wasn't likely responding as it shot past the same phase it was in last time.
<NET||abuse> now it's stuck saying       /     81KB   157KB/s | Fetching revisions:Inserting stream
 * Peng_ shrugs.
<NET||abuse> i'm on bzr 2.1.1   is that version ok in terms of weirdness?
<NET||abuse> stupid me, uploading 14MB pdf.
<Peng_> Dunno.
<NET||abuse> server is only on 2.0.3
<Peng_> 2.0.3 is definitely too old.
<NET||abuse> it's also an old ubuntu hardy server
<NET||abuse> there we are, got 2.1.0 from update
<NET||abuse> ahh, actually .2.1.1.1
<NET||abuse> ok, now it's taking ages to get through   "Fetching Revisions:Get Stream Source"   but the remote repo is a bare empty standalone repo
<NET||abuse> on the server i just ran bzr init   on a directory, did nothing else.
<NET||abuse> now just running bzr push bzr+ssh://me@host/path/to/bzrdir
<NET||abuse> nah this is silly, i removed the 14MB file from the assets, and checked in the local bzr repo again.
<NET||abuse> running push and it is just sitting on   " \      2KB     0KB/s | Fetching revisions:Get stream source"   for ever, i went off and changed clothes and came back,
<NET||abuse> ok, blew away the old bzr dir on the remote server, and re-created it, i've in the interim updated the server bzr from 2.0.3 to 2.1.1,, now when i push to the new bzr directory from my laptop's repo, it is sitting on  /     72KB   140KB/s | Fetching revisions:Inserting stream
<NET||abuse> right, i have to go to the shop,,
<NET||abuse> it's almost dinner time.
<NET||abuse> ok, still no change, exact same readout.
<Peng_> I wonder if something is horribly wrong with the server? Like, it starts swapping or something?
<Peng_> Do htop or ~/.bzr.log say anything interesting?
<Peng_> What about pushing over sftp (or nosmart+bzr+ssh)?
<NET||abuse> htop on the remote server?
<NET||abuse> hehe, no htop command on my server
<Peng_> Install it. It rocks. :D
<NET||abuse> Peng_,  ahhhhhhhhhhh it's started doing stuff,,
<NET||abuse> veeeeery slowly.
<NET||abuse> htop says memory is onlyl 430 of 2011MB
<NET||abuse> ok, 17690KB done on the Inserting stream phase,,,,, i'm goin to the shop to get stuff for dinner :)
<NET||abuse> Peng_, cheers for that,, htop rules
<Peng_> :D
<NET||abuse> CPU load is down at 0.7%
<NET||abuse> this server has 23 sites on it though
<NET||abuse> running quiet
<NET||abuse> Swp is 0
<NET||abuse> bzr only using 3.1MB
<NET||abuse> nice,, love being able to scroll through the processes :)
<NET||abuse> and  tree view,, nice
<NET||abuse> ooh, f10 doesn't work to exit as it's a shortcut in gnome
<Peng_> q exits, IIRC
<mtaylor> you guys are generalizing lp-submit from pipelines and putting it in to core, right?
<james_w> mtaylor: it's already in the launchpad plugin in the version I have
<mtaylor> james_w: ooh neat
<mtaylor> james_w: what's the command called now? is it still lp-submit or did it change?
<james_w> that's now an alias, along with lp-propose, for lp-propose-merge
<mtaylor> omg. that's the best thing I've ever heard
 * mtaylor needs to upgrade to new v of bzr
<mtaylor> when is 2.2 coming out?
<mtaylor> :)
<james_w> not sure actually
<mtaylor> heh.
<mtaylor> well, while I'm bugging you (I'm doing a thing in just a bit showing bzr/launchpad integration...)
<mtaylor> is there any way to associate a branch with a blueprint on the cmd line?
<Peng_> "python -c 'import launchpadlib; ...'" ? :D
<james_w> I don't know of one
<mtaylor> hehe
<mtaylor> ok. just checking
<bialix> mtaylor: august
<mtaylor> bialix: sweet. thanks
<thrope> is there a download tarball feature for loggerhead yet?
<beuno> thrope, no, but there's a branch up for review that I need to get to
<thrope> ah ok - it would be really cool!
<beuno> it will  :)
<beuno> probably not enabled on Launchpad
<thrope> has the loggerhead repo moved again? I dont have any updates since nov
<beuno> but for other people...
<beuno> no, lp:loggerhead
<thrope> i am using  http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/
<beuno> that should be it
<beuno> and there should be updates
<thrope> oh wait pull instead of update - too used to using checkouts :|
<kojiro> I kinda fail at using bzr+svn. So to pull new stuff from svn, I have to merge, and then commit?
<thrope> beuno: my branch has diverged - i have a commit i pulled from michael hudson to fix relative links - is that in main now?
<dash> kojiro: if your branch has diverged from the svn branch, yeah
<beuno> thrope, I don't know, to be honest
<dash> kojiro: it's the same as getting changes from a remote bzr branch. either you pull or you merge.
<kojiro> dash: how can I say, "give my working branch the exact same layout as the remote svn repo and nuke all the differences on my side?"
<kojiro> I'm just not used to DVCS semantics yet.
<dash> kojiro: 'bzr pull --overwrite'
<kojiro> aha
<kojiro> thanks :)
<Peng_> thrope: If Bazaar warns you that it diverged, it means you have revisions that aren't in the branch you're trying to pull.
<Peng_> thrope: There's some ancient branch entitled relative-links rotting in the review queue, so I imagine it has not landed.
<thrope> yeah it hasnt
<Peng_> thrope: Um. There are other neat things, though. And you can probably merge the relative-links branch again.
<thrope> its a shame because its quite important
<Peng_> Might be conflicts, but..
<thrope> im trying to run loggerhead behind ssh
<thrope> sorry i mean https
<thrope> without relative links everything breaks
<Peng_> thrope: I wonder if it would be saner if you ran it through FastCGI instead of a proxy.
<Peng_> https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 <-- Oh, look, I reviewed it.
<Peng_> And then it sat and rotted.
<thrope> yeah I am using proxypass in apache
<thrope> it seemed to merge ok into a fresh branch so its working fine for now - thanks
<thrope> ill keep an eye out for the tarball update
<Peng_> thrope: Thanks for the prod. I'm working on relative-links right now. I think it might actually be trivial to fix the review issues, in which case it might actually get merged someday. :D
<beuno> Peng_, you fix it and I'll merge
<thrope> cool thanks
<Peng_> Fixing the review was easy enough; it's the other potential issues I noticed that are the problem. :-\
<Peng_> beuno & thrope: https://code.edge.launchpad.net/~mnordhoff/loggerhead/relative-links/+merge/24767
<beuno> Peng_, looking
<Peng_> thrope: Y'know, even with the relative-links branch, Loggerhead will still generate absolute links for HTTP redirects and some bits of the feed.
<thrope> feed means rss? Im not so worried about that
<thrope> i want to run loggerhead behind https with apache user auth... in one case I want https://bzr.domain.com/ and in another i want https://domain.com/bzr
<thrope> if theres another way to do it relatively easily I would be happy to try
<Peng_> thrope: I wonder if running Loggerhead over FastCGI would behave better.
<beuno> Peng_, looks good, land!
<thrope> i dont think that was available when I set it up but i will check it now
<thrope> going to eat actually but be back in a bit
<Peng_> beuno: Alright.
<Peng_> thrope: Yeah, FastCGI (and SCGI and mod_wsgi and ...) are a recent addition.
<cobalt_mike> is there any document/page besides http://doc.bazaar.canonical.com/bzr.2.1/downloads/pdf-developers/bzr-en-architecture-overview.pdf that describes the bzr architecture?
<Peng_> thrope: Anyway, relative-links has landed in lp:loggerhead, so you don't need to go "bzr merge"ing anymore.
<kkaefer> hi
<kkaefer> is it possible to rename a tag?
<kkaefer> To rename a tag (change the name but keep it on the same revsion), run ``bzr
<kkaefer>   tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``.
<GaryvdM> kkaefer: yes
<kkaefer> ok ;)
<kkaefer> answered my own question
<Peng_> kkaefer: The old tag won't be deleted when you push to other branches, though.
<GaryvdM> kkaefer: :-)
<dutchie> is there a way to make a repo smaller? clean up old unused stuff etc
<dutchie> ah, bzr pack
<Peng_> dutchie: "bzr pack" doesn't "clean up old unused stuff", it just reorganizes (and, in 2a, recompresses) the existing data.
<Peng_> dutchie: In fact, since it makes a backup first, you usually end up with twice as much disk space being used.
<dutchie> oh
<dutchie> how handy
<dutchie> though it seems to have made it about 8MB smaller
<Peng_> Bazaar doesn't have an equivalent of "git gc".
<Peng_> Well, the removing-unused-stuff aspect.
<mtaylor> abentley: any chance bzr sync-pipeline could eventually support pushing all of the pipeline branches to launchpad in one command?
<abentley> mtaylor, how would that be different from what it does now?
<mtaylor> like, bzr sync-pipeline lp:~mordred/drizzle - and it would just push to lp:~mordred/drizzle/${pipe-nick}
<mtaylor> abentley: oh - does that work?
<mtaylor> wow
<mtaylor> the docs didn't make it sound like it would - lemme go try it out :)
<abentley> mtaylor, the one difference is that you specify the push location of your current pipe, and it works out the rest.
<mtaylor> abentley: neat!
<Peng_> "Transferring revisions 0/3029" That can't be good...
<mtaylor> abentley: do I still have to lp-submit them individually?
<abentley> mtaylor, yes.
<abentley> mtaylor, actually lp-submit is now in bzr core, renamed to lp-propose.
<mtaylor> abentley: I've heard about that! but that's not going to be released until august I hear
<mtaylor> so I can't talk about it in the context of core in the current presentation I'm working on
<mtaylor> but I'm quite excited about it
<abentley> Hmm.  I guess this is the downside of calling our monthly releases 'betas'.
<Phoenixz> Problem: Somebody deleted some files that should not have been deleted. He pushed those changes to my repo, now I dont have those files either. I can see the files with bzr ls -r revision-before-deleting, bzr cat even shows content, but how can I recover those files directly withouth having to copy content one by one using bzr cat? svn has a cp that can do this, but bzr doesnt.. anybody?
<Peng_> Phoenixz: "bzr revert"...?
<dash> Phoenixz: you can do 'bzr revert -r good-revision', which will change your working copy to match that revision
<Phoenixz> dash: ah, that sounds like what I need.. thanks!
<lifeless> james_w: AROUND ?
<lifeless> bah
<lifeless> around ?
<jelmer> 'morning lifeless
<james_w> lifeless: YES
<lifeless> :P
<lifeless> how would you feel if I added a dep on testresources to bzr-builddeb?
<james_w> it's packaged?
<lifeless> (rmadison python-testresources for availability info)
<lifeless> build-dep only
<james_w> my fingers are already in the IRC window :-)
<james_w> yep, I'm ok with that
<lifeless> cool, thanks
<jelmer> lifeless: if you have a chance, any review of my updated segment-url patch would be much appreciated :-)
<lifeless> ok
<mwhudson> Peng_: thanks for poking at the relative links thing
<Peng_> :)
 * Peng_ goes AFK again
<thrope> Peng_: thanks... I think maybe it closes this bug https://bugs.launchpad.net/loggerhead/+bug/527330
<ubottu> Launchpad bug 527330 in loggerhead "loggerhead always generates http urls, even if server.webpath is https" [Medium,Confirmed]
<thrope> I'd also be interested if there is any wsgi /fastcgi info
<thrope> or documentation
<thrope> I used mod_wsgi at some point and I think it was quite easy to set up... but I can still run 2 seperate loggerhead instances from the same apache
<Peng_> Oh, has the mod_wsgi stuff landed yet?
<Peng_> Anyway I'm AFK! :P
<Guest53807> Is there anyway I can have the actual folder stored in lets say /misc/bazaar/<projectname> but have the branch look like /<projectname> so that I can do bzr push ssh+bzr://myserver.com/projectname ?
<Peng_> TuxIce: Yes, but I'm not sure how easy it would be.
<TuxIce> Hmm
<Peng_> TuxIce: Umm. One of the scripts in contrib/ should help. I think.
<Peng_> I swear I'm really AFK! :(
<TuxIce> contrib/ in bzr's source?
<Peng_> Yeah
<TuxIce> Launchpad uses /~ubuntu-art-pkg/+branch/<package>/ubuntu does that mean the home directory ubuntu-art-pkg, folder +branch, folder <package>, folder ubuntu, or are they using clever rewriting or something?
<TresEquis> TuxIce: ~ubuntu-art-pkg is the homedir of the team
<TresEquis> +branch is a "view" identifier
<TresEquis> so it is the "branch" view on that homedir
<TuxIce> Yes. But I can't see ~ubuntu-art-pkg/+branch/<package>/... being a file system directory, so I'd assume launchpad somehow rewrites the url?
<TresEquis> with '<package>/ubuntu" as the subpath passed to the view
<TresEquis> its not on the filesystem
<TresEquis> its in an appserver
<Peng_> TuxIce: Launchpad uses a custom SSH server.
<TuxIce> Oh
<Peng_> TuxIce: (Using twisted.conch.)
 * Peng_ really goes AFK!
<TuxIce> Whats an appserver?
<TresEquis> hmm, I thought we were talking about the webserver
<TresEquis> the '+branch' bit is a Zope3-ism
<TuxIce> Whats a Zope3-ism?
<TuxIce> :P
<thumper> you don't need +branch
<thumper> in fact I'm tempted to remove   the redirect that we have in the code
<thumper> it should be issuing permanent redirects
<TuxIce> How about +source?
<TuxIce> Such as https://launchpad.net/ubuntu/lucid/+source/bzr/ ?
<TresEquis> I knew we were talking about a webserver here
<TuxIce> Does the bzr command just make an http request?
<thumper> TuxIce: that url points to the source package, not a branch
<TuxIce> Mmhmm
<TuxIce> So launchpad serves up URL's of their own scheme by using a custom ssh server?
<TresEquis> bzr+ssh:// URLs would use the twisted.conch things
<thumper> TuxIce: yes
<thumper> TuxIce: the layout on disk is completely different
<TuxIce> Of course
<TresEquis> but http:// or https:// are going through an HTTP server, not an SSH server, right?
<TuxIce> Thats what I'm attempting to do.
<thumper> TresEquis: we have a complex rewrite map program
<thumper> TuxIce: jml started to extract the core custom ssh server stuff into a new project
<thumper> TuxIce: but I think it stalled
<TuxIce> So, If I'm correct, you can branch using an http:// or https:// url, which would pull from a webserver?
<TuxIce> I see.
<thumper> I think for bazaar.launchpad.net https issues a redirect to http
<TresEquis> TuxIce: yes, you can serve branches as static pages via apache
<TuxIce> And then to commit+push, you have to communicate with an ssh (sftp to be more correct) server?
<thumper> but yes, served by apache with a rewrite
<thumper> TuxIce: well, we use bzr+ssh
<TuxIce> I see.
<TresEquis> TuxIce: it is possible to push over HTTP, if auth is set up
<TresEquis> I don't think LP does that, though
<thumper> no
<thumper> we don't
<TresEquis> but loggerhead can be configured to allow it
<thumper> configured to allow what?
<TuxIce> ANd bzr+ssh is an alternative to sftp, correct?
<thumper> pushes?
<TresEquis> push over HTTP
<thumper> TuxIce: sftp is a dumb file level transport, whereas bzr is the smart server protocol
 * TuxIce nods
<thumper> TuxIce: bzr can operate directly or over ssh
<TuxIce> What do you mean directly?
<thumper> TuxIce: as in listening on a particular port (not sure which one)
<TresEquis> thumper: bzr:// URLs require running the BZR server process, or putting it in inetd
<thumper> TresEquis: yes
#bzr 2010-05-06
<TuxIce> So operating directly allows you to use bzr:// instead of bzr+ssh:// ?
<TuxIce> Correct?
<thumper> TuxIce: yes, but the process runs as a specified user on the server
<TuxIce> I see.
<thumper> TuxIce: whereas with ssh it can run as the requester
<TuxIce> Now, launchpad users obviously don't all have they're own physical account on the server, and by physical account I mean an /etc/passwd entry; How do you get around that?
<TuxIce> Operating your ftp daemon to pull from a database?
<dash> TuxIce: sftp server written in python. :)
<TuxIce> I see.
<TresEquis> SSH keys are stored in a single account, w/ info about the "apparent" account passed to the bzr command
<TuxIce> Oh man, so confusing.
<TuxIce> I see.
<TresEquis> or at least that is how I would set it up, having done that for CVS and SVN
<NET||abuse> awww heck,, what'd i do wrong here?   This transport does not update the working tree of: bzr+ssh://me@hostname/path/to/push/repo
<thumper> TresEquis: ssh keys stored in the database connected to the users
<TresEquis> sure
<thumper> NET||abuse: push doesn't update the remote working tree
<thumper> NET||abuse: there is a plugin to do that somewhere
<TuxIce> So really, every time you add a key in launchpad, its being added to one account on the lp server. When you branch/push, your essentially "proxying" (for lack of a better term, through this one account?
<NET||abuse> thumper, oh, ok, maybe i'm using the wrong repo type ont eh remote side then
<TuxIce> And this one account allows sftp access, but not physical /bin/bash ssh access, correct?
<thumper> TuxIce: yes
<TresEquis> TuxIce: that's probably a reasonable metaphor
<NET||abuse> thumper, i was on remote, i did mkdir bzrrepo; cd bzrrepo; bzr init;      then on my local i just pushed to that location.. it uploaded the first time.. will it not upload anymore?
<TuxIce> I see
<TresEquis> TuxIce: sort of like this: http://www.snailbook.com/faq/restricted-scp.auto.html
<NET||abuse> or do i have to create a different type of repo on the remote server? and pull from that server?
<thumper> NET||abuse: I'm surprised that it did it the first time
<NET||abuse> thumper, well it did ;P
<thumper> NET||abuse: you can either pull from the server
<AdamDV-iPod> I see
<thumper> NET||abuse: or add a plugin on the server
<NET||abuse> pull from server? but i want to push up to the server.
 * thumper tries to remember the name
<AdamDV-iPod> And then, when you connect to the lp servers using sftp, your ssh server essentially "rewrites" the URL
<thumper> NET||abuse: http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<NET||abuse> i'd be happy to recreate a new repo, push the current server branch to there, then continue updateing from m ylocal copy to the new server repo, then wipe out the current server repo and branch at the same location as the just deleted old repo from the new server repo
<thumper> AdamDV-iPod: yes
<AdamDV-iPod> Makes sense now. So, would it be possible to get the code that does all this?
<NET||abuse> thumper, i did this before twice, and i didn't require any plugin, where i had a location i pushed to, that location was also active as a working tree, i would pull updates from the bzr pushes to that working tree on the server and those would be the live site files for my websites.
<thumper> NET||abuse: pull updates the working tree, push doesn't
<AdamDV-iPod> I'm assuming the user ssh key proxying is one piece of code, the rewriing and ssh server another?
<thumper> yep
<NET||abuse> thumper, yeh i know, but the same location on the server, seemed to be both  .. em .. would you call it a stub repository ? and the working tree, i would push from my laptop to the stub, in the same directory as the stub(.bzr directory) i would also update, this would populate the /path/to/dir/ with any pushed updates
<AdamDV-iPod> I see. And this code is unattainable because non of the lp debs have seperated it into it's own project?
<AdamDV-iPod> Err, debs
<thumper> AdamDV-iPod: no, all this code is in the launchpad tree
<thumper> lp:launchpad
<AdamDV-iPod> It is?
<thumper> yep
<NET||abuse> so on the server i had   /path/to/repo/.bzr    from the laptop, i would push to me@host/path/to/repo/      then on the server, i would cd /path/to/repo/   bzr branch;   bzr update; bzr update;
<AdamDV-iPod> Including the ssh server?
<thumper> AdamDV-iPod: yep, all there
<AdamDV-iPod> Hmmm, thAt's good then
<NET||abuse> thumper, that said, i dont' care if i have to create a  new bzr repo taht is only for use as a repository, and not as a workign tree, and i bind the working tree that's now on the server to that location on the same host, and push to that location from my local laptop too.
<AdamDV-iPod> Now, time to try and see if I can get a working copy of launchpad setup.
<NET||abuse> thumper, how do i set that up/
<NET||abuse> ?
<AdamDV-iPod> Thank you very much thumper :)
<thumper> AdamDV-iPod: lib/lp/codehosting
<AdamDV-iPod> That's the directory in the src where the code I'm referencing is? Or ..?
<thumper> AdamDV-iPod: yep
<AdamDV-iPod> and that's in the launchpad source that was open sourced a few years ago?
<thumper> uh ha
<AdamDV-iPod> Thanks :D
<AdamDV-iPod> thumper: Launchpad builds on lucid, right?
<thumper> AdamDV-iPod: it does, and we talk in #launchpad-dev
<lifeless> james_w: still around? you register your commands in builddeb a bit strangely - bzr can't tell they are in a plugin as a result.
<lifeless> james_w: scratch that, grep broke me
<lifeless> hi davidstrauss
<davidstrauss> lifeless: hi
<davidstrauss> lifeless: what's up?
<lifeless> nothing particularly ;) just saying hai
<davidstrauss> :-)
<lifeless> sorry about the lag a couple of days back too
<davidstrauss> lifeless: it seems to be fixed now
<lifeless> yeah
<lifeless> should be
<davidstrauss> lifeless: you guys should look into the UEC for processing those heavy loads ;-)
<lifeless> hah
<lifeless> AIUI its database contention concerns that have us serialise everything
<davidstrauss> lifeless: I'd love to help you scale there.
<davidstrauss> lifeless: I do tons of work in the NoSQL space
<lifeless> davidstrauss: cool
<lifeless> davidstrauss: thumper: ^ is the team lead for launchpad-code. We've been having some conversations around e.g. cassandra internally
<davidstrauss> lifeless: launchpad should be easy to for things like branches
<lifeless> Right now we're not very good at doing controlled experiments though, so there is significant mgmt and technical concern that when we start doing nosql we choose The Right Tool
<davidstrauss> easy to shard, i meant
<lifeless> fairly, I'd say
<AdamDV2> So, to setup a bzr branch for checking out by fellow developers on my server, I would navigate to a directory do bzr init, add * and then commit, correct?
<lifeless> AdamDV2: just 'bzr init; bzr add; bzr commit -m "import"'
<lifeless> AdamDV2: you don't need to give paths to most bzr commands
<AdamDV2> I see, thanks
<lifeless> like 'ls', bzr knows that 'cwd is what you want'
<AdamDV2> Can bzr handle ftp:// ?
<lifeless> yes
<AdamDV2> Thanks
<lifeless> if you have a better protocol you should use it
<AdamDV2> I know, such as sftp or bzr or bzr+ssh
<lifeless> ftp servers are very limited and thus slow for hosting bzr branches on
<AdamDV2> How does the bzr:// protocol work?
<AdamDV2> Does it just work out of the box?
<lifeless> if you want to upload a website which you manage in bzr, ftp is fine - but use 'bzr upload' in the bzr-upload plugin instead.
<AdamDV2> I'm only using ftp to test.
<AdamDV2> I'm planning on using bzr://
<lifeless> AdamDV2: bzr+ssh just works out of the box - install bzr on your server and you're good to go if you can ssh in.
<AdamDV2> HOw about just bzr:// ?
<lifeless> bzr:// is only really suitable for read-only access
<AdamDV2> I see.
<lifeless> it has no authentication or acl support
<lifeless> bzr+ssh or bzr+http can do authentication
<AdamDV2> Is there a plugin which handles bzr+mysql?
<lifeless> I'm not sure what that would do; I'm not aware of anything glueing the two together. mtaylor: may know.
<AdamDV2> Use mysql for user authentication?
<AdamDV2> mtaylor: Awake?
<lifeless> libpam-mysql might do what you want
<AdamDV2> Hmm
<AdamDV2> I'll have to fiddle with that
<lifeless> or any of the apache auth stuff for mysql
 * AdamDV2 will look into
<AdamDV2> Gah.
<AdamDV2> I created a branch server side.
<AdamDV2> On my client I checked it out over sftp, changed it a bit, ran add, diff, then commit.
<AdamDV2> Then ran ls on the server, no difference. Whats wrong?
<dash> AdamDV2: does 'bzr log -l1' show your new revision?
<AdamDV2> On the server?
<AdamDV2> Yes, it does
<AdamDV2> dash: Any idea why the files aren't showing up?
<AdamDV2> Oh man, bzr is awesome
<parthm> lifeless: good point on https://code.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 thanks for the review
<parthm> lifeless: i am planning to fix the repo checkout message. will file a bug for the heuristics and branch part.
<lifeless> parthm: cool
<parthm> lifeless: whats a good way to check if we are in a repository?
<lifeless> parthm: the underlying code does it
<lifeless> parthm: checking at the outer layer would be a mistake
<parthm> lifeless: i am looking at bzrlib.branch.create_checkout and wondering where to put the test. 'if lightweight' is already present there.
<parthm> is there something like is_repository or something?
<lifeless> parthm: deeper still
<parthm> lifeless: ok. thanks .. will look.
<lifeless> parthm: create_branch_convenience will know; but pull is the one doing the fetching
<lifeless> parthm: [and this is perhaps why doing it as a heuristic in fetch is actually fundamentally easier]
 * parthm is reading create_branch_convenience
<lifeless> AdamDV2: glad you're liking it
<parthm> lifeless: this is what i have in mind http://pastebin.com/MB6F5UU0 . The change in inside bzrdir.determine_repository_policy. basic testing with branch and checkout (inside/outside repo) shows it works.
<parthm> lifeless: does that look like a good approach.
<parthm> lifeless: nevermind. this shows the message for init also. need to look into it some more. thanks for the pointers.
<lifeless> no probs
<lifeless> -> city, finishing day on the train ;)
<bialix> hi
<bialix> anybody knows how to merge patches to lp:bzr/2.1?
<bialix> GaryvdM was unable to merge there
<bialix> vila: ?
<twb> Peculiar thing when going through polipo: Got a 200 response when asking for multiple ranges, does your server at 127.0.0.1:8080 support range requests?
<vila> twb: A range request should return only part of a file, if your server doesn't support it, performance will suffer,
<vila> twb: if bzr needs, say a few kbytes in a multi MB file, your server is returning the whole file anyway
<twb> Well, it's a proxy, and it definitely supports range requests
<twb> The server on the far side of the proxy is lp:dosage
<vila> twb: try using -Dhttp and look at .bzr.log you'll see what bzr is aksing and *receiving*
<twb> OK.
<twb> Of course, it would help if the problem was reliably reproducible :-/
<twb> I can't reproduce it a second time, so I'll wander off until I can
<twb> Update: I couldn't reproduce the problem again with bzr, but a simple curl -r0-0,-1 shows that polipo doesn't handle *multiple* range requests.
<twb> (i.e. it groks Range: 0-0, but not Range: 0-0,-1.)
<vila> twb: bzr does a lot of multiple requests but... you can't read that unless you stay connected a bit longer...
<spm> vila: :-)
<vila> spm: yeah :) But a bit frustrating nevertheless :)
<spm> oh yes
<vila> my my my, babune is telling me a strange story, a doctest is failing in branchbuilder for hardy/jaunty/karmic but not for freebsd/gentoo,
<vila> digging a bit it seems it's not run on gentoo/freebsd and not on pqm either which is more of a concern
<vila> hmm, lifeless is gone ?
<parthm> vila: hi
<vila> parthm: hey !
<parthm> vila: i was just going through the report. the changeset is https://code.launchpad.net/~parthm/bzr/549310-mandatory-whoami/+merge/24244
<vila> yeah, so I guess the test pass if some env var is set, but which one ?
<parthm> vila: i think the change that might have caused this is that setting whoami is now mandatory. but tests don't do this. so tests use 'EMAIL': 'jrandom@example.com' in tests.__init__.py
<vila> parthm: shouldn't we use EMAIL if it's set ?
<parthm> vila: is possible to reproduce this on lucid?
<parthm> vila: yes. EMAIL is being used. and hence the tests are passing. i am surprised that something failed. let me try this tests specifically.
<vila> parthm: the test pass on the lucid slave, weird, it's supposed to use the same setup as hardy/jaunty/karmic at least as far as env vars are concerned...
<parthm> vila: is this doctests something outside of selftest?
<vila> parthm: no, you can run it with 'bzr selftest -s bzrlib.branchbuilder'
<vila> !paste
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> parthm: failure on hardy: http://paste.ubuntu.com/428801/
<parthm> vila: interestingly the test is passing on my system.
<vila> parthm: I'm sure it is :)
<vila> parthm: that's why I mentioned a possible test isolation problem, if the env is correct (outside of bzr control) the test pass, if it's not, it fails
 * parthm launches synaptic looking for python 2.5
<parthm> upgraded to lucid recently. "Package python2.5 has no available version, but exists in the database." :(
<parthm> vila: could it be the python version? but it passed on pqm so i suppose 2.4 and 2.6 are ok.
<vila> parthm: gentto uses 2.6, I don't think python version is relevant here
<vila> well, my gentto slave use 2.6 (dunno what is available nor used generally on gentoo)
<vila> ha, looks like I have yet another source of typos there, hey, fingers, it's gentoo k?
<vila> parthm: what env vars are not used anymore with your patch ?
<vila> parthm: looks like config.username() docstring is not accurate anymore, it says: "If none is found, a reasonable default is (hopefully)  created." but it seems it now raises NoWhoami instead
<parthm> vila: the only change is setting EMAIL in tests/__init__.py .. _auto_user_id() is gone and replaced by errors.NoWhoami
<vila> parthm: oh, and I suspect the doctests ignores the EMAIL set by bzrlib.tests.__init__.py
<GaryvdM>  Hi vila.
<vila> parthm: haaaa, setting EMAIL bingo :)
<vila> GaryvdM: Hi !
<vila> GaryvdM, parthm: thanks so much for your work yesterday, the review queue looks so much cleaner !
<GaryvdM> vila: re: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/24669
 * parthm fixes config.username() docstring
<vila> GaryvdM: yes, bialix ping me earlier but quicly went after that, probably some auth setting missing on pqm, I'll submit that
<GaryvdM> vila: I don't have permision to push to bzr/2.1. Please could you submit
<GaryvdM> Thanks vila.
<parthm> vila: for a moment there i though i had EMAIL set in my shell. but even without it the tests pass. hmm.
<parthm> vila: any idea why the error is not reproducible?
<vila> GaryvdM: submitted
<vila> parthm: not yet, that's why I wanted to talk with you :D
<vila> parthm: so, on my karmic slave: ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder fails,
<vila> but EMAIL=joe@example.com ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder succeeds
<parthm> vila: weird :)
<parthm> vila: a simple fix could be just setting the EMAIL in the doctest but that still doesn't explain why its not reproducible
<vila> parthm: yup
<vila> parthm: a workaround one would be to set EMAIL in my slaves
<vila> parthm: but I don't see *where* EMAIL is taken into account
<vila> blah, stoopid under your nose: config.username()
<parthm> vila: yes
<parthm> should http://dpaste.com/191445/ be saying "running 0 tests..." at the top?
<vila> ensure_username docstring is wrong too (even if NoWhoami inherits from BzrCommandError, it's worth being more precise)
<vila> parthm: hehe, no patches welcome :)
<vila> parthm: kidding, don't spend too much time no this one
<parthm> vila: not a problem. but this is very weird.
<vila> parthm: or file a bug with a 'papercut' tag
<parthm> vila: i will attach the tag to the bug you filed along with the error log you put up. i will push the updated docstrings anyway. better to keep docs precise if possible
<vila> parthm: in retrospect, setting EMAIL *by default* is a bit weird
<vila> parthm: no, I meant the '0 tests' one
<parthm> vila: ah :)
<vila> the doctest one is a real problem
<vila> ha, not real, both are reals, I meant more serious
<vila> we don't want reports that the test suite is now failing all over random places for no good reasons
<parthm> vila: "setting EMAIL by default"?
<parthm> vila: agreed.
<vila> parthm: in TestCase._cleanEnvironment()
<vila> except for doctests I'm pretty sure all our tests relies on this
<parthm> vila: yes. i couldn't think of a better way. apart from each test doing a whoami or using a config file. any ideas?
<vila> parthm: that's why most of the vars are set to None
<parthm> vila: i was reluctant to do that but wasn't sure there were other options.
<vila> parthm: let's try to barcktrack a bit, the goal here is to avoid people committing without a wrong whoami so they don't come back asking to fix old commits,
<vila> so your fix is fine
<vila> and since you added tests to check the behavior when the variable is explicitly unset, I think the tests are fine too
<vila> parthm: do you have EMAIL set ?
<parthm> vila: i did have EMAIL in my zshrc but even after unsetting it tests pass.
<vila> parthm: meh
<parthm> vila: does the test work for you locally?
<vila> parthm: hehe, what do you call 'locally' ? I have ~10 different configs to tests under :-)
<vila> (more problably 15, but I don't want to brag :)
<parthm> vila: :D ... i just mean whatever system you are using currently.
 * vila trying on karmic
<parthm> vila: https://bugs.launchpad.net/bzr/+bug/576269 ... file it as tech-debt as there was no papercut tag.
<ubottu> Launchpad bug 576269 in bzr "verbose mode in selftest show "running 0 tests"" [Undecided,New]
<parthm> vila: i am on lucid
<a212901390231901> vila, your windows bot seems to have been getting stuck before even getting as far as the first test of late
<vila> a212901390231901: shudder, yes, some weird setup bug, some network share not showing up when it should :-/
<vila> a212901390231901: thanks for noticing !
<vila> parthm: passing locally....
 * parthm wonders how to reproduce the error
<parthm> vila: whats different about the env where the test is failing?
<vila> parthm: searching
<a212901390231901> heh, well done for filing that bug parth, I've been ignoring it for ages
<parthm> a212901390231901: :)
<a212901390231901> what's the fallout from the nodefault whoami? I meant to review the change but didn't find the time.
 * parthm starts reading bug #321320
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
<a212901390231901> ah, got the the pastebin link in the log
<a212901390231901> I'll see if I get it here
<vila> parthm: found it, I'm sure you will appreciate the irony there: comment out your 'email' entry in .bazaar.conf
<parthm> vila: hmm. weird http://dpaste.com/191454/
 * parthm checks if he has some other email set.
<parthm> vila: yup.
<a212901390231901> passes here too.
<a212901390231901> pretty sure I don't have any email or config stuff in the test account
<parthm> vila: reproduced it with EMAIL=<blank> and commented out email in bazaar.conf. phew! :)
<vila> a212901390231901: what does 'bzr whoami' says ?
<vila> say even
<parthm> vila: thanks for finding this.
<vila> parthm: so, summary: people without whoami set will see a failure
<vila> I think it's a good thing in fact :)
<parthm> vila: yes. :)
<vila> after all, your fix is about helping people falling into this trap, so...
<parthm> vila: heh :)
<vila> parthm: thank you for helping me finding out a hole in my slave setups :-D
<a212901390231901> okay, nope, does fail indeed
<parthm> vila: ooh :) ... yes. thats what this shows :)
<parthm> vila: so the interesting question is what do we do about this. we could setup EMAIL for the doctest. or we could let this be as a failsafe.
<parthm> vila: ideally doctests should use the same env as other tests as mentioned in bug #321320 that you linked to this report.
<ubottu> Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
<vila> failsafe sounds ok, I still have to understand while the tests *succeeded* in some slaves
<vila> parthm: that sounds right (even if it will *remove* the failsafe here)
<parthm> vila: if we keep these two setups separate eventually something else will be different and tests will behave weird.
<parthm> vila: we can keep this as a tech-debt ticket. would you like to put a comment in or should i?
<vila> parthm: go ahead
<vila> parthm: you can also look at creating the papercut tag, I'm surprised you can't use it
<parthm> vila: put papercut tag on the "running 0" bug
<vila> parthm: thanks
<parthm> vila: thanks for your help with understanding the doctest issue. i have updated the bug with a comment.
<parthm> vila: how much time should to take for a patch to pass tests on queue to status on lp changing to merged?
<parthm> vila: https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414 passed tests quite some time back but hasn't shown up on trunk.
<vila> parthm: haha, a well known French humorist would tell you: precisely ? A certain amount of time
<parthm> vila: :) ... would 'bzr pull' be more or less immediate?
<parthm> immediate as in a few mintutes
<vila> oh,wait a minute, pqm sent a 'sucess' mail ?
<parthm> vila: no mail yet. just that the tests passed quite some time back on pqm. the queue is empty now.
<vila> parthm: hmm
<vila> parthm: sounds like a failure somewhere to me
<parthm> vila: yup. the success mails came out faster yesterday. maybe we are making pqm work too hard :)
<parthm> vila: last commit on trunk is 14 hrs ago.
<vila> parthm: re-submit or run 'make check' locally (that's what pqm does IIRC)
<parthm> vila: what does 'make check' do?
<vila> parthm: use the source Luke ! :-) It generate docs and run the full test suite with: $(PYTHON) -Werror -O ./bzr selftest --subunit $(tests) | tee selftest.log
<parthm> vila: ah. i though it was something non-standard pertaining to pqm :)
<parthm> vila: i will try to resubmit.
<parthm> vila: i did a resubmit. http://pqm.bazaar-vcs.org/ ... lets see how that goes. thanks.
<vila> parthm: try to put (parthm) at the front for the next submissions, may people rely on that when scanning the commit messages :)
<a212901390231901> I want to file a bug about bzrlib.lsprof being weird code, but I might save it till next week when I can ask why it's like that.
<parthm> vila: will do. i was wondering what the recommended practice was :)
<vila> parthm: putting (something) in front :) lifeless does it automatically in his hydrazine branch, but that's on hold currently
<vila> a212901390231901: jam is likely the best to answer that
<vila> a212901390231901: there are historical reasons which may need to be revisited
<bialix> heya
<vila> parthm: oooh, he's gone :-/
<a212901390231901> hey Alexander.
<bialix> hey mister-with-very-long-nick!
<bialix> :-)
<a212901390231901> :)
<a212901390231901> you don't have time today to do a test build the windows installer for me, do you?
<bialix> a212901390231901: sorry,
<bialix> have to finish urgent job and pack my bag
<a212901390231901> s'cool, can wait for next week.
<bialix> but I will be ready to commit this next week
<parthm> is there something happening on pqm ... i got a weird set of errors for https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414
<parthm> http://dpaste.com/191515/ the tests pass locally
<a212901390231901> meh, testtools tracebacks are so useless
<a212901390231901> I'll pull and try it here
<a212901390231901> hm, known failures under windows as they're old tests with bad locking
<a212901390231901> same basic result.
<parthm> a212901390231901: thanks. i am running my tests again. this mp was submitted earlier this morning but pqm was silent. this was the second submit.
<a212901390231901> is -Werror catching you out?
<a212901390231901> not sure if any of the locking stuff will start pushing warnings, hard to see how the branch in question has made any change to that though
<vila> parthm: makes no sense to me either
<parthm> a212901390231901: will try. i typically run only blackbox locally with selected tests from bt to avoid "new thread" errors.
 * parthm needs more ram than 1GB
<a212901390231901> or -s bb.test_info -s bb.test_revert
<parthm> a212901390231901, vila: no errors with -Werror for bb.test_[info|revert]
<parthm> the patch is actually trivial ... short options. it should really be causing problems.
<a212901390231901> yeah, seems more likely to be something external
<parthm> i will do a resubmit ... the 3rd :P
<parthm> a212901390231901, vila: its in queue now. thanks for trying out the test guys.
<a212901390231901> heh, roundup is funny, "A problem was encountered processing your request. The tracker maintainers have been notified of the problem." = success, comment posted
<a212901390231901> hm, I think I'll give up on thinking of a smarter way to do this and just post the branch for review
<sangi> while trying to install loggerhead ./serve-branches is throwing an error like this: import bzrlib.foreign ImportError: No module named foreign
<jelmer> sangi: the version of bzr you're using is too old
<maxb> Is there actually any point whatsoever to doing incremental packs *during* a 'bzr upgrade' ?
<sangi> installing loggerhead throws an error like this : http://pastebin.com/ZDQp2Kea
<sangi> bzr version is 2.0.3
<lifeless> looks ok
<Peng_> sangi: That's fine.
<Peng_> The bzr logging bit is a bug, but it's not a big deal...
 * luks hopes he won't get into trouble because of pushing to qbzr trunk after a long time of inactivity :)
<luks> hm, and loggerhead doesn't handle long lines in commit messages well
<GaryvdM> Hi luks
<GaryvdM> Luks: Np pushing to trunk..
<luks> hey
<GaryvdM> luks: Are you still coming to UDS?
<luks> GaryvdM: no, I had to cancel :(
<GaryvdM> luks: :-( - I was looking foward to meeting you
<luks> me too...
<luks> I really wanted to go, but couldn't find anybody to take care of some things instead of me during that time
<GaryvdM> I see
<cbz> Why does tortoise-bzr keep throwing lock errors (seemingly for no reason) on using the pull command?
<cbz> The identical command used at the cli then works
<a212901390231901> bad interaction with another shell extension
<a212901390231901> ?
<GaryvdM> cbz: what happens if you run bzr qpull?
<cbz> That is what is having problems effectively.
<cbz> Tortoise-bzr runs bzr qpull
<cbz> Which occasionally complains about being unable to lock a file inside the .bzr directory
<hazmat> any reason why bzr-svn has to refetch all revprops on update... using bzr-svn against apache repo (shared project), means every update has to check/fetch against 1m total repo revs
<hazmat> i would have thought it could just iterate from where it last left off
<hazmat> its got a 3g cache file as well, so even after it fetches remote revsprops on every remote op (update, missing, merge) it still has to churn through its cache file for a few minutes
<jelmer____> hazmat, it doesn't refetch all revprops as far as I know
<jelmer____> hazmat, what version are you using?
<hazmat> jelmer_, bzr-svn 1.0  revno 3275 with bzr 2.0.2
<hazmat> jelmer_, is it possible its just processing all the ones in cache, when it says its pull phase:discovering revprop revisions x/y ?
<jelmer____> hazmat, What version of svn ?
<hazmat> 1.6.9
<hazmat> jelmer_, i'm trying to use it against an apache repo http://svn.apache.org/repos/asf/hadoop/zookeeper/trunk    the project only has 630 revs, but the repo has about 1m revs.
<jelmer____> hazmat, it should only do that once and then just cache the results
<hazmat> jelmer_, does it display the discovering revpop revisions when it processing from cache?
 * hazmat tries updating against bzr-svn 1.0 branch
<jelmer____> hazmat: only for new revisions in the repo
<hazmat> hmm.. well its definitely processing from scratch on every remote cmd.. i'm gonna try updating to bzr-svn 1.0 latest on branch, and bzr 2.1, and see if it continues.
<hazmat> or at least processing every rev somehow.. its got a 2.7gb repo cache in ~/.bazaar/svn-cache
<jelmer____> hazmat, I can't reproduce that with a current version of bzr-svn
<jelmer____> hazmat, and launchpad doesn't appear to suffer from it either
<awilkins> hazmat, I think I have a copy of that repo also
<hazmat> awilkins, if you do an bzr pull on it, does process every repo rev?
<awilkins> Ack, I don't have the revision info cache on this machine
<awilkins> I do recall it doing quite a lot of looking through revision properties for certain operations but I've not really made any detailed study of it
<awilkins> It does have 941,754 revisions which is quite something
<awilkins> And I pulled my copy of it some time ago
<hazmat> so i made a new pristine bzr branch against the repo (existing rev cache), and updated and it works fine with (bzr 2.1, bzr-svn 1.0 (latest))  BUT only as long as the local branch doesn't have any commits, if it does then it tries to process every rev
<hazmat> jelmer_, ^
<funkyweasel> Good afternoon chaps.
<funkyweasel> I'm back with bzr performance issues agin.
<funkyweasel> s/agin/again
<funkyweasel> Ever since I upgraded from ubuntu hardy/bzr 1.3.1 to ubuntu karmic and bzr 2.0.4 I've found bzr to be *really* slow when performing certain operations - status, diff, commiting.  Branching and upgrading take an unthinkable amount of time (several hours, upgrades hang).
<awilkins> funkyweasel, across 1.3 and 2.0.4 Bazaar has moved to a new repository and branch  format ; it sounds like your issues are mostly due to runtime on-the-fly conversions of the data. Not so sure about the upgrades (which should fix the problem).
<funkyweasel> The repo server is still on bzr 1.3.1, so I've tried upgrading local branches to pack-0.92.  This gave a brief speed up back to old levels of performance, but has dropped back to dog-awful performance since.
<funkyweasel> awilkins: No conversion should be happening if I am using branches generated by 1.3.1 in 2.0.4 unless the newer version is sub-optimal for use with the older repo/branch format.
<awilkins> funkyweasel, True
<awilkins> funkyweasel, I don't see why  2.0.4 would be slower for the old formats because it's still the same code AFAIk
<funkyweasel> awilkins: Me neither.  but it's the only explanation I can think of.
<funkyweasel> awilkins: It seems like 2.0.4 is *much* less efficient.
<awilkins> 2.x with native formats is pretty fast - the only thing I have to complain about is the packing speed of format 2a
<funkyweasel> Could it be that 2.0.4 is converting old repo/branch format into the newer format internally, performing diff calculations, then converting back to old output for format?
<awilkins> It takes a lot longer to do a pack on 2a than it does on lower formats, and I'm only losing about 10% repo space on the trees where the time is long enough to be annoying
<jelmer____> hazmat, that's while pushing right?
<funkyweasel> I'm certain that 2.x is the nuts with 2.x repos.  But that's not always handy if you have limited or no access to the repo server on an older version.
<awilkins> funkyweasel, TBH, I use 2.x with 1.14-rich-root branches all the time but don't notice this ; maybe it's something to do with the even-older formats you're using
<funkyweasel> Is it hugely unusual to have a point version difference between local/client and repo server?
<funkyweasel> awilkins: Yep - I am pre-Rich-roots. :/
<awilkins> funkyweasel, I always had to cope with Subversion so I just used rich-root branches by reflex whenever possible
<awilkins> funkyweasel, I have noticed that non-rich-root to rich-root incurs the biggest conversion overhead
<funkyweasel> awilkins: Right, yes.  But I can't do that on the repo server due to the old version of bzr, as I understand it.
<funkyweasel> I am *not* using rich roots as far I am aware.
<awilkins> funkyweasel, Also true .....
<funkyweasel> I just don't understand how *without upgrading branches* the newer version is much slower.  That just doesn't make sense.
<funkyweasel> I've got bzr status taking minutes as opposed to seconds.
<awilkins> funkyweasel, Are you using lightweight checkouts or heavyweight checkouts from the sevrer or are they just branches?
<funkyweasel> Checkouts from repo server.  I tried experimenting with branching from a local checkout of thetrunk, upgrading this new local branch to pack0.92, pushing to repo server and binding to repo server.  But it's still the same shocking performance drop compared to 1.3.1.
<awilkins> funkyweasel, Just a thought, have you tried operations on branches that are not bound to the server?
<funkyweasel> awilkins: Yup.  Same issue.
<hazmat> jelmer_, that's while pulling
<hazmat> jelmer_, i branch, do a local commit, and try pulling, and it has to reprocess every rev, if i don't do the local commit, and just pull, it seems to be fast, although i'm curious if thats also the case when there's new remote revs.
<funkyweasel> I mean, if it's just a case of 2.0.2 being poor at old repo/branch versions then fair enough.  It's annoying but I just don't have time to switch to another solution.  Hopefully the repo server will get upgraded at some point, and for now I can bite down on operations taking long and leave it be.
<jml> TuxIce, thumper: the best place to look for my ssh server work is lp.services.sshserver
<cobalt_mike> bzrlib question: should I expect any problems if I provide my own custom / subclasses _ChangeReporter for e.g. delta.report_changes?
<cobalt_mike> ^subclasseD
<Pilky> is there a way with mv --auto to tell it not to mark certain files as moved, or to undo that for certain files after the fact?
<Pilky> I've got about 10 moved files and 8 are correct but it is picking up 2 deleted files and matching them to 2 new files
<strk> I'm using an unbound branch and now dunno if it diverged or not
<dash> strk: 'bzr missing' can tell you
<strk> when I push, bzr complains 'ERROR: Operation denied because it would change the main history.'
<strk> ah, nice
<strk> ok, 'missing' says there are 3 extra revisions
<strk> only one is really mine, the other 2 are merges from trunk
<strk> now, how do I push mine and leave the merges alone?
<maxb> Are the merges before or after yours?
<maxb> In fact, maybe just pastebin the output of bzr missing
<strk> http://codepad.org/ole3ycZ7 <--- 'missing' output
<maxb> strk: And do you now want to push "Handle the case of failed glue initialization" back to trunk?
<maxb> In which case, you'll need to merge, since the branches have obviously diverged
<maxb> Given that there was something to merge
<maxb> The 'ERROR: Operation denied because it would change the main history.' is indicating that you are disallowed from pushing a merge of *trunk into your branch* (because this would change the assignment of revnos to revisions already in trunk)
<maxb> Instead you must merge *your branch into trunk*
<a212901390231901> ha, wonder if bug 576533 will break the IRC bot
<ubottu> Launchpad bug 576533 in bzr "ProblemType: Crash BzrDebugFlags: set() BzrPlugins: bzrtools /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzrtools [2.1.0] launchpad /usr/lib/python2.6/dist-packages..." [Undecided,New] https://launchpad.net/bugs/576533
<strk> maxb: so, how do I merge my branch into trunk ?
<maxb> have a branch/checkout of trunk; bzr merge ../mybranch
#bzr 2010-05-07
<lifeless> hmm, 25 failures to go
<Peng_> 56/
<Peng_> Um. :D Oops. irssi fail.
<lifeless> Peng_: and here I thought you were prognosticating
<Peng_> No, I just forgot that you put the / before the command.
<mkanat> mwhudson: So, are you going to merge my fix, or are you waiting on additional reviews?
<mkanat> Oh, wait, I mean Peng.
<Peng_> I'm off-duty.
<Peng_> Wait...why am I at the computer at all? I forgot.
<mkanat> Peng: Haha, okay. :-)
<Peng_> mkanat: Regarding your email, the current state of the history-db stuff is that it would not be optional.
<mwhudson> mkanat: want to set a commit message on that merge proposal?
<Peng_> (Still off-duty! I just check my email too much...)
<mwhudson> mkanat: nm, merging anyway
<mwhudson> done
<Peng_> mwhudson: Ping?
<lifeless> hmm, I needs review :P
<mkanat> Peng_: Oh, okay.
<rm200910> Hi . I cannot do a launchpad checkout. "bzr checkout lp:epics-base/3-14 base1" throws out these exceptions: http://pastebin.com/R96AFfJc Any suggestions?
 * rm200910 uses Bazaar (bzr) 2.1.1
<lifeless> wow thats fun
<lifeless> mwhudson: can you have a peek at that ?
<mwhudson> Peng_: hi?
<mwhudson> lifeless: looking
<lifeless> mwhudson: looks like we're not getting a header we need or something
<lifeless> mwhudson: btu I can't see why that would be the case
<mwhudson> lifeless: i think it's a ****ed proxy
<rm200910> i'm using an http_proxy
<rm200910> I must add
<lifeless> rm200910: is it anonymising or something ?
<TresEquis> hmm, I was just able to get it via 'bzr branch' on my machine using bzr 2.1.1
<mwhudson> i don't understand the details though
<lifeless> rm200910: try 3.14 rather than 3-14 ?
<rm200910> lifeless: I don't know if it's anonymizing
<lifeless> rm200910: try this command: bzr checkout lp:epics-base/3.14 base2
<lifeless> TresEquis: using the exact command line, or did your subconscious fix the typo ?
<rm200910> lifeless: bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 111] Connection refused
<Peng_> mwhudson: Eek. Too late. I was just going AFK again.
<Peng_> Um.
<lifeless> rm200910: figuring out what an lp: url refers to requires direct access to ssl at the moment
<lifeless> rm200910: I think that that might be fixed in 2.2 (but I'm not sure)
<Peng_> mwhudson: Are there any plans for when Loggerhead's next release will be?
<lifeless> rm200910: you can use http://bazaar.launchpad.net/~epics-core/epics-base/3.14 as a workaround (or bzr+ssh instead of http if you have write access)
<mwhudson> Peng_: not from my end, i guess "soon" would be nice
<lifeless> actually, I mean
<TresEquis> lifeless: yup, my fingers fixed it
<lifeless> 'bzr+ssh instead of http if you have done bzr lp-login'
<TresEquis> and I used 'bzr branch' rather than 'bzr checkout', too ;)
<lifeless> TresEquis: :)
<rm200910> lifeless: I will try "bzr checkout http://bazaar.launchpad.net/~epics-core/epics-base/3.14 base3"
<rm200910> lifeless: yay! it's doing something
<Peng_> mwhudson: Personally, I'd like there to be a release before we go killing backwards compatibility, so anyone who isn't going to be upgrading to 2.0 or 2.1 just yet will still be able to enjoy the other bug fixes and whatever, but...I'm not the release manager, so I'm not going to demand anything.
<lifeless> Peng_: you could be
<Peng_> Yeah, I'm aware of that. Never done it before, so I dunno.
<rm200910> I don't seem to be able to do lp-login over a proxy either: "bzr: ERROR: Connection error: while sending CONNECT launchpad.net:443: [Errno 111] Connection refused"
<rm200910> thanks for translating the lp: URL to an http url.
<Peng_> IIRC the LP proxy issues should be fixed in 2.1.1?
<lifeless> mwhudson: bug 558343
<ubottu> Launchpad bug 558343 in bzr "NotImplementedError: "should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented" during lp name lookup" [Medium,Confirmed] https://launchpad.net/bugs/558343
<rm200910> I agree with the last comment on that bug: It's not low importance for me!
<lifeless> rm200910: well its got two elements
<lifeless> we can and will fix it in bzr independently of launchpad changing, as I read it
<lifeless> however, medium for us is wrong
<lifeless> rm200910: you should click on the 'does this bug affect you' bit
<mwhudson> lifeless: looks like it indeed
<mwhudson> i think the importance of low for launchpad is ok really, the problem on the server side is a strange response to a seriously bogus request
<lifeless> its probably a simple losa thing to fix
<lifeless> I'm looking at the bzr side of it now
<mwhudson> yeah, i have an unfounded suspicion that the redirect is coming from apache or something
<rm200910> Wow: it is of high importance now!
<lifeless> rm200910: in bzr, yes I upped it
<lifeless> rm200910: do you have pycurl installed ?
<rm200910> lifeless: I checked the "rpm -qa" list and did not find it.
<lifeless> rm200910: thanks
<rm200910> lifeless: I found this pycurl "/tools/RHEL5/src/bzr-2.1.1/bzrlib/transport/http/_pycurl.py"
<lifeless> yes, thats our adapter
<lifeless> only used if you have pycurl installed (don't install it, I was just gathering data)
<lifeless> rm200910: can you do some data gathering for me ?
<lifeless> http://pastebin.com/4KcJTJru
<lifeless> apply that patch to your bzrlib
<lifeless> and show me what it prints (when you have your proxy set as normal)
<rm200910> lifeless: sorry it's going to take a while. This is bazaar installed by my sysadmin
<rm200910> i'll look at installing something in my home directory
<lifeless> rm200910: it can run from source
<rm200910> I suppose I could do "bzr checkout lp:bzr"
<lifeless> rm200910: just grab our tarball, or branch http://bazaar.launchpad.net/bzr/~bzr-pqm/bzr.dev
<rm200910> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/bzr/~bzr-pqm/bzr.dev/"
<rm200910> http://wiki.bazaar.canonical.com/SourceDownloads doesn't give me the 2.1.1 sources.... i wonder where my sysadmin got it from
<rm200910> lifeless: I got 2.1.0 and I'll put your patches in
<rm200910> lifeless: it prints "xmlrpc.edge.launchpad.net"
<lifeless> thanks, I'm looking deeper now
<rm200910> It's doing a checkout when I substitute the "3-14" by "3.14" /home/rm200910/tools/bzr-2.1.0/bzr checkout lp:epics-base/3.14 base1
<lifeless> interesting
<parthm> in a pqm failure mail is an AssertionError in 'File ".../testtools/testcase.py", line 276, in expectFailure' a failure or is it expected failure?
<rm200910> it takes for ever though. Still doing it 5 minutes on. The http checkout was almost immediate
<parthm> i am trying to understand why https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414 is failing while tests pass locally
<rm200910> thanks for your help. Good-bye
<lifeless> rm200910: ok, bye
<lifeless> parthm: expectFailure is an assertion that something should error
<parthm> lifeless: thanks. so thats nothing to worry about. will look some more into the log.
<parthm> aah. its was test_help which was failing. hmm.
<parthm> i was thinking the huge pqm error log should be a text attachment rather than inmail content. made FF crash :(
<lifeless> parthm: that would be good to; though its meant to filter and not be so hgue :(
<parthm> lifeless: it was 3.1M for me as a mail (on gmail). FF takes a looong time for search and hangs when i copy. When I had gmail save, it saved as html :( .... had to run it through html2txt
<parthm> then used vim with text ... and all was well :)
<parthm> lifeless: i thought there might be some filtering ... but this is the first time i had to go through it so i wasn't sure.
<parthm> filtering would be real neat.
<parthm> is it possible to submit the same patch to pqm ... i know p1 is running and will fail. can i put in p2 without waiting for p1 to finish (with nothing between p1 and p2)?
<parthm> p2 is p1 with some fixes.
<lifeless> sure
<parthm> lifeless: cool. thanks.
 * parthm goes to resubmit ls-short-opts patch with fixes.
<AfC> Someone in my office just said "Hudson doesn't directly support bzr" but I could have sworn I heard lifeless talking about how he'd been using Hudson of late for $something. Surely Hudson and Bazaar get along just fine, no?
<lifeless> AfC: they lied
<AfC> :)
<AfC> ok
<lifeless> AfC: it supports bzr as much as it supports CVS or svn
<lifeless> install the plugin from the plugin admin page.
<lifeless> Then Go Hit Them.
<AfC> ouch
<AfC> (the client just typed that)
<AfC> lifeless: thank you very kindly Robert
<lifeless> AfC: sorry :P
<AfC> ha, no, he just typed "ouch" to convey his appreciation of your humour.
<lifeless> oh phew :>
<AfC> s'ok
<sangi> while running serve-branches to install loggerhead,its throwing an error like No handlers could be found for logger "bzr"
<Peng_> sangi: You said that earlier. It's not a problem.
<Peng_> sangi: And serve-branches doesn't install Loggerhead, it just runs it.
<sangi> Peng_, but it is not proceding
<Peng_> sangi: What you pasted earlier looked fine.
<sangi> Peng_, http://pastebin.com/ws0AwuGn
<Peng_> sangi: Visit http://127.0.0.1:8080/ in a browser. It's not working?
<sangi> Peng_, thanks, i am able to view it
<Peng_> OK then.
<parthm> really trivial docstring patch at https://code.launchpad.net/~parthm/bzr/trivial-doc-followup-549310-mandatory-whoami/+merge/24877
<parthm> if someone can approve it i can land it. ... i don't want to approve myself as i am the one who proposed :)
 * parthm looks at vila
<parthm> vila: thanks.
<lifeless> hi poolie
<poolie> hi lifeless, parthm
<parthm> poolie: hi
<parthm> poolie, lifeless: i like the suggestion from lifeless to do 538868-message-for-heavy-checkout more broadly i.e. if revs to be pulled is > N.
<vila> hi all
<vila> parthm: what happened with your short-ls patch ? It landed in bzr.dev apparently...
<GaryvdM> Hi vila
<GungaDin> How do I un-add a file that hasn't been committed?
<avu> GungaDin, bzr rm --keep <file>
<GaryvdM> vila: Nudge for https://code.edge.launchpad.net/~jelmer/bzr/more-colo/+merge/23592
<GaryvdM> vila: You reviwed it previously. Branch has been update since you last reviewed.
<parthm> vila: hi. short-ls patch had test failures (test_help) ... i had a little difficulty (bug #576800) finding the test failure but its fixed and landed :)
<ubottu> Launchpad bug 576800 in bzr "pqm failure log should be attached as a text file" [Low,Confirmed] https://launchpad.net/bugs/576800
<vila> parthm: ok, thanks for the feedback
<vila> GaryvdM: I'm looking into it
<sangi> starting loggerhead throws an error like sudo: no passwd entry for loggerhead! Loggerhead is *not* running
<Peng_> sangi: That sounds like an issue with however you're trying to start it, not Loggerhead itself.
<Peng_> Err, um.
<Peng_> I missed the "sudo".
<Peng_> sangi: That has nothing to do with Loggerhead. From the error message, it sounds like you're trying to sudo to/from an account that either doesn't exist or doesn't have a password set.
<sangi> Peng_, ok
<bialix> hi
<GaryvdM> Hi bialix
<bialix> hi Gary
<bialix> my last day online
<GaryvdM> bialix: I'll try find you on Sunday
<GaryvdM> I should be there by midday.
<bialix> is somebody wants a souvenir from Ukraine -- shout
<Tak> /Library/Python/2.5/site-packages/bzrlib/lockable_files.py:61: UserWarning: 'LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///Users/levi/Code/mono-repo/monodevelop/.bzr/branch/>)' was gc'd while locked
<Tak> problem? or no?
<bialix> Tak: during selftest?
<Tak> no, at runtime
<bialix> not a critical problem, but it seems some code forgot to unlock
<bialix> I'd say file a bug
<Tak> meh, be nice if I had a stack trace
<bialix> there is no stacj trace
<bialix> it's a from garbage collector
<bialix> some code locked the branch and then forgot to unlock
<bialix> is it from regular bzr operations?>
<bialix> or some plugin involved?
<Tak> bzr-svn at least is involved
<Tak> and bzrlib is being used, although I'm using the ui cmd classes as much as possible
<lifeless_> Tak: so, its possibly a bug in bzrlib
<lifeless_> Tak: or, and arguably more likely, a bug in your code. As bialix says, its happening from the object finaliser, so there isn't a stack to refer to to get a backtrace - or at least, not one related to the finalising code
<Tak> oh, it definitely could be a bug in my code
<Tak> I'm only locking manually in a few places, and I'm trying to always unlock in a finally block, but I could have missed something
<Tak> I'm also manually deleting objects in a few places
<lifeless> well, deleting won't unlock
<lifeless> so be sure you've unlocked before you delete
<Tak> yeah, I need to make sure I'm doing that
<GaryvdM> bialix: Are you still here.
<GaryvdM> bialix: If so, please check you email.
<bialix> ack
<bialix> which one?
<GaryvdM> Re: Threads
<bialix> guys, during the sprint, please use my gmail account
<GaryvdM> bialix: Sent to ml
<GaryvdM> Not sure where that goes to
<bialix> I see the mail
<bialix> GaryvdM: cool@
<bialix> GaryvdM: cool!
<bialix> I don't have time to read your code right now, sorry
<GaryvdM> bialix: Ok np
<bialix> but perhaps we have to carefully testing it on PyQt 4.4.x which is still default for windows
<GaryvdM> Sure
<GaryvdM> bialix: Did we not say we were going to upgrade that
<bialix> we said, but 2.1 unlikely will be upgraded
<bialix> only 2.2 and up
<GaryvdM> bialix: Yes ok.
<bialix> so I'd better double test
<bialix> although based on your estimate we'll have 2.2 as defult
<bialix> default
<GaryvdM> bialix: Yes, Try for 2.3...
<bialix> or rather target trunk2a of qbzr with threads to 2.2+
<GaryvdM> Yes
 * bialix has to go, hope will be online sometime tomorrow, or maybe not. see ya soon!
<GaryvdM> luks: Hi. I sent a mail re threads in qbzr to the ml. I would really like it if you could take a look at that code. It is only 123 lines.
<GaryvdM> luks: Any pit falls for picard would be valuable to.
<GaryvdM> *from
<GaryvdM> http://bazaar.launchpad.net/~garyvdm/+junk/thread-test/annotate/head:/main.py
<javatexan> hey guys, I have totally messed up my local repos, is there a easy way to revert to the network version?  bzr pull is not doing it....
<xnox> Is there bzr equivalent of git reflog?
<xnox> i did a rebase of 10 commits and I did it wrong
<xnox> I need to checkout the old head again but I don't know the revid.
<xnox> Where can I look up all available revids in the repository?
<fullermd> You can use 'heads' to try tracking it down, since it's presumably a dead head at this point.
<lifeless> xnox: bzr heads --dead
<xnox> fullermd, that gave me the current tip
<xnox> lifeless, that worked
 * xnox panic is over
<xnox> thank you
<a212901390231901> hmpf, sister has managed to forget her laptop again, so I have nothing to borrow to bring with me
#bzr 2010-05-08
<lifeless> a212901390231901: :(
<lifeless> a212901390231901: there is probably going to be a netbook or something if we ask around
<a212901390231901> I'm going to stick key and a few things on a usb stick and leave this box up with the server
<a212901390231901> do you know if there's anything particular we have to do on arrival Robert?
<lifeless> register for your room
<lifeless> have you read mariannas email?
<a212901390231901> walking up to front desk and declaring my email address doesn't seem quite right
<a212901390231901> yup.
<lifeless> name, rank, serial number
<a212901390231901> the "IMPORTANT: Bazaar Sprint (during UDS), 10-14 May 2010" doesn't seem to say anything about checking in as such
<lifeless> there will be a front desk
<lifeless> name the event and your details
<lifeless> thats usuaully all it takes
<a212901390231901> thanks.
<lifeless> do you have a phone that will roam ?
<a212901390231901> there's also a hotel shuffle thing, but I don't think I need to worry about that till monday.
<a212901390231901> I believe UK mobiles are fine on the continent, if that's what you mean
<a212901390231901> used it there before.
<lifeless> if you do, just make sure you have mariannas mobile, and mine too if you like
<a212901390231901> good thought.
<kojiro> I forgot to add and commit one file that was supposed to go with stuff I already committed. Is there any way to add the file and make it part of the previous commit?
<xnox> kojiro, if you didn't publish your results you can do
<Peng_> kojiro: If you haven't pushed yet, make a copy of your commit message, "bzr uncommit", "bzr add", "bzr commit".
<xnox> yes Peng_ was quicker =)
<kojiro> heh, to me the posts look simultaneous
<Peng> xnonx was first from my POV, but it was within a second.
 * xnox has 1.1s lag with the server
<xnox> so to me I was half way through typing uncommit, add, commit and then i saw Peng
<kojiro> thanks, gents
<kojiro> hate to ask and run, but I gotta get home
<godbyk> For the project I work on, we have a new series in launchpad that is currently based on the main series (https://launchpad.net/ubuntu-manual/+series).
<godbyk> We have a bunch of cruft in the main series that I would like to drop in the lucid-e2 branch. Deleting the files leaves behind all the history and whatnot, so pulling a fresh copy of lucid-e2 is a 200 MB download.
<godbyk> Is there a way I can either purge the history of files that no longer exist or a way to safely kill that branch and create a fresh one in its place without removing the milestones, etc. in launchpad?
<godbyk> (if this is a question that should be directed to #launchpad, let me know.)
<godbyk> thanks for your help!
<xnox> godbyk, mark the branch as abandoned and set a different branch as a series target
<xnox> godbyk, if there is a lot of work you can use $ bzr fast-export && bzr fast-import-filter
<xnox> milestones have no meaning with respect to branches only series do.
<xnox> and you can change which branch series point at easily
<godbyk> xnox: that sounds perfect! thanks for your help.  (I see now in the series settings where it's pointed at the bzr branch.)
<lifeless> vila: https://code.edge.launchpad.net/~lifeless/bzr/bug-558343-wrong-host-with-proxy/+merge/24938
<dcoles> If I'm using bazaar to mirror another VCS system's repository, it's generally a bad idea to use a non-determanistic importer unless I'm always the one doing the importing, correct?
<dcoles> Because if someone tries to pull from the original VCS with something like bzr-fastimport we'll get diverging revision IDs.
<lifeless> hai
<thrillERboy> I tried to create a new project on launchpad
<thrillERboy> My file is showning non-versioned in bazaar, so I can push those files, how to add versions to files?
<thrillERboy> OMG its in Topic I guess, lemme go thru it
<idnaria> thrillERboy_: I believe you want the "bzr add" command
<eric_f> When a merge conflict occurs, which file is the newest one from the repo I tried to bzr update from? .BASE or .THIS?
<Peng_> .THIS is this branch's copy of the file, .OTHER is the copy in the branch you're trying to merge in, and .BASE is their common ancestor.
<Peng_> So .BASE is the oldest.
<eric_f> that means .OTHER would be the newest from the repo I'm bound to then, correct?
<eric_f> in this case the file I wantâ¦ (it's a binary one)
<Peng_> Yeah.
<eric_f> Peng: thanks! :-)
<fbond> lla
<thumper> jelmer_: we are getting the bzr-svn config concurrent write issue again, this time causes a number of imports to be marked as failing
<slangasek> gah, I've just been screwed by trying to use bzr commit --local on a branch bound to an Ubuntu lucid package branch
<slangasek> because 'bzr update && bzr commit' fails since lucid is no longer writable
<slangasek> how can I get the previous tip revision back on top?
<slangasek> n/m, found the answer
#bzr 2010-05-09
<jelmer_> thumper: unfortunately that's really a problem in bzrlib.config
<Kamping_Kaiser> http://paste.debian.net/72622/ any suggetions for debugging this? i tried pushing a new branch, bzr failed. tried again, got this error
<spiv> Kamping_Kaiser: that paste link doesn't seem to work?
<spiv> Kamping_Kaiser: without seeing the error I'm guessing you either need to try "bzr break-lock URL" or "bzr push --use-existing-dir", but those are just wild guesses :)
<Kamping_Kaiser> spiv: odd. it showed me the page after i posted it
<Kamping_Kaiser> bzr push
<Kamping_Kaiser> Using saved push location: sftp://kgoetz@bzr.savannah.nongnu.org/srv/bzr/gnewsense/packages/apt
<Kamping_Kaiser> bzr: ERROR (ignored): <bzrlib.btree_index.BTreeGraphIndex object at 0xb1a1a0c>
<Kamping_Kaiser> bzr: ERROR: Generic path error: 'nbt0u9388m2c62skk7f6.pack': Failure: unable to rename to '../packs/f9193d0ede80c9739d71c395915f49d2.pack')
<Kamping_Kaiser> is hte error
<Kamping_Kaiser> looks like i only selected 1hr for the paste, so that explains that
<spiv> Kamping_Kaiser: odd error
<spiv> Kamping_Kaiser: for some reason that SFTP server is not allowing bzr to rename the just-uploaded pack file from its temporary location to its final location.
<Kamping_Kaiser> that is odd. i'll go and ask savannah if there are known issues with the bzr repos
<spiv> I guess it's possible it's a permission error, but that would be pretty unusual, that would imply you don't have rights to modify .bzr/repository/packs but do have rights to modify .bzr/repository/upload
<Kamping_Kaiser> i don't see a .bzr/repository/ on the server. is that directory created with the first pack file being moved into place?
<spiv> Where did you look?  There's probably a shared repo at about /srv/bzr/gnewsense
<spiv> i.e. /srv/bzr/gnewsense/.bzr/repository, maybe +/- a directory level.
<Kamping_Kaiser> i looked under /srv/bzr/gnewsense/packages/apt/.bzr/ , i'll check the other path too
<spiv> In answer to the question, no, the repository is created well before bzr starts creating or uploading pack files
<Kamping_Kaiser> perms on that pack file appear to match the others in the directory. where 'the directory' is /srv/bzr/gnewsense/.bzr/repository
<nomatter001> hi
<nomatter001> i habe a problem after an unsuccessful bzr push
<nomatter001> last push was interrupted by bzr: ERROR: [Errno 4] Interrupted system callerting stream:repacking texts:texts 433/727
<nomatter001> and now if i try to push again i get: bzr: ERROR (ignored): 'sftp://tfilebank@alf1.brunner.at/home/tfilebank/filebanking.repo/.bzr/repository/upload/ro11tk7b9gparngiezvv.pack'
<nomatter001> bzr: ERROR: Generic path error: 'ro11tk7b9gparngiezvv.pack': Failure: unable to rename to '../packs/9613af81d2a9ac04466355023a7f044c.pack')
<nomatter001> anybody any idea?
<nomatter001> i tried to repair things now by removing 9613af81d2a9ac04466355023a7f044c.pack
<nomatter001> now i can push again but looks like push has the same problem now
<nomatter001> stops doing things at \  44520KB   640KB/s | Fetching revisions:Inserting stream:repacking texts:texts 433/727
<nomatter001> output freezes here
<hno> Playing around with shelving changes, and wonder if there is any method of inspecting a shelved change without unshelving it? shelve --list only lists the description, not the content..
<fullermd_> There's an `unshelve --preview`.
<hno> fullermd_: Since which bzr version? Not shown in bzr unshelve --help for me (2.0.5)
<fullermd_> Mmm, looks like it came in with 2.1 according to NEWS.
<hno> Ok. A reason for upgrading then.
<hno> thanks
#bzr 2011-05-02
<lifeless> jelmer: I'm also going to fix testrepository with trunk
<lifeless> TagCollapsingDecorator doesn't forward testsRun
<jelmer> I've been wondering about that one
<jelmer> so far I've just been hand editing testsRun+=1 out
<lifeless> oh
<lifeless> I see
<lifeless> jml: rev 91.5.21 in testrepository breaks with your TagCollapsingDecorator in subunit.
<lifeless> jml: FWICT its working around 'after filtering testsRun is too small'
<lifeless> as a bug on subunit. So I'm going to fix that there.
<Ursinha> hello
<lifeless> hi Ursinha
<spiv> Morning folks.
<lifeless> poolie: spiv: I wonder if someone from the bzr team could debug this repository problem reported on friday on LP ? (the mixxx/1.9 issue)
<poolie> hi there spiv, lifeless
<poolie> i think we should, too
<poolie> spiv, could you look at it first?
<poolie> i'm leaving tomorrow so i'm not the best choice
<spiv> poolie: Ok
<poolie> thanks
<lifeless> thanks!
<vila> hi all !
* vila changed the topic of #bzr to:  Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
 * fullermd waves.
<vila> hmm, has anyone else trouble to access code.lp.net ?
<vila> ha, went trough, finally
<spm> vila: 1. heyo! 2. yeah, we've lost a key server, is causing pain.
<vila> spm: 1. Hey :) 2. No worries
<poolie> hi vila
<poolie> how are you?
<vila> poolie: hey, hopefully not jetlagged anymore ;)
<poolie> good for you
<vila> you bet ;)
<vila> at least Valentine knows what jetlag *is* about :)
<vila> now
<poolie> haha
<vila> thanks for the reviews on the config stuff to all !
<poolie> S was the same when she first came to Europe with me
<poolie> no problem, thanks for writing it
<poolie> it looks really good and i'm keen to see it landed
<poolie> i hope that came across in the reviews
<vila> yup
<vila> there are some points I don't fully agree and I'll explain why but there are also missing parts that made the review harder, I'll also explain the plan to go from there but may be we can discuss it briefly here
<vila> roughly,
<vila> I'd like to instrument the test suite so we can use it to gather useful stats for a significant set of config uses
<vila> and from that being able to compare the actual and the proposed implementation when it comes to number of IOs and other more fine-grained patterns (how may objects are built, reused etc)
<poolie> i'm going to be leaving sydney tomorrow and i'll be semi-offline
<vila> s/may/many/
<vila> ok, np
<poolie> at UDS, until i see you after that
<poolie> so, grab my attention if you want to talk
<poolie> but don't block too much on me
<vila> ok
<poolie> maybe we should talk now about the points where we don't agree?
<vila> your comment on the whole mp triggered a series of 'yes' from me ;)
<vila> ha right,
<vila> one is using ConfigStore instead of config.Store, I'd like to use this work to show case my ideas there, concretely introducing __repr__ to address your point about python tracebacks to start with
<vila> i.e. I think there are still valuable discussions to have about name spaces
<vila> the distinction between read-only/mutable as class names, hmm, there are various ways to look at it, I need to dig a bit more so not really a disagreement
<poolie> i'm glad you mostly liked it
<poolie> ah, this reminds me a bit of the thing a while ago about 'import config;. .... config.Store(...)'
<poolie> which istr john objecting to
<poolie> and i'm not a big fan myself either
<vila> callables for sections: I'm only mid-way in the whole implementation and I don't want to optimize too early
<vila> I think jam *agrees* with <module>.<symbol> instead
<lifeless> spiv: hi
<lifeless> spiv: did you have any luck with that bug ?
<vila> but some sections are just dicts (true python dicts or almost true python dicts) so forcing the caller to wrap them in a callable sounds weird
<poolie> i'm not sure exactly what you're talking about here
<vila> I also have the intuition that not caching them may simplify building stack variations (as in, I have a config.LocationStack for '/xx/yy' and I reuse it to build one for 'xx/yy/zz')
<vila> poolie: nm then, I'll explain better in the review
<poolie> re your comment above
<poolie> i'm not so sure about instrumenting the performance during the test case
<poolie> i mean, during the test suite in general
<poolie> its patterns are not necessarily very representative
<poolie> a deterministic test for some particular cases could be good
<poolie> or, i guess, measuring the overall test run time
<vila> I'm more after numbers than time
<poolie> but perhaps better measuring actual bzr operations like branching or merging
<vila> i.e. reading/writing  1.000s config files vs 10s
<vila> err 's not seconfs
<vila> seconds :)
<vila> and I think the test suite is still somehow representative of *somthing*, we just need to learn to use it as what it is
<vila> it may not *directly* translates to the user experience but being able to get some numbers for one set of operations across various platforms (for example) may still be interesting
<poolie> ok
<poolie> were you planning to do this before merging?
<vila> and it will help demonstrate goals like: and now we read a given config file only once per operation
<vila> not necessarily, I haven't look precisely yet, but since the overall proposed stack doesn't interfere with the actual implementation, I'd be happy to land everything that reached an agreement and continue with incremental steps
<spiv> lifeless: some, although I've been perturbed by intermittent segfaults in bzr while doing so!
<lifeless> \o/
<poolie> !
<spiv> (current hypothesis is my hardware)
<poolie> seems likely
<poolie> maybe time for a memtest run?
<spiv> Yeah.
<fullermd> What, you just check for logged ECC events...
<vila> fullermd: :-p
<spiv> (Although the memtest-like that lenovo includes in Windows saw no issues a few weeks ago when I let it do a full system check)
<lifeless> spiv: you've moved on from your dell?
<spiv> lifeless: Yeah, since nearly a year ago now!
<spiv> Thinkpad T410
<poolie> spiv,  can you put a note on the bug saying what you did find out, before you end your day?
<poolie> or maybe before you reboot into that
<spiv> poolie: yep
<poolie> thanks
<poolie> wee, look at all the builds
<poolie> vila, regarding class naming
<poolie> at the moment we have a reasonably consistent practice of just using the class name in the repr, just importing them directly, and making them tolerably unique
<poolie> i think if you want to change that we should probably try to do so independently of any other work
<poolie> though it becomes a bit like those cases where you would never get around to doing the cleanup if it wasn't as part of a particular bug
<poolie> at any rate i think having the _discussion_ separately may be better
<poolie> it will give you a chance to explain the advantage
<poolie> vila, can you see my direct messages?
<jam> morning poolie
<poolie> hi there jam
<vila> well, I don't think we are that consistent, if only because we had a lot of cases where it broke or lead to weird behaviors with lazy imports
<jam> vila: I do prefer "from bzrlib import config; config.XXX" however, I'm not sure about config.Store vs config.ConfigStore. The main issue is stuff like tracebacks don't print the module for objects. So you just see "Store". Thus, even though the code may have namespaces, classes should generally be unique.
<vila> jam: hence my proposal to add the module into the __repr__ , AFAIK, we never extract them from there so if the issue is just that they are missing, adding them should fix it
<sobersabre> hi guys.
<sobersabre> I'm looking for an email post-commit notifier plugin.
<vila> jam, poolie: part of the issues with lazy imports are probably linked to the fact that importing a symbol into another module *duplicates* this symbol, while using the module.symbol syntax doesn't
<poolie> hi there
<poolie> sobersabre, bzr-email?
<poolie> vila i find always writing config.Store() in the code is a bit long
<poolie> (though i guess not that much longer than ConfigStore)
<vila> come on, no longer than ConfigStore()
<vila> yup
<poolie> hm
<poolie> anyhow, i wouldn't block the review on it
<vila> cool
<poolie> _my_ experience with python tends to lead me to prefer fairly standalone class names
<sobersabre> I looked at bzr-email and bzr-email-notifier
<poolie> but i'm not sure i can objectively justify it
<poolie> i have certainly had cases where it was quite confusing that there were two different Foos from different modules
<sobersabre> I am not sure where I'm failing, but I need to be able to control the destination of emails on per folder basis. which of them supports this ?
<poolie> istr one case of something like whatever.Exception
<poolie> bzr-email will do that and i'm pretty sure the docs have examples
<poolie> sorry i missed where you said you looked
<poolie> perhaps it is not clear enough
<sobersabre> poolie: I looked at the examples. I didn't see referring to location.
<sobersabre> I somehow remember that there can be a section definition [url] and below it its own definitions for destionation, etc.
<vila> poolie: well, in my case it's not specific to python, it's more about having a rule that fails in mysterious ways at the most inconvenient times ;)
<poolie> basically you want a [/home/sobersabre/....whatever] section in your .bazaar/locations.conf
<sobersabre> but I don't remember the syntax of the right url.
<poolie> then under that, mail_to=who@example.com
<sobersabre> OH!
<poolie> i don't recall if that's the right variable
<sobersabre> I think this is what I've missed locations.conf!
<poolie> what's the rule?
<sobersabre> poolie: no idea. I want to send to various destination depending on the location.
<sobersabre> lemme reread the fine manual.
<vila> importing symbols and creating duplicates. This led to believe I failed all socket/thread leaks only to realize that get_transport has been duplicated before I could redefine it was the most painful one
<vila> but many IllegalScopeReplacer failures have the same root cause
<vila> the trouble is that you can *most of the time* import symbols and be fine
<poolie> ah, that can be bad too
<sobersabre> hm... poolie I don't see any location related example in the output of bzr help email
<vila> but suddenly one case breaks and it's generally quite hard to fix
<poolie> ok
<poolie> and then config.ConfigSection is a bit long
<vila> and redundant
<poolie> if the alternative is to dot-qualify every single symbol things will be pretty long everywhere though
<spiv> vila: I don't like making our code a bit more verbose just to make monkey-patching globals more effective.  I'd rather fix the need to monkey-patch that object at all.
<vila> there are valid cases where a module can relay a symbol
<spiv> Or am I misunderstanding/remembering what you mean by "redefine"?
<vila> spiv: true, that means adding registries here and there and I'm all in favor of doing that because it makes the code clearer anyway
<poolie> yeah
<vila> (get_transport is really a registry in disguise anyway)
<spiv> vila: sometimes hooks rather than registries, but yeah.
<vila> spiv: indeed
<vila> as for ConfigSection, the only valid use cases should be to define daughter classes and I don't mind being a bit more verbose there
<poolie> anyhow, i wouldn't block on it but i would prefer if you find more explicit names
<vila> poolie: funnily enough, that's one of my goals and we seem to all agree that making the *module* name part of them is a Good Thing
<poolie> what i mean is i would prefer 'class ConfigStack' etc
<poolie> i'm happy to also separately look at how things interact with lazy import etc
<vila> yeah, we disagree on the dot and the case is what I meant ;)
<poolie> let's not get stuck on it
<vila> indeed, if it's too controversial I'll wait for a better case anyway, my query here was: can I have a go here and see if we can reach an agreement
<vila> if we can't, I can always rename all classes in the end before they are used in the wild
<poolie> vila i hate to interrupt you from this but i would like you to have a look at a bug for guilhem
<poolie> which is bug 494147
<ubot5> Launchpad bug 494147 in FEniCS Web "The platform sniffer is highly flaky" [Undecided,New] https://launchpad.net/bugs/494147
<poolie> hm no
<poolie> bug 494197
<ubot5> Launchpad bug 494197 in Bazaar "Fail to create .BASE when getting conflicts in some criss-cross merges" [High,Confirmed] https://launchpad.net/bugs/494197
<poolie> heaven help us when we get to seven digits
<vila> poolie: ghaa, I don't even understand what jam is saying in the last comment so that will be a huge context switch ;-/
<poolie> hm, maybe jam could do it?
<vila> well "understand" as in: having an idea of what code is involved there
<poolie> so he has push of tags, and some bugs about tree references
<poolie> the first seemed like it might need time to digest
<poolie> maybe he'll be back in a bit
<vila> at least pairing would minimize the effort
<jam> I could, or I certainly could pair on it
<jam> the depth is certainly a bit tricky, because the obvious answer doesn't work very well because of side-effects
<poolie> there was one other he mentioned which might be easier...
<poolie> bug 721211
<ubot5> Launchpad bug 721211 in Bazaar "bzr merge --weave gives superfluous content conflict" [High,Confirmed] https://launchpad.net/bugs/721211
<vila> O.M.G. When did the comments on mps became rezisable ? Hug from me to the guy fixing that ;)
<bialix> heya vila
<vila> bialix: heya !
<vila> bialix: I may have some mail backlog but: did you release qbzr this week-end ?
<bialix> so, tomorrow is 2.4b2 official day, isn't it?
<vila> in theory, yes
<bialix> vila: just finished it. my weekend is still going
<bialix> 1-2 May is holiday in ex-USSR
<vila> bialix: but the source is already frozen so it's more about announcing the installers anyway and you made it clear that using trunk were fine
<vila> s/trunk/qbzr trunk/
<vila> ha ha, lucky you ! Only 1st is holiday here and that was a Sunday ;)
<bialix> well, I wonder if Gary will be able to build win32 installer
<bialix> I need to setup my own build machine, I just need several free days for this
<bialix> new qbzr is pretty exciting, IMO
<bialix> I'm glad we have so many good contributions for it
<bialix> vila: http://bazaarvcs.wordpress.com/2011/05/02/qbzr-0-21-beta1-new-features/ :-)
<vila> bialix: cool !
<bialix> :-)
<jam> vila: do you have a clean run of windows since my last patch?
<vila> jam: lunch time, but I haven't checked yet, will do and report
<jelmer> jam: still there?
<jelmer> jam: I'm trying to make sure I get the logic for creating new text revisions right. What I have currently:
<jelmer> * for directories only a new text revision is created when the directory is created
<jelmer> * for files/symlinks a new text revision is created if the text or the metadata changes or if there were multiple (different) text parents
<jam> jelmer: not quite correct
<jam> renames will create a new record for directories and files/symlinks
<jam> vila: thanks, everything I saw was failed runs
<jelmer> jam: ok
<vila> jam: yeah, early fails to make matters worse :-/
<jelmer> jam: and IIUC directories don't get a new text revision when their children are created
<jelmer> jam: ?
<jam> jelmer: so for files, if you think in terms of 'last modified'. If one sides supersedes another, than we just take it. If neither is a "head" then we create a new entry
<jam> jelmer: directories are not updated by changing children, correct
<jelmer> jam: when you say one side supersedes the other, you mean that if a merge takes the version from one of the parents as-is, the text revision stays the same?
<jelmer> iow, just the text revision from that parent?
<jam> jelmer: http://paste.ubuntu.com/602216/
<jam> if history goes down
<jam> if when we merge C into B
<jam> if C says "A", and B says "B", then B supersedes A, and wins cleanly (no new text)
<jam> if C and B say C and B, then we create a new entry for D
<jelmer> ah, I see
<jelmer> jam: I think I have a clear idea of it now. Thanks
<jam> jelmer: this is the hardest one: http://paste.ubuntu.com/602220/
<jam> at least, the hardest to get right if you don't track last-modified directly
<jam> I'm not 100% sure it is *worth* spending a lot of time on. But it does mean graph correct vs wrong
<jam> which is why we didn't just go with sha1 as our text handle, because wanted file graphs, and sha1 can converge
<jam> while the graphs never do
<jam> hg uses sha(parent_sha1 + content)
<jam> which doesn't often converge
<jam> unless 2 commits apply the same patch to the same base revision
<jelmer> I'm mainly worried about getting the text store revision graph right, as not getting it right leads to bugs like bug 485601
<ubot5> Launchpad bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,In progress] https://launchpad.net/bugs/485601
<jelmer> jam: are there tests for this behaviour, and if so, where do they live?
<jam> jelmer: probably in per_commit_builder
<jam> or per_repository test_commit_builder ?
<jelmer> jam: That makes sense, thanks.
<jelmer> jam: Found them.
<jam> I count 86 tests in that file, so it is fairly complete for edge cases
<jam> also tests kind changes (file becoming directory, etc)
<jelmer> looks like I need to fix the testsuite to not require a working tree in the same location first :-/
<lamont> what's the bzr equivalent of cherry-pick?
<jam> lamont: "bzr merge -c REVNO" ?
<lamont> or 'tever to get just a single revision in a manner that I can commit it to a different branch, with the tracking I want
<lamont> can I do it without the branch?
<jam> lamont: I'm not sure what you mean by "with the tracking I want". And I don't know how you merge without the branch.
<lamont> that is, export it from one, sneakernet or whatever it to the other, and then commit it?
<jam> lamont: "bzr send -c REVNO -o outputfile; bzr merge outputfile" I think works
<jam> but you may need "-r REVNO-1..REVNO"
<jam> and send gets a bit funky in general, because it is trying to be smarter than you
<lamont> in that other system I sometimes use, I can email the patch in a manner that the far end can stuff it into their branch
<lamont> "the tracking I want" == the commit is intact as itself, and a future merge back from the other branch won't cause a conflict simply because of being the same change
<lamont> ok
<jam> lamont: merges are never a conflict simply because of being the same change. It may conflict if you then do a change on top of that one
<jam> (patch is change a => b, but you then change it to C, a future merge may conflict because of A=>B)
<jam> lamont: I would probably say, get access to the branch if possible, as that makes life easier, but other ways are possible if necessary
<lamont> I would think that if I make the identical change in two branches, that there could be a merge conflict, no?
<lamont> ISTR seeing just such a thing at least once in the last decade...
<jam> lamont: identical change == no conflict, just happy convergence
<lamont> well, near-decade
<jam> the main problem is near-identical changes
<lamont> right
<lamont> and whitespace prolly matters
<jam> yep
<jam> I think we could do something about whitespace, but in some languages it *really* matters.
<vila> jam: yes, your patch fixed the issue
<jam> vila: thanks
<jelmer> Is python2.5 now acceptable for 2.4?
<jelmer> I think I missed the last bit of discussion about it wrt John's patch.
<jam> jelmer: my specific patch is bumped in favor of a compatible one. I don't think the decision is 100% clear to me yet
<naoki> I want a preprocessor for Python....
<naoki> #if PyVERSION < 2060
<naoki> #define b(s) s
<naoki> #else
<naoki> #if PyVERSION < 3000
<naoki> #define b(s) bs
<naoki> #else
<cbz_> So pipe the script through cpp at setup
<naoki> #define b(s) s
<naoki> #endif *2
<naoki> If we use macros like these, we can generate source package for 2.5 and 3.0.
<naoki> #define b(s) b##s
<naoki> My cpp stops because b"foo" is not a valid token in C.
<cbz_> m4 plus a set of custom macros then ;)
<naoki> So we can prepare for moving to Python3 without stopping Python 2.5 support.
<naoki> B("foo") => "foo" (for Python 2.5
<naoki> B("foo") => b"foo" (for Python 2.6 and 3
<tbnorth> hi all - is there a way to move a file from a branch in one project to a branch in another project, i.e. move a file between projects which are both under bzr, but not really related?
<jelmer> tbnorth: there is "bzr add --use-file-ids-from" which can let you keep the existing file id in case the projects are ever merged in the future
<tbnorth> jelmer: so you'd lose the history in the file's new home, but get it back it the projects later merged?
<jelmer> tbnorth: yeah. The alternative is to use "bzr merge -r0..-1 ../path/to/file". That will bring in the history of that specific file but also of the rest of the branch.
<tbnorth> ok, thanks.
<CoffeeIV> I have a project in which some .pdf files are being recogized as binary, and some are not. (doing a bzr diff makes it obivous which are which)  I have looked at https://bugs.launchpad.net/bzr/+bug/218128 , just wondering if there was a workaround
<ubot5> Ubuntu bug 218128 in Bazaar "want a way to mark files as binary even if they look like text (eg pdf files)" [Medium,Confirmed]
<morsik> hi
<morsik> i just installed bzr on my debian server
<morsik> friend (he have shell account) asked me for this
<morsik> but, it's possible to add someone to his bazaar so someone can make changes in his project?
<morsik> the only way i see is creating sysaccount for someone...
<levu> is it possible to merge only one file?
<morsik> why when i'm doing  bzr co bzr+ssh://username@server/ i'm getting:   bzr: ERROR: Not a branch: "bzr+ssh://username@server/".
<morsik> ?
<lifeless> morsik: that url is at the root of the server, generally there will be a path component as well
<morsik> lifeless: i tried /projectname too, with the same result
<morsik> i'm trying to do multiuser repo...
<lifeless> morsik: have you read the docs on this?
<morsik> lifeless: what doc? this? http://wiki.bazaar.canonical.com/BzrAccess
<lifeless> ~http://doc.bazaar.canonical.com/bzr.2.3/en/
<lifeless> bah
<lifeless> morsik: http://doc.bazaar.canonical.com/bzr.2.3/en/ -
<morsik> this is the same link ;p
<lifeless> http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/index.html and http://doc.bazaar.canonical.com/bzr.2.3/en/tutorials/index.html
<lifeless> may be useful
<morsik> lifeless: i saw this tutorial
<morsik> i created repo on user1
<morsik> but anotheruser needs to have access to it...
<morsik> i created also .ssh/authorized_keys
<jelmer> morsik: where is your repository located on the server, what's the path?
<morsik> jelmer: /home/sirmacik/sites/bzr  and here is project /proj
<jelmer> morsik: are you running "bzr co bzr+ssh://username@server/home/sirmacik/sites/bzr/proj" ?
<morsik> no
<jelmer> morsik: what are you running?
<morsik> jelmer: ok, that syntax works...
<jelmer> morsik: you need to specify the full path on the server; you can use ~ to mean the users home directory
<morsik> question is, whats permissions should be on sirmacik user so i can modify his project
<jelmer> morsik: writable in some way by your user account; you could put them in the same group and make the repository group writable
<morsik> yeah, that i know, but probably theres no other nice option?
<jelmer> morsik: there's also the bzr_access script
<jelmer> http://wiki.bazaar.canonical.com/BzrAccess
<morsik> jelmer: i tried this, with no success... or i don't know how to use it
<jelmer> morsik: where did you get stuck?
<morsik> jelmer: well, i created user, i write command="" into .ssh/authorized_keys on sirmacik and otheruser
<morsik> i created bzr_access.conf
<morsik> but hmm... i didn't create ssh keys
<jelmer> morsik: bzr_access works by being installed in the account of just one user
<jelmer> morsik: it lets all the users ssh into the same user account and then looks at the ssh key that was used to login to identify the user
<morsik> mhm...
#bzr 2011-05-03
<poolie> hi all
<jelmer> hi poolie
<poolie> hi there jelmer, how are you?
<jelmer> thanks, had a good weekend, and today I finally got the impression I'm getting to the last of these vf-specific tests that need to be moved
<poolie> great
<jelmer> With the new extensions in subunit I'm going to set up a ratchet (?) to get the number down further and see the progress
<jelmer> poolie: and how are you? are you on the road yet?
<poolie> in a few hours
<poolie> pretty good, just doing all the little chores before travelling
<spiv> Hi all.
<spiv> Nothing like a mysteriously locked up X to start the morning!
<lifeless> \i/
<lifeless> jelmer: why does the subunit recipe not use the subunit debian packaging branch ?
<jelmer> lifeless: that's how jml set it up hystorically, I don't think he has access to the debian branch
<lifeless> ok, changing it
<jelmer> *historically
<lifeless> jelmer: https://code.launchpad.net/~testing-cabal/+archive/archive/+buildjob/2517596/+files/buildlog.txt.gz is what got me looking at this
<lifeless> note the massive conflicts
<lifeless> we should perhaps use nest-part in fact
<jelmer> lifeless: Did you see I pushed an updated branch earlier tonight?
<lifeless> yes, and it had commits on it
<lifeless> which suggests its wrong :)
<jelmer> what's wrong about a branch with commits, isn't that the whole point ? :-P
<lifeless> not for recipes
<lifeless> the point of recipes is to use the packaging data as much as possible
<lifeless> and fix things upstream
<jelmer> I merged upstream, I didn't make any additional changes to the upstream code
<lifeless> jelmer: right, but you needed to merge upstream because the packaging data has previously had changes leading to these conflicts
<lifeless> no?
<jelmer> lifeless: right
<jelmer> I'm not sure why we have those extra changes in the packaging branch
<lifeless> well, we don't in my packaging branch
<jelmer> lifeless: you mean the one on alioth?
<lifeless> jelmer: there is none on alioth
<jelmer> bzr info apt:subunit
<lifeless> lp:~lifeless/debian/sid/subunit/sid
<lifeless> hymm, there is
<lifeless> but thats stale
<lifeless> jelmer: so looking at that
<lifeless> I'm unhappy with 0.0.6-2
<lifeless> jelmer: I have not had a single good experience with source format 3
<lifeless> jelmer: why did you change it ?
<lifeless> jelmer: I mean, I'm glad you're doing stuff there but that particular change is disruptive (as is the dh_python2 change)
<lifeless> jelmer: it must be very late for you
<lifeless> jelmer: so I'm happy to talk about this your morning
<lifeless> jelmer: (and I only now remember you actually stepped up and became maintainer, looking at log of debian/control)
<lifeless> jelmer: I've put lp:~testing-cabal/debian/sid/subunit/daily-builds up as a stable url so we don't go making new branches every release (because one branch builds for all releases we need to figure out how to do compatibility in one place anyhow)
<lifeless> jelmer: I really have to run to the chemist, sorry if any of the above is weird/nonsequitor/annoying
<poolie> hi spiv
<spiv> Hi poolie
<jam> morning all
<jam> spiv: if you're still around, any luck with the concurrent repacking issue?
<spiv> jam: https://bugs.launchpad.net/bzr/+bug/772935 temporarily queue-jumped
<ubot5> Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed]
<jam> sure
<spiv> Basically with the concurrent packing one I want to refactor the heck out of pack_repo.py to make the logic much more testable
<spiv> (without having to resort to e.g. trying to run two threads with precise timing)
<spiv> jam: btw, I've created lp:bzr-repodebug, which collects some of the ad hoc scripts/plugins I've made or seen in the past
<spiv> jam: because it's too hard to find them in random people's +junk months later, but not quite worth making projects for each of them
<spiv> It's currently got check-chk, chk-used-by, fetch-all-records, fix-missing-keys-for-stacking, mirror-revs-into, repo-has-keys and repo-keys commands
<bialix> hi guys
<bialix> C:\work\Bazaar\plugins\format1\__init__.py:13: DeprecationWarning: __builtin__.type.set_default_format was deprecated in version 2.4.0.
<bialix> workingtree.WorkingTreeFormat.set_default_format(workingtree.WorkingTreeFormat5())
<bialix> what's wrong?
<bialix> and why it complains about __builtin__?
<bialix> that's with bzr.exe 2.4.b1
<spiv> That message does seem a bit wrong
<bialix> spiv: the line from my plugin is: workingtree.WorkingTreeFormat.set_default_format(workingtree.WorkingTreeFormat5())
<bialix> so I should use set_default for 2.4, right?
<spiv> bialix: I think so
<spiv> bialix: probably that deprecation needs to use @deprecated_function instead of @deprecated_method, or deprecated_method needs fixing to handle classmethods better, or something.
<spiv> Or maybe move @classmethod after the @deprecated_method line?  Anyway, that message is clearly a bug.
<bialix> spiv: should I file a bug report?
<bialix> guys, why does bzr 2.4b1 print too much info about plugins on traceback?
<bialix> is there any knob I can modify to get the old behavior?
<bialix> Bug 776272
<ubot5> Launchpad bug 776272 in Bazaar "bzr 2.4b1: on traceback bzr prints too much info about plugins" [Critical,Confirmed] https://launchpad.net/bugs/776272
<maxb> bialix: Try 2.4b2?
<bialix> no windows installer available yet :-(
<lifeless> jelmer: hi
<jelmer> lifeless: hi
<lifeless> jelmer: sorry I went skewiff your last night
<jelmer> lifeless: sorry for not responding yesterday
<lifeless> jelmer: no worries, it was v. late for you
<lifeless> jelmer: so, I'm glad you are maintaining subunit
<lifeless> jelmer: I'm worried that in the -2 change we can't build it for CAT in the canonical datacentre anymore
<lifeless> because: source format 3, and dh_python2
<lifeless> I don't know what to do about those. For all the packages I'm still maintainer of I'm basically using source format 1 by choice and the oldest-supported python buildchain.
<lifeless> jelmer: do you have an ideas about how to deal with that?
<jelmer> lifeless: I think those changes make sense if we're considering just Debian (e.g. bugs have been filed about upgrading to dh_python2)
<jelmer> lifeless: I can symphatize with whoever is doing the backporting though, happy to go back for the moment if that helps elsewhere
<lifeless> jelmer: mmmm, perhaps, if we don't care about debian backports
<lifeless> jelmer: the CAT archive can't build source package 3, so at least for me using source format 1 is better (and it works fine with bzr maintenance too)
<lifeless> jelmer: I'm not sure what the dh_python2 backports story is; I've assumed its 'backport debhelper and hope', but I may be wrong
<jelmer> lifeless: dh_python2/source 3 should work fine in squeeze too IIUC
<jelmer> either way, I don't particularly mind going back for the moment
<lifeless> jelmer: squeeze has 2.6.6-3, but -6 was the dh_python landing AFAICT
<lifeless> jelmer: please, I think that would be good
<lifeless> jelmer: the source format is the key thing
<lifeless> jelmer: the CAT dak archive doesn't handle format three at all. Full stop.
<jelmer> lifeless: 2.6.6-3~ is the minimum version according to the wiki
<lifeless> jelmer: ah, interesting;
<lifeless> jelmer: talk to lamont if you want to know the limitations of CAT more
<jelmer> lifeless: I've been there... :)
<jelmer> I backported a newer bzr-builder to it a while back
<lifeless> fun :)
<lamont> it's lucid+security+updates, and then we try to minimize what else we drag in. packages not in lucid are much easier to bring in, after that it's a question of "who else may break if we pick this up?"
<maxb> Unless the package does something interesting, backporting a dh7 dh_python2 package is probably just a matter of swapping --with python2 for --with python-support
<maxb> (and reducing builddeps)
<maxb> dh_python2 doesn't live in debhelper, it lives in the python-defaults source package (a bit perversely)
<jdobrien> why would launchpad display the message: The name 'u1rest' has been blocked by the Launchpad administrators.
<jdobrien> it seems to meet the criteria on the project page
<jelmer> jdobrien: might be that the u1 prefix is blocked?
<jelmer> jdobrien: #launchpad is probably a better place for this question
<jdobrien> jelmer, oh sorry
<jelmer> no problem, it's just that you're more likely to get a useful answer there :)
<jelmer> or I can speculate wildly, if you prefer
<jelmer> jam: hi
<jelmer> jam: Do you know in what situation I could see _LazyGroupCompressFactory._manager being set to None?
<vanguard> is there some way to always use --strict for commit and push?
<jelmer> I'm getting a confusing error in get_bytes_as()
<jelmer> vanguard: I just have an alias that aliases "commit" to "commit --strict"
<jelmer> I think there's also an option that can do it for you, but I forget what it is :)
<vanguard> jelmer: alias in bashrc?
<jelmer> vanguard: in ~/.bazaar/bazaar.conf - see "bzr alias"
<vanguard> jelmer: thanks!
<Dr_Al> I've got a few (fairly elementary) questions about writing some new test code.
<Dr_Al> This is related to the bug in setting the parent location with switch -b
<Dr_Al> Bug 513709
<ubot5> Launchpad bug 513709 in Bazaar ""switch -b" sets incorrect parent for heavyweight checkout" [Low,Confirmed] https://launchpad.net/bugs/513709
<Dr_Al> I'm starting to write a test harness to demonstrate this behaviour, but my experience with bzrlib is a bit limited.
<Dr_Al> According to the Bazaar Testing Guide: "Use the bzrlib library when setting up tests and when evaluating the side-effects of the command. ".  Therefore, I'm trying to use bzrlib to create a treeless repository with a trunk (or whatever) branch inside it (to match the example in the bug report)
<Dr_Al> At the moment, I'm writing the test code in test_switch.py (in the blackbox directory) and I've started by using self.make_repository('repo_lw', shared=True), but I can't see how to specify the tree-less behaviour.
<Dr_Al> Also, what's a good way to get used to using bzrlib (e.g. finding out how to create a branch in the new repository and how to check a branch out to a working folder elsewhere?
<Dr_Al> It's taking me quite a while to get my head round the different types that are rreturned by the various bzrlib functions.
<jelmer> hi Dr_al
<jelmer> Dr_Al: tree-less behaviour would be done with repo.set_make_working_trees()
<jelmer> Dr_Al: To test that bug you probably need to add an extra blackbox test for "bzr switch -b" - the other ones are in bzrlib/tests/blackbox/test_switch.py
<jelmer> The other tests should hopefully give you a bit of inspiration
<Dr_Al> jelmer: Thanks: set_make_working_trees looks good.
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<Dr_Al> jelmer: I'm already working in test_switch.py as I said.  I've managed to create the repository, but every time I want to do something extra, I seem to be spending an inordinate amount of time searching classes, parent-classes, grand-parent classes etc for a function that might do what I want.  In test_switch.py, most of the functions seem to use make_branch_and_tree, which isn't quite what I want
<jelmer> Dr_Al: I guess it always takes a bit of getting used to
<Dr_Al> I could (assuming I could extract the path of the repo from the CHKInventoryRepository object that make_repository returns) just use run_bzr to do all the bits and pieces that I want to do, but that seems to be against the spirit of the Testing Guide quote that I posted.
<jelmer> Dr_Al: Using run_bzr is fine in the blackbox tests
<jelmer> Dr_Al: that bit of the testing guide applies to the non-blackbox stuff
<Dr_Al> jelmer: Really?? It's item 3 on the list of points under the section title "Blackbox (UI) tests"!
<Dr_Al> Most of the other tests in test_switch seem to do all the preparation with bzrlib and then use run_bzr for the one command that they're testing
<jelmer> hmm, ok.. that's not my experience in other blackbox commands. perhaps I'm not aware of the best practices in this regard..
<Dr_Al> Fair enough!
<jelmer> jam, vila; ^
<vila> jelmer: you're right
<vila> Dr_Al: ley me check the guide 8-)
<Dr_Al> Regardless of best practice, is there a good way of interrogating bzrlib?  It seems daft that I'm having to go through classes, parent classes etc ad nauseum to determine the way to do some fairly basic stuff like creating a branch in the repository.
<Dr_Al> I'm sure I'm missing some really obvious bit of documentation...
<Dr_Al> vila: Thanks!
<jelmer> Dr_Al: I usually look for other examples in the code that do similar things as I need to - if you need to create a bound branch you can grep for tests that use bound branches (they'll have something like that in their name)
<jelmer> Dr_Al: Why do you need to create a shared repository, is that relevant for that bug?
<vila> Dr_Al: right, it may be a bit ambiguous in the guide, but the general rule is that for blackbox tests you mainly rely on run_bzr
<vanguard> how can I populate a tree via FTP?
<vila> Dr_Al: UI tests are a bit of a special case as *sometimes* it's easier to tweak directly with bzrlib
<vanguard> I want to upload my website with a simple `bzr push`
<Dr_Al> jelmer: The short answer is: I'm not sure.  I'm basing the test case on the way that we (the company at which I work) use Bazaar.  This is with a shared treeless repository on a network drive with feature branches inside it.  We then use heavyweight checkouts and 'switch -b' / 'switch' to pick branches.
<vila> vanguard: try 'bzr upload' instead from the bzr-upload plugin
<Dr_Al> vila: Okay, fair enough... I'll do it with run_bzr.  It certainly makes my life easier!
<vila> Dr_Al: once you submit your proposal, the reviewer may gives you better ideas and hints (if needed), but don't make your life harder *before* that ;)
<Dr_Al> For verifying whether the test has passed (i.e. whether the parent is set correctly), is it better to parse 'bzr info' or to use bzrlib to (somehow) open the branch and interrogate the parent location.  My instinct says the latter, but then that may end up being quite complicated!
<Dr_Al> vila: Can't argue with that!
<vila> branch.get_parent_location() (from memory)
<vila> bah, one of those ...
<vila> branch.get_parent()
<Dr_Al> jelmer: (continuing earlier comment: sorry, got distracted)... therefore, I thought it was more appropriate to make the test case match the behaviour we were looking for...
<Dr_Al> vila: thank yoU!
<Dr_Al> vila: Now I just need to open the branch (created with run_bzr), but don't worry, I'll do some digging...
<vila> that should be something along bzrlib.branch.Branch.open_containing(path)[0]
<vanguard> vila: that is super handy, thx!
<vila> Dr_Al: bzrlib.builtins is the source of all good bits when you're searching for high level usages of bzrlib internals
<Dr_Al> vila: Great, thanks
<Dr_Al> I'm (fairly obviously) nowhere near ready to propose this for merging (having only written the test harness), but is there any chance someone could have a look at my test harness code (http://bazaar.launchpad.net/~abudden/bzr/switch_parent_513709/revision/5817) and check that I'm writing code in an acceptable style and that the code looks reasonable at first glance?
<vila> Dr_Al: rough review:
<vila> instead of a _test_xxx method, split it into an assert<Result>(relevant params) and probably a test script (see bzrlib.tests.test_script.py)
<vila> never use os.chdir, run_bzr accept a work_dir parameter
<Dr_Al> vila: Thanks... I'll have a look at that.
<vila> the split stuff seems... a bit complex, can't you achieve that with a *single* split ?
<vila> ha, a single class there...
<Dr_Al> I'd like to, but I couldn't see an easy way.  split only produces two entries rather than a list (as I was expecting).
<vila> Dr_Al: you may create a dedicated class for your tests so that they could share a setUp method that will create the needed stuff up to... the run_bzr('checkout'...
<vila> Dr_Al: so that you create two test_ methods in this new class, one for heavy and the other for light
<Dr_Al> I considered parent.split(os.path.sep) or parent.split('/'), but I wasn't sure which would be correct for Windows
<vila> Dr_Al: bzrlib.osutils is your friend there
<Dr_Al> That was my original plan actually (dedicated class), but it seemed more natural to use test_switch.  I'll look at refactoring it into its own class tomorrow.
<Dr_Al> Aha... hadn't seen bzrlib.osutils.
<Dr_Al> Thanks vila. I've got to go now, but I may be back asking more (hopefully gradually less stupid) questions tomorrow.
<vila> Dr_Al: in the end you should end up with two *short* tests that will outline your intent and be trivial to grasp
<vila> there is no stupid questions...
<vila> Dr_Al: oh I see, you copy _test_switch_explicit_nick.... shudder
<chriscauser__> Hi Everyone. I'm just throwing it out there to see what people think. I've written a small script which I'm using to show bzr branch information at the bash prompt. The code is at http://bazaar.launchpad.net/~chy-causer/bzr/bzr-term-info/view/head:/__main__.py . I know that bzr shell offers similar stuff but I wanted to know if anything similar exists and if not, if there was any need for it
<chriscauser__> Eagle eyed people may notice that this script was originally hosted by Github, and for that I apologize :$
<vanguard> chriscauser__: looks nice, I build something like that using bash, not that elegant ...
<chriscauser__> vanguard: My initial version was in bash! It was a little too slow if I wanted to check to see if the working tree was dirty though which is why I dropped down to Python
<vanguard> chriscauser__: I just checked whether there is a .bzr directory. And then I just checked whether `bzr status` had any output
<chriscauser__> Yeah, that's what I started with but doing it in python gave me a (off the top of my head) ~35-40% speed boost
<vanguard> chriscauser__: checking for the dir is prtty easy, but the status slow it down really bad, especially on a cold start
<chriscauser__> vanguard: Yeah :(
<vanguard> chriscauser__: the only cool thing is that I could easily adapt the script to git, hg, svn â¦ it does all the checks and tells me which SCM is used in this folder :)
<chriscauser__> vanguard: Ah! Well, my bash prompt contains $(get_bzr_info)$(get_hg_info)$(get_git_info) so it works for all three of them. The only thing is that if a directory is versioned using two version control systems, it's shown twice, but that's a really fringe problem :)
<vanguard> chriscauser__: using two SCM is a fringe itself I'd say.
<vanguard> chriscauser__: my script would just show the first one that applied, I guess bzr if it was bzr+git
<chriscauser__> vanguard: Oh well :) Glad you like it and hope it may be of some use to you in the future. I'll be working on showing conflicts next
<vila> chriscauser__: You want wt.has_changes()
<vila> yeah, talking to yourself again...
<vila> jelmer: loom broken... never mind, you already landed a fix ;) Gee, almost 3 weeks ago even :-D
<jelmer>  :)
<achiang> what is the easiest way to get a diff of all the files in a directory compared to an earlier revision? unified diff is fine, but maybe a gui tool would be useful too
<vila> achiang: bzr diff -r<revno>
<achiang> oh, that's it?
<vila> yeah
<vila> it's even 'bzr diff' only to look at your uncommitted changes
<achiang> pretty easy. :)
<vila> see 'bzr diff --help' for more
<achiang> well, i'm doing code archaeology, so i don't have uncommited changes per se
<achiang> vila: what is the name of the gui bzr diff tool?
<vila> good, archeology is all about not breaking anything ;)
<vila> bzr qlog from the qbzr plugin ?
<achiang> hm, ok. i think i have that, thanks
<vila> bah, bzr qdiff I meant
<vila> bzr qdiff --help for details
<achiang> vila: thanks
<binary_crayon> Hello, I would like to install Bazaar Explorer from source. How may I install QBzr as dependency? I am using Mac OS X. Thanks
<ckontros> I pulled a branch, made 1 change and tried to push. Got this: http://paste.ubuntu.com/603012 I'm using bzr from the Natty repo.
<ckontros> Not I looked up  "rich-root support" and then tried a "bzr upgrade --rich-root-pack ." Said branch was v.7 and I couldnt go to v.6. SO Im stuck.
<ckontros> So Im stuck. ANy ideas?
<glyph> ckontros: "the natty repo"?  Do you mean "in natty" or "from https://launchpad.net/~bzr/+archive/ppa, and I'm using natty"
<ckontros> glyph: BZR from official natty repos.
<ckontros> Not PPA.
<lifeless> ckontros: 'bzr info -v' and paste the repository  line please
<glyph> ckontros: OK.
<ckontros> lifeless: http://paste.ubuntu.com/603021
<lifeless> ckontros: you're already using rick roots
<lifeless> ckontros: note that the rick root pack format is much slower than the 2a format
<lifeless> ckontros: ok, the *remote* branch is the one that is using an old format
<lifeless> lp:~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio is what needs upgrading
<ckontros> lifeless: Gotcha.
<lifeless> ckontros: don't pass '--rich-root-pack'
<lifeless> ckontros: you may have a number of related branches to upgrade; the launchpad UI has an 'upgrade this branch' button
<lifeless> ckontros: if you do upgrade them all yoiu should also upgrade your local branch
 * ckontros looks
<lifeless> just run 'bzr upgrade' in it
<ckontros> After I pull it clean? (and local?)
<lifeless> sure
<lifeless> each branch of this project needs to be upgraded separately
<ckontros> See, I hit this before and actually tried that 1st thing.
<ckontros> See, something's odd. Im a member of ubuntustudio-dev and it says I cant upload to this branch on the page.  https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ubuntustudio-default-settings/oneiric
<ckontros> james-w looks to have done something last.
<lifeless> that branch is owned by ~ubuntu-branches - its the official packaging branch for that packagin - you need package upload rights to push to that branch
#bzr 2011-05-04
<AfC> Good morning
<ckontros> james-w: Could you look into this for us. It's gonna make it damn hard for the  Studio team to hit the ground running for Oneiric. :) I'm unsure why this was done in the first place. I might not be around when you are so I'll have ScottL (current Studio lead) catch up with you.
<ckontros> Darn. Did the name wrong. james_w` ^^^
<ckontros> lifeless: Thanx to the help. I'll get it sorted.
<jam2> morning all
<lifeless> jelmer: :( I didn't fix the build after all
<lifeless> jelmer: (subunit dailies)
<vila> hi all !
<vila> jam, jelmer, spiv: stand up ?
<jam> vila: in 1 hour
<jam> I would guess jelmer isn't awake yet, but I could be wrong
<vila> 8:00 UTC ?
<vila> spiv: is that ok for you ?
<jam> vila: that is what the schedule says
 * vila nods
<jam> I'm usually not on until 7:00, but I'm here now
<vila> doesn't mean we can't adjust ;)
<jam> So today I'm fine moving it
<spiv> vila, jam: if jelmer's around, now suits me
 * vila acks
<jam> same here, but I think jelmer is still sleeping
<spiv> Otherwise I'll head afk for a bit and be back for the standup
<jam> is poolie gone today, then?
<vila> yup
<Peng> vila: pm?
<vila> Peng: sure
<Kaleetos> I'm having some trouble installing bazaar on my computer, anyone available to help me out?
<vila> Kaleetos: OS/bzr versions ?
<Kaleetos> i'm on mac os 10.5-- bazaar 2.3.1. It installs but when I try to run the bzr it tries to execute from a version of python I don't have anymore (2.5)
<spiv> vila, jam: see you in 40 minutes or so.
<vila> spiv: ack
<Kaleetos> is there a way for me to have bazaar execute from 2.6
<vila> Kaleetos: you deleted the OSX provided python ?
<Kaleetos> as per the instructions on python.org, yes
<vila> Kaleetos: hmm, interesting, do you an URL for that ?
<vila> s/you/you have/
<Kaleetos> this was a long while ago when i was having problems with programs defaulting to the 2.5
<Kaleetos> http://docs.python.org/using/mac.html
<Kaleetos> section 4.1
<Kaleetos> the second bullet point
<vila> Kaleetos: yup, reading
<vila> so, I wasn't aware of that but it's interesting, see bug #776523 for a related issue (a bit reversed to yours but your experience may help decide on how to fix it)
<ubot5> Launchpad bug 776523 in Bazaar Mac Installers "launchpadlib tests requires python 2.6" [Critical,Confirmed] https://launchpad.net/bugs/776523
<vila> Kaleetos: now, what is the precise issue you're having ?
<vila> i.e. what does 'bzr version' says ?
<Kaleetos> vila-- if its necessary I can put that version of python right back where it was (i stored backups), it just causes headaches when running certain programs
<Kaleetos> whenever i run bzr anything it says this: -bash: /usr/local/bin/bzr: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/: bad interpreter: No such file or directory
<vila> ok, and what does the first line in /usr/local/bin/bzr says ?
<Kaleetos> -bash: usr/local/bin/bzr: No such file or directory
<vila> Kaleetos: the first line *in* the script
<Kaleetos> i'm sorry-- i have no idea what that means =(
<Kaleetos> what script?
<vila> Kaleetos: 'head /usr/local/bin/bzr' will display the first few lines in the script
<Kaleetos> # Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010 Canonical Ltd
<Kaleetos> that?
<vila> just a sec, searching for a 10.5 mac
<vila> no, not that, a line starting with #!
<Kaleetos> #!/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
<vila> yup, that one
<vila> this instructs OSX to use the python located at that path
<Kaleetos> ahh. so just change that path and thats it?
<vila> that would be a first try but there could be fallouts
<Kaleetos> well before i do that
<Kaleetos> I'm going to put that backup of 2.5 back in place to see what happens
<Kaleetos> would it matter much if I was running bazaar on the older version of python?
<vila> if you put your backup back in place, everything should be fine
<vila> Kaleetos: quite the contrary, the installer is build against the system provided version
<vila> built
<Kaleetos> oh ok
<vila> Kaleetos: out of curiosity, do you plan to upgrade your mac to 10.6 or 10.7 ?
<Kaleetos> when money permits
<Kaleetos> i would love to now, but I don't have the money and I'd rather not deal with upgrading this old guy
<Kaleetos> I want to get a new mac
<vila> which model is it ?
<Kaleetos> macbook pro
<Kaleetos> ok so now I'm getting this message
<Kaleetos> should I paste it right in here or do you guys have a pasting page?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Kaleetos> http://paste.ubuntu.com/603135/
<vila> Kaleetos: the installer should have installed bzrlib in /Library/Python/2.5/site-packages/bzrlib
<Kaleetos> hm... i'll reinstall
<vila> Kaleetos: either it's not there anymore or some other setting (PYTHONPATH ?) is borked
<vila> re-installing is the safest route
<Kaleetos> nope, same deal
<vila> do you have /Library/Python/2.5/site-packages/bzrlib ?
<Kaleetos> hmm no. and according to my backups I haven't had a Library/Python since October(before I started using python)
<Kaleetos> I don't even see a library/python directory now
<vila> weird
<vila> are you sure you'looking at /Library not /Users/xxx/Library ?
<Kaleetos> maybe the backups don't save that particular directory?
<Kaleetos> !
<Kaleetos> sorry,
<Kaleetos> yup all there
<Kaleetos> including the bzrlib
<vila> ha, better
<Kaleetos> should I manually add that directory into the PYTHONPATH?
<vila> you shouldn't have to
<vila> try: python -v /usr/local/bin/bzr
<Kaleetos> same error
<vila> pastebin output ?
<Kaleetos> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Kaleetos> http://paste.ubuntu.com/603140/
<vila> you're using 2.6
<Kaleetos> yes
<Kaleetos> is it seraching in 2.6 now?
<Kaleetos> lol
<vila> but /usr/local/bin/bzr points to 2.5 so using this script should do the right thing, try python2.5 -v /usr/...
<Kaleetos> python2.5 -v /usr/...
<Kaleetos> oops hold on
<Kaleetos> http://paste.ubuntu.com/603141/
<vila> use the full path to the bzr script, I was lazy ;)
<Kaleetos> OH
<Kaleetos> hahaha
<vila> :)
<Kaleetos> this directory right? /usr/local/bin/bzr/
<vila> this file  /usr/local/bin/bzr
<vila> no trailing /
<Kaleetos> yea just figrued that out heh. ok so it did a bunch of stuff, should i paste that?
 * jelmer waves
<vila> if it doesn't end with the list of basic bzr commands, yes, paste the output
<Kaleetos> http://paste.ubuntu.com/603143/
 * vila scratches head
<vila> Kaleetos: python2.5 -c 'import sys; print sys.path'
<Kaleetos> http://paste.ubuntu.com/603144/
<vila> Kaleetos: otp, be back later
<Kaleetos> ok
<jelmer> vila: can you hear me?
<vila> jelmer: yes, but you don't seem to hear me ;)
<Kaleetos> vila when you get back here is a copy of my bash_profile: http://paste.ubuntu.com/603145/
<Kaleetos> incase maybe something is wrong in there
<spiv> vila: http://package-import.ubuntu.com/status/67061a280d79e806c089681dd8b4a524.html
<jelmer> jam, vila: did somebody say they were going to review spiv's branch?
<jam> jelmer: the one he just put up? I already reviewed it
<jam> was there another one?
<jelmer> jam: Yeah, the parents provider smart request one.
<jam> I looked at it
<chriscauser> vila: Many thanks for the tip (about wt.has_changes().) It seems to shave about .1 second off the script running time (.5 seconds to .4). Unfortunately, it doesn't seem to check for unknowns. Is there a similar method to check if the tree has unknowns? (I can't seem to find one.)
<jelmer> jam: I haven't seen your reply yet, I guess Launchpad is still in read only mode
<vila> chriscauser: glad you see my message, you were gone when I posted it
<vila> chriscauser: as for unknowns, let me check
<chriscauser> vila: Yeah, I went back and checked just now in case I'd missed anything
<Kaleetos> question. If I write a python script containing this : print os.environ['PYTHONPATH'].split(os.pathsep)  ---(after importing os)--- and run it through terminal, shouldn't I get back the PYTHONPATH?
<vila> chriscauser: if wt.unknowns() should do
<vila> Kaleetos: yes, but better use sys.path which will already include PYTHONPATH
<chriscauser> vila: Thanks. That was what I was originally using. The only problem with that is that it doesn't shortcircuit (i.e. It finds all unknowns, even though it returns an iterator)
<Kaleetos> hm.. when I do exactly that, i'm getting a key error
<vila> Kaleetos: exactly what ? The snippet above ?
<Kaleetos> i created a script called test.py containing what I wrote above
<Kaleetos> then i run it through terminal and i get a key error
<Kaleetos> if i run it through textmate's built in terminal i get a PYTHONPATH referring to the textmate installation
<Kaleetos> but directly through terminal gives the key error
<chriscauser> Kaleetos: What happens when you type in 'export PYTHONPATH="/imaginary:/second_imaginary"'' before running from the terminal?
<vila> echo $PYTHONPATH ?
<vila> python -c 'import os; print "\n".join(os.environ["PYTHONPATH"].split(os.pathsep))' works fine here
<vila> or python2.5 -c 'import os; print "\n".join(os.environ["PYTHONPATH"].split(os.pathsep))' works fine here
<vila> in your case
<Kaleetos> the echo thing just shoots back a question mark
<Kaleetos> chris, should I copy and paste that exactly?
<chriscauser> Kaleetos: Everything in the double quotes exactly
<vila> Kaleetos: python2.5 -c 'import sys; print "\n".join(sys.path)'
<Kaleetos> and vila
<Kaleetos> i get the same key error
<Kaleetos> the last thing u gave me worked
<chriscauser> Kaleetos: * single quotes
<vila> Kaleetos: then PYTHONPATH is not in your environment, 'env' will tell you what is defined
<Kaleetos> chris, I get the same keyerror
<vila> Kaleetos: because PYTHONPATH is not in your env, try the 'env' command in a terminal without the single quotes
<Kaleetos> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Kaleetos> http://paste.ubuntu.com/603163/
<vila> Kaleetos: right, no PYTHONPATH there
<Kaleetos> is that the problem?
<vila> python2.5 -c 'import sys; print "\n".join(sys.path)'
<vila> Kaleetos: you shouldn't have to modify PYTHONPATH, /Libray/blah blah should already be added automatically by python, if it's not, something weird is going on
<Kaleetos> perhaps i broke something at some point?
<Kaleetos> http://paste.ubuntu.com/603165/
<vila> ls -l /Library/Python/2.5/site-packages
<Kaleetos> http://paste.ubuntu.com/603167/
<vila> can you re-paste the output of: python2.5 -c 'import sys; print "\n".join(sys.path)'
<vila> meh, nm
<vila> Kaleetos: the weird thing here is that you have site-packages directories below /System instead of /Library
<Kaleetos> what would happen if i tried installing the osx10.6 bazaar in my 10.5 (because 10.6 bazaar installs to python 2.6). would that create all sorts of disaster?
<chriscauser> vila: I've pushed your suggestion to lp. Thank you so much for the help. I hope the script will be of use to other people.
<vila> Kaleetos: that's would be a useful experiment, it may well work
<Kaleetos> or what about installing the version intended for osx 10.4 (designed specifically for python 2.6 downloaded directly from python.org)
<vila> Kaleetos: try un-installing the 10.5 version first if only to limit the clutter
<Kaleetos> ok
<vila> Kaleetos: there two things here, python install and bzr install
<vila> Kaleetos: AFAIK, the bzr installers assume that you're using the system installed python but I don't think they check
<Kaleetos> the OS is not relevant?
<vila> well, the OS is indirectly relevant
<vila> AFAIK it's python version that matters
<Kaleetos> ok, i'll try to install the one for 10.6
<Kaleetos> the uninstaller doesn't work for me =/
<Kaleetos> any other options?
<vila> Kaleetos: :-/
<Kaleetos> ...
<Kaleetos> ok so 10.6's installed
<Kaleetos> and same thing
<vila> for which value of same ? ;D
<Kaleetos>  same != good
<vila> right, that leave many possible causes opened :)
<Kaleetos> i've been trying to get this to work for so long
<vila> I'm starting to suspect that the OSX python and the python.org python may have different ideas about how sys.path is built...
<vila> Kaleetos: *what* is failing with the 10.6 one ?
<vila> Kaleetos: keep in mind that we have many users on both 10.5 and 10.6 with working setups so I'm trying to help you find what is different in *your* setup and how the installers can be fixed...
<Kaleetos> i get the same "please check the directory containing bzrlib is in your PYTHONPATH"
<vila> then paste the sys.path output for 2.6
<lifeless> jelmer: hi
<lifeless> jelmer: what do you think is the right way to fix the subunit recipe
<Kaleetos> i understand, i'm just worried maybe i broke something when i first installed python 2.6
<Kaleetos> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Kaleetos> http://paste.ubuntu.com/603180/
<Kaleetos> http://paste.ubuntu.com/603182/
<Kaleetos> sorry, second one is easier to read
<vila> ls -l /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
<vila> and
<vila> ls -l /Library/Python/2.6/site-packages
<Kaleetos> http://paste.ubuntu.com/603184/
<vila> Kaleetos: ls -l /Library/Python/2.6/site-packages
<Kaleetos> http://paste.ubuntu.com/603185/
<vila> here we are :)
<vila> ok, so indeed, sys.path is built differently
<vila> which explain both failures
<vila> so, PYTHONPATH is indeed the way to fix that
<Kaleetos> i hope you know how to do that too, because I sure don't :)
<vila> so, let's start with what is installed currently:
<vila> head /usr/local/bin/bzr
<Kaleetos> #!/usr/bin/python
<vila> arf :)
<vila> python -V
<vila> err
<vila> /usr/bin/python -V
<Kaleetos> Python 2.6.6
<vila> so
<Kaleetos> to the second
<Kaleetos> Python 2.5.1
<vila> ha
<vila> err, that's weird but let's see if we can deal with that:
<vila> PYTHONPATH=/Library/Python/2.5/site-packages bzr version
<Kaleetos> it paused for a second and then printed out some text from bazaar
<vila> rhaaaa no
<vila> err, yes
<vila> good that text should mention bzrlib: a_path_here
<vila> a_path_here should be /Library/Python/2.5/site-packages/bzrlib
<Kaleetos> http://paste.ubuntu.com/603186/
<vila> Kaleetos: pfew, here we are
<vila> so, the "funny" thing is that you're using the bzr script installed for 10.6 but still using the bzrlib installed for 10.5
<vila> since the script is the same except for the #! line, it doesn't really matter
<Kaleetos> well that would have only occurred just now when I installed the 10.6 version right?
<vila> yes
<vila> now you need to set the proper PYTHONPATH which is tricky since you still want to use 2.6 for other reasons, so let's try something else:
<vila> first, change the first line in the bzr script by adding '2.6': /usr/bin/python2.6 then try
<vila> PYTHONPATH=/Library/Python/2.6/site-packages bzr version
<Kaleetos> wait.. how do i change the bzr script?
<vila> with a text editor
<vila> which one do you use usually ?
<Kaleetos> textmate
<vila> ha, you may need admin access
<chriscauser> vila, Kaleetos: Sorry to butt in, but perhaps a bash alias could help here? (eg. "alias bzr='PYTHONPATH=/Library/Python/2.5/site-packages /usr/local/bin/bzr")
<vila> do you know how to launch textmate as an admin ?
<vila> chriscauser: worth a try
<Kaleetos> no i don't
<chriscauser> Sorry guys, I'm messing up my quotes here
<vila> alias bzr ='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr
<Kaleetos> should i paste that then?
<vila> alias bzr ='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr'
<vila> Kaleetos: startup a fresh terminal so we better control where the alias is defined
<Kaleetos> it says not found
<chriscauser> *"alias bzr='PYTHONPATH=/Library/Python/2.5/site-packages /usr/local/bin/bzr'"
<Kaleetos> double or single quotes
<vila> chriscauser: nope, we want the 2.6 version so specifying python2.6 ignores the #! line
<chriscauser> Everything in the double quotes
<chriscauser> vila: Sorry. I was just trying to correct my quoting rather than anything else
<vila> chriscauser: np :)
<chriscauser> Kaleetos: Do what vila says only remove the space between bzr and =
<vila> argh, good catch ;)
<Kaleetos> should it be 2.5 or 2.6?
<vila> alias bzr='PYTHONPATH=/Library/Python/2.6/site-packages python2.6 /usr/local/bin/bzr'
<Kaleetos> can i just say
<Kaleetos> that i love both you
<Kaleetos> ITS WORKING FINALLY
<Kaleetos> !!!!
<vila> almost
<Kaleetos> ...
<Kaleetos> joy kill
<Kaleetos> lol
<vila> now you need to record that alias to avoid typing it every time you want to use it
<Kaleetos> how do i do that?
<Kaleetos> by record are you talking some special command I don't know about, or just copy and paste it into a text file for future reference
<vila> ha, good question, I can never remember which file is right for that on OSX to cover all cases
<vila> Kaleetos: I mean adding it to a file that all shells will read so you don't have to type it again
<vila> it's one of .profile, .bashrc or .bash_profile
<vila> Kaleetos: to you have one of those in your home directory ?
<Kaleetos> i have the bash_profile
<Kaleetos> its open in the terminal for editing now
<vila> then just add that alias command there
<vila> save the file and start a new terminal
<Kaleetos> it worked
<vila> pfew
<vila> Kaleetos: *now* you can rejoice ;)
<Kaleetos> thank you so much for your patience, and thank you chris for that solution
<Kaleetos> i'm rejoicing by downloading what i've been trying to get for all these hours lol
<vila> Kaleetos: it would help if you could file a bug explaining your issue, setup and workaround
<vila> https://launchpad.net/bzr-mac-installers/+filebug
<Kaleetos> sure I'll do that. Although I'm not sure if it was a bug, my removing the built in insallation of macpython and then putting it back might have broken something. So maybe it was a one time issue
<vila> Kaleetos: the root issue is that the installers don't play well with pythons installed on top of the system one but there should be a way to address that without forcing the users to define an alias
<vila> Kaleetos: I'm afraid your setup is a bit unclean by now and sorting that out may be tricky
<vila> Kaleetos: keep an open eye about weird behaviors still, read your ~/.bzr.log if in doubt for further clues
<Kaleetos> ok
<Kaleetos> well one thing i wanted to ask actually
<Kaleetos> when i installed the 10.6 version, the action was set to "update"
<Kaleetos> I'm guessing that would have over written a significant amount if not all of the previous installation?
<vila> Kaleetos: hmm, if you still have /Library/Python/2.5/bzrlib (and I think you do), then file *another* bug for that
<Kaleetos> yup i do
<Kaleetos> so i should write a bug stating that the update did not remove the previous install
<vila> yup
<vila> if only because you asked here ;)
<Kaleetos> i have 3 different copies of bzr lib in here now 0.0
<vila> 3 ?
<vila> where ?
<Kaleetos> "/Library/Python/2.6/site-packages/bzrlib"
<Kaleetos> "/Library/Python/2.5/site-packages/bzrlib"
<vila> that's the two I was expecting :)
<vila> where is the third ?
<Kaleetos> oh no, one of them was being repeated in my file search for some reason
<Kaleetos> i just closed the finder window and tried again
<Kaleetos> its only 2
<vila> pfew
<vila> I prefer that ;)
<Kaleetos> should i leave the copies alone or can i delete one(whichever one not being used preferably lol)
<vila> another way to address the problem could to create a symlink in /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
<vila> to tell the python.org python about the bzrlib installed by the OSX 10.6 installer
<vila> the alias won't be needed then and this may be more robust than the alias
<vila> Kaleetos: you could probably delete the 2.5 one
<Kaleetos> hmm i just noticed
<Kaleetos> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<Kaleetos> i'm getting that warning when i load bzr
<vila> that's bad
<Kaleetos> anything I can do about that?
<vila> bzr version
<vila> again ?
<vila> the extensions are .so files in the bzrlib directory
<Kaleetos> http://paste.ubuntu.com/603203/
<vila> they enhance the performances but we provide python fallbacks so it's a problem only if you're dealing with big projects
<Kaleetos> I see the .so files, are they supposed to be associated with WINE?
<Kaleetos> they're all whine bottles
<vila> noo, they are regular .so OSX files
<Kaleetos> well whine has decided to take over the show for me
<Kaleetos> lol
<vila> Kaleetos: any more details in ~/.bzr.log (~ is a shorcut for /Users/Carlitos
<jelmer> lifeless: sorry, missed that earlier - looking at the recipe now
<Kaleetos> i get permission denied without sudo
<Kaleetos> and command not found with sudo
<jelmer> lifeless: the previous packaging branch probably patched debian/rules to always run the autotools chain
<spiv> jam: an idea that just occurred to me for "bzr branch --stacked"
<jam> ?
<spiv> jam: BzrDir.sprout, which would do the fetch, also knows if it needs to create a working tree
<vila> Kaleetos: it's a text file, open it with a text editor
<vila> Kaleetos: it's the bzr log file
<spiv> jam: in which case it may as well fetch the tree contents up front, because that data is going to be needed anyway
<spiv> jam: so it wouldn't make "bzr push" of a new stacked branch any larger, but would make "bzr branch --stacked $remote local" more efficient
<jam> interesting idea
<Kaleetos> i can't find that file vila
<Kaleetos> is it hidden in the folder?
<vila> Kaleetos: yes, it starts with a dot (.) so the finder doesn't show it by default
<Kaleetos> got it
<lifeless> jelmer: my packaging rules had
<lifeless>         [ -f configure ] || autoreconf -fi
<lifeless> jelmer: (in debian, not just recipes)
<Kaleetos> vila: you want a copy of the whole the
<jelmer> lifeless: in clean: ?
<Kaleetos> *the whole thing
<jelmer> lifeless: that's the only target that gets run by the recipe builder
<vila> Kaleetos: only the end should be relevant i.e. the last few commands
<Kaleetos> there's a snipit of the en
<Kaleetos> *end
<lifeless> jelmer: build:
<lifeless>         [ -f configure ] || autoreconf -fi
<lifeless>         INSTALLDIRS=vendor $(DH) build
<lifeless> clean:
<lifeless>         make distclean || true
<lifeless>         rm -f configure
<lifeless> jelmer: so clean will trigger the rules to build when the package itself is built
<Kaleetos> and bzr is not working for me :( I'm trying run a command to download some files, but I'm getting this: ERROR: Unable to import library "subvertpy": bzr-svn: Unable to load subvertpy extensions.....
<lifeless> jelmer: I suspect this is also lost in your changes
<jelmer> lifeless: there's no dependency on build in clean?
<lifeless> jelmer: no, why would there be?
<jelmer> lifeless: the recipe builder only runs the clean target, it doesn't run any of the other targets
<Kaleetos> vila: i guess the compiled stuff is indeed necessary
<lifeless> jelmer: right, I don't see the problem though
<vila> Kaleetos: if you're talking to a remote svn server, yes
<lifeless> jelmer: at least not with my packaging rules
<lifeless> I haven't looked at what you did in -2 yet
<Kaleetos> vila: would this problem have anything to do with whine being associated with all of those .so files?
<lifeless> ah, I know
<lifeless> I didn't delete setup.py again, I should have.
<lifeless> the debhelper stuff wrongly runs setup.py
<Kaleetos> vila: and if so, should i associate it with something else or just remove the association?
<vila> Kaleetos: I dunno what whine is, but no, associations shouldn't come into play there
<Kaleetos> whine is an x11 wrapper for windows programs on mac. basically lets me run .exe's directly on mac osx
<vila> wine you mean ?
<Kaleetos> hah yes, wine
<Kaleetos> sorry
<vila> no worries
<vila> Kaleetos: ls -lR /Library/Python/2.6/site-packages/bzrlib
<lifeless> jelmer: ok, fixed branch pushed
<lifeless> jelmer: on the collab-maint packaging
<Kaleetos> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<jelmer> lifeless: I don't see any changes?
<Kaleetos> http://paste.ubuntu.com/603211/
<lifeless> lp:~testing-cabal/debian/sid/subunit/daily-builds
<vila> Kaleetos: nope, you've added tests
<lifeless> jelmer: you've preserved this in your -2 patch anyway
<lifeless> just updated it, which is good.
<lifeless> need to add a nuke of setup.py there so that it doesn't need to be a delta in the branch
<vila> Kaleetos: err, or you lost the beginning
<Kaleetos> vila: you lost me?
<jelmer> lifeless: ah, found it
<jelmer> lifeless: thanks for fixing it
<lifeless> de nada, I broke your fix in my confusion
<vila> Kaleetos: your paste started in bzrlib/tests, it doesn't contain the part I want :-/
<Kaleetos> ah sorry
<Kaleetos> mm
<Kaleetos> i restarted the terminal to clear it out
<Kaleetos> now i'm getting that there is no such file or directory
<Kaleetos> when i run the command ending in daily-builds
<vila> Kaleetos: you copied the wrong line
<vila> ls -lR /Library/Python/2.6/site-packages/bzrlib >~/topaste
<vila> and then copy the content of the ~/topaste file
<vila> Kaleetos: lucky you nobody pasted sudo rm -fr / :D
<Kaleetos> LOL
<Kaleetos> i'm not THAT lost
<Kaleetos> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Kaleetos> http://paste.ubuntu.com/603215/
<Kaleetos> there you go
<vila> hmm, so the .so are right there :-/
<Kaleetos> yup
<vila> PYTHONPATH=/Library/Python/2.6/site-packages python2.6 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
<Kaleetos> http://paste.ubuntu.com/603219/
 * vila blinks
<vila> darn, probably means the 10.6 extensions can't be used on 10.5 :-(
<Kaleetos> mm
<Kaleetos> what if I
<vila> PYTHONPATH=/Library/Python/2.5/site-packages python2.5 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
<Kaleetos> change the alias to point to the 2.5 bzr
<vila> yup, if you haven't deleted it yet :-}
<Kaleetos> in the trash
<Kaleetos> i can restore it
<vila> pfew, almost
<Kaleetos> PYTHONPATH=/Library/Python/2.5/site-packages python2.6
<Kaleetos> should i change both to 2.5
<Kaleetos> or just that first one
<spiv> http://webnumbr.com/bzr-active-reviews is a bit alarming
<Kaleetos> since the bzr script head is still 2.6?
<vila> spiv: yup, time for me to patch pilot for good ;-}
<vila> Kaleetos: PYTHONPATH=/Library/Python/2.5/site-packages python2.5 -c 'import bzrlib._dirstate_helpers_pyx ; print bzrlib._dirstate_helpers_pyx.__file__'
<vila> both 2.5, we'll worry about the bzr script later
<Kaleetos> http://paste.ubuntu.com/603222/
<spiv> Hmm, I guess I should plot merged reviews too so we have something positive to enjoy :)
<vila> Kaleetos: geee, what the hell is wrong with your setup !!!
<Kaleetos> vila: Its fixed!
<vila> Kaleetos: what ? how ?
<Kaleetos> i just restarted terminal, reloaded bzr
<Kaleetos> and no error
<Kaleetos> and the download worked too!
 * vila blinks twice
<Kaleetos> using the 2.5 change in the alias of course
<vila> Kaleetos: may I recommend you some goats&chikens providers for your daily sacrifices ?
<vila> ooooh
<Kaleetos> yea, haha. that terminal session was still using bzr for 2.6
<Kaleetos> so when i restarted with the alias in place it switched
<vila> Kaleetos: pfew, so hopefully you're an happy sailor now
<Kaleetos> so I have one last question to harass you with
<Kaleetos> where did the file i downloaded go??
<Kaleetos> haha
<fullermd> I would suspect that a .so built for py2.5 would get all cranky running on 2.6 (and vice versa)...
<vila> fullermd: nope, tested it locally
<Kaleetos> yea, that makes sense now that I think about it
<fullermd> That creeps me out more   :p
<vila> well, 2.6 can load 2.5, I didn't test the opposite
<Kaleetos> vila, does bzr have a specific directory it downloads to?
<vila> Kaleetos: what command did you issue ?
<Kaleetos> bzr co http://infiniteplatformer.com/dev/Infinite8BitPlatformer/
<Kaleetos> i found it
<Kaleetos> it went to my home folder
<vila> Kaleetos: that's where you issued the command then
<Kaleetos> oh ok, so whatever directory i'm sitting in when i issue the command
<Kaleetos> thats where it goes
<vila> Kaleetos: yup
<Kaleetos> thank you so much for all your help vila
<Kaleetos> now its 7am here and I started this journey at around 12am. so I seriously need to crash, but I will write up that second bug report first thing in the morning
<Kaleetos> thanks again!
<Riddell> jelmer: thanks for approving, what happens to it next?
<jelmer> Riddell: no problemo. I guess you don't have PQM access yet; I can submit it for you
<vila> Kaleetos: thanks
<Dr_Al> vila: Yesterday, you provided some very helpful informal review comments on my first attempt at writing some test code.
<Dr_Al> I (think I) have taken into account everything that you said; would it be possible for you to have another look and see what you think now?
<Dr_Al> The latest revision diff is here: http://tinyurl.com/6556fg5
<Dr_Al> My saved copy of your review comments (for reference) is here: http://paste.ubuntu.com/603195
<jelmer> Riddell: submitted - it's now in PQM and should land on lp:bzr when finished. You can see the progress here: http://pqm.bazaar-vcs.org/
<vila> Dr_Al: seems correct, but just add your new class to test_switch, no need to create a new file (files under blackbox are ~named after the command they are testing)
<vila> Dr_Al: blank line missing after the class name to comply with pep8 too
<vila> Dr_Al: but more importantly: do they *fail* now ?
<Dr_Al> The lightweight one passes and the heavyweight one fails (as expected)
<vila> Dr_Al: and otherwise, feel free to make a merge proposal even for early feedback, you can set the mp to 'work in progress' once you get it
<vila> Dr_Al: great !
<Dr_Al> vila: On another note, should I test "bzr branch --switch" separately to "bzr switch --create-branch" or can they be assumed to be functionally identical?
<Dr_Al> Although I guess that would mean splitting the tests between test_switch.py and test_branch.py
<vila> Dr_Al: it doesn't hurt to add such tests (especially if you manage to parametrize a bit more your script to easily vary for such cases)
<vila> ha, sorry, misread
<vila> hmm, have a look at their implementation in builtins.py and decide from that
 * vila goes to lunch
<Dr_Al> vila: They look sufficiently different to me to seem to need to be tested independently
<Dr_Al> If I move the tests into test_switch and test_branch, should I move assertParentCorrect into TestCaseWithTransport instead of having two copies?  I don't want to start editing parent classes without checking here first!
<jelmer> vila, jam: Aren't parents supposed to be tuples? Tree.get_parent_ids() confusingly returns a list in some case
<jelmer> s
<jam> jelmer: I don't think we've ever been perfectly strict on it
<jam> get_parent_map, IIRC, always returns tuples
<jam> there have also been some odd cases with stuff-being-built vs stuff-read-from-disk
<jam> I'm fine if we want to change it to always be a tuple of revision_ids
<jelmer> jam: I'll submit a MP to change it to a tuple
<jelmer> jam: Thanks
<vila> Dr_Al: hmm, not on TestCaseWithTransport, it's too specific for that, better put it in blackbox/__init__.py may be
<Dr_Al> vila: It would be the only assert.* in there if that's the case: is that okay?
<vila> Dr_Al: hmm, blackbox/__init__.py is indeed almost empty...
<vila> Dr_Al: just make an mp and we'll discuss it there,
<Dr_Al> Okay.
<Dr_Al> Another point for discussion (perhaps this should be in a merge proposal as well, but it's a bit further down the line):
<Dr_Al> When doing "switch -b" on a bound branch, a new branch is created and I'm changing the parent of that new branch to match the source branch.
<Dr_Al> I'm also thinking that I should set the parent location of the heavyweight checkout to match that of the branch to which it is bound.
<Dr_Al> Do you agree?
<vila> Dr_Al: re-reading your last proposal, I think assertParentCorrect can be further simplified, ideally the split shouldn't be needed at all if you were providing the right expected parents (and the None case would be also covered in this case)
<Dr_Al> (As background, the reason for me obsessing about this is that I want to get the submit panel working in Bazaar Explorer... according to the comments in view_workingtree.py there are some other issues that may also be resolved, but I'll come to those next...
<Dr_Al> )
<vila> Dr_Al: yeah, better to address these issues one by one so that the controversial bits don't block the others
<Dr_Al> Okay, the reason it came up was that my current test (which obviously can be fixed) is checking the parent of the bound branch rather than the master branch!
<vila> Dr_Al: and all these discussions are easier with code and tests to explain the issues
<Dr_Al> Good point
<vila> Dr_Al: and mps also track the discussion which help
<Dr_Al> Okay, I'll throw a merge proposal in with a few controversial things and we'll see where we go from there!
<Dr_Al> vila: Merge proposal created: https://code.launchpad.net/~abudden/bzr/switch_parent_513709/+merge/59924
<vila> Dr_Al: ok
<vila> jelmer: move-more-more ? You already did move-more or is it just showing your enthusiasm ? :D
<jelmer> vila: I think I already did two move-more's so I thought it was time for more-more :)
<vila> hehe
<vila> maxb: around ? I just pull hydrazine and get an AttributeError for web_link ??
<vila> maxb: while using feed-pqm that is
<maxb> vila: Hello
<maxb> As a first step, I would try purging your launchpadlib cache.
<vila> maxb: hi ! (Sorry, where are my manners...)
<maxb> Cached stale wadl could produce that error
<vila> .cache/launchpadlib ?
<vila> maxb: or is there a command to do that ?
<maxb> rm -r :-)
<vila> hehe, right, but is it the right directory ?
<vila> :)
<maxb> I'm unsure, I think it moved in natty too
<maxb> I don't have that directory
<vila> hmm
<maxb> vila: Are you on natty?
<vila> and what is this new access scheme, feed-pqm now trigger a dialog with lp asking to confirm access for my host instead of hydrazine only ?
<vila> yes, migrated a couple of days ago
<maxb> If so, ~/.launchpadlib/api.launchpad.net/cache/
<maxb> This new access scheme is about authorizing your Unix user account rather than individual apps.
<vila> weird and what if I want to give read access to some apps ?
<vila> ha, at least purging the cache addressed the issue at hand, thanks maxb !
<maxb> I believe the party line is that if you trust the apps to not go and search for a write-enabled credential somewhere else on your machine, you can just trust them not to write
<maxb> Or, for that matter, steal your firefox cookie and grant themselves a new credential headlessly
<vila> well, I wasn't in the paranoiac mode, more in the idiot-proof mode ;)
<maxb> FWIW, I disagree with the arbitrary changes to the launchpadlib API to ram the new authentication scheme down the throat of existing apps
<vila> I guess people were getting tired authorizing so many apps...
<maxb> I do agree with the overall idea, at least for most purposes
<maxb> I was actually emulating the "one token per host" model using symlinks long before natty
<vila> maxb: wow, I should report you to the good citizen police ! :-P
<vila> someone is monopolizing pqm ;)
<vila> the good side is that it will reduce the review queue...
<vila> hey poolie !
<poolie> hi vila
<poolie> nice to see you at this time of day
<poolie> are you piloting today?
<vila> indeed :) see pqm ;)
<vila> poolie: and land lp:~mbp/bzr/rules (or tell me to do it ;)
<doppiabeo> Hy guys
<poolie> heh, i'll see about that
<poolie> hi doppiabeo
<poolie> i have some lp branches to push too
<poolie> landing there is a bit scary
<doppiabeo> I'm in trouble. My situation: I pulled from a tree... a created a new bzr-working-copy-tree, and now I must update the main tree with my changes, and I'd like to keep my history along with the main history.... is it possible to merge in this case?
<doppiabeo> Thanks in advance
<Dr_Al> Hello all
<Dr_Al> Can anyone tell me: is there a way to get an equivalent of revisionspec.RevisionSpec.from_string("submit:") for the parent branch?  In "bzr help revisionspec" it says that "submit:" will return the parent branch if there is no submit branch, but what if you want the parent branch and there IS a submit branch?
<vila> parent: ?
<vila> err or is that ancestor: instead ?
<Dr_Al> I've tried from_string("parent:") but that produces Unsupported protocol for url "parent:"
<Dr_Al> vila: From the help, "ancestor:" looks like a parent revision rather than a parent branch.  Maybe I'm reading it wrong
<vila> well, it's the common ancestor between the branch and its parent IIRC
<Dr_Al> Okay, I guess I need to separate the two implementations for submit and parent.  I'll see what I can figure out.
<poolie> doppiabeo, one way is:
<poolie> actually, just let me check first
<poolie> you have your own branch with multiple committed changes, and now you want to commit a merge of them onto trunk
<poolie> hi jelmer, jam
<bialix> strange, poolie around at this time :-) hey pooliw
<bialix> hey poolie
<poolie> hi bialix
<poolie> i'm pretty close to you now, in Budapest
<poolie> relatively speaking
<bialix> yep, that's very close :-) UDS-O?
<doppiabeo> I made the mistake to create a new repository at the beginning...
<poolie> yes
<doppiabeo> compyng files from the main one... (I didn't know how bzr work)
<poolie> actually in a directly neighbouring country, i see (i wasn't sure if that was true)
<doppiabeo> and now I want to merge it back in the main one
<bialix> poolie: yes, that's correct
<poolie> doppiabeo, there's a good quick tutorial
<poolie> at, say http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html
<bialix> next time Canonical can choose Kiev for this event ;-)
<doppiabeo> thanks poolie
<doppiabeo> as you know, is it possible to do what I want to do?
<poolie> so you just copied the directory?
<poolie> or you copied across particular source files then edited them
<doppiabeo> files inside directory in a new one, then I added them to a new repo
<jelmer> hey poolie
<doppiabeo> (so know I have two different trees without common ancestors)
<doppiabeo> *now*
<vila> doppiabeo: how many commits in the smallest branch ?
<doppiabeo> 6-7
<a3Dman> http://dl.dropbox.com/u/14234621/May2011/Screen%20shot%202011-05-04%20at%2016.25.34.png
<a3Dman> xD
<doppiabeo> but if I find out howto merge different bzr repositories maybe I can recover more history from another working dir... evenif the most important are the two that I'm trying to unify now...
<doppiabeo> maybe I found something http://www.cuberick.com/2009/02/merge-bazaar-repositories-with-no.html
<ams_cs> hi all
<ams_cs> I push a commit to a launchpad branch this morning, and now somebody else has overwritten it (presumably by mistake)
<ams_cs> I'm trying to fix it up, but 'bzr merge' now says "Nothing to do."
<ams_cs> any suggestions how to fix it?
<maxb> This suggests you are not merging what you think you are merging
<maxb> What is the branch in question?
<ams_cs> I merged lp:~ams-codesourcery/gcc-linaro/compound-conditionals into lp:gcc-linaro/4.6 this morning
<ams_cs> it was committed at 106740
<ams_cs> then at 14:29 UTC+0100 I got a notification saying "1 revision was removed from the branch."
<ams_cs> and two more commits have been pushed at the same time by somebody else
<ams_cs> presumably they used --overwrite by mistake?
<maxb> Yes
<ams_cs> so I did bzr pull --overwrite to sync my local tree
<ams_cs> and then tried the merge again, but it won't work
<maxb> Hmm, that sounds a little odd
<maxb> I'm grabbing the branches to have a look, but of course, they are huge, so it's taking a little while
<ams_cs> very huge
<poolie> doppiabeo, still here?
<poolie> i see what you mean
<ams_cs> I'm doing a fresh branch from lp:gcc-linaro/4.6 to see if that works better
<ams_cs> init-repo should mean it's all cached, but is that likely to defeat the 'freshness' I wonder?
<maxb> It should not matter.
<maxb> Just how big is this branch, I'm > 200MB already ?
<ams_cs> maxb: a compress tarball is like 50MB
<doppiabeo> yes
<ams_cs> maxb: sorry, I'm wrong, it's 7MB
<ams_cs> maxb: sorry, I'm wrong, it's 70MB
<ams_cs> this is not a small project
<poolie> doppiabeo, do you know ,or can you work out, which revision of trunk you started from?
<poolie> if so, perhaps you can
<poolie> branch from thta
<poolie> copy over your work into that working tree
<poolie> run diff to see what you actually changed
<poolie> then merge that in
<doppiabeo> I'm here but working, so I look here every now and then
<doppiabeo> yes I know the revision
<ams_cs> maxb: I get the same failure when I try to merge into my fresh branch :(
<maxb> ams_cs: OK, I have the branches locally
<maxb> bzr is telling you there's nothing to merge because there really isn't
<maxb> Your branch is merged to the current 4.6 branch in 106741: Richard Sandiford 2011-05-04 [merge] Resolve conflicts.
<poolie> hi maxb
<maxb> So, what has happened is that Richard Sandiford has merged 4.6 into his local work branch, and then pushed the result to replace the shared 4.6 branch
<maxb> hi poolie
<ams_cs> maxb: oh, I see, very not-intuitive :(
<maxb> So, there's two things we can do here
<maxb> One, there's a flag, append_revisions_only, that you can set on a branch which will make bzr refuse to push revisions which move existing revisions off the mainline
<ams_cs> maxb: ok, I want that - how?
<maxb> Two, we can straighten out this history goof if we act before any more commits land on the 4.6 branch
<maxb> If your local bzr is new enough, "bzr config -d lp:gcc-linaro/4.6 append_revisions_only=True" ought to do the trick
 * ams_cs examines history more closely
<ams_cs> hmm, bzr: ERROR: unknown command "config"
<maxb> To straighten out the shifted history, you would need to branch from your original landing commit, and then merge the current tip of 4.6
<ams_cs> I'll try a different machine ....
<ams_cs> maxb: ok, I've found a bzr new enough to do the config thing
<maxb> python -c 'from bzrlib.branch import Branch; Branch.open("bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6").set_append_revisions_only(True)'
<ams_cs> I'll leave the history as is
<maxb> would be an alternate way to do it
<poolie> ams_cs, hi there, i saw your mail
<ams_cs> I disapprove of rewriting history enough without doing it myself
<poolie> ams_cs, _cs, do you have the mail launchpad sent you?
<ams_cs> yes
<poolie> could you forward that to mbp@canonical.com?
<ams_cs> poolie: sent
<poolie> thanks
<m4n1sh> in which package is "launchpad-login" for bzr provided?
<m4n1sh> or is it the part of the main bzr package?
<lifeless> its part of the launchpad plugin which is included in the main tree
<m4n1sh> lifeless: if my ssh key is uploaded
<m4n1sh> to launchpad
<m4n1sh> then using some bzr extension can I file a bug
<m4n1sh> using my ssh key?
<m4n1sh> to authenticate?
<lifeless> no
<lifeless> the ssh key is used to authenticate for bzr uploads/downloads only
<m4n1sh> the use-case is
<m4n1sh> firefox is crashing
<lifeless> you can file a bug using the API (which apport/ubuntu-bug do)
<m4n1sh> every time
<m4n1sh> and apport collects the data
<m4n1sh> but you need to submit it
<lifeless> so the upload is not done with firefox
<m4n1sh> but you cant open firefox as it keeps on crashing
<lifeless> you can take the url it opens and open it in a different browset
<m4n1sh> but launchpadlib uses oatuh
<m4n1sh> that is there
<m4n1sh> different browser is the only solution there
<lifeless> Its an interesting case
<lifeless> I would change the defa...
<m4n1sh> lifeless: yes it is
<m4n1sh> this is as I heard a wishlist on apport
<theAdib> hi all. simple question: I run into conflicts. Can I simply rename the foo.h.OTHER file to foo.h?
<abentley> theAdib: Sometimes you can, but usually you need to combine the changes.
<hbeck> hi folks, having some trouble figuring out the proper usage - for a given URL to a repo, I check a specified 'download' directory; if it doesn't exist as a bzr (branch, checkout?) I want to get a specified revision from a master repository and stick it in the specified location. If it's already there, I want to overwrite it with the revision specified.
<hbeck> I think checkout/update are the appropriate things to use here, but not sure?
#bzr 2011-05-05
<spiv> hbeck: yes, checkout and update would do just fine
<spiv> hbeck: the other approach that springs to mind is the bzr-upload plugin, if the 'download' directory isn't local it may be more suitable
<hbeck> spiv: download is local. I'm trying to understand the difference (in the case of a checkout) between update and pull
<spiv> hbeck: if you haven't made any commits locally, then none.
<hbeck> spiv: so bzr pull $MASTER == bzr update (in that case, no local commits)
<spiv> Oh, actually, the other difference is that 'pull' brings a branch up to date with another branch (the parent branch by default), whereas 'update' just brings your working tree up to date with the checkout's master branch.
 * spiv should go get a coffee
<hbeck> so pull is both read/write?
<hbeck> read (to local) and write (to master)
<hbeck> probably bad terminology
<spiv> Yes, bad terminology :)
<spiv> As the help says, âTurn this branch into a mirror of another branch.â  For a checkout, âthisâ branch is the one you have checked out.
<hbeck> parent vs master is confusing
<spiv> (if you look at the 'bzr info' output, it'll say âcheckout of branchâ)
<spiv> Parent is, by default, where someone âbzr branchâed from.  And the parent is used as the default location for pull and merge IIRC.
<bignose> after âbzr mergeâ, I can use âbzr status -vâ to see the summary lines of all merged revisions.
<spiv> When people say master in bzr they mean the branch you made a âbzr checkoutâ of.
<bignose> how can I see the equivalent of âbzr logâ or âbzr log -vâ on those revisions?
<bignose> in other words, the full commit message, and optionally the list of file changes.
<bignose> alternatively, is there an option for âbzr commitâ that will let me work from the commit messages of all pending merged revisions?
<bignose> so I can summarise them in the commit message for the merge.
<spiv> bignose: I'm not sure of a good builtin way.  'bzr qlog' from qbzr happily shows you those revisions, but I don't think 'bzr viz' from bzr-gtk does.
<spiv> The easiest way possibly is to commit; then look at the log; then uncommit and then do the commit properly :/
<spiv> A crude way would be to do 'head -4 .bzr/checkout/dirstate | tail -1 | cat -v', then take the second revid on that line, and run 'bzr log -v r-1..$that_revid'
<lifeless> jelmer: lp:~jelmer/bzr/standard-annotate-interface has renamed file '.bzrignore' => '.bzrignore.moved in it
<hbeck> another newbie question: what happens if you bzr update to a rev earlier than what your local checkout is at?
<spiv> bignose: as a one-line hack: bzr log -r -1..`head -4 .bzr/checkout/dirstate | tail -1 | xargs -n1 -0 echo 2> /dev/null | head -3 | tail -1`
<spiv> We really ought to provide a revisionspec for this stuff.  âpendingmergeâ I guess.
<spiv> hbeck: it will "update" the working tree to that earlier rev (if you have a reasonably current version of bzr)
<hbeck> spiv: would that be the same as pull -r rev# --overwrite ?
<spiv> No, pull would modify the branch as well as your checkout of the branch.
<hbeck> ack, so that would be very bad, in the case of having some master repo and I just wanted to go back to an older rev to build - pull would in effect revert the repo?
<spiv> Yes.
<spiv> (Terminology note: we'd say âbranchâ there, not ârepoâ.  We have repositories, but they are basically just containers for revisions, optionally shared between branches.  It's branches that keep track of what the current revision is.)
<hbeck> noted :)
<hbeck> spiv: given that behavior of pull, I'm a bit confused as to its intended utility?  "a mirror of another branch" suggests that only the "this" branch would be changed
<spiv> hbeck: yes, that's right.  I'm not sure where the confusion is?
<fullermd> pull modifies the destination, not the source (complement of push)
<spiv> hbeck: typically you'd use it like "bzr branch URL my-mirror-of-URL", then later "cd my-mirror-of-URL; bzr pull" to keep that mirror up to date.
<spiv> hbeck: e.g. if you are frequently working with the trunk of some project hosted on the internet you'll probably prefer to have a local copy of that trunk to work with, for speed.  Pull keeps that copy current.
<hbeck> ok, I thought you said that if I did "cd my-mirror; bzr pull -r oldrev --overwrite" that it would move both my-mirror and the URL itself back to oldrev
<fullermd> I think he was talking about doing pull from a checkout (in which case there's only 1 branch to influence)
<spiv> If my-mirror is a *checkout*, rather than a branch
<spiv> Then the branch pull modifies is the checkout's branch.
<hbeck> ah. AH.
<hbeck> lightbulb
<hbeck> so... "bzr co URL dldir; cd dldir; bzr pull -r oldrev --overwrite" changes the branch (in the checkout) in dldir but not out in URL-land.
<hbeck> do I have that right finally?
<fullermd> Other way around.
<fullermd> (and you may need another arg on the pull, but that's irrelevant really)
<fullermd> Think of it this way; you have a branch 'master' (probably bzr+ssh://something or the like)
<fullermd> You want to work locally in 'mywork'.
<fullermd> You can:
<fullermd> 1) bzr branch master mywork
<fullermd> Now you have two branches; the existing 'master', and the new 'mywork' based on [the current state of] master.
<fullermd> You use 'bzr pull' in mywork to drag in new stuff from master (assuming you're not adding new revs locally of course)
<fullermd> or,
<fullermd> 2) bzr co master mywork
<fullermd> Now you still only have _one_ branch; 'master'.  'mywork' isn't a branch, it's just a new working tree on the existing 'master' branch.
<fullermd> You'd use 'update' to "catch up" the tree when 'master' moves ahead.
<fullermd> 'pull' is for copying revs from one branch to another.  'update' is for catching up the working tree to its branch.
<fullermd> (of course, both can be used with '-r' to go backward instead of forward, but that doesn't change the basic difference; pull is for updating branches, update is for updating working trees)
<fullermd> If you ran 'bzr up' in mywork in case (1), you'd be updating the 'mywork' working tree to match its branch, which is also 'mywork'; it contains both in that case.  So it's usually going to be unnecessary, since you're not going to 'move' the branch forward or backward other than by going through the tree already.
<fullermd> IF you run 'bzr pull' in mywork in case (2), you'd be asking bzr to update the branch 'master' (that being the only branch existing) to match its parent, wherever that may (or may not) be.
 * fullermd wanders off into further confusing details...
<hbeck> chewing on that...
<hbeck> I am working with a build system, it has a fetcher that will grab stuff using bzr. Currently it is written to do this:
<hbeck> 1) does the thing to fetch already exist? if no, checkout
<hbeck> if yes, pull --overwrite
<hbeck> with a revision specified by a recipe in the build system
<hbeck> which could be behind the current rev of the 'master' branch location
<hbeck> this stuff that is fetched is not a work area, it is just to download and build from
<hbeck> so it seems like checkout/update is appropriate.
<hbeck> ?
<fullermd> I'd probably tend to use branch/pull.  But in this case it's probably 6.5 of one, half a baker's dozen of the other.
<fullermd> But doing checkout/pull is certainly not what you want   :)
<hbeck> why? (for my own edification in all these confusing details)
<hbeck> to the branch/pull tendency
<fullermd> Well, I generally only go to 'checkout' when I intend to work on and commit stuff directly to 'master'.
<fullermd> I use 'branch' for readonly/reference/etc copies.
<fullermd> To some extent, that's just mental philosophy.
<fullermd> OTOH, it does give you a little extra safety, since your mywork is nearly completely decoupled from master.
<fullermd> If you accidentally pull or commit or whatever in it, it doesn't do anything to master.
<fullermd> You'd have to actually explicitly do something like push.  Whereas with the checkout (assuming you can write to master), commits or pulls or the like will end up doing stuff to master.
<hbeck> ok, that last bit is where I'm confused (pull doing stuff to master, referring to master being the 'master' branch location and mywork being a checkout)
<hbeck> if I did bzr co master mywork
<fullermd> I think calling it the "master branch" in reference to a checkout is just confusing.  It's just the _branch_.
<fullermd> There's only one, so anything that writes stuff to a branch (like pull, or commit) writes it there, because that's the only branch there is.
<hbeck> bzr pull -r oldrev --overwrite master  (from mywork dir)
<hbeck> that moves mywork back to oldrev
<hbeck> and the master (off on some other machine) is not changed
<fullermd> That moves the _branch_ for mywork back to oldrev.
<fullermd> If you did 'bzr branch master mywork', then mywork is its own branch, and master is unchanged.
<fullermd> If you did 'bzr co master mywork', then mywork is _not_ its own branch, it's just a working tree on master.  So the branch you're changing is master.
 * hbeck head explodes
 * fullermd grabs some duct tape.
<hbeck> while we've been talking, i tried this.
<hbeck> bzr co master mywork
<spiv> hbeck: the really short version is: "if you have a checkout, use update.  If you have a branch, use pull."
<hbeck> bzr pull -r oldrev --overwrite  (which fails due to lack of pull location)
<hbeck> so then I did bzr pull -r oldrev --overwrite master
<hbeck> which worked exactly like I thought bzr update -r oldrev should
<hbeck> and our server-hosted stuff is happy and safe
<spiv> hbeck: 'bzr log -d master' will now show that master is at oldrev too.  Is that what you want?
<hbeck> negative spiv, I went over to the master location and it's still at the current rev
<fullermd> That would be one of those 'bound-branch-screwing-things-up" bugs...
<spiv> fullermd: yeah
 * fullermd clears his throat to do that grumble-dance again.
<spiv> hbeck: well, it appears it does work, but personally I find that confusing :)
<hbeck> yeah
<hbeck> it is
<hbeck> extremely
<fullermd> Anyway.  You shouldn't rely on that, because it's a bug/wart/implementational-detail that may (will, hopefully) change.  You'll see different behavior if you used a lightweight checkout, for instance.
<spiv> hbeck: and unlike "bzr update -r oldrev", it will give different results on a checkout made with "bzr co --lightweight"
<hbeck> I'm going to submit a patch to this fetcher thing to use update
<hbeck> appreciate the help :)  sorry for being dense, heh
<spiv> hbeck: that's ok, this corner of bzr is unnecessarily confusing :(
<AuroraBorealis> For some reason i can't access my repository on my ftp server using bazaar explorer anymore, i have to use the command line, anyone have any idea whats going on? :<
<bignose> I'm a little confused by the earlier conversation on checkouts and branches.
<bignose> I am such an old Bazaar user that âcheckoutâ is what the new world order names âbound branchâ.
<bignose> what's the current state of play? are checkouts not good? are bound branches not good? are plaid pants not good?
<fullermd> Plaid pants are totally not good.  Even I know that.
<fullermd> Of course, I'm not overly pro-pants in general, so I'm not the best source...
<vila> hi all !
<fullermd> Again?  You just said that yesterday...
<vila> yeah, any idea about different punch lines ? I grow tired of repeating myself ;)
<fullermd> "So I said, 'Horse?  That looks more like a peanut to me!'"
<spm> you could try RPN? ! all hi<pop-all>
<vila> spm: I like that !
<vila> fullermd: s/Horse/Goat/ ?
<fullermd> I dunno.  I guess it depends on the joke you put before it.  That's your part; I just supply the punchline   :p
<vila> well, you used to supply the goats too...
<fullermd> Oh, now you're just trying to get my goat.
<vila> only one left ?!?!?
<bignose> fullermd: you were the one with strong opinions re. checkout, bound branch, etc.
 * vila ducks
<bignose> so why should I use one or the other or both or neither or 1.5-of-the-way
<fullermd> Oh, I've got strong opinions on all sorts of things.  That's why people avoid me   :)
 * bignose is much happier now having configured Emacs âdiff-modeâ colours properly
<fullermd> Well, I'm not the one to ask about bound branches, as I'm not overly interested in them.  I'm not anti-them, just don't fit anything I need doing.
<bignose> what imbecile thought that having the same colour for added and removed lines was a good idea
<fullermd> My periodic gripe is that there are conceptually "bound branches" and "checkouts", and bzr implements one thing that's part one and part the other, advertising it as botrh.
<vila> bignose: ? That doesn't match my experience and I don't remember having changed anything there...
<fullermd> And both, too.  The 'r' is silent.
<spiv> fullermd: and invisible..
<bignose> vila: âdiff-modeâ has faces for added lines and removed lines; they both inherit from the âchanged linesâ face.
<bignose> which is yellow.
<vila> bignose: weird, deleted lines are red and added lines are blue here..
<bignose> well, they are now for me, but I had to change it from Debian's Emacs defaults :-)
<bignose> (deleted lines red, added lines green)
<bignose> (now for me)
<bignose> (in parentheses)
<vila> oh crap, lost connection to my secondary desktop :-(
<vila> bignose: ha. hunk separators are green here
<fullermd> It's not lost connection, it's just locked up for a few minutes while it tries to swap emacs in   ;p
<vila> bignose: oh, I *did* change that ;)
<vila> ;;; Set more shiny faces for diff-mode
<vila> (custom-set-faces
<vila>  '(diff-hunk-header ((t (:foreground "#007700"))) t)
 * vila frowns at natty :-/
<vila> pfew, thanks firefox for restoring my not-yet-saved review comments... I have no idea those could survive a reboot...
<vila> hmm, I had, now I know
<fullermd> Well, you just save 'em off into a file...
<vila> ha right, I always forgot my time machine
<fullermd> You use ViewSourceWith so you can use $EDITOR on textboxen, then you can just recover the temp file.
<fullermd> Well, unless you put it on a swap-backed /tmp like I do...
 * vila blinks... and seriously considers resurrecting the emacs-client setup task from the TODO graveyard 
 * fullermd . o O ( easier to just set it up to use gvim... )
<bignose> .oO( for some values of âeasierâ )
<vila> . o O (There are two editors: emacs and ed. The later and a working internet connection are enough to setup the former and even there the later may not be needed ;)
<fullermd> And dd/sh is the One True programming language   ;p
<vila> :)
<vila> spiv: do you know in which ubuntu package one may find the python test suite ?
<bignose> vila: it's not in the Python source code package?
<bignose> I wouldn't expect the Python test suite to be in any binary package, if that's what you're expecting.
<vila> bignose: it probably is but this won't make it available with a simple 'import' no ?
<bignose> vila: well, the Python test suite isn't something available with a simple âimportâ.
<bignose> I don't think so, anyway.
<vila> crap
<bignose> since Python is not itself implemented wholly in Python
<bignose> or rather, the âpythonâ packages are CPython, which is implemented mostly in C.
<vila> well, I'm reviewing a proposal where a module from the test suite is used as a basis so it's a compelling reason to make it available
<bignose> by âas a basisâ we might not understand the same thing.
<bignose> vila: are you referring to a subclass?
<bignose> because âas a basisâ doesn't imply that.
<vila> right, sorry for my broken english, have a look at https://code.launchpad.net/~songofacandy/bzr/i18n-utextwrap/+merge/59950
<vila> at the end of 'bzrlib/tests/test_utextwrap.py'
<vila> I've never seen such use and wanted to look at it with a working setup, hence the need to have the import succeeds
<bignose> vila: okay. I think you're referring to the test suite for the Python standard library
<bignose> which is mostly implemented in Python, and AFAIK the test suite for the standard library is also implemented in Python
<bignose> and hence importable
<bignose> vila: the package might be âpython-devâ, but that's just a guess
<vila> yup, I'm after tests.test_textwrap precisely
<vila> already installed
<lifeless> I'm 99% sure the stdlib test are not installed
<bignose> I would not expect any binary package to make the standard library's own test suite available for import.
<vila> hehe, I don't mind if the package is called xxx-test-suite ;)
<spiv> vila: I don't think Python's test suite is packaged
<spiv> vila: the test.regrtest module is packaged, but none of the individual test modules AFAICS
<vila> right, I'll live with that and will just put the module in my private setup for... testing :)
<bialix> vila: for you: https://bugs.launchpad.net/bzr/+bug/777650
<ubot5> Ubuntu bug 777650 in Bazaar "[win32] `bzr selftest > test.log` creates too long lines" [Undecided,New]
<bialix> bonjour vila
<vila> bialix: great, thanks !
<bialix> vila: it seems the old behavior I remember is now changed
<bialix> now selftest does not clear correctly progress messages at all
<bialix> when redirected
<bialix> I wonder if it related to testtools
<vila> It seems related to a bad terminal detection, I don't think testtools is involved.... or is it ?
<vila> bialix: what happens if you force values in osutils._win32_terminal_size ?
<bialix> it's not very easy
<bialix> so it possible but not right now, sorry
<bialix> this bug is not critical for me
<bialix> a bit annoying but I have enough mental force to not cry
<fullermd> Darn.  I'll have to come up with an even more inventive means of torture now...
<vila> try adding comments in this bug for the various different cases your observe then
<bialix> ok
<bialix> o, hi fullermd
<bialix> have you asked for qdiff to remember unidiff knob?
<fullermd> I think I did $YEARS ago...
<bialix> how's bad, I've just thought about fixing that
<fullermd> Well, so you just read my mind very slowly   ;)
<fullermd> 's probably for the best anyway.  If you read it quickly, you'd probably run away screaming.
<bialix> yep
<bialix> are you using qdiff or qbzr in general?
<fullermd> Not with any regularity.  And mostly recreationally when I do.
<bialix> damn, and we don't have blackjack inside yet
<fullermd> I'm waiting on Solitaire.  Red 1604.2.37 on the black 1605.
<bialix> ghaaaa! that's so cool idea!
<fullermd> It's a new UI for rebase   8-}
<bialix> :-D
<vila> . o O (UI for rebase and other history tweaks....)
<vila> . o O (drag: pull, merge, etc...)
<maxb> Does anyone know if there is an open bug for bzr's algorithm for figuring out which revisions to fetch being fairly dire?
<maxb> As an example, try bzr branching gcc-linaro into an empty shared repository. It spent >2MB of data transfer trying to figure out what revisions were missing ("all of them") before I gave up
<vila> maxb: not sure if a bug is filed for it, but branching into an empty shared repository disable the shortcut used when branching otherwise (branching as in: I want all the revisions)
<vila> maxb: the "workaround" is to create a standalone branch and *then* reconfigure it to use a shared repo so that all the queries are local instead of across the network
<maxb> I think we could learn from mercurial here. Their network protocol for figuring this out seemed rather well designed when I read its developer docs
<spiv> maxb: there's an open bug for that.
<maxb> I figured there would be, I'm just having trouble phrasing a suitable search :-/
<spiv> maxb: https://bugs.launchpad.net/bzr/+bug/388269
<ubot5> Ubuntu bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed]
<maxb> thanks :-)
<spiv> maxb: one limitation is that calculating the heads for a repo is not a cheap operation for us
<spiv> maxb: I think we could relatively easily make that cheap (it would involve having the repo on-disk format track the list of heads), although that's only part of the problem.
<spiv> Another is that we probably should be doing exponential walking backwards, rather than the fixed number of steps we do now
<spiv> There's also some potentially clever stuff we could do by using bloom filters rather than sending long strings of revision ids on the wire, although that's more about keeping individual roundtrips small than reducing roundtrips
<spiv> (But if a single roundtrip can do more work then that obviously helps us reduce roundtrips)
<spiv> The approach I see described on the hg wiki seems pretty much in line with ideas we've previously discussed.  Care to help us implement them? :)
<maxb> Definitely interested, though I need to learn a bit more about the existing internals first.
<maxb> Bazaar's rather profligate use of bandwidth is a sore point when trying to tempt hg and git users, I think
<spiv> Well, if it's profligate use of bandwidth you want to fix, those are different buts ;)
<spiv> *bugs
<spiv> This one is excessive network round trips :)
<spiv> (Which tends to suggest more bytes are being exchanged than strictly necessary too, but to a much lesser degree)
<spiv> jam: I've got a crude hack for 'bzr branch --stacked REMOTE local' that fetches inv and text data that'll be needed to build the working tree at lp:~spiv/bzr/faster-stacked-tree-build
<spiv> jam: it's in an extremely ugly state but for one branch it cuts the roundtrips from 151 to 85, and the bytes transferred from 38.6M to 13.5M
<spiv> jam: but it takes 6.9s rather than 3.1s; I guess it's the extra time to write and validate all the extra data into the local repo that we'd otherwise discard
<spiv> jam: it looks like making get_stream_for_missing keys is the main remaining source of VFS calls, fixing that would probably trim the roundtrips and bandwidth even further.
 * spiv -> zzz
<mgz> okay, what else needs following up on...
<jam> spiv: how REMOTE is remote in that case?
<mgz> he's abed.
<mgz> vila's back now right? I wanted to bother him about some config bugs.
<vila> yup
<vila> shoot
<vila> mgz: and I'm landing export-tt without eith
<mgz> gotcha.
<mgz> so, currently bzrlib.config has three entry points for ConfigObj()
<mgz> one of which doesn't try/except, hence bug 502060
<ubot5> Launchpad bug 502060 in Bazaar "Clearer exceptions on config file parsing errors" [Medium,Confirmed] https://launchpad.net/bugs/502060
<mgz> also bug 688677 would need fixing in three places
<ubot5> Launchpad bug 688677 in bzr (Ubuntu) "UnicodeDecodeError loading config file containing invalid UTF-8" [Low,Triaged] https://launchpad.net/bugs/688677
<vila> what do you call an entry point ?
<mgz> is the idea with lp:~vila/bzr/config-abstract-store that the _load_from_string method will then be the only place?
<vila> mgz: yes
<mgz> okay, so I may as well leave those bugs till you've landed
<vila> mgz: but this isn't used so far
<mgz> otherwise we'll just conflict
<mgz> yeah, I didn't see any of your bits *removing* code.
<mgz> so, when you do, you'll fix the first of those bugs as a side effect, probably want a test for it.
<mgz> and the second one will be easy, just need an except UnicodeDecodeError clause.
<vila> huh, while would I fix the first one ?
<vila> anyway, there are tagged with 'config' so I'll probably won't miss them
<mgz> because if the code for TransportConfig._get_configobj goes through your method, it'll start catching ParseError
<vila> ha right
<mgz> they both seem tagged appropriately
<vila> yes, sorry, that what I meant, I checked
<mgz> ...my flakey internet at the moment really screws up bzr and launchpad http access
<vila> jam, mgz: so what are we up with lp:~gz/bzr/test_traceback_compat_656170 â lp:bzr ?
<jam> vila: failing for seemingly unrelated issues, IIRC
<mgz> I was just going to try and send it again to get the pqm output myself
<mgz> but hydrazine's hung
 * mgz hits ctrl+c and waits a few minutes for the timeout
<vila> mgz: when did you use hydrazine last ? I had to clear my cache and re-authorize after upgrading to natty...
<vila> mgz: and launchpadlib has been upgraded too
<mgz> it's just my connection's sucky during the day lately I think, randomly fails to establish tcp connections
<vila> k k , just mentioning
<mgz> I'll pull launchpadlib too and see.
<mgz> http://paste.ubuntu.com/603717/ <- eg. Worked on the next try though.
<vila> weird
<jelmer> hmm
<poolie> hi vila, jam, jelmer
<jelmer> hey poolie, how's Budapest?
<jam> hi poolie, enjoying Budapest?
<jelmer> It looks like IDS refuses to work with non-local repositories
<jelmer> yet, Inter.get defaults to returning "InterRepository" if it can't find any alternatives, and that uses RepoFetcher
<jelmer> which seems to assume data has the same model, etc.
<mgz> I'll look at Naoki's text wrapper branch later when I can actually fetch it
<vila> mgz: that would be awesome !
<poolie> hi, am i back?
<poolie> it is good
<vila> no
<vila> :)
<poolie> vila, so you merged all your config code?
<poolie> that's great
<vila> poolie: almost yes, I'm piloting right now but will resubmit the concrete-stacks one for re-review before starting on new stuff
<vila> the review queue is almost back to a manageable size
<poolie> mm still pretty hefty though
<jam> jelmer: InterRepo doesn't assume same models, does want to use InventoryDeltas if it can.
<jam> otherwise I think it falls all the way back to new.serialize(old.deserialize(content))
<jam> IDS doesn't do remote per other people's request.
<vila> poolie: yeah, but according to http://webnumbr.com/bzr-active-reviews were on the right track ;)
<jam> (and if we have decent inventory deltas, it should be ok)
<jelmer> jam: do sinks deserialize/reserialize?
<jelmer> jam: as far as I can tell RepoFetcher doesn't do any sort of translation; it's also used exactly the same way by InterSameDataRepository
<jelmer> it seems strange that InterRepository is the default while InterSameDataRepository is basically InterRepository with an is_compatible method and is separately registered
 * jelmer if this also be why it is possible to fetch from a subtree format into a non-subtree format
<maxb> In the bzr beta PPA for hardy:
<maxb> ERROR: bzrlib.tests.commands.test_commit.TestCommitWithBoundBranch.test_commit_both_modified
<maxb>  NotImplementedError: <bound method SilentUIFactory.get_password of SilentUIFactory()>
<maxb> Does that mean anything immediate to anyone?
<jelmer> mab: it looks vaguely familiar, but I don't recall what the exact issue was
<poolie> hi maxb,
<poolie> it is familiar
<vila> maxb: rings a bell
<poolie> i think it's a lack of isolation from the test environment
<poolie> is that on trunk?
<maxb> Yes (2.4b2)
<vila> maxb: running tests in parallel ?
<maxb> *gha!*
<maxb> yes
<maxb> hmm
<maxb> but on random ports
<vila> that gives more weight to the test isolation issue
<poolie> jelmer,  ams_cs was saying on the linaro list he found rebase really slow
<poolie> ... what should we do?
<jelmer> that seems likely, it's O(tree) at the moment and it uses a workingtree for its operations rather than e.g. a memory tree
<jelmer> I don't have a silver bullet, although I do have some plans on how to fix rewrite
<jelmer> I can spend some time on that if you like
<poolie> mm
<poolie> it would be useful to improve but it's probably not top of the stack at the moment
<jelmer> poolie: btw, do you know if any of the Linaro folks we've been talking to are going to be at UDS?
<poolie> if it was surprising, or if you thought it would be easy to fix i could get more data
<poolie> michael hope is here now
<poolie> i would guess he's here next week too
<poolie> and jamse
<poolie> *james
<poolie> it's this thread http://lists.linaro.org/pipermail/linaro-toolchain/2011-May/001196.html
<poolie> jelmer, i think we should have at least a bug for rebase performance so people can vote for it
<jelmer> poolie: that's a good idea
<poolie> vila thanks for the prod on my rules branche
<poolie> on the whole i think i'll just land it with the curren name
<vila> poolie: yeah, and keep working on it to fix the related bug ?
<poolie> indeed
<vila> that gives a better history in the end while making the intermediate reviews easier
<poolie> maybe not this week though
<vila> np
<poolie> oh also, vila, consider yourself prodded to send a pp mail at the end of the week
<vila> poolie: hehe, yeah, sounds like an habit we should all take ;)
<poolie> indeed
<poolie> i think i sent one last time i piloted
<poolie> sometimes the Ubuntu pp reports worry me that they are so long
<poolie> it seems like a lot of overhead for one day's work (in their case)
<poolie> but for us i think a short report is good
<poolie> it reminds us we're doing it
<vila> yeah, I read them searching for ideas to pick
<vila> but their context is too different so far
<mgz> cute launchpad bug. I can edit a bug's priority if it's on a project I have rights to and move it to one I don't at the same time.
<poolie> haha
<poolie> presumably this means you can edit anything
<vila> mgz: go ahead, fix bug #1
<ubot5> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<io2> hi; can bzr merge unrelated branches alla git ?
<jelmer> io2: yes, though you have to force it to do so
<jelmer> io2: "bzr merge -r0..-1 ../unrelated-branch"
<io2> oh
<io2> thanks jelmer
<io2> jelmer: i thought that http://zakalwe.fi/~shd/articles/why_not_bazaar.html was still valid tbh
<jelmer> io2: that's a very biased document
<io2> indeed
<io2> trying to find out a cross platform dvcs that works well right now
<quicksilver> s/biased/inaccurate/
<mgz> "We accept social misanthropes, perfectly normal people with 2.5 kids, a dog and soccer practice on Sundays."
<mgz> I get the bit about accepting the dog, after all on the internet no one cares if you're a dog... but can soccer practice on Sundays really format a patch correctly?
 * jelmer has religious problems with both
<io2> guys, wanna help me get from git to bzr ?
<io2> I like the ui tools and launchpad :P
<mgz> yes, particularly if you say that in a NZ accent.
<mgz> http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
<io2> lol
<io2> how fast is bzr these days btw ?
<mgz> still slow on kernel-sized things for some operations, but pretty good for most projects.
<mgz> I tend to get most annoyed by the time it takes Qt to page in rather than anything bzr does, to give you an idea of the kind of delays I normally run into.
<io2> hmm
<mgz> oh man, pqm looks totally hosed.
<poolie> ?
<mgz> I just got a totally different set of errors from jam's run.
<mgz> ah, no, that's the log being confusing.
<vila> mgz: just after processing your submission...
<vila> mgz: :-D
<mgz> they're nearly all expected failures in the email
<vila> mgz: yeah, expected failures...
<mgz> the one real failure is probably real.
<vila> mgz: generally yes
<mgz> and a bunch of compiler warnings :D
<mgz> looks like jam's change to bzrlib.transport.sftp is wrong/sometimes wrong
<vila> mgz: as in ? More tests needed ?
<mgz> as in I don't know the sftp code, but whatever this ReadvFile is has no close method.
<vila> mgz: 'has no method' always or sometimes ?
<mgz> one of those, and I don't know if it's always the object that line is operating on
<vila> huh ? bzr push told me: Using default stacking branch /+branch-id/241735 at lp-85348944:///~vila/bzr
<vila> Is that new ?
<mgz> yup.
<mgz> http://how-bazaar.blogspot.com/2011/04/launchpad-and-stacked-branches.html
<vila> that would make debugging harder :-/
<mgz> hm, this "How to store binaries along tree" thread is almost exactly what I was working on last week on the train
<abentley> vila: The branch is a real branch that you can interact with, so it shouldn't make debugging much harder.
<levu> when i have local A and remote B and i want to merge B into A i do "cd A; bzr merge B", but how do i do it, when i want to merge A into B?
<vila> abentley: but do I get back its path ?
<mgz> levu: `bzr -d B merge A`
<abentley> vila: I wouldn't bother, since it'll always be lp:project.  But you could use launchpadlib, I guess.
<mgz> won't work over dumb transports, in that case, keep a local copy of B and merge to that, then push.
<vila> levu: merges can produce conflicts, conflicts needs a working tree to be resolved (and the result committed), so you generally clone B locally, resolve the conflicts, commit and push the result
<mgz> and what vila said.
<levu> mgz: thx
<levu> vila: ok, then i'll do it this way :)
<mgz> ...and I spelt it wrong, the -d param goes after the merge command
<vila> abentley: right, but the bug causing this fix was about a broken path which we won't see as easily now, but well, I was hoping for some magical url on lp side
<vila> mgz: hmm, I think we cope with any argument order really
<mgz> vila: but the command has to go first, or you get unknown command "-d" which is always confusing.
<vila> really ?
<mgz> yeah, it should at least sniff dashiness really to give a better error message
<abentley> vila: but broken paths are impossible now, except maybe with branch deletion.
<vila> wow, you're right ... I wonder if it has always been the case as I was almost sure it has work at some point
<vila> abentley: yeah, I get that but still, we never show revids in bzr output (for good reasons you explained me long ago) and suddenly lp is showing an opaque id...
<abentley> vila: If you couldn't interact with it at the +branch-id URL, I'd see that as a problem, but as is, it's more of a symlink than a meaningless number.
<abentley> vila: If you want to file a bug that https://code.launchpad.net/+branch-id/241735 doesn't work, that would be one way to let you get the path.
<lamont> http://paste.ubuntu.com/603869/ <-- wassat mean?  2.3.1
<dvheumen> lamont: I'm just guessing here, but the very low-level problem seems to be that it is trying to import something that doesn't exist
<lamont> yeah
<dvheumen> when did this start to happen?
<lamont> when I upgraded to bzr 2.3.1 on some hardy boxen (using our rebuild of same)
<lamont> OTOH, most of the machines are fine with that version
<dvheumen> hmm
<dvheumen> if you simply run 'bzr' does it happen then too?
<dvheumen> I
<dvheumen> or 'bzr --version'
<dvheumen> I'm thinking that maybe it isn't actually bzr itself that generates the error, but one of the plugins that has been installed. It could be missing a dependency or a mismatched version of the dependency
<dvheumen> try 'bzr plugins' for a list of active plugins
<dvheumen> but like I said, at the moment it's just a wild idea :P
<lifeless> lamont: thats running bzr, or something else? it could be a race condition if you have threads in play
<lamont> bzr status
<lifeless> shouldn't happen there :P
<lifeless> file a bug, include bzr.log stuff for that run
<lifeless> check that you have bzrlib/trace.py
<lamont> I have one x86_64 box where I see it
<lamont> -rw-r--r-- 1 root root 20742 2011-03-10 12:32 /usr/share/python-support/python-bzrlib/bzrlib/trace.py
<lamont> -roseapple(root) 310 : find /usr/share/python* | grep bzrlib/trace.py
<lamont> /usr/share/python-support/python-bzrlib/bzrlib/trace.py
<lamont> -roseapple(root) 311 :
<dOxxx> hey vila, are you around?
<poolie> hi dOxxx
<dOxxx> hey poolie
<dOxxx> my emails to vila are bouncing :P
<dOxxx> I think my ISP's mail server got spamblocked by free.fr
<poolie> oh no
<poolie> try vincent.ladeuil@canonical.com
<dOxxx> ah thanks :)
<jelmer> hi poolie, dOxxx
<dOxxx> hey jelmer
<poolie> hi jelmer
<spiv> jam: "REMOTE" is a bzr://localhost/ in that case
<jelmer> mÃ¸rning spiv
<spiv> HÃ¯ jelmer
 * spiv grabs breakfast and coffee etc, it's still a bit early :)
<james_w`> what's the fix when a branch gets renamed on LP and breaks anything that stacks on it by name?
<mgz> http://how-bazaar.blogspot.com/2011/04/launchpad-and-stacked-branches.html
<james_w`> https://bugs.launchpad.net/launchpad/+bug/377519/comments/1
<ubot5> Ubuntu bug 377519 in Launchpad itself "Stacked on location breaks if the stacked upon branch is renamed" [Critical,Fix released]
<ScottK> Riddell: google translate translates both whiskey and whisky to whisky in Hungarian, so it looks like they are a
<ScottK> are educated on the topic.
<maxb> https://launchpadlibrarian.net/71116344/buildlog_ubuntu-natty-amd64.bzr_2.4.0~bzr5823~ppa3931.3928~natty1_FAILEDTOBUILD.txt.gz
<maxb> ok.... what?!
<maxb> Apparently the testsuite failed, but no tests failed?
<mgz> what changed from the last build?
<mgz> subunit, by any chance?
<maxb> ah
<maxb> yes
<mgz> yup, Unpacking python-subunit (from .../python-subunit_0.0.6+bzr147~ppa102~natty1_all.deb) ...
<mgz> my fault.
<maxb> 0.0.6 to 0.0.6+bzr147
<mgz> I made lifeless fix some stuff but haven't actually fixed the bzrlib suite yet.
<maxb> ah
<mgz> though, confusingly the two tests I thought would be the problem appear to be skipped due to lacking _UnicodeFilenameFeature
<mgz> so perhaps it's an issue with the subunit change rather than me being lazy
<mgz> will try fixing the bzrlib side and if it's still broken poke subunit some more.
<mgz> heh, oh man, diff in this branch gives me timestamp 2010-10-21
<lifeless> jelmer: hi
<lifeless> jelmer: your new stuff failed in daily build
<jelmer> lifeless: 'morning
<jelmer> lifeless: which project?
<lifeless> subunit
<mgz> hm, those are the failures I blamed on your merge lifeless?
<mgz> in fairness, the right semantics did change a few revs later too.
<lifeless> mgz: no, differnet
<mgz> and I forgot to query whether the filters would downgrade xfail->pass and uxsuccess->fail if the local unittest didn't support them, which is another issue
<lifeless> they use testtools
<lifeless> if you make a chain that needs downgrading, they will downgrade
<mgz> that's cool then.
#bzr 2011-05-06
<lifeless> jelmer: test_fixup_expected_errors (subunit.tests.test_subunit_filter.TestTestResultFilter)
<lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_expected_errors ... ok
<lifeless> test_fixup_expected_failures (subunit.tests.test_subunit_filter.TestTestResultFilter)
<jelmer> lifeless: thanks, I'll have a look
<lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_expected_failures ... ok
<lifeless> test_fixup_unexpected_success (subunit.tests.test_subunit_filter.TestTestResultFilter)
<lifeless> subunit.tests.test_subunit_filter.TestTestResultFilter.test_fixup_unexpected_success ... ok
<lifeless> jelmer: for me locally, but failed in the package build
<lifeless> cool
<lifeless> its probably shallow
<mgz> yeah, those are the problems
<mgz> see <https://code.launchpad.net/~lifeless/subunit/bug-654474/+merge/59627> jelmer
<ubot5> Ubuntu bug 59627 in linux-source-2.6.15 (Ubuntu) "Intel Core Duo 50% load with powernowd running" [Undecided,Invalid]
<mgz> wth ubotu5.
<mgz> lifeless: while I have you, can you update the milestone etc on bug 770519?
<ubot5> Launchpad bug 770519 in subunit "Test failures and stream leaking in test_test_protocol suite" [Undecided,In progress] https://launchpad.net/bugs/770519
<lifeless> dne
<mgz> thx
 * maxb removes bzr/daily's dependency on testing-cabal for now as a workaround
<maxb> and on jelmer/daily since that also contains a subunit
<jelmer> maxb: that's going to break all packages for old distroseries
<maxb> oh?
<jelmer> maxb: they need newer versions of subunit - that's why we have the dependency on testing-cabal
<lifeless> maxb: mgz: better to fix bzr I think
<maxb> There is a new enough but not too new version in bzr/ppa
<lifeless> the subunit test failures are not the cause of whatever bzr's issue is
<mgz> lifeless: I agree, would prefer if maxb left it borked so I knew if I'd fixed it
<mgz> as I'm not certain yet if it's a bzr issue or a subunit one.
<jelmer> maxb: what about the version of testtools?
<mgz> ...or testtools
<mgz> which could also be my fault!
<maxb> I believe testtools should be adequately satisfied from bzr/ppa too
<lifeless> maxb: so I suspect mgz is debugging now
<jelmer> maxb: why does bzr/daily have a bzr/ppa dependency in the first place? It seems like that might risk bringing in dependencies
<maxb> In any case, if there's stuff in your personal daily PPA that the bzr one depends on, it would be good to make that less ad-hoc
<jelmer> agreed
<maxb> bzr/daily has a dep on bzr/ppa precisely for things which we don't do daily builds of, but still need a recent release of
<maxb> (IIUC, anyway)
<jelmer> maxb: which ones?
<maxb> testtools, subunit
<jelmer> maxb: THat's why we have the dependency on testing-cabal
<lifeless> but we do daily builds of them
<lifeless> in ~testing-cabal
<lifeless> so they don't match the 'dont do daily builds' part of your statement
<maxb> "That ~bzr doesn't do daily builds of"
<mgz> yup, I've got it repo'd
<mgz> it is related to the two tests I knew about, not sure which rev where triggered the build failure but it's easy enough to fix the root cause
<lifeless> what is the root cause
<lifeless> maxb: is there any harm having testing-cabal as a dep
<lifeless> maxb: it seems useful to me
<maxb> I've got no problem with adding it back later, but right now I'm aiming to try to fix the sorry state bzr/daily is currently in, for which I need a bzr build which completes successfully
<mgz> the test bt.per_workingtree.test_smart_add.TestSmartAddTreeUnicode.test_accessible_explicit has its expectFailure logic backwards
<maxb> jelmer: Do you have unpushed revisions for bzr-buildddeb/unstable locally?
<jelmer> maxb: you mean lp:bzr-builddeb?
<maxb> oh, sorry, I was confused by the misleading presence of the alioth branch
<maxb> also, ugh, the recipe is set to use {debupstream}+.... - which of course generates bogus versions when the changelog is UNRELEASED
<jelmer> yeah, that should be ~bzr probably
<mgz> gra, testtools still doesn't make debugging this easy, it loses the matcher output
<lifeless> mgz: it doesn't attach it?
<maxb> I'll set the recipe to use 2.7.4+bzr... (literally) for now. that will ensure we don't need to fix it in sync with pushing the next changelog entry
<mgz> nope, never even formats the exception.
<maxb> jelmer: Hi. I see you have a Build-Depends of bzr (<< 2.4.0~beta1-2) | python-bzrlib.tests in bzr-cvsps-import - unfortunately LP's sbuild is too stupid to resolve that - it only tries to install the first alternative
<maxb> Can you see any downside to swapping them around?
<jelmer> maxb: Yeah, I'm working on swapping them right now
<jelmer> seger pinged me about it earlier
<jelmer> I have a test build running atm
<mgz> maxb: okay, I have a fix for you.
<maxb> jelmer: ok. Might be worth making it bzr (<< 2.4.0~beta1-2~) whilst you do (trailing ~)
<jelmer> maxb: to what point?
<maxb> So the condition applies as intended to any backports that exist (like the bzr PPA ones)
<jelmer> that doesn't seem like a particularly worthwile revision to backport (a beta release?)?
<maxb> Not particularly important, no. Just a thought given they need editing anyway
<jelmer> maxb: There was a merge request for the addition of python-bzrlib.tests to debian/control of bzr-builddeb
<jelmer> james_w`: What's the exact policy on reviews for lp:bzr-builddeb?
<maxb> oh, sorry. I was in the "Packaging branch, no launchpad, exercise good judgement" mentality
<AuroraBorealis> so, is this the place we ask about bzr explorer questions?
<bignose> AuroraBorealis: yes, go for it. (I'm not someone who knows though, so can't asnwer.)
<AuroraBorealis> for some reason on windows bazaar explorer wont connect to my ftp server anymore.
<AuroraBorealis> it just sits there on 'starting' and freezes
<poolie> hi spiv, all
<spiv> Hi poolie
<spiv> How's the springy side of the planet?
 * fullermd jumps up and down a bit to check which side he's on...
<poolie> nice thanks
<james_w`> jelmer, trivial -> no review, everything else -> one review, unless you explicitly want more
<maxb> james_w`: and, who constitutes a valid reviewer?
<james_w`> maxb, anyone on the bzr team, myself and people like you who know something about it
<poolie_droid> hi vila
<poolie_droid> thanks for that mail to linaro John
<vila> hi droid :)
 * vila bbl
<vila> So I said, 'Horse?  That looks more like a peanut to me!
 * fullermd applauds.
 * vila giggles
<vila> fullermd: ViewSourceWith tracks the tmp file ! I thought I had to quit my editor but I only need to save... There is a small lag but I'm already getting used to it, this rocks ;)
<fullermd> Yeah, it's Pretty Durn Shiny(tm).
<vila> . o O (Funny that *I* was pushed to use my favorite editor even more ...)
 * vila grins 
<fullermd> Hey, I told you how to set it up to use a good editor instead...  ;p
<poolie> vila, what's ViewSourceWith?
<vila> poolie: a firefox extension that allows you to use your favorite editor for text fields
<fullermd> Firefox extension to let you use $EDITOR_OF_CHOICE for, among other things, View Source and <textarea>'s.
<vila> poolie: perfect fit for reviews
<vila> poolie: most notably because you can still scrolll the page to view the diff and copy/paste excerpts
<poolie> oh right
<vila> rhaaa, don't we have some option listing the warnings one want to ignore ? I can't remember :-/
<vila> ha ! suppress_warnings
<vila> jelmer: hmm, trying to rebuild the OSX-10.5 installer, I got a compile error in subvertpy (tip) in wc.c about svn_wc_conflict_choice_t being undeclared... rings a bell ? want a bug ?
<vila> jelmer: telling me that I need some recent svn version will only make me cry
<poolie> vila i kind of wonder if these WIP mps will be lost
<vila> which ones ?
<vila> poolie: anyway, PP should switch to https://code.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1 when https://code.launchpad.net/bzr/+activereviews  is back under control no ?https://code.launchpad.net/bzr/+activereviews
<vila> which is what we say on http://wiki.bazaar.canonical.com/PatchPilot/
<poolie> for instance the one from Joke
<poolie> just an observation that many of them seem to get lost there
<vila> poolie: if I get feedback I'll finish this one
<vila> poolie: if I don't, well, it's not active anymore ;)
<maxb> jelmer: Hi. Do you want any help adjusting the rest of the python-bzrlib.tests Build-Depends, or would you rather do each one as you upload?
<AfC> Why would upgrade to Natty be forcing me to remove bzr-git ?
<vila> AfC: Because you installed it from something else than the official repos ?
<vila> AfC: in which case you can just re-install it after the upgrade (after re-activating whatever repos you added)
<jelmer> maxb: No, thanks; I doubt it would save much time as I have to process each package anyway.
<vila> naughty naughty loom bug... An AttributeError caused by a missing import and wrongly interpreted higher in the stack as meaning: this is not a loom...
<vila> bzrlib.merge.anything syntax is Evil
<AfC> vila: oh, right
<AfC> I hate how Ubuntu keeps deactivating your PPA list.
 * vila nods
<vila> AfC: but there may be another reason than just that, Ubuntu is pretty "good" at keeping packages so maybe some other dependency triggered that
<vila> python version, whatever
<AfC> We'll see
<vila> loom devs: I'd like to land https://code.launchpad.net/~vila/bzr-loom/tweaks/+merge/60185
<vila> lifeless, jelmer, whoever: ^
<vila> had I filed a bug I would have set it to Critical, but the fix is so trivial I can't bother
<vila> ... and I don't think it's worth searching why it occurred
<vila> if that doesn't wet your appetite I don't what will :)
<jelmer> vila: sorry, missed that earlier. Approved
<vila> done
<vila> jelmer: keep crawling the history back ;)
<vila> jelmer: hmm, trying to rebuild the OSX-10.5 installer, I got a compile error in subvertpy (tip) in wc.c about svn_wc_conflict_choice_t being undeclared... rings a bell ? want a bug ?
<vila> jelmer: telling me that I need some recent svn version will only make me cry
<jelmer> well, either you need a new version of svn or we need to fix a bug in subvertpy..
<jelmer> can you pastebin the traceback?
<vila> jelmer: *compile* error
<vila> err, C compilation error
<jelmer> uhm, sorry :0
<vila> ;)
<jelmer> Can you pastebin the compile error, mr pedantic ? :-P
<vila> isn't subertpy implemented from scratch ?
<vila> hehe
<vila> justasec, different host
<vila> (and no copy/paste linked to *this* one)
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> http://paste.ubuntu.com/604104/
<jelmer> thanks
<vila> jelmer: is it just a matter of ONLY_SINCE_SVN(1, 5) or something more elaborate ?
<jelmer> vila: probably
<jelmer> looking at it now
<vila> ok, thanks
<jelmer> vila: sorry, had to install libsvn-dev
<jelmer> vila: what svn are you using, 1.5?
<vila> jelmer: no idea, it's the default one coming with OSX 10.5 AFAIK
<vila> 'svn help' says 1.4.4
<jelmer> vila: that's really too old for a decent bzr-svn experience..
<vila> jelmer: tsk tsk, I'm not an OSX 10.5 user, only an installer builder ;)
<vila> jelmer: I mean, bzr-svn has been packaged so far and nobody complained, I think there is at least one bug about how hard it is to upgrade svn there and if we should drop it completely, let's do that. But if there is a simple way to keep supporting it for a few more months...
<jelmer> hmm, ok
<vila> We'll drop OS 10.5 support all at once at some point (10.7 is around the corner)
<vila> let me check what is the default on 10.6
<jelmer> I'm happy to fix this build issue for subvertpy, but svn 1.4 has much much worse performance for bzr-svn
<vila> right, I have no doubt about that ;)
<vila> err, both points !
<vila> bah
<vila> 1) thanks for fixing it, 2) no doubt about the perfs
<vila> svn 1.6.15 on OSX 10.6
<vila> jelmer: so, IIUC, subvertpy wraps libsvn and as such depends on it for providing features. Does that mean some features will not be available on OSX 10.5 or only that they will be slower ?
<jelmer> vila: some features in subvertpy won't be available, but bzr-svn works around that by using slower code paths
<jelmer> and in some cases subvertpy provides the extra functionality if it can
<vila> jelmer: wft (t == them ;) then
<jelmer> :)
<jelmer> vila: pushed a fix, can you try with current trunk?
<vila> huh, no revisions to pull
<vila> revno 2333
<vila> jelmer: ^
<jelmer> vila: I think lp:subvertpy is a mirror, try http://people.samba.org/bzr/jelmer/subvertpy/trunk/
<vila> damn cached parent_location
<vila> jelmer: that fixes the first compilation error
<vila> err, not even wait
<vila> hmpf
<vila> jelmer: http://paste.ubuntu.com/604131/
<vila> jelmer: i.e. one typo and a different error
<vila> ha, shooting in the dark sometimes works :)
<vila> s/2/3/
<jelmer> vila: fixed
<vila> yup, I trust your fix more :) Using svn_wc_resolved_conflict3 (instead of 2) was compiling too but was probably not producing the right code ;)
<vila> and it compiles fine
<vila> jelmer: thanks
<jelmer> vila: according to the header _conflict3 is only available in svn >= 1.5
<vila> ...
<pindonga> hi, I was wondering.. I want to modify the lp-propose command to include some extra options... what is the best way to approach this for inclusion? shall I just submit an MP, or should I first discuss with someone if the changes will ever be approved first?
<vila> pindonga: MP is best, even to *start* a discussion, IRC logs are << MPs threads
<vila> pindonga: I'm not saying you should create a MP with no patch at all either ;)
<pindonga> vila, no, sure, I have the mp almost ready
<pindonga> but no tests yet :)
<pindonga> I'll submit it later, and let you know
<vila> pindonga: ha, not TDD-addict yet :)
<maxb> jelmer: When you touch bzr-colo for the Build-Depends fix, it looks like it's erroneously Architecture: any as well
<maxb> Hmm, oneiric's python-subunit is broken, it's built only for python 2.7, not all supported versions
<pindonga> vila, sorry to bother, I'm trying to find out where the tests are for the launchpad plugin
<cbz> jelmer: just sent in a bug report https://bugs.launchpad.net/bzr-svn/+bug/778793
<ubot5> Ubuntu bug 778793 in Bazaar Subversion Plugin "Unexpected import error on importing svn branch" [Undecided,New]
#bzr 2011-05-07
<AuroraBorealis> is anyone here this time? third time is the charm? =/
<bob2> best to ask'n'idle
<bob2> (or try the list)
<AuroraBorealis> ive been doing that for the past 3 days haha
<bignose> AuroraBorealis: such a long wait would motivate me to join the mailing list and ask there.
<AuroraBorealis> it seems like such a stupid problem to begin with i dunno if any mailing list would help me
<AuroraBorealis> the program (bzr explorer) works but it just hangs on 'starting'
<AuroraBorealis> but i may try that. i hate windows :<
<IbIro> Hey
 * jelmer waves
 * bialix waves back
<bialix> vila: ^-D
<bialix> vila: :-D
<vila> bialix: Isn't it nice when people just ping you for a smile :D
<bialix> I'm reading your mail
<vila> bialix: by the way, I'm about to announce 2.4b2 (I'm very late for that already), any news about the windows installers ?
<bialix> no news from Gary unfortunately :-(
<bialix> I've sent him a mail, but have no response
<vila> ok, thanks for the feedback anyway
<bialix> I'll try to hack existing 2.4b1 installer and make something like 2.4b2. but only tomorrow or on monday
<bialix> btw, this monday is big holiday: Victory day
<bialix> and 1 year passed since we met at uds
<vila> bialix: Happy birthday !
<bialix> ?
<bialix> I'm puzzled
<vila> bialix: 1 year since we met physically ;)
<bialix> yea
<bialix> sorry for the bottle
<vila> hehe
<bialix> vila: I'm going to add FEATURES dictionary to qbzr. As the way to get other code (e.g. bzr-explorer) to know that some features exists in the installed version of qbzr
<bialix> do you think this can be interested for bzr?
<bialix> if so I'll send my thoughts to list, or we just can talk here
<bialix> and side joke: Marius has shown me very good band, they have nice song about PPA: http://www.youtube.com/watch?v=xjCsBK55X9Y :-)
<vila> bialix: as a way to formalize getattr(module, 'function/method', None) ?
<bialix> vila: sort of
<bialix> some methods get new arguments and this can be important
<vila> PPA, nice music...
<bialix> so, inspecting FEATURES dictionary external code can see whether required feature present (new code, new arguments, etc) and work accordingly
<bialix> Tamacun is very nice too
<vila> I'm +-0 there,
<vila> it seems we tried many variants without really achieving the desired result,
<bialix> well, version number does not work if new feature has landed in the middle of the cycle
<vila> well, I can live with that
<bialix> there was discussion about versioning API, but it'' become hell very soon, IMO
<bialix> okay, then I won't worry to spam the list
<vila> bialix: on the contrary, my remark was more to tell you I don't feel like the good public for this discussion, but it's still an open subject worth discussing
<bialix> ok, I see
<bialix> I'll try to dogfood it inside qbzr for some time, and if I'll have some godd result then will present to the bzr MKL
<bialix> ML
<vila> sounds like a good plan
<bialix> vila: I've just realized that my features dict is like hard-coded config in qzbr. I'm not sure yet what it'll imply
<vila> well, it better stays hard-coded no ? If only to avoid highly confusing errors if the code and an external config file become out-of-sync
<bialix> yep, it's hard-coded. but it looks like a config
<bialix> vila: http://groups.google.com/group/qbzr/browse_thread/thread/d26bcb73fb3c6b9 maybe this explanation will be better
<vila> bialix: hehe, yeah, you get the idea, configs are just dicts :)
<bialix> vila: :-)
<vila> bialix: and... I'm pretty sure there are ways to make read-only dicts in python (so you'll have to worry a bit less about people breaking stuff there)
<bialix> vila: I don't remember off hands, in the future I may change it to use special class
<poolie> vila, hi
<poolie> great mail :)
<vila> glad you liked it, I was inspired yesterday evening but had to stop as V. was waiting ;)
<vila> poolie: I think spiv found the right metrics there too so that was fun to write around them
<poolie> :)
 * bialix waves at poolie
<poolie> hi there bialix
<bialix> have you seen Budapest? I haven't been there, but my mother has, and she said it's nice  city
<poolie> i have a little
<poolie> i might go out for a walk later today
<bialix> :-)
<poolie> it's very green and pleasant now
<poolie> http://www.flickr.com/photos/mbp_/5692151369/in/photostream
<bialix> hope there's no snow ;-)
<poolie> not exactly
<bialix> vila: if you have 5 minutes, please update version number on bazaar.canonical.com
<bialix> it's really should be automatic stuff
<vila> bialix: rhaaaaa, thanks for the heads-up
<vila> bialix: fixed
<bialix> :-)
<vila> bialix: as in: fixed in source and pushed, the site will be updated ... by a cron job but I don't remember the frequency
 * bialix nods
<vila> poolie: woooow, now that's some nice place...
<poolie> vila,  that's not actually where i'm staying ;)
<vila> hehe, yeah, I figured ;) But still, nice stones
 * jelmer waves
<BlindWolf8> Hello all
<BlindWolf8> I am having an issue with Bazaar 2.3.1
<BlindWolf8> Can anyone here help me with it?
<jelmer> hi BlindWolf8
<jelmer> BlindWolf8: Please ask your question, if there's somebody who knows what the problem is they can answer
<BlindWolf8> Hi!
<BlindWolf8> OH great!
<BlindWolf8> I am in the middle of something, so it's important that I get an answer quickly
<BlindWolf8> I have a server which is Linux, it's running Bazaar 2.3.1
<BlindWolf8> and so are all my clients
<BlindWolf8> When I commit a file that is around 37 MB or so, bazar doesn't commit the file...it stops with an error message
<BlindWolf8> The mesage is "unexpected end of message"
<BlindWolf8> I'm using the bzr+ssh protocol
<BlindWolf8> everyone has bound branches
<jelmer> it's reproducible oin all clients?
<BlindWolf8> i have reproduced the issue on my computer as well as another client
<BlindWolf8> Any help is appreciated
<BlindWolf8> I've tried changing timeouts, etc. on sshd on the server, but no luck
<BlindWolf8> I am able to commit the file localy
<BlindWolf8> and it's one particular file
<BlindWolf8> *not one
<BlindWolf8> any file that seems to be over or close to that size causes said issue
<jelmer> please file
<jelmer> please file a bug about this - I don't have any immediate ideas but other developers might, there usually aren't a lot of people around in the weekend though
<jelmer> we're certainly aware of problems with big files - but that's usually files that are a couple of hundred megabytes, not 37Mb
<BlindWolf8> Thanks!
<cbz> jelmer: what version of bzr-svn do you want me to retry the svn import with?
<cbz> jelmer: i've got bzr 2.3.1 installed and am using the default there
<cbz> jelmer: looks like 1.0.5
<jelmer> cbz: bzr-svn trunk
<jelmer> cbz: Ah, you're using the Mac installer? I think that uses a bzr-svn snapshot from a while ago
<cbz> windows installer
<cbz> okay, will retry
<ScottK> jelmer: Will you be at UDS this time?
<jelmer> ScottK: Yep, poolie and I are both attending
<ScottK> Great.  I will see you there then.
<jelmer> cool :)
<ScottK> Watch out for this new guy you got on rotation from the disto team.
<ScottK> ;-)
<jelmer> :)
<rsingh> hello everyone
<rsingh> question: when i push my code to the server, now i have various statements like <<<<< TREE in some of my docs, and i'm wondering how to remove them, as I'm new to bzr and the push/pull functionality
<rsingh> anyone?
<jelmer> hi rsingh
<jelmer> rsingh: those<<< markers are the indication of conflicts during pull/update/merge
<jelmer> it happens because the person you pulled from had a different change to the same lines as you did
<jelmer> time to catch my train, back later
<rsingh> belated thanks, jelmer
#bzr 2011-05-08
 * jelmer waves
<tbf> what's the equiv of "git add -p" in bzr?
<tbf> that is: how do i add only parts of a file's changes to the index?
<vila> tbf: Hmm, there is no index in bzr, but you should be able to shelve the changes you don't want to commit with 'bzr shelve --interactive'
<tbf> vila: thanks. reading docs for "bzr shelve"
<tbf> vila: seems to work. thank you
<vila> tbf: Always happy to help ! (TM jam)
<tbf> vila: sorry for asking another stupid question: is it possible to edit commits? forgot to call "bzr whoami" and want to change the commiter id
<vila> tbf: you can't edit commits, but you can 'bzr uncommit' ; 'bzr whoami "<yes, really me@example.com>"', bzr commit (for the last commit)
<tbf> vila: "bzr uncommit" keeps the files?
<vila> tbf: The 'I forgot whoami' trap is known :-/
<vila> tbf: bzr uncommit don't touch any user file, it just move the branch pointer back so the changes are ready to commit
<tbf> vila: thanks. together with bzr shelve i managed to correct the log :-)
<vila> tbf: great, that's the best way to fix that today, we're working on better ways... (Both in preventing the user to forget the whoami and re-recreate commits with a fixed one)
<tbf> vila: well, actually had $EMAIL set for devscripts and git... so bzr is not really to blame.
<vila> Huh ? EMAIL has not be recognized ? That's a bug !
<tbf> vila: my fault to use the other dvcs without rtfm :-)
<tbf> vila: it is recognized but mentions my work email address
<vila> haaa
<vila> So you *did* configure the other dvcs then ? ;)
<tbf> vila: now it becomes tricky. whom's "other dvcs"? mine or yours? :-D
<vila> hehe
<vila> tbf: Since you introduce the term, you have to define it ;)
<vila> tbf: jokes aside, with "other_dvcs != bzr", how did you specified your email ?
#bzr 2012-04-30
<nilg`> hi, how to set append-revisions-only otherwise than at init?
<spiv> With bzr config
<spiv> Something like 'bzr config append_revisions_only=true'
<nilg`> thanks a lot!
<nilg`> spiv: I've done that on my local branch but how do I do the change on the global one?
<nilg`> when I try to commit it tells that there is no change to commit
<nilg`> same thing when I try to push
<LarstiQ> nilg`: you can do `bzr config -d bzr+ssh://server/path/to/remote append_revisions_only=true`
<nilg`> awesome, thx
<LarstiQ> nilg`: and then when you try to push a change that would reorder commits, you'd get: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/tmp/foo/".
<LarstiQ> nilg`: do you know the `bzr missing` command btw?
<nilg`> nsoi010
<nilg`> wrong window...
<nilg`> useful thanks
<nilg`> hmmm, it didn't work, I can still "violate causality"
<LarstiQ> nilg`: ok, how did you do that?
<LarstiQ> nilg`: does `bzr config -d remote/branch` show append_revisions_only is correctly set?
<nilg`> it seems so
<nilg`> locations:
<nilg`>   [lp:opencoglp:opencog]
<nilg`>   append_revisions_only = True
<nilg`>  
<nilg`> then I branch a revision before
<nilg`> bzr branch -r6777 opencog opencog_r6777
<nilg`> (opencog contained lp:opencog actually)
<nilg`> then committed something so it reaches revision 6778
<nilg`> then bzr merge
<nilg`> then bzr commit -m "merge"
<nilg`> and finally bzr push lp:opencog
<LarstiQ> nilg`: what did you merge where?
<nilg`> now the last commit of the trunk (that was at 6778) has been replaced by my fraudulent commit at r6778 as well + the merge
<LarstiQ> I see
<spiv> Huh
<spiv> append_revisions_only in locations.conf?  I'm not sure that works
<spiv> It's a branch.conf thing
<LarstiQ> spiv: aah
<LarstiQ> vila: do you recall config issue with setting branch.conf on lp: ?
<spiv> (You may also need to double-check I got the config option name correct, I'm not sure how careful 'bzr config' is to warn)
<LarstiQ> spiv: I tested that part locally, it works
<nilg`> bzr there's something weird with the tag
<nilg`> [lp:opencoglp:opencog]
<nilg`> see the snippet of bzr config -d lp:opencog that I pasted above
<spiv> nilg`: yes, that's funny too
<nilg`> ho, lol, I wanted to say BTW, not bzr
<spiv> nilg`: anyhow, try, 'bzr config --scope=branch ...'
<spiv> nilg`: (after all, you presumably want this set for everyone using the branch on LP, not just for yourself)
 * spiv -> afk
<vila> LarstiQ: well, yeah, but 2.5.0 should have all the fixes
<nilg`> spiv: in for everybody
<vila> the section name is indeed weird but that means it shouldn't apply to *any* branch
<vila> what does 'bzr config -d lp:opencog' display ?
<vila> (I don't think lp:opencog is even a valid section name....)
<nilg`> "section name"?
<vila> [<section name>]
<nilg`> here's the output of bzr config -d lp:opencog
<nilg`> http://pastebin.com/iRpKwqhB
<vila> right
<vila> so, this means 'bzr config' doesn't interpret lp:opencog *at all*,
<nilg`> so I guess a fix of that would be to take the bzr+ssh... address, right?
<vila> there is no 'branch:' part and locations.conf is matched just because the substring appears in the section name
<vila> yup
<vila> but as spiv mentioned, you'd better set append_revisions_only in the relevant branch.conf
<LarstiQ> right
<LarstiQ> nilg`: so for now a workaround is to do that with hitchhiker
<LarstiQ> vila: unless you have a better idea on how to get it set on launchpad?
<vila> huh ? If nilg` has write access to the branch, 'bzr config -d bzr+ssh://...' should work just fine
<nilg`> vila: you mean no need of --scope=branch?
<nilg`> I do have write access
<LarstiQ> ok, so just not use the lp: shorthand
<vila> yup, by default branch.conf is where the modifications go
<vila> LarstiQ: yup
<LarstiQ> and I see bug 957049 is already filed
<ubot5> Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049
<vila> LarstiQ: ha damn, my memory is flaky coming back from vacations ;(
<nilg`> bzr config -d lp:opencog is still given me the same output
<LarstiQ> vila: I know the feeling
<nilg`> even if I set it to false
<vila> nilg`: don't use the lp: shortcut
<LarstiQ> vila: any idea how to tackle the bug?
<nilg`> http://pastebin.com/ApAA7EEg
<nilg`> oh, sure...
<LarstiQ> nilg`: right, so `bzr config -d bzr+ssh://bazaar.launchpad.net/+branch/opencog/`
<LarstiQ> should now show it
<nilg`> it does ;-)
<LarstiQ> good, good :)
<LarstiQ> nilg`: ok, so toggle to true, try the merge test again?
<nilg`> so before (with lp:opencog) I was writing somewhere else?
<LarstiQ> I'm confident that will work, but better safe than sorry
<LarstiQ> nilg`: yeah, to ~/.bazaar/locations.conf
<LarstiQ> ehm
<LarstiQ> if I'm not mistaken
<vila> LarstiQ: from the top of my head, it probably means url aliases should all be tried to match but there are probably nasty fallouts
<LarstiQ> vila: ok
<nilg`> just to be sure (before I try) http://pastebin.com/BxrAS8vY
<LarstiQ> nilg`: that looks good
<nilg`> woohoo
<nilg`> bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "chroot-66248080:///%2Bbranch/opencog/".')
<nilg`>  
<nilg`> it works, thanks a lot guys
<LarstiQ> nilg`: sorry it took so long
<LarstiQ> nilg`: for the record, which bzr version are you using?
<nilg`> Bazaar (bzr) 2.5.0
<nilg`>  
<LarstiQ> ok
<nilg`> I can paste the whole output on pastebin if you want
<LarstiQ> nilg`: nah, just wanted to make sure I'm not looking at the wrong version of the code for bughunting
<vila> nilg`: what would be even better is to https://bugs.launchpad.net/bzr/+bug/957049/+affectsmetoo and explain that the bug leads to a confusing behavior
<ubot5> Ubuntu bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed]
 * LarstiQ runs the testsuite with a 'directory = directory_service.directories.dereference(directory)' thrown in
<mgz> morning all!
<mgrandi> morn
<LarstiQ> hey mgz, mgrandi
<vila> mgz: o/
 * vila upgrades his last desktop to precise
<mgz> vila: when you're done with the upgrade, LarstiQ wants some help writing a config test, see bug 957049 mp
<ubot5> Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049
 * vila nods @ mgz, LarstiQ
<LarstiQ> vila: cheers. I keep not knowing what to do with the mps, should I resubmit, ask for a new review on this one, submit an entirely new one?
<vila> LarstiQ: I think mgz landed it so wait for it to land and submit a new one
<mgz> has landed, so a new one is fine
<LarstiQ> k, just a moment
<mgz> generally in response to review comments, just pushing up to the same branch and saying what you've changed in comment is fine
<LarstiQ> mgz: except if it has already landed?
<mgz> right, but you could still use the same local branch and just push it to a new location on lp
 * LarstiQ nods
<LarstiQ> mgz: or well, I'm even using the same branch on lp for https://code.launchpad.net/~larstiq/bzr/xdg-config/+merge/104078
<LarstiQ> and after this I'm _really_ getting lunch :)
<vila> LarstiQ: wrong target for the proposal ;) You want 2.5 not trunk ?
<LarstiQ> vila: doh, you are right
<vila> LarstiQ: sorry about that ;)
<LarstiQ> vila: np. Just a sec while I retarget
<LarstiQ> vila: done
<mgz> vila: that branch failed on pqm, or there was some other issue?
<vila> let me check
<vila> hmm, no mail...
<vila> ha, damn laptop
<vila> the mail was blocked locally
<vila> unblocked
<natosha> Hello.  Is there a more detailed developers guide than http://doc.bazaar.canonical.com/developers/HACKING.html ?  Specifically, I am trying to figure out how, internally, Bazaar manages to so gracefully handle case collisions while merging.
<natosha> I thought I'd ask here if there is more detailed documentation before starting to look at the source.
<wgz> natosha: try <http://doc.bazaar.canonical.com/developers/case-insensitive-file-systems.html>
<natosha> wgz, thanks, that gets me closer
<james_w> maxb, hi, did you re-enable the cron job?
<maxb> I did
<maxb> I should have emailed about that
<james_w> thanks
<james_w> np
<james_w> I went to do it and saw it was already done, so wanted to check it was you, or that you knew about it
<maxb> We appear to have a new failure kind spiking, unfortunatly
<maxb> It looks to me like a bug in bzr-builddeb
<maxb> We get a LockContention during a set_tag operation, when it's trying to tag a new upstream version
<maxb> I'm assuming someone's done something wrong with locking conventions surrounding use of a DistributionBranch
<james_w> I don't remember any recent changes related to that though?
<maxb> But I've had a hard time figuring out exactly what the intended use is, regarding the two trees and two branches you instantiate a DistributionBranch with
<james_w> not that I've inspected all the changes closely
<maxb> I don't either, but we're definitely seeing the rise of a new failure signature
<james_w> yeah
<james_w> "only" 80 instances, but that's probably just those that have had an update right?
<maxb> Looks like it. Or, it may only be happening when the importer does a temporary re-import to test a collision
<LarstiQ> newly exposed failure case maybe?
<maxb> Quite possibly a codepath walked more in assessing branches newly copied to a new series
<james_w> is Branch.lock_write() re-entrant?
<maxb> If it's re-entrant at all, it would only be on the same Branch object
<james_w> yeah
<james_w> I'm wondering if it's that we're calling it twice, or that we have two references to the same branch
<jam> james_w: lock_write and lock_read are concurrent (you can call lock_read on a branch which is in lock_write state, but you can't call lock_write if it started as lock_read)
<james_w> jam, what about two lock_writes?
<jam> james_w: fine as long as it is the same object, yes
<james_w> thanks
<mgz> you're meant to be queening jam!
<LarstiQ> hah :)
 * mgz isn't sure what this involves, something strange and dutch
<LarstiQ> mgz: with markets starting at 5 or 6 in the morning at this time of day it's enough to relax :)
<mgz> ...getting up at 5 or 6 to go shopping doesn't sound like a holiday
<LarstiQ> mgz: http://en.wikipedia.org/wiki/Koninginnedag#Activities has some hints
<LarstiQ> mgz: shopping? Selling! :)
 * LarstiQ heads home
<mgorny> is the size information while bzr fetches accurate?
<mgorny> because I fail to understand why it downloads 740M (and time it takes suggests it does that indeed) while the resulting repo takes 140M
<lifeless> what network protocol are you using ?
<mgorny> lp:s25rttr
<mgorny> no firewall so I guess whatever the default is
<lifeless> mgorny: so that could be either ssh or http depending on whether you've done 'bzr lp-login'
<lifeless> erm, that might be bzr launchpad-login, I forget.
<mgorny> no login
<lifeless> so, its going over HTTP
<mgorny> and it seems to clone the repo via bzr branch
<lifeless> which means its basically doing a virtual file system access to the branch data.
<lifeless> logging in should make it massively faster.
<lifeless> the repository may well need a pack as well, if its currently bloated at 700M
<mgorny> bzr does autorepack after fetching?
<mgorny> the proto seems to be very suboptimal
<mgorny> and logging in is not a case, unless we're going to force random no of Gentoo users to create launchpad accounts
<lifeless> why would random no of gentoo users be branching in the first place ?
<mgorny> because of random no of upstreams using bzr for their programs, and users fetching sources then
<lifeless> would tarballs work better for you ?
<mgorny> for me yes
<mgorny> I was mostly wondering whether we are doing something wrong
<mgorny> I'm a git person and it looks weird to me to use 'branch' command to clone a repo
<mgorny> but if it's upstream no-repack fault or proto limitation, I guess we can't do much
<mgorny> just replace live-source ebuilds with snapshots
<lifeless> so the smart streaming protocol is much more efficient
<lifeless> http://bazaar.launchpad.net/~flosoft/s25rttr/trunk/tarball/head:
<lifeless> should get you a tarball
<mgorny> sadly, that won't work for us
<mgorny> because tarballs have to be manifested with checksums
<mgorny> and live tarballs = live checksums
<mgorny> but we'll try to find something
 * mgorny will just run a cruciate for git :P
<lifeless> so the tarball is 40M
<lifeless> much less data
<lifeless> you could create an account for gentoo downloads, with a single shared ssh key, and share that around; a bit awful, but as long as that was never given write privileges probably tolerable
<mgorny> yes, though about that too. if it's launchpad tolerable then it's probably worth considering. i'd ask someone first to check whether that actually benefits us, however.
<mgorny> thanks for the patience.
<lifeless> we have a requested feature to run the streaming protocol over http
<lifeless> but noone has had the time to glue it all together.
<lifeless> the repository is a bit poorly packed atm, but not -terrible-
<lifeless> I'd file a bug on bzr, 700M is unreasonable given the size of repository.
<lifeless> mgorny: ^
<mgorny> ok. I'll just try to get someone to reproduce that first however/
<mgorny> thanks. I'll file it tomorrow or the day after tomorrow. good night.
<lifeless> cool
<maxb> We have a nasty bug in the Launchpad packaging branch uptodate check that's going to bite everyone accessing a precise branch of anything
<maxb> Apparently the packaging uptodate check doesn't follow stacking properly
<fullermd> Lucky for me I only ever deal with vague branches.
#bzr 2012-05-01
<dust_o> i'm in a pickle. i did a commit, for the sake of example, to a revision 2. then did a push. then discovered i would like to revert to previous revision 1. so did a 'bzr uncommit' and a 'bzr revert'. however, launchpad still shows revision 2 for the project. if i try to then add a new revision 2, bzr complains about divergent branch. cannot figure out how to unpickle myself.
<mwhudson> dust_o: push --overwrite
<dust_o> thank you so much!
<dust_o> oh man. can i buy you a pizza or something?
<mwhudson> heh, i can cope :)
<dust_o> well, thank you. was a'feared for my job 8) hehe
<maxb> Is there anyone who actually understands builddeb's DistributionBranch?
<maxb> I'm currently annoyed with it because its comments apparently lie
<jelmer> maxb: hi
<maxb> hi
<jelmer> maxb: sure, I have a vague idea of what it does
<maxb> So, DB claims :
<maxb>         You can only import packages on to the DistributionBranch
<maxb>         if both tree and pristine_upstream_tree are provided.
<maxb> But the main UDD codepath doesn't do that, and I'd venture to say it generally imports packages :-)
<jelmer> yeah, the pristine tree is no longer strictly necessary IIRC
<maxb> The other thing I'm having problems with is understanding why various callsites pass 1 branch / 2 branches / 2 branches + 1 tree / 2 branches + 2 trees
<maxb> "Tree or not" makes sense - am I going to be importing things
<maxb> Also, the only non-test callsite which passes 2 branches which aren't the same branch object appears to be UDD's check_same
<jelmer> maxb: the two branches are the packaging brnach and the pristine source branch
<jelmer> which often aren't the same thing
<maxb> They appear to be the same thing in every callsite I've found apart from check_same
<maxb> And in that callsite they're merely a scratch empty branch in both cases
<jelmer> the tip of the pristine tar branch can matter in some cases
<maxb> *ah* pristine_upstream_tree sometimes gets assigned via extract_upstream_tree not via the DB __init__
<maxb> although when that happens, pristine_upstream_source doesn't get updated equivalently
<maxb> Oh, except PristineTarSource genuinely doesn't use its self.tree at all
<maxb> I wonder if we could remove that, or if it's immutable API at this point
<jelmer> maxb: we can't, not without a lot of refactoring
<jelmer> maxb: I've tried in the past
<maxb> Refactoring in which projects?
<jelmer> bzr-builddeb
<maxb> Oh, you mean because its needed as part of the contract of an UpstreamSource, but not otherwise?
<maxb> no, that doesn't make sense
<jelmer> hmm, actually - it looks like my changes actually landed
<jelmer> so I think it can indeed go
 * maxb asks the tests what they think :-)
<maxb> I wonder if DistributionBranch is used anywhere but builddeb and udd - i.e. what leeway we have in API changes
<maxb> builddeb's tests pass with PristineTarSource's tree removed
<maxb> To double back to an earlier point: "the two branches are the packaging brnach and the pristine source branch which often aren't the same thing" - do you know of an example?
<maxb> oh this is getting horrit
<maxb> After an extract_upstream_tree, DB.pristine_upstream_branch has changed into the result of sprouting from itself
<maxb> I wonder if I could make it so that DistributionBranch __init__ took a single mandatory branch and a single optional tree ONLY
<maxb> Hmm. It almost looks as if a tree.lock_write() and a branch.lock_write() are conflicting
<maxb> But for that to happen, the tree would have to be pointing at the same on-disk branch via a different Branch object, wouldn't it?
<maxb> Time to set up a staging importer with some extra logging, I guess
<maxb>         # Should we just dump the upstream part on whatever is currently
<maxb>         # there, or try and pull all of the other upstream versions
<maxb>         # from lesser branches first? For now we'll just dump it on.
<maxb>         # TODO: this method needs a lot of work for when we will make
<maxb>         # the branches writeable by others.
<maxb> lovely
<mgz> morning
<jam> mgz: /wave
<mgz> who's handling contributor agreements for bzr atm?
<fullermd> NFC.  I'd guess it would be either jam or jam would know, so...
<mgz> I shall squish the jam tomorrow.
<david0rk> Hi all
<jelmer> hi david0rk
<david0rk> Hi Jelmer
<david0rk> are you familiar with bazaar?
<jelmer> david0rk: sure
<david0rk> I've got launchpad setup (account, rsa_pubkey, ssh key)  and i've set a folder on my pc as a bazaar tree.
<david0rk> Now I just need to figure out how to get my sourcecode in bazaar, and push to launchpad.
<david0rk> nevermind.  I figured out using a bit of common sense and tinkering.   BAZAAR IS AWESOME!
#bzr 2012-05-02
<lduros> hello: is there a way when running bzr log to have a less-like pager
<lduros> akin to git log?
<lduros> it's dumping the whole revision log
<lduros> currently
<lduros> i'm using bzr qlog
<lduros> but it would be nice to be able to do something like that from the terminal :-)
<bob2> you can pipe to less
<bob2> or there's a plugin
<lduros> bob2: ok
<lduros> bzr log | less
<lduros> :-P
<lduros> obviously... thanks
<fullermd> Heh.  Just found a dirstate branch/repo lying around.
<mgrandi> oh?
<fullermd> It's probably not the only one.  But it's been some years since the last one I found.
<mgrandi> what is a dirstate branch/repo
<lifeless> fullermd: a branch to hack on dirstate, or a dirstate one ? and by dirstate do you mean packs ?
<fullermd> lifeless: The latter.  And no, straight-up knits.
<lifeless> mgrandi: dirstate is the codename for the working tree metadata file format.
<lifeless> fullermd: wwwwin
<fullermd> I sure hope I don't have any weaves still around.
<mgrandi> ah
<fullermd> mgrandi: Basically, a really old format.
<fullermd> I think it basically proves that my $HOME is a dangerous neighborhood that it's best not to wander around in...
<vila> hi all
<mgz> morning!
<jelmer> hey mgz
 * mgz wombles around
<vila> hey jelmer, mgz !
<jml> ehy
<jml> is there an easy way to get the diff between a merged revision and the tip of the branch that it merges in?
<jml> I mean, bzr log -n0 -r $MERGE_REV will get me the tip of the branch's revno
<jml> and then I can do a diff
<mgz> do you mean like `bzr diff -r mainline:2.1.1` for instance?
<mgz> I'm not quite sure which two revisions you want the diff between
<mgz> jml: in your example, what is $MERGE_REV and what is the final diff command you run?
<jml> umm...
<jml> lp:subunit r165 is where lifeless merged a branch of mine in, making changes first
<mgz> ah, that's the painful case then
<mgz> you want to see what lifeless did right?
<jml> bzr log -n0 -r165 |head to get the tip revision of my branchh
<jml> mgz: yeah
<jml> which turns out to be 162.2.26
<mgz> there's no general case that works for that.
<jml> and then bzr di -r 162.2.26..165
<jml> mgz: because bzr allows arbitrary numbers of revision parents?
<mgz> because you get the 163..164 changes mixed in as well
<jml> ah
<mgz> that's okay when the branch merged is pretty fresh
<mgz> (or when you merge trunk like you did there)
<mgz> I'm not seeing any way of getting to r162.2.26 from r165 either though.
<mgz> given there may be more than one (left hand? I forget the term) parent, I'm not sure there is a command line way
<lifeless> jml: difftastic
<lifeless> mgz: ^
<lifeless> abently wrote the general case as a plugin
<mgz> lifeless: where is this to be found? <https://launchpad.net/+search?field.text=difftastic> doesn't help.
<lifeless> https://launchpad.net/difftacular/trunk
<mgz> ah, difftactular
<lifeless> wrong name
<lifeless> doesn't stick in my head for sime reason
<mgz> leonardr happened to make the same slip in that review
<jml> heh
<lifeless> it might be nice to put that in the bzr plugin register, add to the bazaar project etc, but talk to abentley
<lifeless> (it may be already, I dunno)
<lduros> every time I commit using VC in emacs (C-x v v) or do bzr commit, it pushes in the same time to the remote branch
<lduros> how can I prevent that? :-)
<mgz> unbind your local branch
<jml> how do I set the public location of a branch?
<lduros> mgz: ok
<lduros> bzr unbind ... so easy :-)
<mgz> lduros: you might instead want to work in feature branches, then merge them in to the bound trunk and commit when done
<lduros> I don't see why ppl love git so much
<lduros> mgz: hmm, that might make sense
<mgz> jml: there's a config command that works I think, sec
<mgz> people love git because dvcses are great
<mgz> jml: `bzr config public_branch=lp:foo`
<lduros> mgz: it's like saying people only like apples, but in fact what they like in the apple is the concept of fruit?
<mgz> with the caveat I'm not sure lp: actually works depending on when it gets resolved to bzr+ssh: exactly
<mgz> lduros: yup, but apples are all they have growing in the garden
<lduros> :-P
<lduros> and it's one of the fruits with the most pesticides
<lduros> bzr is more like organic strawberries
<jml> mgz: ta
<jml> mgz: I always forget which has _branch and which has _location
<vila> jml: just use 'bzr config' and you get them all
<mgz> vila: only if it's already set...
<vila> rhaaa, public, sry
<LarstiQ> jml: yeah, it would be nice to clean _branch vs _location up
<pikkachu> when you're about to merge an old branch, do you merge upstream changes into the old branch first, or do you just merge the old branch directly?
<mgz> pikkachu: generally just merge the old branch directly and resolve any conflicts
<mgz> for some landing systems (like pqm which lp:bzr uses) you want to merge trunk first because the landing robot isn't smart enough to handle conflicts
<pikkachu> ok thanks
#bzr 2012-05-03
<maxb> AHA
<maxb> Got it
<maxb> The reason all those UDD imports are failing with LockContention is because branch.bzrdir.open_workingtree() gives you a tree whose tree.branch isn't the same branch as the original
<maxb> Which isn't unreasonable given the indirection via bzrdir
<LarstiQ> maxb: do you need the actual tree in that location? If so, can't you start with it?
<lifeless> maxb: thats actually deliberate
<lifeless> maxb: keeps the core simple, lets folk do clever things if they need to.
<mgz> morning all!
<LarstiQ> hei mgz
<maxb> LarstiQ: The code flow is such that we already have the branch open when it becomes relevant to want the tree too - at least, without restructuring it a bit
<maxb> lifeless: Yes, "... isn't unreasonable ..." = me being happy with bzr core's behaviour
<LarstiQ> maxb: and branch.basis_tree() is not sufficient?
<lifeless> maxb: cool cool
<mgz> ...I missed the context while on bus, this is about relocking issues with new branch objecT?
<maxb> Needs to be a WorkingTree
<LarstiQ> mgz: yeah, 01:50:14 < maxb> The reason all those UDD imports are failing with LockContention is because branch.bzrdir.open_workingtree() gives you a tree whose tree.branch isn't the same branch as the original
<maxb> Yes, a LockContention happens because udd has accidentally aliased the branch object
<LarstiQ> jam: if you have some spare cycles, mind having a look at bug 541626 and whether lp:~larstiq/bzr/bug541626 heads in the right direction?
<ubot5> Launchpad bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] https://launchpad.net/bugs/541626
<mgz> can you preserve the token from the original lock operation and pass it in when locking the new branch?
<mgz> not ideal, really don't want multiple branch objects for the same location
<maxb> preserving the token isn't an option - too many layers of code in the way
<mgz> hm.
<maxb> It's a bit annoying that there isn't a way to open one kind of object from its siblings
<maxb> I suppose I'll just rearrange the code in UDD so it can open the WT first and get the Branch from the WT object
<mgz> that's what I've done in the past, does feel like there should be a better method
<mgz> sometimes you always want the branch but may or may not want the tree
<vila> hi all
<LarstiQ> moin vila
<lifeless> maxb: tree's can't do their thing w.o the branch though
<lifeless> maxb: which is why opening the tree implies opening the branch
<lifeless> it might be interesting to try having a tree with no operations that need a branch, and branch w none that need a repo
<lifeless> I wonder what that would look like
<lifeless> e.g. what would 'do a commit' look like.
<maxb> lifeless: The issue is, I have a Branch already open, and I really want to just open a WorkingTree using my already open Branch
<maxb> Instead, I'm going to have to close my Branch, and open a WorkingTree, which will re-open the branch
<lifeless> you could keep your branch, and open a working tree
<lifeless> the issue AIUI is that you have the branch write locked.
<lifeless> which is rather separate.
<mgz> multiple objects are still an issue for other reasons. is branch.repository shared at least?
<mgz> if not, you also have two sets of caches.
<lifeless> there is a facility to pass in existing transports to various opens()
<lifeless> you could extend that for live objects too; though it would depend on url equivalence
<maxb> I am keeping my branch and opening a working tree - this results in the branch (and repository) being re-opened
<mgz> right, just checked, the repo isn't shared either, that's bad.
<mgz> and I don't like the idea of adding an extra param that can get forgotten as the new right way
<maxb> Really what I need is for the WorkingTree API to acknowledge that the associated Branch may already be open, and let it be passed in
<maxb> It turns out my WT has already been opened once, then discarded, too :-)
<maxb> So, I think my answer here is to stop using BzrDir.create_branch_convenience, and do the creation myself so that I can get hold of the return value of create_workingtree
<jam> LarstiQ: looks fine to me. You'll probably want to look at the tests in test_btree.py that currently only go against index implementations, (or maybe it is per_index?)
<jam> to see if you can get a builder object passing the same _find_ancestors tests.
<LarstiQ> jam: aye
<maxb> Hm. Actually, if you're doing work on lots of branches in a shared repository, it must be really easy to accidentally reopen the repository every time you open a new branch
<mgz> maxb: it is.
<maxb> riight, so the udd importer is probably opening repositories N * number-of-existing-ubuntu-series times :-/
 * maxb kicks off a test import with the modified code
<maxb> gah, thinko, called create_workingtree on the branch not the bzrdir
<maxb> It is a bit inconsistent that we have a branch.bzrdir.create_workingtree(from_branch=branch) but no equivalent for open_workingtree
<mgz> maxb: point me at the mp when you're ready
<maxb> https://code.launchpad.net/~maxb/udd/lockcontention/+merge/104500
<mgz> maxb: reviewed. I can deploy to jubany later, or you can do that.
<mgz> maxb: from my questions, only real addition that I'd like would be a docstring on create_branch that says what the aim is exactly
<mgz> it's kinda just a thin wrapper with some preconfigured bits, maybe the functions that use it need more
<maxb> Well, it's only used in two places, and those have little in common
<maxb> It might even be appropriate to rename it to an underscore-prefixed name, it's so much an implementation detail
<mgz> right, what I'm not clear on is if create_updates_branch needs the tree
<mgz> right, underscore or rename would be good.
<PaoloRotolo> Hi all!
<jelmer> hi PaoloRotolo
<PaoloRotolo> I have a problem with Bazaar. I get this error: "paolo@voyager:~/Sviluppo$ bzr branch lp:ubuntu/precise/gnome-control-center
<PaoloRotolo> bzr: ERROR: Revision {package-import@ubuntu.com-20120316192311-zi5yuz8wrcq6tbhg} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"...
<jelmer> PaoloRotolo: see bug 888615
<ubot5> Launchpad bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed] https://launchpad.net/bugs/888615
<PaoloRotolo> jelmer, thanks!
<jml> halp
<jelmer> jml!
<jml> I just ran 'bzr rmbranch foo' in my colo and now it doesn't work
<jml> was in 'trunk', ran 'bzr rm working-public-ip', and now I can't switch branches
<jelmer> jml: what version of bzr?
<mgz> 2.5.9
<mgz> 9? 0.
<jml> Bazaar (bzr) 2.5.0
 * mgz guesses, need to back port the rmbranch fix still
<jelmer> jml: that doesn't have the rmbranch fix
<jelmer> so if you specify a branch name, it will try to open the branch containing that path
<jelmer> s/branch/control directory/
<jelmer> that control directory would be 'trunk'
<jelmer> and then it removes the active branch
<jml> jelmer: yuck.
<jml> jelmer: how do I dig myself out of this?
<jelmer> jml: you can create the branch again by running "bzr heads --dead-only" to find the relevant revision
<jelmer> and then using "bzr pull -rrevid:REVID --overwrite ." to create the branch again
<jml> jelmer: ok. I'll try that.
<jml> bzr: ERROR: Not a branch: "/home/jml/src/lp-dev-utils/.bzr/branch/": location is a repository.
<jml> :(
<jelmer> jml: try a "bzr init ." first
<jml> jelmer: interesting. now when I try that I get: $ bzr switch trunk
<jml> bzr: ERROR: Cannot switch a branch, only a checkout.
<jelmer> jml: you want "bzr switch -b trunk"
<jml> bzr: ERROR: Cannot lock LockDir(file:///home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock): File exists: u'/home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock': [Errno 17] File exists: '/home/jml/src/lp-dev-utils/.bzr/branches/trunk/lock'
<jml> break the loc?
<jelmer> jml: ah, it already exists
<jelmer> sorry, I didn't realize your current branch was just a reference
<jml> ah
<jelmer> jml: try "bzr rmbranch; bzr co --lightweight file:,branch=trunk ."
<jml> jelmer:  that succeeds without error, but then: bzr switch trunk
<jml> bzr: ERROR: Not a branch: "/home/jml/src/lp-dev-utils/.bzr/branch/": location is a repository.
<jelmer> jml: what does "bzr branches" say?
<jelmer> jml: generally speaking though, I would recommend using something 2.6-ish with colocated branches
<jml> jelmer: it lists four branches, including trunk, but none are selected.
<jml> jelmer: I'm guessing 2.6 is not in 12.04?
<jelmer> jml: no, unfortunately not
<jelmer> jml: you can try "bzr switch --force"
<jml> jelmer: ok.
<jml> jelmer: I think I'll just refetch, and then use heads to pull the branches from the old one into a new colo
<jelmer> ok
<jml> jelmer: thanks though.
<jelmer> jml: I don't think colocated branches are ready for production use, tbh. They're not polished enough.
<jml> jelmer: well, I started using them because I prefer the layout, and because I wanted to help polish them as an alpha user
<jml> doesn't look like that's going to happen though.
 * jml goes temporarily Eeyore
<lduros> i'd like to have a diff of all files between two commits
<lduros> how can I do this? :-)
<jelmer> lduros: bzr diff -r4..5
<lduros> bzr diff -rXXX..XX
<lduros> ah ok
<lduros> :-)
<jelmer> to get the diff between revision 4 and 5
<jelmer> lduros: :)
<lduros> i thought the dots had to be replaced
<lduros> with something
<fullermd> They're actually upside-down apostrophes.  With amputated tails.
<jelmer> fullermd: that sounds like punctuation-abuse to me
<lduros> ah
<lduros> but does it commits in between
<fullermd> You call it punctuation abuse, I call it thursday.
<lduros> does it compare all the commits in between
<lduros> I meant
<fullermd> There's no "in between" really.  There are just two states.
<lduros> ok
<lduros> how can you tell what revision number you are on currently
<lduros> sorry... just learning bzr
<jelmer> lduros: 'bzr revno'
<lduros> cool
<lduros> that shows the latest one though
<lduros> if you are using revert -r xxx
<lduros> it wouldn't show xxx
<lduros> but the latest
<lduros> revision
<lduros> number
<jelmer> lduros: revert doesn't change the revion number
<lduros> hmm ok
<jelmer> lduros: it justs sets the contents of the working tree to match that of the specified revision
<lduros> but it puts the file to a given revision number no?
<lduros> ok
<jelmer> lduros: to the contents of the file in that revision
<lduros> rightok
<lduros> no big deal then :-P
<lduros> hehe
<lduros> at least revision numbers are easier to remember than git sha1 hashes
<lduros> :-P
<lduros> I've been using bazaar for two weeks, and I really love it
<lduros> thanks for making bazaar!
<lduros> :-P
<lduros> if anybody here is involved with it
<lduros> going back in revisions is much simpler than git
<lifeless> lduros: excellent
<lduros> lifeless: I had to find a subtle bug, which I introduced I didn't know where, hundred commits ago
<lduros> I went back, revert commit 10 by 10
<lduros> until I narrowed down to the revision that had an issue
<lduros> this in git was a headache for me
<lduros> with the hashes
<lduros> maybe there's a better way to do it in git
<lduros> than I would
<lifeless> I believe many folk would use git bisect
<lifeless> there is a bisect tool for bzr as well
<lifeless> it just automates (and optimises) the process of narrowing down a change
<lduros> lifeless: hmm
<lduros> but you need to automate the test no?
<lduros> which is not that easy to do in my case
<lduros> since it requires starting firefox, navigating to a certain page and performing a certain task :-P
<lduros> in any case, the fact is that with bzr I didn't need to learn about something like bisect
<lduros> i could do it using the revision numbers
<lduros> makes more sense to humans :-P
<lifeless> nah
<lifeless> you can
<lifeless> but you can also just use it to go one step
<lifeless> check yourself
<lduros> ok
<lifeless> then say 'problem still exists' vs 'problem is gone'
<lifeless> and it decides to go further back or forwards
<lduros> ok
<lduros> so you're convincing me to use git :-P
<lduros> hehe
<lifeless> not at all
<lduros> just kidding
<lifeless> I'm saying that there is a tool, that both systems have, that can help with the problem you had
<lduros> i know, got it :-)
<lifeless> I think its great - its a design goal - that with bzr you didn't need the tool ;)
<lduros> yeh
<dOxxx> lduros: in git you can also use HEAD~10 to refer to the 10th revision before the tip of the current branch
<lduros> dOxxx: maybe, but then HEAD~10 changes if the tip of the current branch changes
<lduros> you can't turn off your computer, or even write the revision number on a piece of paper
<lduros> :-)
<lduros> was just saying I love revision numbers
<lduros> because I like to use my brain
<lduros> :-P
<lduros> maybe people despise that because it's not really being a power user
<lduros> but it's being a power user with your brain, ... sort of
<dOxxx> heh
<dOxxx> you don't need to use the whole git hash. you can usually just use the first 6-8 digits and it should be unique enough
<lduros> yeh but even that many it makes no sense
<dOxxx> but yeah it's not easy as -r500 -r490 etc
<lduros> there's no succession
<lduros> yeh
<dOxxx> btw, as a solution to the tip changing problem, you can use a hash with the ~10 syntax as well, so like abc123~10 would be the 10th commit before the revision whose hash starts with abc123
<lduros> with bzr?
<lduros> yeh
<dOxxx> git
<lduros> yeh, realized afterwards
<lduros> i don't like it as much
<lduros> :-P
<dOxxx> heh
<lduros> so is that bzr bisect: http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html
<lifeless> yes
<lduros> cool
<lduros> just wrote a little post :-P incorporated some of what you lifeless and dOxxx said. Hope that's ok with you. I bet many people will despise me for what i'm saying in there, anyway... http://lduros.net/posts/why-i-think-bazaar-better-git/
<dOxxx> "A simple bzr -r 610..611 allowed me" -> "A simple bzr diff -r 610..611 allowed me" ;)
<dOxxx> but good post :)
<dOxxx> explaining *why* you prefer one to the other may help somebody else decide which they should try first because the same thing would bug them
#bzr 2012-05-04
<vila> hi all
<mgz> morning
<Xtreme> guys, little help needed..
<Xtreme> well, now my php project is in /home/user/www
<Xtreme> so i went to www, and did bzr init
<Xtreme> then bzr add and then commit
<Xtreme> now if i change any file in it, how to track the changes? and how to keep it as different versions?
<Xtreme> any one?
<jpds> Xtreme: Do: bzr commit --show-diff
<jpds> Xtreme: After making a change.
<Xtreme> jpds:  and how to roll back?
<Xtreme> go to previous status
<jpds> Xtreme: bzr uncommit; bzr revert --no-backup
<mgz> really you want to seperate your deployment from your development, but it's not too important for small things
<Xtreme> okay so say i have a index.php
<Xtreme> i did some coding and it working file
<Xtreme> so i add and commit it
<Xtreme> then say, i fucked up some thing and it got screwed
<Xtreme> so if i do bzr uncommit, will i get index.php be replaced with working index.php?
<jpds> Xtreme: Yes.
<jpds> Xtreme: You should really read: http://doc.bazaar.canonical.com/bzr.2.5/en/mini-tutorial/index.html
<jono> hey
<jono> I have a 9 hour old bzr loc
<jono> lock
<jono> bzr break-lock isnt working
<jono> any idea how I fix this?
<jono> ignore me, fixed it :-)
<jono> thanks!
<maxb> jelmer: Hi. There's a compilation error in subvertpy trunk's C code. Use of -> where . is intended (left operand is a struct, not a pointer to a struct)
<jelmer> maxb: fixed, thanks
<maxb> thanks :-)
<thomi> Question: Is there a way to move files from repo A -> repo B and keep their revision history?
<thomi> I'm guessing not - but maybe there's a workaround? I'm moving code from one project to another, and I'd like to keep the history.
<fullermd> Not really.  In concept you could created a similar looking history for them and bring that into the new branch, but...
<fullermd> Files don't have history; history has files.
<jimis> On one PC I have made a no-trees branch of an lp:project, and have been working on it locally for some time
<jimis> What's the best way to move *everything* on to another PC?
<jimis> Oh, I've been working on it with local checkouts on a separate dir
<jimis> I'm afraid I'll lose stuff (like shelves) if I just move the notrees repository and recreate a new local checkout
<fullermd> I don't think there's any way to push shelves around.
<jimis> fullermd: are they stored in the checkout dir and not in the no-trees repo?
<fullermd> Yes, they're a property of the WT.
<jimis> bummer :-)
<jimis> fullermd: anything else I may lose?  (besides uncommitted changes that is...)
<fullermd> Everything committed would be in the branch/repo.
<fullermd> Revs, tags, signatures...
<jimis> alright, so I'll tar this up and only lose shelves
<jimis> thanks for helping
<fullermd> You could always make a temp branch and commit your shelves into it.
<jimis> fullermd: I'd have to resolve many conflicts as each shelve was created a a different point in history
<jimis> fullermd: any ideas how I can get the shelves in diff format?
<fullermd> unshelve --preview?
<jimis> (btw, until today I thought that shelves were implemented as special light branches...)
<fullermd> Pretty sure shelved changed know what their basis revision was.  Not sure that's exposed anywhere...
<fullermd> No, they're really more a transient thing than that.  I can't remember the last time I had anything shelved for more than 5 or 10 minutes.
<jimis> :-(
<jimis> this should be really pointed loudly, since it's unexpected to actually lose data like that in a distributed system
<jimis> I use them all the time for backing off changes and switching to other branches
<jimis> (I use a single-dir checkout workflow)
<jimis> fullermd: I'm curious, what's your workflow?
<fullermd> Nothing particularly exciting.  I mostly have branch/WT coincident.
<fullermd> Using shelves to back off and "whoops, I probably wanted to make that change in this other branch" is probably fairly common (though often unnecessary since switch will merge over uncommitted stuff)
<fullermd> But "let me stick this stuff I don't want to lose on the shelf for a couple weeks" is a bit unexpected.
<jimis> fullermd: WT?
<fullermd> Working Tree.
<jimis> btw, the "bzr switch" silent merging was a major headache for me at first
<jimis> my instict was telling me that uncommitted changes would stay as uncommitted on the same branch for commiting when coming back
<fullermd> Interesting.  I'd reflexively assume just the opposite.
<jimis> that would be an extra merge for me :-)
#bzr 2012-05-05
<jimis> hmmm, unshelve --preview was useful to save some diffs, but they are full of conflicts :-s
<fullermd> Unshelving would do a better job, since it can merge.  The diffs would just be relative to the basis.
<fullermd> Of course, if you've diverged far from the basis, you'd still be paddling.
<jimis> fullermd: ideally I'd want to keep a diff versus the source branch/revision
<jimis> so that it is most readable in case I ever need it
<jimis> I can guess that internally that's the kind of diff stored :-p
<jimis> I'll file a feature request
<jimis> anyway thanks again :-)
<jimis> "bzr info" shows as parent branch an http://bazaar.launchpad.net url
<jimis> that means I'm not using the fastest protocol, right?
<jimis> I remember I had to use http because of the firewall
<jimis> So how can I reset the parent branch to the lp:project url?
<LarstiQ> jimis: either `bzr pull --remember lp:branch` or `bzr config parent_location=lp:branch`
<LarstiQ> jimis: isn't it an option to copy/rsync your working setup to the different pc?
<gwal> hey guys, I recently did a bzr merge because the remote root branch and my local branch were both at revision 4 and bzr rspush complained about it
<gwal> now, after successful merge, when doing bzr rspush I get this: You have 2 extra revision and two local revisions: 5 [merge] and 4
<gwal> does anyone know how to resolve this?
<LarstiQ> gwal: have you committed the merge?
<gwal> LastiQ: yes I have
<LarstiQ> (also, wow, rspush is a really old plugin, it's still alive?)
<LarstiQ> gwal: what does `bzr missing remote/branch` sa?
<LarstiQ> say
<gwal> oh is it really old? what else would you use to push both the database and files onto a remote box? (sorry if this sounds like I have no idea what I'm talking about ... which is true)
<gwal> bzr missing says:
<gwal> You have 2 extra revision(s):
<gwal> revno: 5 [merge]
<gwal> (details about revision)
<gwal> revno: 4
<gwal> (followed by details about rev 4)
<LarstiQ> gwal: so that seems either like it didn't push, or it is comparing with a different location
<LarstiQ> afk for a minute
<gwal> when I try to do bzr rspush I get: bzr: ERROR: Local branch is not a newer version of remote branch.
<gwal> and I am positive that bzr is attempting to push to the same location as always
<gwal> and that bzr missing is comparing with the same location
<gwal> I also need to go but it would be fantastic if anyone had an idea ... will check later
 * LarstiQ has a look at the rspush code
<LarstiQ> gwal: what version of bzrtools/bzr are you using?
<LarstiQ> gwal: as for the usecase of pushing a branch and then updating the files, there is https://launchpad.net/bzr-push-and-update for example
<jimis> LarstiQ: copy/rsync which parts of my setup? I copied the no-trees repo, but the light-checkout can't be copied, a new one must be made from the new location.
<LarstiQ> jimis: must it? hmm
<jimis> LarstiQ: That happens because checkout refers to absolute path, which is different now.
<jimis> I couldn't figure a way to reconfigure this one
<LarstiQ> jimis: you _could_ try just the .bzr/checkout/shelf dir
<jimis> and the path is absolute, even when I give relative path: "bzr co ../no-trees-repo/trunk"
<LarstiQ> jimis: I admit it's a bit hacky, but to get you out of the ditch
<jimis> nice, was afraid to just move this one since .bzr is incomprehensible thus I don't mess with it :-)
<LarstiQ> jimis: that is good approach usually :)
<gwal> LarstiQ: bzr --version spits out this:
<gwal> Bazaar (bzr) 2.2.4
<gwal>   Python interpreter: /usr/bin/python 2.7.0
<gwal>   Python standard library: /usr/lib64/python2.7
<gwal>   Platform: Linux-2.6.35.6-48.fc14.x86_64-x86_64-with-fedora-14-Laughlin
<gwal>   bzrlib: /usr/lib64/python2.7/site-packages/bzrlib
<dOxxx> gwal: bzr 2.2 is quite old by now, 2.5 is the current stable version.
<gwal> dOxxx: do you think that the age of my bzr version causes this error though?
<dOxxx> no idea, but I always try the latest version in case it fixes the problem :)
<gwal> good call bud ;)
<dOxxx> I jsut read up on rspush
<dOxxx> are you sure you are pointing it at the same remote branch?
<dOxxx> check what `bzr info` says for the push or parent branch
<gwal> ok hang on
<gwal> yea no I'm positive it's the correct location
<gwal> to my mind, this problem came up after I had merged the remote branch (revision 4 at remote location) with my local branch (also revision 4)
<gwal> for some reason bazaar now thinks I got two different revisions in my local branch and lists them as revno 5 [merge] and revno 4
<gwal> maybe it is still trying to push revno 4 to the remote location when it really should be pushing revno 5
<dOxxx> did your local and remote branch diverge at rev 4? i.e. is your local rev 4 commit different from the remote rev 4 commit?
<gwal> yes they're different
<gwal> but I merged them into revno 5
<gwal> which I am now trying to push to the remote location
<dOxxx> what if you try using the standard push command?
<gwal> hang on
<gwal> hmm ... it claims I'm holding a lock at this computer and therefore can't push
<dOxxx> the rspush docs say " It will also error out if the upstream directory is non-empty and not an earlier version of the branch."
<dOxxx> this makes me suspect that it can't handle divergent branches even if you merged them
<dOxxx> do you have any other bzr tools open that are using your local branch?
<dOxxx> like qlog or something like that?
<gwal> no it's really just the one terminal I'm working in
<gwal> I don't even know what qlog is ... I'll Google it
<dOxxx> qlog is part of thq qbzr plugin, it's Qt-based GUI commands for bzr
<dOxxx> quite nice to use
<dOxxx> anyway if you're sure that you don't have another bzr command in progress on your local branch, you can try using `bzr break-lock` to force the lock to be released
<gwal> so QBzr?
<dOxxx> yeah that's the plugin
<dOxxx> it's not really related to your problem though...
<gwal> yea thanks though, I'll check it out
<gwal> oh wait ... my bad I think
<gwal> I had used bzr in the terminal on my local machine, then ssh'ed into the remote computer that I am trying to push from in the same window
<gwal> "bzr break-lock ." on the remote machine should do the trick no?
<gwal> I also closed the terminal (local computer) and opened a new one .. doesn't seem to work
<dOxxx> only if you're sure you don't have another bzr process oeprating on that branch
<gwal> i.e. doesn't seem to release the lock
<gwal> ps aux | grep bzr doesn't give any process
<dOxxx> try the push again
<gwal> still complains about the lock
<dOxxx> and break-lock does nothing?
<gwal> doesn't seem to ... at least it doesn't acquire the lock for me
<gwal> wait, do I need to say break-lock for the local branch or do I need to operate it on the remote location?
<dOxxx> local
<gwal> yea no, tried that
<dOxxx> could you copy & paste the output of the push command?
<gwal> bzr push
<gwal> Using saved push location:
<gwal> (... location ...)
<gwal> Unable to obtain lock  held by (my name) at (my local computer's name), acquired 25 minutes ... ago
<gwal> bzr: ERROR: Could not acquire lock "(local)":
<dOxxx> and yet break-lock in that local branch directory does nothing?
<gwal> no, I type in "bzr break-lock" in the local branche's directory, the terminal accepts it (no errors etc.) and I will get the same error message for my next attempt at bzr push
<dOxxx> what URL transport are you using? bzr+ssh?
<gwal> I indicate the remote location with sftp://
<gwal> I'm not sure if that involves ssh?
<dOxxx> similar but not quite the same
<gwal> yea probably does eh?
<gwal> ok
<dOxxx> strange... okay, shot in the dark... try break-lock on the remote branch
<gwal> ssh to the remote location and do break lock there or inside local branch do a bzr break-lock sftp://remote-loc
<gwal> ?
<dOxxx> ssh
<gwal> it was 50/50 ... I tried the latter and that worked
<dOxxx> so it actually found a lock?
<gwal> yes it asked whether I wanted to break the lock of (my name) at my local computer
<dOxxx> weird
<dOxxx> ah I see
<gwal> knowing nothing about bzr I can't gauge that really
<gwal> so doing bzr push worked but it gave me all this info:
<gwal> This transport does not update the working tree of: sftp://(remote loc) ... See 'bzr help working-trees' for more information. Pushed up to revision 5.
<gwal> then doing bzr rspush also worked surprisingly
<dOxxx> right...
<gwal> what's this working trees business?
<dOxxx> okay, so push will update the working tree of the remote branch to the revision you pushed up, but only if the protocol you use supports doing so
<dOxxx> sftp doesn't
<dOxxx> but bzr+ssh should
<gwal> but why does it still say "pushing up rev 5"?
<dOxxx> it's pushed new revisions into the repository in the remote branch
<dOxxx> if you want the working tree in the remote branch to be updated as well, you will have to ssh and run bzr update
<gwal> does that mean that if I were to ssh to the remote location and work on the local branch there then I would be modifying the old revision number 4? whereas if I go somewhere else and pull from the same remote location I would receive the updated revision number 5?
<gwal> the latter seems to hold
<dOxxx> the working tree would be at rev 4, so I'm not quite sure what would happen if you were to commit changes at that point.
<dOxxx> it may give you an error
<dOxxx> it may create a new rev 5 and the old rev 5 would be lost in the ether
<dOxxx> otherwise known as a detached head, I think
<dOxxx> it helps to think of these revisions as a directed acyclic graph
#bzr 2012-05-06
<dOxxx> when you make a new commit, you're adding a connection from the current revision to the new commit
<dOxxx> and then the branch's tip pointer is updated to point at the new commit
<dOxxx> note that the revision checked out in the working tree is not necessarily the same as the branch tip
<gwal> but with bzr update I jump to the tip?
<dOxxx> yes
<dOxxx> that updates the working tree to the same state as the tip revision
<dOxxx> conversely, bzr update -rN will update the working tree to the state at revision N
<gwal> so my tip revision is revision 5 which is in the repository at the remote location indicated with sftp://
<dOxxx> and in the case of the push you did earlier, it add new revisions but couldn't do the equivalent of `bzr update`
<dOxxx> yes
<gwal> I use the remote location exclusively as a repository ... and I just did a bzr pull on this sftp:// location from a different computer which gave me the latest revision (5)
<gwal> I think I remember why I can't use bzr+ssh: the remote location doesn't have bzr installed
<dOxxx> ah yeah
<dOxxx> that does make things a little harder
<gwal> everything seems to be there though .. in the remote sftp:// location and my current pull of revision 5
<dOxxx> if you don't need the working tree in the remote location, you could try `bzr reconfigure --branch sftp://...` to get rid of the working tree
<gwal> what does it mean to get rid of the working tree?
<dOxxx> it means there is no checkout of the latest revision, it's just the .bzr directory with the revision data
<dOxxx> I'm not sure if the reconfigure will work over sfpt though
<dOxxx> sftp*
<gwal> ok ... hang on
<gwal> no .. it complains that sftp://location/.bzr/ is not a local path
<dOxxx> yeah I guess it can't do it remotely
<dOxxx> you'd need bzr on the remote machine to do it
<gwal> yea I understand ... not sure I can get bzr on there though
<gwal> but in itself this isn't inherently bad is it?
<dOxxx> no, you'll just get the warning every time you push
<gwal> ok, I can live with that
<gwal> thanks so much for helping me with this! guess it all just boiled down to my local box holding on to its lock on the remote repository
<dOxxx> yah
<dOxxx> the rspush may not have released it properly when it encounted the divergent branches
<dOxxx> encountered*
<gwal> yea might be that
<dOxxx> any particular reason you were using rspush instead of push?
<gwal> as far as I understand, push doesn't transfer my local files to the remote location?
<dOxxx> err...
<gwal> not true?
<dOxxx> what exactly do you mean by "my local files" ?
<gwal> by that I mean, I bzr add something.c locally, bzr ci this change and when I do a bzr push it doesn't seem to copy those files over to the sftp:// location
<gwal> sorry, I'm new to bzr so this may sound stupid
<dOxxx> that's because it can't update the working tree over sftp
<gwal> ah
<dOxxx> the revision with that change has been pushed
<dOxxx> I'm guessing rspush was able to do it though?
<gwal> yes it was
<dOxxx> interesting
<gwal> ok I see your point, usually bzr push to a bzr+ssh location would do a remote bzr update after my local bzr push?
<dOxxx> yeah
<dOxxx> because it can run bzr on the remote machine
<gwal> yea ok, that makes sense now
<dOxxx> or at least I believe that's what it does :)
<gwal> well it would make sense at any rate ;)
<dOxxx> I usually use tree-less remote repos
<dOxxx> since I don't need the working tree on the remote machine, just want to store the revision data
<gwal> so essentially the kind I'm trying to use on my box that has no bzr installed?
<gwal> that's exactly what I want. how do you go about this yourself?
<gwal> what I do is bzr init local_dir and then bzr rspush local_dir sftp://location
<gwal> (after a bzr ci)
<dOxxx> I use launchpad primarily so it sets that up automatically but I think if you did `bzr pusg --no-tree remote-loc` for the initial push it would create a tree-less repo
<dOxxx> push*
<gwal> oh ok, I'll need to try that
<dOxxx> ah the help for bzr push says:
<dOxxx> The target branch will not have its working tree populated because this
<dOxxx>   is both expensive, and is not supported on remote file systems.
<dOxxx>  
<dOxxx>   Some smart servers or protocols *may* put the working tree in place in
<dOxxx>   the future.
<dOxxx> I think "remote file systems" means protocols like sftp
<dOxxx> so I'm guessing rspush created the working tree initially
<dOxxx> anyway, sounds like you're sorted out?
<gwal> yea it must've ...
<gwal> yea man I think I am. I'll look into the --no-tree option although my current bzr version doesn't seem to know this option
<dOxxx> ah :P
<gwal> maybe I'll need to update my bzr version
<dOxxx> you may not even need that option
<dOxxx> if use push as the first command to create the remote repo
<gwal> good call ... I'll give that a shot. when I read the help last time around (what you pasted above) I read the line about the working tree not being populated as meaning that my files won't get transferred
<gwal> thanks to you though I kind of understand what that means now ... so will try push from now on as initial push
<dOxxx> glad to help
<gwal> thanks again and take care
<dOxxx> cheers :)
<Noldorin> hey fokls
<Noldorin> i'm trying to push a branch to my FTP server...
<Noldorin> i uncommitted locally than made a few more commits
<Noldorin> but it says there are no new revisions to push when i try to push it from locally to the server!
<Noldorin> even when i do --overwrite it still says this
<Noldorin> very weird
<Noldorin> any thoughts?
<LarstiQ> Noldorin: are you pushing to the right location?
<trebor_home> hi. i am new to bzr (cvs-user). are there texinfo files to download for 2.1.x (debian)?
<jelmer> trebor_home: I'm pretty sure we don't have any info files in the debian package
#bzr 2013-04-29
<jave> hello
<jave> is there some way to verify a bzr installation?
<bob2> what do you mean by verify
<jave> I get baffling error messages like: bzr: WARNING: bzrlib version doesn't match the bzr program.
<bob2> how did you install bzr and bzrlib
<jave> so my installation seems broken somehow. I cant figure out how though
<jave> as I remember, just "yum install bzr"
<jave> on fedora 18
<jave> but I have made various other bzr installs during the years, that I believed I have purged
<bob2> file a bug on fedora I guess
<jave> its a local issue
<vila> jave: 'bzr version -v' and 'bzr plugins -v' should help you check which libraries and plugins are used
<jave> vila: seems like theres a problem with the installation on the savannah.gnu.org rather than locally
<vila> jave: well, then the diagnosis should be done there, there is little you can do from your side
<jave> yes I didnt know at first where the problem was
<jave> the error message made it look like it was my local problem
<spundun> hi all... development-colo doesn't support merging branches!!
<spundun> or I can't figure out how to do it
<spundun> https://bugs.launchpad.net/bzr/+bug/1174445
<ubot5> Launchpad bug 1174445 in Bazaar "WE need support to merge colocated branches" [Undecided,New]
<SamB> spundun: huh, I'd never even heard of that flag before
<spundun> --development-colo ?
<SamB> yeah
<spundun> I use it to keep only one working directory and switch branches within that to work on specifics
<spundun> but I can't figure out if there is a way to merge those branches
<spundun> SamB: https://lists.ubuntu.com/archives/bazaar/2012q1/074217.html
<spundun> Found a workaround for it.
<spundun> posted in https://bugs.launchpad.net/bzr/+bug/1174445
<ubot5> Launchpad bug 1174445 in Bazaar "WE need support to merge colocated branches" [Undecided,New]
<SamB> it sounds like the special format isn't needed anymore ...
<spundun> I'm not sure what you mean
<SamB> (or didn't 2.5 ever get released?)
<fullermd_> I'm not aware that it has particularly thorough or meaningful support for colo.
<fullermd_> It was kinda in progress when the wheels came off.
<spundun> "it" being release 2.5?
<fullermd_> Being in-core colo.
<spundun> I'm not aware that it(=in-core colo) has particularly thorough or meaningful support for colo.
<spundun> like that?
<fullermd_> No, the first it was 2.5.  The second was colo.
<spundun> ok :
<fullermd_> 2.5 is out.  Really usable in-core colo isn't.  The formats in 2.5 (theoretically) support it, but the UI mostly isn't there.
<spundun> I'm using lp:bzr
<fullermd_> Situation isn't really different there.
<spundun> yeah, it seems like
<spundun> 2a format seems to work just as good without the --development-colo flag
#bzr 2013-04-30
<Andy80> jelmer, uhm.... I was thinking about it because at least I would have an automatic backup
<Andy80> instead of reling on a single server
<jelmer> Andy80: it's probably sufficient for that - but you can't really use dropbox if you want to collaborate with other people
<jelmer> because they might get weird errors from bzr if they try to access the repository while it is being updated
<Andy80> jelmer, it makes sense :)
<mgz> also, if dropbox is doing a background autoupdate, it can break your local operations on your repo
<Andy80> mgz, oh right.... uhm....then it's really not reliable
#bzr 2013-05-01
<Andy80> hi
<jelmer> hi Andy80
<Andy80> trying to "bzr branch..." a repository, I get this error http://pastebin.com/K3h0qrZq any idea?
<bob2> https://github.com/ansible/ansible/issues/276
<jelmer> Andy80: that looks like a broken installation of pycrypto
<jelmer> nevermind, what bob2 said :)
<Andy80> bob2, jelmer the link basically says that I need libgmp, I installed it with: yum install gmp gmpy
<Andy80> but I keep getting the same error
<Andy80> oh wait....
<Andy80> but it says v5 or later and centos 6.4 provides v4 only
<bob2> i only skimmed but assumed epel is the source of your pain
<Andy80> bob2, could you explain it in more detail please? I'm quite new to centos :\
<bob2> nope, I ditched centos for such reasons
<Andy80> ok
<jelmer> Andy80: a workaround might be to force bzr to use openssh rather than paramiko
<jelmer> Andy80: set BZR_SSH=ssh in your environment
<Andy80> jelmer, just tried with "export BZR_SSH=ssh" and then the same  bzr command, but I get the same error
<jelmer> Andy80: sorry, try "export BZR_SSH=openssh"
<Andy80> jelmer, same error again
<jelmer> hmm, that should be sufficient according to http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/env-variables-help.html I think
<jelmer> Andy80: sorry, I don't really have time to debug this. Perhaps somebody else can help.
<Andy80> jelmer, no problem, thanks anyway :)
#bzr 2013-05-03
<hypnocat> i deleted some lines in a certain file and checked the changes in a number of revisions ago... now i'd like to restore those same lines to the same file... how can i do that?
<LeoNerd> You could reverse-merge that one file
<hypnocat> where can i read about how to do that?
<LeoNerd> bzr help merge
<hypnocat> thanks
<LeoNerd> Specifically something like   bzr merge -r 20..19 . path/to/file
<LeoNerd> If the commit was -r20
<hypnocat> i see
<hypnocat> what is the . there for?
<LeoNerd> Because you're mergeing from the current branch
<LeoNerd> bzr merge [OPTIONS...] BRANCH [FILES...]
<hypnocat> ah
<hypnocat> thank you
<hypnocat> hmm
<hypnocat> %  bzr merge -r 976..975 . foo
<hypnocat> bzr: ERROR: extra argument to command merge: foo
<LeoNerd> Oh, hang on maybe I'm thinking of a different one
#bzr 2014-04-28
<otto> how do I run something like "git add -u *" in bzr?
<otto> bzr status shows deleted files, which I deleted manually. Now I'd like to have bzr to stop tracking them.
<otto> and I don't want to run 'bzr rm' manually on each file
<jelmer> otto: you don't need to
<jelmer> otto: bzr commit will just remove them
<jelmer> no need to explicitly tell bzr about it
<otto> jelmer: ok
#bzr 2014-04-30
<m_tadeu> hi....is there a way to tell the last successfull pull date?
<LeoNerd> It's not stored as such, but you could probably bound it by the timestamp of the most recent commit, combined with the mtimes of files in the .bzr directory
<m_tadeu> LeoNerd: thanx
<zyga> hey, fastimport.helpers lost binary_stream() and now bzrlib-fastimport doesn't work
<zyga> https://bugs.launchpad.net/ubuntu/+source/bzr-fastimport/+bug/1314771
<zyga> anyone knows where the code in question (binary_stream) went to?
<zyga> jelmer: ping
<zyga> jelmer: python-fastimport, there's no tag for the 0.9.2 release
<zyga> jelmer: and I need some help (if you have a moment)
<zyga> jelmer: I'm trying to solve bug 1314771
<zyga> jelmer: I'm trying to figure out where binary_stream() function moved to and at least patch my local environment to work around that
 * jelmer waves
<jelmer> zyga: why do you want 0.9.2 rather than 0.9.3 ?
<zyga> jelmer: hey
<zyga> jelmer: have a look at the bug I linked to
<zyga> jelmer: I sent a debdiff there
<zyga> jelmer: I don't know where that missing code should move to but without it utopic is broken
<zyga> jelmer: can you advise?
<jelmer> zyga: what is utopic?
<jelmer> zyga: this code really belongs in bzr-fastimport, not python-fastimport
<jelmer> it's generic code, not related to fastimport and not used by python-fastimport itself
<zyga> jelmer: ubuntu 14.10 (or debian sid), the 0.9.3 release broke bzr-fastimport (trunk and any released version)
<zyga> jelmer: sure, do you know the upstream of bzr-fastimport that could move those functions there/
<jelmer> zyga: ah, right
<zyga> jelmer: or anything else that rdepends on fastimport and might have called them
<jelmer> zyga: bzr-fastimport is here: http://launchpad.net/bzr-fastimport
<jelmer> zyga: I'd be surprised if anything else uses those functions
<jelmer> (and I didn't realize bzr-fastimport didn't have its own copies of them)
<zyga> jelmer: I'm not a commiter there and you seem to be a part of project maintainers
<zyga> jelmer: can you just copy those and release a new version? We'll get it packaged and release to fix everyone
<SamB> hmm, do "just" and "release a new version" really belong in the same sentence?
<jelmer> zyga: sorry, I'm no longer a committer on bzr-fastimport
<jelmer> zyga: (no longer have commit access)
<zyga> jelmer: I see, thanks
<jelmer> hmm, actually.. I do
<zyga> I need to grab anyone from https://launchpad.net/~bzr/+members#active
<jelmer> zyga: happy to merge mps to fix this
<zyga> jelmer: to what? to bzr-fastimport?
<jelmer> I left some bzr groups because they were too spammy
<jelmer> but apparently not ~bzr-fastimport
<jelmer> zyga: sorry, nevermind
<jelmer> confusingly lp:bzr-fastimport is nowadays owned by ~bzr, not ~bzr-fastimport
<zyga> yeah
<zyga> I just looked at that
<jelmer> zyga: anybody from that group will do, proposing a merge should get their attention
<zyga> jelmer: thanks
#bzr 2014-05-01
<xnox> what needs to happen to make a bugfix/stable release from lp:bzr?
<jelmer> xnox: there is a doc on release management in the source tree
<xnox> jelmer: i'll take a look, thanks.
<xnox> jelmer: oh, as a member of debian bzr packaging team, i can just do the release to debian - debian-style =) it's packaging snapshots now, and we are only missing two commits.
<jelmer> xnox: :)
<jelmer> xnox: are the two last commits worth another upload ?
<xnox> jelmer: apparently we want to sru them into trusty. it would give brownie points to foundation team or something like that =)
<jelmer> xnox: somebody cares about verify-signatures that much? :)
<xnox> jelmer: /o\ ....
 * xnox ponders if i should write in whitespace ended morse code "USE GIT" in the changelog =))))))) </troll>
<jelmer> xnox: you're a bad man.
<xnox> jelmer: ok, "BZR ROCKS" it is.
<SamB> xnox: you could stick it into README.Debian; nobody will ever notice anyway
 * jelmer hugs xnox
#bzr 2014-05-03
 * gattoX sta ascoltando Playing Alcatrazz - Wire And Wood
 * gattoX sta ascoltando Alcatrazz - Desert Diamond
<gattoX> ciao
<gattoX> sta ascoltando Alcatrazz - Lighter Shade Of Green
<gattoX> sta ascoltando Alcatrazz - Sons And Lovers
 * gattoX sta ascoltando Alcatrazz - Jet To Jet
<gattoX> yesssssssss
<gattoX> bye to all
<gattoX> sorry for bother you
<gattoX> byeeeeeeeeeeeeee
#bzr 2015-04-27
<pbw> Is any development still going on with bzr?
#bzr 2016-05-06
<renatosilva> hi, is there any specific reason the windows installer has not been updated to 2.6 and 2.7?
<fullermd> I'd assume "dealing with it is a PITA and nobody's gotten to it"
<renatosilva> is anyone from this thread in this channel? https://lists.ubuntu.com/archives/bazaar/2016q1/076084.html
<renatosilva> fullermd: thanks for sharing this relevant message with the world's community
<fullermd> That's what I'm here for.
#bzr 2017-05-04
<ao2> Hi, I come from a git background and I am trying to find the equivalent of the "git format-patch" and "git am" commands, to share multiple commits (along with author, date, and full commit messages) via email.
<LeoNerd> I believe what you want is a bundle
<LeoNerd> $ bzr help bundle
<ao2> I see I can use "bzr send -o my.patch" to create a merge directinve which contains a bundle with the info I want to communicate, as confirmed by "bzr bundle-info -v my.patch"
<ao2> LeoNerd, I do not understand how I can merge such info from a bundle into a distict repository, "bzr merge" + "bzr commit" results in all changes from the different revisions in the bundle squashed together, and with no commit messages
<ao2> I meant "bzr merge my.patch"
<LeoNerd> Ah; the merge is one commit, but it does retain the distinct identity of the individual changes within that
<ao2> so there's no way to rebuild the history of the individual revisions from a bundle?
<LeoNerd> Define "rebuild"?
<LeoNerd> Do you want them all visible as separate *mainline* commits?
<LeoNerd> Usually a merge appears as one commit with multiple sub-commits inside it
<ao2> I am with Bazaar (bzr) 2.8.0dev1 BTW.
<ao2> rather than rebuild I meant "preserve" the way I added the commits on the local branch
<LeoNerd> So each one is individual at toplevel?
<ao2> yes, and there is also the issue of keeping the commit message[s] from the bundle
<LeoNerd> Should be doable.. I would imagine some variant of 'bzr replay' can do it
<LeoNerd> Though offhand not a thing I've fiddled with before
<ao2> LeoNerd, let me read about that, thanks for the hint
<LeoNerd> (replay is useful for pulling commits around places)
<ao2> "bzr help replay" fails here, is it an extensions?
<LeoNerd> Oh.. hmm.. maybe
<LeoNerd> Personally, I basically never use the email bundle things... those rare times I need to send or receive commits, it's far easier to just have some http-visible repository somewhere
<ao2> LeoNerd, it'd be handy for a one-off contribution, and it is a familiar workflow for git people.
<LeoNerd> Ohright; I'm sure people do it, I'm just saying *I* don't so I'm not sure how helpful I can be in describing it
<ao2> LeoNerd, np :)
<ao2> and thanks
<fullermd> I'm not sure peopole do it, they just merge.
#bzr 2017-05-07
<Apteryx> Hi!
#bzr 2018-05-04
<knownexus> hello! o/
<knownexus> I'm trying to do a checkout, and have it ignore a specific directory (not check it out) Is this possible?
<jelmer> knownexus: sort of
<jelmer> knownexus: you can use "bzr view" to only checkout specific directories
<jelmer> but I don't think that does "all, except dir blah"
<knownexus> would i be able to loop that in some way?
<jelmer> knownexus: Hmm, with some shell scripting perhaps
<jelmer> I think we really need a better flag to "bzr view" here
<jelmer> I'm submitting a few that are prequities for other branches, I'll leave the rest to you :)
<jelmer> we should probably add some more stuff to the website, e.g. link to the main branch, to the ci, etc
