#bzr 2007-10-01
<jaguarondi_> Hi guys, just testing bzr atm. I did a nested branch and 'bzr status' returns it as unknown. Is the normal practice to add these nested branches to the ignore list?
<Verterok> moin
<Peng> MediaWiki?
<Vantage13> is there an environment variable to set to specify a different bzr lib directory?
<matkor> Hi ! What is idea beging merging files using olive-gtk and meld ? I get three views BASE OTHER THIS, where should I store final (merged) version ?
<pitti> hello
<pitti> whoa, the first time in years that bzr really failed for me...
<pitti> I checked out a Debian SVN with "bzr get svn+ssh://...", and now try to merge this into a native bzr branch; when doing that, I get
<pitti> bzr: ERROR: Repository KnitRepository('file:///home/martin/ubuntu/hal/hal/.bzr/') is not compatible with repository KnitRepository3('file:///home/martin/ubuntu/hal/hal-debian/.bzr/')
<pitti> any idea about that/ bzr upgrade'ing the debian svn checkout doesn't work either ("Cannot convert to format <RepositoryFormatKnit1>.  Does not support rich root data.")
<Lo-lan-do> You need to convert your branch to dirstate-with-subtrees or something
<pitti> hm, 'dirstate-with-subtrees' does not exist, it is already 'dirstate', and it refuses to convert to 'knit'
<Lo-lan-do> dirstate-with-subtree, sorry
<vila> try dirstate-with-subtree
<vila> :)
<Peng> Are you planning to drop pycurl? One comment in a bug mentions it.
<Lo-lan-do> I'm still confused as to why that format, which was supposed to become the default format around 0.15 or so, isn't even mentioned in "bzr help formats"
<fullermd> Because it's its purpose is to enable a feature there's not much of a UI for.  I don't think it's slated to become a default any time soon.
<fullermd> At one point, there was a discussion about changing it from a parallel format to a flag, I think.  But that was a long time back.
<ubotu> New bug: #147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed]  https://launchpad.net/bugs/147530
<Lo-lan-do> I see.  But I guess bzr-svn could be a bit more explicit in its error messages then.
<fullermd> Well, I don't think the error message is coming from bzr-svn.
<Lo-lan-do> I don't know where it comes from, but I do know it's confusing :-)
<pitti> meh, now bzr merge excepts out on me; I guess I'll revert the conversion and use classical patch for now
<fullermd> It's just a 'normal' bzr, "Hey-your-formats-are-incompatible-I'm-dying-here!" cry.
<vila> Peng: see bug #82086 about dropping pycurl
<ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]  https://launchpad.net/bugs/82086
<vila> fixing bug #147530 will at least gives a better error
<ubotu> Launchpad bug 147530 in bzr "pycurl http implementation peeks under the covers" [Low,Confirmed]  https://launchpad.net/bugs/147530
<fullermd> vila: What about the "stop making pycurl default if it's around" path that's been discussed a time or two?
<vila> fullermd: and stop verifying site certificates by default ? I'm really no comfortable with that...
<fullermd> Well, we're not verifying the certs by default for all the people who don't have pycurl installed.
<vila> There is still the option to make urllib the default for http and pycurl the default for https, but I'm not really comfortable with that wither
<vila> fullermd: yeah, I know, but windows installs it by default, ubuntu installs it by default, I think debian does that too, so who don't have pycurl really ?
<fullermd> I don't have it as a dependancy of the BSD port.
<vila> hmm
<fullermd> It's vaguely irritating to know that I could have a working setup with a self-signed cert or whatever, that nevers gives me any problems, then install some unrelated software that happens to install pycurl and suddenly have my branch blow up.
<vila> Well, I don't think I'm the one to take that decision, I can implement it though, but I'd feel better with an urllib solution
<vila> fullermd: you can't have working setup with a self-signed cert unless bzr pycurl http implementation is patched
<fullermd> Sure I can.  I can not have pycurl installed and be using urllib, without having any idea that it's a problem.
<vila> thinking that an urllib setup works scares me !
<fullermd> ("I" being not necessarily me personally.  Me personally, I don't think I use http with bzr anywhere except for pulling bzr itself, and plugins)
<vila> Do you know what was my *first* proposed patch for bzr ?
<fullermd> Renaming the command 'vila'?
<vila> lol, no. it was enabling self-signed certificates (or more precisely disabling certificate validation  for self-signed sites)... 1 year and 1/2 ago I'd say :-)
<vila> Now, call me stubborn, but all my http-related activity is aimed at dropping pycurl support (while providing a better urllib impl. though)
<vila> So dropping pycurl while not providing certificate verification
<vila> ... does not fit the bill :)
<vila> I tried to summarize in bug #82086
<ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]  https://launchpad.net/bugs/82086
<fullermd> Oh, I'm not proposing dropping pycurl; I'm mostly questioning whether it makes sense to use it by default when it appears.
<vila> Well, it's true that the subject has come quite often lately, may be a list discussion is in order then
<vila> so that all personal preferences and implications can be exposed
* fullermd nods.
<fullermd> I don't have a particularly strong opinion, and it certainly doesn't really affect me.  It just seems to come up with some regularity.
<fullermd> My going across the network tends to mostly be bzr+ssh   :p
<NamNguyen> abentley, ping
<fullermd> Prob. be a while before he's around.
<NamNguyen> alrighty ;-)
<NamNguyen> i just hit a problem with bb
<NamNguyen> 2nd time
<Lllama> Morning all. Easy question: I've just resolved some conflicts and 'status' tells me I have pending merges. Do I just need to commit for these to take effect?
<Lo-lan-do> Yes
<Lllama> Lo-lan-do: cheers.
<GaryvdM> Hi - I'm trying to push to a ftp server. I'm getting this error: http://pastebin.com/m57d74483 - and I am not sure what to do.
<matkor> Easiest way to see changes introduced in given revision or since given revno ? Prefereable like kdiff presents changes ?
<Lo-lan-do> bzr diff -c 1234
<GaryvdM> I'm still having a problem pushing to a ftp server. It creates a file called /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info.tmp.1191240308.188999900.3268.1560928192
<GaryvdM> Then dose a RNFR /bzr-pushtree/trunk/.bzr/branch-lock/kasvrj7jcy.tmp/info
<GaryvdM> That file dose not exist.
<matkor> Lo-lan-do: bzr diff ... it is text only ... no graphical tool for that ?
<Lo-lan-do> Oh.  Dunno, maybe in olive-gtk.
<GaryvdM> There is bzr-gtk - but it will not show you a sisde by side diff
<GaryvdM> Try https://launchpad.net/bzr-difftools/trunk
<GaryvdM> err https://launchpad.net/bzr-difftools
<harrisony> "353 MB .zip file" hmm pain
<harrisony> oops wrong window, sorry
<matkor> Is there easy way to test (using bzrlib) if at given path there is checkout or branch ?
<gabe> hi, what can i do about this showing up in bzr st?    kind changed:
<gabe>   emailer/steves_mailer (directory => tree-reference)
<matkor> I do bzrlib.workingtree.open_containing(path) , what should be next ?
<AnMaster> Unable to obtain lock sftp://anmaster@hosthere/var/www/envbot.org/htdocs/bzr/.bzr/repository/lock <-- bzr timed out when I pushed, how do I fix this?, deleting the whole repo dir is not an option
<fullermd> AnMaster: 'bzr break-lock'
<fullermd> (of course it's an option.  It's just a really bad one   ;)
<AnMaster> fullermd, yes because uploading about 50 MB on 128 kbps up for just the main branch will be a PAIN
<AnMaster> fullermd, I hope this won't leave it in a broken state or so?
<fullermd> Well, it's a Big Red Button.  If the lock _should_ still exist (like somebody else is writing to it), breaking it could be bad.
<fullermd> But if it's just a stale lock from a lost connection or something, it'll be fine.
<AnMaster> yep I know what it was
<AnMaster> also how do I with rspush from bzrtools specify the port that ssh is on? it is simple to do with normal sftp push but haven't found a way with rspush
<fullermd> That, I have no idea on.
<AnMaster> because ssh is on non standard port on this host
<LeoNerd> Can't you just use the .ssh/config  file in the usual way?
<AnMaster> ah
<AnMaster> LeoNerd, I normally do it like ssh -p port user@host but ok
<LeoNerd> Yes; but the config approach has the advantage that all the SSH tools will use it
<LeoNerd> And you don't have to think about it
<AnMaster> true
* AnMaster goes to read up on syntax of it
* AnMaster swears loudly at trac-bzr
<mrevell> Hey guys - I'll be holding the first of our two Bazaar Documentation meetings here on the hour.
<fullermd> What all ground are you intending to cover?
<mrevell> fullermd: My main aim is to find gaps in the current documentation, so I'm looking for people to suggest areas that they feel are missing from the current docs.
<bwinton> Ooh, in that case, I'm going to run and quickly get lunch and be back here in 4 minutes.  (Hopefully.  Feel free to start without me.)
<fullermd> Well, my main bug on that is the Fundamentals stuff, which we've covered on the list.  That, and the lack of a good reference to the commands.
<fullermd> I've issues with the tutorials, but I think one of the two biggiest (proliferation of partially-overlapping ones) has been resolved since the last time I sat down with the docs.   Been way too busy with work lately   :|
<mrevell> fullermd: Thanks. I'll get the meeting under way.
<mrevell> Welcome to this Bazaar Documentation meeting! Thanks for coming.
<mrevell> The purpose of today's meeting is to identify gaps in the current Bazaar documentation.
<mrevell> My aim is to help the Bazaar team to find and plug those gaps in time for the 1.0 release.
<mrevell> I've divided the agenda into:
<mrevell> * Is the user reference complete?
<mrevell> * What is missing from the user guide?
<mrevell> * What do we want to add the "advanced topics" and "best practice" sections?
<mrevell> So, who's here for the meeting? Say "me", if you're here to chat about the docs.
<mrevell> me
<james_w> me
<Lo-lan-do> Not me, sorry, I'm here to pester jelmer about bzr-svn :-)
<fullermd> me (somewhat)
<mrevell> Thanks guys, we can keep things pretty informal :)
<mrevell> So, my first question:
<james_w> Lo-lan-do: I didn't forward your latest bug as you said that jelmer was already aware.
<mrevell> What do you feel is missing from the user reference?
<Lo-lan-do> james_w: Fine by me
<james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<james_w> mrevell: ^ that one?
<mrevell> james_w: That's it, yeah.
<keir> examples
<james_w> so that is generated from bzr help.
<mrevell> james_w: My main concern is that every command should be covered, as it's also the bzr help
<fullermd> I feel that having the 'reference' generated from the online help is a wrong path; the needs of the two cases are totally different.
<mrevell> james_w: Right, yeah
<james_w> it's a good way of getting something together though.
<fullermd> Examples are a big thing (and good examples often cross command boundaries).
<james_w> I agree that it is not complete, or ideal though.
<fullermd> Really need to tackle each command and answer, "when would I use this?", "when would I not use this?", "what side effects can this cause?", etc.
<keir> examples are usually what i want in man page type help
<keir> sometimes it's not obvious how to string together the arguments for a command
<james_w> yeah, a clear statement for each about whether it modifies the working tree, uses network etc. might be good to have as well.
<fullermd> Thsoe sort of discussions get long, which isn't really suitable for online help (which should be more "remind me what the args/action is" than "describe in detail what each of these things do")
<keir> usually, some command as only a couple 'common use cases'
<james_w> fullermd: indeed. It might be useful to have online though.
<fullermd> Reasonable example: merge --reprocess.  Describing just what that does, and when you would/wouldn't want to use it is a couple paragraphs.  Fitting that into an option list summary doesn't work well   :)
<fullermd> Well.  I'm iffy on that.  If 'bzr help xyz' is more than a screenfull or two...
<james_w> with the topics shadowing feature it would be possible to define long help for each command which is shown if you run bzr help topics/command (I think that's the syntax).
<james_w> yes, not by default, but available.
<james_w> hmmm, short meeting.
<fullermd> See?  The help was too long for him   ;)
<mrevell> Hmm, got disconnected.
<mrevell> :)
<james_w> :)
<mrevell> Would it be reasonable to include a link to web based help, if a description was too long for bzr help?
<fullermd> A good coverage of what sort of conflicts can happen, how you can provoke them, and how to clean them up, would be another thing a ref manual should have.
<james_w> mrevell: reasonable yes, distros can patch this to point to a local copy as well.
<fullermd> It would probably have to be a pretty shallow link.  "For more, see the Bazaar Reference Manual  (online at ....)", rather than a deeper one.  That way would lie madness...
<james_w> fullermd: there is conflicts documentation, but it needs some work, and I agree it should be in the reference section.
<bwinton> I agree with fullermd on the link-to-online-docs point.
<mrevell> fullermd: Why would deeper linking be a problem? Perhaps I'm missing something obvious :)
<fullermd> Ditto for merging; we have some talk about workflows (we have some on the wiki; should emphasize the full continuum from "single shared branch" to "full mesh"), and the merging strategies that work.
<james_w> mrevell: are you against having it in bzr then?
<fullermd> Also, 3-way vs. weave/knit, why you'd use one over the other, and degenerate cases.
<bwinton> mrevell: a deeper link will prevent us from radically changing the structure of the docs.
<james_w> no, you can link to $version.
<mrevell> james_w: No, not at all, I was just picking up the point above that some of this might get too long for the internal help
<fullermd> mrevell: Change between two unsync'd things has bitten me too many times   :)
<mrevell> Ah, thanks fullermd and bwinton
<james_w> mrevell: ok.
<mrevell> So, should we aim for examples for each command?
<fullermd> And of course the pre-mentioned Fundamentals stuff; a good chapter up front on that will save your life many times over later on.
<fullermd> Yes, definitely.  Particularly on the options; when you'd use --xyz on a given command, not just the quickie description of what it does.
<james_w> mrevell: yes. Covering as many use cases for the command as possible.
<mrevell> Great.
<fullermd> "Why would I use --reprocess?"  "What does --verbose actually mean for this command?" etc.
<james_w> (we could make bzr help examples/command work).
<mrevell> james_w: Do you think there'd be some people who wouldn't want to see the examples?
<james_w> no, but again consideration of keeping the default help output reasonably short.
<mrevell> right
<james_w> I'm not suggesting removing all examples from the help output.
<james_w> they are usually the most useful bit.
<mrevell> james_w: Just keeping it to a reasonable length
<james_w> indeed.
<fullermd> I consider "bzr help xyz" to mean "I know how this works, remind me of the options".
<mrevell> fullermd: Great, thanks.
<fullermd> (the concensus may be that the online help should be more involved than that; just my reflex view)
<mrevell> Are there any commands that are missing entirely from bzr help, that you know of?
<james_w> there are hidden commands, but few of those are useful.
<james_w> (in general).
<fullermd> And even they have help; they just don't show up in 'help commands'.
<mrevell> james_w: I presume they're hidden for a reason, though?
<james_w> some commands could do with a brusign up of the help, and a couple of examples.
<james_w> not all have helpful help, but yes they are hidden for a reason.
<james_w> mrevell: are we concentrating on the in-source docs?
<mrevell> Okay, so the main thing I draw from this is that we need examples in bzr help, covering as many use cases as possible. I also take note of "<fullermd> I consider "bzr help xyz" to mean "I know how this works, remind me of the options"."
<mrevell> james_w: Anything that's in doc in the trunk atm.
<james_w> yes, with a short synopsis.
<james_w> mrevell: great.
<mrevell> james_w: But I'd be interested to hear about docs that are on the wiki and should be moved to the branch.
<james_w> yeah, I'm not sure about that.
<mrevell> james_w: Yeah, obviously it'd have to be a special circumstance.
<mrevell> Okay, unless anyone's got anything else to say about the user reference I'd like to move onto the user manual
<james_w> go ahead.
<mrevell> I'd like to make the user manual flow a little more and take the user on a journey from introduction through to in-depth, advanced topics.
<mrevell> The basic question, though, is again: what is missing from what we have already?
<james_w> is http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html the one you mean?
<fullermd> Well, not missing, but it's weird that the HTTP smart server doc is separate from, in a different section from, and not linked to, the page that talks about the rest of the smartserver interfaces.
<fullermd> ("not linked to from", that is)
<mrevell> james_w: Yes, that's it.
<mrevell> fullermd: It's linked from the page james_w referenced, isn't it?
<fullermd> I wonder if the User Manual and User Reference really should be so separate.  It almost seems like it should be one manual, with a spectrum from the relatively linear (step above tutorials) to the more random-access (command reference)
<fullermd> Yes, but there's "Running a Bazaar server" under "Basic Topics", that says nothing about and doesn't link to the bzr+http doc, which is under Best Practices (somewhat incongruously)
<mrevell> fullermd: Right, yes, "best practices" does seem like the wrong place for it.
<fullermd> Now, bzr+http setup is pretty long and involved, so it probably should be external to the rather short, simple setup for the other types.  But more closely related than it is.
<mrevell> I'd propose to turn the user manual intoa tutorial
<mrevell> that takes the user from the start of using Bazaar right through to more involved processes. I think the distinction between that tutorial and the user reference would be more concrete then.
<mrevell> So, anything that isn't part of the (new) tutorial moves from the user manual to the reference.
<fullermd> ISTM that there are 3 natural divisions.
<fullermd> One is the "quick start".  That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff.
<mrevell> :)
<fullermd> The second is the more miniseries-style tutorial stuff, which are individual pieces, but follow a reasonable progression without too much overlap.  Taht would be the "Learning bzr" sort of doc.
<mrevell> Yep
<fullermd> And the third would be the reference.  In-depth discussion of commands and use-cases, lists of config options and revspecs, etc.
<fullermd> The second two could be bundled together as a 2-part "book" potentially.  Certainly there'd be a lot of references to (3) in (2), "For more info, see ...".
<fullermd> The first would stand alone, and operate more as a hook.
<fullermd> Sorry.  I'm real full of very etheral handwaving, and not so much concrete    :|
<mrevell> I agree with those divisions. The mini-tutorial (which I've proposed become "Bazaar in 5 minutes") matches the first division.
<mrevell> Great, thanks for the feedback.
* fullermd shuts up for a while.
<mrevell> thanks very much for your input fullermd :)
<mrevell> If anyone thinks of any other gaps in the documentation - i.e. specific areas where we don't have any or we have very sparse documentation for a particular Bazaar feature - feel free to mail me matthew.revell@canonical, or of course mail the bzr list :)
<mrevell> I'm holding another of these meetings tomorrow (Tues) at 08.00 UTC.
<mrevell> Thanks everyone :)
<mrevell> Meeting ends but feel free to contact me any time with docs suggestions.
<james_w> thanks mrevell
<fullermd> OK.  The rest of you can get words in edgewise now   ;)
<statik> anyone in here figured out how to configure meld to work with the extmerge plugin?
* statik is being thick about understanding how meld arguments match up to extmerge
<schierbeck> phanatic: mjellow
<phanatic> schierbeck: hey, what does that mean? :)
<schierbeck> hello :)
<schierbeck> what's the status on using "revision history"? i say we go for it!
<dbn> Hi all
<Peng> "all" being like 2 people.
<dbn> Hi peng. May I ask you a question concerning bzr 0.90?
<dbn> I have a problem using the bundle command.
<Peng> You can ask any question, but I may not know the answer.
<Peng> 0.91 is out, FYI.
<dbn> :) I give it a try, then.
<dbn> I have setup a remote repository using bzr serve.
<dbn> I made a branch from that location, applied some changes and said bzr bundle
<dbn> bzr now gives a traceback complaining that
<dbn> 'RemoteRepository' object has no attribute '_make_parents_provider'
<Peng> That's strange.
<dbn> That's what I thought. That's why I came here ;)
<Peng> The usual workflow is to keep one copy of the upstream branch on your computer, then to branch off of that to make changes.
<Peng> Maybe it's a 'bzr serve' bug.
<Peng> Report it on the mailing list, maybe?
<Peng> Well, I guess it's not a 'bzr serve' bug.
<dbn> It works well when the remote repository is not contacted via the bzr protocol
<james_w> yeah, that sounds like a bug.
<phanatic> schierbeck: okay, i'll wait till tomorrow. if noone has anything against it, i'll merge "revision history"
<dbn> Do you want me to file a bug report for this?
<Peng> If you do, include steps to reproduce it and a full traceback ..
<james_w> dbn: yes please.
<dbn> Probably I should try out 0.91 first. Maybe this is already resolved ...
<james_w> yes, it might be.
<dbn> Ok, thanks. I will gather the steps to reproduce the bug and file it in the bugtracker.
<james_w> dbn: it is easy to reproduce here.
<james_w> bzr bundle bzr+ssh://localhost/home/jw2328/devel/bzr/bzr.dev
<dbn> james_w: Shall I include that line in the bug report then? Is that sufficient for you?
<james_w> dbn: unless you have any more interesting information. I think the problem is obvious enough.
<dbn> james_w: Ok, thanks.
<hsn_> bzr packages for windows are on wiki listed as 0.91 but they are 0.90
<ubotu> New bug: #147836 in bzr "bzr 0.90.0 bundle command fails with bzr remote repositories" [Undecided,New]  https://launchpad.net/bugs/147836
<james_w> hsn_: thanks, that's a known issue. You can get 0.91 if you access them directly, rather than using the current links.
<hsn_> james_w: should i fix wiki?
<GaryvdM> Is their anyone here that is familiar with the merge_sort code?
<GaryvdM> I am having a problem where by it does not return revision number 1
<GaryvdM> But that revision is in the graph and in the mainline
<GaryvdM> Code here: http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/annotate/szilveszter.farkas%40gmail.com-20071001083733-mn111f1k16ojsqd8?file_id=graph.py-20051016214152-ebf565808c860cf7#L47
<ubotu> New bug: #147860 in bzr "[BUG]  renaming + kind change == assertion failure" [Medium,Triaged]  https://launchpad.net/bugs/147860
<GaryvdM> Ok - found my problem.
<GaryvdM> You need to have revision number 1 at index number 1 of the mainline. Hence mainline[0]  needs to be something else like None.
#bzr 2007-10-02
<lifeless> yay net fuckage
<mpt> Ok, this may be a silly question
<mpt> But is there any way to revert to how a file/tree looked on a particular date?
<mpt> Short of first using bzr log to find the newest revision before that date?
<Peng> bzr revert -r date:2007-09-30
<Peng> See 'bzr help revisionspec'.
<mpt> Neat!
<Peng> Yeah.
<mpt> And that's not mentioned directly in "bzr revert --help" because revisionspec is also used by diff
<mpt> hmm
<lifeless> mpt: we should add a seealso to revisionspec I guess
<lifeless> brb
<mpt> lifeless, it already says "See 'help revisionspec' for details", I just didn't realize that the "details" would be interesting or relevant to ARG
<mpt> because they were on a separate line
<mpt> which is an accident of how long "-r ARG, --revision=ARG" is
<Peng> mpt: A lot of commands use -r.
<poolie> hi
<lifeless> mpt: this is true, but can we make it more clear
<poolie> mpt, lifeless, hello
<lifeless> poolie: just filed a bug
<poolie> thanks
<ubotu> New bug: #147916 in bzr "support for checkout of readonly url has regressed" [Undecided,New]  https://launchpad.net/bugs/147916
<spiv> http://live.gnome.org/iogrind looks shiny
<lifeless> is it a blocktrace wrapper?
<spiv> lifeless: the page says
<spiv> iogrind works in 3 parts:
<spiv>     * tracing the application using valgrind
<spiv>     * snapshotting the filesystem
<spiv>     * simulating the trace, against a snapshot to visualise.
<lifeless> hmm
<lifeless> should use blktrace ;)
<lifeless> no need for snapshot
<lifeless> jelmer: yo
<ubotu> New bug: #147927 in bzr "use python -O (assertions off) when running installed copy" [Undecided,New]  https://launchpad.net/bugs/147927
<lifeless> poolie: another patch sent in
<jelmer> lifeless: hi
<lifeless> your commit mails still say file:///
<lifeless> you need a public_url entry in your config
<jelmer> whoops
<Verterok> moin
<Verterok> I don't known if this is a bug or a problem of my installation, but I'm getting a exit value =1 when I run 'bzr diff'
<Verterok> I found this yesterday, while running the test cases of BazaarClient (the java library, part of bzr-eclipse) my test case for diff is broken and is because 'bzr diff' return a exit value = 1, but the output I get is ok
<lifeless> Verterok: its a feature
<lifeless> 1 - changed
<lifeless> 2 - unrepresentable changes
<lifeless> 3 - error
<lifeless> 0 - no change
<Verterok> lifeless: thanks, now you tell me, It's a nice feature :D
<lifeless> could you file a bug though, bzr help diff should list this
<Verterok> ok, I'll do that
<ubotu> New bug: #147938 in bzr "bzr help diff should list the meaning of exit values" [Undecided,New]  https://launchpad.net/bugs/147938
<poolie> lifeless, are you sure bug 147916 is real?
<ubotu> Launchpad bug 147916 in bzr "support for checkout of readonly url has regressed" [High,Incomplete]  https://launchpad.net/bugs/147916
<lifeless> yes
<lifeless> but I may be wrong
<lifeless> or misjudging some root cause
<lifeless> spiv: damn this patch is long
<poolie> spiv, can you explain why you want bug 106898?
<ubotu> Launchpad bug 106898 in bzr "put_bytes should raise a specific exception when given unicode" [Undecided,New]  https://launchpad.net/bugs/106898
<lifeless> spiv: review sent
<poolie> lifeless, i can't reproduce any failure with readonly branches, nor find a likely report in mail
<poolie> there may well be one that i can't find
<poolie> but for now, i'm going to just work on the other bit - better message when trying to commit to a readonly branch
<lifeless> ok
<poolie> i think it may be enough to (add a test and) just make that error a user error
<poolie> and check the message is reasonable
<lifeless> bbiab, fooding
<poolie> is it just me or is BB timing out a lot?
<lifeless> just you ?
<lifeless> as in, it works for me
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> you promised me a review :)
<spiv> lifeless: thinking of which, lp reviewers meeting in a couple of minutes...
<lifeless> oh crud
<lifeless> my stomach has just decided to throw spasms at me
<spiv> It dislikes the launchpad review team that much? ;)
<lifeless> unrelated I think, but I'm going to do a runner
* lifeless toilets
<poolie> tmi
<spiv> poolie: I think 106898 was motivated by wanting to know what to catch in test_put_bytes_unicode.  UnicodeEncodeError is raised by some transports, but that seems strange (we don't want to try encode unicode in that method, so why should it raise that?).  Some others raise AssertionError, which always feels a bit funny to catch to me but I guess can be ok.
<poolie> i guess the heart of it is
<poolie> i'm not sure how much we should have apis promise they will reject invalid input
<spiv> In that they should reject it, but not promise specifically how?
<spiv> i.e. we should test simply for Exception in test_put_bytes_unicode and stop worrying about the details?
<lifeless> poolie: I think its reasonable to promise when its a cheap promise; and/or the api is at the edge of a subsystem
<poolie> that seems like a good guideline
<poolie> spiv, well, why are you writing this test?
<spiv> I don't really remember why I wrote it.  (Or if I wrote it or just touched it?)
<spiv> But it seems good to ensure that put_bytes will not silently accept unicode strings as if they are bytes.
<spiv> Otherwise with sys.getdefaultencoding() == 'ascii', which it is by default, it's easy for it to appear to work reliably when testing, and then fail on real data that isn't 7-bit ascii.
<poolie> yes, that's true
<poolie> i would probably add TypeError or ValueError or both to the list of exceptions it can raise
<poolie> i don't think we need to test that it raises one particular exception
<poolie> i think declaring a new class would almost certainly be excessive
<spiv> I agree that a new class would be excessive.
<spiv> TypeError seems reasonable to me.  I guess the main thing that bugs me about that test as-is is that UnicodeEncodeError seems like a bogus exception to raise.
<lifeless> well
<spiv> Hmm, and ideally, it should raise when fed u'foo', not just u'\u1234', according to my argument above :)
<lifeless> TypeError requires LBYL
<spiv> (But the test currently only tests with u'\u1234')
<poolie> spiv, i agree that it should do this
<poolie> check the actual type rather than just whether it's convertible
<lifeless> well
<lifeless> the point is that it shouldn't be converted at all
<lifeless> poolie: 139478 would be the regression
<poolie> bug 139478
<ubotu> Launchpad bug 139478 in bzr "UnlockableTransport running update in checkout of readonly branch" [Medium,Triaged]  https://launchpad.net/bugs/139478
<poolie> now that bug numbers are 6 digits maybe ubotu and the markup code should just always recognize them.
<poolie> i'm working on those two now
<lifeless> spiv: so, is that review pending? or no-comment ?
<spiv> lifeless: pending
<lifeless> k
<ubotu> New bug: #147986 in bzr "branch in test root directory can cause confusing results" [Medium,Confirmed]  https://launchpad.net/bugs/147986
<poolie> mrevell, hi
<mrevell> hi poolie
<mrevell> Over the 30 - 45 minutes, we're going to be discussing Bazaar documentation.
<mrevell> Welcome to the meeting and thanks for coming :)
<mrevell> The aim of this meeting is to identify gaps in the current Bazaar docs.
<mrevell> Yesterday we had a similar meeting and the main issues raised were:
<mrevell> * We need examples for as many use cases as possible for each command in bzr help/user reference.
<mrevell> * We need good coverage of what sort of conflicts can happen, how you can provoke them, and how to clean them up.
<mrevell> * We should make the split between user reference and user manual clearer.
<mrevell> So, I'd be keen to hear what you guys feel we're currently missing. I'd like to cover:
<mrevell> * The user reference: do we have an entry for each command, should we cover more advanced topics in the user reference?
<poolie> that's a good list
<Lo-lan-do> Two meetings a day?  WHat kind of bureaucratic monster has #bzr become?
<mrevell> Lo-lan-do: The other was yesterday my time :)
<fullermd> He's just trying to have one without me around.
<Lo-lan-do> mrevell: Mine too, but one every twelve hours still qualifies as two daily here :-)
<mrevell> * The user manual: should this become a straight tutorial, with the reference materials moving into the user reference?
<mrevell> Lo-lan-do: Fair point :)
<poolie> Lo-lan-do, they won't repeat daily
<lifeless> btw,
<mrevell> So, starting with the user reference: have you noticed any obvious gaps in bzr help?
<lifeless> packs are now annotation-free; this means their initial commit for any experimentation will be 30 seconds faster than they were yesterday.
<lifeless> and I'm going to eat, sorry mrevell I will read and comment on minutes though, if there are any
<mrevell> lifeless: thanks
<poolie> mrevell, i think there are some gaps,
<mrevell> lifeless: I'll post minutes to the bazaar list later today
* lifeless waves
<lifeless> ciao
<poolie> there's a gap that the commands are not always explained from the right perspective of the person first reading about the command
<mrevell> poolie: Ah, interesting.
<poolie> a good example might be, um
<poolie> well, an ok example is 'bzr help send'
<poolie> it seems a bit like it just jumps into the details
<mrevell> poolie: Yeah, I can see that.
<poolie> i think the other thing that may be happening with the manual vs reference
<poolie> is that the reference is taken from the materials in the help text
<poolie> if we stick with this distinction, the online help will be all reference-type material, not introductory
<poolie> and i'm not sure that's quite right
<poolie> maybe it's ok, as long as they have a brief introduction to whatever topic they're talking about
<mrevell> Right, yeah, I agree the online help should continue to have an introduction to each topic and should ease the reader into it
<poolie> mrevell, did people say more yesterday about what that split should be?
<mrevell> poolie: Just a moment, I'll put out a quote.
<mrevell> fullermd suggested dividing the documentation along these lines, which I broadly agree with:
<mrevell> fullermd	One is the "quick start".  That's the "bzr in 5 minutes", the "here-kid-the-first-one-is-free" stuff.
<mrevell> fullermd	The second is the more miniseries-style tutorial stuff, which are individual pieces, but follow a reasonable progression without too much overlap.  Taht would be the "Learning bzr" sort of doc.
<mrevell> fullermd	And the third would be the reference.  In-depth discussion of commands and use-cases, lists of config options and revspecs, et
<mrevell> Although I take the point that the reference must include introductory material for the online help.
<fullermd> You can model those three as "get the flavor of bzr/get a recipe for a quick project contribution", "learn bzr", and "reference bzr".
<poolie> that sounds pretty good
<mrevell> So, for the user reference we have the suggestion that not all entries are correctly targeted at someone who needs an introduction to a command. Thanks for that poolie.
<mrevell> Thanks fullermd also
<poolie> i think the only thing to do is to go through them one by one with new-user glasses on
<mrevell> poolie: I have those glasses :)
<poolie> i think the main thing is that the first bit of the description should be a 1-5 sentence summary of what the command is for
<poolie> the purpose
* pbor would like a tips-and-tricks page/FAQ with quick oneliners for common stuff
<mrevell> thanks pbor
<pbor> I just expressed the desire to have it not to write it, so nothing to thank me about :)
<mrevell> poolie: Some of our descriptions are quite a bit longer than 1 - 5 sentences right now. One thing that came up yesterday was that it's sometimes difficult to be concise
<mrevell> pbor: Thanks for the suggestion :)
<mrevell> poolie: Although obviously we can make the writing as tight as possible
<poolie> pbor, yes, i think a faq would be a good idea -
<poolie> particularly a single clearly-identified faq
<poolie> i've been wondering if we should use answers.launchpad.net for that
<poolie> (which i posted about recently)
<poolie> it has some advantages, like trying to guide people who have new questions to the existing answers
<mrevell> poolie: So, I like the idea of ensuring the most important info is in the first 1 - 5 sentences
<poolie> and linking to bugs if the answer relates to a bug, though at the moment only weakly so
<poolie> ok
<poolie> i agree that sometimes it is hard to fit it in that limit
<poolie> this is partly a problem of knowing just how much you ought to explain
<poolie> obviously we don't want every command's help going from first principles
<mrevell> poolie: I'll tkae an action item of looking at a good way of using the Answers FAQ system for bzr
<mrevell> I'd like to move onto the user manual, unless anyone has more to say about the user reference.
<poolie> sure
<poolie> so for the manual
<mrevell> I think the user guide's weakest point, at the moment, is in advanced topics.
<mrevell> Perhaps some material could move out of the current tutorial
<mrevell> into advanced topics
* fullermd somewhat disagrees.
<mrevell> fullermd: Please go ahead
<fullermd> Well, it could just be a taxonomy issue, in what we want to have where.
<poolie> in fullermd's description it looks like there's just one pretty short tutorial, and then the user's guide, and not a long tutorial
<fullermd> But I think of a user guide/manual to be the thing you sit down and read through to understand the program and what you'll do with it.
<fullermd> The current User Guide is just a collection of rather independent articles.  It's random-access.
<fullermd> (that may be a more meta position than we want to go into, though)
<mrevell> fullermd: I agree that we need to make the user guide more cohesive, and that each section should progress naturally one to the next.
<fullermd> We don't currently really have a place where we can say to new users "Go here, and read from here to there, and you'll have a good understanding of bzr"; that's what I'd want a User Guide to be.
<fullermd> (in fairness, that doesn't seem to be what the current UG is _trying_ to do, so...)
<poolie> i agree about cohesion and flow too
<poolie> i think that's because it's acreted rather than because it's particularly what people want
<fullermd> Yah.  It's more a "Hey, we have these docs; we better link to them all".
<poolie> so what, if anything, would be the difference between such a guide, and an extended tutorial?
<mrevell> fullermd: Right. So, as a relatively inexperienced Bazaar user I'm in a good position to see how we should shape that sort of guide. I think your three split model is a great suggestion but I'm concerned that, because the user ref is also bzr help, we shouldn't overload that. Perhaps we need a rewritten tutorial and then further articles that cover "further reading" type topics
<poolie> it seems like they might cover the same concepts and commands
<poolie> but a tutorial has more of a continuing worked example
<fullermd> None, really; that's sort of where I want it to be.  Go in one end of it new, come out the other end with a working bzr gestalt.
<poolie> mrevell, what kind of thing are you thinking of as 'further reading'?
<fullermd> When I read "tutorial", I tend to read it more as "recipe"; it tells you the steps, and maybe a little about why you take them, but it doesn't leave you with the gestalt.
<mrevell> poolie: For example: hosting a team branch in Launchpad, or running a bzr smart server.
<fullermd> Well, that comes back to my opinion about the place of 'bzr help'.  But I think I'm minority there.
<mrevell> poolie: Topics that aren't essential to everyday use of bzr
<fullermd> I think the User Guide should very much reference the User Reference for more in-depth coverage.
<mrevell> poolie: and perhaps that won't be applicable to everyone.
<fullermd> e.g., the USer Guide should talk about the smart server and why you might use it, but setting it up should be the Reference's province.
<poolie> actually i disagree about that particular case
<mrevell> fullermd: I think my concern there is that it's not necessarily a clean break between the two.
<mrevell> poolie: Ah, okay. Well, perhaps using some of the community's tools such as bzr-svn.
<poolie> ok, so the guide should give you a map to most of the content in the reference?
<fullermd> I picture the guide as giving you a solid working understanding.  Read it, then you can comfortably use bzr for your projects.
<fullermd> Reference would be more details of each command and its options (--reprocess was an example I used yesterday) and more involved cases where you'd use them, detail coverage of a spectrum of workflows, etc.
<mrevell> fullermd: Do you think all of that should be in the online help?
<poolie> my default position for the online help
<fullermd> I don't, no.  I want quick-ref.  "I know the concepts, remind me where this command fits and what options it has".  Describing just what the options do and what their side-effects are can be a multi-paragraph endeavor.
<poolie> (i'm willing to change)
<poolie> is that, well, what fullermd just said, pretty much
<poolie> a typical user, if they only had the help and not the guide, could work things out but they'll need to piece it together by themselves
<mrevell> right
<poolie> ok
<poolie> so on the guide in particular
<poolie> i think we want to get rid of the section called 'tutorial'
<mrevell> poolie: Yeah, and make the guide itself work as a tutorial
<mrevell> poolie: in that progresses the user through each topic
<mrevell> coherently
<poolie> maybe a good place to start would be to just change it's index.txt to incorporate an outline of what should be there
<fullermd> I'm hoping in the next week or two work will calm down enough that I can sketch out an outline for my ideal UG.  Hardly had time to breathe lately   :(
<mrevell> poolie: Okay, I'll change the index.txt to create an outline of where I think we should go and then we can get a discussion going on the list.
<poolie> at the moment 'configuration' is one of the first topics
<poolie> did you get enough feedback on the 5 minutes doc?
<poolie> i glanced at it and it looked godo
<poolie> good
<mrevell> poolie: Yeah, I got some great feedback, thanks. In particular, I've got some good feedback on how to pitch it. I was worried that I'd used the slightly wrong tone and that was confirmed
<mrevell> Someone said one part was a little too "cutesy", which I think was a fair comment.
<mrevell> Right, well, thanks for your time guys. Over these two meetings I've had some very useful input. I'll write up the minutes of these two meetings and post them to the bazaar list today.
<mrevell> Unless anyone has anything further they'd like to add, I'll close the meeting and continue discussion on the list.
<poolie> just one more thing
<mrevell> yeah?
<poolie> one more open issue is this: there are several ways
<poolie> you can set up to use Bazaar
<poolie> so at the moment we have centralized_workflow; we could also talk about team branches, or using pqm, or other thnigs
<poolie> similarly, shared repositories vs standalone branches vs checkouts
<poolie> there's potential for confusion
<poolie> i guess
<fullermd> Well, for the latter, I think a good Fundamentals piece will cover that well (as I blathered about at excruciating length on the list)
<poolie> we should be clear about what the mainstream method is
<mrevell> right
<mrevell> but present the alternatives and why you might want to use them
<fullermd> For the former, I think that needs a chapter in the Manual, and emphasizing that it's a continuum rather than a set of points.
<poolie> the former?
<fullermd> The workflows
<fullermd> At one end is a single shared branch everybody works on, at the other is individual branches full-mesh merging, and everything else is in between.
<poolie> ok
<fullermd> I have an idea of tackling that by starting with the single-branch case, and walking up through more and more distributed bits until it finally becomes full-mesh.
<poolie> and then maybe the reference should describe the constituent parts
<fullermd> But you could also go the other way.  Or describe the ends, then walk inward from both.  I haven't decided which I like better
<fullermd> I think what's needed is to cover the continuum, then pick a small handful (3, 4 maybe) points along it and describe how you'd use them specifically, and what use-cases they might well fill.
<mrevell> I have to admit that this is an area where my lack of experience with bzr lets me down. I understand that there are different workflows but I'm sketchy on when is best to use which workflow.
<fullermd> Not sure how to split that between Guide and Reference, though.  The whole would be too big and deep for Guide.
<fullermd> (obviously, I'm a big "understand the concepts, then the 'real' instances are Obvious(tm)" guy.  That may be a blind spot.)
<poolie> tutorials as such do tend to start out with specific examples
<poolie> anyhow, that gives us something good to go on with
<poolie> thanks, mrevell
<poolie> i'm done if you are
<mrevell> fullermd: I worry that starting with the concepts could overwhelm people.
<mrevell> but obviously there's basic ground that needs to be covered to understand what follows
<mrevell> yes, thanks poolie
<mrevell> poolie: I have some great action points and input from these two meetings
<fullermd> Yeah.  It's a problem   :(
<mrevell> I'll write the meetings up for the list and come up with a first draft contents for the tutorial.
<mrevell> I think I'll be relying heavily on community input for the more advanced topics.
<mrevell> Thanks everyone.
<vila> poolie: ping
<vila> poolie: err, a bite late maybe :-/
<fullermd> Is it a bug that heavy checkouts don't inherit the branch nick from their branch?
* fullermd thinks it is...
<Enquest> How can I make sure that "bzr add" ignores a few directories
<poolie> Enquest, add them to .bzrignore
<Enquest> poolie, could you point me to the docs for this
<Enquest> Where is .bzrignore located?
<Enquest> on my home tree on the server tree?
<poolie> Enquest, just in the root of your source tree
<Enquest> there is no file there .bzrignore?
<Enquest> I have to create it
<Enquest> ?
<poolie> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/tutorial.html
<poolie> search for 'ignor'
<poolie> you can either create it, or use the 'bzr ignore' command
<poolie> to create it and add patterns to it
<ubotu> New bug: #148030 in bzr "Heavy checkouts don't inherit nick" [Undecided,New]  https://launchpad.net/bugs/148030
<pbor> speaking of docs, am I the only one to think that in the quick start guide branching a remote branch should come first than creating your own repo?
<fullermd> I don't think that way, no...
<fullermd> (at least, necessarily)
<pbor> maybe it is just me, but I think it is way more common to start using a vcs when joining a project that already uses it than starting a new project
<pbor> usually it goes: "I want to fix this with a patch, how do I get the code"
<pbor> when I start a new project and I pick a vcs chances are that I am already familiar with the vcs I pick
<fullermd> Well, but the steps of using it are pretty much the same, and it's simpler to start describing in isolation (IMO)
<gabe> Enquest: bzrignore is in your home dir
<pbor> fullermd: dunno, I know that each time I read cvs/svn/bzr doc when I started using them it got on my nerves... every time I thought "I do not want to create no f. repo, I don't even know what a repo is! Just tell me the command to get the code"
<fullermd> Well.  That gets into why I *HATE* quick-start docs.
<pbor> fullermd: if I read I quick start doc I just want to get the job done, I am not interested in the theory, so I prefer to order things by how often they are needed... a full reference is a different matter, there I agree that things should go in logical order
<sabdfl> hey revisionistas
<vila> sabdfl: hi
<sabdfl> vila: what's news in bzr-land?
<sabdfl> is there a bundle-buddy page where I can see what's in the queue for review and landing?
<jelmer> sabdfl: see http://bundlebuggy.aaronbentley.com/
<vila> Well, I don't follow as closely as I wish, but lifeless is working on big improvements with pack formats
<vila> http://bundlebuggy.aaronbentley.com/ will show you all pending patches
<vila> bulk of lifeless work does not appear there of course only bits he can merge now to bzr.dev
<vila> also, spiv is working on some smart server improvements also not shown on BB
<vila> but both their works are supposed to land for 0.92, so soon
<sabdfl> thanks vila, that's a nice list
<vila> sabdfl: you're welcome, but take it with a grain of salt, that's mostly my personal view, I may miss some parts
<vila> sabdfl: and finally, mrevell is working on the doc, but you should know that ;)
<fullermd> And I'm just sitting around stirring up trouble, as usual.
<vila> and giving good hints for docs ;)
<fullermd> Well, yeah, in the sense that "someone else should write them the way I think they should be"   ;p
<sabdfl> heh
<sabdfl> every good project has a good curmudgeon
<lifeless> vila: the packs patch is pretty small now, the review I got today gets rid of the largest non-format delta
<lifeless> anyhow, its *sleep* time, just dropping by for a last minute irc fix ;)
<vila> lifeless: glad to know :) Will tell it to sabdfl :)
<vila> lifeless: have a good night
<lifeless> only remaining must-do-before-merge of everything is the index layer; need to give keir's proposed format a fine toothed go-over and profile, or make the toy format do bisection
* lifeless waves
<sabdfl> light lifeless
<Lllama> Afternoon all. Anyone managed to get Trac working with bzr? I'm getting errors about it not being a Svn repository.
<orutherfurd> hi, anyone have any tips for sharing a branch using ssh?  I think I'm running into bug 50568
<ubotu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]  https://launchpad.net/bugs/50568
<fullermd> Well, my solution doesn't really help you   :)
<Sigma> Lllama: did you include "tracbzr.* = enabled" in your components ?
<Lllama> Sigma: Yep. I've got [components]  tracbzr.* = enabled at the bottom of the ini file.
<Lllama> Various bzr related messages show up on the source browser of the subversion repositories, so I'm guessing that the plugin is working.
<abadger1999> Lllama: I can pastebin a working config for you if you still need it.
<Lllama> abadger1999: Worth a look. Cheers.
<abadger1999> Lllama: http://pastebin.ca/723121
<Lllama> abadger1999: cheers. You've got a couple of extra lines, so I'll try playing with them.
<abadger1999> Cool.  Hope it helps!
<Lllama> abadger1999, Sigma: thanks for the pointers. Upgrading from 0.9 to 0.10 was the key.
<abadger1999> Great
<james_w> orutherfurd: you can correct that via chmod/chown.
<fullermd> Only temporarily.  Later pushes can still screw it up when they create new dirs.
<orutherfurd> stupid question, I'm sure, but is there any way for paramiko to explicitly create directories w/same owner and permissions as parent directories?  or to change them after the fact?
<fullermd> No, the problem is the setgid.  The sftp server strips it.
<fullermd> So paramiko can _say_ to set it, but it won't get set.
<orutherfurd> ah, that's unfortunate ;-)
<fullermd> bzr+ssh is probably a workaround.  And the better choice anyway, if you can run with it.
<fullermd> My workaround is to not use a system with SysV filesystem semantics   ;)
<orutherfurd> yeah, I saw that as a suggestion, but one of the big draws for using bzr was not having to install any software on the server
<orutherfurd> easier to fly below the radar
<NfNitLoop> I don't think bzr+ssh requires installing bzr?
<NfNitLoop> or am I getting them mixed up?
<orutherfurd> oh, maybe I was misunderstanding -- I thought that was the 'smart server'
<fullermd> Yes, it does.  Otherwise you'll have a lot of trouble with the 'bzr' part of it.
<NfNitLoop> Ooh.  it's bzr tunneled over ssh.  Duh.
* NfNitLoop reads scrollback before commenting further.
<jelmer> phanatic: ping
<phanatic> jelmer: pong, i saw you've subscribed a bundlebuggy :)
<phanatic> jelmer: got your mail as well. it's awesome, thanks for your work!
<fullermd> Oog.  I hate it when a annoying-but-harmless bug turns into an annoying-but-harmful one   :(
<jelmer> abentley: ping?
<jelmer> phanatic: we don't seem to be able to vote yet :-/
<phanatic> jelmer: yeah, just noticed...
<fullermd> Can somebody more official take a look at bug 114615, particularly in light of the comment I just posted on it?
<ubotu> Launchpad bug 114615 in bzr "AssertionError trying to commit with 0.16.0" [High,Confirmed]  https://launchpad.net/bugs/114615
<fullermd> I feel the desire to bump Importance to Critical for that, but that's above my paygrade.
<jelmer> fullermd: please update that bug to reflect that it affects bzr.dev and 0.91
<fullermd> Hm.  I mentioned it in the comment.  Is there an Affects field I don't see?
<jelmer> There should be a "Edit Description/Summary" link or something on the left
<fullermd> Ooh, the title?  Gotcha.
<fullermd> Damn thing bit me on a real project earlier today.  That was fun to try and reproduce...
<jelmer> ouch
<james_w> if I do mv a b in one branch and edit a in another I get a conflict upon merging the move to the edit. That seems wrong to me.
<james_w> also there is no way to resolve it so that the move gets recorded.
<fullermd> I've not seen that.  A quick test doesn't show it here either.
<james_w> ah, it works this time, I don't know what I was doing there.
<fullermd> I blame violent video games, personally.
<james_w> fullermd: nice bug.
<fullermd> Hrmph.  *I* didn't think it was so nice   ;p
<fullermd> 2 revs down the line...   "WTF?  Why is this totally vital file that's existed in the project for months 'unknown'??"
<james_w> :(
<fullermd> It gave me just enough time to get over "Hmph.  That wacky assertion failure that works the second time isn't fixed yet?"
<fullermd> The test case might be trimmable a bit farther.  I think you need the re-rm'd directory to trigger the assert (and so you need a change in that file deleted), and I presume it's the "other file from the same dir mv'd into another dir" bit that triggers the "rm'd/unknown" bit.
<fullermd> So maybe some of the other files aren't necessary.  But I don't have time today to try and work up truly minimal cases   :|
<james_w> I don't think the second directory is needed.
<james_w> I have just sent an analysis to the report though, so the test case can be trimmed using that.
<fullermd> Probably not.  It's part of an earlier attempt I made at trying to figure out what of my real project brought it about.
<james_w> it was good enough to pinpoint the problem though, so thanks.
<james_w> indeed the second dir is not needed.
<fullermd> Maybe the bug is really "What the hell are you doing to your poor branches?!"
<james_w> changing, renaming and deleting your files all at once? You expect me to merge that?
<fullermd> "Rise up against your oppressors!  Power to the branches!"
<lifeless> james_w: thanks
<james_w> lifeless: no problem.
<james_w> lifeless: is there enough there for you to see the problem?
<james_w> and is the renamed entry the conflict generates the right thing?
<ubotu> New bug: #148287 in bzr "Should be able to refer to historical files by file-id" [Wishlist,New]  https://launchpad.net/bugs/148287
<phanatic_> jelmer: ping
<jelmer> phanatic: pong
<jelmer> phanatic: just sent an email about bundlebuggy
<jelmer> phanatic: you should be able to vote now
<phanatic> jelmer: the main problem is that i can't log in
<jelmer> phanatic: can you try again?
<phanatic> sure
<phanatic> jelmer: doesn't work :(
<jelmer> phanatic: please try again
<jelmer> typo in your username :-/
<phanatic> jelmer: works now, thanks :)
<Rotund> hi.  My company is looking into a new scm/vcs, and they have some questions about bazaar
<Rotund> someone got time to answer some questions?
<Rotund> hello?
<Rotund> Does bzr have support for locking individual files?
<luks> locking as in "CVS-like locking"?
<Rotund> like "noone can change this file"
<luks> no, it doesn't (by design)
<Rotund> That's actually a problem for us
<luks> if you need locking (which I think you don't), then you probably want a strictly centralized vcs
<Rotund> I understand for things actively developed.  We do a lot of testing and have actual releases.
<luks> in bzr you create a couple of branches and then merge them, instead
<Rotund> One thing the people I work with are concerned about is limiting changes to files after they have been reviewed.
#bzr 2007-10-03
<Rotund> This is particularly important for things like tests that should be reviewed long before the last one is written.
<luks> well, that is a different problem
<Rotund> I suppose you could do a "reviewed" branch and limit commit rights
<luks> I think that's the most common solution the branch/merge development model
<Rotund> I've got a lot of concerns I have to alleviate if they consider it.
<Rotund> Mostly it'll need a new process definition.
<abentley> Distributed version control usually works on the basis that it's easier to get forgiveness than permission.
<Rotund> Or you throw a fancy gatekeeper or plugin in to do it.
<Rotund> We're in the kind of business where people die if we mess up, so people want tight control.
<abentley> Well, even so, anyone can work on any file at any time.  It's hoped that the changes won't conflict, but running the risk of conflicts is considered worthwhile for the benefits it gives.
<abentley> Gatekeepers don't necessarily have to be fancy.  If you have reviewers, they can be the gatekeepers.
<Rotund> I think it's a great model for full development, but I'm wondering how to make it work w/ 100 independent tests.
<Rotund> true, true.  Just gotta make sure THEY know the rules.
<Rotund> that's much easier.
<Rotund> can BZR do automated header generation?
<abentley> Rotund, no, but it has hooks for running scripts on commit.
<Rotund> Hmmm.  That should work.
<Rotund> I definitely like the idea of a PQM.
<Rotund> That to me would be great.
<Rotund> keeps people from doing that stupid commit on Friday night that breaks everything.
<Rotund> Or worse... before going on vacation.
<Rotund> I'll definitely have to look into how to do plugins.
<Rotund> Any support for things outside straight text?
<Rotund> A way to diff docs would be great, but rtf files should be doable, right?  That's text I think.
<Rotund> (can't wait for docx/odf)
<abentley> The tool will not damage binary data, but does not have inbuilt support for diffing other types.  There is a plugin that lets you use an arbitrary diff
<Rotund> okay.
<Rotund> Hmmm.  Can you write a plugin that can add attributes to files?
<Rotund> Like, can I have one that would add an attribute "reviewed" that's a boolean?
<schierbeck> hi guys
<Rotund> hi
<schierbeck> phanatic: bundle-buggy kicks ass
<phanatic> schierbeck: indeed :) huge thanks to jelmer for setting it up!
<schierbeck> jelmer rules :)
<spiv> lifeless: sent
<poolie> lifeless, did you build debs?
<lifeless> poolie: build failure
<lifeless> its a background task, cycling on it all day
<poolie> np
<poolie> lifeless, for johnf's patch i'm just going to add a test in RemoteTransportRegistration to make sure we can get the transport
<poolie> ok with you?
<lifeless> poolie: sounds good
<lifeless> abentley: beautiful name
<poolie> yep
<poolie> continuing the buggy theme
<lifeless> as well as being trac inverted
<poolie> i think it's bogus for attempt_lock to explicitly check transport.is_readonly
<poolie> rather than just letting the lock attempt fail
<lifeless> I agree
<lifeless> it may have been a premature optimisation
<poolie> i'd like an  attempt to commit to a readonly transport to say:
<poolie> bzr: error: cannot commit to http.........: transport is readonly
<lifeless> well
<poolie> it might be a bit clearer to say "location is readonly"
<lifeless> it could be that its readonly
<lifeless> $location cannot be locked (it is readonly)
<poolie> actually, right
<poolie> raising it from the lockdir layer is good
<lifeless> $location cannot be locked (IO error creating lockdir)
<lifeless> etc
<poolie> it's probably reasonably clear to say 'cannot be locked'
<poolie> and follow it with the underlying message
<poolie> do you think people will understand why?
<lifeless> I think it is an improvement
<lifeless> I don't know if its enough
<james_w> I don't think it is enough.
<james_w> poolie: just for reference, some commands that require a write raise LockError (well, a subclass), others I think raise TransportNotPossible, and there are probably some that raise something else.
<james_w> the transportNotPossible one is at least partially intelligible, if only because it is not an internal error.
<poolie> james_w, yes, i can see there is some unneeded diversity
<poolie> what do you think would be a good message?
<james_w> If you can't be more specific to pick out the protocols where this is likely a user misunderstanding, then at least put readonly in there, even at the risk of being wrong sometimes.
<poolie> james_w, i looked for your previous patch btw but couldn't find it
<poolie> what we want to communicate seems to be
<poolie> - you were trying to write to $url and couldn't
<poolie> - this is the expected behaviour, not a bug
<james_w> You don't have to assert that it is readonly, just that it is a possibility, and perhaps hint that the user should check the transport they are using. (Maybe using urlspec as a pointer).
<poolie> - because you can't write over $protocol
<poolie> it might be good to hint you could use another protocol
<james_w> You were trying to write to $url and couldn't. This is usually because $transport is readonly. You may be able to use another transport to complete the operation see 'bzr help urlspec' for details on the avaiable transports.
<poolie> if we fix this for readonly protocols people will still hit similar situations when eg they don't have permission for that directory
<james_w> or perhaps 'bzr help transports' which would explain the issue in more depth, and then point to urlspec. Perhaps it could suggest the common ways to change the transport.
<james_w> poolie: yes indeed. Perhaps that could be another sentence. However transport issues seem to be far more prevalent.
<lifeless> I don't think transport and urlspec should be separated
<lifeless> urlspec is afterall simply the address of a transport
<lifeless> poolie: can't write over transport OR can normally but some [transient?]  limitation has occured
<poolie> yes, i know
<lifeless> righto
<poolie> i think this will be sufficiently improved by
<poolie> just:
<poolie> failed to lock $url: $reason
<poolie> as a noninternal error
<poolie> also, i wish there was a more systematic way to handle remote errors in hpss
<spiv> Yeah.
<spiv> Me too...
<lifeless> wow
<lifeless> I can't wait for packs to be in mainline
<lifeless> pushing to knits is painful :(
<lifeless> (its annotating every changed file)
<lifeless> poolie: on error codes
<lifeless> things like pull use exceptions to signal 'can't pull'
<lifeless> but '3' as the return value seems a little weird to me
<lifeless> yo i386
<i386> hey lifeless
<i386> I thought id come and idle here :)
<lifeless> great idea
<poolie> lifeless, i think pull should return 1
<i386> Id like to think so :)
<poolie> you understand that i didn't change that behavior with my recent patch?
<lifeless> poolie: I know, it just got me thinking
<i386> lifeless: perhaps I can offer some of my time at some point
<lifeless> poolie: that perhaps exceptions that are not internal should have a .errno attribute
<poolie> maybe errors should have an attribute to say their
<poolie> jinx
<lifeless> i386: even better idea :)
<i386> Im writing that allocator, btw
<lifeless> excellent
<i386> lifeless: have you heard of Hoard ?
<lifeless> yes
<i386> Its a really advanced memory allocator
<i386> ahh
<i386> Im thinking of writing a obmalloc.c that uses it
<i386> and doing some more profiling if my current reasoning is correct
<lifeless> did you establish that allocation time was the root cause?
<i386> not yet
<lifeless> or is it still speculative?
<i386> yes, speculative - but ill have that answer in the next few days
<lifeless> cool
<i386> Im reading a lot of material at the moment to counter my lack of a Computer Science degree
<i386> for this particular problem
<lifeless> hmm, I wouldn't expect a CS degree to necessarily help
<lifeless> this domain is a little specialised
<lifeless> as well as being NPC IIRC
<i386>  NPC?
<lifeless> non polynomial complete
<lifeless> IIRC memory allocation has been shown to be equivalent to the knapsack problem
<lifeless> time to test commit again
<lifeless> now I've just done mass merges
* lifeless bets it will have backslid
<i386> lifeless: can I get the url for your experimental branch ?
<lifeless> of course
<i386> thanks
<lifeless> it, and details for how to dogfood, are all on the list
* i386 nods
<lifeless> if you goolge for robertc packs repository dogfood
<lifeless> you'll get the first post
<lifeless> uhm, look for [PACKS]  in the message listing, last one was late last week
<lifeless> poolie: I'm gagging for reviews now
<lifeless> hmmm, 1m28
<lifeless> not too bad
<lifeless> twice the speed of knits :)
<lifeless> initial commit:
<lifeless> real    3m49.358s
<lifeless> user    1m28.650s
<lifeless> sys     0m5.840s
<lifeless> incremental:
<lifeless> real    0m25.878s
<lifeless> user    0m23.797s
<lifeless> sys     0m1.372s
<lifeless> partial incremental:
<lifeless> real    0m26.801s
<lifeless> user    0m19.969s
<lifeless> sys     0m0.768s
<spiv> i386: a lot of effort has gone into the design and implementation of the CPython memory allocator.
<lifeless> spiv: I mentioned this :)
<spiv> i386: so I will be pleasantly surprised if you can do better :)
<i386> spiv: im probably completely wrong but leave learning something out of the ordeal
<lifeless> night all
<ubotu> New bug: #148443 in bzr "progress bar for loading tests" [Wishlist,Confirmed]  https://launchpad.net/bugs/148443
* Starting logfile irclogs/bzr.log
<lifeless> poolie: latest packs pushing now
<lifeless> i386: ^
<lifeless> revno 2788
<i386_> hey lifeless
<ubotu> New bug: #148463 in bzr "structured way to remote exceptions" [Medium,Confirmed]  https://launchpad.net/bugs/148463
<i386_> lifeless: what software do you use for bazaar-vcs.org ?
<AnMaster> i386_, hm I wonder that too
<AnMaster> very nice wiki they have there
<elmo> it's moin
<AnMaster> hm looking at http://bazaar-vcs.org/RecentChanges it seems to be moin
<AnMaster> ah elmo beat me to it
* AnMaster prefers trac himself
<AnMaster> or mediawiki, for larger projects
<i386_> AnMaster: 's/mediawiki/Atlassian Confluence/'
<fullermd> Mediawhati?  Trunk?  Are those new versions of vi?   :p
* i386_ is a bit of a company shill sometimes
<AnMaster> i386_, link?
<AnMaster> <fullermd> Mediawhati?  Trunk?  Are those new versions of vi?   :p <-- why? I use emacs myself :P
<hsn_> i think Eclipse is new version of gViM
<i386_> AnMaster: http://www.atlassian.com/software/confluence
<i386_> AnMaster: we give free licenses of our products to open source projects
<i386_> because we love you guys
<AnMaster> not open source though
<fullermd> AnMaster: Well, I only have a gig and a quarter of RAM, so I can't use emacs...
<i386_> no but liberally licensed though
<AnMaster> if not OSI approved license, forget it ;P
<i386_> you buy a license and you get the source :)
<AnMaster> i386_, only non free software on my computer would be bios and nvidia drivers
<AnMaster> (anyway this seems to be getting off topic)
* i386_ shrugs
<Keybuk> I have a random question
<AnMaster> well ask it then?
<fullermd> I have a random answer   :)
<Keybuk> why is it that when I bzr branch with an sftp:// URL, I get a .bzr/branch/parent
<jelmer> hey Scott
<Keybuk> but when I bzr branch with an http:// URL, I get a .bzr/branch/branch.conf ?
<AnMaster> interesting
<jelmer> Keybuk: same branch?
<fullermd> Because the branch you're branching over sftp is a branch5, and the branch over http is a branch6.
<jelmer> Keybuk: it may be different between formats, but it should not be different per transport
<AnMaster> um? what is branch5/6? is this related to formats lke
<AnMaster> like* dirstate?
<fullermd> 'dirstate' (and 'knit') use branch5.  dirstate-tags uses branch6.
<AnMaster> ah
<AnMaster> so then I use branch6
* fullermd stabbies rollup names.
<AnMaster> good to know
<Keybuk> ahh
<AnMaster> fullermd, btw, is there any way to see tags in trac-bzr?
<Keybuk> interesting
<AnMaster> haven't found a way
<Keybuk> it makes a difference, because it means that branch6 branches remember where you push them to
<fullermd> No idea.  I've never used trac, bzr or otherwise.
<Keybuk> whereas branch5 branches don't
<fullermd> No, branch5 branches remember.
<fullermd> They just pollute locations.conf with it, instead of storing it in-branch.
<Keybuk> (instead ~/.bazaar/locations.conf remembers for you, so if you move the directory, it forgets)
<AnMaster> fullermd, how does this work with shared repos, like if you run bzr upgrade --dirstate-tags in one branch in a shared repo
<AnMaster> what will happen then?
<fullermd> AnMaster: Shared repos only share the repo format.  The branch and WT formats can differ inside it all you want.
<AnMaster> ah
<AnMaster> WT?
<i386_> fucking LOL
<fullermd> Working Tree.
<AnMaster> ah
<i386_> This guy just posted anon his penis on /b/ except his name was in the exif data - so I tracked him down on face book
<i386_> and now /b/ is a whole lot less boring
<AnMaster> i386_, *slightly* off topic here I feel
<i386_> http://img.4chan.org/b/res/41472375.html
<i386_> oops
<i386_> wrong chan
* i386_ gets embarrassed 
<i386_> ahhh
<AnMaster> well, I have posted in wrong channels before (asking bzr questions in #trac by mistake for example) but nothing like that, (I'm not on channels like that)
<i386_> huh?
<i386_> 4chan is a message board for anime
<gabe_> nah don't worry not the wrong channel
<i386_> and japanese culture
<gabe_> i need some distraction from work
<fullermd> Right.  The rest of us have standards instead   ;>
<i386_> Anonymous are going to lynch this guy
<gabe_> although looking at 4inchers wasn't what i had in mind
<gabe_> infact i feel a bit queasy now :(
<i386_> :(
<i386_> err sorry everyone
<gabe_> np, you got any intellectually stimulating websites to redeem yourself with? :P something like benchmarks of UFS2 vs XFS or Ext4
<i386_> ahh
<i386_> found this neat website on garbage collection and memory management
<i386_> http://www.memorymanagement.org/
<gabe_> ok that's a good start :)
<gabe_> although not so much use for me as Ruby does all that for me
<jelmer> phanatic: btw, did you see my message about vizchanges?
<GaryvdM> Hi jelmer
<GaryvdM> I just busy replying to it :-)
<jelmer> hi Gary
<jelmer> GaryvdM: thanks!
<sakke> When I try to connect to a server i get the following error: Exception: Error reading SSH protocol banner(10054, 'Connection reset by peer')
<sakke> Traceback (most recent call last):
<sakke>   File "paramiko\transport.pyc", line 1448, in run
<sakke>   File "paramiko\transport.pyc", line 1564, in _check_banner
<sakke> SSHException: Error reading SSH protocol banner(10054, 'Connection reset by peer
<sakke> ')
<sakke> What's the problem?
<AnMaster> sakke, can you ssh in normally?
<AnMaster> also try sftping some file by hand
<AnMaster> if both of those work check the path you used to the server, right port and so on
<AnMaster> in case of typos
<AnMaster> sakke, any luck?
<JackPhil> it complains the pyrex not installed
<JackPhil> is it ok?
<luks> JackPhil, yes, it will still work fine, but a bit slower
<fullermd> It won't be slower if you're running from a release tarball; only from a dev branch.
<AfC> Is that local-area-ad-hoc-network branch-sharing thing that lifeless was working on published and usable?
* AfC is going to a hackfest this weekend and maybe could use it
<LeoNerd> Hmm.... I have a branch that's up to date, with respect to revisions, but is missing a tag compared to the server...
<LeoNerd> Is there some way I can force a resync of the tags?
<luks> bzr pull?
<LeoNerd> Hrm... That seems to have fixed it... Wonder why it didn't before...
<piedoggie> I think my bze repository lost touch with the launch pad repository.  this latest check in flagged in more files than it should have
<piedoggie> how can I reconnect the two?
<thumper> piedoggie: I don't quite understand your problem, would you care to explain a bit more?
<piedoggie> it is weird.  I buit a repository in launchpad
<piedoggie> and thought I uploaded files to it
<piedoggie> but is is empty
<piedoggie> so it make sense that my local copy only stored updates local
<piedoggie> I'll deal with it later.. I have a fire here that comes first
<james_w> put_bytes_non_atomic says "This function is not strictly safe to use. See Transport.put_bytes_non_atomic for more information."
<james_w> This is Transport.put_bytes_non_atomic. Can anyone tell me why it is not safe?
<ubotu> New bug: #148728 in bzr "Bzr gives ugly error error message on bzr+ssh:// timeout" [Undecided,New]  https://launchpad.net/bugs/148728
<BasicOSX> Does bzr do the right thing with spaces in the directory name when over-riding the things in your ~/.bazaar/locations.conf? I tried both spaces and %20 (for the spaces) and I cannot get the overrides to work.
<james_w> BasicOSX: I'm not sure I'm afraid.
<BasicOSX> [/Applications/World of Warcraft/Interface/AddOns/]  vs [/Applications/World%20of%20Warcraft/Interface/AddOns/] 
<james_w> bzr uses ConfigObj to that parsing, so you could check that.
<wingo-pb> good day!
<wingo-pb> can bzr do in-place branching?
<james_w> BasicOSX: it looks like configobj should pick it up ok.
<james_w> wingo-pb: what do you mean?
<BasicOSX> with space or encoded?
<wingo-pb> james_w: like i see with git and `git branch'; it seems useful rather than having repo parent dir and lots of branch checkouts
* wingo-pb looking at his ~/src/foo/trunk dirs, thinking that the step "trunk" can probably be omitted somehow
<james_w> wingo-pb: no it can't.
<ubotu> New bug: #148731 in bzr "Bzr gives ugly error error message when server requires non-existant ssh keys " [Undecided,New]  https://launchpad.net/bugs/148731
<ubotu> New bug: #148737 in bzr "Bzr needs a more decriptive error message when product does not exist on launchpad" [Undecided,New]  https://launchpad.net/bugs/148737
<james_w> however using bzrtools' switch command you can approximate it.
<james_w> or maybe cbranch. Or both, I can't remember.
<james_w> BasicOSX: are you on Windows?
<BasicOSX> no, OSX
<BasicOSX> recently moved to osx, so I'm struggling :-)
<james_w> BasicOSX: should have guessed from the name :)
<james_w> it looks like spaces should be used.
<wingo-pb> james_w: thanks for the info tho
<wingo-pb> is there a place that bzr devs look at for feature requests? ;-)
<james_w> wingo-pb: launchpad, or the mailing list for discussions.
<james_w> wingo-pb: though proposing git style branching won't get very far.
<wingo-pb> james_w: ah, there has been previous discussion in this regard? i occaisionally read the mailing list but must have missed that. anyway sorry to bother you :)
<salty-horse> hi. when running "bzr log|less" and quitting less before the command is done, I get a "IOError: [Errno 32]  Broken pipe" error on flush(). this is quite common in application, but it's especially annoying when ubuntu wants to report the crash. A fix was committed to win32, but I'm on Linux. see http://bundlebuggy.aaronbentley.com/request/%3Ces4ihj%24dcf%241%40sea.gmane.org%3E
<poolie> hello
#bzr 2007-10-04
<lifeless> poolie: call ?
<ubotu> New bug: #148787 in bzr "rpm packages out of date" [Medium,Confirmed]  https://launchpad.net/bugs/148787
<poolie> spiv, hi?
<abentley> fullermd: If you start with "branch5/branch6" then switch to "dirstate/dirstate-tags", you have only yourself to blame for the resulting confusion.
<spiv> poolie: hi
<poolie> spiv, i'm going to get some early lunch, can we talk after that?
<spiv> Ok.
<lifeless> mmm food
* lifeless hates on evo
<lifeless> poolie: ping re reviews
<abadger1999> lifeless: If you find a good replacement, let me know :-)
<lifeless> abadger1999: I hear telnet is
<mneptok> abadger1999: wat clay, a reed, and knowledge of cuneiform is far superior solution than Evolution
<mneptok> *wet
<abadger1999> hah!
<lifeless> mneptok: its funny cause its true
<abadger1999> I switched to t-bird from evo a month ago and was somewhat satisfied until the gpg plugin started causing it to hang.
<mneptok> lifeless: "funny" in that "i really chuckled as i tasted the gun oil" way
<poolie> lifeless, i'm reviewing your code
<lifeless> mneptok: you're heading for quotes page again
<abadger1999> I may have to try sylpheed-claws next.
<lifeless> poolie: thank you!
<lifeless> poolie: sypy is on tonight btw, I plan to head along
<mneptok> abadger1999: Claws' predeliciton for the "hey! welcome to your new day! remember that mail you imported yesterday? i deleted that for you!" was a bit annoying
<lifeless> poolie: I've sent 3 new up today I think
<lifeless> poolie: I'm going for lunch, if theres something you want to ask me about, ring me please
<poolie> hello mneptok
<poolie> nice to see you
<poolie> i wonder what claws is like these days
<poolie> really i just want a mutt that can search quickly, has a bit of mouse support, and doesn't spaz out when its connection drops
<mneptok> poolie: 'allo sahib :)
<jml> poolie: kind of like an offline gmail then?
<mneptok> poolie: Claws' performance vis-a-vis speed is excellent. performance vis-a-vis data integrity ... not so much. in my experience.
<poolie> jml, gmail is pretty close to doing it for me
<poolie> better keyboard support would be nice
<mneptok> Greasemonkey?
<poolie> builtin gpg handling would be good too, though i realize some hacks are possible with encrypting the clipboard etc
<jml> poolie: my main gripe is that it needs internet and "open next email" takes too long (because of internet)
<poolie> mneptok, you know you could probably get in trouble making that proposition to some people
<poolie> :)
<radix> poolie: I've been using some firefox extension to add gpg support to gmail. it's not bad.
<poolie> after using gmail for a while i just switched to evo to see how it was
<poolie> too many crashes
<mneptok> poolie: only if on follow-through my techique is sub-par ;)
<poolie> hello radix
<radix> hi poolie :-)
<lifeless> back
<lifeless> evo would be really good if its developers used it
<abadger1999> if it's developers used it, they'd all kill themselves.
<lifeless> nah
<lifeless> but they would fix it
<lifeless> hmm what to do
<poolie> spiv, hi?
<spiv> poolie: hello
<poolie> call?
<spiv> poolie: want to call?
<spiv> snap
<mneptok> lifeless: i find it unlikely Microsoft employees would actually use Evolution
<mneptok> *bah dum tish*
<lifeless> mneptok: bitchy
<lifeless> I like it
<mneptok> :)
<lifeless> poolie: replied to your review
<poolie> >Would you prefer a[:]  = []  ?
<poolie> well
<poolie> when i first read it, i didn't see the [:]  and wondered "why on earth is he deleting it"?
<poolie> then about 10s later i saw it
<lifeless> I find the del clearer
<lifeless> because [:]  list replacement is IME rarely used
<lifeless> and the point here is to preserve the instance of the list
<poolie> yes, i understand that
<lifeless> I wouldn't want someone to do a = []  as a 'cleanup'
<poolie> exactly
<poolie> maybe you should add a comment explaining you need to keep the instance?
<lifeless> sure
<poolie> so i find it a bit strange, though at the same time straightforward, that the meaning of 'del a' is utterly different from 'del a[...] '
<poolie> but, that's neither here nor there
<poolie> your response is fine with me, anyhow
<lifeless> thanks! 1 down, X to go :)
<poolie> oh, abadger1999 is toshio
<poolie> i presume
<abadger1999> Yep.
<abadger1999> Looking at the Fedora Packaging bug?
<lifeless> speaking of packaging, I've still got this glitch
<keir> abentley, ping
<abentley> pong
<lifeless> hi keir
<lifeless> keir: I've been poking a bit at your code. I'm concerned that the split between key names and data means the locality of reference win will be entirely nullified with todays access pattern and API's
<lifeless> keir: also, have you done any performance tests with your code?
<poolie> abadger1999, yes, but in particular this was the first time i remember seeing your name in mail, or at least the first time i made the connection
<poolie> it also made me smile because my partner is a tiki enthusiast
<abadger1999> Ah :-)
<lifeless> poolie: do I get any other reviews ? :)
<poolie> i've done all but one of them
<poolie> by BB's count
<lifeless> oh hmm
<poolie> i can do that one after matthew's, if you like
<lifeless> poolie: please do
<keir> lifeless, no, i haven't done any perf testing yet
<keir> abentley, if you're going to make a trac-killer, go for full distributed
<keir> abentley, and i feel rather strongly that the killer feature of trac is the pervasive wiki
<abentley> Well, it sounds like you need to write your own.
<keir> abentley, if i could have local editing of the wiki along with the trac wiki integration for tickets and such... sweeet
<keir> abentley, so you're not going to try distributed?
<lifeless> I think wiki integration is killer; I think trac's including the wiki is whack
<abentley> If it's successful, it might expand that way.
<abentley> But distributed is really complicated.
<lifeless> better to work closely with a wiki that is just a great wiki, than write a new one
<lifeless> abentley: btw, I love the name
<abentley> And I don't need that right now.
<keir> i was thinking something that used ReST
<keir> lightweight
<keir> actually, i like the name, but i think it is a bad idea
<keir> because it is not googleable
<keir> the new project 'review board' for example. WORST NAME EVER
<keir> try finding that one!
<abentley> lifeless: Thanks.  I saw it there, and I figured I had to use it, but it's probably just a working title.
<keir> lifeless, if we toss the split between data / key, then we can't topo sort
<abentley> I think it's amusing that "Trac" is actually a real word backwards.
<lifeless> keir: I'm pretty sure you are wrong
<keir> lifeless, then how are you going to find keys?
<keir> lifeless, you can't build a btree on keys anymore because they're not sorted
<lifeless> well
<keir> so you have to build a btree of keys to find their position in the topo sort... then you're back where we are now
<lifeless> so the split between keys and data just groups the data (small) away from the keys (large), but we need th ekeys to answer every query, so we access large data anyhow
<lifeless> I raised this in my first design review on the list
<keir> right
<abentley> keir: Making a distributed wiki is one thing.  That's basically just using Bazaar as a wiki backend.
<lifeless> another way of getting grouping is to keep the keys and data together, and to index on topological index
<abentley> But a distributed bug tracker with correct merging is a lot more complicated.
<lifeless> (that is, topo sort the names presentin the index, assign them in the result order numbers from 0->N-1, and order them that way)
<keir> lifeless, then you have another entire copy of the keys, no?
<lifeless> no
<lifeless> not at this point in the sketch anyhow :)
<keir> i give you a key. how do you find the data in the 'btree' say?
<lifeless> theres no tree in this thought experiment
<keir> ok
<lifeless> just linear grouping based on topo ordering
<keir> so how do you do better than linear scan?
<lifeless> finding an arbitrary key by name is linear
<keir> ok
<keir> so to beat linear
<keir> you have to build an index on the keys
<lifeless> not necessarily
<keir> to find their topo index
<lifeless> it depends on what operations are common
<lifeless> see, this pattern:
<lifeless> find key X
<lifeless> find key[X.parent] 
<lifeless> etc
<keir> right
<keir> but if you want to do better than linear for 1st step
<lifeless> are amortised linear(index size) for the first op, plus constant time for every additional step
<keir> you're sunk because you need to build an index on the keys...
<lifeless> there are two reasons to have fast access to an individual key
<lifeless> one is direct access to it
<lifeless> the second is to make the miss-case fast(because its as slow as the worst case key lookup)
<lifeless> its possible to address the second reason without addressing the first via bloom filters, if we want to.
<lifeless> bloom filters are very fast
<lifeless> now, I suspect we do need reasonably fast direct access
<lifeless> and I'm still mulling this
<keir> i don't see any way to have fast direct access without an index on the keys
<keir> which implies at least 1 copy of the keys sorted by keys
<lifeless> I suspect we have 2-3 versions of indices to get a really really good one
<lifeless> well, copy of the keys is misleading because you can index on much less than the sum of the keys
<lifeless> via e.g. hash'es, tries,
<keir> sure, if we go the hash route
<lifeless> you can probe in a hash table to get a list of byte offsets the key may be at
<lifeless> if there is nothing there, its not in the index, if there is, then follow it to see if its the one you want
<lifeless> no key data, and a variable length hash allows this to scale with index size
<keir> true
<keir> so hash to list of offsets?
<lifeless> don't need secure hashes here - the real data is always present, and we want it, so follow it to handle hash collisions
<keir> sounds reasonable
<lifeless> anyhow, project wise -
<keir> i can do that
<lifeless> I have 3 weeks more or less before UDS
<lifeless> but we freeze well before that
<lifeless> so here is what I'm thinking...
<poolie> lifeless, ok, all your patches that i can see are now merged
<poolie> i mean, reviewed
<lifeless> I toss a trivial 4K-fan-out prefix on the current index and do page-size bisection. This is for 0.92, and is better-but-not-ideal. We freeze the disk format with this, and continue working on your code - getting the design profiled and so on.
<keir> lifeless, sounds sensible
<lifeless> keir: does this make sense to you? It means there is no insane rush to get your index *right*, but its still in the pipeline.
<keir> lifeless, yes. if adding topo sorting isn't too hard, i'll do that after.
<lifeless> packs will be getting reved post 0.92 anyhow as the newer delta logic gets slotted in, so theres plenty of window to drop a new index layer in.
<keir> ok, i have to run
<poolie> lifeless, what if anything did you decide about the gsoc summit?
<keir> i may hop on over the weekend
<lifeless> keir: ok, bye!
<lifeless> poolie: hot damn I entirely forgot to look that up
<lifeless> you wouldn't happen to know where the announcement stuff is? I haven't been emailed about it so have no links
<poolie> uh i think it's next weekend so probably not
<poolie> http://groups.google.com/group/google-summer-of-code-mentors-list/browse_thread/thread/7632570e13d7813e/e69899cd12d7c7ad#e69899cd12d7c7ad
<poolie> iow, in two days time
<poolie> "can i borrow your jet?"
<lifeless> meep
<lifeless> guess not lol
<lifeless> hmm, bb says its reviewed, but I don't see mail about it
<lifeless> the fetch patch
<poolie> after i finish vila's patch i'm going to take a break as i have calls tonight
<poolie> then will submit my patch
<lifeless> ok
<lifeless> please let them know that the packs patch is very small now, with these things reviewed
<lifeless> and I'll be doing the index thing as the next priority
<lifeless> so Monday I hope to be sending in the last patch to remove the packs branch
<lifeless> that is to merge the entire thing
<poolie> lifeless, what is the real difference in intention between tests/blackbox and tests/commands?
<poolie> the docstring is not very enlightening
<lifeless> search me, let me look
<lifeless> vila seems to have created this
<lifeless> poolie: commands/ invokes the objects directly
<lifeless> poolie:         cmd = cmd_cat()
<lifeless>         cmd.run(self.get_url('branch/foo'))
<lifeless>         self.assertEquals(1, len(self.connections))
<lifeless>         self.assertEquals('foo', self.outf.getvalue())
<lifeless> so it is avoiding the run_bzr* infrastructure, its a lower level test.
<lifeless> I think this is quite reasonable but the docstring is as you say unclear
<poolie> yes that does seem to be it
<poolie> to me, that layer seems so thin that it is not worth separately testing with and without it
<lifeless> I don't like the idea of duplicate tests with and without it
<lifeless> I would quite like to have tests of that layer and all the others tests written without it; personally.
<lifeless> anyhow, I'm out for the day; got lots done
<poolie> lifeless, any debs yet?
<poolie> tests of the argument parsing and everything else done without parsing?
<poolie> that would be ok with me
<poolie> i think
<ubotu> New bug: #148857 in bzr "add should not show count of ignored files" [Low,Confirmed]  https://launchpad.net/bugs/148857
<lifeless> poolie: yes, just now in fact.
<lifeless> poolie: without sid, its failing to build for me
<vila> poolie, lifeless : regarding tests/commands, its origin in rev 2485.8.3 in bzr.dev, back in London Sprint, robert told me to separate the tests I was written in test_init (aimed at testing the init command) into a new hierarchy
<vila> and also to create a dedicated transport (based on ftp) to avoid testing against all transports
<vila> the distinction between blackbox (testing the API) and tests/commands for the internal behavior was a bit blurry though :-/
<vila> I think the idea was the connection sharing problem was seen as internal to the commands and not worth blackboxed as users shouldn't be aware of such detail
<mkanat> Is there any way to get a log for all of the items in a directory?
<mkanat> Particularly from a repo with no working tree.
<lifeless> vila: well I advised that when you asked a specific quest
<lifeless> question
<vila> lifeless: I'm not throwing stones ;)
<lifeless> :)
<lifeless> I'm off to sypy
<vila> just explaining the history to help find the right answer
<vila> which I still don't have unfortunately :-/
* vila leaves for a couple of hours, bbl
<lifeless> ciao
<vila> last thought and I'm really gone, I think there is value in testing at that level ,but truth is, the tests I have written could be blackbox ones...
<acuster> Hey all, I just imported a large project from svn into bzr. It took many hours and all my memory but eventually finished---very cool.
<acuster> However, bzr log lists a bunch of files under a "removed:" header
<acuster> the same thing happened when I did a bzr init; bzr add on a fresh svn checkout
<acuster> can anyone explain how bzr is handling those files?
<acuster> after 'bzr revert' is 'bzr st' supposed to have a 'removed:' section?
<poolie_> acuster, no, it should normally not
<acuster> thanks
<acuster> does bzr make errors building a repository due to file name issues, file content issues or layouts?
<poolie_> can you explain the question more?
<acuster> https://bugs.launchpad.net/bzr/+bug/148884
<ubotu> Launchpad bug 148884 in bzr "'bzr add' and 'bzrsvn branch' work but have st with a 'removed:' section" [Undecided,New] 
<acuster> would bzr have issues on files in different encodings?
<poolie_> looking
<acuster> thanks
<poolie_> that is strange
<poolie_> bzr handles filenames as unicode
<poolie_> so it does have trouble if there are names that are not valid in your machine's encoding
<acuster> the file names look ok, I was thinking in terms of contents
<poolie_> generally no, though there are some more things we'd like to do to accomodate people with varying encodings within their tree
<poolie_> that is, with files whose encoding doesn't match your locale's encoding
<acuster> blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java
<acuster> gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java: ISO-8859 C program text
<acuster> blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java
<acuster> gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java: ASCII C program text
<poolie_> and are you experiencing that bug on linux? with 0.91?
<acuster> I'm on ubuntu feisty (utf-8)
<poolie_> >>find . -name '\.svn' | xargs grep rm -Rf
<poolie_> is that really the command you ran?
<acuster> but there must be files in ISO-8859 in other parts of the tree that imported find
<poolie_> i don't think that will do what you intend it to do
<acuster> no
<acuster> without the grep probably
<acuster> but something like that
<acuster> I couldn't get find to work on its own
<mkanat> find -name '\.svn' -exec rf -rf \{\} \;
<mkanat> s/ rf / rm /
<acuster> yeah
<acuster> I didn't find that and gave up after a while ;-)
<acuster> actually the find had '-type d'
<poolie_> just fyi, it would be easier to just put .svn in a .bzrignore in the root
<poolie_> in fact it may be on by default
<acuster> before running bzr?
<acuster> that's nice
<ubotu> New bug: #148884 in bzr "'bzr add' and 'bzrsvn branch' work but have st with a 'removed:' section" [Undecided,New]  https://launchpad.net/bugs/148884
<poolie_> before running add
<acuster> makes sense now
<acuster> bzrsvn should certainly make .svn ignored by default, does that project use the same bugtracker?
<acuster> yeah, another directory that imported fine has files in the 8859 locale
<mkanat> Does 0.91 require Python 2.4 now?
<mkanat> I get a syntax error on 2.3 for: from stat import (S_ISREG, S_ISDIR, S_ISLNK, ST_MODE, ST_SIZE,
<mkanat> I didn't see that anywhere in the relnotes.
<poolie_> mkanat, i don't think we've supported 2.3 for quite a while?
<mkanat> poolie_: It seems to have been working in 0.18.
<poolie_> acuster, yes, it's bzr-svn
<poolie_> !!
<mkanat> Oh, no, I'm a liar.
<mkanat> poolie_: You can ignore me. :-)
<mkanat> Or at least, that last statement. :-)
<acuster> poolie_phone, did you mean it's bzr-svn's error?
<ubotu> New bug: #148908 in bzr "`bzr log --short -rX.Y.Z` gives traceback" [Undecided,New]  https://launchpad.net/bugs/148908
<jelmer> acuster: I think he meant that launchpad is used for tracking bugs in bzr-svn and the product name there is 'bzr-svn'
<acuster> oh, right, thanks
<acuster> how do I ask for the log of the last 20 revisions?
<GaryvdM> bzr log --limit=20
<acuster> ah, or -10..
<acuster> is there a way to do a range? say -20 to -10?
<GaryvdM> bzr log -r.....
<acuster> ah, I was using .. wrong
<acuster> thanks
<GaryvdM> Pleasure
<jezdez_> hi
<jezdez_> I'm trying to checkout a svn repository with bzr-svn from a google code hosting project. I know that I need to use ``bzr co svn+https://..``, though I don't get asked for the password. any ideas?
<ubotu> New bug: #148964 in bzr "bzr update only reports one conflict" [Undecided,New]  https://launchpad.net/bugs/148964
* acuster is totally confused by branches vs checkouts
<acuster> can we branch just a single directory?
<mwhudson> ah! subversion has poisoned your brain i see!
<acuster> can I run bzr branch from above the hierarchy?
<acuster> perhaps.
<mwhudson> more seriously: no, bazaar versions branches and treats them more or less indivisibly
<acuster> and all branches use essentially the same amount of space?
<acuster> what's the difference then with a cp -R ?
<mwhudson> i lack enough context to answer sensibly
<acuster> say I want a master branch that stays in sync with svn and then lots of 'branch|checkout|trees' to work on individual aspects of the code (cleanup, featureA, featureB...)
<mwhudson> acuster: are you familiar with shared repositories?
* acuster lacks enough context ... :-)
<acuster> I've worked with cvs and svn for a number of years
<acuster> without using branches as much as possible
<acuster> for reasons well understood by all
<mwhudson> ok
<mwhudson> so there are two things that can occupy space
<acuster> I would like one local branch to be a clean copy of svn with merges to it immediately followed by pushes to svn
<acuster> and then I want to work in lots of other 'spaces'
<mwhudson> the historical data, i.e. all the revisions
<mwhudson> and the working trees
<mwhudson> a shared repository lets you store all the historical data in once place for several branches
<acuster> history = .bzr and tree = the code hierarchy?
<mwhudson> more or less
<mwhudson> history = .bzr/repository
<mwhudson> there is some other stuff in there too
<acuster> ok
<ubotu> New bug: #148969 in bzr "conflict status flag missing in `bzr update` output" [Undecided,New]  https://launchpad.net/bugs/148969
<acuster> so I need to learn how to use 'shared repositories'?
<mwhudson> if you're worried about historical data filling up your hard drive, yes
<acuster> shared repos can have non linear histories, right?
<mwhudson> sure
<mwhudson> a repo isn't very interesting, really
<mwhudson> it's just a database in some sense, a stack of revisions
<acuster> a stack or a tree?
<mwhudson> well
<mwhudson> having a revision implies also having its parents
<mwhudson> but a repository by it self has no more structure than that
<acuster> so the master branch is the 'shared repositiory' and then I create slave branches off of that for each project?
<acuster> and i can commit/revert on the slaves until ready to merge back to the master?
<acuster> if so, what are the 'slaves' called? checkouts, branches, ...?
<mwhudson> um
<LeoNerd> There are no slaves or masters in bzr; all are created equal
<acuster> all *what* is the question
<LeoNerd> ((quite like SATA I guess :) ))
<acuster> do I need n branches?
<acuster> if so, is making n branches with bzr branch exactly the same thing as making n branches with cp -R ?
<mwhudson> acuster: branches
<acuster> the web site talks about 'working trees' without giving examples or saying how to create them
<LeoNerd> A working tree is the checkout.. the place you work in
<LeoNerd> bzr checkout http://foo/bar...     <== now I have a working tree
<mwhudson> acuster: sorry, i'm too occupied to really do a good job of explaining ...
<mwhudson> hopefully LeoNerd can do better :)
<acuster> mwhudson, thanks
<LeoNerd> The working tree is the tree, where you work. (kinda obvious that bit :) )
<acuster> LeoNerd, backup a second
<acuster> we start with an svn server on the net http://svn...
<LeoNerd> OK.. I know as little as possible about svn...
<acuster> i want a local copy of that and want to be very careful about pushes/pulls to that svn server
<acuster> so i have started with bzr branch http://svn...
<acuster> okay?
<GaryvdM> ok
<acuster> so I have .../trunk/.bzr and ../trunk/gt etc
<GaryvdM> ok
<acuster> now I would like to create some spaces to do some work
<acuster> and then when I am done in one of those spaces
<acuster> merge that work to the first branch
<acuster> then push from that branch back onto the net
<LeoNerd> Right...
<acuster> so I want,say, 4 local spaces to work
<LeoNerd> So that's just bzr branch  and  bzr push
<acuster> what are those? checkouts, branches?
<LeoNerd> (and maybe merge  if the history has changed)
<GaryvdM> 4 branches
<acuster> okay, thanks
<LeoNerd> Explain more clealry
<acuster> so, a final question,
<LeoNerd> These "local spaces".. do they contain the actual files, that you might edit in e.g. vim?
<acuster> if a branch has all the info it needs,
<acuster> what's the difference between bzr branch localdir1 localdir2
<acuster> and cp -R localdir1 localdir2 ?
<LeoNerd> Not much
<acuster> since both will have .bzr and all the files
<LeoNerd> Just 'bzr branch' copies only the .bzr data.
<LeoNerd> cp -R will copy every file on the filesystem, regardless of whether it's bzr branch history or not.
<LeoNerd> cp -R will also copy locally-modified changes in a checkout, if there is on
<LeoNerd> bzr branch will not copy a checkout at all
<LeoNerd> 'bzr branch' is, however, moreorless equivalent of cp -R on just the .bzr directory inside that.
<acuster> ah, so bzr branch is like cp but only for versioned info?
<LeoNerd> Basically, yes.
<LeoNerd> (and of course works over other transports like http and sftp and so on)
<acuster> does bzr branch have all the same history?
<acuster> forget that
<GaryvdM> yes
<acuster> all branches are equal
<LeoNerd> Yes. The two histories will be identical after a 'bzr branch'
<acuster> so checkouts are to let you live in svn hell even after moving to bzr?
<acuster> thanks you all
<GaryvdM> ????
* fullermd wouldn't phrase it that way...
* acuster goes off to create lots of branches, dimmly lit, all alike
<GaryvdM> acuster: please can I try explain somthing to you
<acuster> sure
<LeoNerd> acuster: Be careful not to be eaten by a Grue
<acuster> I wondered if the reference would work... :-)
<GaryvdM> A branch contains a repo and a working tree (wt
<GaryvdM> repo contains the state of the tree at each version
<GaryvdM> the working tree is a place to do your work
<GaryvdM> You can create a shared repo
<GaryvdM> And put branches inside the shared repo
<acuster> (my branch is 954MB, hence my hope I could work without n copies of the same thing)
<GaryvdM> But the shared repo only has a repo - no working tree
<GaryvdM> Hence it is not a branch its' self
<GaryvdM> But the branches that you put inside the shared repo will share there revision history, and hence save space and time.
<GaryvdM> Make sense?
<acuster> sort of
<acuster> how do you go about making a shared repo, starting from a branch?
<GaryvdM> ok
<acuster> how do you go about making a shared repo, starting from a branch, and then making n branches
<mwhudson> bzr init-repo .
<GaryvdM> lets say you have projectfoo/trunk is your branch
<mwhudson> though with bzr-svn it should be
<mwhudson> bzr init-repo --dirtstate-with-subtree . i think
<GaryvdM> ren projectfoo projectfoo-temp
<GaryvdM> bzr init-repo projectfoo
<GaryvdM> cd projectfoo
<GaryvdM> bzr branch ../projectfootemp/trunk
<GaryvdM> cd ..
<GaryvdM> rd projectfoo
<acuster> ren?
<GaryvdM> rename - sorry i'm a windows user
<acuster> rename just changes the name?
<GaryvdM> Yes
<GaryvdM> branches can just be rename on the filesystem
<GaryvdM> s/rename/renamed
<acuster> did you forget some chdir in there?
<acuster> ls = projectfoo/trunk
<acuster> mv projectfoo projectbar
<acuster> cd projectbar
<GaryvdM> no
<acuster> bzr init-repo trunk
<acuster> errr
<GaryvdM> You need to move the existing branch out the way to a temp place
<acuster> okay, thanks for your help. I'll try to walk through that slowly and make sense of it
<GaryvdM> Then create the the shared repo
<GaryvdM> then branch into the shared repo
<GaryvdM> then delete the old temp branch
<acuster> so then i have the same branch I had originally except now it is a shared repo as well?
* GaryvdM thinks bzr needs a builtin way to do this
<GaryvdM> yes
<acuster> which allows one to do what that we could not do before?
<mwhudson> it is _in_ a shared repo, or it _uses_ a shared repo
<GaryvdM> Save disk space
<mwhudson> GaryvdM: you can create the repo in the directory that your branch is in
<mwhudson> branch it into another location in the repo (to copy the revisions into the repo)
<mwhudson> then delete trunk/.bzr/repository
<acuster> because then each branch below that shared repo will be a full copy of the code files but a virtual copy of the repo info?
<GaryvdM> yes
<acuster> yes to me or to mwh?
<GaryvdM> mwhudson: Yhea, but still requires a branch to move the repo to the shared repo
<mwhudson> yes
<GaryvdM> yes to acuster
<mwhudson> it's hacky, but it works :)
<acuster> okay, thanks you all. Will go off and try to sort this out
<GaryvdM> Cool!
<jezdez_> sorry to ask again, but has somebody experience in using bzr with google code hosting via bzr-svn?
<mwhudson> jezdez_: i have not, but i don't think google code hosting does anything very exciting
<mwhudson> (apart from be not very reliable)
<jezdez_> mwhudson: indeed, unfortuneately I actually have no choice and want to use bzr for my changes
<mwhudson> so what are you trying, what happens, and how does that differ from what you'd like to happen?
* acuster finally finds the page he need to read at the start. Thanks again for your help mwhudson, LeoNerd and GaryvdM 
<GaryvdM> It's a pleasure
<acuster> GaryvdM,  http://bazaar-vcs.org/SharedRepositoryTutorial talks about a --trees flag, has this been made the default?
<fullermd> Yes, a couple versions ago.
<acuster> aha. if a branch is made without trees, one can do a checkout from that branch to get a tree?
<LeoNerd> Indeed
<LeoNerd> Any point on any branch may be checked out, to obtain a working tree
<jelmer> GaryvdM: hi, still there?
<acuster> point == revision?
<acuster> and a checkout can be somewhere else entirely on the filesystem?
<LeoNerd> Sure.
<acuster> this all seems quite lovely
<LeoNerd> A "branch" is just a branch
<LeoNerd> A "checkout" is usually a directory that contains a branch _and_ a working tree
<acuster> there's a totally useless statement
<acuster> right
<LeoNerd> But you can also, if you want, make a "lightweight" checkout, which contains just the working tree, and references some branch stored elsewhere
<acuster> the branch vs tree thing was hard to see
<acuster> so what I want is a repo of branches and then a lightweight tree elsewhere on the system
<acuster> bzr can generate a tree just from the info in the .bzr dir?
<fullermd> Glarble.
* fullermd stabbies ambiguous 'checkout' descriptions.
<acuster> finally bitten by the day's original bug.
<GaryvdM> Hi jelmer
<jelmer> GaryvdM: just marked some of your merge requests as approved by you, if you wonder what those emails are sent on your behalf :-)
<GaryvdM> jelmer: I'm not sure what mails your talking about
<jelmer> GaryvdM: see the recent few mails to the bzr-gtk mailing list
<GaryvdM> Ok - now I see them in the archive
<GaryvdM> :-) not sent to my mail
<poolfool> Has anyone attempted to modify the index.tmpl for the bazaar-hgweb (3rd party) plugin? I don't think it works how the instructions describe it.
<Alien_Freak> new at bzr, looking for a getting started guide/howto.... also, any info on importing svn into bzr?
<Peng> Alien_Freak: There's lots on http://bazaar-vcs.org/ .
<Peng> Alien_Freak: There's also information on conversion.
<Alien_Freak> okay.. thanks
<Peng> Sorry, I'd give you a link, but I don't exactly have a web browser open at the moment.
<james_w> Alien_Freak: doc.bazaar-vcs.org/bzr.dev/
<james_w> there is a quickstart tutorial on there.
<Peng> That too.
<Alien_Freak> ok.. ty
<GaryvdM> jelmer: When you say test, did you mean unit test?
<jelmer> GaryvdM: yes
<GaryvdM> Please could you give me some pointers
<GaryvdM> To test it you would you not need a server setup?
<jelmer> GaryvdM: yes, but bzr's testsuite already does that
<GaryvdM> a filezilla server?
<jelmer> GaryvdM: at least some bits appear to be in bzrlib/tests/test_ftp_transport.py
<jelmer> no, but it should be customizable - iirc it's a mock ftp server, but I may be wrong
<GaryvdM> Oh - ok
<jelmer> if that is not the case, you should be able to test that _translate_perm_error() returns the right exception when it gets that error that filezilla returns
<jezdez_> mwhudson: so, sorry for this delay, the kids needed to have dinner :)
<mwhudson> jezdez_: luckily jelmer seems to be around now and he's much more qualified than me to answer
<mwhudson> :)
<jezdez_> mwhudson: ah great
<ubotu> New bug: #149019 in bzr "locations.conf error message has bad line count" [Undecided,New]  https://launchpad.net/bugs/149019
<jezdez_> jelmer: I'm trying to checkout a google hosted project with bzr-svn
<jelmer> jezdez_: what error are you getting?
<jezdez_> jelmer: bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'
<jelmer> jezdez_: please try prefixing the url you are trying to check out with svn+
<jelmer> jezdez_: google gives permission denied errors rather than "no such file error"s for some reason
<jezdez_> jelmer: I tried "bzr checkout svn+https://USERNAME@PROJECTNAME.googlecode.com/svn/trunk/"
<jezdez_> jelmer: google advices to use something like this in a normal svn environment: "svn checkout https://PROJECTNAME.googlecode.com/svn/trunk/ --username USERNAME"
<jezdez_> for a non-anonymous checkout
<jelmer> jezdez_: have you tried running something like 'svn ls https://PROJECTNAME.googlecode.com/svn/trunk/ --username USERNAME' ?
<jezdez_> jelmer: yes, works as it should, listing file in the trunk directory
<jelmer> hmm, in that case the checkout using bzr should also work now
<jezdez_> jelmer: huh, you are right.. now it works. it seems to cache the username input..
<jelmer> yeah, password prompting isn't done by bzr-svn at the moment (yet) :-/
<jelmer> however, it can use the native svn cache
<jezdez_> jelmer: ah, ok.. thanks for putting up this kind of wrapper anyway :) I was looking for such a workaround
<poolfool> What are people using to publish a web view of their bzr 'shared repo'; ie something like ViewVC?
<jelmer> poolfool: loggerhead mostly
<jelmer> jezdez_: No worries, hopefully we'll get the prompting in by the next release...
<jelmer> poolfool: e.g. http://codebrowse.launchpad.net/~jelmer/bzr-svn/0.4/changes
<jezdez_> jelmer: great to hear that, thanks for your help.
<poolfool> jelmer: So the common answer is 'launchpad' you fool.  Ok, what about if I want to self host and not use turbogears?
<jelmer> poolfool: you can run loggerhead yourself
<poolfool> jelmer: Errr ... not use launchpad?
<jelmer> poolfool: launchpad just uses it too
<james_w> poolfool: there is also bazaar-webserve
<poolfool> jelmer: Thanks .... I have been a CVS guy for a while and I have a lot of the office using CVS. Our current setup is CVS-NT on a Linux server with tortuousCVS client and ViewVC for access. I am trying to find the same kind of setup.
<poolfool> james_w: what is the address for bazaar-webserve?
<mwhudson> poolfool: what is your problem with loggerhead?
<james_w> http://goffredo-baroncelli.homelinux.net/bazaar
<poolfool> mwhudson: Actually nothing ... I am just getting into python and not sure I will be able to adapt loggerhead as I want. I know enough perl (shudder) to modify ViewVC to my liking.
<poolfool> muwhudson: That and I am currently running apache ... doesn't loggerhead require cherrypy?
<poolfool> james_w: I have been looking at that a lot right now, found it under the 3rd party plug-ins page. But I am having a problem modifying the index.tpl(?) file as defined in the 'docs'. Changes are not showing up on the page?
<mwhudson> poolfool: yes, sadly :/
* mwhudson maintains loggerhead these days and doesn't like cherrypy either
<mwhudson> poolfool: you can reverse proxy it though
<poolfool> mwhudson: I guess my ideal (ha ha) solution would be ViewVC support bzr as well.
<poolfool> mwhudson: ??? Do you mean redirect from apache to cherrypy?
<mwhudson> given how different bzr and svn are in someways, i don't think viewvc _can_ support bzr sensibly
<mwhudson> (imho)
<mwhudson> poolfool: proxy internally, you know, the usual way you run a long running process behind apache?
<mwhudson> ProxyPass and all that
<poolfool> mwhudson: I totaly agree, I actualy really like bazaar-webserve if 1) it supported cherrypy, 2) had a simpler template engine and 3) worked as the documentation described.
<jelmer> hasn't bazaar-webserve pretty much been obsoleted by loggerhead? afaik it's not being maintained anymore, is it?
<poolfool> jelmer: That is the answer I was looking for, the '.dev' branch has a few commits but it pretty much looks like it's toast. To Bad, it does a lot that loggerhead does not.
<james_w> poolfool: are you sure that it is picking up the templates that you think it is?
<james_w> it has some strange logic to work out where to load the templates from.
<poolfool> james_w: After reading the instructions more then once (or twice), I hope so. I started to leaf through the python code (not my first or second language) to make sure.
<LarstiQ> jelmer: it's still maintained.
<poolfool> james_w: The process I have tried is 1) install plugin to ~/.bazaar/plugin, 2) check that it works, 3) edit template at '~/.bazaar/plugin/bzrweb/templates/index.tmpl' and 4) cry because its not working?
<jelmer> LarstiQ: by whom?
<poolfool> james_w: I have tried restarting '#bzr webserve ..... ' multiple times
<mwhudson> i promise you loggerhead is more actively maintained, because i'm paid to do it :-)
<LarstiQ> jelmer: well, unless Goffredo stopped maintaining it in the period I stopped paying attention to computers..
<LarstiQ> mwhudson: that is certainly true
<mwhudson> what does bzr-webserve do that loggerhead does not?
<jelmer> it doesn't use turbogears I think :-)
<poolfool> mwhudson: Well thank you ... it is a great piece of code ... but it's more of a large hammer, that requires (I think) cherrypy.
<poolfool> mwhudson: All of that said, Loggerhead is probably my next solution .... so I might ask you a few quesitons.
<mwhudson> jelmer: i hope loggerhead won't for too much longer either, i think
<poolfool> One of the really nice things about bzr-webserve (I think) it that it doesn't have outside dependencies (cherrypy), you can fire up a web server for 1) local branches and 2) remote branches.
<poolfool> I just tried it out yesterday and followed /doc/'readme.html' ; but my big heart burn is it's (IMHO) ugly template language and fact that I can't modify index.tmpl.
<james_w> poolfool: is there a directory named 'templates' in the cwd?
<james_w> also what method are you using to run it?
<poolfool> james_w: No, I have been editing ~/.bazaar/plugins/bzrweb/templates
<poolfool> james_w: I am following the instrucitons from the 'readme.txt'; here is what I am doing http://pastebin.com/m52eb144c
<poolfool> james_w: Then I edit the template ('~/.bazaar/plugins/bzrweb/templates/index.tmpl') and ... nothing?
<poolfool> james_w: As a matter of fact the template has a heading level 1 <h1> that doesn't even show up ... so now I am not even sure it uses these templates.
<james_w> right so if in the directory in which you run 'bzr webserve' you have a directory named 'templates' it will use what it finds in there.
<james_w> if not then it will use '~/.bazaar/plugins/bzrweb/templates'
<poolfool> james_w: Ok, I follow you ... but I don't think I am doing anyting wrong. I don't have 'templates' in the cwd or in the branch folder?
<poolfool> james_w: So ... it should use the copy from '~/.bazaar/plugins/bzrweb/templates'?
<james_w> poolfool: I think so.
<james_w> you could try renaming the index.tmpl and see if it complains.
<poolfool> james_w : Well, here is something else in the documentation http://pastebin.com/m59611c13 ; I think I will try 1) creating a 'templates' at cwd, 2) copy from default and 3) modifying index.tmpl
<poolfool> james_w: Still no joy. I also tried 1) modifying index.tmpl and 2) '#bzr webserve --port=9099 "fool site" --templates ./templates ./test_repo'; Still no joy.
<poolfool> LarstiQ: Do you have Godffredo's email address handy or is '@inwind.it" the best for now?
<poolfool> mwhudson: Is loggerhead moving away from turbo gears?
<mwhudson> poolfool: i'm thinking about ti
<mwhudson> it
<mwhudson> it brings some disadvantages and few advantages for an app like loggerhead
<poolfool> mwhudson: Could you elaborate, or do you have a blog? Who pays you to work on loggerhead?
<mwhudson> poolfool: i work for canonical
<poolfool> mwhudson: Oohhh Michael Hudson. Well, I really do like loggerhead ... just might not be what I need right now. Thank you for your hard work ... bzr, loggerhead, ubuntu ... good stuff.
<abadger1999> mwhudson: oh? What are the advantages and disadvantages?
* abadger1999 packages bzr and works on TG apps so you've got my spider sense tingling ;-)
<mwhudson> abadger1999: well, the problems are mostly: cherrypy
<mwhudson> it mangles urls in unhelpful and irrevocable ways
<mwhudson> and does really odd things if there's an exception during url traversal
<mwhudson> the benefits of TG are that it works and the pieces fit together nicely
<Peng> Pylons? Django?
<Alien_Freak> how do I fork off a branch in bzr?  ie,  i need to maintain a main repo, and have a secondary repo sync up to main repository
<mwhudson> Peng: all overkill for the need at hand, really
<Peng> I don't think hgweb uses anything. It's completely custom.
<mwhudson> i'm tempted to redo it as SimpleHTTPServer with genshi templates
<mwhudson> (it uses kid right now, which is another thing i dislike quite a lot)
<abadger1999> Yeah -- we've found some of those things too.  One of our other devs is hosting a TG2 sprint to work on addressing some of those things as well.
<mwhudson> abadger1999: cherrypy 3 looks a _lot_ better from what i can tell
<mwhudson> shame that it's one of the few un-pluggable parts of TG1 :)
* mwhudson afk for a bit
<poolfool> mwhudson: bzr-webserve (hgweb) uses the built in python http object and extends it ... but I just don't get it.
<abadger1999> TG2 is moving to pylons rather than cherrypy3, though.
<poolfool> mwhudson: which would you take (if forced to) builting python http object or cherrypy 2 ?
<fullermd> Alien_Freak: You probably mean 'branch' where you said 'repo'.  And the 'branch' command will do that.
<Alien_Freak> does the branch have all the data that the main branch has?
<fullermd> Yah.
<poolfool> Alien_Freak: Um ... you are what I was about two weeks ago. Lots of good guys on IIRC here. Follow this old track between bignose and me http://pastebin.com/m32b3d220
<Alien_Freak> thanks for link poolfool
<GaryvdM> I pulled the latest bzr.dev
<GaryvdM> When I bzr commit - it's saying that every file in the branch is modified
<GaryvdM> So I did a bzr uncommit, and then a bzr status, and it correctly shows the changed files.
<GaryvdM> And then did a bzr commit again , and again it say that every file is modified.
<GaryvdM> Should I be worried about this?
<jelmer> GaryvdM: what does the diff for the committed revision say?
<james_w> GaryvdM: is it permissions or line-endings?
<GaryvdM> Ah - I'm not sure what I have done with this tree now
<GaryvdM> Let me start again
<GaryvdM> Ok - first of all, when I commit there is an error (I did not notice this the first time)
<GaryvdM> Traceback here: http://pastebin.com/m38f73166
<GaryvdM> In the diff for the commited revision, there are files with properties changed.
<GaryvdM> Is that permissions james_w?
<GaryvdM> I guess I should send this to the mailing list?
<fullermd> "properties changed" probably means +x (well, or -x)
<james_w> GaryvdM: I would report that traceback as a bug.
<GaryvdM> Ok
<schierbeck> hi guys
<KenB_> Anyone have a minute for a newbie Q?
<jelmer> 'evening schierbeck
<jelmer> KenB_: sure
<schierbeck> hi jelmer
<schierbeck> i've got an interesting patch on the list :)
<KenB_> Thx,  I'm trying to figure out how to see what has happened recently in a network repository.  If I do:
<KenB_> bzr diff -r branch:sftp:\\blah\blah
<james_w> it should probably be sftp://blah/blah
<GaryvdM> schierbeck: Hi
<KenB_> [branch colon // s]  not smiley
<KenB_> I get all the diffs on all the files that have been changed, which is too much.  What I want is something like status but referring to the network repos.
<schierbeck> hi GaryvdM
<james_w> KenB_: bzr status -r branch:sftp://blah/blah ?
<KenB_> I tried that, but got an error - I send the error msg to bazaar@lists.ubuntu.com as requested.
<james_w> KenB_: do you have lsdiff installed?
<KenB_> I was thinking that perhaps bzr status -r submit: might work, but apparently submit: is only for diff
<james_w> or diffstat.
<james_w> if you have then doing 'bzr diff -r branch:... | lsdiff' or diffstat should tell you what files changed.
<KenB_> james_w - no, are those plug-ins?
<james_w> they are external to bzr.
<jelmer> lifeless: so, looks like I'll end up working on bzr-git...
<james_w> they are just normal command line tools.
<KenB_> Oh, I get it.  yes, that might help a lot.
<james_w> jelmer: as samba is going to use git?
<jelmer> james_w: well, we'll be using git "on probation" for the next month or so
<jelmer> but I really don't expect us to go back
<ubotu> New bug: #149113 in bzr "KeyError: None when commiting" [Undecided,New]  https://launchpad.net/bugs/149113
<hunmonk> question: does bzr use any kind of database to stored it's stuff?
<hunmonk> if not, what format are the .knit files?
<james_w> they are a custom format.
<hunmonk> but not db driven?
<james_w> no
<lifeless> jelmer: samba ?
<jelmer> lifeless: yes
<lifeless> oh man
<lifeless> thats pretty disappointing
<jelmer> yeah :-/ performance and git-style repositories being the main reasons
<LeoNerd> Define "database"
<lifeless> what, all-branches-in-one-dir ?
<LeoNerd> I could argue that the .knit files are a form of database.
<lifeless> LeoNerd: they are
<LeoNerd> They store data
<jelmer> lifeless: yes
<fullermd> Well.  My phone list (managed with vi and grep, the way $DEITY intended) is a form of database...
<lifeless> LeoNerd: actually, knits are more analogous to tables in a db
<LeoNerd> In such a DB that has tables...
<lifeless> LeoNerd: we do :)
<LeoNerd> I mean.. an LDAP directory is a database.. That doesn't have tables..
<fullermd> all-branches-in-one-dir has some handy properties...
<jelmer> especially for compiled projects
<lifeless> jelmer: switch ?
<jelmer> lifeless: doesn't work for non-lightweight branches afaik and still requires you to have a branch directory somewhere
<lifeless> well, its a small patch to make it work, if its important, and I hadn't heard muttering
<lifeless> and yes, its true you need a branch dir, but it can be ../a and ../b
<jelmer> lifeless: It's not just being able to switch, also the fact that a repository (and all branches in it) can be copied easily, etc
<jelmer> also, I'm just reporting what argumentation I heard, not necessarily what I'm missing in bzr myself (never really having using git)
<lifeless> sure
<lifeless> not meaning to shoot the messenger
<lifeless> just trying to say that with closer dialogue these could have been addressed
<fullermd> That's a handy thing on a large project.  I _like_ knowing my one step of cvsup'ing the FreeBSD repo gives me all the branches, and I don't need to care about them individually.
<lifeless> having different ideas doesn't mean we want to be difficult to use for some projects
<jelmer> lifeless: I know, but that still leaves a couple of other issues open (such as performance)
<lifeless> is this a done deal for samba?
<lifeless> or is there time to show the packs branch and the hpss streaming-fetch stuff?
<jelmer> lifeless: for the time being, I think so - unless we'll hit problems within the next month or so
<lifeless> well
<lifeless> theres an insane git fanboyness happening at the moment
<jelmer> there are still a couple of bzr fans within the team
<lifeless> ok
<lifeless> so what can we do?
<jelmer> but at the moment, we can't do much else but admit migration to git is a better choice /at the moment/
<lifeless> I see
<jelmer> lifeless: *PERFORMANCE*, git-style repositories, parallel imports, nested trees
<jelmer> (git has submodules now, which we may very well use)
<lifeless> yes
<lifeless> they seem to have done roughly our design for that
<lifeless> integrated in the core, rather than a forest style thing built on top
<lifeless> jelmer: have you tried out packs yet?
<jelmer> lifeless: yes! They're a big improvement
<jelmer> I mention parallel imports because different imports from svn and cvs not having the same revids hurt us while we were using bzr - one of the big advantages of git mentioned
<lifeless> well
<lifeless> you can always assign ids using the git algorithm
<jelmer> doesn't that break referential integrity because it doesn't use any parent ids?
<lifeless> huh?
<lifeless> bzr's model allows commit builder to return the id
<lifeless> this is put in for bzr-svn/bzr-hg etc
<jelmer> yes, but you can't use the git algorithm there without problems, can you?
<lifeless> what problems?
<jelmer> I mean, since the git algorithm is purely content-based, it doesn't include parent ids and can those generate the same revid for two revisions with the same contents but different parent ids
<lifeless> if you have all of history guaranteed, you can do that
<lifeless> what do you mean by parent ids?
<lifeless> do you mean file ids?
<lifeless> or the ids of the parents of the commit?
<jelmer> the revids of the parent revisions of the revision you're committing
<lifeless> the git algorithm hashes though in the revision object's serialised form
<jelmer> ah
<jelmer> sorry, I misunderstood then
<lifeless> you can't do this inside bzr's native serialisation format because to insert into the knit you need the revid, but if you leave the index pointers out
<lifeless> and instead hash tree of the user supplied data alone, e.g. a bzr testament, then you can arrive at a hashed, including parent ids, content summary and use that for your revid
<lifeless> then you batch insert all the data
<lifeless> and it will work fine
<lifeless> abentley: ping
<lifeless> jelmer: so packs help; do they help enough ?
#bzr 2007-10-05
<jelmer> lifeless: git fetches within the minute, bzr with packs was still over 10 minutes last time I checked (about two weeks ago)
<lifeless> initial or incremental?
<jelmer> initial
<jelmer> haven't tried incremental
<fullermd> I don't look to packs for the win there.  A carefully tuned layout on a dumb server will still get creamed by a reasonably competent smart server.
<jelmer> this is with rsync for git IIRC
<lifeless> jelmer: well, you can rsync with bzr too
* jelmer ocmpares again with current versions
<lifeless> jelmer: my experiments with packs were about 20% slower than pure rsync
<lifeless> without tree building
<lifeless> and without the smart server
<jelmer> how fast would the smart server be with packs? same as without?
<jelmer> lifeless: rsyncing is not the default though, requires a plugin and has a bunch of constraints
<lifeless> jelmer: as many ops fall back to the VFS, packs will help
<jelmer> lifeless: I understand what you mean, but people will compare them the way I do now
<lifeless> jelmer: ok, so I need to know what you are doing :)
<lifeless> poolie_phone: I have more reviews up :)
<poolie_phone> jelmer, lifeless, hi
<lifeless> I'm going to try and merge Knit1 and Knit3 Repository classes today
<poolie> jelmer, that is disappointing but thanks for letting us know
<poolie> jelmer, do you know what the deciding factors were of git compared to hg?
<poolie> good idea
<poolie> lifeless, call?
<lifeless> shure fing guv
<schierbeck> hi guys
<jelmer> lifeless: how fast should a local clone of a packs branch be?
<jelmer> poolie: hg didn't really seem to have any advantages over
<jelmer> git
<jelmer> slower, written in Python (a couple of us only know C), no submodules/nested trees afaik
<poolie> right
<lifeless> jelmer: hg has 'forests'
<poolie> not built in iirc
<lifeless> poolie: right
<lifeless> poolie: I will come a-visiting I think
<poolie> ok
<lifeless> I'm down to 2 methods
<lifeless> abentley: ping
<lifeless> abentley: whats the difference between inventory.revision_id and inventory.root.revision ?
<abentley> In rich-root trees, inventory.root.revision doesn't changes.  Inventory.revision_id is the revision_id of the inventory.
<abentley> s/changes/change
<lifeless> ok
<lifeless> so inv.revision_id is always the version of the inventory
<lifeless> should deserialise_inventory be asserting on that ?
<abentley> It's not set in all inventory formats.  Some format 5, all 6 and 7.
<lifeless> ok
<lifeless> I'm combining the Repository1 and 3 classes
<lifeless> by pushing the variation out into the instance objects, and the xml serialiser
<lifeless> this makes it easier to do a new physical storage - packs - that has both non-and-rich-root variations
<abentley> That seems confusing to me.
<abentley> Because then you don't have a one-to-one relationship between formats and repository classes.
<lifeless> I never intended that there should be a 1:1
<abentley> Well, I certainly expect it.
<lifeless> oh
<lifeless> well  I'm happy to tackle it a different way, but its very awkward at the moment without multiple inheritance, which is problematic as most methods have base class definitions
<lifeless> as well as being ugly IMO
<lifeless> right now the only difference from knit 1 to 3 in the repository class is - self._serializer, self._commit_builder_class, and the two methods 'serialise_inventory' and 'deserialize_inventory'
<lifeless> which is why it seemed clean to me to just make the first two things be passed to the constructor, and the latter two look like serializer responsibilities
<abentley> Well, I don't want to interfere with you accomplishing things.  I've been slacking on getting rid of the need to hide rich roots.
<lifeless> hmm, if I change __repr__ to note the serializer that might make it more clear
<abentley> Partly is is because of my fear of dirstate.
<lifeless> so if you saw KnitRepository(URL, xml5) and KnitRepository(URL, xml7) would that be clear enough?
<lifeless> hmm, maybe not. I'll send up a draft patch for disucssion shortly
<lifeless> abentley: thats a reasonable fear, I'm afraid and sorry
<lifeless> dirstate is not my bestest code sample
* abentley is sorry for slacking.
<lifeless> what does xml6 add?
<abentley> Showing the serializer would certainly help.
<lifeless> rich roots or subtrees?
<abentley> Rich roots.
<lifeless> ok, down to one method
<lifeless> + test fallout
<lifeless> ok, class deleted.
<lifeless> now I bet things will break
<spiv> poolie: heading off to your place now.
<poolie> ok
<lifeless> ok, full test running
<lifeless> looking good
<lifeless> jelmer: so, is packs still 10 minutes?
<lifeless> jelmer: got the repo up somewhere? how big is it?
<lifeless> ah foo
<lifeless> basis xml creation is erroring :)
<lifeless> correctly I think. hmm
<lifeless> abentley: why does workingtree2/3 use xml7? I didn't think they could handle its extra info
<lifeless> specifically they are trying to serialise an inventory with no root revision in xml7 format, and thats invalid
<lifeless> (for their basis revision)
<abentley> They don't use it for their main inventory, because that would store data they can't handle.
<abentley> All inventory-based working tree formats use the same inventory format.
<abentley> For the basis.
<abentley> At one point, there was a WorkingTree4 that was inventory-based, and it used xml7, and supported subtrees.
<lifeless> ok
<abentley> So all of the other basis-inventory formats were moved over to format 7.
<lifeless> I'm off to catch a train
<lifeless> I'll figure out whats going on on the train
<lifeless> 35 tests failed
<lifeless> which is 7 per format
<lifeless> so not a huge fraction
<abentley> And you want to know why more didn't fail? >:)
<lifeless> bbiab
<lifeless> well
<lifeless> I want a thread to start pulling on :)
<lifeless> oh
<lifeless> have you thought about log-journaled inventories ?
<lifeless> as a way to cheaply get smaller-io-during-commit, and remove the xml diff step
<abentley> They're totally cache, so you can switch to a different format, if you like.
<lifeless> bye for now!
<jelmer> lifeless:
<jelmer> Branched 13034 revision(s).
<jelmer> PYTHONPATH=/usr/local/lib/svn-python LD_LIBRARY_PATH=/usr/local/lib =  branch  653,49s user 6,35s system 90% cpu 12:06,01 total
<Peng> Okay, so I just upgraded my copy of the pack branch to the new format, and I had to work around the bzr.dev index error. I branched bzr.dev as knits, upgraded to packs, and branched the repository branch from the web, and it worked. Was it supposed to?
<Peng> (bzr.dev as in my local copy of it)
<lifeless> Peng: yes
<lifeless> jelmer: thats pack to pack ?
<lifeless> jelmer: or knit to pack ?
<lifeless> jelmer: if its pack to pack, I'm betting its our object validation
<lifeless> we're ungzipping the header of each thing we copy
<lifeless> Peng: it should now feel quite a bit faster than knits to do things with
<lifeless> abentley: I had tests that were cheating a bit much
<lifeless> -Devil FTW
<ubotu> New bug: #149254 in bzr "diff creates inventory objects" [Undecided,New]  https://launchpad.net/bugs/149254
<lifeless> time to fix index parsing to do bisection
<lifeless> should shave 16% off incremental commits
<ubotu> New bug: #149270 in bzr "revisionspec in_history calls fetch, which requires the branch to be writable" [Medium,Confirmed]  https://launchpad.net/bugs/149270
<mkanat> What's a good bzr repo browser for the web?
<spiv> mkanat: loggerhead
<mkanat> spiv: Better than bazaar-webserve?
<spiv> mkanat: launchpad uses it, e.g. http://codebrowse.launchpad.net/~bzr/bzr/trunk/changes
<spiv> mkanat: I think so; the UI is a little more straightforward I think.
<mkanat> spiv: Yeah, I saw that.
<mkanat> spiv: I'm concerned because it hasn't had a release in so long.
<spiv> bazaar-webserve hasn't had a release recently either, afaik.
<spiv> But loggerhead is actively being improved.  Just use trunk.
<spiv> mwhudson: ^ you should pester robey into doing a loggerhead release
<mkanat> spiv: Okay, so if trunk is okay to use, that sounds good.
<mwhudson> spiv: releases are for wimps
<mwhudson> :)
<spiv> mkanat: I believe it is.  Double-check with mwhudson, who looks after the launchpad system that uses it.
<spiv> Ah, here he is, right on cue :)
<mwhudson> mkanat: this is the code that runs on launchpad now: https://code.edge.launchpad.net/~mwhudson/loggerhead/production
<mkanat> mwhudson: Is that a modified branch, or just a branch from a particular point of loggerhead trunk?
<mwhudson> i'd definitely recommend using this code
<mwhudson> if by trunk you mean robey's devel branch, then yes it has some changes robey hasn't merged yet
<mkanat> mwhudson: Okay.
<mwhudson> in particular, it uses sqlite for its caches, not bdb
<mkanat> mwhudson: Oh, awesome.
<mwhudson> which means it crashes far less often :)
<mkanat> Yeah. SQLite is love.
<mkanat> And BDB is not love. :-D
<mwhudson> right
<mwhudson> i have a couple more things i want to do with loggerhead, then yeah, probably time for a release, indeed
<mwhudson> mkanat: how big are the branches you want to show?
<mkanat> mwhudson: Oh, not that big.
<mkanat> mwhudson: At least, not right now. No more than 6000 revisions.
<mkanat> mwhudson: But most of them have 100 or so.
<mwhudson> probably don't need the cache at all then
<mwhudson> though that more depends on tree size than history size by now
<mkanat> mwhudson: Is there an example config anywhere for hosting directly from Apache instead of by proxying to the TurboGears webserver?
<mwhudson> how would that work?
<mwhudson> loggerhead is a turbogears app (for now, anyway)
<mkanat> mwhudson: I'm not sure, really. :-) I don't know anything about TurboGears, but I'd assume that it could be run through WSGI or something.
<mwhudson> well, i'm afraid i don't know either :)
<mkanat> mwhudson: Okay. :-)
<mwhudson> we run it via ProxyPass
<mkanat> Okay, looks like that's the only good way to run it.
<mkanat> I could run it through flup, but that'd be really complicated.
<mkanat> Though probably faster or more stable.
<mkanat> mwhudson: Where does loggerhead.conf go?
<mwhudson> next to loggerhead.conf.example
<mkanat> mwhudson: Um, in the directory that I installed *from*?
<mwhudson> oh, you installed it? :)
<mkanat> mwhudson: Ha, I figured it was Python, so...
<mwhudson> i've never done that, just run it from the checkout directory
<mkanat> So it just looks for it in whatever directory you run things from, I take it.
<mwhudson> most likely
<mwhudson> i've not looked at this area of the code at all, sorry
<mkanat> mwhudson: That's fine. :-)
<mkanat> mwhudson: Any idea what's up with "TurboGears requires autoreload.package to be set."?
<mwhudson> nope
<mwhudson> mkanat: what version of tg do you have?
<mkanat> mwhudson: 1.0.1
<lifeless> mwhudson: bzr is for wimps then
<mwhudson> lifeless: probably!
<mwhudson> there probably should be a loggerhead release fairly soon
<mwhudson> but just not yet
<mkanat> Great, as soon as I connect to loggerhead it crashes.
<mkanat> Oh, no.
<mkanat> But something is wrong.
<mkanat> I'll figure it out.
<mkanat> Audagsdgkljdfa. Proxy doesn't work under SELinux. Have to find the right setting.
<mkanat> Yay, it's working. :-)
<mkanat> http://bzr.everythingsolved.com/browse/
<mkanat> There will be other things there, at some point.
<mwhudson> mkanat: cool :)
<mkanat> :-)
<mkanat> mwhudson: Is there any way to make it actually overlap with the repo itself?
<mkanat> mwhudson: So that you can check out from the same address you browse from?
<mwhudson> that's an apache question really
<mwhudson> it should be possible
<mkanat> Yeah.
<mkanat> I'm just trying to think of some reliable way to do it.
<mwhudson> serve .bzr off the filesystem, proxy everything else to loggerhead
<mkanat> Yeah.
<mkanat> Maybe just FilesMatch.
<mwhudson> i'm sure we have a bug open on doing the same thing for launchpad
<mwhudson> but i can't find it
<mwhudson> ah https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/137551
<ubotu> Launchpad bug 137551 in launchpad-bazaar "code browsing should share url space with code hosting" [High,Confirmed] 
<mkanat> Ah, yeah, I could do it with rewrite, maybe.
<mkanat> I could do it with Location, I just have to remember what the PCRE for "not" is.
<mkanat> Ah, (?!)
<mkanat> I wonder if that'll work.
<mkanat> Yeah, no.
<mkanat> And now it's mysteriously stopped working. Wonderful.
<mkanat> mwhudson: Any idea why it might start just fine but not take its port?
<lifeless> was the port not cleanly shutdown
<mwhudson> mkanat: look in the log file?
<mkanat> lifeless: Yeah, that's possible. But netstat doesn't show anything holding it.
<lifeless> tcp has this lovely behaviour of sitting in shutdown for a while
<lifeless> netstat -an ?
<mkanat> mwhudson: Log file doesn't show anything about it.
<mkanat> [root@control vhosts] # netstat -an | grep 8080
<mkanat> [root@control vhosts] #
<mkanat> lifeless: Oh, maybe that was it, though.
<mkanat> lifeless: Because now it seems to be working, I think...
<mkanat> lifeless: Ahhh, yeah. :-)
<mkanat> Um, and now the pid file disappeared. I assume this is why I had a TCP port in a bad state.
<mkanat> But the server's still running.
<mwhudson> the whole startup/shutdown thing is a bit flaky tbh
<mwhudson> when testing i always run it ./start-loggerhead -f
<mkanat> Okay.
<mkanat> Yeah, that's what I'm doing now.
<acuster> launchpad.net's search function for "java" returns two copies of Sears
<acuster> and several other projects...hmmm
<acuster> limewire-project
<acuster> and
<acuster> limewire-client
<acuster> but from the ui they look the same
<jelmer> lifeless: yes, that's packs to packs
<mkanat> mwhudson: Okay, weird bug!
<mkanat> mwhudson: http://bzr.everythingsolved.com/
<mkanat> mwhudson: Click on "trunk" for vci, and then "trunk" for bugzilla.
<mkanat> mwhudson: For some reason, the second produces a 404 in loggerhead (which then causes Apache to do weird things, but that doesn't matter).
<mkanat> mwhudson: But add a / after "trunk" on bugzilla, and it works just fine.
<lifeless> jelmer: you might like to profile it and see where the time is going
<lifeless> jelmer: especially if thats local disk
<jelmer> lifeless: yes, it is local disk
<jelmer> lifeless: will do
<salty-horse> is there a web interface for the official bzr.dev repos?
<phanatic> salty-horse: check out on launchpad
<salty-horse> good idea. thanks
<phanatic> salty-horse: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files
<salty-horse> thanks
<salty-horse> I don't understand the warning here: http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20071005032619-b6c99y625rawducb?file_id=osutils.py-20050309040759-eeaff12fbf77ac86#L936 - why pass a string that is then converted to unicode? why not allow unicode strings? also, why the difference between "Unicode" and "utf8"? .cache_utf8 converts between them, but why?
<quicksilver> salty-horse: unicode is a character numbering system
<quicksilver> salty-horse: utf8 is a particular way of encoding that into bytes
<quicksilver> salty-horse: I believe that, behind the scenes, python uses some variant of utf16 for 'unicode' strings, but ideally the programmer doesn't need to know how it's storing them
<salty-horse> so why not accept python's generic unicode as a data type, and then convert it to whatever? why accept an 'str' type? (which is more restrictive, language-wise)
<salty-horse> back soon. answer at will :) (thanks)
<mwhudson> is it possible that bzr 0.91 disregards .ssh/config where bzr 0.90 did not?
<mwhudson> it does look rather that way :/
<mwhudson> hm, only a bit actually
<mwhudson> it seems to be ignoring the Port option only
<fullermd> That's known.
<mwhudson> ok
<mwhudson> is there a bug report?
<fullermd> I think so.  Just remember it being discussed last weekish.
<mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/146715
<ubotu> Launchpad bug 146715 in bzr "bzr+ssh broken for non standard ports." [High,Triaged] 
<lifeless> salty-horse: converting from bytes to unicode and back is slow
<lifeless> salty-horse: we have to serialise at some point, and often we are serialising the same strings, so we cache the serialised result, and vice verca for parsing
<lifeless> treating bytes that are not unicode as unicode causes a slow implicit upcast in python 2.x
<salty-horse> what you do internally is fine - cache the conversions at will. my worry is the type of the passed argument. why insist on utf8 strings instead of the built-in python datatype? (or did I misunderstand your explanation somehow?)
<lifeless> and this is bad when we want to write some exact representation to disk (which we need to do as we're exchanging data with different machines, so we need to be able to get the data back even if they are using code pages)
<lifeless> generally in our api's we either accept unicode strings, or we accept utf8 byte sequences but not both
<lifeless> it depends on the api whether it is a character centric api or a byte centric api
<lifeless> for instance, transport.get_bytes is byte centric, so it returns bytes
<lifeless> but WorkingTree.commit(message='string here')
<lifeless> that string is expected to be unicode
<lifeless> this is another way of saying - we are using the built in python data types.
<salty-horse> and the revision_id in the same function is expected to be utf8
<salty-horse> see http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20071005032619-b6c99y625rawducb?file_id=osutils.py-20050309040759-eeaff12fbf77ac86#L936
<jelmer> salty-horse: all revision ids are expected to be byte strings - that's consistent throughout the code
<salty-horse> jelmer, to me it feels unintuitive to convert my strings from unicode to utf8 str's (the conversion is never lossy) just because you prefer one over the other (for the moment, it works, but with a deprecation warning)
<salty-horse> I thought revision id's are TEXT strings, not binary data -- after all, they are printed as text in bzr log --show-ids
<jelmer> salty-horse: afaik they can only contain ascii characters, nothing fancy but lifeless can probably correct me on that
<salty-horse> jelmer, I think that's unlikely. why use utf8 instead of regular "binary data" str?
<jelmer> salty-horse: ascii != utf8
<lifeless> salty-horse: performance is the key reason
<jelmer> lifeless: is it ascii or utf8?
<lifeless> jelmer: revision ids are utf8 strings, with some limitations (no \n's for example)
<salty-horse> jelmer, I'm well aware of that :)
<lifeless> salty-horse: are you writing a gui perchance ?
<salty-horse> lifeless, no. fixing deprecation warnings in the tailor bzr backend
<lifeless> ok
<lifeless> well, any revision id bzr generates is utf8
<lifeless> and will never be upcast to unicode by bzr itself
<lifeless> any revision id you ask bzr to use must be utf8
<salty-horse> my fix was this:
<salty-horse> hunk ./vcpx/repository/bzr.py 289
<salty-horse> -        revision_id = "%s-%s-%s" % (email, compact_date(timestamp),
<salty-horse> +        revision_id = "%s-%s-%s" % (email.encode('utf8'), compact_date(timestamp),
<lifeless> is tailor generating its own revision ids ?
<salty-horse> yes. the last part you don't see is hexlify(rand_bytes(8))
<salty-horse> (yes, *I think*) :)
<lifeless> any reason not to use the bzrlib function to do this? :)
* salty-horse cheks
<salty-horse> c
<lifeless> anyhow, in the limited context of fixing the deprecation warning, yes that fix is fine
<lifeless> I don't know why tailor would need to generate revision ids though
<lifeless> if you are committing, bzr will generate a revision id for you
<salty-horse> I'll check with them to see if there's any reason -- I just starting hacking after seeing the warnings
<jelmer> lifeless: profile on local packs copy finished
<jelmer> lifeless: appears _find_file_ids_from_xml_inventory_lines() is very expensive
<jelmer> if I'm reading the output correctly
<jelmer> lifeless: interested in the callgrind file?
<lifeless> jelmer: hmm, its meant to be fast; yes I am.
<salty-horse> lifeless, when having bazaar generate the id's, it will inject the email of the repository converter (tailor user), which may have nothing to do with the converted project. but there's no problem with that on #tailor, so it will be automatic :)
<fullermd> Presumably it would also inject the current date, too.
<salty-horse> fullermd, seems like it uses the original commit timestamp
<jelmer> lifeless: sent
<james_w> it looks like safe_file_id doesn't check the characters contained within. Is there a check that the file-id is safe to use as a filename somewhere?
<jelmer> james_w: no - but that should be done by the backend, anyway
<james_w> jelmer: so there is no function I can call to check this for me?
<jelmer> james_w: imho knits should escape where necessary because these restraints are knit/weave-specific
<james_w> jelmer: thanks. I am writing code that will put files on disk, so I wanted to know if there was something I could reuse. I can't find it for knits, but I'll keep looking.
<lifeless> james_w: what do you need?
<lifeless> james_w: the escape code is in bzrlib.store.*
<lifeless> but generally its a mistake to name backend files after user supplied data
#bzr 2007-10-06
<AfC> Can anyone comment on the state of bzr-git? I have _one_ last project that's not in Bazaar yet that is in Git. It'd be nice to somehow convert it into a bzr branch, but I had no luck with tailor (for months of trying)
<lifeless> jelmer of bzr-svn fame is hacking on it now
<lifeless> its not up to converting yet, only data inspection
<AfC> lifeless: ok, thanks Robert
<AfC> I'm going to go ahead and just do a big initial import for now. Maybe I can use --file-ids or whatever later to recover the history
<Peng> Why not keep it in git for the moment?
<AfC> Peng: you're asking that HERE, in #bzr?
<AfC> {sigh}
<AfC> Peng: but also because I can hardly remember how to use Git and am not really that interested in relearning.
* AfC just tried to figure out how to `revert` a file and could decide whether it was `reset` or `reset --hard` or what. Git is horrendous.
<AfC> s/could/could not/
<Peng> Heh.
<Peng> I have no experience with git. :P
<Peng> Maybe I should be glad.
* Peng wanders off.
<Peng> But if bzr-git is progressing quickly, I was just thinking that it shouldn't be too bad to use it for a little while, especially when otherwise you risk losing the history.
* Peng wanders off.
<AfC> Peng: fair enough
<AfC> Peng: nah, I need to get on with collaborating with someone. I'll wait until there is a way to graft the two branches together.
<AfC> It's all cosmetic, of course
<AfC> Just feelgood factor that you want to recover, mostly
<keir> lifeless, ping
<lifeless> keir: pong
<keir> lifeless, hey
<keir> lifeless, did you start on the 4k fanout?
<lifeless> keir: putting the finishing touches on bisection
<lifeless> its 19 roundtrips on a 200MB index
<lifeless> to get down to a 4K size
<keir> i was thinking about this
<keir> for big indicies, why not pad them out to 4k blocks?
<lifeless> a 4K prelude on the index will give about 16 times granularity, or log(16, 2) - 4 less round trips
<keir> then we can have a fan out table which selects down to 4k nicely
<lifeless> hmm, right now I just want to get enough legs on this toy format to survive while the real one comes together
<keir> of course :)
<keir> so in a 200mb index, that's ~2.5m keys, right?
<keir> assuming something like 80 bytes per key/vaue/refs
<lifeless> 800K keys
<lifeless> (I gave you a 200M index to play with :))
<lifeless> for the current toy format of course
<keir> yes
<keir> i am using the old 100mb 0.tix
<lifeless> oh, was it only 100M. ll
<lifeless> lol
<lifeless> 200MB for it + the rev index and inv index
<keir> wait, i found 115k keys in that one...
<keir> i wonder if my parsing code is wrong
<keir> most key/val/refs are ~90 bytes, so 115k keys makes sense
<keir> wait
<keir> i think i dropped a 0
<lifeless> I think that index is a little unusual because it has converted data
<lifeless> our native indices have longer keys
<keir> are you always reading 4k at a time?
<lifeless> o
<lifeless> no
<keir> less?
<lifeless> minimum of get_recommended_page_size
<lifeless> which transport supplies
<keir> aah, i see
<lifeless> a single readv may hit many locations, each of which is fanned out to that figure if its smaller
<lifeless> so on http we'll read 64k minimum
<lifeless> but something like ftp may well choose to read 200K or more, because of the insane effort needed to issue what amounts to a readv
<lifeless> so its not truely pages in the toy index
<lifeless> read read <->
<lifeless> we read <->
<keir> so really, a 4k fanout/preamble may be too small
<lifeless> transport expands that
<lifeless> we get back [......] 
<lifeless> if the edges of that are not already parsed, we strip up to the first \n
<lifeless> giving row\nrow\n....
<lifeless> we parse those
<lifeless> mark the range as parsed
<lifeless> and the low and high key found in the range
<lifeless> the bisection code to drive this is on the commits list
<lifeless> bisect_multi_bytes(content_lookup, size, keys)
<lifeless> content_lookup is a callable that takes a list of (location, ley) tuples
<lifeless> and returns those tuples with an added status: one of (-1, +1, False, result)
<lifeless> where -1 and +1 are 'lower than this location' and higher than..
<lifeless> False is 'cannot be in this index'
<lifeless> and result is 'return this to the caller'
<keir> ok
<lifeless> I'm putting the final bits of the content_lookup callable on GraphIndex at the moment
<keir> i see that the hash based fan out is nice
<keir> then merging with bzr.dev?
<lifeless> then profile for regressions on local operations
<lifeless> then profile for regressions on network operations
<lifeless> then send in a [MERGE]  to the list for ddebate
<lifeless> so this won't add any prelude
<keir> ok
<lifeless> adding a prelude will simply provide the first 4 left-right jumps within the index at the front, cheaply
<keir> only first 4?
<lifeless> 4 keys/K
<lifeless> 4*4 == 16
<lifeless> log(16,2) == 4
<keir> index is 4000 single bytes or 2000 shorts?
<lifeless> so this makes a 64K index achieve 2 round trips lookups
<lifeless> this is the toy index
<lifeless> strings
<lifeless> current format, not sure where you are getting bytes/shorts concepts
<lifeless> the prelude I'm thinking for this format, is trivial: a list of psuedo keys
<lifeless> and the byte offset of the start of the first key that sorts after the pseudo key
<keir> i was thinking the prelude would be the fan out.
<lifeless> I think we're talking past each other to some degree
<lifeless> the stuff I talked about with you the other day was for the format you're working on, with topological grouping
<keir> it's late here, i probably shouldn't be bothering you!
<lifeless> this index is linear sorted
<keir> lifeless, yes, i realize that
<lifeless> ok cool
<keir> lifeless, the hash indexing works for linear ordering too
<keir> which is neat
<lifeless> so given keys AA AB AC BA BB BC
<keir> using a hash index you can just glue it on any ordering
<lifeless> well, you need a complete hash table
<lifeless> I'm planning on using the sorted facility of this index to just improve on regular bisection- basically the same as the git fan-out prelude
<lifeless> with the keys above, a prelude might look like
<keir> AA <loc> BB <loc>
<lifeless> '' 0, 'B' 30
<keir> yes
<keir> that's exactly how my other code works
<lifeless> that is, if I'm looking for a key between '' and 'B', I know its between 0 and 30
<lifeless> ok
<lifeless> so, the reason I want to do this rather than a generalised full-index hash table
<lifeless> is that this is very simple to code;
<lifeless> take all the keys in order
<lifeless> bisect through them and pull out key, location pairs
<lifeless> until I've got 4K of data.
<lifeless> stop.
<lifeless> if I want to, shrink the prelude keys to the smallest unique string at the location I picked up, allowing it to be smaller
<keir> yes, that's also how my code works. it does it recursively until the top level is 4k
<lifeless> cool
<keir> ok i lie slightly; it does it bottom up
<keir> but same idea
<lifeless> :)
<keir> lifeless, i just did some excel work. i have the following proposal.
<keir> store a 4k preamble which is a histogram of the number of keys in that bin
<keir> where each bin is a 1 byte uchar
<keir> then store the usual tag/offset jazz after
<keir> this way it fits into 4k
<keir> for roughly up to 800k keys
<lifeless> what is a bin precisely
<lifeless> is it positional
<lifeless> a key prefix
<lifeless> ?
<keir> lop the first byte off of each hash
<keir> sorry
<keir> 3 bytes
<keir> grr
<keir> 12 bytes
<keir> bites
<keir> bits
* keir needs sleep
<keir> that gives you 1 position in the 4k table (each entry 1 byte)
<keir> the 'table' is really a histogram of the number of keys which fell in that bin
<keir> which you count by taking the first 12 bits of each hash, indexing into the table, and incrementing
<lifeless> I don't understand; which hash? and what does this do for us?
<keir> in two round trips most of the time you'll have the exact location
<keir> the benefit is that by having the client do the cumulative sum to get the offset into the tag part of the hash table, we can store huge tables
<lifeless> if I understand this correctly
<lifeless> then I can paraphrase this as:
<lifeless> 'store a table of hash:list of locations at the front of the file. To allow the table to become very big, store a summary of the table at the front of the table, size limited to 4K.
<keir> yes
<lifeless> the summary of the table lists the number of locations stored against every combination of X bits of hash, to allow direct access to the serialised sparse table once the 4K summary is read.
<keir> yes
<lifeless> it sounds like you are making good progress on figuring out how to have a very small 'find a key' logic, while still allowing arbitary sorts for data locality
<keir> exactly
<lifeless> I'm fairly uninterested in whacking this into the toy format as yet
<lifeless> but very interested in it being in the real format
<keir> ok
<keir> so for the 800mb case
<lifeless> 800K case? :)
<keir> excel tells me it'll be 4k of preamble and ~13mb of tag:offset pairs
<keir> 800k keys rather :)
<keir> the nice thing about this is that i can whack it on top of the toy format no problem
<keir> and then the average bin will be still something around 4k
<keir> as in, you'll have to grab 4k of data
<lifeless> hmmm
<lifeless> tell you what, I'll finish this bisection approach off
<keir> yes
<keir> i'll keep working on excel
<keir> and mail the list
<lifeless> and think seriously about this hash approach
<lifeless> what hash function were you thinking of using?
<keir> sha, just because it's Proven
<keir> but maybe it's too slow
<lifeless> its very slow
<lifeless> also its cryptographically secure
<lifeless> which is unneeded here
<lifeless> as we support collisions
<keir> yes
<keir> crc32!
<keir> ftw!
<lifeless> well
<lifeless> that would work, and is bound in python
<keir> we'd probably want more bits
<lifeless> why
<lifeless> 800K << 2.6M
<lifeless> I wonder if hashlittle is available in the stdlib
<lifeless> so
<lifeless> wikipedias' list of hash functions
<lifeless> suggests that adler32 is about the fastest thing out there
<lifeless> crc32 ~= md5
<lifeless> at 3.6* adler
<lifeless> and sha is 6 * adler
<lifeless> so I'd use adler up to say 500K keys
<keir> neat
<keir> is adler in python?
<lifeless> yes
<lifeless> in the zlib module
<lifeless> and go md5 at 500K keys
<lifeless> and stay at md5
<lifeless> this is only data lookup, things are verified by sha as they are reconstructed, so we don't care about hostile modifications
<keir> "Adler-32 has a weakness for short messages with few hundred bytes, because the checksums for these messages have a poor coverage of the 32 available bits."
<keir> this is bad for us
<keir> probably crc32?
<keir> i suppose we can just try
<lifeless> test, test and more testing :)
<keir> is there a function in your code which gives me the offset of a key given the key? i.e. during the building phase
<lifeless> no
<keir> ok
<lifeless> because the location cannot be determined without knowing the number of key references before the key + the length of the keys before the key
<lifeless> so we wait until finish() is invoked to calculate this
<keir> of course.
<keir> it seems entirely reasonable to add  the hash index as an index on the index... in a seperate file
<keir> cool, now that i look back at git's index, this way is nicer
<lifeless> if you update the 'size of offset needed' logic to understand that there will be a hash table there, it should fit in very nicely
<keir> by storing the histogram rather than the cumulative sum, we can store fewer bits per hash table entry
<keir> and nicely enough, given the number of keys, the hash table (including both 4k start and rest) is fixed size
<lifeless> but i'm not against extra files if that really helps
<lifeless> actually the hash table probably isn't fixed size - but it is bounded.
<lifeless> collisions will share hash names
<keir> hmm, this is true
<keir> i had originaly envisioned sha hashes so i was thinking no collisions
<lifeless> even sha can collide
<lifeless> its true we don't know how to *make* it collide
<lifeless> but its a fallacy to say it won't :)
<keir> actually that ruins everything
<lifeless> hmm?
<lifeless> collisions don't ruin anything here
<lifeless> the number of bytes in the hash table is:
<keir> the whole trick with the histogram relies on your bins being exactly nentries*fixed size
<lifeless> right
<keir> ooh, i see
<keir> you just duplicate the tag
<lifeless> and you have that
<lifeless> nah no need
<keir> duh
<lifeless> here:
<lifeless> trivial format for the table:
<lifeless> HASH LOCREF[ LOCREF...] 
<keir> (well, the table format is pretty trivial!)
<lifeless> oops
<lifeless> HASH LOCREF[ LOCREF...] \n
<keir> i am against delimiters...
<keir> in this part of the table
<keir> i'd go like this:
<lifeless> well
<lifeless> if you don't duplicate the hash
<keir> TAG OFFSET TAG OFFSET TAG OFFSET
<lifeless> then a collision moves the table up
<keir> up?
<lifeless> the idea of the table summary is to say 'if your hash starts with 010110' then sum up the counts for all hashes in the summary before that
<lifeless> and you can tell where in the table to read from to read the data for all hases that start with 010110
<keir> yes
<lifeless> by up I mean 'earlier'
<keir> what i'm suggesting, is to dupe the tag and increment the bin anyway
<keir> then the reading end needs to know that there may be duped tags
<lifeless> if its a fixed size, then take the sum of the bins, multiply by the size of a keyref + your hash size and you know where to read
<keir> i don't see how to do the offset calc when there are delimiters
<lifeless> if its not a fixed size
<lifeless> then it will never be further in the file, but it may be earlier
<lifeless> but
<keir> i think delimiters are a bad idea in this context
<keir> hopefully collisions will be rare enough that it's worth duping the content
<keir> of course, we'll see in testing
<lifeless> anyhow, you can calculate the upper bound of collisions in the reader
<lifeless> 4 bins, with 10 keys each - at minimum there are 4 unique hashes, at most 40
<lifeless> but its better than that
<keir> ah yes
<lifeless> if you record 'hash, refs' rather than 'refs' in the bin summary
<lifeless> then you can handle any number of collisions and still predict exact location
<keir> but then our summary will be either larger or less selective
<lifeless> right
<lifeless> so its a tradeoff between larger table when there are collisions and larger summary when there aren't
<keir> hmm, the keys in 0.tix should be unique right?
<lifeless> yes
<keir> wow, lots and lots of crc32 collisions
<keir> i'm getting 50% collisions
<keir> i guess that's what happens when you load 800k items
<lifeless> yah
<lifeless> don't use crc32
<lifeless> :)
<lifeless> as its meant to be ~ the same as md5
<lifeless> I'd check what distribution you're getting
<keir> sorry
<keir> bug
<keir> in 717k i get 50 collisions
<keir> for crc32
<keir> 4000 with addler32
<lifeless> what cpu do you have?
<keir> this is just doing the dumbest thing throwing all the keys into a dict() keyed on hash
<lifeless> 4K/717K is nice and low - 0.5%
<keir> pokey old centrino
<lifeless> ok
<lifeless> print "0x%u" % hash('asdfg')
<lifeless> 0x3709412585253919148
<lifeless> I don't think we can use this hash
<keir> it can hash all of them pretty fast even on this machine
<lifeless> but I'm curious what result you get
<keir> 0x-848537172
<lifeless> hah! so much for unsigned
<lifeless> anyhow, different number
<keir> bin = int(sha.sha(key).hexdigest()[:4] , 16)
<keir> i'm getting 65k collisions with that one
<keir> that should be a 32 bit hash right?
<lifeless> 4 bits per char
<lifeless> 4 chars
<keir> duh
<keir> 54
<lifeless> really, use md5
<lifeless> seriously faster
<keir> just checking collisions
<lifeless> sure
<keir> 61
<keir> wow, so far the winner is the fastest and dumbest: crc32 ftw!
<lifeless> :)
<lifeless> have you tried adler ?
<keir> 4000
<lifeless> hmm, I remember one of adler/crc has endianness/word size issues
<keir> by authors admision, is broken below 128 chars due to design
<lifeless> we'll want to check
<keir> it's adler
<keir> it's unsuitable
<lifeless> k
<lifeless> brb
<lifeless> back
<james_w> lifeless: I was asking about disk safe filenames for the patches/threads/loom plugin. I guess I could use a random string and store the mapping.
<keir> lifeless, so if we have 12 bits to pick inside the 4k preamble, we're left with an awkward 20 bit tag. i suggest we use a 44 bit hash; 12 bits for preamble, 32 for tag
<keir> then our records are 8 bytes
<keir> which are very cache performant (aligning to 4 bytes good!)
<keir> 0 collisions on 717k
<lifeless> james_w: a bit more context would be useful
<keir> (8 bytes being tag:offset)
<keir> i'm off to bed
<lifeless> night!
<keir> it's been a fun thought experiment
<lifeless> we're making really good progress I think
<keir> i'm pretty convinced this is the right approach
<keir> super simple, compact
<james_w> lifeless: I don't know if you saw on the list (extra revisions in sprout), but I am looking at doing something like the loom plugin. This means that I need to create new branch. Each 'thread' has a name, so I was going to name the hidden branches the same, so I wanted to know if there was a function to check if a string was safe for writing to disk.
<james_w> you suggested that using user supplied input wasn't a good idea.
<lifeless> I don't understand whats being written to disk
<lifeless> or what you mean by hidden branch
<james_w> for each thread I create a hidden branch, which is just a branch that is stored in .bzr to suggest to the user that they shouldn't modify it manually. This involves creating a new directory beneath .bzr that is a branch.
<lifeless> I suggest using some mapping
<james_w> each of these branches has a name, which I was going to use for the name of the directory, so that given a name I can find the branch.
<lifeless> and thinking about renames
<lifeless> are there relationships between these branches
<lifeless> bbiab
<james_w> yes, I am working on a single linked list assumption at the moment.
<james_w> or a stack might be a better term.
<james_w> If i remove that you can get git workflow, but it is more work.
<Peng> lifeless (since keir /quit): You might be using the hash functions for different purposes, but what about Mercurial's hash functions? Either their old GNU diff-based one or their new lyhash (by Leonid Yuriev)? http://hg.intevation.org/mercurial/crew/rev/d0c48891dd4a?style=gitweb
<schierbeck> hello lads
<s|k> hi
<keir> why are the new bzr packs still ~5x larger than git packs?
<luks> bzr packs are really just knits written into bigger files
<luks> but the structure of data in bzr and git is very different, anyway
<keir> the bzr packs don't compress at all either...
<keir> hmm
<keir> git is snapshot based
<keir> but internall just uses heuristics to store the diffs
<luks> knits are gzipped
<luks> gzipped text deltas
<keir> that the complete linux kernel history is 100mb, is pretty nice!
<keir> (for git)
<keir> interesting, i'll have to look into this
<keir> the tiny size for git repos is really nice for branching projects -- tiny download time!
<keir> is there docs of what a knit is?
<keir> i don't see it clearly explained in the developers/ dir in docs
<keir> i see, so text deltas rather than a more efficient xdiff type binary encoding
<fullermd> And occasional fulltext copies.  That adds up size on long histories.
<keir> git does that too
<keir> i still don't see how it's a 5x size difference though
<fullermd> Not in the same sense, AIUI.
<luks> annotations add a lot, too. or are they dropped from packs already?
<keir> hmm. annotations are very important for some projects (gnome, etc)
<fullermd> That doesn't mean storing them is necessary.
<keir> well, the issue gnome had with svn was that annotate was very slow compared to cvs
<keir> back in the day it was a blocker to svn conversion
<fullermd> Well, annotations are also important to things like annotation-based merges.
<fullermd> What both end up meaning is that annotations should be get-able "fast enough".  Which means either finding a blazing fast way to derive them on the fly, or caching them.
<fullermd> With knits, they're cached at commit time, which has a lot of drawbacks.  Space usage, CPU and I/O time to add/retrieve them on all operations.
<fullermd> Makes it very hard to use a non-line-based delta algorithm, since annotations are line-based (my brain rebels at reading a byte-wise 'annotate' output)
<fullermd> Related, it means they're hard-coded based on the 'diff' algorithm used at commit-time.  That can suck.
<fullermd> AIUI, the plan with packs is to add the capability to gen and store an external cache when things come needed, independent of the actual text store.
<keir> sensible
<keir> is there a fast mpdiff implementation already?
<keir> anyone used bzr-git?
<keir> i can't get it to work at all
<keir> and there is no docs whatsoever
<keir> bzr branch ../git ---> 'GitRepository' object has no attribute '_format'
<fullermd> I thought I heard it wasn't up to branching.
<keir> there is not a single example command showing how to use any of its functionality, so i'm guessing
<keir> so bzr-git is, at the moment, entirely useless?
<fullermd> I think lifeless said it's only "there" enough to look at history (presumably 'log' and the like)
<lifeless> keir: bzr-git can show history but is not complete enough to pull data across
<lifeless> luks: knits have annotations, we won't be changing the knits repo format, so that won't change; packs have knits though
<lifeless> erm, packs have the deltas, and they are not annotated
<luks> well, that's what I meant
<luks> I just wasn't sure if packs still have annotations
<lifeless> ok
<lifeless> they don't
<lifeless> packs are something like 10% smaller than bzr's knit based repositories
<keir> lifeless, why are they so much larger than git repos?
<jelmer> 'morning *
<keir> because libxdiff (what git uses) is 5x better than line diff + gzip?
<lifeless> keir: two reasons that I know of; one is that we know we can do better on size - john and aaron have done lots of experiments on this - but we haven't moved their research into a disk format [yet] .
<lifeless> in fact thats a general enough statement that it covers the second reason too :)
<lifeless> hi jelmer
<keir> lifeless, ok :)
<lifeless> Peng: thanks; I wasn't aware of lyhash
<Peng> lifeless: :)
<lifeless> keir: so I would expect the next iteration of packs to bring in some of their improvements which will increase performance more, decrease size etc,.
<lifeless> keir: I'm curious though where you are getting the size comparison from?
<lifeless> keir: is it a tree with the same history in both formats?
<keir> lifeless, order of magnitude comparisons of git tree vs bzr tree
<keir> same source size
<keir> similar history size
<lifeless> well
<lifeless> similar can cover a multitude of sins
<keir> true
<keir> i was trying to convert the git repo into bzr packs
<keir> to do a proper comparison
<lifeless> yah, thats not ready yet
<lifeless> oh, also, a thought - if you were doing du -sh .bzr
<lifeless> there is the obsolete_packs directory
<keir> it's empty
<lifeless> ok
<lifeless> :)
<keir> all the size is in the single .pack
<keir> 54mb
<lifeless> how old was the project when it was in knit format ?
<keir> compared to the git 15mb one
<keir> this is packs.packs
<keir> knit is similar size
<keir> .bzr in packs is 61mb
<lifeless> uhm, I wasn't clear
<keir> in knits it's 71mb
<lifeless> old knit generation code generated bigger knits
<lifeless> for two fairly dumb in hindsight reasons
<lifeless> the first is the python GZipFile uses zlib compression level 9 by default for some insane reason
<keir> hmm
<lifeless> this generates bigger output in a non trivial % of cases
<lifeless> I saved a surprising amount of disk in the moz repo tests by converting that to -1, not to mention a bucketload of time
<lifeless> the second reason is that we started with a full text every 50 commits no matter what
<lifeless> (per file history)
<keir> ah, i see
<lifeless> and the inventory file - which is a) big and b) changes on every commit
<lifeless> lets just say that it became a dominating factor in several repositories
<lifeless> now we use a heuristic that says 'if the size of the deltas == the size of the file, write a new full text'
<lifeless> oh, and theres another reason too
<lifeless> we delta against history always
<Peng> To get more efficient knits, what, re-clone?
<lifeless> not against best size/closest match/introduction to repo
<lifeless> which means if you imagine a Y graph
<lifeless> if at the point just before the split you are due-for-a-full-text
<lifeless> both arms will get a fulltext, one each.
<lifeless> Peng: by diffing against history its trivial to be sure that you have all the deltas needed to reconstruct a text during branching
<lifeless> because you can take all the inventories; grab the texts they want as either fultext-or-delta, and you're done
<lifeless> if you have arbitrary deltas, you need to grab other data that you dont want in general, replace the local delta for the thing that referenced it with another, then you're done
<lifeless> this is one reason pack text indices have two pointers
<lifeless> one to another text for delta parent
<keir> aah, a history-parent and delta parent
<lifeless> one to a list of parents for file graph
<lifeless> so that we can e.g. delta against last-added, but still tell what we need during fetch easily
<bialix> luks: ping
<luks> hi!
<lifeless> if someone digs into the 'pack' command (not the autopack, the manual 'please make me fast daddy' command)
<lifeless> then they can fix existing repositories to be considerably smaller, especially now that packs are not annotated.
<lifeless> keir: did I just hear a penny dropping ? :)
<lifeless> hi bialix
<lifeless> anyway, I've some stuff to do here, hope this discussion helps - the 5x thing is definately a problem, but I'm quite sure you won't see it *that bad* if you start with packs and git and build up a given graph programatically
<luks> hi again :)
<bialix> hi, luks, lifeless
<bialix> luks, I thinking about separate file for strings, but it seems to few strings at this moment
<bialix> ^too few
<luks> I'm fine with it as it is
<luks> we can move them later if the list will start growing
<bialix> ok for me
<luks> what still worries me are error messages from bzrlib
<luks> but I guess that's not easily fixable for now
<bialix> yeah
<bialix> duplicate them inside QBzr is not best idea
<luks> yep
<bialix> luks, I saw you change some plurals-relaed things in qdiff
<luks> yes, I realized I need a plural in the title
<luks> and I couldn't figure out how to do it with pygettext
<luks> so I switched it to xgettext
<bialix> it's may be something strange with my standalone QBzr, but it seems that this code is not working on my win32
<luks> hmm
<luks> what's the problem?
<keir> lifeless, i was looking into this because i was thinking about the compressed keys issue -- if we compress keys into groups of 16, we get a 4x saving on space for storing the keys
<bialix> I don't see this messages at all
<keir> lifeless, but i wanted to check if the size of the keys was even on the cards compared to pack sizes
<bialix> luks: may be it's something related to bug #148409
<ubotu> Launchpad bug 148409 in qbzr "qdiff --inline: option has no effect?" [Undecided,New]  https://launchpad.net/bugs/148409
<luks> bialix, I think I'm confused now
<luks> you mean you don't see the title in qdiff at all?
<bialix> luks: because my bad english, or because my bug report?
<luks> neither, I just don't see how are these two related
<luks> the "X files" title should appear only if you specify more than 2 files to diff on the command line
<bialix> no, title in qdiff is present, I don't see "X files" message
<bialix> mmm, and when I specify no files?
<luks> then you get only "QBzr - Diff"
<bialix> aha
<luks> and if you open it from qlog then I believe you get "QBzr - Diff - <revision ID>"
<luks> maybe this should be unified
<luks> it made sense to me back then, but it looks confusing now that I think about it again :)
<bialix> here screenshot http://bialix.com/qbzr/qdiff-2-files.png with 2 files in command line
<luks> more than two
<bialix> yep
<bialix> my bad
<bialix> but --inline does not work anyway
<luks> I know, it used to work, but then I added this new diff viewer and didn't bother to implement it there
<luks> but I'm about to rewrite it again, because the diff gets misaligned sometimes
<bialix> well, ok, I just want to know it's not win32-specific
<luks> no, it's not
<bialix> btw, I hve some strange bug with diff on my ru.po
<bialix> somewhat something breaks html rendering in diff and I saw raw html code
<luks> can you mail me the patch that does it?
<bialix> here is screenshot: http://bialix.com/qbzr/qdiff-html-bug.png
<luks> ouch
<bialix> it's from my i18n branch
<bialix> it's already on laucnhpad server
<bialix> bzr qdi -c136
<luks> I see
<luks> I used an ugly hack there, but it doesn't play well with utf-8
<luks> hm, maybe not
<bialix> luks: good night
<luks> night
#bzr 2007-10-07
<lifeless> keir: well, I'm heading to lunch
<lifeless> keir: have fun!
<keir> lifeless, i have to switch back to RL stuff for now
<schierbeck> jelmer: ping
<lifeless> hi i386, missed you at yum cha today
<i386> lifeless: yeah I wasnt there!
<i386> how are you?
<lifeless> good
<i386> just hacking on my project at the moment
<acuster> d
<acuster> Hey all,
<acuster> in http://bazaar-vcs.org/releases/debs/feisty/
<acuster> what's the difference between bzr*bazaar and the bzr without?
<welterde> what does "EOF during negotiation" mean?(while doing bzr push)
<james_w> acuster: that is just the version number.
<acuster> ?
<james_w> welterde: there was some sort of error. The messages need to be improved, is there more to the message?
<acuster> bzr_0.90-1_i386.deb
<james_w> welterde: and are you using sftp:// or bzr+ssh://?
<acuster> vs
<welterde> james_w: sftp://
<acuster> bzr_0.90-1bazaar1_i386.deb
<james_w> welterde: ok, I assume that you can ssh to the server.
<welterde> yup
<james_w> welterde: are you using a non-standard port?
<welterde> no
<welterde> it happens right after it requests the sftp subsystem
<welterde> if that helps^^
<james_w> acuster: the bazaar ones are a higher version.
<james_w> welterde: is there any more error message?
<acuster> thanks
<welterde> james_w: just that "bzr: ERROR: Unable to connect to SSH host"
<welterde> but thats not quite true^^
<james_w> welterde: what is the command line you are using?
<acuster>  /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed.
<welterde> james_w: bzr push
<james_w> welterde: and in 'bzr info' what is the parent branch?
<james_w> acuster: what version of bzr-svn are you using?
<welterde> it has no parent branch^^
<acuster> 0.4.2 and 0.4.1
<james_w> welterde: does it have a push branch?
<james_w> acuster: I would suggest filing a bug then.
<acuster> thanks
<welterde> james_w: yes... sftp://bteam@gandalf.srv.welterde.de/~/projects/web/vg/main/
<james_w> welterde: and 'ssh bteam@gandalf.srv.welterde.de'
<james_w> I believe you already said it does.
<welterde> oh...
<james_w> welterde: is there anything in ~/.ssh/config about this host?
<welterde> i think it might fail, because i set the login-shell to /bin/false^^
<welterde> silly me^^ now it works
<james_w> :)
<lifeless> I hate python bugs
<lifeless> 'foo'.rfind('\n', None, None)
<lifeless> try that
<glogiotatidis> hello everyone, can anybody help me install a plugin?
<lifeless> glogiotatidis: sure
<lifeless> gnight all
<jelmer> welterde: please try 0.4.3
<jelmer> welterde: there have been changes in that part of the code, so chance is it's been fixed
<welterde> jelmer: changing login-shell to /bin/zsh helped^^
<jelmer> huh!?
<welterde> [15:34:30]        jelmer | welterde: please try 0.4.3
<james_w> jelmer: it was acuster that had the bzr-svn issue.
<jelmer> ah, sorry!
<orion_> is it possible to use bzr as a GIT frontend, not using it for anything else
<james_w> orion_: bzr-git will allow you to do that, but it is not ready for use yet.
<hsn_> can we see results of survey?
<luks> http://www.surveymonkey.com/sr.aspx?sm=FDeDsLzaZ0AKNEATuA0QklWayMZKGfHcrP1U4V55jAY%3d
<hsn_> nice
<hsn_> i need better win install guide (click-by-click based) for my team, should i create it on wiki as AlternativeWindowsInstallGuide ?
<hsn_> nowdays users needs to read more pages for hunting all bazaar depends
<james_w> hsn_: please do.
<james_w> hsn_: why not just improve the windows install guide though?
<hsn_> beause its faster for me to start with empty page instead of merging and editing 3-4 pages
<hsn_> currently ppl needs to hunt depend libraries from at least these pages: http://bazaar-vcs.org/WindowsDownloads http://bazaar-vcs.org/BzrWin32Installer http://bazaar-vcs.org/BzrOnPureWindows
<hsn_> and ppl on my team are complaining about this a lot
<adedov> hi! Please explain howto merge with bundle file'
<luks> bzr merge path/to/bundle.patch
<luks> or do you mean something different?
<adedov> luks: it says me following "bzr: ERROR: Revision {...} not present in "inventory"."
<luks> adedov, no idea, sorry
<adedov> I made sample repository with two revisions and then created a branch of it. After that I added one revision to a branch and created a bundle with command "bzr bundle-revisions -r2..3". The resulting bundle is not applied to an original branch.
<luks> why the -r2..3?
<adedov> what I need instead?
<luks> anyway, if you have a recent version of bzr, use 'bzr send' instead of 'bzr bundle'
<luks> well, nothing :)
<luks> it will figure out the missing revisions
<adedov> I want to try out if I can create bundles without having remote respository.
<adedov> Actually, I want invent a process to review code of students projects. I.e. I want make them send me a bundles without having access to a mine local branch.
<luks> how do they get the code then?
<adedov> They do it them-selves. I want to review. Comfortably, though.
<luks> so you want them to send you the whole branch by mail?
<luks> what is 'your local branch' then?
<adedov> no, just a bundle of changes since the last review.
<adedov> or it looks as broken idea at it root?
<luks> not sure
<luks> so each student has an independant project? or are they based on your code?
<adedov> each has it own one
<adedov> my task is code review. actually it is programming language course. I must peek language/design mistakes.
<adedov> I had experienced some PITA with mailing tgz files. Now I think about reviewing bundles.
<adedov> btw, "bundle" and "bundle-revisions" deprecated?
<luks> yes
<luks> dunno, if it's just for reviews, I'd use plain diffs
<adedov> you may be right, but I also need build a project and look for its functionality. so the plain diffs won't work (e.g. because of added/removed files).
<luks> I think something like "bzr send -rtag:review-X.. -o for-review.patch" should work
<luks> and they would add a review-X tag after each review
<adedov> ok, I shall check.
<luks> I'm not sure about the "Revision not present in inventory" problem, though
<luks> but it's very likely that 'bzr send' will work better
<adedov> how to make "bzr send" not send any mail?
<luks> bzr send -o filename
<luks> that will generate a file
<adedov> the same error
<adedov> well, it seems I will need create a personal read-only branches available via internet for them.
<luks> you could send a mail to the mailing list, there is usually not many people here over weekends
<adedov> luks: ok, thank you very much
<the_angry_angel> Hi guys, just wondering if someone can help shed some light on a problem. I'm using bzr on Windows (0.91) and when I try to push a repository to a linux server, over sftp only the .bzr directory appears to get copied. I've hunted through the docs and unless I'm being a huge dick, I believe it should also be copying the rest of the files in the directory? That's what it does when I try to push via a file:// path on the same machine at least.
<dato> the_angry_angel: pushing over sftp:// and file:// is different
<mwhudson> push only updates the branch , not the working tree
<mwhudson> there's a push-and-update plugin somewhere
<dato> it is expected (or, it is the current behavior) that pushing over sftp:// only pushes the .bzr directory
<the_angry_angel> ok, excuse my ignorance as I'm starting out with bzr, but does that include the actual revisions of the files? or should I be rsync / scp'ing the working data also to my publishing server?
<dato> the_angry_angel: the .bzr directory contains everything needed for people to be able to branch off from your server
<the_angry_angel> So the actual working data is irrelevant :)
<the_angry_angel> Ok, that makes sense :) thank you dato
<dato> np
<s|k> hi
<s|k> why am I getting a bzr: ERROR: Permission denied: "/.bzr": [Errno 13]  Permission denied?
<s|k> I'm trying to set up a shared repository on a remote system
<mwhudson> well, you probably don't have write access to / do you?
<dato> you are probably trying to push to /?
<dato> s|k: you have probably forgotten a /~/ part in your path
<mwhudson> what url are you passing to init-repo ?
<s|k> my command is bzr init-repo --no-trees sftp://user@domain.com
<mwhudson> right, you need to specify the location on the server
<s|k> sftp goes into the home directory for user doesn't it?
<dato> nope
<s|k> hrm so if I make it sftp://user@domain.com/dir/
<s|k> then dir is a directory in /home/user ?
<dato> you want sftp://user@domain.com/~/dir/
<s|k> ohh
<s|k> thanks
<s|k> I think that worked
<s|k> I have another question
<s|k> I set up a special user on my remote server for bzr
<s|k> it seems to me though that I'll have to give that user login info to everyone that I want to give 'commit access' too
<s|k> to*
<s|k> I'm new to bzr if you haven't noticed :P
<s|k> my question is, is there a better way?
<bialix> luks: ping
<hsn_> need english speaker forr fixing my manual at http://bazaar-vcs.org/WindowsInstall
<hsn_> manual tested on live BFU :)
<bialix> hsn_: hi
<bialix> I'm not english speaker, but windows maintainer of bzr
<bialix> do you read this page? http://bazaar-vcs.org/BzrWin32Installer
<hsn_> I am person blamed by my team for BZR too hard to install thing
<bialix> one note: Python language - python-2.4.4.msi | Homepage
<hsn_> and they are right, i used lot of time for geting bzr work on windows too
<bialix> it's not exactly "Python language" -- it's Python interpreter
<bialix> hsn_: it's shame for me to hear this
<bialix> I use standalone bzr.exe
<bialix> and install process for me: download installer, then run it
<bialix> I want note that QBzr GUI is works well with bzr.exe, while bzr-gtk is not
<bialix> QBzr is also has installer for Windows
<bialix> hsn_: you wrote: We will use Python 2.4 branch instead of newer Python 2.5 because binaries of some additional packages are not yet available for Python 2.5.
<bialix> probably "we are using Python 2.4..."
<bialix> what's libraries is unavailable?
<hsn_> i think celementtree
<bialix_> hsn_: celementtree as well as elementtree is the part of standard python library since python 2.5
<bialix_> you don't need to install it yourself
<bialix_> I'm not PyGTK expert, so I can't say is all needed PyGTK libraries available for python 2.5
<bialix_> and if you read my instructions from http://bazaar-vcs.org/BzrWin32Installer you could see that I built python-based windows installer and for paramiko too
<hsn_> where is .exe based installer for paramiko? i see just .zip linked from that page
<bialix_> and my version of paramiko does not require mfc71.dll ;-)
<bialix_> from that page: "NOTE: I strongly recommend to use my version paramiko.ctypes, that use ctypes instead of pywin32. This version avoids dependency on MFC71.dll. (Binary package)"
<bialix_> http://bialix.com/python/paramiko-1.7.1-ctypes.win32.exe
<hsn_> this is paramiko sftp/ssh library + ctypes?
<luks> bialix, pong
<bialix_> this is paramiko library that use ctypes library instead of pywin32
<bialix_> to use my version you need install ctypes on python 2.4 as well
<bialix_> luks: hi
<luks> hey
<bialix_> luks: have a question about QtAssistant
<bialix_> it wants dcf files, but I don;t know where to find it
<luks> um, I'm actually not sure what dcf files are
<bialix_> I installed PyQt from complete installer, as you suggested
<bialix_> when I try to run assistant at first I have many error messages about missing html files
<bialix_> these files for some reason was installed to C:\Program Files\PyQt4\doc, but assistant looks for them in C:\Python25\PyQt4\doc
<bialix_> I copy these html files, but now it want dcf files
<luks> hmm, and it didn
<bialix_> IIUC, these dcf files used for search
<luks> didn
<luks> ok, one more try
<luks> and it didn't install and dcf files?
* luks sighs
<luks> any
<bialix_> no dcf files here
<bialix_> I look into tar.gz and zip archives and found nothing inside
<bialix_> I mean from page http://www.riverbankcomputing.co.uk/pyqt/download.php
<luks> I don't know, I have a full Qt here, but I expected that the installed will be fully working
<luks> one moment, I'll try to find the dcf files I have here
<lifeless> moaning
<bialix_> ta-da!
<bialix_> luks: I did refactoring for timestamp formatting as string
<bialix_> is there better way to convert QtString to python string without this: ''.join(_date.toString(QtCore.Qt.LocalDate).toUtf8()
<luks> unicode(_date.toString(QtCore.Qt.LocalDate))
<bialix_> gosh
<luks> I think str() around the .toUtf8() object should work, too
<luks> depends where it's needed
<bialix_> unicode is OK
<luks> bialix, http://users.musicbrainz.org/~luks/tmp/qt.dcf (sorry it took so long, I'm on a slow gprs connection right now)
<luks> I think putting this file to the "html" directory should make it work
<bialix> actually assistant want several dcf, but thankyou anyway
<bialix> assistant.dcf, designer.dcf, linguist.dcf, qmake.dcf
<bialix> but I saw in documentation topic about add/remove those dcf, so may be I remove them for now
<luks> yep, you can remove those
<luks> I have also bzrlib API docs in the assistant :)
<bialix> cool
<hsn_> ctypes are part of py2.5?
<luks> yes
<bialix> luks: just sent you new patch
<luks> bialix, umm, is ignoring _lib a good idea? there are some versioned files under it
<bialix> luks: what's about standard Qt buttons like Close/Cancel? May be I replace them with user buttons, to have ability translate label?
<bialix> luks, I ignore ./_lib, it's not your installer/_lib
<luks> oh
<bialix> I checked this
<bialix> I hacking qbzr directly in directory where it's installed
<bialix> so I'm able to run and test it after every change I did
<luks> regarding the buttons
<luks> I use something like http://rafb.net/p/WyoJzE88.html elsewhere, maybe it could be used also in qbzr
<luks> it emulates the standard QDialogButtonBox buttons, but with gettext translations
<bialix> place this class to util.py?
<luks> yes. it will need some tweaks, but I think it should be usable
<bialix> you're explicitly skip some code on win32. it's win32-uncompatible?
<luks> no, windows and mac don't have icons on pushbuttons
<bialix> ah, OK
<luks> but on linux/gnome people will get the standard "close" icon, for example
<bialix> umm, I'm still lamer in Qt. what tweaking you have in mind?
<luks> self.tagger.style() -> QtGui.QApplication.style()
<luks> actually, that's probably it. I don't see anything else
<luks> maybe self.style() would work, too
<luks> bialix, +_date = QtCore.QDateTime() -- I don't think it's a good idea to use a global instance, here
<bialix> why?
<luks> it would break threaded code
<bialix> format_timestamp often called from loop
<luks> currently there isn't any, but there used to be and probably will be again
<luks> hm
<bialix> I did it for performance optimization, but it's possible to change for local variable
<bialix> so, I rework it back?
<luks> yes, I'd feel safer to have it as a local variable
#bzr 2008-09-29
<tro> i'm trying to convert a svn repository into a bzr one. i just did "bzr svn-import --all --trees http://...mysvnrepo/project ../project-bzr", but there are no working trees in ../project-bzr. it's a repository, in fact. how do i get a branch from that?
<tro> i'm using bzr 1.7 and bzr-svn 0.4.13
<jelmer> tro, are any branches created?
<tro> jelmer: i'm not sure. it's just a .bzr directory inside. the size looks about right
<tro> and i saw it retrieving revisions one by one
<jelmer> tro, did you specify --scheme ?
<tro> nope. i have no trunk/branches/tags. it's just one directory per project
<tro> should i have done "--scheme none"?
<tro> jelmer: would it work better if i had an svnadmin dump?
<jelmer> tro, if you have just one directory per project, use "bzr branch"
<jelmer> rather than svn-import
<jelmer> svn-import is for complete repositories
<tro> ah
<tro> jelmer: tried bzr branch. got: "bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("REPORT of '/svn/!svn/vcc/default': Chunk delimiter was invalid (http://glyphy.com)", 175002)"
<tro> and then a stacktrace
<jelmer> tro, I don't recall seeing that error before - any chance you can file a bug?
<jelmer> tro, are you on Mac OS X?
<tro> jelmer: ubuntu
<tro> jelmer: should i file a bug in the standard bzr place? https://bugs.launchpad.net/bzr
<tro> or is there a bzr-svn specific place too?
<jelmer> launchpad.net/bzr-svn
<jelmer> tro, is this a public repository?
<tro> jelmer: no, sorry
<tro> it's using http basic
<tro> i pointed bzr branch to a working copy. should i have pointed it to the repository instead?
<tro> jelmer: i'll try with a public repo as well
<tro> works fine with a public  repository on the same server
<jelmer> tro, it's hard to do anything about it if I can't reproduce it :-/
<tro> jelmer: i understand. i'll try a few things here. i'll see if i can create a new private repo where the problem occurs. then i could just give you a password to that
<tro> jelmer: works fine with a simple project in a private repo. darn.
<jml> lifeless: did I return your umbrella?
<tro> the one i'm trying to branch has lots of renames/moves and additions/deletions
<tro> jelmer: bug for this: https://bugs.launchpad.net/bzr-svn/+bug/275643
<ubottu> Launchpad bug 275643 in bzr-svn ""Chunk delimiter was invalid" on remote branch" [Undecided,New]
<jelmer> tro, This shouldn't be related to that
<jelmer> tro, The error comes from within the Subversion layer
<tro> jelmer: do you think downgrading to subversion 1.4 would help?
<lifeless> jml: I think not
<jelmer> tro: it could - I'm not sure what's triggering this error
<tro> meanwhile, i've got an svnadmin dump file. can i create branches out of that?
<jml> lifeless: ok. thanks.
<jelmer> tro, not with bzr-svn (it will just create a repository from the dump file and access that like it is currently)
<jelmer> tro, what you may want to try though is to access the repository locally
<jelmer> tro, specify a file:// url rather than a http:// url
<tro> jelmer: the remote svn repository is hosted. i'm not sure if i'll be able to install the dev svn libraries there
<tro> oh, but i can certainly recreate the repo locally
<jelmer> yeah
<alperkanat> hey there.. anyone here using nginx with bazaar ?
<tro> jelmer: i recreated the remote repository locally from a "svnadmin dump". i can create a branch now, but not all revisions are there. many were skipped.
<jelmer> tro, skipped in what sense?
<jelmer> hi alperkanat
<tro> the revnos don't map 1:1. bzr revision 1 started at svn revision 7
<alperkanat> jelmer: hi ?
<jelmer> tro, that's correct - see the FAQ
<jelmer> alperkanat, just replying to your "hey there..."
<alperkanat> oh ok :)
<tro> jelmer: ah. in that case it worked fine
<tro> i wonder what was wrong, though. i'm sorry, i can't make that repo public, but maybe i can help you gather some more debug data?
<poolie> hello lifeless
<lifeless> hi poolie
<lifeless> hey, tomorrow, want to spend the day together, your place?
<poolie> that would be great
<lifeless> cool, midmorning start?
<lifeless> s/start/arrival/ (clarity FTW)
<poolie> hm
<poolie> i'm just imagining you saying "so i woke up at 5am therefore midmorning is 7:10, so get out of bed"!
<poolie> :)
<lifeless> :>
<poolie> but about 9:30-11:30 would be fine :)
<lifeless> mmmm pie
<dlee> Apologies, I probably missed this:  Which is the right 1.7 release Windows installer bzr version now?
<poolie> dlee, i think there's no 1.7.rc1 installer yet
<poolie> so 1.7 would be the way to go
<dlee> The "Windows installer(s_
<dlee> installer(s)" page shows an rc1, but I thought that was older than 1.7 release.
<poolie> this one -> https://edge.launchpad.net/bzr/+download ?
<poolie> yes that is kind of confusing
<dlee> Yes that one
<poolie> you want bzr-setup-1.7-1.exe, second from the top
<poolie> i'm just going to file a bug that this table is hard to understand :)
<dlee> The Instructions link, after Windows installer(s), still only lists 1.6.1.  I seem to have gotten a developer interested in Bazaar, but I've been having him wait for the 1.7 installer.  Thanks for the bug; I didn't think of filing that.
<dlee> Thanks much
 * dlee goes to update some systems...
<poolie> dlee, it's bug 275677 if you'd like to add anything
<ubottu> Launchpad bug 275677 in launchpad "downloads should be grouped by release, not series" [Undecided,New] https://launchpad.net/bugs/275677
<poolie> spiv, i just noticed you have 6 approved patches...
<poolie> markh: i was going to try making a 1.7.1rc1 exe soon
<poolie> unless you're doing it at the moment, in any case the practice and making sure it's documented might be useful...
<vila> hi all!
<poolie> hello vila
<poolie> spiv, ping?
<spiv> poolie: pong
<poolie> spiv, how's it going?
<poolie> want any reviews?
<markh> poolie: I haven't started yet.  By all means have a go and see if the wiki is up to date.  It is fairly complicated though - eg, you need c compilers, etc
<poolie> is it complicated to do, or just to set it up?
<markh> just setup really
<markh> sourcing and installing the various packages etc - but once the environment is setup it is easy
<poolie> i was thinking about getting a shared virtual server for us somewhere
<poolie> and we could set it up on that, then just turn the crank when a release comes out
<markh> the setup process could do with some work to make it more reliable though - eg, the "official" setup process should know exactly which "optional" components it wants and fail if they don't exist.  Nothing will prevent a build going out without paramiko, for example.
<markh> that would be fine with me.  You will need MS Visual Studio on it
<markh> well
<markh> the freebie one might work to actually :)
<vila> poolie: is http://paste.ubuntu.com/51983/ ok as a NEWS entry for python-2.6 ?
<poolie> vila, i think 'works with python2.6' is a new portability feature
<vila> http://paste.ubuntu.com/51985/
<vila> :)
<poolie> and the notes to developers about how to support it should be separate
<poolie> if you see what i mean
<vila> ok
<vila> so that part should stay in INTERNALS right ?
<poolie> right
<vila> Overall, thins have evolved in the right direction, with recent modifications on python, less of my modifications are needed. Since you voted 'tweak', I'll submit the good bits to pqm and reply to your review to explain the differences
<vila> s/thins/things/
<poolie> ok, great
<vila> oh, and my patch about proxies has been merged in python too ;-)
 * vila grab some coffee
<lifeless> poolie: see you tomorrow
<poolie> see you
<poolie> spiv, are you still around?
<poolie> vila, i have some reservations about triaging bugs for the sake of it
<poolie> at the end of the day would you rather classify 20 bugs or fix one?
<vila> I'm all ears
<poolie> (the proportion may vary)
<poolie> i guess i'd say that reading them is good
<vila> I think I should begin fixing when the new queue is low enough. The rationale being that duplicates can be avoided doing so and people will be more responsive if their bugs are triaged when there are still hot
<poolie> but, if you're not going to act on it now, is recategorizing it really useful
<vila> but if you think that's counter productive I'll stop doing that
<vila> my main motivation is that I find too many 'New' bugs depressing :-/ More than to many 'Triaged' bugs
<vila> s/to/too/
<vila> Having bugs triaged and/tagged means, to me, that fixing them is therefore more organized. And also that reading the 'New' bugs doesn't have to done again
<vila> s/to done/to be done./
<beuno> james_w, congrats on your MOTUship. Long overdue ;)
<james_w> thanks beuno
<jml> markh: have you filed a bug about those failed uploads?
<vila> PQM blocked at 'merge successful' again, I /msged mthaddon, but I'm not sure he's online...
<thumper> Odd_Bloke: ping
<Odd_Bloke> thumper: Pong, for something brief.
<Odd_Bloke> I'm at work ATM.
<jml> Odd_Bloke: that never stops us from talking on IRC! :P
<Odd_Bloke> Yeah, but your boss is much less likely to walk into the room in which you're working. ;)
<jml> Odd_Bloke: he's on most of the IRC channels though :)
<Odd_Bloke> Touche.
<rawler_> does anyone know a nice way to rebase and drop a revision..
<rawler_> basically, I have two branches, whereas HEAD@A is the branch-point of branch B..
 * thumper stabs config-manager
<thumper> lifeless: oi
<thumper> lifeless: how am I supposed to run "make check" for pqm on a clean hardy machine?
<rawler_> I have a bunch of revisions on top of the branch-point in branch B, but would like to drop one close to the branch-point.. any ideas?
<thumper> lifeless: config-manager says it needs pybaz, and pybaz says "isn't installable"
<Odd_Bloke> thumper: You can move the imports for config-manager to where they are actually used.
<thumper> Odd_Bloke: got a branch for that?
<james_w> thumper: you are using config-manager from the hardy package?
<thumper> james_w: config-manager: Depends: pybaz but it is not installable
<james_w> sucks
<thumper> james_w: that is what I get if I try to install config-manager
<james_w> bug 235952
<ubottu> Launchpad bug 235952 in config-manager "Not installable in Hardy (missing dependancies)" [Undecided,Confirmed] https://launchpad.net/bugs/235952
 * thumper stabs unsupported packages
<Odd_Bloke> thumper: I don't think so, no.
<Odd_Bloke> It's quite obvious.
 * thumper throws in the towel for today
<thrope> hi - i'm trying to checkout a google code svn repository using bzr-svn
<thrope> but I'm having toruble authenticating
<thrope> ah ok - got it sorry for the noise
<Odd_Bloke> thrope: Google Code is a PITA, don't worry about it.
<james_w> erm, I didn't think config-manager worked with other systems as well.
<james_w> It only ships an arch implementation though
<Odd_Bloke> james_w: It has a bzr implementation.
<james_w> Odd_Bloke: ah yeah, it's just hidden. Thanks.
<Odd_Bloke> james_w: It's basically a mess. :p
<thrope> oh - turns out it didnt remember my password on the google code svn checkout... also I have to enter it 3 times
<thrope> any idea whats going on there?
<jelmer> thrope, bzr's authentication layer doesn't cache passwords yet
<thrope> oh
<thrope> any idea why I need to enter it 3 times?
<thrope> http://pastebin.com/m7c5b0229
<jelmer> three connections are made to the server
<jelmer> but since bzr doesn't cache the password, you have to re-enter it each time it needs the password
<thrope> oh
<thrope> any idea when the caching feature migth be added?
<thrope> it makes it a bit of a pain to work with obviously
<jakobb> thrope: http://tinyurl.com/4zl6ae
<thrope> great thanks
<thrope> having trouble getting it to work actually
<thrope> is there an example anywhere for use with googlecode?
<thrope> http://pastebin.com/m39dadb2a
<thrope> I tried with and without path specified but it doesnt seem to work
<ryanhaigh> is there some way to compact a bzr branch or to remove files from previous revisions, i have a branch which i was using locally which has a lot of images in it that are regularly modified, i have since removed those files and added them to the ignored files but they are still in previous revisions
<bob2> there's no ui for it atm
<thrope> in fact - even if I take the password out of the authentication.conf and enter it by hand - I can't authenticate if there are any settings in authencation.conf
<thrope> it seems to be the user setting in authentication.conf that prevents it from working even typing the password in by hand
<thrope> has anyone used bzr-svn with googlecode svn repository?
<jelmer> thrope, yes, people have used it with google code before
<thrope> jelmer: any idea what the settings in authentication.conf should be?
<jakobb> thrope: what's the full url to the repository you're trying to access?
<thrope> https://pyentropy.googlecode.com
<thrope> https://pyentropy.googlecode.com/svn/trunk i guess
<jakobb> so... why did you put 'project' in the host then?
<thrope> sorry i replaced the name of the project in the config files i was pasting
<jakobb> aah, oke.....
<thrope> if i have scheme=https and host=pyentropy.googlecode.com in the file, then I can still log in typing in my password
<thrope> as soon as I add the extra line user=user
<thrope> then I can't log in anymore
<jakobb> I have a suspicion...... let me check......
<thrope> bzr: ERROR: Permission denied: ".": OPTIONS of 'https://robince@pyentropy.googlecode.com/svn/trunk': authorization failed (https://pyentropy.googlecode.com)
<jakobb> thrope: what's the error you get?
<jakobb> right... that's what I wanted to know
<jakobb> what command do you give??
<thrope> bzr up
<thrope> it is a checkout in a shared repository
<thrope> (ie following the manual for svn use
<jakobb> hmmm.... that kills my suspicion
<thrope> if I remove the user line it is fine... with the user line I get the error
<thrope> i'm pasting the password so thats the same every time
<thrope> maybe its becuase I checked out with https://user@host):
<thrope> .//branch/branch.conf:bound_location = https://robince@pyentropy.googlecode.com/svn/trunk
<jakobb> it would be surprising if that were the problem
<ryanhaigh> so is there no way to do what i asked about, compacting the branch/removing files from previous revs?
<jakobb> ryanhaigh: i don't think there are standard ways of doing this
<ryanhaigh> ok thanks for the response anyway
<jakobb> but there may be some tricks; i'm not familiar enough with version control stuff to think of something
<jakobb> ryanhaigh: maybe there is a possibility to create a seperate branch, with the images removed??
<jakobb> and then continue with that branch
<jakobb> thrope: how do things work for a clean checkout? does that work with your auth.conf set?
<thrope> jakobb: clean checout: bzr: ERROR: Invalid http response for https://pyentropy.googlecode.com/svn/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<jelmer> thrope, that's bug 256612
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612
<thrope> jelmer: ah ok - it's a bit confusing that svn+https has a deprecation warning, but is actually still required for accessing https repositories
<thrope> in any case - trying a fresh checkout authentication still fails if I have user set in authentication.conf
<jelmer> vila, ping
<vila> jelmer: pong
<vila> oh, 256162 ?
<jelmer> any idea what could be going wrong there? ^^
<jelmer> vila, Well, that too :-)
<jelmer> thrope, what happens if you don't set a user in authentication.conf ?
<thrope> it works
<thrope> but i have to entter the password each time
<jelmer> vila, any idea what could cause that?
<thrope> ah actually it doesn't work
<vila> jelmer: It would be easier for me if I could reproduce :-/ But when I try to install libsvn-dev I get:libsvn-dev:
<vila>  Depends: libaprutil1-dev but it is not going to be installed
<thrope> with no user, and password option it still doesn't work - i enter the password 3 times just like when it it is working then I get the permission denied
<jelmer> what if you explicitly install libaprutil1-dev ?
<jelmer> ah, ok - so that's no different
<vila> ibaprutil1-dev:
<vila>  Depends: libpq-dev but it is not going to be installed
<jelmer> vila, and what if you install that explicitly ?
<vila> chasing
<vila> ibpq-dev:
<vila>   Depends: libpq5 (=8.3.3-0ubuntu0.8.04) but 8.3.3-1~gutsy1 is to be installed
<vila> lipq5 *is* installed 8-/
<jelmer> what about apt-get install libpq5=8.3.3-0ubuntu0.8.04 ?
<jelmer> or is there a reason it's still at that older version?
<thrope> i'm on a mac incidently - but I don't think that should make any difference here
<vila> jelmer: no idea, I never played with those
<vila> jelmer: roughly, regarding these 401, will it help if bzr-svn get a AuthError inheriting from ConnectionError instead of InvalidHttpResponse (really unfortunate)
<jelmer> vila: The problem is, it fails before bzr-svn is involved
<jelmer> bzr needs to continue probing with other formats even when the first fails
<vila> hmm
<vila> jelmer: the problem is that if we catch the 401 then nobody will see it (if bzr-svn is not used) :-/
<jelmer> vila: we should catch the 404 and store it, try the other backends and if they fail as well, raise the first error
<vila> no, look at bzr.dir.find_format, the final error is already NotBranchError(path=transport.base)
<vila> so the 401 should somehow becomes a NotBranchError, catching ConnectionError may fit
<vila> bzrdir.probe_transport may be too restrictive or asking too much by catching only NoSuchFile
<jelmer> vila, we should catch *any* errors that happen during probing
<jelmer> and later raise the error raised by the first format
<vila> imagine  a server handling format2, we try format1 (NoSuchFile), format2(bad password), format3 (blah), the user will have a hard time understanding why we say NoSuchFIle when he mistype his password...
<vila> damned if you do, damned if you don't
<jelmer> ah, true
<jelmer> but that assumes the servers errors are correct
<jelmer> while some servers return incorrect errors
<vila> let's start with correct errors :) But yes, there is a weakness here
<vila> The error is correct here, we use HTTP and we don't provide the right credentials so we fail
<vila> In that case only bzr-svn knows the right credentials, but that's not the ideal answer either :-/
<vila> May be we should collect *all* the errors and display them if no format can be found (that will be correct but ugly...)
<vila> jelmer: the simplest solution seems to be that bzr-svn provides the credentials to bzr (so that bzr can happily fail (still ugly but nobody sees it :-( ))
<vila> that should also address the "i enter the password 3 times"
<awilkins> Hmm, while on the general subject, I couldn't do an anonymous branch of an SVN repo because it insisted on asking me fo auth which I didn't have
<awilkins> Does it really need to ask for write-access to branch, or it this a peculiarity of the repo in question forcing https?
<jelmer> vila, yeah
<jelmer> vila, except bzr has to support prompting for Basic auth passwords then :-)
<vila> It does prompt for passwords, it doesn't prompt for users
<vila> all right, libsvn-dev is happy now, don't now what happened with libpq5 there, it looks like some gutsy dependency was still active
<vila> jelmer: so what version should I get ? lp:bzr-svn ?
<jelmer> vila, lp:~jelmer/bzr-svn/0.4
<vila> jelmer: wil I be able to run it from linux and OSX from the same source directory ?
<strk_away> bzr: ERROR: Cannot commit to branch BzrBranch6('file:///usr/src/gnash/gnash-head/'). It is bound to BzrBranch6('file:///usr/src/gnash/bzr/trunk/'), which is bound to sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/.
<vila> strk_away: only one level of bind is allowed
<strk_away> so unbind and then update ?
<vila> unbind and then push I'd say
<strk_away> uhm.. I was used to 'commit' for an automatic push, what am I doing wrong
<strk> supposedly my workin tree is a checkout of bzr/trunk (local) which is bound to the remote one
<awilkins> A checkout is a bound branch
<strk> so what's the deal with max one level of bind allowed ?
<awilkins> I'd imagine it's there to hedge against both complexity and the possibility of making an circular bind
<strk> gah.. well, I committed these changes and have NO idea how to push upstream now :/
<awilkins> strk: bzr push <my upstream branch>   ?
<Prodoc> Good afternoon
<Prodoc> This might be a dumb question but is it possible to use bzr in a portable manner on e.g. a USB stick under Windows? I was only able to find an installer.
<beuno> Prodoc, sure, you can run from source
<awilkins> Prodoc: The "exe" version should be runnably portably
<awilkins> Prodoc: The "source" version needs python to be installed (or a portable python?)
<Prodoc> awilkins: by the 'exe' you mean just copy the folder to a usb stick after the installation?
<awilkins> Prodoc: AFAIK that will work ; you might also want to set up a quick batch file or something to start a command prompt with the binary on the PATH
<awilkins> Or maybe just start "bzr shell"
 * awilkins thinks about trying this also
<awilkins> Sounds good for adjusting server config, etc, in a versioned way impromptu-stylee
<Prodoc> I was wondering if it'll start complaining about the .conf file located in '\Documents and Settings\*user*\Application Data\bazaar\2.0'
<awilkins> Hmm.
 * awilkins moves folder
<awilkins> It seems to recreate it, but not whine about it's absence
<strk> I feel like I'm about to loose all my changes
<strk> keep getting errors on every operation
<strk> push: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
<strk> trying to bind to the remote branch directly now
<Prodoc> The file only contains the user info (name+email). Not something you want to loose though. Maybe it'll accept the file if it's located in the same folder as bazaar?
<awilkins> Prodoc: If you also set BZR_HOME in your "start me up" file, it will take the conf from there  http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#environment-variables
<Prodoc> ah, cool
<Prodoc> let's see if it accepts relative paths
<Prodoc> ow, darn...just realized that I'll probably don't have the proper rights to set the PATH
<awilkins> Prodoc: You should be able to set PATH for your current user
<awilkins> There's a system and  user PATH ; user PATH is often not set be default though
<awilkins> Windows appends user PATH to system PATH
<awilkins> It's not permanent anyway ; you're only setting the ENV variable in the context of the shell you open
<awilkins> Create a shortcut to %comspec% /k <batch file>
<Prodoc> yeah, but that'll get lost as soon as you start a different process, so using it in combi with eclipse isn't going to work
<awilkins> It might still work if you start the eclipse instance from the shell
<awilkins> That's all you're doing for bzr anyway ; starting it from an environment
<awilkins> Which is why it get the ENV vars from that environment
 * Prodoc wonders if it's possible to set this stuff in eclipse itself...
 * Prodoc goes and check
<awilkins> Isn't the email addy of the user in Eclipe a pref in bzr-eclipse?
<Prodoc> you can set it by bzr whoami
<awilkins> Prodoc: It's a pref in the Eclipse plugin too
<Prodoc> ah
<Prodoc> problem solved then :D
<robsta> hiya
<robsta> seems i encountered something, bzr bails out on a "diff" operation
<robsta> what can i do to make the bugreport most useful?
<Prodoc> darn, the latest eclipse plugin has problems
<awilkins> Prodoc: What kind of problems?
<Prodoc> If you try to go to the settings you'll get a big 'The current displayed page contains invalid values' error
<awilkins> Prodoc: But you can't set the values?
<Prodoc> nope
<awilkins> Prodoc: Which version are you using ; that should be fixed in the latest dev snapshots
<Prodoc> 1.1.0
<Prodoc> with bzr-xmloutput 0.8 and eclipse 3.4.1
<Prodoc> fixed it
<awilkins> Hmm. That version should work. I've been using source, because I'm on Callisto and the UI stuff isn't compatible ; I've got a patched branch
<Prodoc> I managed to set the 'Executable' value after a couple of tries
<Prodoc> that seems to be the cause of the problems
<Prodoc> now everything is available again without the errors
<Prodoc> it shouldn't be a requirement though, if it's available in the PATH
<awilkins> Prodoc: It's because it defaults to "bzr" and I don't think java applies PATHEXT
<awilkins> And Windows knoweth not what to do with #!/bin/python
<pcc1> hello, after upgrading from 1.3 to 1.5, htttp transport no longer works for me (seems to be trying to use the smart server): "bzr: ERROR: Transport error: Server refuses to fullfil the request" how can I force it to use the dumb server?
<Peng_> pcc1: "bzr branch nosmart+http://example.com/..."
<Peng_> pcc1: You should fix your web server too.
<pcc1> unfortunately I don't run it
<Peng_> Well...you should yell at whoever does. :P
<Peng_> Bazaar will try to POST to http://.../your/branch/.bzr/smart. If the server returns a 404, it will gracefully fall back to using dumb HTTP, but your server seems to be doing something weird instead.
<pcc1> it looked like it was returning a 403
<Peng_> Oh
<pcc1> perhaps bzr should downgrade if it gets anything other than 200
<Prodoc> awilkins: too bad, the Eclipse plugin doesn't allow you to specify a relative path for the bzr executable. Would have solved all problems in one go, no config problems and no need to set the PATH for Windows
<Prodoc> I'll file a RFE
<Verterok> Prodoc: I'm out of context (just reading the backlog), a relative path?
<Prodoc> aye, in Eclipse
<Prodoc> here you can specify the location of bzr.exe
<Prodoc> by being able to specify a relative path you can have a portable setup of bazaar with eclipse without any additional hassle
<Verterok> Prodoc: ok, that wouldd be nice. but relative to what? :) the eclipse install?, the workspace?
<Prodoc> since the prefs are not related to the workspace I'd say the eclipse folder
<Verterok> Prodoc: actually, the prefs are stored in the workspace.
<Prodoc> hmm...
<Prodoc> still I'd go for the eclipse folder I think, the most stable factor
<Verterok> Prodoc: ok, I'll take a look about how to do that, please file that RFE ;)
<Verterok> Prodoc: Just to note, I've been playing with bzrlib.config, to add support in eclipse (i.e: to allow default username, per branch config, etc)
<Prodoc> so if you use the browse feature to find the exe you'd get an absolute path, if you fill in the location by hand (which isn't possible at the moment) and no drive letter is specified it'll be treated as a relative path
<Prodoc> Verterok: does that mean that a portable solution won't be working for long unless the feature to specify the config folder's location is added?
<Verterok> Prodoc: sure, I'll check about this relative-path thingy, it sound easy to implemente :)
<Verterok> Prodoc: not at all :)
<Verterok> Prodoc: the preference page 'll be exactly the same
<Verterok> Prodoc: the only difference is that bzr-eclipse 'll use the config facilities provided by bzrlib
<Verterok> Prodoc: so, if you have a per branch config of your email (in branch.conf or in locations.conf), it 'll use that instead of the global config
<Prodoc> (if you missed the previous bit of the portable discussion: the config file is stored in  '\Documents and Settings\*user*\Application Data\bazaar\2.0', which isn't available anyone if you go portable)
<Prodoc> ah, cool
<Verterok> Prodoc: my idea was to fallback to global config, but provided a preference page (in the project properties) to allow the customization of it :)
<Verterok> s/provided/provide
<robsta> jelmer: is there any way to work around missing ghost revs?
 * robsta had been wondering why svn and bzr were showing different rev# for some time anyway ...
<Prodoc> Verterok: just wondering, does the ID value in the eclipse prefs overwrite the global whoami setting of bzr at the moment?
<Verterok> Prodoc: yeap, it uses the BZR_EMAIL env var
<jelmer> robsta, the rev numbers being different is independent - see the FAQ
<jelmer> robsta, I'm not sure if there's a good workaround, lifeless/abentley/jam may be able to comment better
<Prodoc> Weird, I thought I never set that value before in Eclipse, and the value differs from the value I set by whoami. Just have made a mistake.
<Verterok> Prodoc: it default to the current user name, but you should change that :)
<Verterok> Prodoc: take a look for a use case for the config improvements: https://bugs.edge.launchpad.net/bzr-eclipse/+bug/264378
<ubottu> Launchpad bug 264378 in bzr-java-lib "No way to stop XMLRPC server" [High,Fix committed]
<Verterok> Prodoc: in that bug, Luis comment about his problem with the global-only config, and request the per branch config :)
<Prodoc> Ah, I was starting to think you send me the wrong link ;-)
<Prodoc> RFE submitted by the way
<Verterok> Prodoc: thanks!Ã§
<robsta> jelmer: well, sigh, thanks anyway
<james_w> beuno: hey, was there a bug about the plugin installer stuff you were working on?
<james_w> I want to dupe bug 275207 to it if there was
<ubottu> Launchpad bug 275207 in bzr "[usability] "bzr vis" should print message saying "you need to install brz-gtk"" [Undecided,Confirmed] https://launchpad.net/bugs/275207
<jfroy|work> vila: https://code.launchpad.net/~jeanfrancois.roy/bzr/keychain-auth-rdonly *very* experimental
<vila> jfroy|work: ok. I'll look at it
<beuno> james_w, there should be. Let me find it...
<jfroy|work> vila: it's really a hack at this point, but I wanted to prototype things. I need to port my _keychain module tests to the bzr test infrastructure
<jfroy|work> although I'm guessing by things I saw that it has issues on OS X?
<jfroy|work> I might have to rewrite the _keychain module using Pyrex as well >.>
<vila> what ? Your proto ?
<vila> Things will be easier if you do that in a plugin, I'll look at what you did to see what is needed
<jfroy|work> yeah, I think a plugin + refactoring in bzr is the way to go
<jfroy|work> Roughly, I'm thinking AuthConfig should provide authentication configuration information, such as a default user name for a particular set of domains, or servers, and then have a list of credential providers capable of giving back a password given a set of connection parameters (host, port, scheme, path, user, etc.)
<jfroy|work> Then plugins can export or register credential providers, and we can add one for the conf file itself as well.
<vila> That's the idea and the user decides in auth.conf, no need to register a 'plain text' credentials provider :)
<vila> jfroy|work: I'm off, I'll try to mail you tomorrow
<jfroy|work> I'd rather avoid the "user decides explicitly" model, in the sense that installing the keychain authentication plugin should be considered as an indication of intention by the user for bzr to check the keychain for credentials when it needs them
<beuno> james_w, actually, seems there's no bug
<james_w> beuno: thanks for looking, I'll open a bzr task on that one
<jfroy|work> vila: np, I'll continue to play around in the branch until I figure out a design that seems to work and scale
<rockstar> jelmer, ping
<jelmer> rockstar, pong
<abeaumont> hi, trying to push to a svn repo i got an error, because the svn repo was tagged. I solved the problem with a svn-push, but now when i try to do a pull i get the same error: 'Conflicting tags:'. How can i solve that? is svn-import the command to solve that?
<jelmer> abeaumont, did you change any tags before you pushed?
<abeaumont> jelmer: in svn repo? yes
<jelmer> abeaumont, remove the tags locally and pull again
<abeaumont> jelmer: ok, it worked, i'll have to do this everytime a new tag is done in svn or i did something wrong?
<jelmer> abeaumont, yes
<jelmer> abeaumont, the same thing would happen if the remote branch was a native bzr branch
<jelmer> abeaumont, bzr tags aren't versioned
<abeaumont> jelmer: oh, I see
<abeaumont> jelmer: ok, thanks!
<LeoNerd> Does bzr have an equivalent of tla/baz's "sync-tree"..? I.e. just pretend a I have some foreign merge?
<LeoNerd> I've tried merge ; revert  but the revert even forgets the pending merges. I want to revert all the file changes -except- the pending merge.. since I know it's actuall been done anyway
<LeoNerd> Ohwait... merge -c   doesn't actually mark it, does it?
<luks> `bzr revert .` ?
<luks> I don't know what sync-tree does, but revert . revers all the changes but not the pending merges
<LeoNerd> That's not helping... it turns out   merge -c   and   merge -r 340..341   don't actually mark the mrge
<LeoNerd> This is ... annoying
<LeoNerd> 'bzr st' doesn't list it in pending merges
<luks> isn't that documented on bzr help merge?
<uws> LeoNerd: No merge tracking for cherry picking, unfortunately
<luks> bzr doesn't track cherrypicks
<LeoNerd> Oh...
<uws> but at least it doesn't generate conflict if you cherry pick the same change twice (checks the ancestor and the resulting file contents, and if they match nothing happens)
<luks> it doesn't fit the "the history is a DAG" scheme
<LeoNerd> uws: Ah OK... that's... probably sufficient
<uws> luks: everyone knows that history repeats itself!
<LeoNerd> OK.. this is a bit annoying.. I've just moved the entire revision control system out of tla/baz into bzr because it's generally nicer.
<uws> LeoNerd: yeah, it sort of works for me
<LeoNerd> Only.. I kinda rely on those cherrypics :P
<nosklo> hello!
<nosklo> I am having trouble using bzr-svn could someone help me?
<nosklo> here is the traceback: http://dpaste.com/81248/ Is it related to using a proxy? Does it support proxies?
<jelmer> nosklo, can you reproduce this? It looks like google code is messing up
<nosklo> jelmer, yes, it happens every time I try.
<nosklo> jelmer, I am now trying it in a machine with a direct connection to see if it is proxy-related
<jelmer> nosklo, bzr-svn uses the same library for network access as the svn command-line client, so a proxy in the middle shouldn't make a difference
<nosklo> this seems proxy-related, since with a direct connection it worked out fine.
<jelmer> ok, strange
<nosklo> jelmer, checking proxy logs now
<alperkanat> anyone here using bzr with mac os x leopard ?
<thrope> jelmer: is there anyway to disable the "The svn+ syntax is deprecated, " message - it comes with every operation and I think it shouldn't be deprecated anyway, since the svn+ syntax is the only way I can access my repository
<jelmer> thrope, Nothing other than commenting it out in the source
<jelmer> thrope, It's correct it's deprecated - it's a bug in bzr that causes it to not work for you
<thrope> ok - it's just its a bit like the message the python interpreter gives you when you type quite
<thrope> *quit
<nosklo> it is a proxy issue. It works with a direct connection. It seems to stop at random revision number - not sure what is happening yet.
<jelmer> nosklo: what sort of request / path is failing?
<nosklo> jelmer, PROPFIND http://formalchemy.googlecode.com/svn/!svn/vcc/default HTTP/1.1
<nosklo> jelmer, I think (by looking at the proxy logs) that this was the last request before fail
<jelmer> nosklo, do you still have the backtrace you got up somewhere?
<nosklo> http://dpaste.com/81248/
<jelmer> nosklo, can you try running something like this:
<jelmer> svn proplist --revprop -r42 http://formalchemy.googlecode.com/svn/trunk
<jelmer> (on the machine with the proxy)
<nosklo> jelmer, you mean on the proxy server?
<nosklo> jelmer, I ran it on both machines, the one behind the proxy and the one with direct connection. Both returned this: http://dpaste.com/81267/
<jelmer> hmm, so I wonder if the proxy broke on a particular revision
<nosklo> jelmer, problem is revision number disappears from the screen when the traceback is printed
<johan> I'm doing a bzr checkout of a bzr+ssh:// branch, but when I do a checking the remote working tree is not updated
<johan> s/checking/check-in/
<uws> johan: That is intended.
<johan> is it possible to remotely update a working tree?
<uws> the idea is that you don't have a working tree at the remote end
<johan> I want the working tree, this is for a website.
<uws> there's a plugin for that I think, bzr-upload  or something like that
<uws> others in here will know
<johan> looks good, thanks
<uws> johan: or the rspush stuff from bzrtools might help (doesn't work with checkouts i think)
<jelmer> nosklo, if you set BZR_PDB=1 when running that command it should put you in a debugger
<jelmer> nosklo, after that, run "up" followed by "print self.revnum"
<nosklo> jelmer, *** AttributeError: 'SvnBranch' object has no attribute 'revnum'
<jelmer> nosklo, you're running "bzr checkout http://formalchemy.googlecode.com/svn/trunk/ formalchemy" again?
<nosklo> jelmer, yes.
<nosklo> jelmer, weird, it seems to stop at random revisions, now the command you gave me returned "1"
<alperkanat> how can i populate a remote directory tree ? should i do checkout then commit ?
<alperkanat> if i branch and then push the changes, how can i populate the mainline ?
<jelmer> nosklo, google code seems to not always be very reliable
<jelmer> not sure how the proxy complicates that though
<hash_g> Hi
<hash_g> Is there a way to configure bzr to commit on change in a period of time ?
<thumper> hash_g: ??? cron?
<hash_g> in the bzr itself I mean
<hash_g> I'm on win xp and don't want to write bat ;]
<nosklo> jelmer, strange that I made thru it to the end 3 times without the proxy. Made a loop trying it behind the proxy and it is still trying, although the error is always on a random revision
<nosklo> jelmer, I will make some tests with non-google repositories
<uws> hash_g: You don't want to commit at random intervals. Commits are intended to mark PROGRESS, not just CHANGES. You may accidently commit broken stuff
<nosklo> jelmer, I think I found out
<nosklo> jelmer, it was some kind of proxy limit issue. Thanks for helping me figuring it out, sorry for the raising a bzr non-issue.
<jelmer> nosklo: Any chance you can file a bug explaining this issue so we can add an entry to the FAQ?
<jelmer> nosklo, (or perhaps just a patch to the FAQ?)
<nosklo> jelmer, of course. I am just trying to fix it, and as soon as I have some full definition, I will do it.
<hash_g> it is a web-design project html/css/png/svg so I want to see progress in time
<hash_g> because some ideas come and gone, it all changes and I want to see how it evolved
<nosklo> jelmer, But I was able to do the entire checkout without problems behind the proxy by stopping the entire network and not using the proxy to anything else.
<nosklo> jelmer, anyway bzr should not die in a traceback
<jelmer> nosklo,
<davidstrauss> I'm getting "bzr: ERROR: Cannot lock LockDir" errors. But when I ssh directly, I have no trouble "touch"ing the file.
<jelmer> there's not a lot it can do
<davidstrauss> I'm running Bazaar 1.7
<jelmer> nosklo, it gets the error from the underlying library and that doesn't provide enough information
<davidstrauss> This is my traceback http://pastebin.com/m4fb1ee08
<hash_g> uws so I want
<hash_g> but don't know how
<hash_g> and probably I would never know
<lifeless> poolie: is 7am, is time to be waking
<alperkanat> i've got a questions about bazaar.. i branch a project.. i make some changes and push it to a centralized server.. i guess that the mainline only has the history of changes not the actual tree ? then what happens if someone else wants to branch the mainline ? will he have the changes of mine ?
<enobrev> can anyone tell me how to disable tortoisebzr on win32?
<trotek> enobrev: try reinstalling and disabling the tortoisebzr option, maybe?
<enobrev> trotek: guess i could try that.  seems silly that it can't be turned off otherwise.  thanks.
<poolie> hello lifeless
<abentley> lifeless: PQM appears hung.  Can you please give it a thump?
<markh> are there any plans at all to localize things like help for options?  If not, is it expected that each GUI toolkit for example, will simply copy/paste these strings and localize them independently from each other?
<abentley> markh: I think localization just hasn't been a priority so far.
<markh> abentley: it looks like qbzr might want to localize some of these strings - it would seem a shame for such localizations to be done provately in its code.
<lifeless> markh: The main concern is performance
<lifeless> markh: e.g. docstrings are evaluated at class object construction, which is at module load time
<lifeless> markh: so if all the command docstrings themselves were localised, we'd process and translate every help text for all commands, just by loading the module.
<markh> lifeless: so yeah, clearly that would be bad.  But having 'bzr help foo' show localized info for the options foo takes needn't cause that, should it?
<lifeless> markh: noone has put a patch forward without that cost, as yet.
<james_w> lifeless: isn't that the use case for N_() ?
<lifeless> markh: if someone were to, I'm sure it would be gladly reviewed
<markh> lifeless: I guess I'm asking if I should encourage qbzr to try and contribute such localizations to the core rather than keep them private.  That would depend on support and help from bzr though, so I guess I'm asking if that would be forthcoming
<lifeless> markh: I wouldn't expect anyone to cut code, if thats what you mean; AFAIK its not near the top of the pile for any of the regular contributors
<lifeless> markh: I'm interested in its existing; I can promise to outline my concerns and review patches
<lifeless> jam did some testing I think about a year back
<lifeless> back online in 90m or so -> poolies
<poolie> hello
<poolie> see you then lifeless
<markh> hrm - I don't think I want to take that burden on all by myself...
<jam> lifeless, markh: from what I remember,simply doing "import gettext" was pretty expensive, and doing "gettext.install()" was also a big issue
<jam> If we used N_() in lots of places, and then translate on-demand that would probably get us around some of the overhead.
<markh> jam: yeah, that might be true.  I'm asking about intent and plans
<jam> It also makes the test suite easier to run as you don't have to worry about the translation at all times
<markh> ie, if bzr has no interest in localizations for such strings, my question is answered!
#bzr 2008-09-30
<markh> I just like avoiding duplication of effort *before* that effort happens ;)
<jam> I think long term we would like to have i18n and l10n in core, we just have to find out if we can do it without suddenly doubling our startup overhead
<jam> which is already too high
<abentley> markh: I don't think we have no interest, but we don't have enough to do it ourselves right now.
<jam> my rough testing here
<jam> shows that it may not cost as much as I was originally worried
<jam> poolie: call time?
<poolie> good point!
<markh> wouldn't you try and only gettext() things as they are displayed?  Even the import could be delayed.  Regardless though, it sounds like the approach I need to take is let qbzr do what it does, and hope bzr can reuse some of it when it gets to the point it cares enough about l10n to apply resources?
<poolie> spiv, call
<jam> markh: well, in traditional C code, I'm pretty sure you sprinkle _() liberally throughout your code
<jam> rather than just at the point of display
<markh> jam: lucky we aren't writing traditional C code ;)
<markh> personally, I think gettext was invented by people who thought considering l10n *before* coding was for wimps ;)
<markh> jam: you probably know the context of this from the qbzr mailing list.  Should qbzr treat localization of the identical options it shares with bzr in isolation?  I understand there are issues so the answer may be "sorry, we don't have the resources to care about that now, just go for it"...
<poolie> that's probably a reasonable answer
 * markh will one day learn to accept a simple answer... :)
<markh> another option would be for bzr to adopt localizations - but not attempt to use them at runtime.  The doc generation process could though, and it would offer a single entry point for projects like qbzr to not only source l10ns from, but to contribute them to.
<markh> then later, bzr could adopt them at runtime if it can work out how to without costing too much perf
<markh> am I just making things hard on myself?
<poolie> that could be good
<fullermd> Making things hard on himself?   :)
<johan> I get this warning when pulling old branch (using bzr 1.5): Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<johan> this is from launchpad, what am I doing wrong?
<mwhudson> johan: using bzr 1.5
<mwhudson> if you upgrade to 1.6 it will go away
<mwhudson> (the message from the client is a bit misleading, yes)
<johan> mwhudson: sure, will do, thanks
<johan> mwhudson, beuno: btw, great work on loggerhead. 1.6 is really nifty
<mwhudson> it's getting there :)
<johan> works fine here
<johan> except that I couldn't quite figure out how to configure user-dirs properly
<mwhudson> it's still too slow, uses too much memory
<mwhudson> (but you probably won't notice unless you're us)
<mwhudson> ah yes, the user dirs thing is a strange beasty
<johan> it's not instant, but /much/ faster than before
 * mwhudson afk for a bit
<poolie> biab
<spiv_> poolie: hi, sorry I missed the call.  Today I'm going to try land most of my patches that are approved in bundle buggy.
<Peng_> mwhudson: ping?
<mwhudson> Peng_: hi
<Peng_> Hi!
<Peng_> mwhudson: I'm being impatient, but can you confirm my issues in https://bugs.edge.launchpad.net/loggerhead/+bug/268867/comments/2 ? I might have just broken my LH setup or something.
<ubottu> Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New]
<mwhudson> Peng_: i can easily believe
<mwhudson> it
<mwhudson> Peng_: whenever i think about url generation in loggerhead i just want to cry :/
<Peng_> Heh.
<Peng_> I've backed out breadcrumbs from my copy of LH due to that bug, but it's starting make it hard to keep merging the trunk.
<mwhudson> Peng_: care to help me configure apache locally to reproduce?
<Peng_> I run Lighttpd. :P
<mwhudson> bah
<Peng_> I dunno. I run a pretty basic mod_proxy setup.
<mwhudson> ah, ok, can reprp
<mwhudson> *o
 * mwhudson stabs simpleTALES
<Peng_> Oh, good (or not).
<mwhudson> well, it's just so fun to debug
<mwhudson> WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: 'int' object is not callable
<mwhudson> a traceback would be nice
<mwhudson> uh
<mwhudson> does this stuff work at all?
<Peng_> What?
<Peng_> Is it just me, or does serve-branches not use loggerhead.trace.setup_logging()?
<mwhudson> Peng_: breadcrumbs
<Peng_> mwhudson: When I filed bug 268867, they seemed fine, aside from that bug.
<ubottu> Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,New] https://launchpad.net/bugs/268867
<Peng_> I run a stripped-down version of serve-branches. Stop improving it, guys, it's getting hard to hack it all out. :(
<mwhudson> Peng_: can you try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs ?
<mwhudson> (when it gets there)
<Peng_> OK
<mwhudson> Peng_: try now
<Peng_> Yeah
<Peng_> Argh, that's based on the tip. I still haven't merged that.
 * Peng_ 's head spins
<mwhudson> Peng_: what changes do you have from tip?
<Peng_> mwhudson: Mainly my stripped-down version of serve-branches.
<mwhudson> Peng_: what does serve-branches do that you don't want it to, by default?
<Peng_> mwhudson: I started when it was still new and very simple. I occasionally added something (sys.path, different logging, etc.), and whenever you added a feature I didn't need (--port or something), I didn't merge it, so now my script is kind of a mess.
<mwhudson> i see
<mwhudson> i guess it would be easier for you to call your script something else :)
<Peng_> :)
<Peng_> Heh.
<Peng_> Hmm, that's not a bad idea.
<Peng> Packet loss to your server is a good excuse not to work on LH, right? :P
<mwhudson> heh heh
<Peng_> Wait, I only needed to change like 2 lines in serve-branches. Thank you, "bzr diff".
<Peng_> mwhudson: Err, now I just got a traceback.
<mwhudson> Peng_: darn
<Peng_> Hold on
<mwhudson> Peng_: pastebin?
<Peng_> Damn, I forgot about Paste not logging exceptions.
<Peng_> Which the new serve-branches code I didn't merge may have fixed.
<Peng_> mwhudson: It was when I visited the root page. Here's the tail of the traceback, fwiw. http://paste.pocoo.org/show/86566/
<mwhudson> oh ffs
<abadger1999> mwhudson: What's wrong with breadcrumbs?
<Peng_> They attract roaches.
<Peng_> And housecats!
<abadger1999> well housecats aren't so bad.
<abadger1999> except the vet bills.
<mwhudson> Peng_: try pulling rev 228
<Peng_> Hold on
<Peng_> mwhudson: Of which rbanch?
<mwhudson> uh
<Peng_> fix-breadcrumbs? I don't see a new revision
<mwhudson> bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/fix-breadcrumbs rev 229
<mwhudson> it'll be there in a minute
<Peng_> Yeah, there iti s
<mwhudson> you want 229 though, 228 is trivially broken
<Peng_> Oh.
<Peng_> Hey, no instant explosion!
<Peng_> mwhudson: Seems to work perfectly (testing only the root and a /changes page)
<mwhudson> Peng_: good good
<Peng_> (Aside from how the links don't end in a /, but that's only a minor inefficiency, not a real issue.)
<Peng_> mwhudson: Thank you! :)
<mwhudson> i guess i'll merge to trunk then
<Peng_> :)
<Peng_> mwhudson: Not that it really matters, but do you mind if I add the fix-breadcrumbs branch to the list of related branches on the bug?
<mwhudson> Peng: nope
<Peng_> Thanks again for fixing this. :)
<mwhudson> np
<abadger1999> mwhudson: Hmm... I have errors with that branch.
<abadger1999> http://localhost/bzrpackagedb/fedora-packagedb-devel
<mwhudson> abadger1999: that's not a very useful url :)
<abadger1999> There should be a "/" between bzr and packagedb
<abadger1999> heh.  yeah.
<abadger1999> mwhudson: server.webpath = 'http://localhost/bzr/'
<abadger1999> And... I'm using my mod_wsgi script rather than serve-branches.
<mwhudson> abadger1999: ah, what happens if you don't have the slash on the end of the webpath?
<mwhudson> well, nothing i guess
 * mwhudson hates urls
<abadger1999> mwhudson: I get the same error.
<abadger1999> well not error.  Same url.
<mwhudson> yeah, sorry, that was daft
<mwhudson> abadger1999: where do you get it?
<abadger1999> Those are the links on the front page.
<abadger1999> So that's one of my branches
<abadger1999> The branches are autoconfigured.
<abadger1999> auto_publish_folder = '/bzr/packagedb/'
<mwhudson> abadger1999: um, is this new with this branch?
<abadger1999> mwhudson: yeah.  I wrote the breadcrumb patch that was merged at revno 224.
<abadger1999> mwhudson: It worked at that point.
<abadger1999> Actually... Let me just make sure I didn't have any other patches in my mod_wsgi branch that have bearing on this.
<mwhudson> yeah, rev 227 _really_ shouldn't have changed the browse view at all
<abadger1999> mwhudson: My browse.pt  has:                     <a tal:attributes="href python:branch.static_url('/' + project.name + '/' +  view.name)"
<abadger1999> yours doesn't have the '/'
<mwhudson> the first one?
<mwhudson> hm
<mwhudson> abadger1999: is this a change you made?
<abadger1999> I think I must have added that specifically for the mod_wsgi stuff.
<abadger1999> I just confused the browse.pt and breadcrumbs.pt changes.
 * mwhudson grumps
<mwhudson> it seems that all calls but that one to static_url have '/' as path[0]
<mwhudson> so i may as well change that one
<abadger1999> mwhudson: Cool.  Have you looked at my mod_wsgi branch?
<mwhudson> abadger1999: no
 * mwhudson looks
<abadger1999> mwhudson: https://code.launchpad.net/~toshio/loggerhead/mod_wsgi
<mwhudson> abadger1999: do you know how unicode ends up in SCRIPT_NAME ?
<abadger1999> mwhudson: Well, mod_wsgi and paste both put it there.
<abadger1999> mwhudson: I'm talking to the mod_wsgi upstream right now... it might be part of the wsgi spec
<mwhudson> ok
<mwhudson> "HTTP does not directly support Unicode, and neither does this interface. All encoding/decoding must be handled by the application; all strings passed to or from the server must be standard Python byte strings, not Unicode objects. The result of using a Unicode object where a string object is required, is undefined."
<mwhudson> (from pep 333)
<abadger1999> yeah.
<mwhudson> but whatever
<mwhudson> abadger1999: i think on trunk, you should be able to call loggerhead.trace.something rather than copy/paste the logging config
<mwhudson> (in loggerhead.wsgi)
<abadger1999> That would be nice.
<mwhudson> and in general it would be nice for start-loggerhead and loggerhead.wsgi to share slightly more code
<mwhudson> looks fine in other respects though
<abadger1999> mwhudson: Sure.  Do you want the code moved into loggerhead and the two scripts just call them?
<abadger1999> Or just to use the same code?
<mwhudson> abadger1999: i think that would be great
<abadger1999> Cool.
<mwhudson> (the former)
<GPH-Laptop> If I create a central/shared repository (bzr init-repo) over an existing file structure, what will that do? Will it change any of the files? Will it automatically include all of them in the repository?
<fullermd> No, it won't change any existing stuff.
<fullermd> It'll only affect new branches.
<GPH-Laptop> Can those files be edited directly?
<fullermd> Which files?
<GPH-Laptop> Lemme explain the situation and give some background
<GPH-Laptop> our web team here has been maintaining the large (university) website using one SFTP user
<GPH-Laptop> all developers use that same user to upload changes to the server
<GPH-Laptop> which means that conflicts occur, and no one know who did what or when
<GPH-Laptop> I would like to switch development over to Bazaar
<GPH-Laptop> so... would it be best to init-repo right over the htdocs, or should I put it in a separate location?
<fullermd> OK, so that's not _quite_ the right question.
<GPH-Laptop> I would prefer that each developer be able to use their own username to commit changes
<fullermd> Repos (init-repo) don't contain files; you don't work in repos.  Branches (init) do.
<thumper> lifeless: ping
<GPH-Laptop> instead of the master username
<GPH-Laptop> ah, OK
<fullermd> Repos are used to share storage among related branches.  We can ignore them for now.
<thumper> james_w: I don't suppose you have insomnia?
<fullermd> GPH-Laptop: The branch itself is the unit you work with; all the files are in there, that's where you edit, where you commit, etc.
<GPH-Laptop> right
<fullermd> GPH-Laptop: So, the question is, what are the boundaries of the branch?  Is the entire site one monolithic entity, or are there multiple pieces in it that are rather independent?
<fullermd> That's a question both of structure (how does it all fit together?), and of development (are there separate maintainer teams for different pieces?).
<GPH-Laptop> I'm not sure... I think it's kind of a mixture... the web team has access to everything, but users also have their own ~homedirectory/
<GPH-Laptop> but those personal directories need not be included
<fullermd> Well, those aren't in htdocs, right?  They're off in userdirs.
<GPH-Laptop> true, yeah
<GPH-Laptop> but there are a lot of symlinks to custom dirs
<GPH-Laptop> that might not quite map to a specific user
<GPH-Laptop> but nonetheless act like a userdir
<GPH-Laptop> I think
<fullermd> Well, that probably doesn't matter.  bzr won't walk _through_ the symlinks, though it could version the symlinks themselves.
<GPH-Laptop> OK
<fullermd> (you can choose to ignore and not version them of course)
<GPH-Laptop> right
<fullermd> Presumably they're somewhat peripheral; they're not necessary bits of the site proper, they're just other things that happen to be under the same base.
<GPH-Laptop> yeah
<GPH-Laptop> not something that would be actively developed
<fullermd> So, as a first approximation, "everything under htdocs that's part of the actual site" would be the bounds of the branch you want to create.
<GPH-Laptop> right
<GPH-Laptop> sounds good
<fullermd> Which may just be everything there, then eventually drop things like symlinks as you figure you don't need them, or may be more careful up-front deciding.
<fullermd> One thing to remember is that once something's committed, it will always be in the history.  That could matter for two reasons; information security, and storage/transfer resources.
<GPH-Laptop> right
<fullermd> On the one hand, if you commit a file with passwords in it, even if you later delete it it'll always be in the history.
<fullermd> On the other, if you accidentally commit that directory of DVD ISO's...   well, your branch is gonna be Zarking Huge(tm) forever, and take ages to download.
<GPH-Laptop> right
<GPH-Laptop> no way to delete that stuff?
<fullermd> Well, yes and no.
<fullermd> It's permanently part of that history; there's no way to go back to a revision and take out parts of it.
<jml> why does TransportConfig.set_option() take value, name rather than name, value?
<fullermd> You could create a new history from scratch, that's pretty much like the old one EXCEPT without those pieces.
<fullermd> But that's a new history; you can't merge from the old stuff into it, everybody has to re-download from scratch, etc.
<GPH-Laptop> oh, wow, no file-by-file?
<fullermd> Right.  Revisions are the whole tree.
<GPH-Laptop> right
<GPH-Laptop> gotta remember that
<fullermd> Now, things like symlinks that are neither sensitive nor huge, that get committed but you don't really want and eventually delete, are still 'clutter' in the repo in a way, but probably don't much matter.
<GPH-Laptop> hmm
<fullermd> So you have to look at just what your situation is to figure out how painstaking you want to be about setting up things initially.
<fullermd> It doesn't sound like you have much worry there, though I've seen some big files hiding around web dirs long after their purpose (if any) had vanished.  Ultra-high-res images, tarballs, blah blah blah.
<fullermd> Somebody needed somewhere to stick that MPEG to send to their friend, 6 years ago, and forgot about.
<GPH-Laptop> heh
<GPH-Laptop> yeah
<GPH-Laptop> hmm
<fullermd> At the moment, you have no history to preserve at all.  So, if a week from now you find out there's a buncha big stuff there you didn't really want, it may not be a big loss to just throw away the bzr metadata and re-start from scratch.
<fullermd> Throwing away history like that makes ME twitch, of course.  But a lot of people are less obsessive than I am   :)
<GPH-Laptop> is the repo compressed in any way?
<GPH-Laptop> I'm probably more on your side of that line ;)
<GPH-Laptop> but I don't know how the rest of the web team is
<GPH-Laptop> I just joined it
<fullermd> Yes, changes are stored as deltas rather than as continaul full-texts.  And there's gzip compression of the whole repo.
<GPH-Laptop> oh, OK
<GPH-Laptop> good
<fullermd> Future formats will probably feature much better compression, especially for binary files.
<fullermd> As current VCS's go, the current bzr formats are a little on the large side for the history.  But that doesn't sound like it will be a big deal for you.
<GPH-Laptop> OK
<GPH-Laptop> I tried to find something that fit what we needed... Git and Mercury didn't seem to cut it
<GPH-Laptop> the problem is, there aren't any good Mac OS X GUI clients
<GPH-Laptop> and we could really use that
<fullermd> Where did git and hg fall short?
<GPH-Laptop> I forget... just at places that I consider important... I think they just did things differently than I would prefer
<GPH-Laptop> Why? Would you recommend one of those instead?
<fullermd> Well, if I did, I'd be in #hg or #git rather than #bzr   :)
<GPH-Laptop> That's what I figured
<fullermd> Partly, I'm just curious.
<GPH-Laptop> Yeah, I don't remember
<GPH-Laptop> it was probably things we won't even wind up using
<fullermd> And partly, despite a lot of higher-level differences the base models among the three are very similar.
<GPH-Laptop> but I'm a kind of guy who thinks CVS does some things better than SVN
<GPH-Laptop> like tags and branches and stuff
<fullermd> SVN does tags and branches?   ;)
<GPH-Laptop> exactly
<fullermd> I used CVS for many years.  I moved to bzr after I decided SVN was mature enough to consider, and actually _looked_ at it.
<GPH-Laptop> heh
<GPH-Laptop> Wikipedia's got a nice comparison
<abadger1999> GPH-Laptop: Tags I agree with you, branches not so much.
<GPH-Laptop> abadger1999: Maybe not in the sense of merging
<abadger1999> True. svn has branching but merging was not fun.
<fullermd> Of course, CVS by its nature allows things that none of the modern VCS's do.
<GPH-Laptop> either way, Bazaar looks to be a good choice
<GPH-Laptop> and I'd like to implement it ASAP ;)
<fullermd> Always a good plan   :)
<GPH-Laptop> I just had to deal with a editing conflict
<GPH-Laptop> which is not good over SFTP
<fullermd> Now, here's the last sticky question; what's your deployment plan?
<fullermd> (deploying the website, that is, not bzr)
<GPH-Laptop> oh
<GPH-Laptop> well
<fullermd> When you 'bzr push' (or whatever workflow method you use) the changes up to your central site, it'll push the repo stuff with the history and all, but it doesn't do anything with the checked-out working files.
<GPH-Laptop> we actually have two different websites... htdocs-dev operates on :8888, htdocs is live at :80
<fullermd> So you need some way to actually update the files the webserver sees.
<GPH-Laptop> So they can't be the same files?
<fullermd> Well, they never ARE the same files, much like the RCS files in a CVS repo aren't the same files as the working files in your checkout.
<GPH-Laptop> true
<fullermd> You can't point Apache at a CVS repo and have the files served (at least, not without horribly evil mod_whatever we'll pretend doesn't exist)
<GPH-Laptop> lol
<GPH-Laptop> OK, so they'll need to be pushed live either way
<fullermd> It's analogous with bzr; commands like "bzr push" shove around the 'repo', not working copies.
<fullermd> Right.  There are a number of possible routes, but which is best depends on your case.
<fullermd> For me, I'm a *nix guy, and I work with servers I can login to.  So MY deployment scheme is a set of Makefile's, and I deploy via "make install".
<GPH-Laptop> oh
<GPH-Laptop> I was thinking cron
<fullermd> For devs that need a Mac GUI client, this is obviously not so hot a choice   :)
<GPH-Laptop> yeah
<fullermd> cron is an option; just have a checkout where Apache looks for the site, and "bzr up" every 12 hours or something.
<GPH-Laptop> yeah
<bob2> (don't forget the bzr-update-after-push plugin)
<fullermd> That could be supplemented by a carefully-crafted secure page with a "click here to force update".
<GPH-Laptop> oooh
<GPH-Laptop> OK, now we're getting fancy
<GPH-Laptop> let's get the thing set up first :P
<fullermd> As bob2 said, there's a push-and-update or something plugin, which makes the push ssh into the server and run 'bzr up' every time you push.
<fullermd> Though that means that the branch you're pushing into would have to be the one sitting where Apache looks, which may not be your best choice.
<fullermd> There's also a "bzr upload" plugin, which deploys/updates working files via sftp (or probably other transports) out of your local working dir.
<fullermd> The conceptually simplest is probably the first; having a checkout where the live site points, and updating that (via cron, via manual, via whatever) at the appropriate interval.
<GPH-Laptop> OK
<GPH-Laptop> so first I set up a repository outside of htdocs
<GPH-Laptop> ?
<fullermd> Doing that (or any other thing where the live site is an actual bzr branch), I'd be sure to take pains to block off access to the .bzr directory, just on GP.
<fullermd> I'd play with it locally first.  Copy down all the files (or take a copy of the ones you already have), and setup a branch.
<GPH-Laptop> aren't dot-prefix files automatically off-limits?
<fullermd> A thing to realize is that the location of and relationship between branches are MUCH more fluid than in CVSVN.
<fullermd> Not in any server I've ever worked with....  Apache blocks and reserves .ht*, but no other dotfiles.
<GPH-Laptop> oh, OK
<GPH-Laptop> well, what if I set up everything on the server, but outside the realm of the public website
<GPH-Laptop> and basically pretend like I'm committing to the website
<GPH-Laptop> ?
<fullermd> Here's what I would suggest.
<fullermd> 1) First setup a branch locally and play with it a while, to get used to actually _using_ bzr.  If you've already got CVSVN background, you'll have all the general knowledge, so just a little while of fiddling should get you used to the minor differences.
<fullermd> 2) Once you're comfortable with that (and assuming you haven't trashed your branch ;), setup a "central" branch on the server (probably somewhere other than the web root), and reconfig your local branch to be a checkout of it.
<fullermd> Up to this point, you're the only one using bzr, so you'll have to take care to bring in any changes from the live site.
<fullermd> Then, 3) strongarm your associates into making their own checkouts and working from them.
<GPH-Laptop> heh
<fullermd> (up to here, you're still _deploying_ the files however you're doing it already; FTP or rsync or whatever)
<GPH-Laptop> yeah
<fullermd> Then 4) choose the deployment strategy; making the live site a checkout, etc.
<GPH-Laptop> OK
<fullermd> Now, note that you're actually _using_ bzr pretty much like CVSVN here; there's one central branch that everybody checks out.
<GPH-Laptop> the problem I'm having in my head is the terminology, e.g. the difference between a branch and a repository, etc.
<fullermd> The native support for that workflow is, IMO, one of the *BIG* things bzr brings to the table than the other DVCSen don't.  They tend to undervalue its real use.
<fullermd> Gimme a sec to finish off this email, then we can chat about that.
<GPH-Laptop> ok
<fullermd> There.  Darn clients...
<GPH-Laptop> heh
<fullermd> So, in CVS, you essentially have two pieces.  You have the repo, where all the history and metadata and whatnot is stored, and the checkout, where you actually work on files.
<GPH-Laptop> yup
<fullermd> Branches are implicit, and essentially properties of certain revision numbers.
<fullermd> SVN is similar, except worse in making branches social constructs of various paths within the repo.  *shudder*
<GPH-Laptop> heh
<fullermd> In both cases, you actually check out [some subset of] the repository.
<fullermd> In bzr, things are a bit different.  The checkout is still pretty much the same; it's where you work on files.
<fullermd> The repository is basically a big bucket, into which every revision goes.  There's no order or sorting per se; it's just a big storage box.
<fullermd> You can't "check out" a repository; the concept is just without meaning.
<fullermd> There's a third entity, which is the branch.  It's an explicit construct, rather than being implicit like in CVS or SVN (in their own different ways)
<fullermd> A branch is what says "THIS is the current revision", basically speaking.
<fullermd> Each revision points to another rev (or 2 revs, or 3 revs, or no revs in the case of initial revisions) and says "That's my parent.
<lifeless> thumper: pong, but leaving poolies soon, topic ?
<fullermd> So essentially, a branch describes WHICH revisions are important for a particular line of development.
<GPH-Laptop> I see... and these revisions are the who repository, not just specific files, right?
<fullermd> The branch doesn't actually HAVE them; it just says which you care about.  You reach into the bucket of the repository to fish out the revs you want at any given time.
<fullermd> Right.
<fullermd> In the "default" case, where you run "bzr init", then add files and work on them, all 3 pieces (checkout, branch, repository) are sort of colocated, right there where you're working.
<fullermd> When you use init-repo, then make branches inside that repo, you've got 2 pieces (checkout and branch) colocated, with the repository being a step up.  And that repository is then shared by multiple branches.
<fullermd> And you can have other cases where all 3 pieces are in different places.
<fullermd> But in most ways, it doesn't matter which way things are setup; everything works the same.
<GPH-Laptop> OK, this is the part where I lose you, hang on
<fullermd> OK.
<GPH-Laptop> what do you mean when you say "colocated"? the same directory?
<fullermd> Right.
<GPH-Laptop> so what does init-repo do?
<fullermd> (well, technically, the checkout metafiles are in .bzr/checkout/, the branch in .bzr/branch/, and the repo in .bzr/repository/, but...)
<GPH-Laptop> :P
<fullermd> init-repo creates a shared repository, which is a repo that multiple branches can refer to.
<fullermd> Take your site.  Let's presume it's big, and has a lot of history.
<fullermd> Enough that the whole history is a hundred megs.
<fullermd> Anytime you make a new branch, the whole history is in each place, so if you "bzr branch trunk fixlinks" to make a branch to fix some links in, you eat up another hundred megs of disk space.
<fullermd> (to say nothing of eating 200 megs of I/O, or worse, a hundred megs of network)
<fullermd> Obviously, this doesn't scale well.
<GPH-Laptop> right
<fullermd> In CVSVN, there's only one copy of the history, ever; on the central server.
<fullermd> This means that access the history can be slow, or even impossible if you're disconnected from the network (or it is)
<fullermd> So with the distributed systems, everybody has a copy of the history locally.
<fullermd> Which wouldn't be so bad, really, if you only had to deal with ONE copy of the history, rather than one per branch.
<fullermd> Enter, the shared repository.
<fullermd> Because remember, branches don't actually hold the history; the repository does.  So you _need_ one copy per repository.
<fullermd> You can thus share one copy of the history across multiple branches, IF the branches share one repository, rather than each having their own.
<fullermd> We often say "repository" when we MEAN "shared repository", and so we say things like "you don't need a repository"
<fullermd> Of course, every branch needs a repository, but it can be either private ("standalone branch"), or shared among multiple branches (which is what init-repo does for you)
<fullermd> The important thing (as mentioned in the separate of the 3 pieces earlier) is that the existence of a shared repository doesn't change any of the semantics of working on the branches.
<fullermd> It just saves space (and time, since there's less data to shuffle around in various operations)
<fullermd> So, for instance, let's say we're both working on this site, and we each have 3 branches.
<fullermd> Let's say they're the same 3, for simplicity.  trunk, fixlinks, and newimages.
<fullermd> We've got a central server, with a shared repo in /repo, and the branches inside that repo: /repo/trunk, /repo/fixlinks, and /repo/newimages.
<fullermd> So on the server, there's one repository in /repo full of all that history, which is probably mostly the same.  The branches have diverged a bit, but most of their history is still common.
<fullermd> So instead of taking up 3*N space, it just takes up N+<a few little bits of the differences>.
<fullermd> Now you've got a repo in ~/website, with the 3 branches checked out in it: ~/repo/trunk, ~/repo/fixlinks, ~/repo/newimages
<fullermd> Er, ~/website/, not ~/repo/ in all those cases.
<GPH-Laptop> ight
<fullermd> Now I've got all 3 checked out too: ~/website/trunk, ~/website/fixlinks, etc.
<fullermd> BUT, for whatever reason, I *DON'T* have a shared repo in ~/website/
<fullermd> So on MY machine, each of those branches has their own (internal) repo, so I have 3 full copies of the history.
<fullermd> Rather stupid on my part.
<GPH-Laptop> heh
<fullermd> But it doesn't have any impact on how I work with you, or with the central server.
<fullermd> Any operation that we'd need to refer to each other with, like merging or pulling, just points at a branch.  Finding the repository for that branch is handled entirely internally.
<GPH-Laptop> on the central server?
<fullermd> On any place.
<GPH-Laptop> ok
<fullermd> It's distributed remember; a central server is a VERY handy social construct, but it's not a technical one in distributed systems.  Any branch is equal technically.
<GPH-Laptop> ok
<GPH-Laptop> so what is the difference between my files and your files?
<fullermd> If I create a repo in ~/website/ later on, it doesn't affect those existing branches.
<fullermd> But I can explicitly convert them to using a repo, and so regain all that space.
<fullermd> So the important points here are (a) [shared] repo layouts (or even usage) don't have to be consistent across a project; they're purely local constructs
<fullermd> And (b) your choice of laying out or using shared repos isn't permanent; you can change it around anytime, with very little work.
<GPH-Laptop> so the shared repo is for me and my multiple branches?
<fullermd> Essentially, the difference between my files and your files is...   well, my files are my files, and your files are your files   :)
<fullermd> Right.  A shared repo only has meaning where it is; it doesn't affect anything outside.
<GPH-Laptop> I think I'm having trouble letter go of the central server
<fullermd> All commands work on and between _branches_, not repos (not quite true, but close enough).
<GPH-Laptop> letting
<fullermd> You never checkout a repo, or branch a repo, or commit into a repo; you do things on branches.
<fullermd> Sure.  And you shouldn't necessarily; most of my work has a central server.  But that's because I _choose_ one location to be central.
<GPH-Laptop> one shared repo
<fullermd> It becomes central because I treat it as central; I push all my revs up there, and other people push their revs up there, and we agree that that's the "master", "authoritative" copy.
<fullermd> But there's no technical different; no separate setup, no special "I am master" flag.
<GPH-Laptop> so, in my case, a shared repo on the server
<fullermd> If you're going to have multiple branches (even possibly in the future), yes, a shared repo.
<fullermd> But you don't need to; if all you'll ever have there is trunk, you could just make it a standalone branch.
<GPH-Laptop> would be the "central" location
<GPH-Laptop> I think we'll be needing multiple branches
 * fullermd nods.
<fullermd> Probably a good idea to plan for that, even if it doesn't ever come about.
<GPH-Laptop> OK, so the server has the one central shared repo
<GPH-Laptop> now how do the branches work?
<GPH-Laptop> are they on the server, or local, or what?
<fullermd> So, going back to my 4 steps earlier, in (1) you create a standalone branch locally to fiddle with, and then in (2) push it up to becoming a repository branch in the shared repo in the server.
<fullermd> Both.
<fullermd> Let's take the example of bzr itself.  It's developed in bzr.
<fullermd> I keep a local mirror of the bzr development.
<fullermd> I did that via "bzr branch http://bazaar-vcs.org/bzr/bzr.dev/", which is where that branch is available.
<fullermd> And every few days, I do a "bzr pull" to keep it updated.
<fullermd> Sorta like using cvsup to mirror a CVS repo.
<GPH-Laptop> yeah... I used GUI for CVS, too :P
<fullermd> Now, _conceptually_, to me, that's just a mirror.  I don't do local development.  It's not, to me, a "new branch".  It's just a copy of the main one.
<fullermd> But technically, in bzr terms, it IS a new branch.  It's a new branch that HAPPENS to never get anything in it that isn't copied from somewhere else, but that's just happenstance.
<fullermd> So right off, there are 2 branches of bzr in the world; the one on bazaar-vcs.org, and the one on my hard drive.
<fullermd> In technical terms, there's no reason to prefer one over the other for being the "real" bzr, or the "master" bzr.  It's a social decision.
<fullermd> In your case, you'll have a branch of the site on server:/repo/trunk/, and a branch on workstation:~/website/trunk/.
<fullermd> (assume you do a 'branch', not a 'checkout', which you probably won't, but for the purposes of this discussion...)
<fullermd> You'll work in ~/website/trunk/, and make commits.  They're sitting there, nowhere else.  You'll push those revs up to the server:/repo/trunk/ when it seems appropriate to you.  And you'll pull new revs from there that other people push up there.
<GPH-Laptop> so I commit locally first, and then push the commits to the server later?
<fullermd> By and large, using checkouts will be easier; those will act pretty much like you'd expect from CVSVN.  You commit, it goes to the repo on the server.  You try to commit and you're out of date, you have to 'update' then commit.
<GPH-Laptop> oh, ok
<fullermd> If you're working in a branch rather than a checkout, yes.
<fullermd> (This is also a lie; checkouts support commit --local.  But until you've a pretty deep understanding of bzr and just what it does, you'd be well advised to forget about it)
<GPH-Laptop> consider it done
<GPH-Laptop> ;)
<fullermd> The basic commands are what you expect from CVS.  Commit is bzr commit or bzr ci, update is bzr up, checkout is bzr co, diff is bzr diff, stat (which doesn't exist in CVS, irritatingly) is bzr stat, etc.
<fullermd> The extra commands come when you deal with multiple branches and moving stuff between them.
<GPH-Laptop> OK, well, we're in the process of moving from PHP4 to PHP5
<fullermd> push and pull are sorta like mirroring commands; make {that branch there, this branch here} an up-to-date copy of {this branch here, that branch there}
<GPH-Laptop> but they need to be independent of each other
<GPH-Laptop> so that would be branches, no?
<fullermd> merge is used to merge together changes from another branch into one you're working on locally.
<fullermd> Right.
<fullermd> So, let's pretend that you're the only one doing the 4->5 conversion.
<fullermd> The other half dozen people are just continuing to work on the existing site.
<fullermd> There's a server:/repo/trunk/ branch that's used for that.
<fullermd> And you've got a checkout of it in ~/site/trunk/
<fullermd> (and so does everybody else of course)
<fullermd> You work with this just like you'd work with CVS.
<fullermd> Now, you want to go work on the 4->5 conversion.  Nobody else is involved, so you decide not to bother putting a new branch on the server.
<fullermd> Instead, you just make a branch locally.  You do something like "cd ~/site ; bzr branch trunk php5"
<fullermd> Now you've got a new branch in ~/site/php5/ to do that work.
<fullermd> You work for a week or two, getting a bunch of it done.  Meanwhile other people are still making changes to the live site, so obviously you need to work those in too, or your conversion will be a conversion of an old version of the site, which isn't much help.
<fullermd> So you keep your trunk copy updated: cd ~/site/trunk/ ; bzr up
<fullermd> (and you may still do some work on trunk too; who knows)
<fullermd> And every so often, you merge those changes into your ongoing PHP5 work: cd ~/site/php5/ ; bzr merge ../trunk
<fullermd> This merges them in and prepares the merge commit, though it doesn't actually commit it.  This gives you a chance to resolve any conflicts, and generally look things over, before you "bzr ci" to commit the merge.
<fullermd> Rinse, repeat; this process goes on for about 20 freakin' years, until you finally get done the conversion.
<fullermd> Then when that's done, it's time to take it live.  So you go the other way around: cd ~/site/trunk/ ; bzr merge ../php5   (review and commit)
<fullermd> And now the branch is landed, you take it live, receive worldwide adulation.  Riches, power, beautiful women throwing themselves at your feet, etc.
<GPH-Laptop> lol
<fullermd> There's a few things to notice here.
<fullermd> 1) Since bzr actually has merge tracking, there's no magic about all those merges from trunk into php5 you did along the way.  You just do 'bzr merge', and it brings in the new stuff.  No remembering what you've merged before, no re-re-re-resolving old conflicts, etc.
<fullermd> You can do it as often as you want.  Do it every day at 4:30 pm, and each merge will make very little change; and when it DOES conflict, it'll conflict in code you were just working on, so it's easy to fix.
<fullermd> bzr has very smart merge algorithms, but the biggest thing that makes merging easy is making a lot of small merges all through the process, rather than one giant merge at the end.
<fullermd> 2) This php5 branch you did all this work in, never existed on the server.  It only ever exists on your local drive.
<fullermd> 3) Once you've done the merge into trunk at the end, all those revisions are in the trunk branch too.  So you could rm -rf php5, and you still have that entire detailed history in trunk if you ever need to go back to it.
<fullermd> And as a consequence of (2), 4) Nobody needs to even know you've done any of this until it's landed.  So you don't need to get buy-in to the idea ahead of time; only when it's ready.
<fullermd> (which isn't to say that working in a corner on codebombs is a good idea; just that the barriers are social, not technical)
<fullermd> Now, let's back up a little, and pretend you're partway done.
<fullermd> And you have to go on vacation.  Luckily, I'm also working on this site, and I can do PHP stuff, so I can take it over and finish it for you.
<fullermd> I do that by making my own branch of your php5 branch in my ~/site/php5/.
<fullermd> (how I get to your branch is an open question, but irrelevant; somehow you give me access to be able to read those files)
<fullermd> My branch has a full copy of all your history of course.  So I pick up where you left off, doing my own merges from trunk occasionally.
<fullermd> Eventually I finish, then *I* merge it into trunk and land the changes, and *I* get the riches and fame.  You come back from vacation to find yourself my handservant.
<GPH-Laptop> lol
<GPH-Laptop> thanks a lot
<fullermd> Again, the php5 branch never existed on the server.  You've still got an old, outdated copy of it on your hard drive.  I've got the new, latest copy on mine.
<fullermd> Both of us can rm -rf them now if we want.  Or you could 'pull' mine, so that yours is up to date, then rm it.  Or keep it around for a while, just in case.  Doesn't matter.
<fullermd> But let's back up and assume that you're not going on vacation, but you decide you need some help with it; it's too much for one person to do on their own.
<fullermd> So you again come bother me, and nag me into helping.  I get my copy from your machine into ~/php5/, and go on working.
<fullermd> Of course, we can't just each go off our separate ways; we have to stay in sync.
<fullermd> So, much like merging trunk, every so often I would "bzr merge bzr+ssh://GPH-Laptop/home/gph/site/php5/" (or however I access it) to merge in your changes since last time I synced.
<fullermd> And you would do the same in reverse; merge my changes back.
<fullermd> This means that if, say, I do my daily merge of trunk, and then afterward you do your daily merge of my changes, you get all the stuff from trunk and don't have to merge it yourself.
<fullermd> Of course, you COULD just go ahead and "bzr merge ../trunk", but you may get the answer "Nothing to do" if nothing new has shown up since I merged.
<fullermd> And otherwise the process goes on until we decide that we're done, then I sneak down to the machineroom and pull out your ethernet cable so that I can be the one that merges it into trunk, adulation, women, etc.
<abadger1999> mwhudson: I have good news and bad news.
<fullermd> But wait; that's a little annoying, us having to merge back and forth.
<mwhudson> abadger1999: tell me the good news now and the bad news tomorrow? :)
<thumper> lifeless: sorry, fixed the problem anyway
<fullermd> And if there were *3* of us working on it, it would be even worse; we'd have more complicated merging to do.  It can work just fine of course, but it's more mental overhead to keep track of what's going on.
<abadger1999> Good news is I'm testing the combined mod_wsgi paste.httpserver stuff and it works for mod_wsgi.
<fullermd> And what about 4 people, or 5, or 50?  Eeek.
<abadger1999> mwhudson: bad news has to do with breadcrumbs :-(
<fullermd> So instead of my branch'ing from your branch, what you do instead is that you push your php5 branch up to the server, so now we have server:/repo/php5 alongside server:/repo/trunk
<mwhudson> abadger1999: argh
<fullermd> Then you convert your branch from being an independent branch, to being a checkout of server:/repo/php5.  And I check it out locally.
<mwhudson> abadger1999: can you file bug reports?  i'm really too fried to think hard about this stuff now :/
<fullermd> Then we both work on it pretty much like we work on trunk; we just commit, and update to get changes from anybody else working on it.  Somebody every once in a while merges trunk and commits it, and we all get that in our update's.
<abadger1999> mwhudson: No problem.
<fullermd> And when it's ready, anybody can update (to be sure they're up to date), then merge it into trunk and steal all our fame.
<abadger1999> mwhudson: If I understood simpleTAL better I'd do a better job of debugging :-(
<fullermd> GPH-Laptop: The thing to notice here is that ALL of these ways are valid, and ALL of them are appropriate in certain cases.  Almost any of these workflows CAN be used at almost any time, but different ones are optimal for different uses.
<GPH-Laptop> right
<GPH-Laptop> but, by spelling it out for me, it helps me wrap my head around it
<fullermd> GPH-Laptop: The second thing to notice is that just because we START with one workflow (you having a local php5 branch, us both having local copies with sync to each other), doesn't mean we're stuck with that workflow forever.
<fullermd> We can easily decide "Wait, it's too much work us both having independent local branches; let's make a central php5 branch and work there"
<fullermd> And converting over to working that way is very, very easy.
<fullermd> (and going the other way too, from one central branch to 2 independant local ones, would be easy too, if for some reason we wanted to switch)
<fullermd> So just because you're doing a "central" workflow for one bit (trunk), doesn't mean you can't get all funky distributed with other branches.  And just because you're all funky distributed with a branch, doesn't mean you can't easily switch it over to centralized.
<GPH-Laptop> So, if we had the central php5 branch... would our local files be a branch or a checkout?
<fullermd> So you have a lot of freedom to tailor the workflow to the needs of the moment, AND to the needs of given developers.
<fullermd> They COULD be either; I could have my php5 be separate, and treat the central branch like I treated yours, as something to merge from.
<fullermd> Or I could make it a checkout, and work straight-line in it.
<GPH-Laptop> so a branch is pretty much a middle man?
<GPH-Laptop> a local branch, that is
<fullermd> And if I had write access to your ~/site/ somehow, I could checkout YOUR ~/site/php5 too, instead of branch'ing it.
<fullermd> Hm.  I'm not sure I'd phrase it that way.
<GPH-Laptop> alright, nevermind then
<fullermd> A branch is the thing you work on, via a checkout.
<GPH-Laptop> now, if you did check out my stuff, too, could you still merge the two?
<GPH-Laptop> two checkouts
<fullermd> (which checkout COULD just be colocated with the branch, in simple cases)
<fullermd> Well, technically, you merge branches, not checkouts.  But you do all the work in a checkout.
<fullermd> Let's take the case where there's trunk and php5 on the server, and I've checked out both.
<fullermd> When I cd ~/site/trunk ; bzr merge ../php5
<fullermd> What I'm DOING is actually merging the php5 branch into the trunk branch, and preparing the merge to be committed.
<fullermd> Of course, I just refer to my checkout, not to the actual branch.  But bzr just uses the checkout to find the branch to get the revs to merge (which come from the repository)
<fullermd> So it sorta steps down through all 3 pieces to get what it needs.
<GPH-Laptop> so... commit is 2 steps in a branch, 1 step in a checkout, and merge is 1 step in a branch and 2 steps in a checkout?
<GPH-Laptop> relative to the central repositor
<GPH-Laptop> y
<GPH-Laptop> or branch
<GPH-Laptop> or whatever
<GPH-Laptop> the central server
<fullermd> Mmm.  I'm not sure that phrasing means much...
<fullermd> When you commit, the process goes something like:
<fullermd> 1) Get the current state of everything from the checkout
<fullermd> 2) Get the previous revision (which is at the moment the latest) from the branch (slight lie, but close enough)
<fullermd> 3) Create a new revision, with that previous one as its parent, containing the new files (stored as a set of diffs for compression, but conceptually a snapshot of the whole tree)
<fullermd> 4) Stuff that revision in the repository (wherever that might be for this particular case)
<fullermd> 5) Update the branch to tell it "Your head revision is now <newrev>"
<fullermd> (this glosses over details, and skips some others, but it's close enough for understanding)
<fullermd> Merge works somewhat crossing levels.
<fullermd> On one level, it's just as if you'd made changes to the files manually; it just does it for you.
<fullermd> But on another level, it queues up the revisions you're trying to merge, so they become part of the history.
<fullermd> On a normal commit, the revision you create has one "parent"; it's the revision you start from.
<fullermd> On a merge, though, the revision has TWO parents; the first is as above; the one you started working from in your checkout.
<fullermd> The second, though, is the head of the revisions you merged.  That's what makes merges special; it points back along BOTH lines of development.
<GPH-Laptop> hmm... OK
<GPH-Laptop> I think I understand those concepts enough
<fullermd> That's why, after you've merge php5 into trunk, you don't need php5 anymore; trunk has all those revisions pointed to.
<GPH-Laptop> right
<GPH-Laptop> now what about implementation?
<GPH-Laptop> where do I have to install Bazaar?
<fullermd> And it's also what makes the merge tracking work right; bzr knows which revs are already merged, because it can see them in the history.
<fullermd> Where in terms of where on a machine, or where in terms of on what machines?
<GPH-Laptop> on what machines
<vila> hi all
<fullermd> Well, in one sense, you don't _need_ it on the server; bzr can hold a repository on a machine and just access it via sftp or other "dumb" protocols.
<fullermd> But that won't help you checking it out on the live site there of course.  So you need it on the server, practically speaking.
<fullermd> And having it on the server lets you use the smart protocol, like bzr+ssh, which will be more efficient.
<GPH-Laptop> oh, for the automation, yeah
<GPH-Laptop> hmm... ok
<fullermd> And of course, you need bzr (with whatever frontend) on whatever machines developers are working on.
<fullermd> Pretty much the same as asking "Where do I need to have cvs installed".
 * fullermd waves at vila.
<GPH-Laptop> right
<GPH-Laptop> hmm, I suppose
<fullermd> Now, if you want to talk about available GUI frontends, I'm the wrong guy to ask   :)
<GPH-Laptop> Now, let's assume that I can't get it installed on the server right away... that only affects automated syncing with the live site, right?
<fullermd> Well, it means you need to use dumb protocols to access the branches on the server, which can be slower.
<GPH-Laptop> and the protocol used
<GPH-Laptop> which brings me to another question... is it easy to switch from one protocol to another?
<fullermd> And it does mean you'll have to find some way to deploy that doesn't involve having the working files directly on the server.
<fullermd> Oh, yes.  Trivial.
<GPH-Laptop> OK... and it seems like either ssh or sftp will work fine... which is faster?
<fullermd> bzr+ssh is a smart protocol; sftp is the dumb one.
<GPH-Laptop> assume I don't have access to server-side bzr
<fullermd> Well, then sftp is the only choice   :)
<GPH-Laptop> oh, ok
<GPH-Laptop> no standalone ssh?
<lifeless> GPH-Laptop: sftp is standalone ssh
<GPH-Laptop> meh
<fullermd> Well, once you ssh in, what do you do?   :)
<GPH-Laptop> oh... good point
<GPH-Laptop> so what would be the commands I would have to issue to create the repository and trunk branch on the server?
<fullermd> cd /repo ; bzr init-repo . ; bzr init trunk
<GPH-Laptop> I meant assuming I'm issuing them from my local machine
<fullermd> You should be able to bzr init-repo sftp://server/repo/ ; bzr init sftp://server/repo/trunk too, without bzr up there.
<fullermd> Now, you may have (I would suggest) already made a branch locally with the files in it, and you want to turn that into the trunk.
<fullermd> In that case, you'd replace the last step with "cd /where/ever ; bzr push sftp://server/repo/trunk/"
<fullermd> (and then do something like "bzr bind :push" to turn your 'till-now-independant branch into a checkout of the central trunk)
<GPH-Laptop> what if I only have some of the files on my local machine, but the server should have all of them?
<fullermd> Slurp 'em all down and put 'em in the branch.
<GPH-Laptop> before or after all that stuff?
<fullermd> Now, if you have ssh access to the server, and it's already got python and such in place, you could pull down a copy of a bzr tarball and run it out of the source dir until you can get somebody to install it system-wide.
<fullermd> That would let you do more of the stuff on the server and save transferring files back and forth.
<fullermd> Well, before or after.  It'd just have to be before you started considering that trunk authoritative of course.
<GPH-Laptop> right
<GPH-Laptop> well, I guess all my changes are already on the server
<fullermd> I advocate before; get it all working right locally and fiddle with it a bit, then set things up centrally.
<fullermd> The ease of rearranging workflows means that you can bite off a little at a time, and get it digested before trying the next push.
<GPH-Laptop> so would that be init or init-repo to set it up on my machine first?
<fullermd> init to setup a branch.  init-repo would create the shared repo to share storage among multiple branches.
<fullermd> But you can skip the repo for now; can deal with that when you need it.
<GPH-Laptop> so init on my local, download all the files, then init-repo on the serveR?
<fullermd> Mmm.  Let's forget the server for now.  init on your local, download all the files [that you care about]
<fullermd> bzr add to schedule them for addition, and bzr ci to commit them.
<fullermd> Now you've got a branch (with all of 1 revision) setup with the necessary files.
<GPH-Laptop> so this would be ~/site/trunk/
<GPH-Laptop> right?
<fullermd> Then you can bzr init-repo sftp://server/repo/ ; bzr push sftp://server/repo/trunk" at any time now or in the future to create a central trunk.
<fullermd> Right.
<fullermd> You can init-repo in ~/site/ now if you want.  But it doesn't much matter.
<GPH-Laptop> does it matter if I init after I download?
<fullermd> Not really.  init just sets up a bzr branch in the directory you specify (or current dir if you don't)
<GPH-Laptop> ok
<GPH-Laptop> what about whoami and other peripheral stuff?
<fullermd> Well, when you commit, we have to mark who committed.
<fullermd> With CVS, that's easy; we just take the username.
<fullermd> Since there's only one system, a username is unique.
<fullermd> With a distributed system, since commit can conceptually happen on any machine in the universe...   username?  Not so great.
<fullermd> So we have to come up with a committer ID somehow.  whoami is how you set that.
<fullermd> Generally they look like RFC822 addresses.   "Name <em@ai.l>"
<fullermd> If you don't explicitly set it, bzr guesses that your email is `username`@`hostname`, or various other heuristics.
<fullermd> (which is more than likely wrong, so you want to explicitly set it  :)
<GPH-Laptop> right
<GPH-Laptop> how do I set it for this specific repo?
<fullermd> whoami has a --branch option to set it for a specific branch.
<fullermd> You can use patterns in the location.conf file (~/.bazaar/locations.conf on *nix) to set a specific whoami based on the path to where you are at the moment.
<fullermd> I think whoami --branch sets it in the branch's local config, so that's not as great an option if it's a branch that multiple people commit on.
<fullermd> Of course, if it's just on your local machine, that's not a worry.
<GPH-Laptop> well, I've got a global whoami to my regular e-mail address, but I want to set this school repo to my school e-mail address
<GPH-Laptop> but that spans (or will span) multiple branches
<fullermd> You could setup a locations.conf that looks like:
<fullermd> [/home/gph/school]
<fullermd> email = GPH <gph@school>
<fullermd> [/home/gph/play]
<fullermd> email = GPH <gph@play>
<fullermd> And then just have all school-related branches under ~/school/, etc.
<GPH-Laptop> can I use DEFAULT for the latter case?
<fullermd> Well, you could just leave off the second case if gph@play is your default setting.
<GPH-Laptop> ok
<GPH-Laptop> and this goes in ~/.bazaar/locations.conf?
<fullermd> Right.
<GPH-Laptop> ok
<fullermd> It would be a different place on Windows...   I think OS X uses the same as *nix.
<GPH-Laptop> ok
<GPH-Laptop> I'll give it a try
<fullermd> Check "bzr version"; it'll list "Bazaar configuration:" as the directory where that stuff goes.
<GPH-Laptop> yeah, same place
<GPH-Laptop> does it have to be absolute, or can I use ~ in the conf file?
<fullermd> I'm not sure.
<fullermd> I know it supports some globbing, so [/home/gph/*/school] would do what you'd expect.  But I'm not sure if it does ~-expansion.
 * fullermd prods lifeless.
<fullermd> I s'pose I could just try it and find out...
<GPH-Laptop> how do I get it to kick in?
 * fullermd frowns.
<fullermd> OK, it looks like it doesn't.  And it only kicks in when there's actually a bzr branch there.
<fullermd> That sounds like a bug...
 * fullermd files.
<GPH-Laptop> ^_^
<GPH-Laptop> OK, works
<GPH-Laptop> good
<chandlerc> wow, 70mb resident memory doing bzr update??
<chandlerc> 80 now
<chandlerc> is that... normal?
 * GPH-Laptop shudders as he starts to download the entire server
<chandlerc> 124mb...
<GPH-Laptop> alright, I think it's about time for bed
<GPH-Laptop> fullermd: Thank you very much for your help
<GPH-Laptop> You're a regular here, I gather?
<fullermd> Oh, yes.  Any excuse not to get work done...
<GPH-Laptop> What do you think I'm doing? ;)
<fullermd> See?  We're helping each other.  God bless the Internet.
<GPH-Laptop> lol
<GPH-Laptop> I'll be back again to distract you soon enough
<GPH-Laptop> but I need some shut-eye
<fullermd> Well, I guess I should actually get work done anyway.
<GPH-Laptop> as I download the entire website
<GPH-Laptop> geez... it's just going through directories right now... it hasn't even started on the files yet
<GPH-Laptop> I really hope I don't run out of disk space while I sleep
<fullermd> That would bode poorly for using bzr on the files   :p
<GPH-Laptop> lol
<GPH-Laptop> well, I still have to filter out all the junk
<GPH-Laptop> hmm...
<GPH-Laptop> yeah, alright, bed
<GPH-Laptop> gotta stop talking
<Treenaks> Is there a way to get the patch + log at the same time in bzr? (like "git log -p" in git)
<Treenaks> I've figured out something like 'bzr send -r 3..4 -v -o- .', but it's not really intuitive to figure out :)
<luks> there is no equivalent of git log -p
<Treenaks> hm.. so my 'bzr send' hack is really the best approximation?
<luks> I'm not sure what does the -v do
<lifeless> -v shows a status between commits
<chandlerc> jelmer: i figured out what the deal was with the crash -- i stopped working with trunk/tags/branches, and started on a flat svn repo... with trunk/tags/branches, I get the segfault again
<chandlerc> jelmer: but there is nothing in my .bzr.log or in the output to provide a bug report... kinda at a loss
<chandlerc> fun times
<chandlerc> pdb is useless because the whole python interpreter crashes
<fullermd> If you're gonna have tools, they might as well be thorough   :)
<Treenaks> lifeless: is there a reason for not being able to show diffs with log?
<lifeless> Treenaks: not implemented ?
<Treenaks> lifeless: Yeah, ok.. but no 'deeper' reason ("we don't want it", etc.)
<james_w> hey thumper, 'fraid not.
<chandlerc> jelmer: Bug #276219 filed.
<ubottu> Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219
<AfC> Ah the joys of calling native libraries from managed code.
<gmb> Hi.
<gmb> I'm having trouble doing a bzr upgrade --1.6 in a repo.
<gmb> I get the following error:
<gmb> 'bzr: ERROR: Directory not empty:  "/$path-to-repo/.bzr/repository": [Errno 39] Directory  not empty'
<gmb> Does anyone have any idea why I'd get that?
<gmb> (Note that I've subbed in $path-to-repo there; it was a long path ;))
<james_w> cryptic
<gmb> Somewhat, yes :)
<james_w> can you grab a copy of the repo to test with?
<gmb> james_w: I have a backup copy. I'll rsync it to somewhere I can play with it, hang on.
<james_w> cool
<james_w> just don't want to trash your data
<gmb> james_w: Good plan!
 * gmb notes that he should probably clear that repo out more often :/
<gmb> Hurrah
<gmb> james_w: I now have a repo to muck about with.
<james_w> woo!
<james_w> so can you try the upgrade again, but with -Derror this time please?
<james_w> (that's a command line argument if you haven't seen -D before with bzr)
<lifeless> jml:
<lifeless> robertc@lifeless-64:~/source/unittest/testresources$ bzr merge http://bazaar.launchpad.net/~jml/testresources/tests-meaning-cleanup
<lifeless> http://bazaar.launchpad.net/%7Ejml/testresources/tests-meaning-cleanup is permanently redirected to /~jml/testresources/tests-meaning-cleanup/changes
<lifeless> ^ little ugly ?
<jml> yeah, a little.
<jml> but, I'm not sure why it's happening.
<lifeless> also, merged and pushed
<jml> lifeless: thanks :)
<quicksilver> vila: ping?
<vila> quicksilver: pong
<quicksilver> vila: I'm finding DVC is getting pretty slow now we have 800 revisions in our tree :(
<quicksilver> vila: at least, for view revision logs.
<vila> ha, I never do that :-/
<quicksilver> maybe I'm doing things wrong.
<quicksilver> I am the main patch reviewer
<quicksilver> so I update my tree to other people's recent commits
<quicksilver> hit C-x V L and then review their commits one by one
 * vila looking at sources
<vila> hmm, there is a last-n parameter, but I can't find a way to specify it directly
<vila> may be you can just rebind C-x V L to show the last 20 or whatever
 * quicksilver nods
<quicksilver> vila: has there been developmend on dvc recently?
<quicksilver> because I have a fairly old version.
<quicksilver> is there some mailing list it's discussed on.
<quicksilver> ?
<vila> dev continues at almost the same speed, the list is: dvc-dev@gna.org, subscribe at https://mail.gna.org/listinfo/dvc-dev
<vila> it seems they miss the deadline for inclusion in emacs-23 and they now target 24 (or 22/23 :-)
<vila> they made good progress to support other DVCs too, bzr support staying almost stable, generic parts have improved too
<quicksilver> excellent.
<quicksilver> I will join the list! thanks
<vila> quicksilver: you're welcome ;)
<quicksilver> vila: it would help if the log mode could parse incrementally
<quicksilver> (Rather than waiting for the command to terminate)
<quicksilver> but as I understand it, asynchronous stuff is pretty hard in emacs.
<vila> quicksilver: as always, the hard things are the ones you never did :)
<quicksilver> well, worse than that
<quicksilver> the hard things are the ones other people never did for me ;)
<quicksilver> or not yet, anyway.
<vila> hehe
<jam> morning vila
<vila> mornign jam !
<vila> nearly good :)
<vila> morning jam !
<jam> :)
<jelmer> jam, Keep up the good work!
<Stavros> hello
<Stavros> i have a use case i need some help with:
<Stavros> i branch off some code to develop a feature, and push that to production. i need to fix a bug in HEAD, so I do, how can i push that bugfix to production while retaining the branch's changes?
<Tak> make a separate branch of HEAD, fix the bug there, and push it?
<Stavros> well, head does have a branch already
<Stavros> so i just push it? how does it merge the changes?
<Tak> maybe I'm misunderstanding your question
<Stavros> let me explain better
<Stavros> i have head and branch, creating branch A
<Stavros> i merrily make changes to branch a
<Stavros> then i make a change to head and want to merge it into branch a
<Stavros> how do i do that?
<Tak> oh - wouldn't you just pull from head to branch a?
<luks> bzr merge path/to/head
<luks> this will merge all head's changes, which you might not want
<Stavros> aha
<Stavros> is there a way to only merge some?
<nefertum|> is it possible to commit the tags to a remote repository?
<Stavros> nefertum|: yes, just push it
<Stavros> nefertum|: with --overwrite, probably
<luks> Stavros: you can do bzr merge -c X path/to/head, but then you have to commit a new revision
<Stavros> ah
<luks> Stavros: and bzr doesn't know it's the original one
<nefertum|> mmmm, yes Stavros i'm using push without --overwrite...
<luks> usually it's best to have small branches, so that you can merge them in cases like this
<Stavros> well i probably won't need to merge some changes, so the first alternative should work, thanks
<Stavros> nefertum|: yeah, you have to use overwrite because tags aren't versioned
<Stavros> luks: that's what i'll do then, thanks
<luks> http://www.venge.net/mtn-wiki/DaggyFixes if you want some interesting and (maybe) confusing reading :)
<Stavros> oh i've read that, it has some good ideas
<Stavros> i'll read it again to refresh my memory, thanks
<nefertum> i'm trying to do a checkout from a svn repository, i've installed bzr-svn, and i have this error: http://pastebin.ca/1214966
<nefertum> any idea about this?
<nefertum> could anyone explain me what means "branches without working trees" (--no-trees)
<nefertum> :|
<beuno> nefertum, just the repository
<beuno> so you would just have a .bzr directory
<beuno> but no files
<nefertum> beuno: and if i want to add a project or a branch of a project? bzr init ??
<nefertum> and that's all?
<beuno> nefertum, you want to add more files to the branch?
<nefertum> well, really i'm reading the bazaar doc and i didn't understand this...
<nefertum> i'm a newbie with bzt
<nefertum> s/bzt/bzr
<beuno> working tree-less branches are usually so use remotely
<beuno> so you would have a branch with a WT locally
<beuno> and push
<beuno> to the remote branch
<nefertum> aham...
<beuno> which really doesn't need to have all the files laying around
<beuno> locally, you probably want a working tree to actually work on  :)
<nefertum> beuno: so then, i only need a WT in the branches but not in the repository, isnt it?
<beuno> nefertum, are you using a shared repository?
<nefertum> i'd like to have a server with the repository, yes
<nefertum> i should configure in it a repository without WT then
<nefertum> and push branches in it?
<beuno> nefertum, if you push remotely, you don't get a WT
<nefertum> aham...
<nefertum> beuno: if i start the repository in local, to push it later to a remote server, and then have to use WT or not?
<nefertum> i think i'm not understanding this :-P
<Verterok> nefertum: if you push there is not WT involved
<asabil> is it normal that bzr dpush uses 100% cpu
<jelmer> nefertum, hi
<jelmer> nefertum, please try a newer version of bzr-svn
<jelmer> asabil, it's not very heavily optimized
<asabil> I mean uses 100% cpu for about 1 minute and hangs there doing nothing
<asabil> I had to kill it
<jelmer> asabil, how many revisions were you trying to push?
<jelmer> it's got a very high per-revision overhead
<asabil> 1 revision
<jelmer> what version of bzr-svn?
<asabil> 0.4.13
<asabil> the one from the PPA
<jelmer> asabil, have you ever pushed anything to that repository befoer?
<asabil> no
<jelmer> in that case it may just be filling the cache looking for older bzr-svn revisions
<jelmer> that'll be slow the first time you access the repo
<asabil> well, the repo is branched from bzr-mirror
<jelmer> that shouldn't matter
<asabil> hmm ok
<asabil> I am trying again
<asabil> I just don't know what is happening
<nefertum> jelmer: thanks, i'll try
<nefertum> jelmer: i'm using 0.40.10-2 version, from debian unstable...
<nefertum> which one is the last version?
<jelmer> nefertum, 0.4.13
<jelmer> nefertum, experimental has the latest
<nefertum> thanks jelmer !
<nefertum> jelmer: it worked, thanks a lot
<jelmer> nefertum, you're welcome
<asabil> jelmer: is 35 minutes too much ?
<jelmer> asabil, how big is the repository?
<asabil> about 1800 revisions
<asabil> jelmer: is using bzr push faster ?
<jelmer> asabil, it is faster, I'm not sure whether it's significant though
<chandlerc[g]> jelmer: ping
<jelmer> chandlerc[g], pong
<chandlerc[g]> gah, sorry
<chandlerc[g]> stuff keeps distracting me
<chandlerc[g]> 0.4 branch
<chandlerc[g]> and i agree, that it seems like the entire PyArg function failed
<chandlerc[g]> anything i can do to help debug it?
<jelmer> If you can find out what causes PyArg_ParseTuple to return NULL, that would help :-)
<chandlerc[g]> where do i look?
<jelmer> I'm a bit at a loss as to what's happening here
<chandlerc[g]> yea, me too
<chandlerc[g]> weird thing, its happening for multiple different svn repositories
<chandlerc[g]> i'm adding empty directories to the repository, could that do it?
<jelmer> If you can attach a script that reproduces the problem for you with a local svn repo, that would help
<chandlerc[g]> hmm
<chandlerc[g]> dunno
<chandlerc[g]> it's totally blocked my work though
<chandlerc[g]> =]
<chandlerc[g]> so i'm willing to do anything i can to help
<chandlerc[g]> i'll try to set up a local svn when i get home today though
<jelmer> A script that reproduces it would allow me to reproduce the problem locally
<chandlerc[g]> yea
<jelmer> It's hard for me to say anything sensible about it if I can't reproduce it :-/
<chandlerc[g]> i've got it reproduced on two separate remote repositories
<james_w> thumper: hey, can I still be of assistance to you?
<thumper> hi james_w
<thumper> james_w: I've managed to sort out my issues
<thumper> but thanks for asking
<james_w> thumper: coolness
<hsn_> why my bzr log shows 195 revisions and bzr check 201 and 0 unreferenced revisions?
<poolie> hsn_: well, depending on how you're counting, there may be 6 merged-in revisions
<hsn_> poolie: how can i count merged revisions?
<poolie> they're shown indented in the log display
<poolie> there's also a bzr-stats plugin iirc that might be interesting
<hsn_> part of bzrtools?
<jam> poolie: just letting you know I won't make it to the standup tonight, have to watch my son. Though if you want to call my cell phone, I guess I could participate that way
<poolie> hi
<poolie> hsn_: launchpad.net/bzr-stats
<james_w> jml: hey hey
<james_w> jml: would you have a little time for a chat today?
<jml> james_w: yes
<jml> james_w: when's good/
<james_w> jml: great, I'd just like to figure something bzrlib out, and then I'm done for the day, so perhaps 30 minutes?
<jml> james_w: fine by me
<james_w> well, done coding that is
<james_w> jml: great, thanks
<james_w> anyone know how to request a file over a transport where it will be redirected?
<james_w> ah, got it I think
<lifeless> james_w: redirects are exceptions
<lifeless> james_w: so catch it and rerequest
<james_w> lifeless: yeah, there's do_catching_redirections to help. I was requesting the transport of the new location of the file, rather than it's parent dir, so when I did the final .get() it ended up with the filename doubled on the end
<james_w> thanks though
<nefertum> mmm, i'm starting with bazaar and i'd like to have a shared repository in a server and do distributed development with bazaar
<nefertum> i've started a repository in /bazaar with bzr init-repo
<nefertum> i'd like to use the nested style i've read in the user guide
<nefertum> the doubt is...i push a man branch to the server, or many of them, and later can i get all the content of the repo?
<lifeless> nefertum: yes
<nefertum> lifeless: i've created the repo with --no-trees
<nefertum> but i don't understand well the meaning of this...
<lifeless> nefertum: a 'shared repository' is just a DB
#bzr 2008-10-01
<nefertum> lifeless: in a structure like /repo/tom/feature1/ for example, tom is a branch? or only feature1 ?
<nefertum> i need to create tom/ withg 'bzr init tom' ?
<LarstiQ> nefertum: both can be, it's more usual to have only feature1/ be the branch though
<nefertum> LarstiQ: i have the next problem...i have in a machine a repo and in local i've created a new branch that i've just pushed to the server
<nefertum> but now i don't know if i can get all the content of the repository
<nefertum> in the remote server the repo is /bazaar, and i've created the branch /bazaar/main
<nefertum> but if i created /bazaar/feature1 i'd like in the future to get all the repository content in another machine, for example
<LarstiQ> you mean you want to get all the branches instead of specific ones?
<nefertum> yes, all the repo tree
<nefertum> i have to do a checkout?
<LarstiQ> nefertum: no
<LarstiQ> nefertum: maybe I don't really understand what your goal is
<nefertum> like in svn, i can do svn co url/svn/repo/ and this gives me all the repo
<nefertum> i don't know how to do this in bazaar
<AmanicA> fwiw, I think you can just copy it
<LarstiQ> nefertum: in bazaar branches are much more loosely coupled with a repository
<LarstiQ> (than in subversion)
<nefertum> aham..
<LarstiQ> nefertum: but even in svn, there are usually only a couple of branches you care about, and not the rest
<nefertum> yes...that's what i've seen
<Verterok> nefertum: unlike svn, in bzr a repository is just a place to store revisions. you can have standalone branches (without a separate repository)
<nefertum> Verterok: the idea is that i'd like to have a remote server with a repository and i don't know if i should create it first in the remote machine or push the repository from my local repo...
<nefertum> basic things i supose...
<AmanicA> you can just create it on the remote side
<Verterok> nefertum: first, we should clarify what a repository means :)
<nefertum> mmmm, well, in bazaar is also my local branches, but i mean about a server that stores the main branches in a project
<nefertum> so the developers push the changes in it
<Verterok> nefertum: in that case, as AmanicA said, you can create it in the remote side
<nefertum> aham...
<nefertum> ok, but i should create with --no-trees or --trees ?
<Verterok> nefertum: and probably you would have a local repository in you workstation
<lifeless> nefertum: if its on a central server, --no-trees
<AmanicA> I prefer --no-trees on the central server
<nefertum> yes, actually i have a local repo
<nefertum> ok, so i can create an empty repo with --no-trees an later push my branches in it?
<lifeless> nefertum: if its on your workstation, and you want to edit your code inside the repo (rather than doing a checkout), --trees
<Verterok> nefertum: yeap
<nefertum> i'll try...
<mwhudson> i find myself wanting to do cd :this
<AmanicA> will `bzr cd :this` work ? :)
<LarstiQ> markh: I recently got a very cryptic bzr-svn message on windows, is there a list somewhere (I looked at http://bazaar-vcs.org/WindowsDownloads and regular Downloads) that mentions what components go into a specific installer release?
<markh> LarstiQ: not really :(  There is a wiki that describes the parts needed, but the version numbers are often stale - eg, bzr-svn is now using svn-1.5.x rather than 1.4.x.
<LarstiQ> markh: that's exactly what I ran into btw, a "upgrade your Subversion client" message
<markh> LarstiQ: that wiki page is http://bazaar-vcs.org/WindowsInstall
<LarstiQ> markh: thanks!
<markh> I've seen that error on my local svn repos lately too (ie, without bzr-svn)
<LarstiQ> markh: so the installer has it's own subversion library?
<markh> yeah
<LarstiQ> aaah, ok
<LarstiQ> markh: the problem was that I had a svn 1.5 working copy
<markh> LarstiQ: you using 1.7 binaries?
<markh> or 1.6?
<LarstiQ> markh: and then tried to bzr diff on that, but I guess it must have been with 1.4
<LarstiQ> markh: 1.5
<markh> 1.6 was built with 1.4
<markh> right!
<markh> 1,7 is built with later libs
 * LarstiQ nods
<LarstiQ> that should fix it in this case then
<markh> IIUC, 1.5 used the "pysvn" bindings - now bzr-svn uses its own bindings
<LarstiQ> markh: Would it be possible to detect if TortoiseSvn is installed and use those libraries?
<LarstiQ> markh: right, but it steel needs an svn library to talk to?
<LarstiQ> still even
<markh> it would be a bit of a qa nightmare.  But for 1.7 etc, we should be using the latest available anyway...
<markh> yeah - but what svn library was used was outside the control of bzr-svn - it just relied on whatever pysvn uses.  Now things are directly under bzr-svn's control
<markh> it bundles the full svn runtim
<LarstiQ> ah ok, so less problems there
<LarstiQ> markh: the main thing to do I guess is to catch that message thrown by svn and display something that makes more sense to the user
<LarstiQ> markh: since upgrading Tortoise makes the problem of incompatible working copies worse :)
<markh> LarstiQ: but IIUC, only old bzr clients will display that message, and its too late to fix them?
 * LarstiQ will file a bug/patch for that tomorrow
<LarstiQ> markh: I'll test it
<LarstiQ> markh: for svn 1.5, yes. But if I use svn trunk I think I'd get the same message
<markh> IIUC, the problem is the old version of bzr you have uses old versions of svn libs?  And newer TSVN and bzr versions use a later version?
<LarstiQ> markh: correct
<markh> LarstiQ: right - so you want to upgrade just the bzr-svn for your old bzr binary?
<markh> I mean, your old 'svn.exe' copies will no longer work either.  All the other tools need an upgrade to work - same with bzr
<LarstiQ> markh: for my concrete problem, I'll just install bzr 1.7
<markh> (fyi, 1.6 uses old svn too - only 1.7 has svn 1.5)
<LarstiQ> markh: but when the next svn release comes out and is incompatible, there is a window for confusing errors until we can say "use the latest bzr installer, that will work"
<LarstiQ> markh: ok
<LarstiQ> markh: so I'd like to nail that confusing message before the next incompatible svn release comes out
<markh> right.
<lifeless> what-da-fark ?
<lifeless> bzr: ERROR: No module named chkmap
<lifeless> You may need to install this Python library separately.
<mneptok> lifeless: that dependency issue has caused a lot of failed marriages when it crops up while driving
<poolie> hhe
<poolie> heh*
<poolie> spiv, are your around?
<poolie> you*
<poolie> typo city
<mneptok> oh, is that where we're going? i'm pretty sure it's the next left. no need to get the map out ...
 * mneptok accelerates and turns up the radio
<spiv> poolie: yeah
<poolie> would my comment at the end of https://bugs.edge.launchpad.net/bzr/+bug/260335 be allright?
<ubottu> Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid]
<spiv> poolie: that seems ok.  We certainly don't want to advise downgrading :)
<poolie> out to lunch, biab
<jml> I'm pushing a new revision up to a stacked branch and getting a "Revision {...} not present" error.
<jml> I had just created that branch, did a local commit, and then pushed again.
<fullermd> board 1
 * fullermd twitches.
<jml> I get the same thing even if I don't commit :(
<jml> oh, branchformat6...
<mwhudson> i guess someone should file a report for that bug :(
<leo2007> after upgrading to bzr 1.7, I won't be able to push to a remote ssh repository anymore. Any ideas?
<lifeless> leo2007: why won't you be able to?
<leo2007> lifeless: I've just posted the error here: http://pastebin.com/d7f25357c
<spiv> markh: see leo2007's traceback
<markh> thats a new one :)
<markh> leo2007: do you use putty or ssh?
<lifeless> leo2007: your use of the future tense was quite confusing :)
<leo2007> markh: sorry for my English. I used to be able to push to remote server with version 1.5. But couldn't. I use putty.
<markh> leo2007: Try setting BZR_SSH=plink and trying again
<markh> ie, at the cmd-prompt
<markh> set BZR_SSH=plink<enter>
<markh> and try again
<leo2007> markh: same error
<markh> hrm - is plink.exe on your path?  The traceback shouldn't reference paramiko if putty's plink is being used (I think :)
<lifeless> markh: paramiko provides our sfp:// implementation, FWIW
<markh> lifeless: right - sftp:// urls?  But ssh+... ones use ssh/putty?
<markh> hrm
 * markh thinks he is confused...
<markh> putty/ssh only used for auth, not for "remote file-system" work?
<markh> The windows error message for that error code is the (not very helpful) "'Key not valid for use in specified state."
<markh> oh
<markh> I've seen this error before :(
<leo2007> The new error is here: http://pastebin.com/d5fe02026
<lifeless> markh: if you use bzr+ssh then paramiko shouldn't be needed; but if you use sftp then paramiko gives use the parsing logic, still use putty or whatever for the transport
<leo2007> plink is in my path
<lifeless> poolie: ping
<lifeless> poolie: I need to decide where to put some tests; you've moved the pack repository specific tests out of test_repository, but these tests I am writing are not really pack specific
<lifeless> poolie: rather they are the actual format I'm working on specific
<lifeless> I would have previously put them in test_repository, I'm just not sure why the pack ones got moved out, I'm confused and wondering if I should be doing the same
<spiv> markh: I vaguely recall a thread or two on the paramiko list about random number sources, perhaps that's related?
<markh> ah yes, its all coming back to me now :) Its a bug I reported in pycrypto a while back
<markh> hrmph - the bug was #1343753 at sourceforge, but apparently the project is now managed at launchpad - and there are 20 bugs in total ever reported.  It is as if the bugs didn't migrate.
<markh> so I can't work out the status of the bug in that package at the moment :(
<markh> a copy of the sourceforge bug message is at http://osdir.com/ml/python.cryptography.cvs/2005-11/msg00000.html
<leo2007> so what's the solution?
<markh> good question :(  Use the version you were in the past for now I guess...
<markh> the bug still exists in pycrypto best I can tell.  I guess I better open a new bug.
<leo2007> where to get older versions?
<spiv> leo2007: https://edge.launchpad.net/bzr/+download
<spiv> (Or just https://launchpad.net/bzr/+download)
<lifeless> spiv: of pycrypto ? :P
<poolie> lifeless: (back)
<spiv> lifeless: I thought it was bundled in the win32 installer?
<poolie> re test_repository: as i recall, test_repository was just getting too big
<poolie> and, i think having one file or module per scope of parameterization is probably something good to aim for
<markh> leo2007: I might be able to get a fix in an hour or so - will you be around?  The error doesn't happen everywhere, so having someone to repro it is important...
<lifeless> poolie:  on the former, mmm, possibly. On the latter, I disagree
<lifeless> poolie: because, it makes choosing to parameterise a heavier task than it should be
<leo2007> markh: I'll be around and happy to test
<poolie> it's (just) over a thousand lines, that's the point where i start wondering if it can easily be split
<poolie> do you mean that if parameterizing means adding a new file it'll make people not do it?
<lifeless> poolie: yes
<lifeless> poolie: jam has complained about the cost already, comparing it to mixins
<leo2007> I am restarting my computer.
<lifeless> poolie: not to mention that we have lots of examples of parameterisation within a single module already
<poolie> so, my thinking was basically "hm this is getting big; oh, these tests are somewhat logically separate so i'll hive them off"
<poolie> this is not to say they must always be that way
<poolie> as i see it the cost is in understanding how to set it up - like that 20-25 line function we looked at yesterday
<markh> so a recent bug on pycrypto's launchpad page has just been marked "fix committed" - but the points points at some *git* repository!
<markh> there are 4 bzr branches on launchpad, but none are marked as "trunk" nor owned by the project itself.  I'm really not sure *where* the trunk is!
<spiv> markh: the homepage linked from launchpad.net/pycrypto does list a git branch, so I guess that is the current trunk.
<markh> right - so the "problem" seems to be a new maintainer.  The most recent version looks like it came from amk's launchpad branch
<vila> hi all
<spiv> vila: good afternoon
<markh> leo2007: grab http://starship.python.net/crew/mhammond/Crypto.Util.winrandom.pyd and replace the existing copy of that file in the bzr directory with the new copy (take a copy of the old one first though!)
<chandlerc> jelmer: i have a self-contained local reproduction now.
<spiv> vila: thanks for that review
<chandlerc> jelmer: this is the weirdest crash i've seen in a long time
<markh> leo2007: any joy?
<vila> spiv: thanks for yours :)
<chandlerc> anyone want to try and reproduce bug #276219 with the tarball i posted?
<ubottu> Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219
<chandlerc> just wanna make sure i've done enough for others to reproduce, and it reproduces it on my machine, but that's hardly a good sample
<leo2007> markh: I will test it in a minute.
<leo2007> markh: need to reinstall version 1.u
<leo2007> s/1.u/1.7/
<poolie> spiv/lifeless: re your comment on bug 260335 - we're still issuing this error about Repository.get_parent_map in 1.8pre
<ubottu> Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid] https://launchpad.net/bugs/260335
<poolie> jml, are you still here?
<jml> poolie: yes.
<spiv> poolie: you mean when the client is 1.8pre?  What version is the server?
<poolie> so jml said that error still occurs if you use 1.5 against a 1.6 server
<poolie> the error seems to be issued from inside get_parent_map
<poolie> did we really remove that, and if so why is the client still trying to call it?
<poolie> and, kind of related to that, the conclusion the client draws if its unsupported is that the server is older than 1.2
<poolie> so if what was said in that bug is correct, maybe the other code is wrong?
<AfC> Any idea why the signature tab of bzr-gtk's visualize would say "Revision committer is not the same as the signer." for all the revisions for which I just did `sign-my-commits`?
<spiv> I'm confused.  The error in that bug will be emitted by 1.5 against a 1.6 server because the streaming pull verb (Repository.stream_revision_chunked) was removed as fallout of the versionedfiles work.
<spiv> I don't see anything in that bug talking about get_parent_map or get_revision_graph?
<poolie> ok i might just be confused...
<lifeless> poolie: the guy that filed it is running 1.5
<lifeless> poolie: he says 'i want to run whats in debian stable' or something like that
<lifeless> in other news, I've written a dumb CHKMap
<lifeless> and am fixing repository so it can work with a CHKMapInventory
<jml> poolie: was here something you wanted in particular?
<poolie> jml, i was just going to ask you about your comment on that bug
<spiv> AfC: maybe it's verifying that the committer ID (i.e. the 'bzr whoami' of the committer) matches an ID on the GPG key that signed it?
<poolie> but it's fine
 * spiv -> yoga
<jml> ok :)
<AfC> spiv: not sure. Have a happy downwards dog.
<poolie> afc, that would be my guess too that it's used the wrong userid
<poolie> does it show which one did sign it?
<AfC> poolie: yeah, it does
<AfC> poolie: and it notes that that one is ultimately trusted
<poolie> but is it the same as the committer userid?
<AfC> um
<AfC> huh?
<AfC> I'm not really sure what you're asking. I issued `bzr sign-my-commits` and it chugged away for a while.
<poolie> so
<poolie> you said that bzr-gtk complains that "revision committer is not the same as the signer"
<poolie> and i'm wondering if they are actually different, or if it's just misunderstanding them
<AfC> poolie: that's what it's saying
<poolie> and if they are different, in what way they're wrong
<AfC> poolie: I'd assume so
<poolie> but does it show you which key was used to sign it?
<AfC> Yes its does.
<AfC> I mean, it could only have identified what key to use to sign what commits if sign-my-commits made the correlation. So is bzr-gtk not using the same logic maybe?
<poolie> that's what i'm wondering
<AfC> Yes its does -> mine
<AfC> [This is in the category of "I'd file a bug if I knew I wasn't doing something wrong and if I knew what to report"]
<poolie> could it be that your gpg key does not have a uid for precisely the same address that was used to make the commits?
<AfC> Hm.
<AfC> Yes, I guess that's the case.
<AfC> bzr whoami : Andrew Cowie <andrew@operationaldynamics.com>
<AfC> gpg --fingerprint ... : uid Andrew Frederick Cowie <andrew@operationaldynamics.com>
<AfC> So, like, the fact that `sign-my-commits` figured out what key to use is sorta damning as far as `visualize` is concerned, right?
<poolie> well, they should be consistent with each other
<AfC> Or, put the other way, how on earth did `sign-my-commits` know what to use if it is going to be so pedantic as to try and match the stuff outside the email address?
<AfC> yeah
<poolie> i'd be inclined to say that sign-my-commits should complain if there's no key that corresponds to your committer address
<lifeless> AfC: gpg has a default key for signing
<AfC> Well, it's too late now. The testaments are made, and I'm sure not about to change my key.
<AfC> lifeless: ah, yes, I have that set.
<AfC> poolie: (though I point out that there IS a key that corresponds to my committer _email_ address. I had assumed that was what it looked up until Robert pointed out that maybe gpg did the default thing)
<luks> AfC: well, it shouldn't sign somebody else's revisions with your key
<AfC> I would hope not :)
<luks> and as far as gpg is concerned, the uid was different so technically it's somebody else
 * luks would report a bug against bzr sign-my-commits
<AfC> {shrug}
 * AfC hopes sign-my-commits keeps doing what it's doing, actually.
<AfC> otherwise I won't be able to use it anymore.
<luks> you can have multiple uids on your key, can't you?
<poolie> so, there is a separate key (not uid) that it's used instead?
<AfC> luks: I've worked hard not to pollute my key. I'll keep it that way, thanks.
<luks> ok
<AfC> poolie: no, I only have one uid on one key.
<AfC> poolie: the email address of the uid matches `whoami`
<AfC> Huh. My key is back into the top 100. How about that. Can't say as I've been doing _that_ many signings lately. I guess a bunch of keys must have expired.
<poolie> afc, and it's the same uid as on the revisions?
<AfC> poolie: `bzr vis` reports key 57F6E7BD was used to sign the revisions. That is indeed me. Judging by what flew by when I ran `bzr sign-my-commits`, I'd say that my key was in fact used to sign, correlating what visualize is saying.
<AfC> poolie: The only crink in the works is that something is not recognizing that 57F6E7BD is me (or, more to the point, the same person as "Andrew Cowie <andrew@operationaldynamics.com>")
<poolie> ok, so it seems like there's a bug in bzr-gtk displaying that warning when in fact the key does correspond to the author
<sabdfl> when bzr tries to delete a directory during a merge or pull, it baulks if the directory is not empty
<sabdfl> does it factor in whether or not the files in question are "ignored"?
<poolie> sabdfl: i think so; if not that would be a bug
<poolie> hi btw
<sabdfl> howdy!
<arnarl> hi, we have a branch where a binary directory (about 30M) has been checked in (a while back) which makes the whole thing much larger than it needs to be. Is there any surgery I can do that drops this directory from the history and the branch?
<arnarl> (it is not a public branch)
<poolie> arnarl: you can use launchpad.net/bzr-rebase to make a new history in which "that never happened"
<poolie> but carrying across your later commits
<poolie> you'll have to get everyone to restart their work based on that branch
<arnarl> poolis: sounds great
<arnarl> what do you mean by restart?
<arnarl> check it out again?
<poolie> yes,
<arnarl> ah, that shouldn't be a problem
<arnarl> poolie: thnx
<lllama> Hello all. I'm trying to "bzr init" in an existing directory and I'm getting an error saying "No repository present". Any idea what I'm doing wrong?
<poolie> lllama: what does 'bzr info' show there?
<AfC> lllama: what version of Bazaar are you running?
<lllama> poolie: Same error
<lllama> AfC: 1.6.1
<AfC> lllama: that's certainly reasonably recent.
<poolie> is there a traceback?
<AfC> lllama: is there a .bzr directory in any parent directory above where you are trying to `bzr init`
<AfC> lllama: ?
<lllama> poolie: Nope. Just a "bzr: ERROR" line.
<lllama> AfC: checking....
<lllama> AfC: Ah. There is. There shouldn't be though.
<lllama> If I do a bzr st in the parent then I get told it's not a branch.
<lllama> same with info.
<lllama> I'll try moving the .bzr dir out of the parent and see what breaks...
<lllama> Hm. Same error. I think I'll try a big clean out.
<poolie> lllama: if pain persists can you look in ~/.bzr.log, see if there's a traceback at the end, and put it in answers.launchpad.net/bzr
<leo2007> markh: sorry I won't be able to test the new BZR.
<lllama> poolie: will do. Thanks for the help.
<zrg_needsjob> Folks, i got bzr-synchronized dev and live setups of php app.  Problem is, there are certain parts of few configuration files that have to differ on those installations, but leaving those files entirely out is not a good solution.  I was wondering if there was way to mark part of file to be "ignored" by bzr, or how is such situation best handled?
<james_w> zrg_needsjob: that's not possible
<james_w> zrg_needsjob: the usual ways are to have a .local file which is included in to the main one, if possible with the format
<james_w> zrg_needsjob: or have a .template which is copied and customised in each branch
<zrg_needsjob> james_w: including unfortunately not possible but would be good solution, what do you mean by template?
<bob2> zrg_needsjob: can you just merge only one way?
<james_w> zrg_needsjob: the same file basically, but with blanks for the passwords or whatever. When you make a new branch you copy the file and make any changes necessary. It's a pain to update the common bits then though
<zrg_needsjob> bob_2: there are occasional changes in live setup too that have to be backported and actually now i have 2 dev setups.  they all use same remote repository, so commits and updates go whichever way.
<zrg_needsjob> ignore blocks would be cool feature tho i think :)
<uws> does trac-bzr work with trac 0.11?
<thrope> is it possible to get colored difs with bzr?
<Odd_Bloke> thrope: Yes, look at the cdiff command in bzrtools.
<thrope> Odd_Bloke: great - had it installed just didnt know the command, thanks
<nosklo> hi people
<nosklo> when using bzr-svn, how does one specify the username to authenticate?
<LarstiQ> nosklo: http://user@host/svn/... is one way
<trotek> LarstiQ: is there another? :)
<LarstiQ> trotek: yes, but it depends on what you are trying to do
<nosklo> when I do it. It segfaults :(
<nosklo> bzr-svn just segfaults, no traceback. http://dpaste.com/81664/
<jelmer> nosklo, what version of bzr-svn?
<nosklo> jelmer, bzr 1.3.1, bzr-svn 0.4.9
<nosklo> jelmer, ubuntu default
<jelmer> nosklo, 0.4.13 should work better
<nosklo> jelmer, okay. updating.
<awilkins> Heh, mercurial still can't cut it for my use case
<awilkins> It still goes "boink" on long paths with lots of caps in them
<fullermd> They're getting way ahead of us.  bzr still doesn't even have a prototype "boink" feature   :|
<luks> I'll try to make a plugin
<awilkins> I think I'd prefer "boink" to be written in Erlang, not Python
<awilkins> That way you can work on other implementations of "boink" and replace them at runtime without interfering with other instances
<awilkins> Although doesn't stackless Python achieve that also?
<Odd_Bloke> Quick, let's rewrite bzr in Erlang.
<fullermd> True.  We could be the only VCS on the planet that supports massively-parallel boinking.
<Odd_Bloke> Only then can it be truly distributed version control.
<jam> sabdfl, poolie: We don not factor in if the files are ignored. We don't know if they are ignored because they are private (your secret passwords) or because they are junk (your .pyc cruft)
<jam> so when we delete a directory, it must be fully empty
<LeoNerd> "boink" ?
<jam> it is an open bug that we want to solve
<jam> I think we were talking about putting things in a "lost+found" or something like that
 * fullermd contemplates being left in a darkened room with `log -v` and a blunt object.
<fullermd> Gaah.  Stupid inability-to-refer-to-historical-files bug!
 * fullermd stabbies.
<Pieter> fix it
<davidmac> I have had many clients that have asked the following question with many vcs's, any idea how to do with bzr?  Q: How do I export *only* the files changed since the last revision or a specific revision?
<davidmac> The idea is they only want to push the smallest set of changes when version production-type deployments.
<LarstiQ> davidmac: use bzr-upload?
<fullermd> You could wrap a little scripting around 'stat' to do it, I s'pose.
<fullermd> Or just use bzr diff | patch
<fullermd> Or what LarstiQ said.  Depends on just what's involved in the deployment.
<davidmac> hmmm.  I'll check into that.  I don't think diff is the answer they want.  I'll explain deployment...
<davidmac> Just an example:  They version production which has a lot of binaries: executables, images, etc. on linux and it is very large to do a full export from stage to prode.  They only want to export the changed binaries so they can zip them up and send them from stage.
<davidmac> I'm new to bzr so I'll check in to bzr-upload and stat.
<LarstiQ> 'zip them up and send them from staging', is there some difficulty in getting something to production?
<davidmac> Yes, in many cases.  This specific client has that case.  They are in a hosting environment where they can make changes in dev and stage, but have to provide a tgz file when pushing to prod.
<fullermd> How does that handle deletions or moves?
<davidmac> Ops team doesn't want them sending the entire 2 gig file every time, just the changes files.
<davidmac> It doesn't handle deletions and moves, pretty problematic as I see it.  I'm encouraging them to use bzr in production too to export a tagged build.
<davidmac> I was thinking as a temporary workaround, since they have control of stage, they could just do a find -mtime type of approach to create a zip.
<fullermd> Anyway, wrapping some scripting around 'stat' to figure out what to export is probably the easiest way to work up a tarball.  Still won't do well at moves, or at all at deletions.  Dunno how you could do that easily.  shar, maybe.
<davidmac> thx
<fullermd> You can use bzr stat -rx..y to see what files were touched between those revs, and go from there.
<davidmac> very kewl fullermd, I'll check that out
<davidmac> One more piece of advice I need, then I'll leave you guys alone :)
<fullermd> (for scriptability, especially see stat -S)
<davidmac> This is the logical description of what they want to do:  They have a program.cfg config file for dev, same name but different contents for dev, also for prod.  How would you recommend they do an export and get only the correct config file in each environment?
<davidmac> They have done this with clearcase filters before.
<fullermd> Well, I do similar things by having a dev.conf and a live.conf under version control, and just choose which is applied in each case by a symlink.  Whether that's an option in your environment...
<davidmac> k, anything is an option at this point, just looking for inputs in case there is some elegant semi-automatic way to do it in bzr.
<fullermd> Not really.  What's versioned is what's versioned.  You could have the contents of the files be different in different branches, but that would take careful manual maintenance merging between them.
<fullermd> I find it easier to just have the separate files, and have the program load a "conf.conf" or something that's a symlink to one or the other.
<fullermd> (it also means I can craft up custom conf.conf files for certain places to have different settings, without having to worry about them being local changes not to commit)
<davidmac> Okay, thanks.  And thanks for all your help.  I like what I've seen so far of bzr, so much that I'll probably start hacking some plugins or scripts myself, and maybe a ulipad integration :)
<davidmac> y'all have a good one!
<Verterok> Âº
<Verterok> ups
<thrope> hi - I am using bzr-svn in what I think it the recommended way - I have a checkout of my svn trunk, which I branch to do work, then merge updates, then merge into my bazaar checkout and commit to svn
<thrope> this is working great - it is really nice to be able to work with subversion in this way
<thrope> but I loose all the information about the commits in the branch - in subversion I just see the merge commit
<Odd_Bloke> thrope: Check out the 'rebase' plugin.
<thrope> I wondered if there is a better way of working - or perhaps a bazaar plugin to automatically propograte the commit message with some infromation about the seperate commits.
<thrope> Odd_Bloke: I have the rebase plugin - but I must admit I have some trouble understanding what it does
<thrope> Odd_Bloke: do you mean I should rebase my trunk bzr checkout before comitting
<Odd_Bloke> thrope: I'm not entirely sure myself, I don't use it.  But you should 'rebase' your branch onto the trunk.
<thrope> no - you mean rebase my branch to the trunk checkout before merging (then I could push in theory) back and committing to svn
<Odd_Bloke> thrope: Yes.
<Odd_Bloke> That essentially throws away the commits in your branch and creates new, similar ones based on a different revision.
<thrope> right I think I get it
<Odd_Bloke> Which is fine, so long as you haven't branched from the commits that are being thrown away.
<thrope> I didn't want that initially because it's nice to have the branch structure in my bzr trunk, but I loose it in svn. If I do the rebase, I have all the commits in svn (and my bzr trunk) but I loose the branch structure in my trunk
<Odd_Bloke> thrope: Why are you using SVN?
<Odd_Bloke> You could perhaps push your branches to SVN branches...
<Odd_Bloke> jelmer will know better.
<thrope> partly habit, got all my stuff in there at the moment, partly because it's easier to work with other people and has nice things like viewvcs
<Odd_Bloke> thrope: For the latter, have you seen Loggerhead?
<thrope> also I didn't quite figure out how to have a central bazaar repo that works like svn - I work on a lot of different machines and use svn to keep them in sync
<LarstiQ> thrope: bzr-snv will set the meta data so at least the bzr revisions will be known, even if you only see the merge commit in svn
<thrope> ok
<jelmer> you can set push-merged-revisions in newer versions of bzr-svn
<Odd_Bloke> LarstiQ: But the bzr revisions won't be pulled into a new branch, you'll get ghosts, right?
<jelmer> and it'll push the merged revisions as well, not just the mainline
<Odd_Bloke> jelmer: So, to answer my own question, 'no'?
<LarstiQ> Odd_Bloke: right, but you could distribute your bzr branch for other bzr users to pull from, or apparently set push-merged-revisions ;)
<thrope> Odd_Bloke: I had a look at loggerhead and will try and install it - but it wasn't clear to me how to run a centralised bzr branch on a remote server... If I understand to update I need to merge 'into' that central branch to maintain the mainline - which would require logging onto the server... I couldn't see anyway to push a merge and resolve conflicts remotely
<Odd_Bloke> thrope: The way to do it is to keep a pristine copy of the branch locally.
<Odd_Bloke> So you merge into the pristine copy and push from there.
<Odd_Bloke> thrope: If you've been doing that and it hasn't been working, something's going wrong somewhere along the line.
<thrope> Odd_Bloke: no I haven't really tried because everythings in svn at the moment anyway... I will have a look though
<thrope> jelmer: where do I set push-merged-revisions?
<jelmer> thrope, in ~/.bazaar/subversion.conf for the relevant repository
<thrope> ok thanks
<jelmer> thrope: s/push-merged-revisions/push_merged_revisions/
<alejandro_> hey, I have a question about the eclipse plugin
<Verterok> alejandro_: shoot :) (I'll try to answer)
<alejandro_> I just installed the plugin using the update site
<Verterok> alejandro_: ok, did you installed the bzr-xmloutput plugin?
<alejandro_> and in the preference/configuration dialog I get "invalid command 'xmlversion'"
<alejandro_> yes
<alejandro_> 0.8
<Verterok> alejandro_: which OS? windows?
<alejandro_> ubuntu
<Verterok> alejandro_: from a terminal, try: bzr -Derror xmlversion
<Verterok> alejandro_: it seems that the xmloutput plugin is not correctly installed
<alejandro_> I just dropped it at $HOME/.bazaar/plugins and ran setup.py build_ext -i
<alejandro_> should that produce any output?
<Verterok> alejandro_: the plugin must be installed as xmloutput, not bzr-xmloutput
<Verterok> bzr-xmloutput is an invalid name for a python module
<alejandro_> oh, that could be
<Verterok> alejandro_: also the setup.py step is not neccesary :). it's a pure python plugin
<alejandro_> great, it works now. Thanks a lot
<thrope> jelmer: is there anywhere I can find info on the format of subversion.conf - how to specify repositories etc.
<Verterok> alejandro_: np
<aantn> hello
<aantn> is it possible to set bzr to automatically ignore certain files with bzr add?
<LarstiQ> aantn: bzr add will ignore files that match patterns, see `bzr ignore`
<aantn> LarstiQ: I know
<aantn> I'd like to set it to always ignore two or three files of my choice
<LarstiQ> aantn: ok, then I don't understand your question?
<LarstiQ> aantn: ah, globally, and not on a per branch basis?
<aantn> LarstiQ: no, just per branch
 * LarstiQ swings back to not understanding the question
<aantn> LarstiQ: sorry, never mind
<aantn> LarstiQ: I misread your initial answer. Thanks :)
<LarstiQ> aantn: ah, ok :)
<thrope> I had to leave earlier - does anyone know where I can get some info on the format of the subversion.conf file for bzr-svn?
<sharms> If I did a bzr co on a remote branch, how can I make that checkout be the master instead?
<justizin> hi folks, i downloaded the bzr 1.7 installer for leopard, but the only bzr i can find is in /usr/local/bin, from macports..
<LarstiQ> justizin: are you sure it's from macports?
<LarstiQ> justizin: as that is also the location the .dmg uses afaik
<LarstiQ> sharms: `bzr unbind` will make the checkout into a regular branch. Do you also want to switch the remote branch to be a checkout of your local one? In that case, do a `bzr bind path/to/new/master`
<sharms> thanks!
<thrope> justizin: macports normally uses /opt/local
<justizin> LarstiQ: FYI, its' an FHS violation.
<justizin> i have something in /usr/local, but yah, it's probably overwritten without consent. ;)
<LarstiQ> justizin: FHS, on OSX?
<justizin> FHS is not Linux, it's UNIX
<justizin> if you use OSX's installer facilities, it's like using rpm, which counts as "vendor installed", and goes in /usr
<LarstiQ> justizin: All I know is that the .dmg switched from /usr/bin to /usr/local/bin
<justizin> right on, good to know, it's a pain in the ass because it's not on path, and yes, whether anyone cares, it's an FHS violation
 * justizin memorized the FHS in high school
<LarstiQ> justizin: you'll have to take it up with someone who actually knows anything about it to know why though
<justizin> thanks for the heads up
<justizin> yeh
<justizin> they wont want to hear it
 * justizin symlinks
<justizin> :)
<LarstiQ> ookay
<Keltia> uh, FHS is not really a UNIX thing, it started as a pure linux thingy and some people tried to extend it to others but it has never really taken off outside linux
 * Keltia goes back to lurk mode
<Odd_Bloke> Yeah, but people who use free software on the Macs feel they have to make up their inferiority somehow. ;)
<Keltia> Odd_Bloke: I'm one of them :)
<Odd_Bloke> Keltia: :D
<komputes> If I see a file that is part of a bzr branch, is there a simple way that I can track down who added that specific file?
<fullermd> log it and keep scrolling back?
<fullermd> (or log --forward it and don't scroll, of course)
<Peng_> "log --forward -l 1" maybe?
<guilhembi_> jam: hi! I wonder if you saw this: today when I "make" bzr.dev (linux gcc), I get lots of compiler warnings, and the resulting bzr segfaults on simple "bzr branch" (no problem if no "make"); no problem with bzr-1.7-rc1.
<jam>  guilhembi_: hmmm. I certainly haven't seen that
<guilhembi_> I re-tried with a fresh branch of bzr.dev, same problem. Seems to have been recently introduced...
<jam> are you on 64-bit or 32 bit
<guilhembi_> jam: 32; I'm diff-ing some c files like _btree_serializer_c.c (lots of warnings),
<guilhembi_> and it's really different between bzr.dev and 1.7.1-rc1:
<jam> guilhembi_: so my *guess* is an issue with Py_ssize_t and int, but 32-bit shouldn't matter
<guilhembi_> for example, 1.7.1-rc1 starts with
<guilhembi_> Generated by Pyrex 0.9.6.4
<guilhembi_> and bzr.dev starts with Generated by Pyrex 0.9.4.1
<jam> well, that is *your* pyrex version
<guilhembi_> then lots of code difference in this C file.
<jam> I tend to build with 0.9.8
<jam> guilhembi_: but it is generated from the _btree_serializer_pyx.pyx
<guilhembi_> But still, I had no issue the previous time I did "make" in bzr.dev, which was only a few weeks ago...
<jam> guilhembi_: sure, I'll email you a "current" form for all of them, and see if that fixes it
<jam> we certainly could have done something that broke pyrex 0.9.4
<Peng_> Hmm, I'm on 0.9.51a-1 without problems.
<Peng_> 5.1*
<jam> guilhembi_: also, btree_serializer shouldn't be the problem, as I doubt you are using a btree repo yet
<guilhembi_> jam: other files give lots of warnings:
<guilhembi_> bzrlib/_knit_load_data_c.c
<guilhembi_> bzrlib/_dirstate_helpers_c.c
<guilhembi_> bzrlib/_readdir_pyx.c
<guilhembi_> eof
<guilhembi_> jam: I'll just upgrade my pyrex
<guilhembi_> and see if it helps
<jam> just make sure you "make clean" first
<guilhembi_> yes
<guilhembi_> jam: that's funny: "make clean" does not remove bzrlib/_btree_serializer_c.c
<guilhembi_> shouldn't it?
<jam> yeah, it is just hard to do arbitrarily, as we have some .c files that need to be kept
<guilhembi_> jam: ok, so better re-branch...
<jam> guilhembi_: well "rm bzrlib/*.c ; bzr revert" works, too
<Peng_> Or bzrtools's clean-tree command may help
<guilhembi_> jam: ok, my too old pyrex was the cause, sorry for eating your time
<jam> guilhembi_: not really, we still need to know what we did
<jam> because unless necessary
<jam> we'd like to support older versions
<stefanlsd> Is it safe to delete obsolete_packs
<jam> stefanlsd: not the directory, but everything *in* the directory, yes
<jam> bbiab, need to reboot
<stefanlsd> jam: k. thanks
<mwhudson> beuno: have you looked at the loggerhead breadcrumbs bug?
<Peng_> Which bug?
<mwhudson> the same one
<mwhudson> abadger1999 has been having fun
<Peng_> Oh
<beuno> mwhudson, not yet. Do you have a number handy?
<abadger1999> mwhudson: heh.  "fun" heh.
<abadger1999> :-)
<mwhudson> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/268867
<ubottu> Launchpad bug 268867 in loggerhead "Breadcrumbs ignore PrefixMiddleware" [Undecided,In progress]
<jam> guilhembi_: We might just open a bug about bzr.dev not supporting pyrex 0.9.4, but if you could include any of the errors, .c files, etc it would be helpful
<beuno> mwhudson, I merged that into trunk already
<guilhembi_> jam: where should I put the errors?
<beuno> mwhudson, https://code.edge.launchpad.net/~toshio/loggerhead/breadcrumb
<mwhudson> beuno: um, there is more
<jam> guilhembi_: well, as attachments when possible
<beuno> mwhudson, ah?  sorry, didn't look into it that deep
<guilhembi_> jam: ok if you open the bug report, I'll attach my errors. Or do you want me to open the bug report?
<mwhudson> well, abadger1999 commented yesterday complaining about r227
<jam> either way, I don't have much to go on from my side, though
<abadger1999> mwhudson: Yeah.  the original branch that was merged fixed things for start-loggerhead and my mod_wsgi script.
<beuno> mwhudson, ah, I see.
<mwhudson> abadger1999: does https://code.edge.launchpad.net/~toshio/loggerhead/mod_wsgi fix the problems you've been having?
<abadger1999> mwhudson: But by r227, those were broken and only serve-branches worked.
<abadger1999> mwhudson: yes... I'm toshio :-)
<beuno> ah!  hi abadger1999!  :)
<beuno> thanks for the fixes
<mwhudson> abadger1999: yes, i've figured that much out :)
<abadger1999> beuno: No problems :-)
 * beuno re-assigns the bug to abadger1999 
<mwhudson> AmanicA: thankks for the python2.4 branch :)
<abadger1999> hah :-)
 * beuno is *very* happy to see Loggerhead getting more and more contributions
<abadger1999> Ugh.
<abadger1999> okay, that branch doesn't fix my problems because I pushed mod_wsgi code to it.
<guilhembi_> jam: https://bugs.launchpad.net/bzr/+bug/276868
<abadger1999> which has a merge to trunk at some point
<ubottu> Launchpad bug 276868 in bzr "bzr.dev does not support pyrex 0.9.4.1" [Undecided,New]
<abadger1999> So here's the relevant line in what was the branch:
<abadger1999> <tal:block repeat="crumb directory_breadcrumbs"><span tal:condition="not:repeat/crumb/start">/</span><a tal:attributes="href python:url([crumb['suffix']])" tal:content="crumb/dir_name" /></tal:block>
<abadger1999> specifically: href python:url([crumb['suffix']])"
<abadger1999> mwhudson: But at some point after my branch was merged you commited a change with this:  href python:static_url('/'+crumb['path'])"
<AmanicA> mwhudson cool
<abadger1999> the comment is: "fix breadcrumbs, maybe"
<mwhudson> abadger1999: ah yes
<mwhudson> hmm
<abadger1999> I don't know TAL very well (first exposure to it) so I don't know what the practical difference is.
<mwhudson> i'm not sure that breadcrumbs make much sense when using start-loggerhead ...
<abadger1999> Hmm... That could be.
<mwhudson> i guess i should write myself a loggerhead.conf and see what happens
<jam> guilhembi_: thanks for reporting it. I wish there was more info. But I believe 0.9.4 could easily cause compiler warnings, so that isn't a strictly obvious problem.
<jam> stuff like the "declared static but not used" I remember being in older versions of pyrex
<abadger1999> mwhudson: Here's mine for reference: http://toshio.fedorapeople.org/loggerhead.conf
<abadger1999> I've been playing with server.webpath.  Normally it's uncommented.
<Peng_> Yeah, I get a lot of warnings with 0.9.5.whatever, but no actual problems.
<guilhembi_> jam: if this bzr.dev/pyrex cannot be fixed, maybe one can add something like "require pyrex_version >=x.y.z" to "make".
<guilhembi_> opensuse 10.2 is from end of 2006, upgrading pyrex is imaginable.
<guilhembi_> (that's my distro).
<jam> guilhembi_: well, we try to support back to python2.4, so whatever was around in that era
<jam> though for *packaged* versions
<jam> we always bundle the .c files directly
<jam> so it doesn't matter what version of pyrex you have
<guilhembi_> jam: so, maybe:
<guilhembi_> "if .c file is missing, require pyrex_version >=x.y.z" in "make"...
<guilhembi_> if someone uses bzr.dev he may/should accept having recent tools, I believe we require that in MySQL.
<guilhembi_> we do for m4/automake/autoconf.
<jam> guilhembi_: do you still have access to the older code?
<jam> I'm curious what you would get with
<mwhudson> hm, a url like http://localhost:8080/None/static/images/ico_branch.gif seems suspicious :)
<jam> bzr revert -r 3731
<jam> as one of the last changes is:
<jam>  3732 Canonical.com Patch Queue Manager	2008-09-24 [merge]
<jam>       (robertc) Allow C extensions to build on python2.4 with older pyrex
<jam>       	versions. (Robert Collins)
<jam> guilhembi_: what version, btw, 0.9.4, or 0.9.4.1?
<jam> and what version of python?
 * mwhudson stabs ff
<guilhembi_> jam:
<guilhembi_> Python 2.5 (r25:51908, Nov 27 2006, 19:14:46)
<guilhembi_> pyrex was 0.9.4.1-25
<guilhembi_> but I upgraded it, I don't have it around, I can see to restore it...
<jam> well, I don't know Suse's packaging system very well anymore
<jam> you *could* rm /usr/lib/python2.5/site-packages/Pyrex and then install from scratch, but I'll try doing that here first
<guilhembi_> jam: wait, I started
<guilhembi_> removed 0.9.8, reinstalling 0.9.4.1...
<jam> wow, *lots* of exceptions with 0.9.4 and python2.4
<stefanlsd> how can drop a commit revision? i  tried revert, but not exactly what i want.
<guilhembi_> jam: "bzr branch -r3731" still warnings and segfault
<jam> just a sec, I'll give you another node to check
<Peng_> stefanlsd: If you want to remove the most recent revision(s) from history, use "bzr uncommit".
<jam> you say that 1.7 series works
<guilhembi_> jam: 1.7.1-rc1 yes
<guilhembi_> jam: but 1.7 source package!
<jam> sure
<guilhembi_> which has the .c built with canonical's pyrex, more recent than mine.
<stefanlsd> Peng_: thanks. that was it
<jam> but haven't you been using bzr.dev for a while?
<jam> or you just haven't done 'make' in a while?
<jam> well, *my* compile issues for 2.4 were because of a missing Python.h :)
<jam> no wonder it wasn't working
<guilhembi_> jam: I hadn't done "make" since a few weeks.
<jam> k, I still have some thoughts
<guilhembi_> jam: wait
<guilhembi_> jam: I read wrongly:
<guilhembi_> with -r3731, warnings but no segfault
<jam> guilhembi_: so there is still a question, did the extensions actually *build* correctly
<jam> do you have all of the .so files that we might expect
<guilhembi_> jam: wait
<guilhembi_> with -r3731, warnings but no segfault
<jam> it is possible it doesn't segfault because it doesn't finish compiling
<guilhembi_> with -r3757, warnings but segfault
<guilhembi_> s/but/and/ .I'm doing dichotomy
<jam> bisection, I would say :)
<guilhembi_> from the messages, it finishes compiling
<mwhudson> abadger1999: um
<guilhembi_> mmm in my maths lessons, "dichotomie" (in French) was looking at a and b, then (a+b)/2 and (a or b), etc.
<abadger1999> mwhudson: yes.
<guilhembi_> 3732 is ok
<mwhudson> abadger1999: your rearrangement of interpreting the 'potential_overrides' values from the config file is broken
<guilhembi_> 3745 broken, continuing
<abadger1999> mwhudson: k.  I nthe latest mod_wsgi branch?
<jam> well 3738 is suspicious
<mwhudson>         value = keytype(config.get(key, default))
<mwhudson>         if value is not None:
<mwhudson>             parsed_conf[key] = keytype(value)
<jam> 3739 is too
<guilhembi_> jam: 3738 ok
<mwhudson> if keytype is str and default is None...
<guilhembi_> 3741 broken
<guilhembi_> 3739 broken
<guilhembi_> jam: 3739 introduced the problem.
<guilhembi_> the segfault.
<jam> yeah, that was a big code drop
<abadger1999> Yeah... that's broke.
 * abadger1999 looks at what was there before
<jam> guilhembi_: so... new code breaks older compiler. Not entirely surprising :)
<jam> I just wish we had more to go on as to *why* the segfault occurs
<jam> I'll see if I can reproduce here
<jam> and maybe I can get a gdb traceback
<jam> crap
<jam> it seems you can't have multiple versions of pyrex installed side-by-side
<abadger1999>         value = config.get(key, default)
<abadger1999>         if value is not None:
<abadger1999>             parsed_conf[key] = keytype(value)
<jam> there is only one /usr/bin/pyrexc
<abadger1999> mwhudson: That better? ^
<mwhudson> abadger1999: maybe
<mwhudson> value = config.get(key)
<mwhudson> if value is not None:
<mwhudson>  parsed_conf[key] = keytype(value)
<mwhudson> else:
<mwhudson>  parsed_conf[key] = default
<mwhudson> ?
<abadger1999> mwhudson: That works.  I might do keytype(default) as well... it shouldn't hurt if default is already an int or a str
<abadger1999> but it will protect us if someone set '10' instead of 10.
<abadger1999> (OTHOH, it might break on non-simple types.)
<mwhudson> i don't think it's worth worrying about being very generic here
<abadger1999> k.
<jam> guilhembi_: segfault :)
<jam> Segfault at bzrlib/_dirstate_helpers_c.c:7785
<lifeless> moin
<jam> lifeless: morning. Seems that the compiled iter_changes breaks on pyrex 0.9.4 with a segfault
<mwhudson> abadger1999: can you commit/push that change, then i'll get back to digging?
<lifeless> jam: fun
<jam> anyway, I'll be back in a few minutes
<abadger1999> k
<jam> lifeless: it works fine with pyrex 0.9.6 and 0.9.8
<jam> So i'm trying to figure if it is a simple fix
<jam> or if we just make a dependency for running from source
<lifeless> jam: hmm, isn't dapper 0.9.4 anyhow?, if so it worked on pqm ...
<guilhembi_> jam: ok, it seems you have good insight now, I'll head to bed.
<lifeless> no, feisty has it though
<jam> lifeless: I was able to reproduce it with a local install and some creative PATH settings, so I'll poke at it for a while
<abadger1999> mwhudson: Which branch are you pulling from?
<mwhudson> abadger1999: ~toshio/loggerhead/mod_wsgi
<thumper> are there any pre-canned presentations about bzr that I can pillage for a 15 minute talk I'm giving to a PUG?
<abadger1999> mwhudson: Cool. It's pushed.
<lifeless> thumper: PUG?
<beuno> thumper, http://bazaar-vcs.org/Talks
<thumper> lifeless: python user group
<lifeless> oh lol :P
<thumper> beuno: thanks
<lifeless> clearly I've been playing too much wow - I was thinking 'pick up group?' surely not.
<thumper> lol
<jfroy> What is the proper way to install Bazaar plugins system-wide? I'm having an issue where on a stock Leopard system, easy_install bzr bzr-svn results in a functional bzr install, a successful installation of bzr-svn, but the plugin doesn't get found (e.g. there are no load failures either, it's just not found).
<lifeless> jfroy: wherever 'python -c import bzrlib.plugins; print bzrlib.plugins.__path__'
<lifeless> jfroy: is where they should go; I'm not sure on the right way to install bzr-svn though
<jfroy> Ah, it seems bzr-svn doesn't install itself properly, or rather this is probably a setuptools issue
<nosklo> I checked out a svn repository by using bzr checkout. Made a small change in a file, and now I want to commit. Repository uses simple http auth on apache. Why doesn't it work? It works fine with svn.
<lifeless> mwhudson_: are you aware of any downsides to putting a proxy object in sys.modules?
<jfroy> ls -l /Library/Python/2.5/site-packages/bzr_svn-0.4.13-py2.5-macosx-10.5-i386.egg/
<jfroy> drwxr-xr-x  3 root  admin  102 Oct  1 14:30 bzrlib
<jfroy> it installs as an egg
<mwhudson> lifeless: not really
<nosklo> it never asked for my password http://dpaste.com/81778/
<jfroy> (And so does bzr: /Library/Python/2.5/site-packages/bzr-1.7.1rc1-py2.5-macosx-10.5-i386.egg/bzrlib/plugins)
<jfroy> Although bzr seems to be smart enough to add site-packages/bzrlib/plugins to its plugin import path as well
<lifeless> nosklo: have you read te FAQ I think it talks about auth
<jfroy> In general, is it recommend to use easy_install for plugins (apparently there are issues), or should one generally download them and run the standard setup.py (that may not even address the issue).
<lifeless> jfroy: I am of the 'easy install is a broken concept' school; other than digging into what-why-and-how of eggs to decide I really do dislike them, I don't ever use the egg-and-related facilities
<lifeless> jfroy: thus my recommendation will always be to use bzr's setup.py, and ditto bzr-svn's setup.py
<nosklo> lifeless, hmm, can you point me to it? is it this faq http://samba.org/~jelmer/bzr-svn/FAQ.html here? can't find it.
<jam> lifeless: so... as near as I can tell it is just a buggy pyrex that would be really hard to work around
<jam> (for the 'fails with pyrex 1.4.1 stuff)
<lifeless> patches from users of easy_install are welcome, as long as they don't degrade support for non-easy-install environments
<jam> It is re-using a variable
<jfroy> lifeless: noted. I will agree with you there are issues with setuptools, but easy_install is truly useful as a Python package manager of sort. Until a better solution is developed...
<jam> and sometimes setting "pointer = 0" and using PY_XDECREF
<jam> and sometimes using PY_DECREF
<lifeless> jfroy: macosX? fink|maxports|the packaged bzr installer
<jam> and it is failing because it is using PY_DECREF when it should be using PY_XDECREF
<lifeless> jam: uhg
<jfroy> Just this morning, I had to hack some of the guts of setuptools because its zip unarchiver didn't restore UNIX mode bits when installing an egg, and I had UNIX executables as package data that wouldn't run after installation (obviously)
<lifeless> nosklo: oh, its changed; uhm
<jam> lifeless: so I get the feeling that if we want to support 1.4.1, we just need to create smaller functios
<lifeless> jelmer: ^ haaalp
<jam> functions
<lifeless> jam: 1.4.1 ?
<jam> lifeless: sorry pyrex 0.9.4.1
<lifeless> jam: :P
<jfroy> lifeless: that's general a good solution; however, unfortunately, there is no easy way to install or manage python packages using MacPorts while using the system's interpreter
<jam> It seems to just be something it runs into when a function is complex enough
<lifeless> jam: can we blacklist that version or something?
<jam> lifeless: sure, we can do it as part of setup.py I believe
<lifeless> jfroy: oh, ah well
<jfroy> And I need the system's interpreter because I heavily use PyObjC import packages for system frameworks
<jam> we can look at Pyrex.Compiler.Version or somesuch
<jfroy> mmm, it may be a worthwhile idea to see if a bzr install-plugin command / plugin would be useful to assist in installing plugins
<lifeless> jfroy: ok; well like I say, happy to review patches to work better in that environment; you might like to look at 'bzrlib.plugin' to see how the 'load plugins' code works
 * jfroy add item to TODO
<jam> lifeless: either that, or it is this bugfix
<jam>   - Temporary vars used by del statement not being properly     released, sometimes leading to double decrefs. [Jiba]
<jfroy> lifeless: I think, unfortunately, that it's not a Bazaar issue, but a plugin packaging issue, e.g. I've seen plugins install in various different ways based on weather they use setuptools or plain distutils, and how their setup.py is configured. It's somewhat of a mess...
<jam> but the "del" statements I see aren't near where it is segfaulting
<jfroy> *whether
<lifeless> jfroy: actual install for plugins is really just their setup.py; this works very well in  other environments; it *sounds* like failing introspection
<jfroy> lifeless: yeah it's setuptools' doing. Bazaar just doesn't scan eggs on the path for plugins. The "fix" would be to have bazaar scan every entry in sys.path for "bzrlib-plugins/" as a subdirectory of every entry, making sure that's not an actual package, and then adding that as a plugin import path
<jfroy> let alone refactoring the plugin code to support importing from potentially a virtual directory, e.g. if the plugin was installed as a zipped egg
<jfroy> Sounds like a lot of work that's not really worth the trouble :|
<jam> jfroy: it isn't worth some of our time, but it may be worth it for others
<jam> if people really need to use setuptools to install everything
<jfroy> jam: it's not an issue for people comfortable with Python, but in a situation (such as mine) where you'd like to promote adoption of Bazaar, it does help to be able to tell people to just "sudo easy_install bzr bzr-svn ..."
<jfroy> One liner install instructions are A Good Thingâ¢
<jam> jfroy: well, if they have "easy_install" available
<jfroy> No matter how flawed the underlying install mechanism may be...
<jam> apt-get install bzr works well here
<jfroy> jam: quite true...
<jam> or "start bzr-setup.exe"
<jam> depending on your platform
<jfroy> I'm mostly concerned with Mac OS X. MacPorts is certainly viable in a lot of cases.
<jfroy> But not in mine :(
<jfroy> I should get in touch with the maintainer of the 10.5 Installer package to help improve it.
<jam> jfroy: sure, I know I'd certainly appreciate the help in getting things packaged everywhere
<Verterok> jfroy: I usually build the 10.4 installer, what improvements to recommend?
<Verterok> ah, mornin' all
<jfroy> Verterok: I just sent an email to Szilveszter Farkas, I can forward it to you.
<Verterok> jfroy: that would be nice, I know the installers are a bit different, but I'ld like improve it
<jfroy> The 10.4 installer actually offers more plugins than the 10.5 one (bundling loom would be nice), but the critical one is bzr-svn (in my case).
<Verterok> jfroy: right, I'm working to include bzr-svn in the 10.4 installer, but I'm fighting with PackageManager to include both versions (for 1.4.x and 1.5.2)
<Verterok> jfroy: actually, buidling a mpkg for bzr-svn is quite easy
<jfroy> The maintainer for the 10.5 package recommends using bdist_mpkg
<Verterok> jfroy: yeap, I use that. just need to patch the setup.py to use setuptools instead of distutils
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.7.1 now available! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<mxpxpod> I'm using bzr-svn version 0.4.13 and I'm trying to branch an svn repo without using svn+ in the URL (since it's deprecated), but when I do that, it tells me that authorization is required... how do I get around that?
<Verterok> jfroy: and to build it run something like: http://rafb.net/p/qlHJMT35.html
<jfroy> Verterok: it dies on me, fails to find the nidump command
<jfroy> looking at the source right now
<jelmer> mxpxpod, that's a known bug
<Verterok> jfroy: I have it at /usr/bin/nidump
<jfroy> That sounds like one of the old netinfo tools
<mxpxpod> jelmer: any fix?
<jfroy> Verterok: they're gone on 10.5 :p
<jelmer> mxpxpod, for now please just use svn+  until that bug is fixed
<mxpxpod> jelmer: ok, thanks
<Verterok> jfroy: setuptools is trying ot use it?
<jelmer> mxpxpod: bug 256612
<ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [Medium,Triaged] https://launchpad.net/bugs/256612
<mxpxpod> jelmer: thank you
<poolie> hi jelmer, all
<jfroy> Verterok: it's used by bdist_mpgk.tools.get_gid()
<jam> poolie: morning. Can you call the house today for the standup? Or my cellphone
<jelmer> hi poolie, Verterok, jfroy, jam
<poolie> sure
#bzr 2008-10-02
<Verterok> heya!
 * Verterok waves greetings
<Verterok> jfroy: it looks like a bug un setuptools :(
<Verterok> jfroy: or an old version
<jfroy> Verterok: not part of setuptools, that's part of bdist_mpkg
<Peng_> How do you get "bzr: ERROR: No module named tests" when running from source?! :(
<Peng_> Ahh! Plugin! Heh
<Verterok> jfroy: right, it seems to be fixed in trunk
<Peng_> That's what I get for not reading hte traceback first.
<jfroy> Verterok: Ah, I see
<Verterok> jfroy: the trac instance seems to be down, but you can get it from the svn: "< impl> I didn't realize Aerdan had prioritized the animals he wants to have sex  with"]
<Verterok> 19:48 < mxpxpod> jelmer: ok, thanks
<Verterok> worng paste :p
<Verterok> jfroy: http://svn.pythonmac.org/bdist_mpkg/bdist_mpkg/trunk/
<jfroy> yeah I got it :)
<Verterok> ok
<jfroy> Verterok: seems to work great
<Verterok> nice
<jam> poolie: can you call back?
<poolie> sure
<lifeless> hi poolie
<jfroy> Verterok: yup, works :)
<Verterok> jfroy: yay!
<jfroy> It is Very Goodâ¢ not to have to type my svn passwords 3 times or more for operations on svn repositories (with my experimental bzr+keychain branch)
<jfroy> :)
<jfroy> Need to get that out of experimental now :p
<lifeless> poolie: sorry, missed it
<lifeless> poolie: pls ring again
<jfroy> Verterok: It's kind of sucky that you have to maintain two builds to target 1.4 and 1.5
<Verterok> jfroy: yeap, don't have an idea of how much I agree on that
<jfroy> Tiger is so long ago for me, was svn even bundled with it?
<Verterok> jfroy: but I know there are a lot of people still on 1.4.x
<Verterok> jfroy: nope, you must install it from "somewhere" (macports, collabnet, etc)
<jfroy> Verterok: that's incredibly crappy :/
<Verterok> jfroy: yeap, that's the reason I only build it against collebnet binaries :)
<jfroy> Honestly, I'd just make 2 packages, one for svn 1.4 and one for svn 1.5, installed in /usr/local/ (e.g. the collabnet binary packages). If they have it elsewhere, I'd just tell them to build bzr-svn from source...
<Peng_> Eek, there's a test that builds everything?
<Verterok> jfroy: imagine building it for macports, fink, collabnet (all x2 (1.4 amd 1.5)) :p
<jfroy> Verterok: no thanks ;p
<Verterok> me neigther :)
<jfroy> If you wanted to be *reaallly* clever, you could build against 1.4 only in /usr/local, then use an installer script to find the actual install, then muck around the Mach-O headers to change the import paths, and hoping the 1.5 libraries are binary compatible with the 1.4 libraries :p
<jfroy> Sounds like a lot of unpleasant installer script work :p
<Verterok> indeed :p
<jfroy> Verterok: oh, you'd also have to weak import all symbols and modify the bzr-svn source to check for NULL function symbols, in case someone decides to build from source and omit support for https, or keychain, or what have you :p
<Verterok> jfroy: that sounds way too complicated :), I'll stick with the script that build both version against collabnet binaries. as far I know, is the more complete dmg for 10.4
<Verterok> if someone builds svn from source, I'm pretty sure the 'll be able to build bzr-svn ;)
<jfroy> Verterok: I wasn't being serious :p
<Verterok> jfroy: I supposed that, but just in case :)
<poolie> markh, could you try to build 1.7.1 exes sometime?
<poolie> i did not set up that server yet
<poolie> i'd like to
<markh> poolie: sure - I'll try and do that this afternoon
<poolie> thanks
<markh> I've been working on porting pywin32 to py3k recently - that is an interestng experience :)
<markh> well - more like watching/helping some other person do it :)
<markh> I figured I should get a little hands-on experience before the first official release - even if only by a few days
<jml> spiv: is there a config option I can use so that -dHPSS is always on?
<spiv> jml: "alias bzr='bzr -Dhpss'" in your bashrc ;)
<jml> incidentally, MemoryTransport.rename's behaviour varies based on dict ordering.
<spiv> jml: that doesn't sound good.
<jml> spiv: it doesn't feel good eiter.
<mwhudson> in other sucky news
<mwhudson> mwh@grond:init-stack-pull$ bzr push
<mwhudson> Using saved push location: bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/init-stack-pull
<mwhudson> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Emwhudson/launchpad/init-stack-pull/.bzr/repository/')
<spiv> mwhudson: pastebin the traceback?
<mwhudson> spiv: there is no traceback
<spiv> mwhudson: ~/.bzr.log is your traceback-recording friend! :)
<mwhudson> hey guess what guys!!!
<mwhudson> it was autopacking
<spiv> It might be caused by the same sort of situation that has caused TooManyConcurrentRequestErrors in the past.
<spiv> Heh.
<jml> number one bzr bug
<mwhudson> at least it's fixed now
<spiv> mwhudson: I'd still like to see the traceback :)
<mwhudson> spiv: https://pastebin.canonical.com/9805/
<mwhudson> spiv: happens with bzr.dev 3731 too fwiw
<spiv> Yeah, I think it does have the same root cause.
<spiv> mwhudson: thanks
<mwhudson> my bzr.dev may be a little out of date tho
<jml> spiv: bug 276972 if you are interested.
<ubottu> Launchpad bug 276972 in bzr "MemoryTransport.rename behaviour varies with dict ordering" [Undecided,New] https://launchpad.net/bugs/276972
<spiv> jml: ta
<mwhudson> spiv: happens with bzr.dev too, but maybe upgrading the bzr on the server would fix it?  not sure
<mwhudson> (as would maybe pushing over sftp i guess)
<spiv> mwhudson: depends on what the underlying error that is being masked by the bug in BzrBranch.push is
<spiv> mwhudson: I can give you a patch to allow the original exception to propagate
<mwhudson> spiv: i am driving several hundred km away in about 20 mins :)
<spiv> mwhudson: http://rafb.net/p/4pgIvJ66.html
<spiv> mwhudson: but if you go enjoy your road trip instead I'll understand :)
<spiv> mwhudson: https://bugs.edge.launchpad.net/bzr/+bug/230902
<ubottu> Launchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]
<lifeless> spiv: ping; remind me - subclasses of classes with slots; need the total list of attributes?
<spiv> lifeless: IIRC, they just need the list of attributes added by the subclass.
<spiv> Hmm, apparently my memory is faulty.
<lifeless> spiv: :P
<spiv> Ah, no, just my quick 10-second attempt to verify it in the python interpreter was wrong :)
<spiv> My memory turns out to be fine :)
<spiv> (And the docs in fact say the meaning of defining the same slot twice, i.e. in a class and in a subclass, is "undefined")
 * mwhudson off
<lifeless> spiv: interesting; see, I want to delete a slot the base class has :P
<spiv> lifeless: ah, well... tough :P
<lifeless> :->
<lifeless> when did I last mention hating doctest?
<lifeless> abentley: are you up?
<abentley> Yeah
<lifeless> serializers are puzzling me
<lifeless> I'm hacking on a demand-loading inventory
<lifeless> serializer foo currently assumes you *can* serialize an inventory to a single string
<lifeless> e.g. bzrlib/tests/per_repository/test_repository.py
<lifeless> line 671,
<lifeless> test_add_revision_inventory_sha1
<lifeless> which checks that the serializer is used and its sha output recorded
<lifeless> I *think* I need to make the interface tests not be defined in terms of the serializer object, but I was wondering if you had any thoughts?
<abentley> lifeless: by demand-loading, what do you mean?  Segmented so that only some items are loaded at a time?
<lifeless> abentley: yes
<lifeless> abentley: fragemented into lots of little pieces
<abentley> So I would say the serializer abstraction doesn't make sense for these.
<lifeless> I figure I can have a serializer object that represents the particular style of splitting
<lifeless> and we still have revisions as single objects
<abentley> Okay, our *current* serializer abstraction doesn't make sense.
<lifeless> :>
<lifeless> thanks, I think I have what I need
<lifeless> I've posted about this work btw, and its pushed
<lifeless> the most recent stuff isn't passing tests yet and I'm closing the gap there hoping to push more to play with tonight
<abentley> You'll probably want moral equivalents of most of the single-string serializer tests.
<abentley> And I'd imagine the existing tests should be used for existing serializers.
<abentley> lifeless: Yeah, I sort of read it.
<poolie> lifeless: i don't have a strong opinion that you should do a cache in a CHKInventory now
<poolie> it is not very clear from your mail why you'd want to
<abentley> I'm not really clear on what CHK stands for, so I can't comment intelligently.
<lifeless> abentley: its an abbreviation for content hash key; e.g. "md5:1234123421342" or "sha1:1234135143514645acdef"
<lifeless> (this predates git's terminology and is more general, I think its a more useful way to talk about using hashes as keys)
<abentley> lifeless: So CHK is a superset of content-addressible filesystem.
<lifeless> poolie: there may be code that does lots of repeated lookups of the same fileid
<lifeless> poolie: a cache would ameliorate those codepaths (remove repeated-parsing overhead)
<poolie> right
<poolie> i thought that's what you meant
<lifeless> abentley: roughly yeah; not really a file system as packs are transactional etc etc
<abentley> lifeless: I mean the CHK terminology, not your work specifically.
<lifeless> abentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic
<poolie> abentley, i agree, i think HashKeyedInventory or something would be clearer
<poolie> or even just HashedInventory
<lifeless> SmokingInventory
<poolie> mm
<poolie> at least it's not scatalogical
<abentley> Yeah, HashedInventory is more evocative.
<lifeless> its building on CHKMap not on hashing itself; its quite generic code; uhm, I'm sure thenaming can be improved, but perhaps its making the layers clearer that is needed
<abentley> This is also a split inventory concept.  Is it splitting on directories or a radix tree?
<lifeless> abentley: either
<lifeless> abentley: I intend to put together CHKMap subclasses to let use experiment with both both those concepts and the other variations
<lifeless> abentley: (which are the parameters I mentioned in my mail from tuesday)
<lifeless> s/use/us/
<poolie> presumably both of them should be renamed if we think 'CHK' is cryptic
<abentley> lifeless: I didn't see that mentioned in the email.
<lifeless> poolie: presumably; one more note on naming though - it should be quite specific; 'Hashed' is IMO hopelessly generic, I mean, current Inventory objects are Hashed internally. (self._byid).
<spiv> I didn't find "CHK" too cryptic, but perhaps I'm just odd :)
<lifeless> abentley: this list:
<lifeless> The undecided aspects, which experimentation/modeling is needed on:
<lifeless> ...
<lifeless> includes the item for how we break up nodes in the tree
<abentley> lifeless: It doesn't actually say that, though.  I had to re-read it 3 times to guess that "should we canonicalise nodes by size rules, or (only applies to a name map that doesn't hash keys) by directory membership" was addressingthat.
<lifeless> abentley: sorry :)
<lifeless> abentley: I'm quite deeply embedded in this now, after some months of lead up; I'll try to be more clear in future
<lifeless> abentley: though there is a tradeoff in repeating content from the design work (which is in doc/developers/inventory.txt in bzr.dev)
<abentley> lifeless: Yes, there is a balance to be struck.
<lifeless> abentley: I just an image of a set of scales being hit repeatedly
<lifeless> abentley: :)
<markh> poolie: uploaded
<poolie> thanks!
<poolie> markh, could you send me a brief roadmap of what you'd like to do next on tortoise?
<markh> sure
<vila> hi all
<vila> spiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ?
<lifeless> spiv: ping
<lifeless> spiv: I have a wtf moment in check
<lifeless> spiv: in repository.py, line 3259 for me is:
<lifeless> knit_parents = parent_map[key]
<lifeless> this is in a try:except RevisionNotPresent: guard
<lifeless> but parent_map is a plain dict ?
 * spiv opens it up
<spiv> lifeless: sure looks like a wtf
<lifeless> spiv: clearly, I'm doing heart surgery here, so I'm seeking option numero duo
<lifeless> spiv: ok, so its broken code, and the question is 'why do normal repos not hit it'
<lifeless> spiv: thanks
<spiv> lifeless: I assume there's a gap in the test coverage :(
<lifeless> spiv: possibly not
<spiv> lifeless: hmm, actually
<lifeless> spiv: possibly its a redundant check that cannot trigger unless something else is broken
<lifeless> (as in some other code is broken)
<spiv> lifeless: yeah, that's what I'm suspecting
<spiv> lifeless: anyway, no need for us both to do the same digging at the same time :)
<lifeless> spiv: I'm not digging at that :)
<lifeless> spiv: with consensus on the wtf, I'm ignoring it
<spiv> Ah.  Well, I still intend not to get side-tracked then :P
<lifeless> spiv: good choice :)
<spiv> vila: oh, I didn't re-read the new patch carefully, I thought it was just updating == to is.  I see now it also moved it to the right layer.
<poolie> lifeless: did you call?
<lifeless> poolie: no
<spiv> vila: it'd be nice to have a test that reliably fails (on all platforms) without this fix.
<spiv> vila: I *think* that's probably feasible using the _DisconnectingTCPServer in test_bundle (i.e. the same way that is triggering test failures for you atm)
<vila> spiv: I'll look into that, do you also want it to apply to all SmartMedium classes ?
<vila> well, may be not all, the pipe one may not be relevant
<spiv> vila: e.g., start a _DisconnectingTCPServer, create a SmartTCPClientMedium pointing at it, and then try client_medium.read_bytes(1)
<spiv> Well, it'd be good to have equivalent tests for all SmartMedium classes, but it can't be the exact same test.
<spiv> Pipes don't talk to sockets and get socket.errors, after all :)
<jdrake> bzr is *sweet*
<vila> sure, and socket.error may not be relevant either for http
<spiv> Right.
<spiv> I certainly wouldn't object to doing that :)
<vila> spiv: Ok, I read that as BB:resubmit then :) Thanks
<spiv> But I wouldn't hold up landing the fix to this medium while working on unique tests for all medium implementations.
<spiv> So, bb:tweak :)
<jdrake> I can actually remember how to use some of the commands, unlike cvs
<spiv> jdrake: that's because we don't use "update" to do three different operations ;)
<jdrake> haha
<jdrake> I might actually be able to use bzr to do more than just code with school coming up.
<spiv> vila: bb:tweak formally given
<vila> spiv: ok, thanks
<lifeless> abentley: if you're around, do you remember the precise in-memory difference between a rich-root inv and a non-rich-root ?
<lifeless> abentley: actually, nvm, asking that question clued me in to the answer
<robsta> hi lifeless
<robsta> lifeless: jelmer hinted you might know a workaround for phantom references messing up "diff"
<robsta> (bug#275861)
<robsta> oh "ghost revisions" it's called
<lifeless> robsta: hi; uhm, I don't think I do
<lifeless> robsta: did he hint with any more detail ?
<lifeless> jelmer: ^ EWHYME?
<robsta> lifeless: no; is this specific to svn server-side?
<lifeless> robsta: yes, bzr-svn exercises the ghost capabilities most strongly of anything bar 'baz-import' which I think has actually been deleted from bzrtools now
<lifeless> robsta: last I heard jelmer was working on changing a bunch of stuff to fit what bzr's core looks for more; I don't know  if he has
<lifeless> robsta: BTW, orthogonal thing, you might like to try the 'development2' format in bzr.dev; it uses the btree stuff I was doing back @ guadec; the new compressor isn't finalised yet, but the index stuff helps quite a bit
<robsta> lifeless: define "quite a bit"
<robsta> lifeless: i tried going back to bzr-playground.gnome.org, but when i merge my svn into the bzr branch there's an error about rich-root
<lifeless> robsta: depending on specific workload, up to 10 times faster, or more.
<lifeless> robsta: pastebin the rich root error please
<robsta> speed is not the problem, the problem is that diff bails on me
<lifeless> robsta: right, did I mention orthogonal?
<robsta> lifeless: http://pastebin.com/m36aec880
 * robsta prefers to stay one-dimensional
<lifeless> that would be the whiskey dimension?
<lifeless> run bzr info -v locally please
<lifeless> specifically on gtk-css-engine-bzr
<robsta> http://pastebin.com/m6f95d2bf
<lifeless> no idea *how* you got that setup; but its not a bzr-svn compatible local repository
<lifeless> back it up, then bzr upgrade --rich-root-pack
<lifeless> then try again
<robsta> lifeless: yay
<robsta> lifeless: so does this still have ghost references, or can i push --overwrite this to the upstream svn?
<lifeless> robsta: give it a shot; I disclaim all knowledge of code internals
<lifeless> svn is atomic yeah? whats the worst could happen :P
<poolie> vila, yeah, let's talk here
<vila> Discussing with John, it appears that log.py miss an API with revids (that's the main blocking part for missing)
<vila> <vila> either that or some variation where you give the list of revisions you want to show
<vila> <vila> roughly speaking, log is designed around revnos with shortcuts to avoid O(history) when only mainline revisions are needed
<lifeless> vila: ^ oh yeah, re ghosts, bzr-svn, major user.
<vila> lifeless: thanks, sorry, I still need to send that mail :-/
<vila> lifeless: but it's not forgotten !
<robsta> lifeless: "No new revisions to push." can i force this somehow?
<robsta> lifeless: for some reason svn is like 30 revs ahead
<vila> I (well jam too :)  think log.py should evolve in a direction where we can calculate revnos on-demand
<poolie> vila, i think that idea of jam's that we should show why some revisions are included is interestning
<poolie> > the true solution is to be able to get revnos without being O(history)
<poolie> right, that would be highly useful
<vila> sure, the two are related, but getting revnos without being O(history) is the root
<poolie> so as i understand there are two threads towards that - either caching them, or looking for algorithms that let us skip larger parts of the graph
<vila> another one being changing the revno definition, but for compatibility I don't want to *start* with that
<vila> an intermediate solution is also to use gdfo
<vila> gdfo == Greatest Distance From Origin
<vila> which could also help spiv case in Batch get_parent_map HPSS calls made from InterRepo._walk_to_common_revisions
<vila> I know that but I'm not able to explain it clearly just yet :-/
<vila> roughly, we indirectly batches requests when bisecting today, using gdfo can help batching requests in a more controlled way
<lifeless> robsta: svn has new content?
<lifeless> robsta: or just a higher 'revno' ?
<robsta> lifeless: just revno, just pulled everything into the bzr tree
<lifeless> robsta: revno is per-branch, so it sounds like no-problem to me, or am I missing something?
<poolie> vila, so as far as scheduling it, i'd be looking at: is it likely you'll make progress on it, does it matter to guilhem and other users, and should we be concentrating on something else instead
<poolie> i would say the startup overhead for log does matter to people
<lifeless> robsta: I have to go now; sorry
<lifeless> robsta: uhm, I'd hope jelmer is up soon
<vila> I'm surely making progress on it but I need some more time to show results
<lifeless> bye poolie
<lifeless> and vila etc
<robsta> lifeless: will use it, should work, thanks!
<vila> the scale being days
<poolie> night lifeless
<vila> lifeless: cu
<vila> the scale being days, several days, but not more than two weeks I'd say
<fullermd> Well, on the downside, getting log running IS awfully slow sometimes...
<fullermd> But on the sorta-upside, any time I feel like log is too slow, I can just run log -v to jolt myself.
<vila> another aspect, thanks fullermd, is to make log really streamed
<fullermd> We're storing the revno of HEAD in the branch.  I can't help but feel we're not USING it, though...
<vila> another option being to *not* show revnos for people who want really fast log :)
 * spiv goes to the shops
<vila> fullermd: we use it !
<vila> all shortcuts are based on that
<poolie> vila, or we could default to log --line, and make sure that it does not compute non-mainline revisions
<poolie> i think that may be the easiest in some ways?
<vila> poolie: I think we do already
<poolie> do you know what's the main thing in the profile of --line?
<poolie> hm
<fullermd> That's even sadder, then.
<poolie> well, perhaps that's beside the point
<poolie> fullermd: what is?
<fullermd> log --forward --short -r-10.. of bzr.dev (with bzr dev), with all the caches heated up and all, takes like 3 seconds.
<vila> I concentrate on higher level stuff so far but plan to measure progress on how things go
<fullermd> I assumed at least some of that was eaten up walking back to origin to figure out the revnos.
<poolie> hm, it's about 800ms for me...
<fullermd> 2.608u 0.223s 0:02.84 99.2%
<vila> fullermd: come on, --forward is just asking for slowness :)
<vila> at least for now
<fullermd> Doesn't make any distinguishable difference   :p
<poolie> hm
<vila> roughly, actually, log is based on the idea that we built the history we need (the long part) then we issue the formatted text we want for each revision
<fullermd> Now, granted, my system isn't the speediest on the planet.  But still, it's fast enough that Firefox is almost usable a good half of the time.
<poolie> anyhow
<vila> What I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text
<luks> jelmer: are you around?
<poolie> hi luks
<luks> hi
<luks> ok, now I'm really confused
<luks> I thought `bzr dpush` from bzr-svn was supposed to rebase my branch
<luks> but it kept my bzr revision untouched, so I deleted the bzr-svn cache, tried to branch again and I still get the original revision
<bob2> hm, so long since I modified a chatscript
<bob2> oops
<No`> hi bazaarians
<jelmer> luks, somewhat
<jelmer> luks, it will rebase your *local* branch
<jelmer> if necessary
<luks> jelmer: yeah, the thing is that it did not
<luks> jelmer: at least from what I can see
<luks> jelmer: and I don't understand where is the info (revid, etc.) stored, because it's not in SVN
<jelmer> luks, it will also not rebase if it didn't have to push anything
<luks> jelmer: it pushed one revision, I'll try to branch on a completely clean machine
<lifeless> jelmer: robsta has some issues
<robsta> lifeless: should i attach the repo tarball to the bug (1.7M bz2) =
<lifeless> robsta: sure
<lifeless> jelmer: I am not here right now, but all I had robsta do was upgrade to rich root (they weren't, for some ??? reason - don't know how anything had worked before then)
<lifeless> jelmer: but now it has a missing text error, I'm suspecting some bzr-svn interaction bug; perhaps you can chat in detail with robsta to figure out exactly what's happened
<robsta> #277043, fyi
<Se6ast> Hi guys. I do have a small project versioned with bzr (personal version control in the guide), myproj/subprojA. so in subprojA there is a .bzr repo with the full history. However, I am now adding other sub-projects: myproj/subprojB, myproj/subprojC and I would like to have a new bzr repo with everything in myproj. So I cd myproj; bzr init. How can I pull all the versioning history of subprojA into it ? with merge? in myproj if I do bzr merge subproj
<jelmer> lifeless, robsta: I don't have time to look into it at the moment, but have a look when I do. Thanks for filing a bug.
<robsta> n/p
<jml> is there a revisionspec for branch parent?
<visik7> I want to checkout django-1.0  with bzr
<visik7> bzr get http://code.djangoproject.com/svn/django/trunk django-bzr
<visik7> works
<visik7> while
<visik7>  bzr get http://code.djangoproject.com/svn/django/tags/releases/1.0 django
<visik7> doesn't
<visik7> the 2 path works with the svn command
<lifeless> jml: :parent ?
<jml> lifeless: nope. maybe my bzr is too old.
<lifeless> oh thats a location alias
<lifeless> meh
<liw> if I convert my branch to rich-root-pack format, how likely will I make other people suffer? (the main person I collaborate with has that format and that makes it hard for me to currently accept his bundles)
<g0nzal0> hi there!
<g0nzal0> I'm trying to use bzr-svn
<g0nzal0> I installed it using "sudo easy_install bzr-svn"
<g0nzal0> but it doesn't seem to be working :(
<g0nzal0> http://dpaste.com/81931/
<Verterok> g0nzal0: what is the name of the directory were easy_install "installed"?
<g0nzal0> /usr/lib/python2.5/site-packages/bzr_svn-0.4.13-py2.5-linux-i686.egg
<Verterok> ohh eggs
<Verterok> g0nzal0: I'm not sure that bzr  plugins work as eggs at all
<g0nzal0> I see, I'll try something else, thanks for the info :)
<Verterok> g0nzal0: try installing it using plain old setup.py and avoid egg
<g0nzal0> yes, I'm onto it
<Verterok> g0nzal0: np
<g0nzal0> Verterok: :(
<g0nzal0> http://dpaste.com/81935/
<Verterok> let's see
<Verterok> g0nzal0: run it with -Derror
<Verterok> g0nzal0: i.e: bzr -Derror plugins
<g0nzal0> Verterok: I had bzr installed with easy_install too
<g0nzal0> Verterok: took that away
<g0nzal0> Verterok: and reinstalled it from ppa
<g0nzal0> Verterok: (I use Ubuntu)
<g0nzal0> $ bzr -Derror plugins
<g0nzal0> gtk 0.94.0
<g0nzal0>     Graphical support for Bazaar using GTK.
<g0nzal0> launchpad
<g0nzal0>     Launchpad.net integration plugin for Bazaar.
<g0nzal0> svn 0.4.13
<g0nzal0>     Support for Subversion branches
<g0nzal0> :-D
<Verterok> g0nzal0: goooood, ppa is goood :)
<g0nzal0> didn't know about it, it rocks! :)
<vila> la la la, Russian roulette, pqm blocked
<g0nzal0> I'm branching django-survey with bzr-branch!!!
<jam> vila: *why* does it always happen from *your* submissions?
<jam> I'm really quite surprised
<jam> I wonder if it is merging from lp: that is causing problems
<vila> I had one submission passing without problem from lp earlier
<jam> maybe it doesn't like "osx" in names
<vila> what surprised me the most is that the submissions are successful while someone is *killing* a process (knowing what process may help though)
<jam> vila: I just pinged mthaddon, and he said he got it going again
<vila> thanks to him and you, again...
<vila> Most probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :)
<_MMA_> Command to upload *all* unknown files in a existing branch?
<_MMA_> bzr add ?
<beuno> yeap
<beuno> well
<beuno> depends on your definition of *all*
<beuno> add won't add ignored files
<_MMA_> Anything shown as "unknown".
<beuno> yeap
<beuno> bzr add
<_MMA_> Oh. I thought it had to have something after "add". Like "bzr add all" or something. :)
<_MMA_> cool
<beuno> nope nope, it's the default
<beuno> you have to add something if you *just* want to add one file
<_MMA_> I see.
<idx_foo> Installing bzr for eclipse, I have bzr, jdk, eclipse and xml plugin of correct versions.
<idx_foo> In Window -> Preferences, turning on icon decorators causes "An error has occured. See error log for details"
<Verterok> idx_foo: did you configured the bzr executable in Preferences --> Team --> Bazaar?
<idx_foo> When trying to share a project, I choose a bzr path, click next, it flashes up a progress dialog very quickly, then does nothing.
<idx_foo> Verterok: yes, to /usr/bin/bzr
<idx_foo> bzr works fine, and the --xml option does too.
<Verterok> idx_foo: which version of bzr-eclipse and xmloutput?
<Verterok> also, what is the name of xmloutput plugin folder in .bazaar/plugins ?
<idx_foo> bzr_xmloutput_0_8_0
<Verterok> (it should be xmloutput)
<idx_foo> bzr eclipse 1.1.0
<idx_foo> oh
<idx_foo> I'll try that
<Verterok> idx_foo: rename bzr_xmloutput_0_8_0 to xmloutput :)
<idx_foo> nope
<idx_foo> Now the error doesn't happen in the pref window
<idx_foo> But still can't share the project
<idx_foo> I'll be back later
<Verterok> idx_foo_away: when you come back, please check the log at <workspace>/.metadata/.log
<Stavros> hello
<Stavros> my repo is in knit4 format and i need to upgrade, which is a good format to use?
<beuno> Stavros, packs 0.92 if you're not into any weird stuff
<Stavros> beuno: does sodomy count?
<beuno> well, weird is a very dodgy concept
<beuno> I'd say, go with packs, and if something doesn't work, you can always change again  :)
<Stavros> that doesn't work
<Stavros> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
<beuno> ah
<beuno> rich root
<Stavros> and it broke my repo
<Stavros> good thing it made a backup
<Stavros> what's rich root?
<beuno> bzr makes backups when upgrading
<beuno> bzr.backup/
<Stavros> i moved it back and it works
<Stavros> but no upgrade
<Stavros> why do i have this rich root?
<beuno> Stavros, I think you have to do bzr upgrade --rich-root-pack
<Stavros> Ã´Ã§Ã¡Ã´ Ã³Ã¥Ã¥Ã¬Ã³ Ã´Ã¯ Ã§Ã¡Ã¹Ã¥ Ã²Ã¯Ã±ÃªÃ¥Ã¤, Ã´Ã§Ã¡Ã­ÃªÃ³
<Stavros> Ã±Ã¥Ã±
<Stavros> damn
<Stavros> that seems to have worked, thanks
<nihilocrat> hello
<nihilocrat> I'm having an issue with several of my projects... there are some files that constantly have conflicts (they are binary and necessarily changed every commit)
<nihilocrat> I solve them by just copying *.OTHER over the original file and resolving it
<nihilocrat> but in some cases I am getting conflicts where it says some file called <filename>.OTHER.OTHER.OTHER<etc> is conflicted
<nihilocrat> I have no idea how that happens and how to get it to go back to just being <filename>.OTHER
<beuno> nihilocrat, are you running "bzr resolve FILENAME" after you copy the file over the existing one?
<nihilocrat> yes
<nihilocrat> here's what I usually do:
<nihilocrat> mv file.OTHER file
<nihilocrat> resolve file
<nihilocrat> *bzr resolve
<beuno> and then you commit?
<nihilocrat> the mv is just normal old mv
<nihilocrat> no, I don't commit, usually it's the case where this is a working copy that I'm pushing to
<nihilocrat> (web app code)
<beuno> I see, the remote branch is the one with .OTHER.OTHER...?
<nihilocrat> yeah
<nihilocrat> usually I push, and then update
<nihilocrat> and then the conflicts appear
<beuno> yes, that's happened to me
<beuno> I'm not exactly sure why that happens (I should probably look into it)
<beuno> but, what I have to do, is resolve them remotely, and commit
<nihilocrat> due to annoying firewall configuration that can't be changed, I can't just bind to the master branch and update
<nihilocrat> I have to push
<nihilocrat> ok
<beuno> it only happens sometimes
<nihilocrat> hmm
<beuno> so, I haven't needed to look into it too much
<nihilocrat> I might try resolving, committing, then pulling
<beuno> I'd also recommend running "bzr reconcile" on the remote branch
<nihilocrat> see if it at least gets rid of OTHER.OTHER.OTHER
<nihilocrat> oh
<nihilocrat> never heard of that command
<nihilocrat> I'll look into it
<beuno> nihilocrat, make sure the remote repo is clean and resolved, commit, resolve
<beuno> and pull
<beuno> should work well from then on
<nihilocrat> ok
<idx_foo> Ok, so I'm installing bzr eclipse, but when I go to Team > Share Project, at the Select Directory screen, "Finish" pops up a progress bar that dissapeares quickly, and doe not xlose the wizard. The project cannot be shared as a result.
<Verterok> idx_foo: go to preferences -> team -> bazaar
<idx_foo> yes
<idx_foo> done
<Verterok> idx_foo: there is textfield to speficy the port of the xmltpc service, and just above it a label that indicate what kind of client was detected
<idx_foo> XmlRpcClient
<Verterok> so far so good :)
<idx_foo> Recheck changes nothing
<Verterok> that means that the xmloutput is correctly installed
<idx_foo> Btw, before hand to check bzr from the terminal I did "bzr init" and then "bzr add somefolder"
<Verterok> idx_foo: np, thanks ok
<idx_foo> Successfully, but I don't know how  that will change Eclipse's behaviour
<Verterok> idx_foo: please check the log file at <workspace>/.metadata/.log
<Verterok> idx_foo: that should not affect eclipse
<Verterok> idx_foo: of open the error log view if you have de SDK
<idx_foo> what SDK is this
<idx_foo> I have .log open in gedit now, rather huge though
<idx_foo> I'm getting "java.lang.NoClassDefFoundError: org/eclipse/jface/viewers/BaseLabelProvider"
<Verterok> yeap, it grow and grow, until you zap it
<Verterok> idx_foo: what version of eclipse?
<idx_foo> 3.2.2
<idx_foo> On Ubuntu 8.10
<idx_foo> 8.04 even
<Verterok> bzr-eclipse only works with >= 3.3
<idx_foo> Heh
<idx_foo> Lets hope there's a deb of 3.3 somewhere
<idx_foo> So in other words Ubuntu's repository is rubbish
<idx_foo> Sorry about that, must have skimmed over the Eclipse req.
<Verterok> idx_foo: I don't think so :(, but installing eclipse is just unzip/untar the archive
<Verterok> idx_foo: I think all debian based distros lacks an updated eclipse
<Verterok> idx_foo: np :)
<Verterok> idx_foo: there is Bug #123064
<ubottu> Launchpad bug 123064 in eclipse "Upgrade to Eclipse 3.4.1" [Wishlist,Confirmed] https://launchpad.net/bugs/123064
<idx_foo> Any other good IDEs with bazaar integrated?
<idx_foo> For Linux that is
<Verterok> idx_foo: just download the lastest version from eclipse.org, unzip and run :)
<Verterok> idx_foo: I think gedit is integrated with bzr
<beuno> idx_foo, https://edge.launchpad.net/bzr-gedit
<beuno> hi Verterok
<Verterok> idx_foo: also, PIDA for a list of all: http://bazaar-vcs.org/IDEIntegration
<Verterok> beuno: hey there!
<idx_foo> Working fine now. Thanks for the help Verterok
<Verterok> np :)
<idx_foo> I just hope this is sufficiently different/better than svn to warrant the switch
 * Verterok invites idx_foo to file bugs as he encounter them :)
<idx_foo> But is failing miserably when installed on the wrong version of Eclipse a bug, or a deterent? :)
<Verterok> idx_foo: bzr-eclipse is under active development, but the basic workflows are covered
<Verterok> he left :p
<rockstar> jam, want to do TWiB in an hour?
<jelmer> rockstar: hi
<persia> Hi.  I've started to use bzr a lot lately, and wanted to ask about the chances of a much more stupid algorithm for pulling/pushing/merging to help speed up my use case.
<jelmer> hi persia
<jelmer> persia: what's your use case?
<persia> Hi jelmer.
<persia> I've *lots* of bandwidth (gigabit fibre ethernet to the international routers), but also lots of latency (about 150-200ms to launchpad).
<persia> For protocols like FTP and HTTP, I get to take advantage of increasing TCP windows, and get lots of packets in flight.
<persia> This means I get to use 2-3Mbps of bandwidth at that latency.
<persia> For bzr, it seems there are *lots* of little transactions, trying to save me bandwidth, but each one starts with a small TCP window, and with my latency, it makes it *very* slow.
<persia> So, what I'd like is some switch I can pass to tell bzr to be stupid, and just grab the entire repo on the other end as one big upload/download, and then process it afterwards.
<jelmer> persia: there's a lot of incremental work going on trying to reduce the number of round trips
<persia> OK.  That helps some.  Is that related to work to make it push more per trip?
<beuno> persia, one thing to make sure is that you're using packs format (you probably are if the repos are new enough)
<persia> Unless I'm downloading a few megabytes, I haven't a chance of reaching reasonable transit speeds.
<jelmer> persia: for the smart server, yes
<jelmer> persia: for FTP and HTTP a flag like the one you describe could indeed help
<jelmer> (I'm in the same situation btw, although my latency isn't as bad as yours)
<persia> Well, generally, those are just one big file.  websites that have *lots* of little files to try to make it feel faster for people with low bandwidth or low latency are slow for me though.
<beuno> persia, the core devs are almost all in australia. That puts their focus on latency quite a lot  :)
<persia> Yeah.  My combination of bandwidth and latency seems to be a corner case, and as I've spent 3 hours waiting for bzr to do stuff today, I figured I'd come by and see if I could publicise my use case to make it faster.
<beuno> the flag for bigger chunks in http/ftp does sounds interesting
<persia> Well yes, but the situation in Australia is different: nobody has much more than maybe 10Mbps there, and the undersea trunks are usually congeste.
<persia> s/.$/d./
<beuno> true
<beuno> persia, feel compelled enough to start a thread in the mailing list?
<persia> So they focus on latency, but can't take advantage of TCP windows like here or in Korea.
<persia> beuno: I could, if it's likely.  I don't know how many bzr LP users are in Japan or Korea, and I don't think this environment is common anywhere else.
<persia> Also, what's the mailing list?
<jelmer> bazaar@lists.canonical.com
<persia> OK.  Is there likely to be space in the development queue that optimising for such a situation is likely, or is it more interesting to focus on other use cases for now, and I should test again with 1.7 or 1.8 and start a thread then?
<persia> (feel free to remove any duplicate words when parsing)
<beuno> persia, speed is the main focus ATM I believe
<beuno> so this sounds entirely appropriate
<persia> OK, then adding my use case is probably worthwhile.  I'll send an email during my next pause.  Thanks :)
<beuno> :)
<pygi> hi hi
<AmanicA> I made a super cool linux startup script for loggerhead today. Do markh/beuno think I should make a branch/patch adding it to the mainline?
<beuno> AmanicA, merge proposal!
<beuno> yes  :)
<AmanicA> beuno, like in branch or like in bundle?
<beuno> AmanicA, branch
<beuno> and file a merge proposal in Launchpad
<AmanicA> beuno, atm I call the script loggerheadd  (the double dd is not a typo) and I added it to the root. is that ok?
<AmanicA> beuno: cool will do. hope I dont overhelm you guys, but I was itching a lot this week :)
<beuno> AmanicA, I'd try and name it something less confusing  :)
<beuno> and, the rest you can get from the review
<beuno> AmanicA, we *love* contributions
<AmanicA> beuno: any ideas?
<AmanicA> cool:)
<beuno> we sometimes suck on responding in a proper time frame, but we really love 'em
<beuno> AmanicA, what does the script do exactly?
<AmanicA> its a /etc/init.d script
<AmanicA> (and lots of them end in d for daemon)
<beuno> I see
<beuno> hm, tough call
<beuno> I'd say, file it as "noname", and we can go through it during the review
<AmanicA> ah, then I can tust leave it like is, and if the reviewer have a bettername, we can update it :P
<AmanicA> s/tust/just/
<beuno> sure
<AmanicA> any idea when launchpad will support stacking properly? as its a bit of overhead to upload branches for single file changes..
<beuno> AmanicA, well, it sort-of does now
<beuno> if we upgrade the loggerhead branch to 1.6 format
<beuno> you should be able to stack
<AmanicA> oh, so not ATM :(
<beuno> let's wait for mwhudson to come by, and ask him if he's cool with that
<AmanicA> no rush, I just wondered
<beuno> well, I've stacked things
<AmanicA> loggerhead is luckily small
<beuno> it has some gotchas
<beuno> but it works
<beuno> and I'd love to have more people test it
<AmanicA> I'm thinking uploading bzr branches could get hecktick
<AmanicA> bzr i.e. bzr.dev.my_fix etc.
<beuno> yeap yeap
<beuno> it's going to be very usable very soon
<AmanicA> can hardly wait:)
<blueyed> jelmer: about bzr-shell-hooks: do you think it makes sense to chdir() to the branch root, before executing the command?
<jelmer> blueyed: sure
<blueyed> jelmer: how do I get the directory from branch? (or the other way around: can you just add it? :))
<jelmer> blueyed: branch.base IIRC
<uws> wow, bzr is quite fast!
<uws> committing 2000 new files takes only a few seconds
<uws> i now use it for "scratch" version control. putting temp data in bzr, and removing .bzr once in a while if i made sure I didn't screw up :)
<blueyed> jelmer: yes. and then, I should probably not use urlutils._posix_local_path_from_url directly?!
<rockstar> jelmer, hi back (sorry, went out to eat some lunch)
<jelmer> blueyed: branch.transport.local_abspath(".") should work I think
<jelmer> rockstar: I've finished exporting the bindings of bzr-svn - https://edge.launchpad.net/subvertpy
<rockstar> jelmer, you used the name!  Yippee!
 * rockstar feels like he contributed.
<blueyed> jelmer: great, it works. I'll add that only for the "local" part, i.e. if branch gets set to "local", not when it gets set to "master".. I suppose the latter is for remote operations?!
<jelmer> blueyed: no, it's for checkouts
<blueyed> jelmer: ok, so I'll add it for both cases.. however, only when branch.transport is given. Since, on "uncommit" it isn't given..
<blueyed> the backtrace then: http://pastebin.com/m6dd9b59e
<jelmer> blueyed: try branch.bzrdir.root_transport instead
<AmanicA> sheweet, I made the loggerhead top five contributers list!   (without even trying)
<rocky> jelmer: now you just need to convert trac to use it ;)
<AmanicA> rocky: :) yup (you know Ive made a gforge plugin which uses)
<AmanicA> it
<rocky> AmanicA: hmmm?
<AmanicA> neveermind
<blueyed> jelmer: works better. now I'm wondering why 'pre_commit = sh -c "echo \$4 > blogs/inc/_revision.inc.php"' results in 'bzr: ERROR: [Errno 2] No such file or directory'.. something simple like "echo" works..
<jelmer> rocky: it can already do that through trac-bzr and bzr-svn ;-)
<rocky> boo =P
<jelmer> blueyed: not sure if that escaping will work ok
<blueyed> jelmer: ok, that's a problem with subprocess.call, which uses the whole command as-is (and it does not exist), would have to pass ["sh", "-c", "..."] + args
<blueyed> ..but cannot put that in the config (as list)
<blueyed> jelmer: it would work with shell=True for subprocess.call
<jam> persia: still around?
<jam> There may be a somewhat trivial hack you can do to rebalance one of our algorithms
<persia> jam: That's exactly the sort of thing I hoped was true :)
<jam> persia: bzrlib/transport/http/__init__.py
<jam> around line 344
<jam> is "recommended_page_size()"
<jam> we currently set it to 64kB
<lifeless> persia: we should be keeping one tcp connection open
<lifeless> persia: what protocol are you using?
<persia> lifeless: No idea.  I do bzr branch lp:... and bzr push lp:...
<persia> jam: SO I could just bump that to a couple megabytes, and I'd be happy?
<lifeless> persia: if you've authenticated, and you probably have both will be over bzr+ssh
<lifeless> persia: so per bzr command the windows should be expanding as normal; modulo ssh window bugs (have been before, bet there will be again)
<lifeless> persia: if you're running lots of commands, try setting up a master control connection which may help the windows expand
<persia> lifeless: OK.  Then my guess at the cause is probably wrong.  Still takes *way* longer than it ought, and I thought my situation might be odd enough that a hack would help, when it wouldn't help others.
<lifeless> persia: it may be right; gather some stats:P
<persia> No, I don't run lots of commands.  I branch.  I push.  I forget about it.  A few days later, I delete the cruft.
<lifeless> persia: I'm simply noting that we won't, per-command, be connecting many many times; 2 perhaps - directory lookup + ssh for data
<persia> lifeless: That's all?  Which version of bzr?  (I use 1.3)
<lifeless> persia: should be any for this use case
<persia> lifeless: OK.  Thanks.  I'll try jam's hack anyway, and see if it helps me.  Maybe I'm just confused.
<jam> persia: well depends how you are connecting. my change won't effect bzr+ssh (as it only effects http)
<persia> Oh, and I'm probably usually using bzr+ssh.  Oh well.
<jam> You might set the one in "bzrlib/transport/remote.py" though
<lifeless> or you could try out a btree repo :P
<jam> lifeless: I think btree would actually exacerbate his specific problem, as it doesn't have the concept of minimum request size
<jam> we haven't hooked in recommended_page_size() handling
<jam> though I think we could do so at logical-block partitions in the Btree index code
<jelmer> is there some way to peek at the smart server commands?
<jam> which avoids some of the inefficiencies in our current system
<lifeless> jam: I don't think he's identified the problem, just assumed that his network configuration implied a specific issue
<jelmer> wireshark doesn't work so well at ssh connections?
<jam> jelmer: -Dhpss ?
<jam> gives a log of every request
<jelmer> jam: ah, thanks
<lifeless> jam: and as such, any test that expands our knowledge is helpful
<jelmer> yeah, the number of roundtrips with hpss is really bad :-(
<lifeless> jam: specifically, btree does less roundtrips often just cause of the better fan-out
<persia> If someone wants to prepare a test script that does stuff, I'm happy to run it against either hardy or intrepid, and return the results.  On the other hand, I don't understand most of the recent conversation, so wouldn't know how to produce useful test results.
<jelmer> it's the limiting factor for me, git seems CPU-bound
<jelmer> at least this explains why bzr-svn is faster than bzr+ssh for me
<jelmer> bbl
<lifeless> persia: don't worry about it; we are testing on high latency stuff at the moment
<uws> sftp:// feels faster than bzr+ssh:// for me even
<uws> (no numbers to confirm/deny this)
<uws> perhaps it's the overhead of starting a python process on my rather slow server
<persia> lifeless: OK.  I just fear you're not going to notice throttling with the congestion in the cables down there :)
<lifeless> uws: could well be
<jam> uws: I know spiv just introduced a patch which patches a hole in the bzr+ssh case for push and pull
<jam> basically, while we are inspecting,sftp/http will download some searching for things that aren't there and cache it
<jam> bzr+ssh just returns an empty response
<uws> jam: care to elaborate on what "patches a hole" means?
<jam> uws: "fixes an edge case" ?
<uws> oh, I thought "avoid the bzr startup overhead" :)
<jam> so for push/pull we have to find out what each side doesn't have
<jam> I guess for bzr+ssh if you have 50 new revisions it may actually send 50 requests and not get anything before it starts finding info
<jam> while for http and sftp it will be filling in info about the indexes during that time
<jam> which makes future correspondence faster
<uws> mkay.
<jam> basically, you can get 50 round trips with bzr+ssh that don't actually transmit any info
<jam> which is a bit naughty
<uws> ah, ok.
<jam> well, they transmit1 bit of info
<jam> "not there"
<jam> rather than 64kB of "not there yet, but here is some other info"
<jam> I take it back, I reviewed it, but it hasn't landed yet
<jam> lifeless: I'll note that Index *bandwidth* is the number one issue right now for me doing "bzr up" in my bzr.dev branch.
<jam> (this is specific to my case)
<jam> I haven't nailed down all the reasons yet
<jam> but I have the feeling we have non-clustered revsion-ids
<jam> like "john@" and "pqm@"
<jam> so it has to bisect a lot of the index, and it interacts in poor ways with the page expanding algorithm
<lifeless> jam: right
<jam> right now, if you make a request for 100-200, it expands to 100-64100
<jam> but then if you request 50-100, it expands to 50-64050
<jam> I'm thinking to not worry about it for GI, and just work on it a bit with the btree code
<lifeless> jam: for sure
<jam> But it means the expansion needs to occur at the index layer, rather than the Transport layer
<lifeless> jam: having figured out that GI couldn't be really fixed without disk changes, I'm not going to touch it again; it will just throw something else out to do so
<blueyed> I want to have the revision/revno in a textfile inside the branch and tried the pre_commit hook for this, but the changed file gets not committed. Is this possible after all? (or would I need to do this during deployment and keep it out of the branch)
<jam> blueyed: there is a "start_commit" hook which you could use, but you won't have the revision_id
<jam> (I think)
<jam> I don't know that there is a way to commit a file with the text of the revision_id to come
<jam> it is possible in bzr's structure, but I don't think we expose a hook at the right time for it.
<lifeless> and we shouldn't
<blueyed> jam: start_commit isn't defined with the shell_hooks plugin
<lifeless> its incompatible with the minimal contract for foreign branch commit support
<jam> lifeless: I agree that not all foreign formats could support it. I don't think that should absolutely prevent us from doing it
<lifeless> jam: it should at a minimum make us question very hard
<lifeless> jam: I don't think its a good idea regardless of foreign formats
<jam> it is similar in concept to $Keyword$ expansion, and has similar benefits and drawbacks
<blueyed> lifeless: it would be really handy to provide a $app_revision variable (that's what I was trying to do), or add a suffix like "rXX" to a version number.
<jam> I think some people would rather get extra conflicts at certain times
<jam> than not have the ability at all
<jam> blueyed: you can always run "bzr version-info > my_file.txt" as part of a "build" process
<jam> which is certainly the recommended way to do it
<blueyed> jam: yes, I know.. that's what I've meant with "deploying".. it's a php app after all and there's no "build" process (and also no "deploying" currently).
 * spiv hops on a train
<lifeless> blueyed: doing that on tree building - checkout/pull - is much more reliable
<blueyed> yes, I see. Thanks.
<jam> blueyed: have you looked into what "bzr upload" supports? I haven't poked into that code, but it may be a good place to hook in that sort of work
<blueyed> jam: well, I can see no hooks, but it creates a file .bzr-upload.revid, which could be used probably
<jam> I'll also mention it is probably easier to get code into a plugin
<jam> As it has a smaller system-wide effect
<blueyed> sure. It was only a nice-to-have idea, no problem.. :)
<beuno> blueyed, it does have a tip-change hook to auto-upload
<beuno> provided by james_w in a patch  ;)
<jam> blueyed: And on that note, you could use the "post-branch-tip-changed" hook to generate the file after commit
<jam> but then the file isn't versioned.
<blueyed> beuno: well, looked in the released version (Intrepid) only.. but found it now.. that's different however (and it's hooking, not being hooked AFAICS).. but I get the idea, that a post-upload hook might get added to the plugin. However, the hidden file would be enough in my case
<beuno> blueyed, it's in intrepid???  :)
<blueyed> yes.. as with pre_commit.. that would be the whole idea however (and is why the upload plugin does not fit really).. I'm fine with it after all..
<blueyed> beuno: yes, 0.1.0~bzr44-1
<beuno> oh, very cool!
<beuno> I didn't know
<jam> lifeless: it seems when you landed the btree format repository into bzr.dev, we lost the "convert indexes in place" code.
<jam> which is a bit of a shame, as it makes it more difficult to set up a test repository
<jam> does the code in the plugin still work?
<lifeless> jam: the plugin code needs some adjustments, to use bzr's index logic etc
<lifeless> jam: the reason I didn't port that code across is that for gc its not helpful; and I don't plan on suggesting that dev2 become a production format ever
<jam> lifeless: sure, it just makes my life easier when trying to test stuff out :)
<jam> I'm hacking around it now with a script
<lifeless> back shortly, fooding
#bzr 2008-10-03
<poolie> jam, hi
<poolie> and lifeless
<poolie> jam, want to talk?
<jam> isn't it standup time?
<spiv> https://bugs.edge.launchpad.net/bzr/+bug/230902
<ubottu> Launchpad bug 230902 in bzr "BzrError: Must end write group before releasing write lock on KnitPackRepository" [High,Confirmed]
<lifeless> spiv: un
<lifeless> spiv: fun
<poolie> jam, nicely done with setup.py, but it should be in news too
<spiv> jam: I just realised there's a problem with my batching patch; mail sent.
<lifeless> spiv: btw I think your batching should apply to all repos
<lifeless> spiv: there is no reason to special case it for remote
<lifeless> IMNSHO
<spiv> lifeless: Hmm.
<spiv> lifeless: I think it would penalise plain pack repos.
<lifeless> spiv: index lookups for 5 keys are more efficient than 5 lookups for 1 key
<lifeless> spiv: with both GI and BTGI
<spiv> lifeless: e.g. if there's only one new revision, then asking about 50 revisions will cause extra work for no benefit.  And doing it one-by-one with plain packs isn't so bad because it's filling the caches of the indexes AIUI.
<spiv> What's GI/BTGI?
<lifeless> spiv: tell you what; test it :)
<lifeless> graphindex btreegraphindex
<spiv> Ah ok.
<lifeless> kiko: why have you moved the download instructions lower on the front page?
<lifeless> kiko: they used to be lower and we moved them to the top based on feedback from users of the web site
<kiko> lifeless, because I had to scroll to read what it was.
<lifeless> kiko: yes, thats the tradeoff we made
<kiko> a bad one. but it's fixed now.
<lifeless> kiko: another one, and this one matters more, is why you've just moved the toc to the bottom of the workflows page
<lifeless> its entirely useless there
<kiko-zzz> lifeless, yeah, maybe we should just remove that ToC entirely, I'm not sure
<lifeless> kiko-zzz: its a long page, I think it needs a toc
<kiko-zzz> yeah.. ok
<kiko-zzz> I wish we could at least float the damn toc or something
<kiko-zzz> but it would fight with the sidebar
<lifeless> just put it under the intro
<lifeless> right before solo
<kiko-zzz> that page is a bit of a mess
<lifeless> thanks for putting the toc back
<kiko-zzz> the images should be like 1/3rd of the size
<kiko-zzz> maybe tomorrow
<lifeless> I'm not sure the welcome page is better; but I let others worry about that
<kiko-zzz> I'm absolutely sure it's better, luckily
<kiko-zzz> man who do I have to kill to get some food in this office
<lifeless> kiko-zzz: you just reminded very strongly of linus
<lifeless> absolute confidence, and yet, still wrong
<kiko-zzz> at least I get it done
<kiko-zzz> now get out of my way :)
<jml> lifeless: for a minute there I was thinking you meant the Peanuts character.
<lifeless> jml: perhaps I was
<jml> lifeless: it doesn't gel.
<lifeless> jml: ah, then perhaps I wasn't
<poolie> kiko-zzz, maybe we should really split the wiki from the web site
<poolie> it's hard to make it look slick in moin
<kiko-zzz> yeah, it's an idea. for now I think it's okay but it needs a facelift for december
<kiko-zzz> maybe just a moin facelift, but maybe something more nicer
<lifeless> what happens in december?
<poolie> the end of the year :)
<kiko-zzz> xmas
<kiko-zzz> gifts
<kiko-zzz> vacations
<kiko-zzz> god's last 3 gifts to mankind
<poolie> 'myrrh... how nice!'
<poolie> makes a change from socks
<poolie> lifeless, more seriously i think kiko was wanting us to have something exciting and public happen before then
<poolie> repostiory stuff will be exciting, but maybe not ready for wide use
<markh> "tests suite passes on all major platforms" would possibly qualify as exciting and public :)
<poolie> that is pretty exciting
<poolie> is that true on windows at the moment, or not quite?
<markh> will be exciting :)  No movement on the LockContentionErrors AFAIK
<markh> I need guidance on how to handle them before I can progress on it
<markh> s/handle/silence/whatever/
<lifeless> implement dirstatev2, new tree format, then silence the existing one
<lifeless> or v4 or whatever the signature would reach
<poolie> someone else had a problem with file locking on a mac the other day
<markh> oh, I didn't think it was *that* easy! ;)
<poolie> eventually we need to get away from that
<lifeless> well I mailed the list with a proposal
<poolie> not to say we can't take a smaller step first
<lifeless> the responses seemed to vary
<markh> tests are too noisy on windows so regressions will not be noticed.  Silencing the test noise is IMO more important than fixing the implementation
<markh> and presumably easier
<poolie> markh, did you get my pm?
<lifeless> markh: given that tests fail because of the implementation, I really can't agree
<markh> lifeless: my concern is that regressions completely unrelated to the *known* problem of locks will be hit
<markh> and experience shows that *has* happened in the past - regression have been introduced that the tests *did* see, but got lost in the noise
<markh> that IMO is worse than what we already know is bad about locks on windows
<lifeless> markh: selftest -v | grep 'FAILURE|ERROR'
<lifeless> markh: then do that and diff, if there are + lines, its new failures
<markh> lifeless: who are you saying should do that regularly?
<markh> it wasn't me that introduced the regressions I'm talking about
<lifeless> whoever is doing release related stuff on windows; before the release
<markh> well - the end result is we end up in a catch 22 - wont fix tests until we fix the impl, impl is very hard to fix, especially on windows, as tests are too noisy to see what regressions you introduced :)
<markh> but - I'm not interested in arguing this
<markh> I just suggested it might be good public info to work towards and announce
<markh> take it or leave it :)
<markh> I'm interested in helping fix tests - but have no time to help with a dirstate impl
<lifeless> markh: I don't get the catch-22, but perhaps I just have a different understanding on how the tests fit together
<markh> lifeless: i think if the situation was reversed, and we had massive linux test failures due to an implementation problem, I doubt your solutions would fly - either the "live with it or provide a new impl" position or the "live with it and use grep to detect regressions" position.
<poolie> hm
 * jml emulates looms with branches
<poolie> > Silencing the test noise is IMO more important than fixing the implementation
<poolie> i mostly agree, getting to a known reliable state is a good first step
<markh> We *know* all about the lock problems.  We *don't* know about new regressions
<poolie> right
<markh> bbiab
<lifeless> markh: actually, I use the diff approach when I'm dealing with horribly broken branches, which happen when I do some of the heavy lifting I do regularly
<lifeless> markh: if I was a windows dev, I would be hacking on the tweaked implementation at top speed because that would permanently fix this issue
<lifeless> markh: but I'm not a windows dev, so even if wrote a new impl for you (which really is quite small, ~500 lines totall diff I think) I couldn't be sure it had fixed things for windows
<lifeless> markh: you seem to feel I'm not helping, so I'll drop it
<lifeless> poolie: silencing the test noise doesn't get us a known reliable state
<poolie> ok i'm going to look at this usertest thing with spiv
<lifeless> I thought someone wrote a stats gatherer that determines by annotate the contributors to the code base
<lifeless> (rather than commit cout, which is... crude)
<spiv> lifeless: maybe abentley did?
<jml> ooh, fancy: "You can restore the old tip by running:..."
<lifeless> poolie: bzr 1.8. branch created
<teratorn> anyone alive that knows about bzr-svn internals? got a bug that I wouldn't mind talking about: https://bugs.launchpad.net/bzr/+bug/277369
<ubottu> Launchpad bug 277369 in bzr-svn "Push to SVN: exceptions.AttributeError: children" [Undecided,Fix released]
<jelmer> teratorn, Yeah, I just closed that one, it's already fixed
<teratorn> jelmer: oh wow that rocks
<teratorn> jelmer: in trunk?
<jelmer> teratorn, Not exactly sure what version, 0.4.13 for sur ehas the fix
<teratorn> oh, heh. well I just commented on the bug after having upgraded to the latest release
<poolie> nicely done
<teratorn> I mean, it still crashes :)
<jelmer> teratorn, You'll probably have to repush the other revisions as well
<jelmer> teratorn, since the error would actually be in there
<teratorn> jelmer: hmm, how would I do that?
<jelmer> teratorn, the easiest way is to remove the revisions manually from svn
<jelmer> teratorn, that requires administration access to it though
 * jelmer gets some sleep
<teratorn> I didn't even know that was possible, with SVN
<abentley> spiv: wisnae me.
<gimmal> hey folks. having trouble installing bzr-xmloutput plugin. 'bzr plugins' gives me this: Unable to load plugin 'xmloutput' from '/usr/lib/python2.4/site-packages/bzrlib/plugins' # so how do I find out why it can't load the thing?
<gimmal> fwiw, it's being installed for sake of bzr + eclipse eclipse plugin
<markh> gimmal: check out .bzr.log - executing 'bzr version' will tell you where it is
<gimmal> ok. thank you
<markh> probably in ~
<gimmal> yeah
<gimmal> hey do y'all have a minute to look at a paste? I'm no python student as of yet ... heh
<gimmal> it boils down to this in the traceback: TypeError: __init__() got an unexpected keyword argument 'short_name'
<gimmal> which is in the traceback, listed after this: File "/usr/lib/python2.4/site-packages/bzrlib/plugins/xmloutput/__init__.py", line 108, in cmd_xmlstatus
<gimmal>     short_name='V'), # any ideas?
<gimmal> bzr version mismatch?
<markh> that would be my guess
<gimmal> ok; could be simple to fix, thanks
<gimmal> simple, muahahah ... so i just start virtualbox, copy my /etc/apt/soruces.list to a vfat partition, move my hdd to the gateway laptop (where bzr is, and where eclipse is installed), then use gnome-terminal via an xming (xserver for vista) session ... update the apt repo on that comp, install the bzr deb from backports.org, then start eclipse (via gnome-terminal via xming) again ... pretty simple, yeah, just involving a lot of steps...
<gimmal> the hdd is a portable, duhuhuhehe
<gimmal> if only virtualbox was booting the virtual deb image ... it's some kind of ext2 fs support in the windows env...
<gimmal> woo success ... weird wait preiod after plugging in the hdd
<vila> hi all
<gimmal> well thanks for the help
<loswillios> hey
<loswillios> I have a little problem here, bzr pull tells me to do 'bzr upgrade' to get better performance but 'bzr upgrade' says format 1 is already at the most recent format.
<loswillios> anyway to solve that, or workaround the message?
<jml> loswillios: perhaps it's the remote branch that needs to be upgraded?
<bob2> it may say that if it is an old rich-root format
<loswillios> hm.. I guess I should do a clean check out
<loswillios> jml: seems like it: even 'bzr get http://bazaar.launchpad.net/~team-mms/mms/1.1.0 mms-1.1.0' says "Format <RepositoryFormatKnit1> for http://bazaar.launchpad.net/%7Eteam-mms/mms/1.1.0/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance"
<jml> loswillios: so, if you want to work around it, you need to upgrade that branch.
<jml> loswillios: which is only something you can do if you are a member of ~team-mms
<loswillios> I'll poke the author, thanks
<_raz_> Does someone know a solution for the push/branch issue for ftp in version 1.7 (https://bugs.launchpad.net/bzr/+bug/259855)?
<ubottu> Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed]
<_raz_> looking at the 1.7 bzrdir code, the patch for it is already in, but does not resolve that issue - at least not for me
<_raz_> looking at the push result on the server, the .bzr directory and all subdirectories miss a g+x in contrast to the old behaviour
<_raz_> files accordingly lack g+r and so on
<_raz_> though this only seems to affect anything directly under .bzr, not under the directories within it
<kiorky> Uhm is that normal ,that with pyrex, i can not run 'easy_install bzr' (i go into sandbox violation)
<lifeless> kiorky: no idea, we generally recommend people use packages
<lifeless> kiorky: we have binaries for windows, macos X and most linux distros have current packages
<poolie> night all
<rocky> does bzr 1.7 run on py2.6 ?
<fullermd> I don't think so.
<fullermd> vila is doing some work on that.
<vila> bzr.dev should, but since 2.6final is not yet out, take it with a grain of salt...
<rocky> vila: 2.6 final is out =P
<rocky> jelmer: any release of bzr-svn supporting bzr 1.7 yet? or still use the 0.4 branch?
<vila> oops, since when ?
<jelmer> rocky, 0.4.13
<rocky> vila: lol, you must not read much python blogs ... it was released yesterday i think, i read about 50 blog posts about it ;)
<rocky> jelmer: awesome, thanks
<rocky> will test it out
<fullermd> vila: See what you miss when you sleep?   :p
<vila> rocky: anyway, you're welcome to test it and report any problems, but the test suite is passing (modulo a very minor/cosmetic error)
<vila> fullermd: damn, I knew it !
<vila> fullermd: I'm still wondering when *you* sleep though :)
<fullermd> I'll get all the sleep I need when I'm dead   ;)
<jelmer> hmm, no python 2.6 in debian yet :-(
<fullermd> Debian?  Do they even know there's a python 2.4 yet?
<rocky> lol
 * rocky just finished building python2.6 on his ubuntu
<rocky> jelmer: when i "bzr co https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk ClueMapper-trunk" (you can do this too, it's an anonymous svn repo) at around rev 82 it slows down *big* time ... bzr 1.7.1 + bzr-svn 0.4.13 + svn 1.5.1
<jelmer> rocky, svn rev 82?
<rocky> i guess, i'm watching the status bar
<rocky> it gets to 82/156 and slows down (it's at 87 right now)
 * rocky integrates cluemapper svn repo into jelmer's bzr-svn test cycles ... :)
<Leonidas> is it possible to manipulate a bzr branch without having a working tree?
<fullermd> Depends on what manipulation you want to perform.
<Odd_Bloke> Leonidas: It depends what you mean by 'manip... yeah.
<Leonidas> jelmer: python 2.6 is probably not going into debian anytime soon - freeze.
<Leonidas> fullermd: add files, commit stuff.
<Odd_Bloke> Leonidas: It could go into experimental.
<Odd_Bloke> Oh, wait, it'd be a separate package, it could go into unstable. >.<
<fullermd> Well, no, since that would be manipulating a working tree.
<Leonidas> Odd_Bloke: yeah, thats possible
<jelmer> Leonidas, I run experimental
<Leonidas> fullermd: ok, thanks.
 * Leonidas runs testing and stable and backports important stuff.
<fullermd> (of course, if you dug into bzrlib, you could pretend to have a working tree in some ways, but then you sorta HAVE a WT)
<Leonidas> (but as long as there are no packages, there's nothing to backport)
<Leonidas> fullermd: no, thats too problematic, I'll just make me a working tree.
<LarstiQ> Leonidas: those kinds of things are what a working tree is for, so no :)
<LarstiQ> Leonidas: but you need not have a working tree _on disk_, you can use a memory backed tree.
<abentley> Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those.
<Leonidas> Is there a low-level commit? I have a list of files which changed and want to commit them without creating files in the working tree.
<Leonidas> I'm trying to understand bzrlib.commit.Commit.commit() - where does it gather the changes to the WorkingTree?
<jpe> Is bzr ls --non-recursive http://url supposed to work?
<chadmiller> Hi all.  One of my co-workers is using a SVN tree converted to BZR.  In merging one tree to another, bzr complained that the files inside src/ were versioned but src itself was not.  It moved src to src.moved, and added the merging files as src/... .  I thought we worked around it by collating them with "find -exec mv" .  Now, when he's finished merging files, "bzr commit" looks like it's removing all files.  All his source files are "unknown" and "removed
<chadmiller> " at the same time.  What can he do?
<AmanicA> Leonidas: I think its in  self.builder = self.branch.get_commit_builder(self.parents, ..
<Leonidas> AmanicA: yeah, I'm now currently trying to overwrite stuff in the Commit class. Fiddling with the builder was a bit too complicated.
<AmanicA> yes
<AmanicA> I saw its a bit complicate
<AmanicA> d
<LarstiQ> chadmiller: that sounds confusing
<chadmiller> Well, we certainly are.
<AmanicA> chadmille: it sounds like the src dir was added in 2 different branches (thus 2 different file ids)
<chadmiller> -ed.  not -ing.
<chadmiller> AmanicA: I thought so.  He insists it wasn't.  The latest-common-ancestor has it, he says.
<fullermd> Well, leaving aside the "how did you get src moved in the first place", if you find -exec mv'd all the files, as far as bzr is concerned they ARE removed...
<chadmiller> We didn't "bzr rm" them or anything.
<fullermd> But they're not where it expects them.
<chadmiller> fullermd: So, it expect them in "src.moved"?
<chadmiller> Which we then "bzr mv" to "src"?
<fullermd> Sure.  That's where it put them.  I don't think your description works; the files can't be versioned while src/ is not, but if src (in the branch you merged) isn't the same as src (in your branch), you'd expect yours to end up in src.moved, and everything cascades from there.
<chadmiller> Okay.  I'll try that.
<fullermd> Mass moved like that tend to lead to wackiness down the line though.  I'd start with investigating why the src/'s are distinct.
<chadmiller> "Conflict because src is not versioned, but has versioned children.  Versioned directory."
<fullermd> That sounds like src was removed on the other branch.
<fullermd> If it were then re-add'd (instead of revert'd back into existence), that would explain why it's considered different.
<chadmiller> fullermd: Occam's razor says it is a svn conversion bug.
<fullermd> Likely.
<fullermd> So, the thing to decide is, which of the src/'s is more likely to be used going forward, and which exists in other branches you may want to merge in the future, etc.
<fullermd> Then you can decide which to keep.
<chadmiller> "bzr: ERROR: Could not move src.moved => src: src is already versioned."
<chadmiller> I'm having him "bzr mv src src.old", then "bzr mv src.moved src"
<LarstiQ> that error I'd expect when he did "bzr mv src.moved src"
<LarstiQ> without the .old step in between
<Leonidas> AmanicA: right, bzr seems to have no memoery-API, this looks like it's goingt to be painful
<LarstiQ> what?
<LarstiQ> Leonidas: did you see what abentley said? And look at how bzr-svn does things?
<Leonidas> LarstiQ: no, sorry - my bouncer has no backlog.
<Leonidas> This is a bit of a problem, I have to reconfigure it some day. or find one which is not crappy
<abentley> Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those using install_revision.
<Leonidas> abentley: ah. This sounds easier.
<Leonidas> install_revision(repository, rev, revision_tree)
<Leonidas> So after I installed the revision, I have to link it to the branch.
<abentley> Leonidas: Yes; Branch.set_last_revision_info
<Leonidas> very nice, trying this.
<chadmiller> Back next week.
<fullermd> Oh, surely there aren't THAT many files to move   :p
<chadmiller> ideas to chad@sun.com, please.
<Leonidas> I'm getting "Revision is not compatible with KnitPackRepository" when adding an empty revision (that is, it only has a revid)
<Arjen> How do I determine the commit in which a file was introduced?
<Verterok> Arjen: bzr log -l 1 --forward <the_file>
<loxs> hello, I can't find any documentation on how to setup a "smart server". could anyone help me please?
<beuno> loxs, all you need is to have bzr installed on the remote server
<beuno> and for clients to use bzr+ssh
<loxs> you mean sftp?
<beuno> no, I really mean bzr+ssh
<loxs> because for this I don't need bzr installed on the remote server
<beuno> right
<loxs> hm, then could you please explain what do you mean by bzr+ssh
<beuno> for bzr+ssh you do, because it uses the remote bzr installation to, well, be smart  :)
<beuno> loxs, sure
<beuno> you would do:  bzr branch bzr+ssh://user@host/path/to/branch
<beuno> instead of: bzr branch sftp://...
<loxs> ahamz... that sounds nice
<loxs> and how do you manage permissions? on filesystem level?
<beuno> yeap
<beuno> since you're using ssh, whatever that user has read/write access to
<loxs> I want to allow my developers commit to their own branches, but disallow them to commit to trunk. But for them to be able to commit to their branches, they need to have a write access to the .bzr in the main repository directory... is it safe?
<beuno> loxs, they can have their own branches in their home dir
<Leonidas> I need some help on this code: http://paste.pocoo.org/show/86963/
<loxs> hm, right... I can't stop thinking in svn terms... thanks for opening my eyes :)
<Leonidas> I'm currently missing two things: 1) how to generate a revid 2) how to get the proper revno
<beuno> loxs, :)
<Verterok> Leonidas: I known nothing about commit internals, but it seems that rev_id id returned by the commit_builder
<Verterok> beuno: hi
<Leonidas> Verterok: yeah, me too. but CommitBuilder does not generate it, it gets it as an argument on instantiation
<beuno> Verterok, ho
<Verterok> Leonidas: it's an argument of Commit
<Verterok> Leonidas: from the docstring: "        :param rev_id: If set, use this as the new revision id.
<Verterok>             Useful for test or import commands that need to tightly
<Verterok>             If null (default), a time/random revision id is generated."
<Verterok>             control what revisions are assigned.  If you duplicate
<Verterok>             a revision id that exists elsewhere it is your own fault.
<Verterok> apologize the big paste
<Leonidas> Verterok: I know, but I don't understand where it is being generated.
<Leonidas> Verterok: rev_id is None by default
<Leonidas> Verterok: self.rev_id is set to None in commit()
<Leonidas> but I'm missing the part where it gets generated
<Verterok> Leonidas: I think this should clarify that :) "If null (default), a time/random revision id is generated."
<Leonidas> the builder returns an id, so I suspect it generates it.
<Leonidas> Verterok: but where is the part where it gets generated in the code?
<Verterok> Leonidas: I assume in the Commit builder, beacuse if it's null, it returns a generated rev_id
<Leonidas> Verterok: repository.CommitBuilder.commit() only returns the rev_id that was passed to its constructor
<Verterok> mmm...maybe we are missing something :p
<Leonidas> Verterok: yeah, I feel stupid/blind ;)
<Verterok> Leonidas: don't feel alone :)
<jam> Leonidas, Verterok: In CommitBuilder there is _generate_revision_if_needed which calls _gen_revision_id
<jam> which is used if you don't supply a revision_id
<jam> and _generate_if_needed is called as part of CommitBuilder.__init__
<Verterok> jam: thanks!
<LaserJock> quick question, is it possible to change the committer's email address in the log?
<LaserJock> would rebase do that?
<beuno> LaserJock, you could do it with rebase, but it would break compatibility with anyone else who branched
<Leonidas> jam: thanks, gen_revision_id was what I was looking for.
<jam> LaserJock: it would be possible to do so during rebase, I don't think it specifically supportsr it
<jam> beuno: that's what rebase *does* anyway :)
<LaserJock> beuno: I don't care about anybody else ;-)
<Leonidas> jam: can you also tell me how to get the right revno?
<beuno> LaserJock, life's so much easier that way  :p
<jam> Leonidas: "right revno"? in what context
<LaserJock> beuno: I don't do anything people care about anyway :-)
<beuno> jam, you may be the right person to answer this. How can I find out what revno a revid is part of?
<jam> "is part of" ?
<LaserJock> ok, so related question, is it possible to have multiple email addresses in bzr?
<jam> you mean when it was merged?
<beuno> jam, it's merged into that revno, yes
<jam> LaserJock: you can generally set a email address per branch
<jam> beuno: "bzr log" ?
<LaserJock> jam: ah, excellent
<jam> "bzr log -r revid:XXX..-1"
<beuno> jam, right. Now, let's say I need to do that through python
<jam> beuno: you could use the output of 'bzrlib.tsort.merge_sort()'
<jam> it is what 'bzr log file' now does
<beuno> "here's a revid, give me the mainine revno it belogs to"
<jam> you can see the code in log.py
 * beuno looks
<jam> around line 603
<Leonidas> jam: In this context: http://paste.pocoo.org/show/86963/
<Leonidas> jam: line 1 is already replaced with something that is not static anymore
<jam> Leonidas: so for the "set_last_revision_info()" call?
<jam> and you aren't doing this as a commit on something else
<jam> which you know the revno?
<jam> I can give you a way, but some are easier/faster than others
<jam> for example, if you know the revno, parent_id for the parent of this commit, then it is just revno+1
<Leonidas> jam: well, I commit this on something else.
<jam> otherwise there is bzrlib.repository.get_graph().find_distance_from_null()
<jam> you can look at bzrlib/graph.py find_distance_from_null
<jam> to figure out what to pass it
<jam> generally you'll want to give it a hint about some other revision
<Leonidas> jam: actually I am now writing a converter from hg to bzr and constucting changesets.
<LaserJock> hmm, I must be doing something wrong, rebase isn't working
<beuno> jam, so I would sort the graph, and then iterate over it, until scheduled_nodes[-1][1] < merge_depth ?
<LaserJock> there's gotta be a simple way to do this. I just want to change my email address on a branch that only has 3 revisions
<Leonidas> jam: isn't revno+1 a bit too easy? The revno is this number that bzr log outputs, right? But then the revno can look something like 34.1.3 etc.
<abentley> Leonidas: A commit can never produce a dotted revno, by definition.  revno + 1 is exactly what commit does.
<Leonidas> abentley: ok, fine. Then I can just take the last revno and add 1.
<LaserJock> rebase just says there aren't any revisions to rebase :(
<abentley> Leonidas: As long as the previous revision is the lefthand parent of the new revision.  (Otherwise, you're not simulating commit.)
<LaserJock> ok, let's try this a different way. How do I go back to a previous revision?
<LaserJock> do I have to branch each revision separately?
<LarstiQ> LaserJock: that depends on what you mean with "go back to"
<LaserJock> ok, I just want to go through these 3 revisions and make a new branch from them
<LaserJock> so I was thinking if I can get back to revision 1, then copy that over and commit, then go to revision 2, copy and commit, then same for revision 3
<LaserJock> but I don't exactly know how to go back in history
<LarstiQ> LaserJock: that sounds like what rebase does, sort of
<LarstiQ> LaserJock: unless you want to use those 3 actual revisions
<LaserJock> well, I couldn't get rebase to work
<LaserJock> it just said there was nothing to rebase
<LaserJock> perhaps it's because I'm trying to rebase a whole branch
<LaserJock> man, this is really frustrating
<james_w> LaserJock: how are you running rebase?
<LaserJock> well, I've tries several things
<LaserJock> just plain bzr rebase
<james_w> also, it will still leave the original email adress as author I believe
<LaserJock> bah
<LaserJock> I also tried --onto and -r to see what that'd do
<james_w> I'd try "bzr-fast-export", edit the output, then "bzr fast-import"
<LaserJock> oh, good idea
<james_w> for rebase I'd guess rebase on to an empty branch would be what you want
<LaserJock> I couldn't
<LaserJock> it said that there was no history
<james_w> ah, ok
<LaserJock> I know it's not exactly bzr-specific but I can't  believe how hard it is just to change the email address
<james_w> well, it's designed to have immutable history
<LaserJock> right, which I suppose works, except when you want to change history
<LaserJock> :-)
<LaserJock> james_w: well, I ended just doing bzr export into 3 directories then cp the files in an commit
<Arjen> I can't get the bzr search plugin to accept multi-word multi-word strings to search for
<tacone> how space efficent bzr is for binary files ?
<tacone> let's say pictures (which normally doesn't get modified, just added or removed)
<GPHemsley> jam: Version number for 1.7.1 still says 1.7.1-rc1 (or something else with "rc" in it; I didn't look closely) in some parts of the Mac installer/upgrader
#bzr 2008-10-04
<Verterok> GPHemsley: OS X 10.4 installer?
<ferringb> anyone here use trac-bzr and been noticing some heavy memory leaks?
<chandlerc[g]> is there a way to do automatic paging of bzr commands?
<chandlerc[g]> or do i need to be less lazy about passing it to | less
<jml> lifeless: found your umbrella
<teratorn> jelmer: need any clarification on 277369? Just FYI you can catch me on IRC most of the time :)
<chandlerc> jelmer: any ideas on how to make progress on Bug #276219
<ubottu> Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219
<jml> find_branches should be a generator.
<teratorn> yield jml
<jml> never.
<jml> also, it's slow and cpu intensive
 * jml hacks on a plugin to switch from tree-and-branch repos to treeless repo and lightweight checkouts
<luks> chandlerc_[m]: 8 hours later, but if you still need it :) http://bzr.oxygene.sk/bzrbrowse.cgi/bzr-plugins/pager
 * jml is done
<jml> hmm.
<jml> cbranch seems to be taking an order of magnitude longer than branch; co --lightweight
<jml> for some reason, I am running 'bzr check' on a large repository.
 * jml learns cbranch
<jml> ... and discovers bzr cbranch --lightweight --hardlink
<jml> man, I'm going to be making branches *all the time*
 * AfC just updated a Subversion project that decided it was on [svn] revision 701629.
<AfC> 700,000 ?
<luks> kde?
<AfC> No. A small Java build tool (ish) called Ivy.
<AfC> Oh my god. The repository root is https://svn.apache.org/repos/asf , which seems to mean that bloody EVERYTHING done under the Apache umbrella is in a single Subversion repo? Gadzooks!
<jml> I've just finished a draft of a plugin that does 'bzr new-project foo trunk' that creates a shared repo in foo and a branch called trunk in it
<jml> it also does treeless repos for those crazies.
<bob2> yay
<jml> lp:~jml/+junk/bzr-establish if you are interested â very rough atm.
<jml> no warranty express or implied, all rights reserved etc etc.
<james_w> hey jml
<jml> james_w: hi
<james_w> look like you're having a productive weekend
<jml> james_w: not productive enough :)
<jml> james_w: but still kind of fun.
<jml> s/kind of//
<fullermd> AfC: Sure; it's easier to manage the universe if it's all in one place, right?   :p
 * AfC really hates the Apache community's mindset, but that's nothing new.
<Arjen> Can I easily search the history for a deletion of a file?
<fullermd> Not directly.
<fullermd> Closest thing would be to dig through log -v 'till you see it disappear.
<Arjen> Weird
<Leonidas> When I have a Inventory and bind that to Tree._inventory, how do I add files to it?
<Leonidas> I probably can add InventoryFile (& friends) to it, but I don't know how to add the contents to the InventoryFile
<Leonidas> I'm not sure whether using TreeBuilder couldn't be easier even.
<nefertum> i've pushed a local repository to a remote machine, but the rights then doesn't permit anybody except me to write in it
<nefertum> is there anyway, instead of changin with chmod, the rights for pushed repo?
<Peaker> nefertum: you want to set the repo or its container dirs to have the right group (chgrp) and possibly chmod g+s (sticky group bit) to have subdirs/subfiles inherit the right group owner
<nefertum> yes, that's
<nefertum> so i've started a main branch, and pushed in a remote machine
<nefertum> i'd like other developers to be able to push their commits
<nefertum> i can change rights by hand but it's not very elegant
<nefertum> smart
<Peaker> you only have to change them once
<Peaker> you could do so before pushing in the first place, too
<Peaker> you have to set the right group ownership
<nefertum> Peaker: but i have to do that for every branches i publish
<Peaker> nefertum: or to a single containing directory above them all
<nefertum> but when you push another branch that directory doesn't have the parent rights
<Peaker> it does, if the parent had g+s, I think
<nefertum> mmm
<nefertum> Peaker: how I set sticky group bit?
<Peaker> nefertum: chmod g+s
<nefertum> mmm
<nefertum> thanks Peaker
<tacone> hello, is it possible to create a working tree on a remote host, pulling it from a local branch ?
<tacone>  bzr branch /home/tacone/tmp/my-repo sftp://tacone@localhost/home/tacone/mybranch creates an empty directory with .bzr in it, but no other files. further pull/merge attempts in that dir will fail. am I missing something ?
<fullermd> Why would future pull attempts fail?
<fullermd> (obviously merge attempts would fail, since merge needs a WT, but that's another matter)
<fullermd> If you're in a position to merge into it (or for that matter, to pull into it) you can create the WT as needed.
<tacone> merge will fail with a error message (says checkout dir doesn't exists)
<tacone> pull doesn't fail. works, but create no file
<luke-jr_> Is there any way to get a Free bzr?
<fullermd> Well, that's all expected, since you don't have a WT there.  You can create one with checkout if you want one.
<beuno> luke-jr_, what do you mean by "free"?
<fullermd> I'll email you a free bzr for $29.95...
<luke-jr_> beuno: free as in speech
<beuno> luke-jr_, it *is* free
<tacone> luke-jr_: bzr is part of GNU
<luke-jr_> it appears bzr depends on 'cElementTree'
<luke-jr_> which is non-Free
<tacone> fullermd: isn't the branch command supposed create a working tree ?
<beuno> luke-jr_, I don't think it depends
<fullermd> Non-Free?
<beuno> maybe, optionally, for perfomance
<tacone> beuno:  it does on hardy
<tacone> Depends: libc6 (>= 2.1.3), python (>= 2.4), python (>> 2.5) | python-celementtree, python (<< 2.6), python-central (>= 0.6.1)
<luke-jr_> beuno: even the non-'c' version is non-Free IIRC
<tacone> oh well. optionally, right.
<beuno> :)
<fullermd> It's built in to python 2.5.  Only need it separately for 2.4.
<luke-jr_> fullermd: Python 2.5 is non-Free then, or it was relicensed?
<tacone> fullermd: isn't the branch command supposed to create a working tree ?
<beuno> I'm pretty sure bzr wouldn't be part of the gnu toolchain if it wasn't completely free
<fullermd> Er.  The cElementTree license is isomorphic to a 3-clause BSD license.
<fullermd> That's less involved and more "Free" (if you wish to attach such a mystic meaning to the word) than Python itself.
<luke-jr_> fullermd: the cElementTree license prohibits commercial use
<luke-jr_> or rather, prohibits sale
<tacone> ok, I just think I'll open a bug for that.
<fullermd> Oh that's the elementtree license I was looking at.
<fullermd> The PKG-INFO file in the cElementTree dist says   License: Python (MIT style)
<luke-jr_> Gentoo says it's the same license
<luke-jr_> the latest ElementTree download has the no-fee license
<luke-jr_> but also says Python in the PKG-INFO file
<luke-jr_> :/
<fullermd> What's the latest?
<luke-jr_> 1.2.7 preview
<fullermd> http://svn.effbot.org/public/tags/elementtree-1.2.7-20070827-preview/README
<luke-jr_> the 1.3 subversion repo has it as well
<fullermd> Looks the same to me.
<luke-jr_> exactly
<luke-jr_> Permission to use, copy, modify, and distribute this software and its associated documentation for any purpose __and without fee__ is hereby granted...
<fullermd> I don't think that means what you think it means.
<luke-jr_> well, I am taking it literally
<luke-jr_> he is only granting permission "without fee"
<luke-jr_> for without fee*
<fullermd> By any reading I can readily imagine, it means the same thing as the similar words in the MIT license.
<luke-jr_> whatever he meant to say, he said the permission is granted forâ¦without fee
<fullermd> "[...] for any purpose is hereby granted without fee" is linguistically identical, if perhaps clearer.
<luke-jr_> I'm not an English major nor lawyer, but that seems to have a different meaning
<fullermd> I think you're misreading it.  It would be trivial to settle with a quick email.
 * luke-jr_ emails.
<fullermd> If the "without fee" were a provision binding on the user, it would be put in the section after "provided that".
<luke-jr_> now I've hit a larger, unrelated problem: xv appears to have the same issue, but not ambiguous
<fullermd> Yeah, xv is actually shareware.
<luke-jr_> :/
<luke-jr_> open source shareware, I presume?
 * luke-jr_ ponders if he's even willing to make *that* compromise
<luke-jr_> working OpenGL will make xv useless anyway, I think
<fullermd> The README requires prior consent for distribution of modified versions.
<fullermd> I wonder from time to time if I might replace xv in my usage, but the darn thing just keeps working, and I haven't seen a good alternative anyway.
<luke-jr_> OpenGL doesn't replace it?
<fullermd> OpenGL is an API, not a program...
<luke-jr_> xv is a program?
<fullermd> OK, maybe we're talking about different xv's   :p
<luke-jr_> apparently!
<luke-jr_> I don't even care about this one
<luke-jr_> haha, oops
<fullermd> I'm talking about xv the image viewer, which has been standard issue for like 15 or 20 years.
<luke-jr_> I was talking about the 'xv' X11 extension, and confusing it with the viewer
 * luke-jr_ wonders what is depending on the xv app
<fullermd> I have no idea what would or even could.  You mean bzr is depending on it?
<luke-jr_> nope
 * fullermd is all confuzzled now.
<luke-jr_> sorry, this is unrelated to bzr now
<luke-jr_> I'm just cleaning out all non-Free cruft from my desktop
<fullermd> Anyway, Xv works well with my video card.  OpenGL, I seriously doubt near as well.
<luke-jr_> Gentoo just got ACCEPT_LICENSE so I can easily weed them out
<fullermd> Though I wouldn't think libXv had a license any different than any other component of X...
<luke-jr_> actually, X.org is a complete mishmosh of licenses supposedly
<luke-jr_> I've had to approve about 10 different ones so far
<luke-jr_> hah, found out that ElementTree's author did not coin that phrase
<luke-jr_> so he has no say as to its real meaning anyhow
<luke-jr_> that came fron font-adobe-75dpi
<luke-jr_> dev-python/imaging depended on xv btw
<tacone> done: https://bugs.launchpad.net/bzr/+bug/278303
<ubottu> Launchpad bug 278303 in bzr "bzr can't create a branch via sftp" [Undecided,New]
<fullermd> That's not really a bug...
<fullermd> branch creates a new branch, which is what it did.
<fullermd> You can't work with a WT remotely.
<tacone> I didn't know.
<fullermd> Well, that's what we have IRC here for   :)
<tacone> yes but you got somewhat distracted before, didn't you ;-)
<fullermd> A case could theoretically be made that the lack of remote WT support is bug-ish, but it'd be a hard row to hoe.
<fullermd> Well, that's ALSO what IRC is for   :p
<tacone> do you know any good bidirectional sync over ftp which doesn't require anything installed on the remote end ?
<fullermd> Over _FTP_?  I have no idea.  I spend a half hour each morning praying that FTP is really dead this time...
<luke-jr_> tacone: FTP is a security hole
<tacone> sftp
<tacone> pardon
<fullermd> I mean, wget or any of that family of stuff can sync one way or the other of course.
<luke-jr_> tacone: Subversion âº
<tacone> doesn't need to be versioned anyway.
<fullermd> I dunno if anybody's built anything in particular for SFTP like that.  Most of the time if you have sftp, you have ssh, so you can just use rsync or something (of course that requires something on the server side)
<tacone> rsync is uni-directional
<tacone> unison requires also installation on the remote end.
<fullermd> Well, you can't have "bi-directional" without versioning.  You can only have alternating uni-directional.
<tacone> right.
 * fullermd is being made highly grumpy by this merge   :(
#bzr 2008-10-05
<unenough> what's the easiest way to create an archive of my repo? or at least the latest version of it?
<jml> unenough: for what purpose?
<unenough> backup
<RAOF> unenough: bzr push sftp://mybackuphost/backup?
<AfC> Um, er, help!
 * RAOF waits for the rest :)
<AfC> I have a perfectly ordinary Subversion checkout of some upstream project. I want to use Bazaar to track the few files I care about and to shuttle my own patches back and forth. Nothing terribly unusual.
<AfC> But I just did `bzr init .` in said checkout and suddenly bzr-svn kicked off starting to do its cache update etc as if I were going to use bzr-svn to pull from Subversion!
<AfC> a) I didn't expect that
<AfC> b) I don't really want it to do that.
<AfC> So
 * AfC wonders what to do.
<RAOF> That's kinda wierd, yeah.  I dunno.
<AfC> I mean, sure I could uninstall bzr-svn, but that's a bit much.
<jml> AfC: ooh ooh, I know this
<jml> gimme a sec
<jml> AfC: bzr --builtin init .
 * AfC just did `bzr init --no-plugins .` but that's ridiculous!
<AfC> --builtin?
<AfC> That's a new one on me.
<jml> AfC: me too, I found out about it yesterday
<jml> AfC: it's in 'help global-options'
<AfC> jml: Ah. I was just searching help looking for that help page (and not finding it) :|
<AfC> FUCKING HELL.
<AfC> I just tried to `bzr add` a single file and then bzr-svn kicked off and tried to update its cache again.
<AfC> This is not a bzr-svn branch, god damn it!
<AfC> Oh, that's just right royally fucked. `bzr --builtin add filename` doesn't skip the svn plugin.
<pygi> hi hi gour
<gour> hello pygi
<gour> i'd like to fetch pinax project via bzr-svn which contains several external apps referenced in svn.externals. since i'm not at familiar with svn, I wonder if bzr-svn can do the job or am i better using svn?
<gour> it looks bzr-svn cannot handle it (yet)
<Quadduc> How do I make the "committer" field in a commit to a local branch use something other than my OS real name, user name and host?
<bob2> bzr whoami
<Quadduc> bob2: Thanks. I thought I had already done that (using --branch), but it was reset when I re-created the branch.
<Quadduc> However, the Bazaar plugin for Eclipse does not seem to respect whoami, and instead just uses my user name.
<loswillios> hey guys
<loswillios> Using bzr-1.7 I can't check out http://bazaar.launchpad.net/~team-mms/mms/1.1.0 mms-1.1.0
<loswillios> It is stalled after a while
<Peng_> loswillios: Stalled? There's no network activity or anything? Are you sure? It might just be slow.
<loswillios> Peng_: it says \ [----    ] bzr get http://bazaar.launchpad.net/~team-mms/mms/1.1.0 mms-1.1.0
<loswillios> err, \ [---    ] Transferring 0/4 for a while and then there's nothing
<bob2> the progress bar has stopped, but it is still downloading in the background
<loswillios> nope, no progress bar at all
<loswillios> just disappears and I have to kill the process
<loswillios> not even ctrl-c works
<loswillios> currently trying to reproduce on another machine which is faster
<Odd_Bloke> loswillios: Try running with -Dhttp, that'll log all HTTP activity.
<loswillios> but I left the command sitting for an hour or so
<loswillios> ok
<Odd_Bloke> loswillios: If it isn't printing to std{out,err}, then look in ~/.bzr.log
<Odd_Bloke> (-EBASHISM)
 * Odd_Bloke --> breakfast
<loswillios> ok, currently running..
<loswillios> is bzr get deprecated? I can't find it in the man page anymore
<bob2> it has always just been an alias
<loswillios> ah
<Odd_Bloke> loswillios: It's probably listed in 'bzr help branch'.
<Odd_Bloke> Right, actually to breakfast.
<bob2> nice, trying to check it out oom'd my linode
<clemente> Hi, I know how to do self.run_bzr('add hello') in a test, but I would like to translate this to bzrlib's API calls. Is there a guide which tells how to translate each operation?
<jml> clemente: no, not really.
<jml> clemente: the easiest thing to do is read the source for bzrlib/builtins.py
<jml> clemente: although, for that thing specifically, you want something like WorkingTree.open('.').add('hello')
<jml> clemente: there's also a hacking guide which might help
<clemente> jml: yes, thanks, that's a help. I also found this http://bazaar-vcs.org/Integrating_with_Bazaar , but it tells about working with real files, and not directly with revisions, commits, inventories etc.
<jml> clemente: cool.
<dwt_> Hey guys, I've got a problem with "bzr shell" from bzrtools
<dwt_> that is, it kills itself with this error message:
<dwt_> bzr: ERROR: [Errno 22] Invalid argument
<dwt_> which according to the debugger occurs here:
<dwt_> 3 dwt@dwcp ...ktive Projekte/otr-messaging/Adium-bzr % BZR_PDB=1 bzr shell
<dwt_> bzr: ERROR: [Errno 22] Invalid argument
<dwt_> **** entering debugger
<dwt_> > /Users/dwt/.bazaar/plugins/bzrtools/shell.py(105)__init__()
<dwt_> -> readline.read_history_file(self.history_file)
<dwt_> (Pdb) l
<dwt_> 100  	        ensure_config_dir_exists()
<dwt_> 101  	        self.history_file = osutils.pathjoin(config_dir(), 'shell-history')
<dwt_> 102  	        readline.set_completer_delims(string.whitespace)
<dwt_> 103  	        if os.access(self.history_file, os.R_OK) and \
<dwt_> 104  	            os.path.isfile(self.history_file):
<dwt_> 105  ->	            readline.read_history_file(self.history_file)
<dwt_> 106  	        self.cwd = os.getcwd()
<dwt_> 107  	
<dwt_> 108  	    def write_history(self):
<dwt_> 109  	        readline.write_history_file(self.history_file)
<dwt_> 110  	
<dwt_> Now I'm not sure what might cause this - self.history_file looks great
<dwt_> the fiel is there and readable too
<jml> dwt_: this happens immediately on startup?
<dwt_> (as the tests on the two previous lines should assure)
<dwt_> yes
<jml> dwt_: which version of bzr & bzrtools?
<dwt_> bzr: 1.7.1
<dwt_> bzrtools 1.7 (the latest)
<dwt_> (I just downloaded it)
<jml> dwt_: can you run the command with -Derror and paste the output to paste.ubuntu.com?
<dwt_> sure
<dwt_> http://paste.ubuntu.com/54222/
<jml> thanks
<dwt_> Do I read the debugger output right that calling readline.read_history_file() immediately bombs? (it seems to be a wrapped c-library)
<jml> yeah.
<jml> dwt_: it might be worth trying: import readline; readline.read_history_file('/whatever/the/path/is')
<dwt_> (Pdb) pp readline.read_history_file.__doc__
<dwt_> 'read_history_file([filename]) -> None\nLoad a readline history file.\nThe default filename is ~/.history.'
<dwt_> This however suggests that it is called correctly, right?
<jml> dwt_: the error is almost certainly coming from some lower level file operation
<jml> the actual Python call is correct.
<dwt_> I*'l try the readline call myself
<jml> dwt_: thanks
<dwt_> hm, when I try this in an ipython shell
<dwt_> it works perfectly
<dwt_> interestingly
<dwt_> when I try it in a normal python shell
<dwt_> it bombs
<jml> dwt_: ok, one more thing to try before I blame high solar electromagnetism
<jml> oohh
<jml> dwt_: incidentally, what's the value of self.history_file?
<dwt_> (Pdb) pp self.history_file
<dwt_> '/Users/dwt/.bazaar/shell-history'
<jml> dwt_: ok. let's try strace :)
<dwt_> oh dang
<dwt_> that would be dtrace for me
<dwt_> (mac leopard)
<dwt_> as to why ipython can do it
<jml> dwt_: I should have guessed from Adium.
<dwt_> its actually using it's own implementation of readline
<dwt_> Â¿
<jml> dwt_: so, if you can paste the last few bits of strace (or dtrace) output to the pastebin, I'd be much obliged.
<dwt_> I'l try
<dwt_> But you have to give me some minutes
<dwt_> as I'm not at all up to speed with dtrace
<jml> dwt_: with strace, it's just "strace bzr shell"
<jml> my OS X-fu is rusty, I'm afraid.
<dwt_> yeah, as far as I remember with dtrace
<dwt_> it should be "sudo dtruss bzr  shell"
<dwt_> I'm working on it. :)
<dwt_> so when I try this:
<dwt_> sudo dtruss python -c "import readline; readline.read_history_file('/Users/dwt/.bazaar/shell-history')"
<dwt_> I'm getting tons of output
<dwt_> Hope you can read it. :)
<dwt_> http://paste.ubuntu.com/54225/
<jml> are those the last lines?
<dwt_> yep
<dwt_> sigaction looks like it died from a signal, right?
<jml> well, there's a syntax error there.
<dwt_> damn
<jml> what happens when you drop the 'dtruss'
<dwt_> Just a second
<dwt_> where exactly do you means I should drop the dtruss?
<dwt_> as far as I can see I only have it in the right location
<jml> I mean, run this: sudo python -c "import readline; readline.read_history_file('/Users/dwt/.bazaar/shell-history')"
<dwt_> sudo python -c "import readline; readline.read_history_file('/Users/dwt/.bazaar/shell-history');"
<dwt_> Traceback (most recent call last):
<dwt_>   File "<string>", line 1, in <module>
<dwt_> IOError: [Errno 2] No such file or directory
<dwt_> Interesting
<dwt_> Now where's that syntax error.
<jml> so, you aren't getting the same output as when you run it as your user.
<dwt_> yes
<dwt_> interestingliy
<jml> bummer.
<dwt_> all the while the fine sits there just fine
<dwt_> 127 dwt@dwcp ~ % ll /Users/dwt/.bazaar/shell-history
<dwt_> -rw-------  1 dwt  dwt  2443  7 Aug 10:18 /Users/dwt/.bazaar/shell-history
<jml> o.O
<bob2> on HFS?
<dwt_> yes
<dwt_> do you guys get
<dwt_> why on earth its a different error message from doing this directly
<dwt_> vs. calling it via bzr shell?
<dwt_> when I do it directly it's: IOError: [Errno 2] No such file or directory
<jml> dwt_: even without the 'sudo'?
<dwt_> 1 dwt@dwcp ~ % python -c "import readline; readline.read_history_file('/Users/dwt/.bazaar/shell-history');"Traceback (most recent call last):
<dwt_>   File "<string>", line 1, in <module>
<dwt_> IOError: [Errno 2] No such file or directory
<dwt_> while with bzr I get
<dwt_> 1 dwt@dwcp ~ % bzr shell
<dwt_> bzr: ERROR: [Errno 22] Invalid argument
<bob2> no idea, but case-insensitive filesystems make me suspicous
<dwt_> Even though it seems readline is called exactly the same
<jml> bob2: good call!
<jml> dwt_: what does, python -c "open('/Users/dwt/.bazaar/shell-history')" say?
<dwt_> nothing
<jml> weird weird weird
<dwt_> dwt@dwcp ~ % python -c "print open('/Users/dwt/.bazaar/shell-history')"
<dwt_> <open file '/Users/dwt/.bazaar/shell-history', mode 'r' at 0x62458>
<dwt_> dwt@dwcp ~ % python -c "print open('/Users/dwt/.bazaar/shell-history').read()"
<dwt_> ls
<dwt_> diff
<dwt_> shell open AnimatedGrid.xcodeproj/
<dwt_> help shell
<dwt_> open AnimatedGrid.xcodeproj/
<dwt_> exit
<dwt_> diff
<dwt_> ci  -m  "added a new provider and refactored the storage model to use a two dimensional array"
<dwt_> push
<dwt_> help push
<dwt_> bzr info
<dwt_> bzr push parent
<dwt_> bzr st
<dwt_> ls
<dwt_> ls parent/
<jml> yeah, we don't need it all :)
<dwt_> ...
<dwt_> I don't get this
<bob2> python -c "import os ; print os.listdir('/Users/')"
<dwt_> dwt@dwcp ~ % python -c "import os ; print os.listdir('/Users/')"
<dwt_> ['.localized', 'dwt', 'Shared']
<dwt_> I mean what can be the reason for this?
<dwt_> the path is as case-perfect as it can be
<dwt_> its also there
<dwt_> the file is readable
<dwt_> but still libreadline does not like it
<dwt_> at all.
<dwt_> maybe I should try write a c-program that does the same thing
<dwt_> and see if that fails
<dwt_> I am considering just rm-ing the history file
<jml> dwt_: at the least, I think you should file a bug against bzrtools
<jml> dwt_: well, try moving it out of the way first
<dwt_> I'l do
<dwt_> well, moving it out of the way
<dwt_> seems to allow me to invoke the shell again
<jml> (the bug should include the -Derror traceback, the python -c 'import readline; ... '  error, the ls -l command and the python -c 'print open(...)')
<jml> dwt_: hmm
<jml> dwt_: I am perplexed!
<dwt_> reinvoking the shell also works
<dwt_> with history support
<jml> hmm.
<dwt_> one interesting difference
<dwt_> the newly created file starts with this line:
<dwt_> _HiStOrY_V2_
<dwt_> while the old one doesn't
<jml> dwt_: I wonder... have you upgraded Python recently?
<dwt_> not that I can think of
<dwt_> ha
<dwt_> prepending the _HiStOrY_V2_ to the old file
<dwt_> makes it load again
<dwt_> so that's the reason
<jml> that sounds like either corruption or version incompatibility
<dwt_> well, I can try to check my backups
<dwt_> but I guess that it was never there
<dwt_> I did update bzr recently
<dwt_> not python
<jml> dwt_: what about OS X? Had leopard for a while?
<dwt_> yep
<dwt_> the last update was from 10.5.4 to 10.5.5
<dwt_> that might have caried a python update of sorts
<dwt_> I didn't however remember to read that in the release notes
<jml> or a libreadline update...
<dwt_> then again, apple is known to be sloppy at this stuff
<dwt_> yep
<dwt_> neither anything about libreadline
<jml> hmm.
<dwt_> so, should I file a bug still?
<jml> dwt_: no, probably not.
<dwt_> ok...
<jml> dwt_: I'll mention it to abentley when I next speak with him
<dwt_> super
<jml> (or he'll see his name in his IRC logs!)
<dwt_> I mean, its just a prepend of "_HiStOrY_V2_"
<dwt_> and everything works again.
<dwt_> (strange though)
<dwt_> ok, thanks a lot for your help
<jml> http://osdir.com/ml/lang.r.mac/2005-09/msg00031.html
<jml> we aren't the only ones :)
<dwt_> great
<dwt_> so they stumped it.
<dwt_> Ah well
<dwt_> on with the real hacking. :)
<dwt_> Thanks again
<tretle> how do I change the email address associated with bzr whoami?
<bob2> bzr whoami "Your Name <your@example.org>"
<tretle> thanks
<aidos> hi everyone. I 've had recently a pretty weird behaviour from bzr, after a merge, one of the revision had been "skipped", I had it in the history but none of the modifications had been applied
<bob2> can you see it in the output of 'bzr log'?
<aidos> yes
<bob2> perhaps a later revision undid it
<aidos> it's what i thought, but none of the following revisions modified the files that should have bee reverted
<aidos> ...that should have been reverted for that behaviour to be normal
<aidos> any ideas?
<bob2> have a look at the 'bzr blame affectedfile' output
<asabil> hi all
<asabil> who is actually working on bzr-git ?
<clemente> asabil: you can see it in the log; the most active seems to be jelmer
<asabil> clemente: oh ok thanks
<asabil> jelmer: ping ?
<jelmer> asabil, hi
<asabil> hi jelmer, could you please take a look at my bzr-git fixes branch ?
<jelmer> asabil, thanks, emrged
<asabil> :)
<clemente> How can I tell Bundle Buggy that a patch has been superseded by another?
<jelmer> clemente: click "Superseded"
<clemente> jelmer: I suppose I need an account for that
<jelmer> clemente: ah, could be
<jelmer> clemente: it will also mark patches as superseded if the new bundle includes a superset of revisions of the old one IIRC
<clemente> jelmer: yes, but in my case it didn't work, because I took my own bundle, merged it in another branch, and commited it again. Only to have the same tree in other computer
<clemente> maybe there are better ways to copy revisions which can preserve history
<clemente> (Revision history, but whatever Bundle Buggy is tracking)
<thrope_> how can I get bzr log to show the files affected by each revision?
<jelmer> thrope_: bzr log -v
<thrope_> also if I do -r-5..-1 on a file that hasnt had a change in those revisions there isn't any output - what options should I use to get the last 5 revisions of that file
<thrope_> jelmer: right - sorry I don't know I missed that in the help
<thrope_> *how
<Peng_> thrope_: "bzr log -l 5 some_file"?
<LarstiQ> thrope_: --limit
<thrope_> oh right - thanks
<thrope_> trouble is when I use it with --forward I get the first 5 instead of the last 5
<LarstiQ> makes sense to me
<thrope_> so how I can I get the last 5 revisions of a file in --forward order
<thrope_> I'm trying to find an alias for a screenfull of revisions with the most recent at the bottom
<LarstiQ> thrope_: you could do something like jam's shortlog plugin
<thrope_> what is that?
<LarstiQ> hmm, can't seem to find it right now
<jelmer> wasn't shortlog from uws?
<LarstiQ> jelmer: that's lastlog
<jelmer> ah
<LarstiQ> which also might be useful
<LarstiQ> thrope_: a custom logformatter
<thrope_> ah I tried googling but I think shortlog is too general a term
<uws> yeah, "bzr lastlog" is mine
<uws> trivial plugin but very useful for me
<uws> note that you can do roughly the same with aliases in ~/.bazaar/bazaar.conf
<uws> [ALIASES]    last = log -r -10:-1 --forward --short          # for example
<uws> only difference is that my plugin handles branches with < 10 revisions correctly
<uws> and that you can give the number on the command line (e.g. bzr lastlog 5)
 * uws gone now
#bzr 2009-09-28
<igc> morning
<Peng_> Good morning. :)
<verterok> jfroy: pong
<jfroy> verterok: just wanted to let you know I had pushed my packaging stuff
<verterok> jfroy: cool :)
<jfroy> it's kind of a half-baked solution.
<jfroy> it will stage the various packages and plug-ins into independent "destination roots" that make it easy to build the distribution using Package Maker.
<jfroy> The next step is to build the Package Maker document, or at least update the content files.
<verterok> jfroy: I'm quite curious about this way of building the installer, as the weak point of my scrits is that I need to manually edit the pmproj/pmdoc
<jfroy> same deal
<verterok> jfroy: oh, :(
<jfroy> I started building a PackageMakerDocument class in the script
<jfroy> but it's not quite done
<jfroy> I'll try to work on it when I have some free time.
<verterok> jfroy: well at least in the case of .pmdoc it might be possible to do that from the script, as it's a bunch of xml's in a dir :) ,right?
<jfroy> yep, that's the plan
<verterok> jfroy: did you checkedout the branch I talked about in the mails?
<jfroy> yes3
<jfroy> I picked the installer background from it :p
<verterok> :)
<verterok> jfroy: we should unify this into a single branch ;)
<jfroy> yeah
<verterok> jfroy: please..url of your branch? (/me is imIn the branch there is a lot of stuff to download depedencies, plugins, etc and build the packages, docs, and also to generate the DMG.)
<verterok> Looks like you know a thing or two about building installer ;)
<verterok> It would be great if you can include this way of building it as part of the scripts included in https://code.launchpad.net/~verterok/bzr/OSX-10.4-dmg so we finally get an automated way to build thins.
<verterok> oops, sorry
<verterok> cliboard failure :(
<jfroy> lp:~jeanfrancois.roy/+junk/SnowLeopard-package
<verterok> jfroy: please..url of your branch? (/me is impatiante) :)
<verterok> jfroy: thanks
<verterok> jfroy: the PackageMakerDocument it's quite cool
<jfroy> and very much not done :p
<verterok> jfroy: yes, but it's a start
<jfroy> it shouldn't be too hard though to finish
<jfroy> although there are some complexities to deal with, well special cases really
<jfroy> My package has a custom requirement on bzr-svn such that bzr-svn is disabled if subvertpy is disabled
<jfroy> need to figure out a nice way to put that in place
<verterok> jfroy: I just read your mail. both solutions are quite similar from 1000ft, mine using bdist_mpkg and generating the doc.
<jfroy> yeah
<jfroy> though I produce a more "modern" single-file package
<verterok> jfroy: I;d like to remove the dependency on bdist_mpkg as it forces me to patch each plugin setup.py in the build process
<jfroy> yeah, for plug-ins I don't "install" them
<jfroy> I just stage them inside bzrlib
<jfroy> and run build_ext --in-place on them
<lifeless> I have a patch for bzr
<lifeless> back on bundle buggy
<lifeless> which bundles many plugins
<lifeless> the reason its not merged
<lifeless> is that it doesn't run build_ext --in-place on them nor install them when setup.py install is called.
 * lifeless would love to see someone pick that up and run with it
<verterok> jfroy: I'll try to use your scripts to build the Leopard and Tiger installers
<jfroy> ok
<verterok> jfroy: and possibly include the download script from my branch ;)
<jfroy> yes, that would be a nice combo
<verterok> jfroy: so, regarding ian comments, it's ok with you about labeling your installer as a core-installer? (I'll try to build a matching installer for Leopard and Tiger)
<verterok> jfroy: and also build the 'desktop' version for them too
<jfroy> yes it's fine I think
<jfroy> since I don't include any GUI-related plug-ins.
<verterok> jfroy: ok, cool :)
<jfroy> In any case, I think it's useless to offer qbzr and bzr-explorer if you're not going to also bundle Qt and py-qt
<jfroy> It's like "here's a super nice car, but we won't give you the engine. Go build one yourself."
<verterok> jfroy: it might be, I don't really know
<verterok> jfroy: I'll packaging pyqt with your approach
<verterok> jfroy: don't know about QT, installing it is quite easy
<jfroy> Qt is OK.
<jfroy> If you bundle PyQT that would make it all pretty easy.
<jfroy> oh one particular thing
<jfroy> we should refactor the compiler to use based on the system version and store it as a Builder class attribute or something.
<jfroy> We want gcc 4.0 on 10.4, gcc 4.2 on 10.5 and llvm-gcc-4.2 on 10.6 :/
<verterok> jfroy: ok, I'll take a look to this compiler thing :)
<verterok> thanks
<jfroy> verterok: I've pushed an updated readme that addresses Ian's feedback.
<verterok> jfroy: ok, thanks
<jfroy> fixing the compiler thing now
<verterok> jfroy: I was thinking about that, we can check which compiler to use at runtime ;)
<jfroy> and fixed
<jfroy> (and pushed)
<jfroy> whoa, or not
<jfroy> oh, duh
<jfroy> hate you mac_ver()
<verterok> jfroy: I'm using bdist_mpkg to do that in my scripts: "from bdist_mpkg import tools; osx_version = '.'.join(map(str, tools.sw_vers().version[:2]))"
<lifeless> igc: on the wiki
<lifeless> igc: perhaps we should say 'every 6 months, with beta releases available every month'
<igc> lifeless: yep, that's better
<jfroy> OK fix pushed :p
<jfroy> yeah, I wasn't casting to ints and using ints in my branch :p
<lifeless> igc: are you still editing [in which case can you do it], or should I make the change?
<igc> lifeless: you can do it - I'm not editing
<verterok> jfroy: cool, thx
<jfroy> strange
<jfroy> it's not using llvm for linking...
<jfroy> Do you need to set more than CC?
<verterok> jfroy: no idea :)
<jfroy> and yes you do, LDSHARED :/
<jfroy> bah
<jfroy> or not?
<jfroy> weird, nm
<igc> jfroy, verterok: great to see you guys chatting about this stuff! While it's desirable in the medium term, I don't think we're ready to combine the Windows and Mac installers into one project yet ...
<jfroy> huh, we didn't propose that?
<igc> jfroy, verterok: so maybe one of you should create a project called bzr-mac-packaging and put your combined branch there
<verterok> igc: agreed
<igc> jfroy: no, jam suggested it on the mailing list
<jfroy> oh, well, it doesn't make sense?
<igc> jfroy: so plugin authors like jelmer had one project to update after releasing a new bzr-svn say
<jfroy> it's not their responsibility IMO
<jfroy> they should just announce new releases on the mailing list
<jfroy> package maintainers can pick them up when appropriate
<verterok> igc: once I merge both branches, actualle jfroy branch + some utilities from my branch, I'll push it and create the project
<igc> jfroy: that would work as well. The trick is getting the right combo of bzr-svn+subvertpy+bzr-rewrite and we'd prefer jelmer to own updating that for the Windows installer
<igc> jfroy,verterok: anyhow, I'm *really* pleased to see os x packaging progressing
<igc> verterok: I'm with jfroy wrt needing PyQt and Qt bundled for the "desktop" installer - bundling qbzr and explorer without those also bundled doesn't help much
<jfroy> igc: fair enough, but I'm sure we can establish communication with him and deal with it
<igc> verterok: Qt is a simple install but PyQt is a nightmare for casual users
<verterok> igc: I'll try to use jfroy approach to build pyqt
<jfroy> igc: this is going to take more time to come up with, which is why I only worked on a core installer.
<jfroy> we could get the open-source Qt installer and merge it all in into one giant package :p
<jfroy> but it won't be small -- probably > 30 MB
<jfroy> well, not that that's particularly large by today's standards
<lifeless> spiv: around?
<fullermd> Huh.  First 2 chars of the MD5 of bzrtools 2.0.1 are the same as that of 2.0.  Good thing it's not an 8-bit hash...
<lifeless> \o/
<lifeless> creepy
<fullermd> Maybe it's a coincidence.  Or maybe it's part of the plan of the global banking cartel!
<spm> that'd be the new bzr --crack-md5 feature isn't it?
<lifeless> distributed virtual cracking system
<spm> 'zactly
<fullermd> Yeah, we're merging that into 2.0.x, just 'cuz nobody would expect to see it in a stable release.  It's more sekrit that way.
<lifeless> we'll respin 2.0.0 in fact, without changing the md5sum, cause thats the point
<spm> bzr: taking over the world, one cracked md5sum at a time
<fullermd> 1 down, 340282366920938463463374607431768211455 to go!
<spm> so by next tuesday?
<fullermd> Wednesday more likely.  I have an early tee time on Tuesday.
<spm> far be it for us to let world domination get in the way of a game of golf! your excuse is acceptable.
<spiv> lifeless: yeah, what can I do for you?
<lifeless> spiv: various bug state questions
<spiv> hit me, as they say.
<lifeless> spiv: I'm picking $foo to work on, check your mail is sufficient at this point
<lifeless> 'hit me with your rhthym Stig' could have a whole new meaning ;)
<meoblast001> how do you apply patches with Bazaar?
<lifeless> from other bzr users?
<meoblast001> no, from myself
<lifeless> bzr merge generally
<meoblast001> well, i created a diff with bzr diff
<spiv> (A rhythm Stig?  I'm imagining a car racing around a course while playing a tune by careful revving of the engine...)
<meoblast001> and i'd like to apply it at a different directory
<lifeless> spiv: yup
<lifeless> spiv: that was the sort of image I was hoping to provoke
<AfC> meoblast001: the "different directory" is also a Branch with a WorkingTree ?
<lifeless> meoblast001: bzr patch can do that, but if you did something like
<lifeless> 'bzr diff -r x..y'
<lifeless> to make the patch, then I'd like to introduce you to
<meoblast001> hm, i checked bzr <tab> and didn't see patch
<lifeless> 'bzr send -r x..y $path_to_trunk -o-'
<lifeless> which will make a rich patch
<lifeless> which 'bzr merge' or 'bzr pull' can use directly.
<meoblast001> bzr: ERROR: unknown command "patch"
<lifeless> its in the bzrtools plugin
<meoblast001> oh
<lifeless> but like I say, its _very_ unusual to use patches to move stuff from one bzr tree to another
<spiv> meoblast001: I'm not certain about exactly what you want to achieve, but GNU patch doesn't stop working just because there's a .bzr directory somewhere :)
<lifeless> and by very, I mean very very very very
<meoblast001> spiv: i tried GNU patch and it didn't do anything, maybe i don't know how to use it :/
<meoblast001> patch -p0 blah.diff?
<spiv> meoblast001: but as lifeless is saying, I'm surprised that you can't use "bzr merge".  Can you explain more about what you are doing?
<meoblast001> i have 1 branch that i was modifying, when i realized i had to make some modifications to my entire branch that would make all checkouts incompatible (had to overwrite the branch on launchpad)
<meoblast001> so now, i can't continue editing the old copy until i apply the difference to the new one
<spiv> meoblast001: perhaps you want "bzr merge --uncommitted"?
<meoblast001> which am i doing bzr merge on?
<meoblast001> how would i apply the patch with GNU patch?
<spiv> You have an "old copy" and a "new one", and they are both bzr branches of the same project?
<meoblast001> yes, but one is now incompatible
<meoblast001> i knew that not many people at all had a checkout of my project, so i went forth with fixing some problems with older commits
<meoblast001> this made my own older branches incompatible
<spiv> You rebased?
<meoblast001> well, i fast-exported :P
<meoblast001> i had to remove a font, a directory, and 2 source files that really should have never been there
<spiv> Ok, that explains a lot.
<spiv> (As well as demonstrating why history rewriting of published branches is a bad idea :P )
<meoblast001> and my project is only a half year old, i'm pretty sure only 2 people (including me) have a checkout
 * fullermd . o O (Famous last words?  :)
<spiv> So you effectively want to rebase some changes from the old history onto the new history.
<meoblast001> basically, i want to construct a patch of uncommitted changes to my old, incompatible branch, and apply them to my new branch
<spiv> diff/patch should work ok for that, I'd think, assuming you don't mind bringing the change across in a single commit.
<meoblast001> i made the diff, i just can't get it to apply
<meoblast001> well, the only thing i'm trying to bring across is uncommitted changes anyway
<spiv> If fast-export has kept the file-ids the same, then "cd new-one; bzr merge --uncommitted ../old-one" would work,.
<spiv> But I would expect "patch -p0 blah.diff" to work too.  How does it fail?
<meoblast001> it just sits there, and does nothing
<meoblast001> maybe i'm not waiting long enough?
<fullermd> patch doesn't take the patch file as an argument...
<spiv> Oh, "patch -p0 < blah.diff" maybe.
<spiv> "bzr patch" is more convenient in this respect :)
<meoblast001> 1 out of 1 hunk FAILED -- saving rejects to file src/Makefile.am.rej
<meoblast001> hm
<meoblast001> i know what that is
<meoblast001> since fallbacks.cpp was one of the files i removed, it isn't in the new Makefile.am
 * igc lunch
<malibu> Hi there... so now that bzr is at 2.0.0.... Does TortoiseBZR work better / FASTER ?
<lifeless> malibu: Tortoise hasn't been radically changed by the work on 2.0; I think naoki was doing some work on it though.
<lifeless> so it may be better, but its not really cause of 2.0 :)
<malibu> Is there anywhere where the changes may be logged?
<lifeless> the tortoisebzr project I imagine ;)
<lifeless> [sorry I don't know quite where that is]
<malibu> ohh.. yeah I found it
<malibu> it doesn't work for lightweight checkouts and won't be fixed.... darn
<lifeless> why do you need lightweight checkouts? for most folk a regular checkout is much better
<malibu> I put everything in my repository.. install files, config files.. I use it to sync my machines from my own server, like dropbox
<malibu> If I do not do lightweight, there is too much space used by the .bzr directory
<malibu> I had the same problem with subversion and git
<malibu> But using lightweight, the .bzr directory stays small
<malibu> It has been working quite well for me for a couple months now.. But I had hoped to get TortoiseBZR to work at some point
<malibu> I didn't realize there wasn't enough in the .bzr directory to allow it to work at all
<malibu> I had thought bazaar could still track what files had been changed since last update / commit
<lifeless> we can tell 'not the same'
<lifeless> but will stil connect to the network
<malibu> For lightweight, it would be nice to still work offline by checking modification dates.
<malibu> oh erll
<malibu> well
<lifeless> there is metadata needed that isnt in a lightweight checkout
<lifeless> which is why we connect to the repo
<malibu> unfortunately for me..
<malibu> Still, bzr is the best for my purposes
<malibu> Is there a way to do a normal checkout but limit the size of the .bzr ?
<malibu> Sometimes I've seen it get just as big as the actual working copy
<lifeless> malibu: sorry, I've got to pop out
<malibu> I guess something like lightweight with the metadata.. which I assume is small
<malibu> ok
<malibu> later
<verterok> jfroy: still around?
<lifeless> spiv: igc: if you need me SMS me
<jfroy> aye
<lifeless> I won't be far, but $stuff to $do
<verterok> jfroy: looking to your branch, I realized there is no mention of pycrypto or paramiko
<jfroy> yeah I haven't included them.
<jfroy> probably should I guess
<verterok> jfroy: hmm, probably :)
<spiv> lifeless: happy $doing of $stuff :)
 * spiv -> lunch
<vila> hi all
<Peng_> Hello. :)
<bialix> hello bzr
<spiv> Hello bialix :)
<bialix> hello spiv
<bialix> :-)
<rusty> So, if I really want people to be able to browse my repo in a web server, I really need fastCGI et al?  (ccan used the hgweb stuff, and it broke with a recent upgrade)
<nedosa> hi, i have a question about rebase, i'm getting the "No revisions to rebase." message
<nedosa> Tried it on a simple test case, created a new child branch, made some commits, then tried to run rebase on the child branch against the parent
<nedosa> even then, it would give me "No revisions to rebase"
<spm> rusty: if I understand your meaning; you can use loggerhead without an apache/web-server per-se. Or are you meaning super performance issues?
<rusty> spm: nope... thanks, just found that by punching right keywords into google :)
<poolie> hello spm, rusty
<spm> hey poolie
<spm> poolie: how's london?
<rusty> poolie: hi!
<poolie> pretty normal: grey, coldish, full of canonical people
<poolie> pretty good really
<spm> heh
<lifeless> poolie: hi poolie
<bialix> hello poolie
<bialix> the whole universe looking at poolie and asking: when?
<poolie> the final announce?
<poolie> today!
<poolie> but right now... tada, a meeting!
<spiv> Woo!
<lifeless> poolie: :P
<lifeless> poolie: have a good week
<poolie> exciting lp & bzr hacks for 4.0
<spiv> He's such a tease.
<lifeless> hehe
<fullermd> Jeez, we just finally got 2.0, and already we're talking about 4.0?
<lifeless> lp 4.0
<spiv> fullermd: exponential improvement!
<spiv> (or he's talking about Launchpad 4.0...)
<lifeless> txen rzb si 1.2
 * spiv wanders off
<lifeless> igc: are we talking past each other?
<rusty> OK, how does loggerhead know what repos to serve?
<rusty> So far I have a blank page: http://ccan.ozlabs.org/repo/
<lifeless> rusty: how are you running it?
<lifeless> rusty: the general way is 'bzr serve --http <path[cwd implied]>'
<rusty> lifeless: via apache.  I am *TRYING* to replace the hgweb hack which was broken in the move.
<lifeless> rusty: so in apache you have a proxypass
<lifeless> rusty: yes?
<rusty> Yep...
<lifeless> right
<rusty> lifeless: as you can see, it's hitting loggerhead.
<lifeless> so the backend is what matters - how are you starting loggerhead
<rusty> lifeless: ?  from /etc/init.d/loggerhead ?
<lifeless> rusty: can you pastebin that somewhere?
<rusty> lifeless: it's standard ubuntu package...
<lifeless> rusty: I'm pretty sure that the packaging adds the init script
<lifeless> rusty: upstream its 'bzr serve --http' as I said :)
<Peng_> Which version of Loggerhead?
<rusty> Peng: 1.10-1.. actually,t his is debian Sid.
<rusty> lifeless: basically "start-stop-daemon -p $PIDFILE -S --startas /usr/bin/start-loggerhead -- -p $PIDFILE -c /etc/loggerhead.conf -L /var/log/loggerhead 2>/dev/null"
<lifeless> ugh
<lifeless> so we all roundly hate loggerhead.conf
<lifeless> but thats what you'll need to edit
<rusty> lifeless: it doesn't seem to have a "here is my repo" option.
<Peng_> Or you could upgrade.
<lifeless> rusty:
<lifeless> [ccan]
<lifeless>  name = 'ccan'
<lifeless>  auto_publish_foder='/path/to/root/containing/branches'
<lifeless>  url_prefix='http://ccan/webroot/branches'
<lifeless> #(or whatever)
<rusty> lifeless: /path == dir which has .bzr subdir?
<lifeless> rusty: the root area to want to server our
<lifeless> *out*
<lifeless> root-of-the-area
<rusty> lifeless: I ahve a ccan repo.  Actually, just a .bzr/ dir (it's not checked out).
<rusty> lifeless: I want to serve it on the intertubes.
<lifeless> rusty: righto, so put the path to the repo as the auto_publish_folder
<rusty> lifeless: it is in /home/ccan/ccan/
<lifeless> rusty: is it just one branch, or many?
<rusty> lifeless: yeah, that's waht I though.  Still blank.
<rusty> lifeless: just one.
<lifeless> I was assuming many
<lifeless> for one
<rusty> May have branches in future, but today, one.
<lifeless> is there a shared repo at /home/ccan ?
<lifeless> [where would other branches go, in future]
<rusty> No, I use ssh hack to allow commit access.  OK, -ETIMEDOUT.  I'll decide what to do tomorrow...
<garyvdm> Hi all
<garyvdm> vila: I would like to make a change to bzr-upload. I just want to see what you think of the idea first.
<vila> garyvdm: hi, what is your idea ?
<garyvdm> I would like for it to check on upload, that the revision that you are uploading is a decedent of the revision that was there.
<garyvdm> Just like bzr push
<vila> wow poolie in my TZ ! Welcome ! :)
<garyvdm> And add a --overwrite option to disable it.
<lifeless> vila: poolie is offline :P
<vila> garyvdm: That sounds useful and coherent with push, so +1 on the idea
<garyvdm> vila: Cool - I'm going to start on that now :-)
<vila> lifeless: rats, missed that in my vgrep, and of course I didn't use completion *this* time :D
<vila> hi bialix
<loxs_wrk> folks is it safe to rename branches inside a --no-trees repository? Is it ok to do it with mv or do I need to use bazaar somehow for this purpose?
<fullermd> loxs_wrk: As long as you don't mv it outside the repository, that's fine.
<fullermd> (of course, anything pointing at the old location will need to be updated)
<loxs_wrk> yeah, that's obvious
<loxs_wrk> thanks
<nedosa> hi all, i have a quick question about bzr rebase
<nedosa> I keep getting "No revisions to pull." whenever i try and do a rebase
<NET||abuse> hey guys.
<NET||abuse> i've got a local branch for a stand alone branch, but i pushed it up to my web server over bzr+ssh last week, to just get the branch backed up,, how can i alias the remote branch address?
<NET||abuse> so i can just do bzr push mywebsitealiasname
<NET||abuse> since the web bzr+ssh path is already stored in the related branches attribute in bzr info.
<lifeless> nedosa: probably you have no local work or something; file bugs on bzr-rebase please.
<lifeless> NET||abuse: install the bookmarks plugin
<NET||abuse> aohhhh,,
<NET||abuse> i'm on intrepid, is that installed by default?
<vila> NET||abuse: 'bzr plugins' will tell you
<NET||abuse> pqm, upload, dbus, tools, deb, netrc credential store.
<nedosa> lifeless: well, i have a very simple test case, empty an empty repo, add a file, commit, then branch that, add a few more commits to my child branch
<vila> NET||abuse: then you don't have it
<lifeless> nedosa: yes, and so you have nothing new to pull into your child branch do you?
<vila> NET||abuse: cd $PLUGINS ; bzr branch lp:bzr-bookmarks bookmarks
<nedosa> lifeless: sorry, i meant create an empty repo....now if I do a bzr rebase from my child branch, it say "No revision to rebase."
<lifeless> nedosa: yes, as I said, you have nothing new to pull in in the example you've described
<nedosa> lifeless: I see o.k., maybe I'm missing how rebase should work then
<lifeless> nedosa: you have two branches, the trunk and the child, and the child is missing nothing from trunk; what do you expect rebase to do in that situation?
<nedosa> lifeless: I expected the changes to be pushed onto the trunk and there I would be able to re-arrange my commits
<lifeless> so, to push changes to trunk, use bzr push
<lifeless> even in git rebase wouldn't do anything in this situation :)
<lifeless> as for rearranging commits, I think thats basically unimplemented in bzr's rebase - there isn't a rebase -i yet.
<NET||abuse> vila, $PLUGINS doesn't seem to be set to anything for me.
<vila> NET||abuse: sorry, I meant <whatever your plugins directory is>
<bialix> bonjour vila
<nedosa> oh i see, I thought modifying the history of a branch meant rearranging the commits, apologies
<vila> NET||abuse: 'bzr version' should tell you that
<NET||abuse> vila,  :) figured... ok, branched that stuff..
<nedosa> lifeless: so as it stands, there's nothing in bzr that re-arrange commits, is that right ?
<spiv> NET||abuse: out of interest, why do you need an alias?  "bzr push" remembers the push address so you don't need to type it again next time.
<lifeless> spiv: he wants two, lp and a backup
<lifeless> spiv: AIUI
<NET||abuse> exactly, i was planing on pushing to a backup server location also.. so having a few bookmarks / aliases is a good thing.
<igc> hi lifeless
<igc> lifeless: so I think we can't close bug 116094 as "Fix Released"
<ubottu> Launchpad bug 116094 in bzr "local clone without shared repository is too slow" [High,Fix released] https://launchpad.net/bugs/116094
<igc> we could say "Won't fix" - don't do that
<lifeless> igc: do you think we're going to make copying history substantially faster?
<igc> lifeless: not while we have our current approach
<lifeless> igc: because I think we've tapped out all the low hanging fruit that make sense, and the next speed jump is going to be a tonne more C
<igc> lifeless: if we detected 'local branch' and did just (lock branch, cp -a) under the covers we could
<lifeless> igc: I think it *is* fixed, because we've made it fast, its not doing what 'hg is'.
<igc> lifeless: the trap with reocmmending cp -a is lack of locking
<fullermd> cp -a also isn't what you want when branch'ing into an existing repo...
<lifeless> igc: I'd be amazed if git is as fast as hg, git does an actual history copy AFAIK
<lifeless> igc: the recommended way to use git is to make a local branch in the repo, which is ~ what bzr branch in a shared repo is.
<igc> lifeless: so the use cases for 'local branch' are (1) create a feature branch (2) take a backup
<lifeless> igc: I want to understand why you think we *haven't* solved it - we got a report that cloning was way to slow, and now its not.
<lifeless> igc: its not the same as hg, because we're not hg.
<igc> lifeless: I still think the bug is clear ... *local* branch *outside* a shared repo is slow
<igc> lifeless: and at 20 minutes for OOo on a super-fast desktop, I don't understand how you think we can say it's fixed
<lifeless> igc: I think its exactly as slow as it should be to do a history copy
<lifeless> its very understandable: copying within repositories is ~= symlinking, copying out of them processes history
<igc> lifeless: as I said, 'cp -a' is what we'll be compared against and 20 minutes is far greater than 90 seconds
<lifeless> igc: If we're going to do more work on it, the bug should stay open. If not, it should be closed.
<lifeless> igc: this isn't about what we're compared to, its about whether we're going to do more in this space or not.
<igc> lifeless: so close it as "Won't Fix"
<lifeless> fine
<igc> lifeless: please don't claim it's fixed
<lifeless> igc: having spent nearly 2 years making it faster I find calling that work 'wont fix' really objectionable
<igc> lifeless: branching over a network is faster - granted
<lifeless> but if it will stop the fighting, we'll call it that
<lifeless> I feel like you are arguing 3 different bugs as reasons to keep this open
<lifeless> but not suggesting that we should be doing more work on the specific thing this bug was about
<igc> lifeless: I don't think local branching is much faster for 2a than pack is it?
<lifeless> igc: it was opened *on knits*
<lifeless> igc: I think fix released is appropriate when we've done a lot of work to address a bug, whether or not we reached the rather arbitrary goal that the filer set
<lifeless> igc: if we didn't address it at all, wont fix would be appropriate
<NET||abuse> hmm, so i have a bit of a disjointed directory structure in my app, how can i export a portion or two from my bzr working tree to deployment locations,
<NET||abuse> doing this locally to the web server
<lifeless> igc: and I've got to say, this back and forward leaves a rather unpleasant taste in ones mouth. How can we avoid it?
<igc> lifeless: sorry, I'm not trying to be difficult
<igc> lifeless: I just feel the bug isn't fixed
<lifeless> igc: If I demonstrated that on the history of the day we're now appropriately fast, would you be convinced?
<igc> lifeless: if you take any large project and bzr is within 100% of git or hg for 'local clone', I think it's fixed
<igc> lifeless: i just timed 'git clone' on the kernel - 13 seconds
<igc> lifeless: I don't think my fastimport of the kernel worked but I suspect we're a few minutes, not 26 seconds
<igc> the git time was cold cache btw
<lifeless> igc: I'm presuming it does history processing
<igc> lifeless: http://www.kernel.org/pub/software/scm/git-core/docs/git-clone.html suggests it hardlinks by default if the source and target are both local
<lifeless> igc: test across two filesystem then ;)
<lifeless> igc: hardlinking is a really bad behaviour IMO, for a number of reasons
<lifeless> igc: or perhaps use --no-hardlinks
<lifeless> igc: so, I object to bugs being open that we're not going to action; I feel that as we have improved more than enough to fix the original report it should be closed.
<lifeless> igc: and I feel like you're basically moving the goalposts on the bug
<igc> so git clone --no-hardlinks on the kernel took 10.3 seconds (cold cache)
<spiv> Less than hardlinking?  That's surprising.
<igc> spiv: maybe my drop-caches script is too soft?
<igc> echo 1 | sudo tee /proc/sys/vm/drop_caches
<igc> should I use 3 instead of 1?
<spiv> I think 2 or 3.
<igc> spiv: thanks. I'll try again
<spiv> You need 2 to drop the fs metadata cache.
<lifeless> I use 3
<spiv> I'd just use 3, you may as well turn the knob up to the max :)
<lifeless> also you still need to avoid the 'just cp' facilies
<lifeless> facility
<igc> hmm - just tried 3 - still takes 10 seconds
<spiv> The man page for proc also says you ought to run sync before writing to drop_cache, otherwise there may be dirty pages the kernel cannot drop.
<ScriptFanix> helloo
<ScriptFanix> -o
<spiv> Hi
<ScriptFanix> I have a question abour bzr builddeb and file permissions
<james_w> hello ScriptFanix
<ScriptFanix> in my branch, I have file with mode 700 or 600
<lifeless> :!less ~/bin/drop-caches
<lifeless> #!/bin/sh
<lifeless> # get written data to disk (not that its guaranteed)
<lifeless> sync
<lifeless> # (drop the unmodified pages)
<lifeless> echo 3 | sudo dd of=/proc/sys/vm/drop_caches 2>/dev/null
<lifeless> is mine
<ScriptFanix> when I run bzr builddeb -e --native, those file and up with permissions 644 / 755
<james_w> ScriptFanix: which files?
<ScriptFanix> I and up with a debian package with files containing potentially sensitive information world-readable (bad bad bad)
<spiv> igc, lifeless: I don't have a firm opinion on what to do with the bug report that's controversial, but I agree with lifeless that it's good to have something that can be closed positively after a good chunk of work has been done
<ScriptFanix> james_w: for one package it's an ssh authorized_keys file
<spiv> igc, lifeless: both for giving ourselves and users warm fuzzy feelings, and also for making the reports of work queued and work done reasonably intelligible.
<james_w> ScriptFanix: inside the package?
<ScriptFanix> for another, it's a file where the user is supposed to enter a mysql root password
<ScriptFanix> james_w: yup
<james_w> ScriptFanix: "man dh_fixperms"
<NET||abuse> i'm googling around alot trying to find good articles on methods of exporting to publish to your webserver,, and i'm not really finding the right articles at all.. .can anyone point me at some good material for this?
<spiv> igc, lifeless: so doing a large chunk of work towards fixing a bug, and then closing that bug Won't Fix definitely feels wrong.
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/342869 is that fixed, do you think?
<ScriptFanix> james_w: thanks, that should do the trick
<ubottu> Launchpad bug 342869 in bzr "Internal error on push" [Undecided,New]
<NET||abuse> i remember seeing one article which had you setup a bare repo on the server and setup auto hooks to push commits to it straight out to your web server,,,
<ScriptFanix> (I'm new to debian packaging)
<NET||abuse> would someone show me something like this?
<spiv> igc, lifeless: I'm not sure if that's an argument for leaving this bug unresolved for now, or splitting difficult bugs into smaller ones, or something else...
<igc> spiv: performance bugs are hard to make the call on w.r.t. fixed vs otherwise
<NET||abuse> oh,, and if i have a wt on my web server, can i just cp -r part/of/working/tree /path/to/site.com/www/    and not be moving bzr related meta files over also?
<spiv> (although leaving unresolved is probably poor for much the same reason)
<igc> spiv: I simply saying that 'local branch outside a shared repo' is still slow so ...
<igc> closing it simply because we're done work on it doesn't make sense IMO
<spiv> But if the outcome for this bug isn't "mark fixed" (and I'm not saying it should or shouldn't be) then I think we probably need to do something a bit differently.
<igc> slow is slow
<igc> spiv: you, lifeless and jam have made *great* stride wrt network performance
<lifeless> igc: unless we make the system fragile - see the number of options git clone _requires_ because they support hardlinking etc.
<spiv> Anyway, dinner needs me!
<lifeless> then its not going to get radically faster
<spiv> Happy bug-squashing, whatever form it takes!
<lifeless> without considerable elbow grease
<lifeless> I am pretty damn sure we've exceeded the requirements of the original bug report; upcasting it to 'bzr is not as fast as git' isn't useful
<lifeless> I'm done for the day
<Fly-Man-> Morning
<Fly-Man-> Any Bazaar developers awake that could have a look at a pastebin
<Fly-Man-> captured after the nice message
<Fly-Man-> segmentation fault
<Fly-Man-> while trying to capture a bzr branch
<mzz> Fly-Man-: I'm not a bazaar developer, but if the segfault isn't in a bazaar-specific extension I can look
<Fly-Man-> mzz
<Fly-Man-> let me grab the pastebins for ya
 * mzz wishes people would just include the pastebin link the first time around in cases like this
<Fly-Man-> used gdb for debugging
<Fly-Man-> http://launchpad.pastebin.com/d364c32a9
<Fly-Man-> this is what gdb gave
<Fly-Man-> http://launchpad.pastebin.com/d1e011574
<Fly-Man-> Used the ppa that's mentioned in this posting
<Fly-Man-> https://dev.launchpad.net/Getting
<Fly-Man-> => https://edge.launchpad.net/~bzr/+archive/ppa
<mzz> bah, memory corruption
<mzz> Fly-Man-: is the branch data needed to reproduce this available?
<mzz> Fly-Man-: and what python is that?
<Fly-Man-> python 2.6
<Fly-Man-> bzr 2.0.0-1~bazaar1~jaunty1
<mzz> Fly-Man-: ubuntu jaunty's? ubuntu karmic's?
<Fly-Man-> Jaunty
<Fly-Man-> I don't run Karmic yet
<Fly-Man-> Was planning to
<mzz> that's fine
<Fly-Man-> if this won't work
 * mzz has jaunty here
<mzz> Fly-Man-: can you give me instructions for reproducing this?
<Fly-Man-> Yes
<Fly-Man-> I installed a clean slate Jaunty
<Fly-Man-> then I ran apt-get update / upgrade / dist-upgrade
<Fly-Man-> to get the system setup fully
<Fly-Man-> after that, I added the 2 lines from the ppa to the /etc/sources.lst
<Fly-Man-> ran apt-get update again
<Fly-Man-> added the keys for the pp
<Fly-Man-> and started to follow the instructions on that page
<mzz> (mainly interested in the bzr commands you ran)
<Fly-Man-> after about 140 / 175 mb pulling
<Fly-Man-> it just dies
<mzz> ahh
<mzz> launchpad, got it.
<Fly-Man-> mzz, I ran the rocketsetup
<Fly-Man-> that has the commands in it
<mzz> yeah, got it now. Running...
<Fly-Man-> mzz: thanks
<Fly-Man-> if you get the same error, I know it's not my bzr
<GaryvdM> Hi - I'm getting an error: bzr: ERROR: wanted 8638 bytes but next hunk only contains 322: 'gcb1z\n8621\n19545\nx\x9c\x9d'...
<Fly-Man-> but I think i'll jump to Karmic then
<GaryvdM> This is the .bzr.log: http://pastebin.com/d2f71d8e4
<GaryvdM> How can I work out what's wrong?
<mzz> GaryvdM: I'd start by running "bzr check" on both ends
<GaryvdM> mzz:
<GaryvdM> mzz: Ok
<GaryvdM> mzz: both are ok
<mzz> GaryvdM: then I'm afraid for someone who actually knows bzr to show up
<SamB_XP> mzz: you're afraid ?
<mzz> SamB_XP: frequently
<SamB_XP> why are you afraid of people who know bzr ?
<mzz> err, wait
<mzz> I don't know what happened there
<SamB_XP> lol
<mzz> GaryvdM: then I'm afraid *you'll have to wait* for someone who actually knows bzr to show up
<GaryvdM> :-)
<mzz> my brain got ahead of my fingers a little there, I think
<GaryvdM> Hmm - odd - bzr pack on the source fixed it.
<igc> night all
<Fly-Man-> mzz: I think I found something that could explain the behaviour
<mzz> Fly-Man-: I haven't reproduced yet (it's pulling revisions)
<Fly-Man-> mzz: It will pull revisions
<Fly-Man-> but around 140 Mb or 171 mb it will give the error
<bialix> GaryvdM: hello
<mzz> Fly-Man-: looks like it's well past that point now (still going though). Are you sure your physical ram is ok?
<Fly-Man-> yup
<mzz> (bzr is pretty ram-hungry while it's doing this)
<Fly-Man-> it's a virtual machine
<Fly-Man-> with 2 gb ram
<mzz> Fly-Man-: if I wanted to debug this I'd first try to reproduce locally somehow, and then running a debug build of python under valgrind, assuming I'm correct about this being memory corruption
<mzz> (running valgrind on a regular build of python is fairly pointless)
<mzz> but only if you're sure about the hardware being ok (in this case that means the vm software being ok and the hardware the host is running on being ok)
<Fly-Man-> yupz, the machine is brandnew
<mzz> I'd trust it more if it was old
<orattue> What's the difference between using the protocol bzr+ssh:// over sftp:// - I can't seem to find any clear answers in documentation...
<garyvdm> Hi bialix
<Tak> orattue: as I understand it, bzr+ssh invokes (and thus requires) bzr at both ends, while sftp just uses raw sftp to transfer data
<orattue> Tak: are there any benefits to using bzr+ssh?
<garyvdm> orattue: bzr+ssh has some performance advantages
<garyvdm> orattue: e.g. Sometimes bzr will autopack it's repository. With sftp, this has to be done on the client, transferring all the data over the wire. With bzr+ssh, that is all done on the server.
<orattue> GaryvdM: yeah think I have experience an autopack over sftp:// not good :(
<mzz> bzr+ssh should cut down on the number of roundtrips, so I'd expect the performance difference to be more noticable if there's a lot of network latency
<bialix> GaryvdM: what you think about upgrading qbzr trunk to 2a?
<GaryvdM> bialix: That would be good.
<Fly-Man-> mzz: Same error occurs with the installed version from Karmic
<bialix> GaryvdM: I won't object, because 2a is supported at least since bzr 1.17
<bialix> and qbzr support only recent bzr versions
<GaryvdM> bialix: Though, it's not urgent for me.
<bialix> GaryvdM: I'm unlikely will have chance to do upgrade soon
<Fly-Man-> mzz: It seems to be in all 2.0.x branches
<Fly-Man-> when I try it on another machine with 1.18
<Fly-Man-> it works instantly
<mzz> Fly-Man-: works for me using the same jaunty+ppa
<Fly-Man-> mzz: that's odd ....
<Tak> hmm, shouldn't dpush have the same option set as push? (e.g. --no-strict)
<GaryvdM> Tak: probably, but --no-strict is quite a new option.
<GaryvdM> Tak: I think the right thing to do here is to log a bug...
<allenap> Hi, I'm using the Ubuntu Jaunty PPA ("deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu jaunty main") and I noticed that bzrlib is no longer available for Python 2.4. Does anyone know if this is a new policy, an issue with the package, or a local problem?
<GaryvdM> allenap: As far as I know, bzr still supports py 2.4. What distro are you using.
<GaryvdM> allenap: The version of py in jaunty is 2.6...
<allenap> GaryvdM: Ubuntu Jaunty (9.04).
<GaryvdM> allenap: Have you specifically chosen to run py 2.4?
<allenap> GaryvdM: Unfortunately yes :) Developing Launchpad.
<Tak> hmm, is dpush part of bzr proper? or one of the plugins?
<allenap> GaryvdM: When Launchpad builds, it creates an egg for bzr, so that's fine, no dependency on the system bzr. However, to prepare the build there is a script that needs bzrlib.
<GaryvdM> allenap: *I think* that the .deb in the ppa are built against the default py version for the distro, so you may need to build from source. I am not an expert on this though...
<allenap> GaryvdM: It's not a huge problem; that script can be run using python2.6, but I wanted to ask in case something had been removed.
<allenap> GaryvdM: ... by mistake.
<GaryvdM> allenap: I think it is just the .debs that require py 2.6, not the source...
<allenap> GaryvdM: Okay, that's reasonable. Thanks.
<jelmer> tak: It's part of bzr itself
<Tak> k, thanks
<Tak> what determines whether a command goes into the "hidden" list or not? (bzr help [hidden-]commands)
 * Tak full of silly questions today
<jelmer> Tak: if it's got 'hidden = True' set in the class IIRC
<Tak> well...I mean more philosophically
<james_w> if it has the aura of a hidden command
<james_w> basically whether it should show up in "bzr help commands"
<james_w> so internal, experimental, highly specialised or similar
<Tak> I see
<GaryvdM> Tak: Alot of the hidden commands are things that would be used by bzr devs, but not by ordinary users (e.g. dump-btree)
<GaryvdM> Tak: qsubprocess is use by qbzr to launch a command with a specialized ui_factory, would never be used directly by a user.
<Tak> dpush is what prompted my question ;-)
<Tak> I just found out about it the other day, and it seems like it would be highly useful to many bzr-#{othervcs} users
<smoser> kirkland, i know you use 'bzr cdiff' is it busted for you right now?
<smoser> $ bzr cdiff
<smoser> Plugin "Bzrtools" is not up to date with installed Bazaar version 2.0.0.
<smoser> There should be a newer version of Bzrtools available, e.g. 2.0.
<james_w> smoser: install updates
<james_w> it should be built by now
<smoser> james_w, looks like it. i *can* read, but i'd done that some time before when update wasn't available. thanks.
<james_w> yeah, it was just fixed this morning, not your fault as you have bzrtools 2.0 installed :-)
 * GaryvdM seeks poolie...
<orattue> hmm - bzr: ERROR: Cannot commit to branch BzrBranch6('file:///Library/WebServer/Documents/example.com/apps/'). It is bound to BzrBranch6('sftp://pixeco@dev.pixeco.com/home/bazaar/pixeco/example.com/apps/trunk/'), which is bound to file:///home/bazaar/pixeco/example.com/apps/trunk/.
<orattue> v.circular - anyone ever seen this before?
<LarstiQ> yeah
<LarstiQ> orattue: `bzr unbind` sftp://pixeco@dev.pixeco.com/home/bazaar/pixeco/example.com/apps/trunk/
<orattue> LarstiQ: right but I want to commit to that location...
<rbistolfi> Hi, I get this error trying to branch from lp, any ideas? http://pastie.org/633561
<LarstiQ> orattue: yes, but it is bound to itself, you need to fix that first
<LarstiQ> orattue: so unbind it from itself, and continue
<luke-jr> how do you undelete in Bazaar? O.o
<luks> undelete?
<LarstiQ> luke-jr: vague term like that, use case?
<luke-jr> in Subversion, I would copy the file from its last revision
<luks> bzr revert -r X path/to/file
<luke-jr> no, teh delete is commmitted
<LarstiQ> luke-jr: yes, what luks said
<luks> that's why there is "-r X"
<dash> luke-jr: revert does more in bzr than in svn :)
<luke-jr> o
<luke-jr> so that will restore the old file and commit it with its original history?
<dash> restore yes, commit no.
<luke-jr> O.o?
<dash> it just changes your WC
<luke-jr> :/
<dash> but you can commit it then. :)
<luks> why :/?
<LarstiQ> luke-jr: unlike svn revert, you can commit the result of a revert
<luks> commit is as simple as bzr commit -m 'restored path/to/file'
<luks> but people usually want more than that
<luke-jr> but then I'd lose the history?
<luks> no
<luke-jr> and probably break merges
<luks> it will be the same file with the same history
<luks> again, no
<luke-jr> oh
<luke-jr> so it restores the history, so when I commit manually, it's there
<luke-jr> ?
<dash> yes
<luke-jr> ok
<luks> it's there when you run revert
<luke-jr> thanks
<luks> then you commit manually
<luke-jr> and does that work smoothly with bzr-svn?
<dash> bzr in general won't let you do stuff that breaks merges
<LarstiQ> yes (although the history was never gone, so didn't really need restoring)
<luke-jr> or am I better off using svn to restore it?
<dash> luke-jr: works fine with bzr-svn
<luke-jr> so bzr-svn will represent it as a copy in svn? :)
<nedosa> hi all, is there anything in bzr to support rearranging commits ? I thought bzr-rebase can do it, but apparently not yet
<LarstiQ> luke-jr: euh, that I don't know exactly
<LarstiQ> luke-jr: try it! :)
<luke-jr> LarstiQ: svn has no simple undo if not :/
<LarstiQ> luke-jr: do you really need it to be a copyz?
<LarstiQ> svndump if you need to be sure
<luke-jr> LarstiQ: of course... :/
<LarstiQ> or try it on a an example repo
<LarstiQ> luke-jr: why?
<luke-jr> because I'm a perfectionist
<luke-jr> and some of these might be big
<LarstiQ> if bzr-svn doesn't use a copy, I'd think it uses the original entry
<LarstiQ> by pivoting in the revision
<LarstiQ> thereby using even less space
<LarstiQ> buuut, that's svn details I'm not going to vow on :)
<luke-jr> eh?
<luke-jr> Subversion can only do it with a copy...
<LarstiQ> luke-jr: not if you say "use this prior revision"
<LarstiQ> which may or may not be possible in the case of reverting one file
 * LarstiQ knows enough about svn inner workings to be dangerous
<LarstiQ> not enough to know exactly how it will play out
<LarstiQ> luke-jr: the bundled svn _client_ can only do it with a copy
<luke-jr> LarstiQ: how would that be represented in a svn dump?
<LarstiQ> luke-jr: good question
<luks> is this something you are going to do regularly?
 * luke-jr notes his Subversion repository is generated from a hand-crafted svn dump of his
<luks> if not, I'd just use svn copy and be done
<luke-jr> heh
<luks> otherwise I'd test bzr-svn on a test local repository
<luks> the file will use the same history and everything in bzr
<luks> but I don't think anybody here, except jelmer, knows what will it do in svn :)
<luks> ouch, bzrlib version check in qbzr :(
<GaryvdM> luks: I wanted to have just a minimum check, but there is no api for that :-(
<GaryvdM> luks: I really think it's better overall to do a version check. It takes away alot of unknowns.
<luks> GaryvdM: my problem with it is that parts of qbzr might easily work with older bzrlib, but it will refuse to run
<luks> I had enough of that with bzrtools and bzr-svn
<luks> (upgrade bzr => oops, no plugin works anymore => locally comment out version checks => they all work fine)
<GaryvdM> luks: Ok - that could be solve by not defining a max version.
<luks> I can understand it in bzr-svn, where a different format API might lead to data corruption
<luks> but not in a tool plugin, like qbzr or bzrtools
<luks> well, max version is only one end of it
<luks> the point is that one version number is not a good way to represent "compatibility"
<Tak> heh, I put a min version check on md-bzr because of the strict/no-strict behavior
<jelmer> Tak: how do I build monodevelop-bzr from the command-line *and* build the GUI code?
<jelmer> Tak: so far I've used mdtool but that doesn't seem to create the .cs files
<Tak> hmm, good question
<GaryvdM> luks: Sorry - I had some one talking to me.
<GaryvdM> There is some system wide code (SubprocessUIFactory) that was not compatible with bzrlib 1.16. That affects a large scope of the qbzr functionality.
<Tak> jelmer: apparently there's not a way; I guess we should add a generated.cs and then add it to ignores
<luks> GaryvdM: I have no real problem with that, it's your choice
<GaryvdM> I agree on the max check though.
<luks> just note that the lack of a version check in earlier qbzr versions was intentional
<GaryvdM> luks: yes
<luks> for example, the qcommit code from qbzr r1 (3 years old, written against bzr 0.10) still works fine
<luks> that's two major bzr versions
<luks> it didn't do much, but it shows that some API does not change while some does
<luks> and a single number can't reflect that
<jelmer> Tak: just for everything in gtk-gui/ ?
<Tak> jelmer: yeah
<RobOakes> I've got a quick question about creating a branch from a separate user account.  Is there any way to tell bzr which public key I want to use?
<jfroy|work> Is there documentation on the attributes or properties of things in bzrlib?
<jfroy|work> I just looked everywhere on a way of getting a revision object from a branch and a revid, only to dig out of the source that I could do branch.repository.get_revision()
<jfroy|work> pydoctor is hugely not helpful by being silent on attributes / properties completely :|
<mwhudson> it should document @properties, but yeah
 * gerard_ loves bazaar
<gerard_> and now the complaint: bzr svn-import <path to local repo> is SLOOOW
<gerard_> any way to get data from svn into bzr faster?
<gerard_> is bzr-fastimport much faster?
<GaryvdM> jfroy|work: branch.repository.get_revision() is the correct way to do what you want.
<jfroy|work> GaryvdM: precisely what I am doing :p
<GaryvdM> jfroy|work: "getting a revision object from a branch and a revid" :-p
<jelmer> gerard_: how slow is slow?
<gerard_> good question
<Tak> so zen
<gerard_> about 1s per revision
<jelmer> gerard_: could be right, depending on the size of the trees
<jelmer> gerard_: what versions of bzr/bzr-svn?
<gerard_> meh
<gerard_> Bazaar (bzr) 1.5, bzr-svn 0.4.10
<gerard_> about 8000 revisions in total
<jelmer> gerard_: oh, upgrading will definitely get things a lot faster
<gerard_> jelmer: probably, but it's the latest version in debian testing
<jelmer> gerard_: in debian stable I think
<jelmer> gerard_: testing has 1.17
<gerard_> hmm, I was in the opinions that I was running testing
<gerard_> let me check
<gerard_> not the first time they switched around stuff and I got stuck with stable
<gerard_> jelmer: right, I feel stupid now
<gerard_> let me check how much faster it is
<gerard_> jelmer: ahh, thanks alot
<gerard_> works much much better now
<Tak> ugh, speaking of version limiting, I made a stupid mistake that breaks the md-bzr version check for 2.0
<gerard_> now I need to plan when I'm going to update my system to testing again....
<gerard_> it still doesn't understand ^C very well but that's ok
<jfroy|work> Is there a way to get an output similar to 'bzr log -c FOO' but using the bzrlib API for a specific Revision object?
<jfroy|work> mmm, bzrlib.log
<Mez> how do I find the revid of the current branch tip
<Mez> nvm, found it.
<jfroy|work> mmm, that's not a simple API
<jrwren> https://bugs.launchpad.net/bzr/+bug/186014 says fix release, how can I find out what the fix was ?
<ubottu> Launchpad bug 186014 in bzr "MemoryError on diff/commit due to corrupted dirstate" [High,Fix released]
<GaryvdM> jrwren: The milestone says 1.17
<jrwren> hrm, well I'm on 1.18.1, wondering how I can fix up a corrupted dirstate
<scrash09> Hi! I just started using bzr, and need a little help.
<scrash09> If I checkout a source tree (e.g., /webapp) that contains a user-files directory (e.g., /webapp/files) that I replace with my local stuff.  Every once in a while I want to merge upstream changes into my local setup.
<scrash09> When I try a merge, though, I get 'bzr: ERROR: Working tree "/webapp" has uncommitted changes (See bzr status).'; 'bzr status' then lists any files i've modified/added in /webapp/files.
<scrash09> Do I _have_ to manage /webapp/files under bzr control in order to keep the upstream changes in sync? Or is there a way to exclude the /webapp/files folder from the sync/merge process?
<jrwren> you can ignore those files, but then you get no help for merging.
<scrash09> jrwren: Sorry, I don't understand what you mean by "no help" ...
<jrwren> scrash09: teh whole point is to use VCS to help you merge.  If you commit those files, and then "every once in a while" merge upstream changes... bzr will help you merge those changes, or rather, help you manage teh versions of them. You still need a nice diff tool to merge conflicts.
<jrwren> scrash09: but if it is source, quite often it can just merge and work.
<scrash09> jrwren: Hm.  I'm not grokking this. :-(  E.g., the 'upstream' in my case is a Drupal-clone, Pressflow (not that it matters, I suppose).  It includes a 'sites' folder  .... that I'll put my stuff into.  So, Pressflow changes and I want to merge those changes "around" my sites folder.  I _try_ to do that, using bzr merge, but get an ERROR -- and it refuses.
<scrash09> Oh, and I will _never_ merge _my_ local stuff back into upstream ...
<dub> hi, is there a dns name for a launchpad.net bzr server?
<Peng_> dub: What do you mean?
<dub> I've been given a probelm with 'bzr.launchpad.net' to look at, which appears to be wrong
<Peng_> dub: It's bazaar.launchpad.net.
<dub> thanks, are there any known issues with bazaar and transparent HTTP caching that you are aware of?
<Peng_> dub: Broken HTTP caches sometimes get freaked out by what bzr does, but not that often, and I think it might've been worked around anyway.
<Peng_> dub: You can access bazaar.launchpad.net over SSH if you need to. It's faster, too.
<scrash09> Can 'bzr ignore' be used to ignore an entire subdirectory below my tree root?  Or just file-name pattern matching?
<dub> thanks for your help
<Peng_> That one didn't wait long.
<dash> maybe he tried it
<Peng_> Hopefully, but we'll never know.
<jrwren> any good docs for working with multiple heads?  we ahve 3 heads, adn I don't know why.
<dash> jrwren: hmm. where are you seeing this? :)
<jrwren> bzr heads --all
<jrwren> shows 3 heads, only 1 tip. somehow, some of us are using different heads, not sure how/why
<jrwren> i guess this is called nested trees?
<zsquareplusc> running heads within a branch in a shared repo also lists the heads of the other branches in the repo, at least is seems to do that here
<jrwren> oh no, nested trees is something else entirely.
<jrwren> zsquareplusc: yes, and would hopefully show on TIP per branch
<zsquareplusc> yes
<jrwren> mine shows one TIP per branch, but also 2 other HEAD things that aren't TIP
<zsquareplusc> maybe with stacked trees you see a head for each "layer"?
<jrwren> hrm... maybe I inadvertently stacked my trees.
<jrwren> stacked branches teh same as stacked trees?
<Fly-Man-> mzz: *ping*
<Fly-Man-> mzz: For some stupid reason, it works now ;)
<Fly-Man-> I baked 1.18 from source
<Fly-Man-> then all of a sudden it worked
<lifeless> moin
<lifeless> dub: intercepting caches - no. Unless they ignore cache control headers
<dub> does it user tcp/80?
<dub> I get a 302 to https://launchpad.net
<dub> use*
<lifeless> port 80 for http, 443 for https, as normal
<dub> is there another URI that the application uses?
<dub> ie, not bazaar.lp
<zsquareplusc> jrwren: is it a shared repo where you deleted branches?
<lifeless> dub: many, depends on what the user types in ;)
<lifeless> dub: why?
<dub> I have a user complaining about inability to 'edit stuff on bzr.launchpad.net'
<dub> using bazaar as the client
<lifeless> are they able to connect to port 22 ?
<Peng_> dub: The user needs to pastebin the error he's getting.
<lifeless> to push or commit on launchpad, we use bzr+ssh, which tunnels over ssh - on port 22
<dub> I can ask, at this stage I was just trying to establish the actual URI and do the usual checks on if its cache friendly
<lifeless> and as Peng_ says, seeing the error would help immensely, as there are multiple possible causes.
<lifeless> dub: I wouldn't say its friendly, we cache bust a lot (because of the nature of the beast). However, 'works when folk are doing interception' - yes.
<jrwren> zsquareplusc: it is a shared repo, but we did not delete branches
<Peng_> dub: The http access is read-only. If the user wants to "edit stuff", he/she/other has to use ssh anyway, and who in the world has a transparent SSH cache?
<dash> One way to get multiple heads is to use incommit
<dash> er uncommit
<Peng_> I've heard that radiation can do it too.
<dub> Peng_, we're caching tcp/80. The user is rather vague on details but is sending through the error message
<rbistolfi> Hi, any idea about why do I get this? http://pastie.org/633561
<Peng_> rbistolfi: ...Do you have a transparent proxy? What happens if you try again?
<Peng_> dub: Is rbistolfi the person you were talking about?
<dub> no idea sorry
<dub> the IP suggests not
<lifeless> oubiwann: you're flapping
<oubiwann> yeah... I need to extend my wireless network
<lifeless> rbistolfi: is it a private branch?
<lifeless> oh sorry, terrible pastebin site.
<lifeless> uhm as Peng says, looks like something mangling the http response
<lifeless> rbistolfi: ^
<dub> not seeing much in the way of cache control headers
<dub> should be using expires
<lifeless> dub: not really, if you're seeing web pages, they don't matter. if you're see VCS metadata, we no-cache them all in the client
<dub> my users error is much the same as rbistolfi
<dub> looking at headers returned from an HTTP request for the URI I see no attempt at cache control.
<lifeless> dub: thats right.
<lifeless> dub: Completely consistent with what I was saying ;)
<lifeless> dub: if you're running squid, you have an old version.
<dub> im not
<lifeless> known bug, fixed a while back.
<lifeless> ok
<lifeless> in which case could you please open a bug? We'll need to figure out if the product you've got is doing the wrong thing so we can add it to our knowledgebase [or fix bzr if its a bzr http bug]
#bzr 2009-09-29
<dub> sorry I dont have time
<dub> I'll bypass it and let the user log one if they feel the need
<dub> might I suggest that you dont use tcp/80 if you're not doing http and if you are use expires
<lifeless> dub: we're doing HTTP
<lifeless> dub: and expires is orthogonal to the issue @ hand; VCS data doesn't have a strict semantic value for expires
<lifeless> expires wouldn't help us at all
<dub> expires is the only way to reliably prevent caching
<dub> in my limited experience anyway
<lifeless> dub: no-cache does it fine
<lifeless> we don't care if caches cache, we cache bust. We have to because there are folk that run caches that don't conform to the rfc's
<dub> if you say so. yet you seem to have an application that causes caching issues
<lifeless> no
<lifeless> failing to process specific http messages != caching issue
<dub> we cache several gbps and I dont know of other problem apps
<dub> expires fixes all stale data type problems
<lifeless> sure, but this is a proxy issue, not a caching issue
<lifeless> I repeat, its not a stale data issue, not if it looks like rbistolfi's issue.
<dub> regardless, i've spent enough time on this, thanks for your assistnace
<lifeless> anytme
<lifeless> please do encourage your user to file a bug
<dub> will do
<igc> morning
<igc> hi lifeless
<lifeless> hi igc
<verterok> igc, lifeless: hi!
<verterok> igc: OS X 10.4 DMG's uploaded. hopefully I'll get Leopard DMG for tomorrow (actually as soon I reboot my "work laptop" into OS X :/ )
<igc> verterok: well done and thank you
<verterok> igc: np
<spm> lifeless: ref upgrading the bzr pqm chroot to hardy; any probs at your end if we stop pqm while the upgrade is done? or would you prefer a less intrusive cutover? I image it'd take an hour or two max.
<lifeless> spm: stop it
<spm> lifeless: ta
<lifeless> spm: I presume you'll take a backup in case we have to roll back?
<spm> lifeless: heh. 1st thing pjdc did - how big is the chroot vs how much space do we have :-)
<verterok> igc: http://developer.apple.com/mac/library/DOCUMENTATION/Carbon/Conceptual/ProvidingUserAssitAppleHelp/authoring_help/authoring_help_book.html#//apple_ref/doc/uid/TP30000903-CH206-CIHEAADH
<verterok> igc: ^ there is a description of the layout/format required by the Mac Help viewer
<jrwren> dash: thanks! I'll bet uncommit is how I got multiple heads.
<spm> lifeless: the upgrade is done. Can you fire in a trivial request so we can verify how much we've broken?
<robert_ancell> Can anyone tell me what is wrong with the branch lp:~ubuntu-desktop/gdm/ubuntu.  When I try and push it says the branches are diverged and when I look at https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu it says LP is processing changes for this branch
<zsquareplusc> someone else seems to have pushed up new revisions
<zsquareplusc> you probably need to "merge"
<spm> robert_ancell: ahhh. that'd possibly be related to an issue we're having atm. see #launchpad.
<robert_ancell> spm, ok, thanks
<lifeless> spm: do we have python-subunit installed now?
<spm> lifeless: indeed we do!
<lifeless> ok,  I'll do something shortly
<lifeless> lunch is begging first
<fullermd> Ooh, what a good idea.
<lifeless> http://paste.ubuntu.com/280891/
<lifeless> I need someone to audit that
<lifeless> I think its robust and clear; I'd like it to be moreso
<spiv> lifeless: the layout and invariants section are inconsistent about saying MD5HASH vs. HASH
<spiv> lifeless: the meaning of "There is always 1 and only one match for:
<spiv> " and the following bullet list isn't obvious to me.
<lifeless> I'll clean it up. the intent is that only one of the following statements is true
<lifeless> I hope you have the spare cycles to also logic check it ;)
<spiv> "- current" isn't a statement, though?
<lifeless> its a file
<lifeless> as per layout
<lifeless> so 'there is a file called current'
<lifeless> bbs
<spiv> So just say that ;)
<spiv> e.g. "There is always: - a file called 'current'; - exactly 1 file matching '*.check'; - exactly 1 file matching HASH.{current,delete}"
<spiv> It might be worth saying upfront in the Invariants section if the intent is that this recovery will be performed automatically, or if it will need human intervention.  I'm guessing you intend automatic (I hope so :)
<spiv> In the insert operations, it's not clear what "check if the insert should complete", and jumping ahead to the commentary still doesn't make it clear exactly what the check is, or what the check is for.
<spiv> In read sequence, what about the (small) race between listing *.check and opening the result vs. another process renaming foo.check?
<spiv> I assume the answer there is the same as in the next bullet; loop.
<spiv> s/;/:/
<spiv> What does "Closing a dirstate" mean?
<spiv> What about multiple concurrent processes attempting recovery of the same dirstate?
<spiv> Your markup is a bit inconsistent about using \n or \\n
<spiv> Typo: "remaned"
<lifeless> spiv: I intend to make automatic recovery possible, I don't intend to do so in the initial spike
<lifeless> spiv: well, any policy that someone might implement, such as stat cache updates, policy checks, what have you
<spiv> What happens in during insert if "mv current foo.check" fails (due to concurrent insert)?
<lifeless> this is good - thanks
<spiv> lifeless: so "don't write new file if stat cache has barely changed?
<lifeless> more 'dont trash someone elses changes'
<lifeless> its a critical section, the only time you can be sure noone else inserts (unless they invoke recovery concurrently, and that would be a mess
<lifeless> so, listing *.check and the .check rename happening, - loop
 * lifeless pages up and starts implementing improvements
<spiv> "errors can be removed" probably should be "errors can be ignored"?
<spiv> I'm not sure how "dont trash someone elses changes" fits with "check if the insert should complete".  If you got as far as the "rename current statefilename.check" succeeding, then as you say you're in the critical section, so how can there be other changes that could be inadvertently trashed?
<spiv> Ok, read it all now.
<spiv> In my ideal world, I think maybe there'd be some sort of formal proof, or at least exhaustive state diagram, to demonstrate that all states are unambiguous in the face of concurrency.  That would be a lot of work, though.
<spiv> But it is just complex enough that I can't feel 100% sure that it's robust on a single read-through, although it seems plausible that it is.  (With some assumptions about what the FS guarantees, of course...)
<spiv> (And I don't see any obvious simplifications you could make to the design.)
<spiv> So, I worry a little about bugs in edge-cases.  I guess they are likely to have easy-to-repair consequences if they do happen.
<lifeless> so stat cache updates
<lifeless> say you have two writers A and B
<lifeless> they both concurrently prepare an update
<lifeless> A is doing a stat cache update
<lifeless> we don't know what B is doing
<lifeless> B wins the race on 'mv current HASH.check'
<lifeless> and thus completes its insert first
<lifeless> now, A has a new state file it wants to write
<lifeless> so once A is in the critical section
<lifeless> it can reliably see that the pointer has changed
<spiv> Oh, so it's a check that the renamed current has the same pointer we think it has?
<lifeless> if we care, yes
<lifeless> a stat cache update cares that its unchanged
<spiv> We need to care, I think, or else we risk losing semantic changes from B.
<lifeless> a 'merge' or 'add' or whathaveyou doesn't care if the pointer changed.
<lifeless> spiv: so there is a lockdir lock surrounding the WT still
<lifeless> spiv: only one semantic writer is permitted.
<spiv> Ah, ok.  That's worth mentioning briefly then :)
<spiv> So a stat cache update cares that it's unchanged because otherwise there may be a semantic change from another process?
<lifeless> right
<lifeless> I'm writing prose about this at the top of the docstring
<spiv> But an 'add' or whatever doesn't mind, because it will have first read the pointer inside the semantic lockdir write lock?
<lifeless> no
<lifeless> an add doesn't care because it is happy to trash stat cache updates
<lifeless> and it knows noone else is allowed to be an 'add' concurrently.
<spiv> That's what I meant!
<lifeless> ok, but its not what you said :)
<lifeless> [the old pointer value /doesn't matter/ to logicalwriters
<spiv> It's inferring from its ownership of the semantic write lock that the only possible concurrent changes were stat cache only.
<lifeless> yes
<lifeless> thank you very much
<lifeless> I'm sure it will need more polishing, but I feel its clearer now.
<lifeless> and I'm glad you didn't find conceptual holes
<spiv> That's ok, I know how hard it is to write precise and clear text about complex state machines :)
<spiv> Not yet ;)
<lifeless> with that, I'm going back to full screen editing;
<lifeless> oh
<lifeless> do you have anything that needs to land?
<lifeless> spm needs a guinea pig
<spiv> lifeless: Actually, I'm a little uncertain about how automatic recovery would interact with concurrent inserts.
<lifeless> spiv: so, automatic recovery would want to be a logical writer - and thus hold the external lock
<lifeless> There Can Be Only One
<spiv> lifeless: i.e. how can a process tell "I need to do a recovery" apart from "another process is mid-insert"?  Via the semantic write-lock?
<spiv> Ok.
<lifeless> spiv: I think it boils down to time
<spm> lifeless: is no rush; is more if we do it sooner vs later; but worst case we have a backup that can be failed to.
<lifeless> the critical section should be _very fast_
<lifeless> so waiting a second (say) and then offering would be appropriate.
<spiv> "should" :)
<spiv> Yeah, I think prompting the user is necessary.
<lifeless> anyhow, as I say, I'm designing to permit, not to implement automatic recovery.
<lifeless> like break-lock
<spiv> I'm thinking someone will try this on sshfs over a crappy, slow link at some point :)
<lifeless> the idea is to fail rarely, and only when the machine crashed
<lifeless> or that FTP server we had the other week
<spiv> Yep.
<lifeless> the one that took up to 10 minutes to delete files
<lifeless> There's a limit to which I'll design for that. Obviously-broken is not ok :)
<lifeless> I think this will work well on windows.
<lifeless> and Unix
<lifeless> spiv: so, do you have any to-land branches?
<spiv> lifeless: no, but apparently you do: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279
<lifeless> blah :P
<lifeless> no I don't
<lifeless> thats landed
<abentley> lifeless: you gave me a "needs fixing" on https://code.edge.launchpad.net/~abentley/bzr/fix_get_mtime/+merge/10544 but I replied that the requested fix wasn't suitable.  Could you please comment?
<spiv> lifeless: if you review https://code.edge.launchpad.net/~spiv/bzr/paramiko-keyboard-interactive/+merge/12559 I will...
<spiv> lifeless: (it's short)
<lifeless> abentley: will do
<spiv> lifeless: I can easily enough make an uncontroversial branch that removes some unused import lines if you like
<lifeless> beuno: / abentley: https://code.edge.launchpad.net/~lifeless/bzr/bug-423818/+merge/11279 - why is the 'change status' edit link at the far right
<lifeless> when on e.g. +me the edit thing is beside fields
<spiv> lifeless: it's just a matter of pointing mwhudson's pyflakes branch at practically any file in bzrlib :)
<abentley> lifeless: rockstar misunderstood an aspect of the 3.0 migration.
<lifeless> ok
<lifeless> is there a bug for that form, or would you like me to file one?
 * spiv mumbles "affects me too"
<abentley> lifeless: I'm not sure, but rockstar is aware that it needs to be changed.
<lifeless> ok, no need to for pointless bit-setting then ;)
<lifeless> spiv: doit
<spiv> lifeless: on the trivial imports, or the paramiko (or both?)
<spiv> (I'm doing the trivial atm :)
<lifeless> paramiko
<spiv> lifeless: cool, thanks
<barry> spiv: hello!
<spiv> barry: good afternoon :)
<lifeless> abentley: I've commented; you may need to escalate to Martin - I think its worth writing the code to do the path calculations
<barry> spiv: good evening :)
<spiv> :)
<barry> spiv: can i play dumb user and maybe we can walk through the upgrade instructions?
<spiv> barry: I have a message from the future for you: Tuesday is a good day :)
<lifeless> abentley: but my only data is years old now when I got close to inventory-free commits at 0.92 time
<barry> :)
<lifeless> beuno: have you read the upgrade guide?
<lifeless> bah
<lifeless> barry: ^
<spiv> barry: sounds good.
<barry> lifeless: sort of, but there are some holes missing that i think we should fill to make life easier for the next person
<barry> let me bring up the instructions on this box
<barry> spiv: let's start here: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad
<barry> #1.  i nominate myself )
<barry> er, :)
<barry> #2.  "unset the current trunk from being the development focus"
<lifeless> oh right, today is tuesday
<SamB_XP_> lifeless: is not!
<SamB_XP_> it's still monday
<barry> spiv: i think we need a lot more detail there.  unfortunately it is not obvious how to do this on launchpad
<barry> spiv: and, while i think i know how to do it, even then it's not 100% clear
<barry> spiv: so, let's try to do it and then let's document it so it's really easy for the next person
<barry> spiv: i start by going here: https://edge.launchpad.net/mailman
<barry> spiv: i click on 'Change detals'
<barry> spiv: i scroll down to Development focus
<barry> spiv: i click on the pull down menu
<barry> spiv: uh oh, i've hit my first snag.  i cannot "unset" this, i can only assign it to a different series, none of which are correct
 * spiv tries to play along on another project on staging
 * barry waits
<abentley> barry: You used to be able to set the branch associated with the dev focus via the registry pages.  You could set it to blank there.  I think this has been removed in 3.0
<spiv> barry: yeah, I see that too.
<barry> abentley: is that hiding somewhere behind a url hack perhaps?
<barry> abentley: iow, maybe the functionality is still there but the link to the page to do that got lost
<abentley> barry: You would know about the secret URLs of registry pages better than me.
 * barry has seen that in a couple of instances
<barry> abentley: heh
<barry> spiv: okay, so we've hit our first snag.  i'm updating my copy of the code to see if there's a hidden page somewhere for this.  if not, i will file a bug
<spiv> barry: https://edge.launchpad.net/mailman/3.0/+edit and blank the branch, maybe?  (try on staging perhaps)
<barry> spiv: good idea!
<spiv> barry: I hope you're keeping notes :)
<barry> spiv: i log all my irc sessions :)
<spiv> Close enough!
<rockstar> lifeless, the fix for moving change status is about to hit PQM (it's in ec2test now)
<barry> spiv: yep, i think that's it.  https://code.staging.launchpad.net/mailman
<barry> "A development focus branch hasn't been specified"
<barry> spiv: iirc, i will have to push my migrated branch under a name other than "3.0" because the latter is pack-0.92 and shouldn't be changed due to any stacking going on
<barry> spiv: so moving forward my dev focus branch will have to be something else unfortunately.  right?
<lifeless> rockstar: cool
<lifeless> barry: you can upgrade in-place too, which the guide doesn't documented
 * lifeless thinks in-place is nicer
<spiv> barry: Hmm, I'm not sure.  Launchpad might be smart enough there, but I'm not certain.  mwhudson, abentley, do you guys know?
<lifeless> but its a problem if contributors don't upgrade their stacked branches
<lifeless> spiv: lp doesn't rewrite the stack-on
<lifeless> spiv: so no, its not smart enough
<spiv> Drat.
<spiv> mwhudson, abentley: turns out lifeless knows everything :)
<barry> lifeless: yes, in-place would be nicer.  in this particular case, there is only one unmerged branch potentially stacked on it, and i can't merge it into my 0.92 branch anyway
<spiv> barry: So, sadly, yes.  Unless you upgrade in-place, as lifeless says.
<spiv> It might be good to mention that as an option in the upgrade guide, but at the same time overwhelming people with options isn't so good either.
<barry> spiv: okay.  let's try this.  let's finish the instructions as written, and then try an in-place upgrade.  then someone <wink> can document both
<barry> spiv: so actually, now i need to grab a copy of the trunk and do the migration.  talk to you tomorrow :)
 * barry is guessing it will take a while
<spiv> lifeless: btw: http://pqm.bazaar-vcs.org/
<lifeless> barry: winking isn't gonig to help :P
<lifeless> spiv: looks hopeful
<lifeless> spiv: next patch, turn on --subunit ;)
<barry> lifeless: i'll be happy to document the steps.  is doc.bazaar-vcs.org a wiki?
<lifeless> no
<lifeless> the upgrade guide is a branch somewhere
<lifeless> I suspect it may even be a separate project, and if thats so I have no idea where it is
<spiv> Isn't it part of the docs in bzr's source?
<tedg> I need some help "decoding" an error.  http://pastebin.ubuntu.com/280929/
<spiv> doc/en/upgrade-guide ?
<tedg> I'm unsure of where to start looking.  I'm thinking by the 17000 number there it's looking for an older SVN revsion than I have?
<spiv> tedg: on what command?
<tedg> spiv: bzr gannotate configure.ac
<SamB_XP_> tedg: it would ;-)
<tedg> Normal annotate gives approximately the same error.
<SamB_XP_> that, too, is expected
<SamB_XP_> I mean, that you would get the same error
<SamB_XP_> not that you would get an error ...
<tedg> Oh, good. I was confused :)
<spiv> tedg: yes, it appears that revision of that file is not present in your repo
<tedg> spiv: So how do I decode that revision number into something useful?
<spiv> Possibly due to a bug in the bzr-svn conversion?  /me checks if that is on Launchpad
<spiv> tedg: not sure what you mean by "useful" in this context?
<tedg> Well, it's not a conversion yet.  But hopefully will be soon... so I'm trying to get bugs out first.
<SamB_XP_> whatever it is it sounds like a bug!
<tedg> spiv: i.e., it's a missing SVN version.
<tedg> spiv: Or, it was because I used bzr-svn to merge in a branch that somehow it figured out about.
<SamB_XP_> tedg: how can you have a missing svn version ?
<tedg> spiv: Or, it's just foobar :)
<SamB_XP_> also that's spelled fubar
<barry> lifeless: i will at least email the public mailing list when i figure it out.  can you explain "migrate in-place" though?
<tedg> SamB_XP_: So the history of the repo is that it was converted from CVS.  But the way that SF did it is that they lumped everything into one repo, which was split out -- so there is a discontinuity around revision 20K which I believe that bzr-svn just sees as "the beginning of time"
<lifeless> there's also a mythic button on LP that says 'doit'
<tedg> Which honestly, is kinda fine.  As long as it's really "the beginning of time."
<SamB_XP_> tedg: that sounds kinda crazy ...
<tedg> SamB_XP_: People who know me, will not disagree with you on that one. :)
<SamB_XP_> what happens if you try to checkout the previous revision with SVN itself?
<tedg> Well, yes.  You kinda have to know the previous layout, which wasn't a "standard SVN layout" as it was in CVS.
<spiv> tedg: so there's a missing record in bzr's database.  It's for the configure.ac file introduced in SVN 17075, and it's modification you made to it in revision ted@canonical.com-20081121044907-chfl7r1x8s1kcp5n.
<spiv> tedg: I'm not sure why it's absent, but it's almost certainly due a bug somewhere along the line :(
<tedg> Ah, I see now.  It looks like the first SVK cherry-pick is the issue: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/configure.ac?view=log
<tedg> Which means there are most definitely other files with this problem.
<spiv> Oh, if you're trying to round-trip via the SVN repo, that might explain it I guess.
 * barry -> sleep
<spiv> That would presumably make all the foreign revisions be ghosts.
<barry> spiv, lifeless, abentley thanks.  we'll pick this up again tomorrow.  the future awaits
<tedg> spiv: No, not round trip in that regard.  The problem is that SVK (not SVN) did some very funny things with how it merged in.
<lifeless> night barry
<tedg> spiv: It records complex merges as odd copies with changes.  Borders on evil :)
<spiv> barry: g'night
<tedg> So if I could find all these "oddities" by hand.  Could I fix them with something like the rebase plugin?
<tedg> If I assumed that I'd never go back to SVN again.
<tedg> For those who are curious here's the rev where the repo was converted from CVS to SVN and rearranged: http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=10643
 * igc lunch
<spiv> tedg: so, that particular data appears to still exist in lp:~ted/inkscape/devbuild
<spiv> (and some of your other Launchpad branches)
<spiv> tedg: so if you rebranch that into your local repo that might be enough to fix it (i.e. to copy the data that is missing locally)
<lifeless> 50% there
<lifeless> .oO
<lifeless> interface tests passing
<abentley> lifeless: I've replied.  The gist is that you're asking for complicated code that will only be used in a corner case and usually won't prevent a path<->id map being generated.
<tedg> spiv: Sorry, I walked away... I'll give that a try!
<tedg> spiv: Just to be curious, how did you find that out?
<lifeless> does anyone here have a windows machine?
<rbistolfi> Peng_, lifeless: Sorry I got an emergency and I was afk
<rbistolfi> re: http://pastie.org/633561
<rbistolfi> I am not behind a proxy and I dont know if it is a privete branch, I just found it in launchpad
<lifeless> rbistolfi: its not
<Peng_> I branched it, so I guess it's not a private branch.
<Peng_> Eh, there we go.
<lifeless> rbistolfi: the error you have looks like a interecepting proxy to us
<abentley> lifeless: I have a windows machine.
<lifeless> abentley: I need to know what exception dirstate raises
<Peng_> Or, something just went Horribly Wrong with the connection.
<lifeless> could you do a small test for me?
<abentley> lifeless: Okay.
<lifeless> given a bzrlib wt4 tree at path foo
<lifeless> state1 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
<lifeless> state1.lock_read()
<lifeless> state2 = bzrlib.dirstate.DirState.on_file('foo/.bzr/checkout/dirstate')
<lifeless> state2.lock_write()
<spiv> tedg: http://paste.ubuntu.com/280963/
<lifeless> the last line should raise something from bzrlib.errors
<rbistolfi> lifeless, Peng_: thanks, I will try to branch from a server I admin connected to another isp, maybe I am being intercepted after all
<lifeless> you'll want to state1.unlock(), and you're done.
<tedg> spiv: Didn't go well: bug 438509
<ubottu> Launchpad bug 438509 in bzr "Crash when branching into repo" [Undecided,New] https://launchpad.net/bugs/438509
<lifeless> I should say, wt4 or newer, anything dirstate based
<spiv> tedg: oh wow, I haven't seen that assert triggered before
<tedg> I assume I get some kind of award? ;)
<spiv> tedg: I wonder if that's a symptom of the same problem, I suppose it could be...
<abentley> lifeless: I have 1.2.0dev0 on my Windows box, and it seems to be broken, too.
<lifeless> abentley: bzrlib is broken, or the python I gave you is broken?
<abentley> lifeless: bzrlib is broken.  "bzr init foo" fails.
<lifeless> oh, eep
<lifeless> abentley: is the tree you have there dirstate based? if so you don't need to init...
<abentley> lifeless: It is a lightweight checkout from an ext3 partition which has since been reformatted.
<lifeless> works for me
<lifeless> as long as it has a dirstate file the results should be useful
<lifeless> windows OS locks will mutually exclude the two locks
<lifeless> I just need to catch the error so my test for dirstate2 doesn't blowup on windows
<spiv> tedg: I wonder if making a new shared repository ("bzr init-repo --1.9-rich-root") and branching lp:~ted/inkscape/devbuild into that and then your other local branches would work better?
<abentley> lifeless: I get errors.LockContention
<lifeless> thank you very much
<abentley> lifeless: You're welcome.
<spiv> tedg: FWIW, bzr 2.0.0 should be much more aggressive about preventing incomplete data to be committed in the first place.
<tedg> spiv: No, similar error.  Are the details useful?
<spiv> Obviously that doesn't help your existing situation (unless you have a time machine), but I thought I should reassure you a little bit :)
<tedg> spiv: I am running 2.0 now... should I reimport the repo?
<spiv> tedg: Did it fail on the first branch?
<tedg> spiv: I had a copy of devbuild locally in a shared repo, I then branch the branch in the new shared repo over.
<spiv> tedg: please use the copy from Launchpad
<spiv> Because we know that that copy has that missing record in its repo.
<spiv> "bzr check" on your local repos might be interesting, probably it will report the same issue.
<spiv> I just successfully branched lp:~ted/inkscape/devbuild from Launchpad, so it appears that that copy isn't missing anything that it is supposed to have.
<lifeless> ok, dirstate2 works
<lifeless> time to put a tree on it and user-level test it
<spiv> lifeless: nice
<lifeless> I just wish we'd not been scraping performance issues right up to 2.0.0
<lifeless> this would have been so nice to have in there
<spiv> lifeless: yeah.
<lifeless> I've had this in my head for about a year
<lifeless> as a 'TUIT' problem
<rbistolfi> lifeless, Peng_: well if I tunnel my conection through Miami I can branch it just find, I think that fits well with the proxy theory. I have pretty much the same setup in both machines.
<rbistolfi> s/find/fine/
<Peng_> You can avoid the issue, and get a speed boost, if you get a LP account and use bzr+ssh.
<rbistolfi> I will do, tyvm
<tedg> spiv: Okay, so branching that way makes the error MUCH larger: http://pastebin.ubuntu.com/280979/
<tedg> spiv: Still running the check.
<spiv> tedg: hmm, looks like text versions from the original SVN import are missing somehow!
<spiv> Very odd.
<spiv> Oh, that's interesting; one way the missing text revisions were svn-v4:..., the other they are svn-v3-trunk:...
<tedg> So could it be a disagreement between versions of the SVN plugin?
<spiv> I wonder if a "bzr svn-upgrade" somewhere along the line is part of the cause...
<tedg> I don't think there is a svn-upgrade.
<spiv> Hmm, I'm sure there used to be a command that would rebase revisions from an older version of a plugin to use the new mapping.
<spiv> s/a plugin/the svn plugin/
<spiv> Yes, there was definitely a "bzr svn-upgrade" in the past, I wonder why it's gone now.
<spiv> Ah, it's now "bzr foreign-mapping-upgrade"
<tedg> spiv: I don't seem to have that command, is it in a plugin?
<tedg> The bzr check is still running... is there a point I should give up?
<lifeless> spiv: your patch landed?
<tedg> spiv: It seems to be in rebase.  But I can't get it to work.
<tedg> It basically says the SVN repository isn't a repository.
<igc> bbiab
<spiv> lifeless: yes
<spiv> tedg: I'm not very familiar with it, I was just speculating that it may have been involved in the history of this branch.
<tedg> I think I'm going to try a new import tonight with the new and shiny 2.0 and see if that helps... start fresh tomorrow.
<tedg> spiv, thanks for your help!
<spiv> tedg: you're welcome, sorry I couldn't be more helpful
<lifeless> \o/
<lifeless> WTFormat7 passes interface tests
<fullermd> Does that mean it works right, or that the tests have insufficient coverage?  :p
<lifeless> fullermd: bit of both
<lifeless> fullermd: I suspect that its possible to make it delete the HASH file for the current pointer with a sufficiently clever flip-flop state change at the moment
<lifeless> fullermd: so I want to add a random seed to the state files
<lifeless> fullermd: or tweak that more, before folk are doing more than play with it as a shiny shiny
<lifeless> fullermd: however, you can do a diff while a commit editor is open
<spiv> lifeless: oh yeah, that reminds me
<spiv> lifeless: I was also going to ask about two concurrent stat cache updates to the same state
<spiv> Which may be why you want some random bits in the filenames?
<lifeless> spiv: same issue ;)
 * spiv nods
<lifeless> yes
<lifeless> in practice, doing 'bzr add foo' 'bzr rm foo' with no other changes can flip flop
<lifeless> doing 'bzr diff' and keeping the process alive in a GUI in between could cause something that sees the old state around
<lifeless> but I'm /not sure/ you can force destructive behaviour without being able to run stat fingerprints backwards
<lifeless> I think simply putting the 'lazy delete' inside the 'I own the current file' "mutex" may be sufficient.
<lifeless> though if we start doing that I may simply start using regular lockdirs to do the locking, though they will be a lot slower.
<lifeless> its fun to close 6 bugs with one push :)
<lifeless> heh, I lied, 7
<lifeless> poolie: are you here, or is it just a bot?
<lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/dirstate2 :)
<lifeless> note the bug list ;)
<lifeless> ahhh bugspam
<vila> hi all
<igc> hi vila
<igc> out for a bit - bbl
<bialix> hello all
<bialix> (ru) people asking about comparison of 2a format to hg/git: storage size, speed. Is there already exists one, or planned?
<vila> hello bialix
<bialix> bonjour vila
<fullermd> I'm not aware of a useful existing one.  fast-import probably makes it a lot easier to put one together though.
<vila> igc ran tests and should have a few numbers
<vila> but, AIUI, there is no absolute rule here, what I understand is that 2a has sizes comparable with hg/git, sometimes better, sometimes worse, but always in a reasonable amount
<vila> for speed, things are even more unclear as benchmarks are like statistics...
<vila> now, all of that is also highly subjective and on that front people seem quite happy :D
<bialix> it seems so
<bialix> but anyway I'd better asking
<fullermd> A historical problem with those sort of comparisons is that they're often done on trees with no history.  I'd be very happy to never see such a thing again...
<bialix> fullermd: IIUC fast-import should be a key here
<fullermd> ("Oh, look, I benchmarked VCS A, B, and C on importing two tarballs of a project.  Now we all know what's faster and smaller.")
<bialix> convert the same repo into different systems
<bialix> tarball is a wrong attempt IMO
<fullermd> Yah.
<vila> fullermd: hmm, I don't think that's the case anymore but may be the more recent benchmarks need more exposure...
<lifeless> I saw someone test a single commit benchmark just riday
<lifeless> *friday*
<lifeless> :)
<fullermd> Yeah, they come up with painful regularity out around the Interblog.
<fullermd> 'course, historically, we wouldn't want to argue against that, since it painted bzr in a better light than otherwise   :|
<lifeless> by which you mean only slightly worse than tar?
<vila> the last benchmarks igc produced showed that bzr was not the best for all operations, I think that's enough to make it an honest one :D
<fullermd> Back around 1.0, we had claims of speed and size comparable to brands G and H.  And the benchmarks to back them up; we were of similar overall speed and similar (or better!) size on disk!
<fullermd> ... for projects with one revision...
<bialix> so, good benchmark will depend on how good and robust fast-import conversion
<spiv> vila: can you help with testing my fix for https://bugs.launchpad.net/bugs/433846 ?
<ubottu> Launchpad bug 433846 in bzr "[ssh/sftp] failure to do password auth with paramiko when server only supports 'keyboard-interactive'" [High,Fix committed]
<vila> spiv: I still haven't a working windows setup :-/
<fullermd> Yah, without some way of getting as-nearly-as-practical identical sizable histories in both tools, any benchmark is going to be of very limited use.
<vila> spiv: that what you need here right ?
<fullermd> Luckily, fast-import fills that niche nicely   :)
<spiv> vila: that would be ideal
<spiv> vila: it's not really Windows-specific, but it would be nice to test a scenario as close to the actual reporters as possible.
<spiv> vila: if you don't have working Windows I'll do some Windows-less testing myself.  Thanks.
<vila> spiv: you're welcome :-/
<spiv> vila: (alternatively, if you can push a button and produce a test Windows installer with that fix we can offer to the reporter, that would do ;)
<vila> lol
<bialix> lol
<fm> i just hit http://pastebin.com/m6fa4b0de
<vila> spiv: unfortunately even the installer builds are failing on kerguelen for quite a few days now :-/ And they are outdated anyway AIUI
<fm> vila: can you look at the backtrace?
<bialix> fm: bzr unable to version control fifo
<fm> but it gives an internal error ...
<bialix> file a bug please
<bialix> bzr should not allow you to add fifo in first place
<bialix> or maybe some of your entries was plain file/symlink and now fifo
<fullermd> Hm, it'd be fun to be able to 'revert' a FIFO...
<vila> fm: definitely a bug to be filed, bzr shouldn't backtrace, as a workaround, try to identify which file is a fifo and bzr ignore it
<fm> bialix: https://bugs.launchpad.net/bzr/+bug/438569
<ubottu> Launchpad bug 438569 in bzr "bzr gives internal error on fifo" [Undecided,New]
<vila> great
<BjornT> jelmer: i'm trying to use bzr-git to branch from github, but after exactly 5 minutes i get this error: http://paste.ubuntu.com/281091/
<BjornT> jelmer: do you know why that would be? i can access github using git without any problems
<jelmer> BjornT: bzr/bzr-git doesn't support rsync-style URLs
<jelmer> BjornT: and it is not yet possible to fetch individual branches (as we have no way to address branches that are not on the filesystem)
<jelmer> BjornT: you might want to try 'bzr branch git://github.com/bjornt/windmill.git'
<jelmer> BjornT: or s/branch/git-import/ (for all branches, not just HEAD)
<Tak> jelmer: ping
<jelmer> Tak: pong
<Tak> hi
<Tak> would you like for me to merge your 2.0 changes before merging 2.0 into ... what is that called, mainline?
<jelmer> Tak: please do
<jelmer> Tak: yeah, mainline/trunk/ whatever you want to call it :-)
<Tak> yeah, I have a habit of referring to my development branch as "trunk", plus there's another one actually labeled "trunk" I think ... :-P
<Tak> ok, doing that now
<gioele> Hello
<Tak> hello gioele
<gioele> What is the state of keyword expansion? bzr help content-filters does not says nothing specific about keyword expansion. Also, in the wiki there are only old (2004/2005) blueprints
<spiv> gioele: I think you need the bzr-keywords plugin (https://launchpad.net/bzr-keywords)
<spiv> gioele: which hooks into the content filtering feature in core bzr
<gioele> Do lightweight checkouts have to be in the same format of the remote branch?
<beuno> gioele, it probably needs to at least be rich-root or non-rich-root
<beuno> and, different formats will likely make it slower
<eLBati> hi
<eLBati> I can't understand why this happens
<eLBati> 8# bzr checkin -vm "first translation" index.rst
<eLBati> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<eLBati> launchpad-login is set
<eLBati> but what is checkin trying to do? shouldn't it do a local checkin?
<eLBati> uhm it does so with every command
<mzz> eLBati: what does "bzr info" say?
<vila> eLBati: you created a checkout from a branch you can't commit to
<mzz> eLBati: I'm guessing you created a checkout where you wanted a branch
<Lo-lan-do> Hi all
<Lo-lan-do> jelmer, james_w: I'd like to upload loggerhead to unstable and add myself as an uploader if it's all right with you.
<mzz> eLBati: if that's indeed what happened I think you can use "bzr reconfigure" to turn it into a regular standalone branch you can commit to
<Lo-lan-do> jelmer, james_w: Also, I'll need to get it into bpo at some point, do you have a procedure for that?
<eLBati> mzz, yes it's a checkout
<eLBati> so, with a checkout I can't commit?
<mzz> eLBati: you can only commit to a checkout if you can commit to the thing it is a checkout of
<mzz> eLBati: (it commits to the branch the checkout is "bound" to first, then locally)
<mzz> eLBati: to avoid this use "bzr branch" (or the alias "bzr get") to create a standalone copy of the remote branch instead of "bzr checkout"
<jelmer> Lo-lan-do: please do
<jelmer> Lo-lan-do: we don't have any procedure for bpo uploads
<eLBati> thanks mzz
<Lo-lan-do> jelmer: I don't even know how to do an upload to bpo :-)  I'll read up on that.
<james_w> hey Lo-lan-do
<james_w> does loggerhead now use the system yui correctly?
<Lo-lan-do> james_w: It does, but unfortunately the system yui isn't the same as the one expected by loggerhead.
<Lo-lan-do> LH uses 3.0rc2, whereas sid only has 2.7something.
<Lo-lan-do> So unless --use-cdn is used, some of the Ajaxy things are broken.
<Lo-lan-do> I guess I could add a check for the presence of an appropriate version, and add the --use-cdn switch if needed.
<eLBati> what is target configuration of bzr reconfigure?
<Lo-lan-do> eLBati: It's what you want to turn your directory into.
<Lo-lan-do> jelmer, james_w: Any thoughts about this automated use of remote YUI?
<james_w> I'm not sure it would go down well in some comments
<james_w> some contexts I mean
<james_w> I'm not sure we should be using the system one if it is the wrong version
<james_w> 2 and 3 are basically different projects as I understand it, so trying to force it seems unnecessary
<Lo-lan-do> jaldhar tells me he'll upload yui 3 soonish.
<eLBati> thanks Lo-lan-do
<james_w> cool
<Lo-lan-do> I guess I could revert the "use system yui" patch until thenâ¦
<Lo-lan-do> Oh well, I'll just document the "feature" until yui3 appears, and then I'll use a versioned dependency.
<eLBati> mzz, # bzr reconfigure --branch
<eLBati> bzr: ERROR: Working tree "..." has uncommitted changes
<mzz> eLBati: --standalone
<eLBati> I just did a checkout
<mzz> eLBati: I know. bzr reconfigure --standalone
<mzz> or "bzr unbind", actually.
<eLBati> thanks mzz
<eLBati> if I have uncommited changes, how could I undo such changes and get the repository version of files?
<dash> you can do "bzr revert" if you want to remove those changes
<dash> or "bzr shelve" if you want to save them for later
<eLBati> thanks
<igc> night all
<Tak> can one dpush from an unbound checkout?
<jelmer> Tak: yes
<jelmer> Tak: unbound checkout == standalone branch
<Tak> yeah - I didn't know if there were some internal semantics that would make it work differently
<Tak> thanks
<mzz> an unbound (heavyweight) checkout *is* a standalone branch, so I don't know what kind of "internal semantics" you mean
<mzz> (they're not equivalent or the like, unbinding the checkout turned it into exactly a standalone branch)
<awilkins> Yeesh, --2a might be the New Hotness, but it repacks a lot slower than older formats
<awilkins> It's just taken 15 minutes to repack ~800MB
<mathrick> hi
<mathrick> http://pastebin.com/m6d14728b
<mathrick> what gives?
<mathrick> it's not an error that makes any sense to me
<Lo-lan-do> mathrick: You're in a repo, not in a branch inside that repo.
<Lo-lan-do> The branches are probably in a subdir?
<idnar> heh, that's ironic, I just did that myself about 2 minutes ago
<mathrick> Lo-lan-do: oh, so that means I forgot to init that dir. No good :(
<mathrick> thanks
<idnar> the message is a bit confusing
<mathrick> it is
<idnar> although I immediately figured out my problem when I saw what directory I was in
<mathrick> I thought I had it init'd already
<mathrick> hmm
<mathrick> is there an option to make bzr add symlinks by their pointed-to contents?
<mathrick> add/commit, really
<mathrick> oh, it's the incremental commit plugin interfering
<Tak> hooray!
<Tak> my mysterious bzr-svn crash was being caused by the dbus plugin
<awilkins> ubottu: #43805
<ubottu> Sorry, I don't know anything about 43805
<awilkins> ubottu: #438805
<ubottu> Sorry, I don't know anything about 438805
<awilkins> Gah
<mathrick> ubottu: bug #43805
<ubottu> Launchpad bug 43805 in apmd "apm kernel modules are loaded after hal" [Medium,Fix released] https://launchpad.net/bugs/43805
<awilkins> https://bugs.launchpad.net/bzr/+bug/438805
<ubottu> Launchpad bug 438805 in bzr "Missing referenced chk root keys" [Undecided,New]
<mathrick> hmm
<mathrick> ubottu: bug #43805 in bzr
<mathrick> it doesn't seem to understand that
<awilkins> Wrong bug number ... they're globally unique per LP instance AFAIK
<mathrick> oh
<awilkins> Just doing a `bzr check` on the repository that's provoking the problem
<mathrick> right
<mathrick> okay, thanks for the help, gotta be going
<tolstoy> Anyone having issues running on Snow Leopard using the installer?
<tolstoy> bzr: ERROR: Unsupported protocol for url "sftp://kirwin@host/path/to/code/": Unable to import paramiko (required for sftp support): No module named paramiko
<tolstoy> Who put together the installer anyway? No one to email!
<kirkland> is there a way to pass -uc -us to bzr builddeb ?
<kirkland> it didn't "just work"
<tolstoy> jfroy|work: Hi, I'm the one with the snow leopard error from twitter.
<jfroy|work> tolstoy: hey
<jfroy|work> so basically I didn't include paramiko in the 10.6 installer.
<jfroy|work> And it seems that was the wrong decision.
<tolstoy> Yeah.
<jfroy|work> The initial thought being that the bazaar installer should only install bazaar and nothing else.
<tolstoy> Heh. ;)
<tolstoy> Well, you know how people are about dependency hell.....
<tolstoy> Seems like there should at least be enough there to support all the commands.
<tolstoy> I just tried "bzr miss sftp://me@host:/path/to/project" and it errors out.
<jfroy|work> well it's not that it doesn't support all the commands
<jfroy|work> it just won't support sftp transports
<tolstoy> Isn't sftp kind of fundamental? (I don't really know. I've always used it, though.)
<jfroy|work> I don't use it ever.
<LarstiQ> jfroy|work: or ssh in certain cases
<jfroy|work> I use the smart server or work with svn repositories.
<Lo-lan-do> Isn't "dependency hell" kind of 1998?
<jfroy|work> Lo-lan-do: unfortunately, Mac OS X doesn't really have a good story w/r to dependency management.
<tolstoy> Exactly.
<jfroy|work> Well not for binary packages anyways.
<jfroy|work> In any case, I'm going to bake another installer.
<tolstoy> That would be awesome.
<tolstoy> Hm. The only other thing I could think of is a bzr command to settle dependencies on its own.
<tolstoy> Which seems kind of, well, out of scope.
<jfroy|work> no
<jfroy|work> a better idea would be for bzr to offer to install those dependencies
<jfroy|work> something like "SFTP support requires Paramiko, which you do not have installed. Would you like to from PyPI? Yes | No", and if yes run sudo easy_install paramiko
<jfroy|work> done
<jfroy|work> that would be classy
<jfroy|work> and broken on Linux and Windows, but that's a detail :p
<tolstoy> Heh. Works for me.
<jfroy|work> verterok: ping
<tolstoy> You could even keep stats, and if practically everyone always installs paramiko, might as well bundle it in the original install.
<verterok> jfroy|work: pong
<jfroy|work> verterok: did you push a new packaging branch and all. Might want to rebake the 10.6 installer using that.
<verterok> jfroy|work: I started working on something, lp:~verterok/+junk/OSX-package
<verterok> jfroy|work: it adds the "download all stuff before build" script
<jfroy|work> ok, I'll just use my setup for now just to quickly rebake
<verterok> jfroy|work: ok :)
<jfroy|work> baking....
<jfroy|work> pretty easy to do now once that the infrastructure is in place :)
<jfroy|work> one further improvements would be to use remote packages for optional installs (to keep the download small)
<jfroy|work> and sign the packages
<jfroy|work> *and another to sign
<james_w> kirkland: "bzr builddeb -S -- -uc -us"
<james_w> annoying I know
<kirkland> james_w: ah, thanks
<james_w> it will "just work" one day
<jfroy|work> And there we go, new installer up.
<jfroy|work> Enjoy your paramiko flavored goodness.
<jfroy|work> tolstoy:
<tolstoy> I'll give it a try! Thanks.
<tolstoy> jfroy|work: http://bazaar-vcs.org/MacOSXDownloads, right?
<jfroy|work> yeah
<jfroy|work> it's feeding off my blog right now.
<tolstoy> It is larger.
<jfroy|work> which scares me :p
<tolstoy>   from sha import *
<tolstoy>    /Library/Python/2.6/site-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
<tolstoy>   from sha import *
<tolstoy> I think it works, but there's that "interesting" output. ;)
<tolstoy> jfroy|work: This has got to be such a headache for you.
<tolstoy> jfroy|work: Maybe link against the Python 2.5 lib? Seems to be installed on my Snow Leopard, anyway.
<Pilky> tolstoy: I think he links against 2.6 as that allows for 64 bit
<Pilky> tolstoy: I think 2.5 is only 32 bit on snow leopard
<tolstoy> Ah (drkirwin here). It seems reasonable. Wonder why there's the deprecation warning, then?
<Pilky> could be that it is deprecated, but paramiko hasn't been updated to use hashlib?
<fullermd> No, that's from pycrypto.  It needs a patch to not throw deprecation warnings against py2.6.
<fullermd> It works, it's just noisy.
<tolstoy> Right. I was able to push my changes.
<jfroy|work> tolstoy: I target Python 2.6 on SL because it's the default interpreter and because it's 64-bit
<jfroy|work> and bzr eats memory like candy
<tolstoy> jfroy|work: Works for me. Well, except for those pesky deprecation warnings.
<mwhudson> jelmer: does bzr-git support accessing git over http?
<jelmer> mwhudson: no, not yet
<mwhudson> rockstar: ^^
<jelmer> mwhudson: bug 373688
<ubottu> Launchpad bug 373688 in dulwich "support for HTTP git repositories" [Wishlist,Triaged] https://launchpad.net/bugs/373688
<Meths> I'm getting a file lock issue using bzr (1.18) shelve on Windows, even after a reboot, are there any known issues with shelve?
<tolstoy> Well, gotta go.
<tolstoy> jfroy|work: I'll see if there's a new package later this afternoon (PST) that fixes the deprecation working. I mean, if it's in the works.
<jfroy|work> There isn't, it's a problem with PyCrypto.
<tolstoy> Oh. So all snow leopard BZR users will have to see those messages indefinitely?
<tolstoy> So, bzr, on snow leopard, using the installer, spews deprecation messages for every sftp operation.
<tolstoy> How should I report that? Launchpad bug?
<tolstoy> It's not an installer issue?
<bialix> tolstoy: at least you can send message to main bzr ML or to bzr-mac one
<tolstoy> Okay. I didn't realize there was a bzr-mac list. I'll look it up.
<lifeless> moin
<RAOF> mushi mushi.
<lifeless> mmm sushi sushi
<RAOF> Not for breakfast, thanks.
<dkobozev> hi all. i have a workflow-related question.
<dkobozev> i'm working on a php website. i have a bunch of php files that should go into public_html folder. plus, i have a database schema file and a db dump with test data.
<dkobozev> the latter two shouldn't go into public_html, obviously. what would be the best way to manage these with bzr?
<dkobozev> creating two separate branches - one for php files, one for db files - seems very impractical.
<fullermd> I use a single branch, but use scripts to deploy the files that need to be deployed.
<dkobozev> like post-commit hooks in svn?
<fullermd> No, like Makefiles.
<fullermd> I (speaking for nobody but myself, natch) am a firm believer in separation of VCS and deployment.
<dkobozev> so you would keep both php and db files in public_html in my case?
<fullermd> No, I'd keep both in the _bzr branch_.  And the bzr branch out of public_html.
<dkobozev> got it.
<fullermd> Then I do the equivalent of a 'make install' to copy the files into place for deployment.
<fullermd> (though my dev environment is actually often a symlink into the subdir of the branch where the files are)
<fullermd> But that's just local anyway.
<dkobozev> i like the symlink idea...
<fullermd> Yeah, it streamlines the dev process.
<dkobozev> are there any security implications to having a symlink to a branch subdir vs copying the files to public_html?
<fullermd> Though it sometimes requires a little fiddling, since what's in the branch isn't always directly workable (another reason for the install scripts)
<fullermd> Well, if you copied everything under that subdir, it would be equivalent.
<jelmer> lifeless: What's the easiest way to get my key in the PQM updated?
<fullermd> Hard to say much beyond that; it's pretty case-by-case what exactly is where.
<fullermd> But the root of my branches 'typically' has two dirs, a db/ where the database schema and such live, and a src/ which is roughly a mirror of how the deployed files look.
<fullermd> (there are differences, e.g. which config files are enabled in different deployments, which the Makefiles handle)
<dkobozev> yeah, config files is another consideration. i usually do not put them under version control at all, which is not nice sometimes.
<fullermd> My default skeleton that I branch from for new projects has a live.conf and a dev.conf.  The install process symlinks one or the other (as appropriate) to the 'real' config file name.
<fullermd> And in manual environments, I .bzrignore the 'real' name and symlink as appropriate, or have the code default to loading the dev if the normal name isn't there, or various other permutations.
<fullermd> By not deploying via VCS, I'm freed from having to have the stuff under version control be an exact replica of the deployed state, which gives me flexibility for those sort of customizations.
<fullermd> The downside, which people who swing the other way will point out, is that now I have two systems to deal with (and probably one of them to maintain myself).
<dkobozev> what language do you use to write your install scripts? bash?
<fullermd> For me, that's trivial overhead with big gains.  I can see that the scales may be reversed for other people.
<fullermd> At the moment, they tend to be Makefile's, so the real work is done by gobs of standard *nix utils (mostly install(1)).
<fullermd> Though special cases sometimes call for more specific sh scripts or throwing something together with awk or perl or...
<dkobozev> i'd say it would have to be a pretty big project for such heavy machinery :)
<fullermd> I do my best to slaughter all the special cases, but they keep creeping in under the door at night...
<dkobozev> you pointed me in an interesting direction. somehow, i never considered tools such as make for web development.
<fullermd> Always look at every possible tool for a job, and ask yourself, "Will using this make people think I'm a giant nerd?"
<fullermd> If the answer is 'hell yeah', wallow in it   8-}
<lifeless> jelmer: make sure its updated on the keyservers, and ping spm
<dkobozev> true enough. but i also dislike killing flies with nukes and napalm :)
<dkobozev> and thanks for the symlink suggestion. i'll use that or something similar.
<jelmer> lifeless: thanks
<fullermd> Pfft.  The surest way to kill a fly is to destroy the planet it's on!
<abentley> lifeless: What's the correct URL to submit to the 2.0 branch?  I tried bzr+ssh://bazaar.launchpad.com/~bzr-pqm/bzr/2.0
<lifeless> abentley: I think its http; its in the docs
<lifeless> I'll just check my locations, one sec
<lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> abentley: ^
<abentley> lifeless: Thanks.
<dkobozev> fullermd: if it's worth doing, it's worth over-doing, eh?
<lifeless> black holes
<lifeless> only way to be sure
<lifeless> jelmer: bug 438959
<ubottu> Launchpad bug 438959 in bzr-svn "annotate breaks on ghost text revisions" [Undecided,Invalid] https://launchpad.net/bugs/438959
<lifeless> jelmer: seems valid to me: user does something, gets error.
<jelmer> lifeless: it's still valid, but assigned to bzr
<jelmer> lifeless: not bzr-svn
<lifeless> ok
<lifeless> thanks
<jelmer> ls
#bzr 2009-09-30
<spm> jelmer: heyo, need a key updated?
<jelmer> spm: hi!
<jelmer> spm: Yes - I have a new GPG key, D729A457 and would like to use it in the Bazaar PQM
<spm> kk
<lifeless> jelmer: done a key transition document ? :)
<jelmer> lifeless: no, that's a good point actually...
<SamB_XP> especially important is a section on going back in time and preventing yourself from losing the previous key in the first place ...
<spm> jelmer: sorry, got a tad distracted on other stuff tehre; that key is now imported, so should be fine and dandy.
<awilkins> jelmer: I've split all those branches in the big repo into separate repositories since they probably don't have much in common apart from being for the same project ; one other branch was broken by that missing object
<awilkins> I've kept the old repo but I can't release it.. it bother me that "check" ran OK on it even though it was broken
<awilkins> Anyway sleeptime
<lifeless> spiv: got any specific network stuff you want me to look at this week?
<spiv> lifeless: not off the top of my head.
<lifeless> k
 * lifeless goes back to dirstate 
<jelmer> spm: Cool, thanks!
 * igc bbl - out for a medical visit
<lifeless> abentley: is there a tag for tree transform bugs?
<spiv> lifeless: four bugs (2 open) have 'treetransform' (which was my first guess).
<jfroy|work> OK, so people are complaining about the PyCrypto warnings
<jfroy|work> Should I just outright patch PyCrypto?
<fullermd> I'd say so.  It's a pretty simple patch.
<Peng_> I think people have done just that; maybe Ubuntu?
<fullermd> There's a patch on LP somewhere for it.  The FBSD port of it has a functionally identical patch.
<jfroy|work> Done deal.
<fullermd> http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/py-pycrypto/files/python25%2B.txt?rev=1.1
<fullermd> Should DTRT with older versions too.
<barry> lifeless: ping
<barry> or spiv perhaps?
<lifeless> hai
<barry> lifeless: hiya.  yesterday you mentioned in passing upgrading my branch "in-place".  what did you mean? :)
 * spm waves hi to barry with the RedHat son ;-)
<lifeless> barry: 'bzr upgrade lp:FOO'
 * barry waves and reminds him it was a /Ferrari/ hat!  he's got an ubuntu laptop fer gosh sakes :)
<lifeless> barry: will upgrade that branch; if its a branch that other branches are stacked on, you have to upgrade the stacked branches too or they will stop working
<barry> lifeless:  gotcha, thanks.  i'm going to try it.  i think there are few if any stacked branches
<blueyed_> why are >50mb being uploaded to a stacked branch (where I have branched from, changed some files, and now are pushing back to)?
<blueyed_> format changes?
<blueyed_> $ bzr push lp:~blueyed/b2evolution/slug-history
<blueyed_> Using default stacking branch /~blueyed/b2evolution/trunk-cvs at lp-46127440:///~blueyed/b2evolution
<blueyed_> [#########-          ]  51621KB   116KB/s | Fetching revisions:Inserting stream
<SamB_XP> blueyed_: could be ...
<spiv> No, the formats are the same.
<lifeless> spiv: sure about that ?
<lifeless> blueyed_: can you pastebin the end of your ~/.bzr.log ?
<spiv> lifeless: well, Launchpad is!
<lifeless> spiv: on the server end yes
<lifeless> spiv: but old bzr + on the fly conversion ...
<lifeless> spiv: note that blueyed_ branched *from* an existing stacked branch, so there wouldn't be a warning about the formats as the branch isn't being created
<spiv> Oh, I see
<spiv> Certainly, the revids for say rev 8249 are the same in the two branches, so there should be common history.
<lifeless> right
<blueyed_> lifeless: http://pastebin.com/m22326b2c
<blueyed_> nothing about stacking in the log though.
<lifeless> blueyed_: oh, and whats your bzrv ersion ?
<blueyed_> lifeless: karmic, 2.0..
<blueyed_> 2.0.0
<lifeless> ok
<lifeless> what does 'bzr info' show for your local branch ?
<lifeless> blueyed_: the branch on launchpad doesn't claim to be stacked when I examine it
<lifeless> blueyed_: and in fact, its a pack-0.92 branch, which doesn't support stacking
<blueyed_> but bzr told me about it, when pushing?! what can I do to make it stacked? I thought LP would do so automatically?
<lifeless> blueyed_: so I think the answer is 'its not stacked' ;)
<blueyed_> ok :)
<blueyed_> I need to upgrade and push the trunk branch?
<blueyed_> (which is autogenerated via tailor)
<lifeless> blueyed_: upgrade your trunk branch to something thats supports stacking, such as 1.6 (the minimum) or 2a (one way conversion but worth doing :))
<blueyed_> ok, thanks.
<blueyed_> good night
<lifeless> gnight
<spiv> Oh, right, that's one of those confusing "Using default stacking ..." messages that are actually emitted on stderr on the server.
<lifeless> I'm starting to hate the big red border
<jfroy> I have a new Snow Leopard package to upload to LP with a patched PyCrypto.
<jfroy> http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg
<jfroy> Whoever can do that :)
<lifeless> jfroy: have you digitally signed it ?
<lifeless> gpg --armor --sign --detach-sig Bazaar2.0.0-3.pkg
<jfroy> Hum, that would require me to have a gpg signature :p
<lifeless> ok
<jfroy> I can sign the package with a certificate however
<lifeless> I urge you to do that in future, it makes it easier :)
<lifeless> its uploading now
<jfroy> "that"?
<lifeless> should I delete the -2 version?
<jfroy> Yes
<lifeless> [get a GPG sig]
<jfroy> Right, I can get that.
<jfroy> Not that anyone would trust me :|
<lifeless> you can get in the global web of trust pretty easily
<lifeless> where are you geographically?
<jfroy> Cupertino, CA
<lifeless> Dead Easy
<lifeless> back shortly
<fullermd> I can't have web of trust discussions.  I found out that it takes an average of 4 minutes (with 1 sigma of about 2.5 min) to get into the metaphysics of identity, then everything falls apart.
<lifeless> yes, but you use FreeBSD :P
<dash> jfroy: heh i'm in santa clara
<spm> my observation is most people ignore the 'trust' part. They want certainty in an uncertain world.
<fullermd> Well, it SAYS it's FreeBSD anyway.  I don't know whether to trust that claim...
<jfroy> spm: and an untrusted signature gives you none of that.
<jfroy> :p
<dash> jfroy: i work in cupertino though :D
<lifeless> trust is relative
<jfroy> dash: ^^
<jfroy> mmm
<jfroy> I think I do in fact have a GPG key
<jfroy> or used it
<jfroy> *used to
<jfroy> might be expired by now. Let's see, how do I use this gpg thingy
<lifeless> spiv: bug 327558
<ubottu> Launchpad bug 327558 in bzr "windows commands raise an 10054, 'Connection reset by peer' error" [Undecided,Confirmed] https://launchpad.net/bugs/327558
<lifeless> jfroy: don't worry about it now, I did the upload already :)
<spiv> lifeless: thanks
<lifeless> spiv: appears harmless but noisy; I haven't dug deeply, it showed up as an odd tag so I peeked at it
<lifeless> spiv: may be something to toss to vila
<spiv> lifeless: already fixed actually :)
<lifeless> spiv: easythen ;)
<spiv> Very!
 * spiv -> lunch
<jfroy> lifeless: http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg (new package signed with my MobileMe cert) and http://www.devklog.net/bazaar/Bazaar2.0.0-3.pkg.asc signed with 0591FA2D
<jfroy> the key should be on the MIT server.
<jfroy> I think :/
<lifeless> jfroy: gpg: key 0591FA2D: public key "Jean-Francois Roy <bahamut@macstorm.org>" imported
<lifeless> ?
<jfroy> indeed, should have 3 identifies in it
<lifeless> jfroy: I think I touched a couple of your bugs this morning
<jfroy> thought I changed the principal one to jeanfrancois.roy@me.com
<jfroy> Oh well.
<jfroy> *identities
<lifeless> ok, deleting that -3 and reuploading
<jfroy> It's always worth it to do it right :)
<jfroy> And almost never not to.
<lifeless> jfroy: so, dirstate bugs
<lifeless> jfroy: can you reproduce?
<jfroy> huh, remind me the bug #
<lifeless> check your bugmail :)
<lifeless> this laste 4 hours I've been trawling bugs
<jfroy> right, those emails I send to Trash almost in a manic way :p
<jfroy> joking
<jfroy> or not?
<jfroy> doh
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/328674
<ubottu> Launchpad bug 328674 in bzr "TypeError: 'NoneType' object is unsubscriptable error in _dirstate_helpers_c.ProcessEntryC._process_entry when running status" [Undecided,Incomplete]
<jfroy> whoa talk about ancient
<jfroy> haven't seen that backtrace again I think
<jfroy> In any case, I have no idea what I was doing at the time that triggered the problem.
<lifeless> ok
<tolstoy> Oh, dear. The Snow Leopard installer doesn't work. Yikes!
 * igc lunch
<lifeless> tolstoy: which one
<tolstoy> The third one.
<tolstoy> I tried it on two machines.
<lifeless> jfroy: ^
<tolstoy> The first machine already had the first version of the package installed, and the other hard the second.
<tolstoy> Syslog doesn't reveal much.
<tolstoy> I'm not sure how to completely uninstall the whole thing to see if maybe there's an artifact from an earlier install.
<lifeless> tolstoy: could you file a bug?
<tolstoy> Okay. I was just going to reply to the mailing list.
<lifeless> do both :)
<lifeless> bugs are useful though
<tolstoy> Is there a log one can tail to find more detailed output about what an installer is doing?
<tolstoy> Hm. Maybe install.log?
<lifeless> no idea sorry, not a macoser
<tolstoy> Failed install preflight: Error Domain=PKInstallErrorDomain Code=102 UserInfo=0x11a59a5f0 "The package âBazaar2-1.0.0-3.pkgâ is untrusted." Underlying Error=(Error Domain=NSOSStatusErrorDomain Code=-2147409622 UserInfo=0x11a591fd0 "The operation couldnât be completed. CSSMERR_TP_NOT_TRUSTED")
<tolstoy> Glad I found that log. I bet that's pretty clear to jfroy'll know right off the bat what's up with that.
<lifeless> ah thats the signature :)
<lifeless> I guess you have to trust him somewhere
<tolstoy> The other two packages worked. I bet it's just a missed step somewhere.
<tolstoy> lifeless: You think I should still file a bug?
<lifeless> yes
<lifeless> we'll need to document it
<lifeless> tolstoy: -3 is the first one that is signed
<tolstoy> Ah, okay.
<tolstoy> https://bugs.launchpad.net/bzr/+bug/439141
<ubottu> Launchpad bug 439141 in bzr "bzr 2.0 mac osx installer (-3) not trusted" [Undecided,New]
<tolstoy> Ah. Well, there you go. ;)
<lifeless> thanks
<jfroy> tolstoy: ouch, that's bad
<tolstoy> Heh. At least I could find a decent error message! ;)
<jfroy> So apparently what I thought was a trusted system root wasn't
<jfroy> :sigh: this has been a huge FAIL in retrospect
<Peng_> Stupid question: Renaming a directory and renaming the files in it. Does that work?
<tolstoy> Peng_: Works for me, as long as it's "bzr mv".
<lifeless> jfroy: -4, unsigned, gpg sig only ? :)
<Peng_> Ah, I got it! Except the moves are listed in "status" 2-3 times. That can't be good.
<jfroy> lifeless: coming right uo
<jfroy> *up
<Peng_> Committing seems alright, though.
<lifeless> Peng_: each fileid that has its parent or name change will be listed, and only those
<jfroy> lifeless: http://www.devklog.net/bazaar/Bazaar2.0.0-4.pkg, http://www.devklog.net/bazaar/Bazaar2.0.0-4.pkg.asc
<Peng_> Uh-oh. Now "bzr check" fails.
<lifeless> Peng_: ?!
<lifeless> Peng_: bzr version ?
<Peng_> lifeless: bzr.dev, as of yesterday.
<Peng_> The "bzr check" failure doesn't seem to be related. I think it might be...not a problem, anyway. Hold on.
<Peng_> Remember that branch with the screwed-up revision? My current repo doesn't have the revision, but I still have the branch, so I think it failed because the branch points to a revision that does not exist.
<lifeless> ah if its in the reop check will examine it
<lifeless> anyone think the karmic booting screen looks very X-Files?
<Peng_> Yeah, I temporarily moved the branch out of the way, and check passes now. Never mind about the crisis. :P
<Peng_> Sorry if I raised your blood pressure or anything.
<lifeless> no
<lifeless> but thanks :)
<fullermd> lifeless: Bug 403322 the same thing as bug 430672, no?
<ubottu> Launchpad bug 403322 in bzr "IndexError on moving added file" [High,Confirmed] https://launchpad.net/bugs/403322
<lifeless> TolstoyAway: try now
<ubottu> Launchpad bug 430672 in bzr/2.0 "Crash when renaming a directory" [High,Confirmed] https://launchpad.net/bugs/430672
<lifeless> -4 is up
<jfroy> yeah
<jfroy> and the link has been updated on the wiki
<lifeless> fullermd: could be
<fullermd> It looks like the same trigger mechanism (mv'ing to the lexically earlier name), and the error looks the same.
<lifeless> fullermd: see my latest comment
<fullermd> Yeah, that looks like what it should do.  Wanna just dupe it?
<Peng_> beuno: ping
<Peng_> beuno: (Low-priority, though.)
<Peng_> beuno: Never mind.
<lifeless> fullermd: yeah, reduped, moved over, submitted for review
<fullermd> Sweet.
<fullermd> Lesson learned: I don't need to get things marked Critical.  Just leave additional bugs for the same problem lying around, and pounce on people when they start working on them   ;)
<lifeless> fullermd: my lp bug for the afternoon
<lifeless> https://bugs.edge.launchpad.net/launchpad/+bug/439153
<ubottu> Launchpad bug 439153 in launchpad "messy javascript window when marking a dup as a dup" [Undecided,New]
<fullermd> If you find a bug using a bug tracker, does that count as two wrongs making a right?
<lifeless> fullermd: no
<lifeless> fullermd: did you look at the png ?
<fullermd> Oh, yes.  I was being more whimsical.
<wgrant> lifeless: That bug is a dupe. Not sure which of. It's less impressive for those who are not members of ~launchpad.
<lifeless> wgrant: thanks
<lifeless> i was... startled
<fullermd> OK, there's _definitely_ whimsy potential in a dupe bug about a problem with dupeing...
<wgrant> Now, there is already a dupe of the original.
<wgrant> So I might mark lifeless' bug as a dupe of the dupe, take a screenshot of the error and attach it to the original.
<fullermd> Should be safe, as long as the bug tracker supports tail recursion   ;)
<wgrant> There was a bug just after AJAX dupe-marking was introduced where it wouldn't stop you from marking a bug as a dupe of itself.
<wgrant> This caused infinite recursion.
<wgrant> And LP devs got the very, very long traceback in the same popup as lifeless' screenshot shows.
<lifeless> I love to get tracebacks
<lifeless> especially red ones in skinny boxen
<emmajane> igc, ping?
<igc> hi emmajane
<emmajane> igc, hey.
<emmajane> I'm going a bit cross-eyed trying to catch up with the mailing list and get the changes in. Can you take a peek at the latest and let me know what i'm missing?
<igc> emmajane: sure
<emmajane> thanks
<igc> emmajane: I was just pushing an update to the Download text and saw your latest round of changes
<emmajane> igc, I'm not sure how much more I can do tonight. (it's nearly 2am here)
<igc> np
<igc> emmajane: the banner looks a little out of alignment btw
<igc> the "Bazaar" title is lower than the logo
<emmajane> igc, move it up?
<igc> emmajane: I'll try that
<emmajane> igc, I've already got the fix. I just wanted to make sure you meant that. :)
<igc> emmajane: pull my dlwnload fix before committing btw
<emmajane> ok
<igc> emmajane: also Get Help needs to link to BzrSupport, not BzrExtras :-)
 * emmajane sighs. too tired to copy and paste. good catch.
<igc> emmajane: the Home link needs to go to '.', not '/'
<igc> emmajane: otherewise it breaks in it's current location (xxx/static/)
<igc> s/it's/its/
<lifeless> it's important to get that right :)
<fullermd> Yeah, people who get it wrong really put they're credibility on the line.
<lifeless> ouch
<fullermd> Accept when it's intentional, of course   :p
<emmajane> igc, links fixed.
<igc> emmajane: the top line links are really nice now - well done
<emmajane> argh. I think I screwed that up. where did your distro links go? :/
<igc> emmajane: but search is broken?
<emmajane> oh, there they are.
<emmajane> search has never worked. I am still trying to figure out what Dustin sent me.
<emmajane> he's got some extra XML site map and other directories and stuff.
<kirkland> emmajane: ?
<emmajane> it has always loaded inline
<emmajane> kirkland, hey :)
<kirkland> emmajane: hiya
<emmajane> kirkland, your search is way intense.
<emmajane> kirkland, it confuses me.
<kirkland> emmajane: :-)  is it?
<kirkland> emmajane: sorry
<emmajane> kirkland, assok. I just open the files and stare at them and then walk away trying not to cry at how stupidly complicated google makes a SEARCH WIDGET.
<kirkland> emmajane: okay, it's not that bad
<kirkland> emmajane: i've made it complicated to do extra complex things
<lifeless> it's worse?
<emmajane> http://bazaar-vcs.org/static/
<igc> emmajane: one more thing we discussed on the list ...
<emmajane> kirkland, I can't figure out how to make it not load inline.
<igc> emmajane: the subtext for qdiff
<kirkland> emmajane: the results?
<emmajane> kirkland, yeah
<lifeless> fullermd: got any other pet bugs ?
<emmajane> igc, Either I haven't found that yet, or I can't remember finding it.
<igc> should just be "Track changes easily with QBzr."
<emmajane> with a link?
<emmajane> or no link.
<igc> emmajane: they can't dwnload qdiff as such
<emmajane> k
<igc> I don't think it needs a link
<fullermd> lifeless: Not that come to mind.  Lemme see if anything discrete jumps out of what LP thinks I'm related to...
<kirkland> emmajane: http://pastebin.ubuntu.com/281892/
<kirkland> emmajane: you need that snippet wherever you want your results
<emmajane> igc, uploaded
<kirkland> emmajane: changing, of course, the id from mine to yours
 * emmajane nods
<emmajane> kirkland, and if I want it on another page?
<emmajane> like a proper form ought to work? ;)
<emmajane> or rather, is it possible (for now) just to dump it to a google provided page?
<kirkland> emmajane: you just change the action of your form
<emmajane> kirkland, also? why are you still awake answering my questions at 1am? :)
<kirkland> emmajane: why are you still awake?  :-)
<kirkland> emmajane: i'm fighting eucalyptus
<emmajane> kirkland, I asked you first! ;)
<kirkland> :-)
<emmajane> I'm guessing eucalyptus is not what I think it is.
<fullermd> lifeless: Nothing particularly recent anyway.  Plenty of things I'd like to see, but...
<kirkland> emmajane: okay, so whats the location of your results page?
<emmajane> kirkland, I'm inventing one now.
<emmajane> I was thinking it should go to google.
<emmajane> so now I'm making a search results .html file.
 * emmajane tries to remember not to cuss in the commit messages. :)
<jfroy> emmajane: the navigation tabs look wrong on Safari I think
<emmajane> "wrong" doesn't help me much
<jfroy> get the browser and see for yourself :p
<lifeless> fullermd: no worries
<lifeless> I've just been trying to make dirstate really robust
<lifeless> tired of corrupt dirstate files
<jfroy> http://home.devklog.net/~bahamut/tabs.png
<jfroy> or not
<jfroy> ok go now
<jfroy> mv-ed the file in the wrong directory :|
<emmajane> hm. I already solved that problem.
<igc> poolie: how often does /static/ auto-refresh from the branch
<fullermd> Yeah.  I remember the first few versions after 0.15, when I kept finding new ways to trip it up every few weeks.  It really had it in for me for a while there   :|
<fullermd> (and not just for my inspired proliferation of pronouns)
<emmajane> kirkland, ok, that's what had me. I don't have a <form> according to what Google told me to insert into my page template. Which means there's no where to tell it to go to a secon dpage.
<kirkland> emmajane: what's your results page?
<kirkland> emmajane: i'll give you the two snippets
<emmajane> the file name?
<kirkland> emmajane: http://pastebin.ubuntu.com/281902/
<kirkland> emmajane: replace http://foo with your results page
<kirkland> emmajane: and replace the cx with your cx
<emmajane> OH!
<igc> emmajane: more feedback from the list discussions ... (nothing important at this time of night)
<emmajane> kirkland, you just ignore their javascripty thing.
<igc> emmajane (1) text size is apparently too small
<emmajane> igc, it's using ems now.
<kirkland> emmajane: and this goes on the results page: http://pastebin.ubuntu.com/281904/
<igc> (2) abentley mentioned extra whitespace after the footer - seems ok to me
<kirkland> emmajane: i gotta call it a night
<kirkland> emmajane: messages logged; ping me tomorrow if you're still having issues
<kirkland> g'night
<emmajane> igc, I'm ignoring the whitespace. it's because of the extra clears used to make sure the background extends properly.
<emmajane> igc, messing with it could wreck it. ;)
<emmajane> kirkland, thank you :)
<emmajane> kirkland, I owe you loads of $drink
<igc> (3) that's all I can recall right now (except more carousel images)
<kirkland> emmajane: heh ;-)  thx
<emmajane> igc, ok. let me just figure out the search and then I'll ping you.
<vila> hi all
<igc> emmajane: that cascading header link problem occurs on IE8 as well as Safari
<igc> emmajane: ok on FF on Vista and Ubuntu though
<emmajane> igc, I'm probably just going to switch it back to what I had that worked instead of inserting random CSS from someone on the list.
<emmajane> seeing as what I had was browser tested. :)
<igc> emmajane: yep
<igc> emmajane: I'm heading off early today - family stuff to do
<igc> emmajane: poolie might be around later if you have questions
<emmajane> igc, I'll hopefully be asleep shortly. it's nearly 3am here.
<igc> night all
<igc> emmajane: sounds a good idea :-)
<emmajane> igc, have a good afternoon
<emmajane> igc, ok. I've pushed the latest that includes the template for search results. It's not working locally, but I'm sure that isn't a surprise. sleep is next on the agenda for me.
<tolstoy> jfroy: The Mac OSX installer (snow leopard) #4 works! Even for me! Thanks for all the effort.
<jfroy> tolstoy: good to know
<jfroy> The PyCrypto warnings are gone?
<tolstoy> Yep.
<lifeless> spiv: if you have time in your day, I have two 2.0.x patches I'd love reviews on :)
<spiv> lifeless: I'll take a look and see if I can manage something before heading to yoga...
<lifeless> spiv: thanks
<poolie> hi igc, lifeless, spiv (where applicable)
<vila> hello poolie :-P
<poolie> hey there
 * poolie is swallowed by a meeting
<vila> hehe
<davidstrauss> lifeless: Re: the issue on the corrupted dirstate, I have the shared branch storage .bzr/, but I've converted all branches to be standalone.
<lifeless> kk; it'll be only in the wt so we can't really progress it
<vila> lifeless: related to dirstate, a way to force dirstate re-build from scratch could help in many circumstances, is that something that you can easily add in dirstate2 (or even dirstate) ?
<lifeless> vila: just an automated 'remove-tree; checkout .' ?
<vila> kind of, don't touch my tree :D
<vila> the idea is that it's needed in contexts where you need the dirstate even in somewhat buggy contexts so the less commands are used the better
<jtv> lifeless: we're suddenly hitting bug 375013 on lp branches.  Any idea what changed & what we can do about it?
<ubottu> Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged] https://launchpad.net/bugs/375013
<lifeless> what do you mean 'on lp branches'
<jtv> lifeless: on lp-hosted branches.
<lifeless> details man!
<jtv> We're committing translations to them using the commit-preview-tree trick.  This started giving errors for some branches.
<lifeless> those branches are stacked; you can't commit directly to them
<jtv> so have to branch-commit-push like regular people?
<lifeless> yes
<lifeless> its a limitation/bug
<lifeless> can be fixed but not trivially
<lifeless> we have certain invariants we require repositories (which every branch has one) to maintain
<jtv> there's a workaround in the bug description...  does it "fix up" the branch for thus usage permanently?
<lifeless> and commit wasn't maintaining them, this was causing corrupt branch errors
<lifeless> jtv: no, it makes a local branch
<lifeless> 'checkout' does a full clone
<jtv> similar to 'branch'?  Or is it lightweight?
<lifeless> ==branch
<lifeless> if this is for translation
<lifeless> I suggest saying 'can only be done to series'
<lifeless> and having some glue in lp that makes sure series branches are not stacked.
<lifeless> or something like that
<lifeless> hmm, not well thought out.
<lifeless> anyhow, your users need to do 'bzr reconfigure --branch URL' where URL is the lp url to the branch they want translations to go into
<lifeless> jtv: sorry, --unstacked
<jtv> lifeless: yes, this is for translations... I wouldn't want to add a restriction like that; I have heard rumblings about branches becoming stacked by default.
<lifeless> branches are stacked by default
<jtv> then what are they stacked on if no parent is given?
<lifeless> as long as their is somewhere to stack them and the palce to stack them is itself stackable (so we don't de facto require a minimum bzr that group don't require
<jtv> ah
<lifeless> the trunk series
<jtv> so about bzr reconfigure...  what's that do?
<jtv> I'm assuming it'd upset people if we did it for them...
<jtv> ...at least if we did it quietly.
<lifeless> I don't think it would upset them
<lifeless> it may disrupt access while its done though [I haven't checked]
<jtv> hah... we lock the branch anyway
<jtv> so what does it do?  If it were completely harmless, it'd be automatic.
<lifeless> it does a big fetch
<lifeless> pulls in all the unfetched data
<lifeless> then toggles the bit that says 'stacked' to say 'not stacked'
<jtv> So at that point it draws a static copy from the branch it was stacked on, and replaces its stacking with that copy?
<bialix> hello igc
<bialix> igc: why not show bzr-explorer screenshot on new bzr site instead of qdiff? why???
<lifeless> jtv: uhm, something like that ;P
<jtv> which sounds like it might very well upset some users...
<lifeless> jtv: huh? why
<jtv> Because updates from the stacked-on branch would stop showing up in the stacked branch, wouldn't they?
<lifeless> no, updates don't show up in other branches anyway
<lifeless> this is a sharding layer change
<lifeless> to put it in db terms
<lifeless> semantically transparent
<jtv> oic
<jtv> so merely less efficient in storage, that sort of thing?
<jtv> which in this case is our problem anyway, not the users'
<lifeless> right
<lifeless> thus, 18:44 < lifeless> I don't think it would upset them
 * jtv comprehends
<jtv> lifeless: so just bzr reconfigure --unstacked lp:~my/project/branch would do it?  Then we can recommend that as a workaround, and figure out a good way to automate it.
<lifeless> yes
<jtv> any easy way to do it straight from bzrlib?  or better to go with the command-line client?
<lifeless> branch.set_stacked_on_url(None)
<jtv> that's actually easier
<jtv> lifeless: I suppose I can just do that before exporting, without checking if it's actually needed first?
<lifeless> jtv: uhm, I'm not sure I'd do that ;)
<lifeless> have a poke at the code first...
<jtv> ok, I'm sure there's a matching getter that I can check first
<jtv> if branch.get_stacked_on_url(): branch.set_stacked_on_url(None)
<lifeless> yes, thats safe
<lifeless> I'm not sure that setting it unconditionally is /unsafe/ mind you, just ECautious
<jtv> Right
<jtv> and if lifeless is not sure, I'm not touching anything at all  :)
<jtv> lifeless: thanks manily!
<lifeless> de nada
<nedosa> lifeless: quick question, so bzr rebase doesn't support re-arranging commits, is that right ?
<Lo-lan-do> nedosa: I believe it doesn't
<nedosa> Lo-lan-do: cheers, is there any way around it  ?
<Lo-lan-do> No easy way that I know of. You can use bzr replay by hand, but it's not going to be as slick.
<nedosa> Lo-lan-do: is bzr replay a plugin ?
<luks> it's a command from the bzr-rewrite plugin
<Lo-lan-do> It's in rebase
<luks> wasn't that renamed to bzr-rewrtie?
<Lo-lan-do> Was it? I don't know.  Feel free to ignore me :-)
<lifeless> yes, it was renamed
<lifeless> nedosa: replay is in the bzr-rewrite plugin
<lifeless> nedosa: and you could use that to reorder, approximately.
<lifeless> it will be a bit clunky, we don't have a good answer to history editing yet.
<Lo-lan-do> Is there something for squashing yet?
<nedosa> lifeless: cheers, will give that a try
<lifeless> Lo-lan-do: merge
<Lo-lan-do> lifeless: It still keeps the intermediate revisions, or did I miss something else?
<luks> bzr revert --forget-merges
<Lo-lan-do> Nice.
<nedosa> lifeless: do you think your dev branch of the bzr-rewrite plugin is fairly reliable ? having a hard time locating the bzr rewrite plugin :)
<lifeless> jelmer: ^
<lifeless> nedosa: no comment :O
<lifeless> nedosa: but have you tried lp:bzr-rewrite ?
<nedosa> lifeless: ah sorry, my siliness
<nedosa> so seems like bzr-rebase is being renamed to bzr-rewrite
<SamB_XP> hmm, there should be a "motd" on lp:bzr-rebase to announce this ...
<mereandor> hi! I have a problem with "bzr export" when LC_ALL=C - it works just fine with the normal locale - is there a way to work around this?
<lifeless> mereandor: details please :P
<mereandor> http://nopaste.info/b495a6edc9.html
<mereandor> when I use LC_ALL=C bzr export I get this error
<mereandor> without the LC_ALL it works just fine
<lifeless> ok, you have a path that is not ascii
<mereandor> in the repository or in my filesystem?
<lifeless> not sure from the traceback, but I'd suspect repository
<mereandor> ok
<mereandor> is there a way to make bzr accept unicode filenames?
<lifeless> anyhow, to handle non-ASCII we need a non-ASCII locale; such as UTF8 or whatever
<mereandor> ok
<lifeless> mereandor: we handle unicode filenames, thats what LC_ALL=OTHER_THAN_C lets us do
<lifeless> LC_ALL=C -> ASCII only
<mereandor> ok so I have to change the locale to something sensible
<mereandor> thanks a lot for your help
<johnf> so if a bzr check gives bzr: ERROR: parent_id {53@91d23e16-c8f7-0310-bc44-da976c688e4e:customer_care%2Ftrunk:lib%2FBulletproof%2FPlan} not in inventory
<johnf> what would my next step be?
<lifeless> install bzr 2.0.0 and call me in the morning
<johnf> yeah just realised this server is running 1.13
 * Lo-lan-do wants 2.0 in bpo
<johnf> Lo-lan-do: let me see what I can do
<Lo-lan-do> johnf: Actually, I can wait for a few weeks.  Give it time to propagate to testing first :-)
<Lo-lan-do> (I can do a local backport myself if needed, I'm just going to need an "official" one for a client in a few weeks)
<phinze> oh boy, now i've gone and done oit
<phinze> it started by getting "Tree transform is malformed" on a bzr shelve operation
<phinze> but now i get a StopIteration on all bzr shelve commands
<phinze> but i needed shelf #1 :(
<phinze> time to root around in .bzr i suppose ... if anybody has any tips i'd much appreciate it
<vila> phinze: what did you do ?
<phinze> vila: i believe it may have had to do with shelving additions of several binary (swf) files
<phinze> all's well now, i reached into .bzr/checkout/shelf/ and (after backing it up) removed 5 1.5MB shelf-N files and renamed shelf-4 (at 85K) to shelf-1
<vila> phinze: have a look in .bzr/checkout/shelf, you'll find several files there, moving them around should allow you to identify the culprit
<phinze> one step ahead of you :)
<vila> phinze: :D
<vila> the renaming was optional and dangerous (who told you that number wasn't used somewhere else ? )
<vila> ;-)
<phinze> always nice when the internals of my tools are relatively sane
<phinze> heh, well... ls told me! :)
<johnf> lifeless: similar error now
<johnf> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', '53@91d23e16-c8f7-0310-bc44-da976c688e4e:customer_care%2Ftrunk:lib%2FBulletproof%2FPlan'
<johnf> reason: Parent not in inventory.
<johnf> that's on 2.0
<jelmer> johnf: is this an import from svn made using an older bzr-svn version?
<johnf> jelmer: yes
<johnf> well a branch of an olf svn tree anyway
<johnf> old even
<jam> morning all
<jam> barry: ping
<barry> jam: pong
<barry> hiya!
<jam> hey
<jam> Thought it might work better to do a bit more live support
<jam> rather than via email
<barry> jam: just read your message, yes, thanks!
<jam> barry: so lets start with
<jam> sftp ...
<jam> cd ...
<barry> jam: aside: i really think we need that big launchpad button to upgrade a branch.  i suspect my network is not stable enough to complete such a long running task
<jam> ls .bzr/
<barry> sftp> cd ~mailman-coders/mailman/3.0
<barry> sftp> ls .bzr
<barry> .bzr/README               .bzr/branch               .bzr/branch-format
<barry> .bzr/branch-lock          .bzr/repository           .bzr/repository.backup
<jam> barry: you could add my ssh public key to let me connect as you and have me do it :)
<jam> (you can always remove it after)
<jam> ls .bzr/repository
<jam> ls .bzr/repository.backup
<barry> jam: i wouldn't mind doing that, but i kind of want to feel the pain so i have a better idea of what's happening ;)
<jam> (btw, I agree that we should be creating the new repo somewhere *else* and then move it into place... not sure why that design wasn't chosen.)
<jam> barry: ssh devpad; screen; bzr upgrade ...
<jam> ?
<jam> of course ,the best way to do it is:
<jam> bzr branch lp:mailman
<jam> cd mailman
<jam> bzr upgrade
<jam> bzr push lp:~mailman/mailman/trunk-2a
<barry> jam: +1 on screen
<barry> jam: i've done that (called it mm3-2a)
<barry> jam: but i really want my 3.0 trunk branch to be called "3.0" :)
<barry> sftp> ls .bzr/repository
<barry> .bzr/repository/format                  .bzr/repository/indices
<barry> .bzr/repository/lock                    .bzr/repository/obsolete_packs
<barry> .bzr/repository/pack-names              .bzr/repository/packs
<barry> .bzr/repository/shared-storage          .bzr/repository/upload
<barry> sftp> ls .bzr/repository.backup
<barry> .bzr/repository.backup/format           .bzr/repository.backup/indices
<barry> .bzr/repository.backup/lock             .bzr/repository.backup/obsolete_packs
<barry> .bzr/repository.backup/pack-names       .bzr/repository.backup/packs
<barry> .bzr/repository.backup/shared-storage   .bzr/repository.backup/upload
<barry>  
<jam> ls -l .bzr/repository/pack-names .bzr/repository.backup/pack-names
<barry> sftp> ls -l .bzr/repository/pack-names .bzr/repository.backup/pack-names
<barry> -rw-r--r--    0 1001     1001           72 Sep 29 21:57 .bzr/repository/pack-names
<barry>  
<jam> ls -l .bzr/repository.backup/pack-names
<jam> (check if there is a typo there)
<barry> ah, right, i thought that looked weird.  sec...
<barry> ls -l .bzr/repository.backup/pack-names
<barry> -rw-r--r--    0 1001     1001          966 Sep 29 21:57 .bzr/repository.backup/pack-names
<barry>  
<jam> so if it was up to me, I would do
<jam> rmtree backup.bzr
<jam> rm tree .bzr/repository
<jam> mv .bzr/repository.backup .bzr/repository
<jam> though you probably need something like a gui client or hitchhiker to get 'rmtree'
<barry> i've never used hitchhiker.  maybe time to start.  but... are you sure that's safe?
<jam> barry: you just said you have another copy of it locally, right?
<jam> but yeah
<jam> it should be ok in this situatio
<jam> of course, if you really want to do it
<jam> rmtree .bzr
<jam> bzr push lp:mailman --use-existing-dir
<jam> since you already have a local conversion
<barry> jam: probably: cd mm3-2a; bzr push lp:~mailman-coders/mailman/3.0 --use-existing-dir (since i de-linked the dev focus when i started)
<barry> jam: i'm willing to try that
<jam> barry: You also can just go onto launchpad and rename the mm3-2a
<jam> or use the launchpad gui to delete a branch, etc
<barry> jam: hmm, yeah, you're right!
<barry> jam: delete the 3.0 branch, rename mm3-2a to 3.0
<jam> right
<barry> jam: re-link the dev focus to 3.0
<jam> the only issue is if people are currently stacked on your 3.0 branch
<jam> it won't let you delete it
<jam> but I think it will let you rename it
<barry> jam: thanks.  sometimes the obvious is staring you right in the face :)
<jam> If it doesn't let you, we can work around using --use-existing-dir
<barry> right.  i think we have no stacked branches on 3.0, but i'll find out
<barry> jam: +1.  give me a sec to try it...
<jam> if you do have stacked branches, they'll have to then be upgraded before they work again, but yeah, let me know
<jam> vila: morning, can I ask a question
<vila> morning jam ! Sure ask :)
<jam> vila: I'm trying to do some memory profiling (as I think you know) but I don't have a 64-bit python version anywhere
<jam> do you have one I could have access to ?
<vila> hmm, as on babune ?
<jam> vila: something like that
<barry> jam: there were merge proposals hanging off the old branch.  even though they were merged, lp would make me delete them, so instead, i renamed it and moved mm3-2a to 3.0
<jam> I'd need a shell account, etc
<jam> barry: sounds reasonable
<vila> jam: yeah, sure, appetizers are included
<barry> jam: thanks!  i will write up my experiences and post them to the bazaar mailing list.  hopefully it will help make life easier for the next person.  i really appreciate the help
<jam> barry: yeah, I'm sorry it was a pita for you
<jam> it certainly is something we should do better
<vila> jam: what's your preferred ssh key on lp ?
<vila> jameinel@samus  ?
<barry> jam: yep, though i don't mind slogging through it to identify the pain points
<jam> vila: yeah, I think that is good
<vila> shudder, reboot after panic, writing crash summary, /: write failed, file system is full :-(
<jam> vila: ouchie!!!
<vila> jam: well, only there are 2 with that comment, I pick the first
<Zelut> I just did a pull, it suggested I run 'bzr upgrade' which i did, and now it wont let me push my changes back.
<Zelut> [cedwards@daphne origami]$ bzr push lp:origami
<Zelut> Format <RepositoryFormatKnit1> for lp-46123344:///~christer.edwards/origami/trunk/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<Zelut> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~christer.edwards/origami/trunk/.bzr/)
<Zelut> is not compatible with
<Zelut> any suggestions?
<Zelut> CHKInventoryRepository('file:///home/cedwards/origami/.bzr/repository/')
<Zelut> different rich-root support
<Tak> does launchpad support that format yet?
<Tak> also, is there any reason that "Pull New Revisions" in BazaarExplorer doesn't behave the same as `bzr pull`?
<asabil> Zelut: you need to upgrade your repository a well in launchpad
<Zelut> asabil: can you tell me how to do that?
<jelmer> Zelut: update your local repository to 2a
<jelmer> Zelut: bzr upgrade --2a <url>
<Zelut> thanks. that seems to have fixed it.
<tsmith> is this the help chanel or the dev channel or both?
<tsmith> So, there are times when I just cna't seem to get a fix to work; and I end up w/ lots of commits like "Fixes issue #1" "Fixes issue #1 try 2" so on and so on...sometimes up to 10 tries.  Is there a way to distribute changes to an external server, and revert them all as a group?
<Keybuk> bzr: ERROR: 77afdcdf611d88cf3e8b0806fd04c56c.tix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
<Keybuk> help!
<lifeless> Keybuk: head the file
<Keybuk> lifeless: the file?
<Keybuk> debian/changelog?
<Keybuk> oh, you mean find the .tix file under .bzr ?
<Keybuk> it's a file of 316 zeros
<lifeless> Keybuk: you had a system crash, didn't you
<Keybuk> nope
<Keybuk> ah, no, I did copy this branch off the system that crashed
<Keybuk> yes
 * lifeless suspects it was running ext4
<Keybuk> indeed
 * lifeless wants fbarrier very badly indeed
<Keybuk> fpony ()
<lifeless> at 316 bytes it was probably a new commit not a repack, so we don't have the data at all
<lifeless> are the other files with the same prefix also zeroed?
<lifeless> and how old a ext4 version was it running when the crash happened?
<Keybuk> so I tried to branch it again
<Keybuk> then I got
<lifeless> the first question is to see if we have any hope of recovery; the latter is for input to whether bzr should start fsyncing/add an option
<Keybuk> bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66', 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh')]).
<lifeless> branch from.. the old machine?
<Keybuk> no, LP
<Keybuk> bzr branch lp:~ubuntu-core-dev/upstart/ubuntu
<Keybuk> crashed with that
<lifeless> una momento
<lifeless> works for me
<lifeless> cd /tmp/
<lifeless> robertc@lifeless-64:/tmp$ bzr branch lp:~ubuntu-core-dev/upstart/ubuntu
<lifeless> Branched 1223 revision(s).
<lifeless> robertc@lifeless-64:/tmp$
<lifeless> now, I'm not in core dev
<Keybuk> hasn't for me twice in a row
<Keybuk> same failure both times
<lifeless> so lets look at what lp thinks
<lifeless> what does 'bzr revno lp:~ubuntu-core-dev/upstart/ubuntu' report for you?
<Keybuk> 1223
<lifeless> ok
<lifeless> try this
<lifeless> bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu
<lifeless> if that works for you, the writable copy on lp is missing those texts
<lifeless> probably from a bug we closed early this year
<lifeless> I'll find you the fix script in a minute, and you should run that
<Keybuk> that did, indeed, work
<lifeless> ok
<lifeless> cd to that branch
<Keybuk> yup
<StyXman> does anyone know any other free project hosting wich supports bazaar besides launchpad? I'm just looking for options...
<lifeless> grab this file
<lifeless> http://launchpadlibrarian.net/26166834/fix-branch.py
<lifeless> (linked from https://bugs.edge.launchpad.net/launchpad-code/+bug/354036)
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory (unfixable by users) error when pulling a branch from the mirrored area" [Undecided,Confirmed]
<Keybuk> lifeless: IndexError: list index out of range
<Keybuk> oh, I see, I need to give it "."
<Keybuk> ok
<Keybuk> but now what?
<Keybuk> warcraft upstart% bzr push --remember lp:~ubuntu-core-dev/upstart/ubuntu
<Keybuk> No new revisions to push.
<lifeless> actually, as I look deeper you have a unique issue
<lifeless> You're using 2.0.0 ?
<Keybuk> yes
<Keybuk> though I suspect for the first time
<lifeless> ok, I'm going to file a bug and get back to you about how to correct this
<lifeless> actually, lets fix it
<lifeless> and I'll file a bug separately
<lifeless> python
<lifeless> >>> import bzrlib.repository
<lifeless> source = bzrlib.repository.Repository.open('.')
<lifeless> target = bzrlib.repository.open('bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu/')
<lifeless> source.lock_read()
<lifeless> target.lock_write()
<Keybuk> AttributeError: 'module' object has no attribute 'open'
<lifeless> stream = source.texts.get_record_stream([('texts', 'process.c-20060804042848-002ec799c7183356',
<Keybuk> ok
<lifeless>                 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356',
<lifeless>                 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66',
<lifeless>                 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh')], 'unordered', True)
<Keybuk> ok
<lifeless> (the attribute error - missing 'Repository' as per the line before)
<lifeless> target.texts.insert_record_stream(stream)
<Keybuk> right
<Keybuk> bzrlib.errors.RevisionNotPresent: Revision {[('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c')]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex(<bzrlib.btree_index.BTreeGraphIndex object at 0x32d8090>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5e10>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5bd0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5990>, <b
<Keybuk> zrlib.btree_index.BTreeGraphIndex object at 0x32ce510>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d55d0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5390>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d5150>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2ed0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2c90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2a50>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2810>
<Keybuk> , <bzrlib.btree_index.BTreeGraphIndex object at 0x32d25d0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2390>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32d2150>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32ceed0>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32cec90>, <bzrlib.btree_index.BTreeGraphIndex object at 0x32cea50>)), <bzrlib.knit._DirectPackAccess object at 0x32cc850>)".
<lifeless> \o/
<lifeless> ok, I'm filing a bug
<lifeless> this needs deeper checking
<lifeless> are you 'keybuk' on launchpad ?
<Keybuk> no, 'scott'
<lifeless> does 'bzr check' pass for you?
<Keybuk> in the checkout-from-http?
<Keybuk> yes, ish
<Keybuk>   2259 revisions
<Keybuk>    626 file-ids
<Keybuk>      2 inconsistent parents
<lifeless> ok, just realised I didn't transform the error keys
<lifeless> this will work:
<lifeless> http://pastebin.com/fdb29168
<Keybuk> ok
<Keybuk> that did not error
<Keybuk> now what do I do?
<lifeless> cool
<lifeless> try branching again
<lifeless> from the normal url
<Keybuk> ok...
<Keybuk> is branching
<lifeless> success?
<Keybuk> bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set([('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090714141825-3zd92vjv9b5gia2c'), ('texts', 'process.c-20060804042848-002ec799c7183356', 'scott@netsplit.com-20090803220543-yqjmdr9pbuj4yqpn'), ('texts', 'main.c-20060516195723-2691e3b471617c66', 'scott@netsplit.com-20090922161534-0p9jjuv3y885t6yh'), ('texts', 'main.c-20060516195723-2691e3b471617c66'
<Keybuk> , 'scott@netsplit.com-20090922205552-q4izjm87q1pxjlp6')]).
<Keybuk> ;)
<lifeless> though art kidding me
<lifeless> ok
<lifeless> try
<lifeless> nosmart+lp:~....
<lifeless> [I can't test this, not in the right group]
<igc> morning
<Keybuk> lifeless: thatest worketh
<lifeless> Keybuk: ok, smart server bug, or something approximately like that.
<lifeless> Keybuk: filing, high.
<lifeless> Keybuk: nothing is wrong with your repo AFAICT.
<lifeless> bzr is being bitchy
<tsmith> man i tried ext4 and jfs
<tsmith> i constantly had to run fsck ;O they jus twouldn't mount!!! corrupted block or something
<tsmith> i went back to xfs
<lifeless> hi igc
<igc> hi lifeless
<Keybuk> tsmith: of course, the difference there is that ext4 is *telling* you that your filesystem is corrupted
<Keybuk> whereas xfs does it itself quietly ;)
<mzz> I haven't had an ext4 fs eat itself yet (but for that matter I haven't had a reiserfs do it yet either, so perhaps I'm just not abusing them enough or something)
<lifeless> Keybuk: so how recent was the ext4 kernel that ate that file?
<lifeless> [broadly speaking]
<mzz> I have had some hardware-level hd trouble though, so I'm more likely to worry about that currently.
<Keybuk> lifeless: given that the disk died on the laptop I rescued it from, I'm not entirely blaming ext4
<mzz> err, yeah.
<lifeless> Keybuk: ah, fair'nuff
<lifeless> clickodeath
<lifeless> ?
<Keybuk> yup
<lifeless> whats our hardware support on eeepc's like?
<Keybuk> good
<lifeless> cool
<Keybuk> all diamondville stuff is fully supported
<lifeless> Lynne is in love:)
<awilkins> I find the most common cause of filesystem corruption I have these days is bad RAM
<mzz> I guess that makes sense, since a lot of the important bits should end up cached
<awilkins> I had some bad blocks in the first 20MB or so and it made things unstable... you could see it when you booted windows 7 because it was RIGHT in the middle of where the splash movie loaded
<tsmith> mzz: you arent' abusing it correclty
<tsmith> i can get ext4 to fail in a matter of days
<mzz> weird.
<tsmith> but i dont know if ext4 was made for my particular needs
<tsmith> redditmirror.cc
<mzz> I don't shutdown uncleanly *that* often, but I do feel like I actually use the fs.
<tsmith> hundreds of millions of small files (jpg, css, html) in tends of thousands of directories, accessed randommly by hundreds of thousands of visitors
<tsmith> pushing 100 m hits a week ;/
<lifeless> tsmith: it was made to be fast there... no wonder it gets speed wobbles
<tsmith> when i was the #1 link on stumbleupon for 3 days, my server was pushing 80% CPU just on IO waits
<tsmith> it was crazy
<igc> emmajane: did you see the email re the top navigation links still not quite right? The last two are lower than the others
<beuno> james_w, hey. bzr is complaining that it doesn't have it's extensions built, after installing from nightlies. Any ideas?
<james_w> hmm, maybe pyrex got dropped again
<james_w> beuno: please file a bug
<lifeless> james_w: last time this happened I suggested you put a check in the nightlies to _require_ the .so's
<lifeless> james_w: this time, unless you have a really good reason, I'm going to be much more persistent about this
<james_w> I know
<james_w> well
<james_w> the nightlies use the same packaging as the PPAs
<james_w> why not have the check there as well?
<lifeless> even more important
<lifeless> I'm totally up with that
<lifeless> we don't want any deb to ship without the full range of so's
<james_w> lp:~bzr/bzr/packaging-{dapper,hardy,intrepid,jaunty,karmic}
<lifeless> I'm not blaming you :) I just want to make sure that when the nightlies are fixed, that the problem will stay fixed
<lifeless> s/blaming/blaming or accusing/
<lifeless> so, there is a bug barry opened
<lifeless> I'll add to that that the PPA packaging is used (I didn't know that)
 * barry wakes up
<lifeless> and if you have time to look at this, you could add the check, otherwise I'll pester johnf to look at it
<lifeless> james_w: sound good?
<james_w> sure
<lifeless> barry: do you have that bug # handy?
<lifeless> barry: about the missing .so's
<barry> lifeless: let me look
<lifeless> [back shortly, foodingk]
<barry> lifeless: bug 439100
<ubottu> Launchpad bug 439100 in bzr "bzr: warning: some compiled extensions could not be loaded;" [Undecided,New] https://launchpad.net/bugs/439100
<lifeless> barry: and you're using nightlies?
<barry> lifeless: yes, i believe i am (somewhat unintentionally)
<lifeless> james_w: are you intending to poke at this?
#bzr 2009-10-01
<james_w> yeah
<james_w> not tonight though
<james_w> ah, I think it's just karmic that is affected
<james_w> I missed that branch when fixing last time
<james_w> so even if I had added the check it still wouldn't have caught this problem
<johnf> jelmer: ping
<SamB_XP_> barry: why did you decide to use the nightlies by accident ?
<lifeless> james_w: it wouldn't have caught it? [oh because you wouldn't have added the check there :P]
<lifeless> james_w: I'll see if johnf can fix it, its his daytime now.
<lifeless> johnf: https://bugs.edge.launchpad.net/bzr/+bug/439100
<ubottu> Launchpad bug 439100 in bzr "bzr: warning: some compiled extensions could not be loaded;" [Critical,Confirmed]
<james_w> yeah
<james_w> just add python-pyrex to build-depends
<james_w> and then glob the .so files in the .install file I say
<lifeless> so that dh_install errors if missing?
<lifeless> uhm, I suspect the python stuff will interact badly
<james_w> yeah
<james_w> or just an "ls" glob in the rules file or something
<lifeless> in particular if things change we'll break, so we shhouldn't alter the install mechanism
<lifeless> james_w: yeah, I was thinking
<lifeless> [ 7 -e `ls debian/pkg/.../*.so | wc -l` ]
<lifeless> erm, not -e. equal.
<johnf> so my question is what are the nightlies being built from because the other PPA packages are fine
<johnf> Although I'm using a new method now which I need to document soon
<lifeless> \o/
<lifeless> you've probably discarded the karmic packaging
<lifeless> the nightlies build using the packaging branches AIUI
<lifeless> james_w: are the nightlies conceptually compatible with autoppa
<james_w> not sure
<james_w> the normal builds don't have a problem as they are built from the release tarballs
<johnf> ahh the packaging branches don't have pyrex
<james_w> with you don't need pyrex for
<james_w> as the release manager does that step
<james_w> so it's an uneeded dependency there
<james_w> but just installing it everywhere makes it easier to manage
<johnf> ok Let me document my new process using debian as a base and autoppa on top of that over the weekend and then let's switch the nightlies over to that process
<lifeless> johnf: so I have two goals: a) fix it. b) put a rule in to catch regressions (e.g. if we change to cython)
<johnf> lifeless: I think preference would be to catch it in the Makefile so that we solve this problem for all distributions. ie a make install should fail
<johnf> in fact why don't we just make the make fail if pyrex is missing?
<lifeless> different users
<lifeless> we were going to start versioning the .c files
<idnar> what exactly is the format of a bzr+ssh:// URL?
<lifeless> std66
<lifeless> which is to say, what you'd expect
<lifeless> idnar: is there a particular thing that is troubling you?
<idnar> I just don't know how to construct one, I've only ever worked with scp/rsync-style paths
<lifeless> oh
<lifeless> so the same as http:// urls
<idnar> and I seem to be doing it wrong, because bzr tells me "Parent directory of [...] does not exist"
<lifeless> rooted at /
<idnar> I guess I need the absolute path to the home directory
<lifeless>  bzr+ssh://[user[:password]@host/paths/home/here
<lifeless> yes
<lifeless> because we start the server when we connect, it doesn't have a build in chroot like http servers do
<spiv> (If you have bzr.dev on the server, you can use a path starting with ~/ to be relative to the home directory on the server, e.g. bzr+ssh://myhost/~/myproj)
<idnar> ah, I tried that, but this is with 1.16 or something
<mzz> I keep forgetting where /~/ works. Is that only with bzr.dev with bzr+ssh currently?
<spiv> mzz: yes
<lifeless> idnar: we had a choice between // meaning root and / meaning homedir, or /~/ meaning homedir and / meaning root
<mzz> ok
<lifeless> we took the latter choice
<lifeless> mzz: and sftp
<lifeless> mzz: sftp has always worked
<mzz> ahh, sftp is probably what I was confused with then.
<mzz> oh well, no big deal either way, my name's not that long compared to the hostname and branch name usually
<lifeless> idnar: 2.0. Its good. Get it.
<mzz> yay, progress (although I really don't use bzr with any trees of sufficient size for it to matter all that much to me)
<idnar> lifeless: we probably will once it's in lenny-backports
<lifeless> idnar: I suspect that requires a request
<lifeless> its in debian so should be trivial for the backport team to do
<idnar> anyhow, it's pretty far down my list of priorities right now
<lifeless> sure
<lifeless> I'd drop them a mail though :)
<idnar> 2a format seems like it'll be nice when we switch, though
<lifeless> its rocking
<idnar> we're currently using 1.6 format, I think
<jelmer> /clear
<idnar> whatever the minimum that supports stacking is
<lifeless> 1.6
<lifeless> 1.9 has faster indices
<lifeless> 2a has faster everything
<idnar> I think we could upgrade to 1.14, but I'll just wait until we can do 2a
<lifeless> you can now
<lifeless> but it is fragile < 2.0.0
<mwhudson> Peng: can you explain in words of one syllable what the problems with loggerhead and yui3 final are?
<mzz> that is not a lot of speech sound things. To say a thing with that rule in place is hard, but at the same time a bit fun
<lifeless> mwhudson: does not work ? ;)
<mwhudson> lifeless: ta
<mwhudson> seems to be accurate in fact, surprisingly enough
<mwhudson> it just doesn't work at all, for no very obvious reason
<lifeless> if I can suggest unbundling yui - debian unbundle it anyway; make it a dependency
<mwhudson> possibly a good idea
<mwhudson> orthogonal though
<lifeless> yes
<Peng_> mwhudson: There's a new feature in YUI 3.0.0, where you basically do YUI.use('whatever', function() { my_code(); }). It's possible that the old style that Loggerhead uses doesn't work anymore. I didn't check, though.
<Peng_> mwhudson: http://www.yuiblog.com/blog/2009/09/29/yui-3-0-0/
 * Peng_ goes AFK again
<mwhudson> Peng_: yes, that's right it seems
<mwhudson> Peng_: it's not a new feature in yui 3 vs 3pr2, it's new compared to yui2
<mwhudson> Peng_: thanks for the prod
<emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
<emmajane> kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
<emmajane> kirkland, http://bazaar-vcs.org/static/
<emmajane> (just in case you still happen to be around :) )
<emmajane> hrm
<emmajane> let's try that again...
<emmajane> igc, I did see the email about the nav problem. I can replicate using browsershots.
<emmajane>  kirkland, I tried the snippets you gave me yesterday, but I'm getting an error on the results page.
<emmajane> kirkland, http://bazaar-vcs.org/static/
<emmajane> (just in case you still happen to be around :) )
<kirkland> emmajane: these are wrong:
<kirkland>   var googleSearchIframeName = "cse-search-results";
<kirkland>   var googleSearchFormName = "cse-search-box";
<kirkland> emmajane: mine look like this:
<kirkland>                 var googleSearchIframeName = "results_003883529982892832976:ly2fmeg302s";
<kirkland>                 var googleSearchFormName = "searchbox_003883529982892832976:ly2fmeg302s";
<kirkland> emmajane: you need yours to make your google cx id or whatever
<kirkland> emmajane: do you have access to the google custom search front end?
<emmajane> kirkland, it's poolie's. I don't have all the controls as when I make my own.
<kirkland> emmajane: gotcha
<kirkland> emmajane: try this...
<emmajane> I believe I'm: cx=009852948614216791564:dr5xzrczfnu
<kirkland> emmajane: oh, there you go
<kirkland> emmajane: http://pastebin.ubuntu.com/282607/
<emmajane> so just results_009852948614216791564:dr5xzrczfnu (maybe?)
<kirkland> emmajane: replace the _[0-9]* with that
<kirkland> emmajane: yes, exactly
<emmajane> with the :etc
<kirkland>     <input type="hidden" name="cx" value="009852948614216791564" />
<kirkland> emmajane: and that too
<kirkland> emmajane: yes, with the :.*
<emmajane> thanks :)
<emmajane> I've found the documentation on this to be plentiful AND useless all at the same time. :/
<kirkland> emmajane: :-)
<kirkland> emmajane: it is a bit of a mystery
<emmajane> kirkland, /me shakes her fist at the proprietary money makers. ;)
<emmajane> ok. I've plugged that in and now I'm getting no error and no results locally. Just uploading to test.
<emmajane> kirkland, hm. same thing as locally. no results. http://tools.hicktech.com/bzr-website/
 * kirkland looks
<lifeless> meep
<lifeless> I've wandered into html land
<emmajane> lifeless, avert your eyes! :)
<lifeless> davidstrauss: its plone you're upstream on right?
<emmajane> davidstrauss, you're meddling in plone now too?!
<emmajane> davidstrauss, TRAITOR :)
<kirkland> emmajane: change <form action="search.html" id="cse-search-box">
<kirkland> emmajane: to id="searchbox_009852948614216791564:dr5xzrczfnu"
<emmajane> ah
<kirkland> emmajane: and also:
<kirkland> <div id="cse-search-results"></div>
<lifeless> emmajane: no, I was confused
<lifeless> its drupal
<kirkland> emmajane: to <div id="results_009852948614216791564:dr5xzrczfnu"></div>
<lifeless> I knew it was some webby thing
<emmajane> lifeless, LOL
<emmajane> lifeless, plone. drupal. what's the diff? ;)
<lifeless> exactly!
 * emmajane grins
<lifeless> so I was going to ask
<lifeless> what does it do for test runs; web based reporting and so on, or very console orientated?
<emmajane> lifeless, ummm. they have a bot and a farm.
<emmajane> there's a testing suite which has web-based reporting and updates the issue queue to say if patches passed the suite.
<emmajane> after that I start running out of words to repeat.
<lifeless> ;)
<lifeless> http://drupal.org/node/394888 seems relevant
<emmajane> sdboyer, you know the answer to that ^^
<emmajane> chx would know too if he were around.
<lifeless> http://testing.drupal.org/ needs more google juice
 * emmajane nods.
<lifeless> jelmer: http://testing.drupal.org/pifr/file/1/13019
<emmajane> lifeless, http://drupal.org/node/162788#comment-1697272 <-- example of integration with our issues queue.
<emmajane> not sure if you wanted to see that bit though.
<emmajane> http://drupal.org/node/162788#comment-1770146 <-- and failures
<lifeless> emmajane: thats nice
<emmajane> as much as we hate our issues queue, the test bot is pretty cool.
<lifeless> http://build.samba.org/?function=Recent+Builds;tree=samba_4_0_test uses http://launchpad.net/subunit but does its html rendering via regex and guesswork
<lifeless> so there is a bug on subunit to have a good html reporter
 * emmajane nods
<emmajane> lifeless, it can be a bit brutal to track down the right test (most of the time I'm doing docs patches and it's a wonky test that needs to be fixed), but generally I find it more useful than having nothing.
<lifeless> does it file bugs automatically?
<emmajane> hahaha
<emmajane> no.
<emmajane> :)
<lifeless> so, how do you get the integration, you just say 'test XXX' when you file it?
<emmajane> patches don't get accepted to core if they don't pass the bot.
<emmajane> (which is the issue queue integration part).
<emmajane> patches that are "red" don't go in.
<lifeless> ok
<lifeless> so you have a queue
<emmajane> yah
<lifeless> and if it passes it lands
<lifeless> and if it fails it becomes an item in the issue queue?
<emmajane> uploading a .patch triggers the bot to run the tests.
<lifeless> its basically a prettier PQM :)
<lifeless> I like
<emmajane> then you hit reload on the issue a million times and eventually the place where you uploaded your patch turns green or red.
<spm> Am trying to debug why 'bzr launchpad-login' (in a chroot) is returning "bzr: ERROR: Connection error: curl connection error (Problem with the SSL CA cert (path? access rights?))" any suggested flags? or is strace the best bet?
<emmajane> lifeless, "normal people" don't ever look at testing.d.o they just wait to get the results back.
<lifeless> emmajane: so you upload the patch to the bug tracker?
<emmajane> lifeless, yup
<lifeless> emmajane: very nice
<emmajane> it seems to work for us. :)
<lifeless> emmajane: is committing to core done by the bot, or someone taking a passed item and going 'doit'
<emmajane> lifeless, one of two humans gets to commit to core.
<lifeless> spm: apt-get remove python-curl
<lifeless> spm: :P
<emmajane> lifeless, we have a status on an issue which is, "ready to be committed"
<lifeless> spm: (don't, I'm teasing)
<spm> lifeless: ha ha. :-)
<emmajane> lifeless, then either Dries or $co-maintainer will commit the patch.
<lifeless> spm: its probably ca-certificates
<spiv> spm: what lifeless just said; is the ca-certifcates package installed?
<kirkland> emmajane: any luck?
<emmajane> lifeless, contrib modules are, of course, totally different and don't have a testing suite unless the developer chooses to create one (but I don't believe that's part of the testing bot's job)
<emmajane> kirkland, no. :(
<emmajane> kirkland, back to Bad Request.
<spm> lifeless: spiv: huh. no it isn't. lets try that then.
<kirkland> emmajane: where's the latest?
<emmajane> kirkland, Just trying to figure out what I did this time. :(
<spiv> lifeless: thinking of subunit, is it time to add --subunit to make check?
<kirkland> emmajane: it's working for me
<lifeless> spiv: yes!
<emmajane> arh. wrong tab.
<kirkland> emmajane: http://tools.hicktech.com/bzr-website/search.html?cx=009852948614216791564%3Adr5xzrczfnu&cof=FORID%3A10&ie=UTF-8&q=emma&sa=Search#881
 * emmajane bangs her head repeatedly.
<emmajane> kirkland, you are like a Google-god.
<emmajane> kirkland, thank you :)
<lifeless> kirkland: so how did you get roped into this ;)
<lifeless> [not why, how :P]
<emmajane> lifeless, I think I threatened to cry...
 * emmajane is classy like that
<lifeless> lol
<kirkland> lifeless: heh, not sure
<lifeless> spiv: should I submit a pycon talk; I think I have about 5 hours to do that in.
<kirkland> lifeless: i have a couple of semi-useful google-custom-searches up and around
<lifeless> spiv: do they do travel assistance ever?
<kirkland> lifeless: i think poolie outed me :-)
<spiv> lifeless: I'm afraid I don't know.
<emmajane> lifeless, I think hypa7ia is just working on hers. :)
<kirkland> emmajane: results, formatting look nice
<lifeless> spiv: bah, some python god :P
<emmajane> kirkland, I'll never tell who outed you. I need to protect my sources. :)
<kirkland> emmajane: heh
<kirkland> emmajane, et al: enjoy ;-)
<emmajane> bzr commit -m "Google Search is now working. Everyone buy kirkland a $drink."
<kirkland> emmajane: heh!
<lifeless> drink="bombay sapphire" \1
<lifeless> spiv: would you like to do the honours [--subunit to trunk?]
<spiv> lifeless: do we care about normal humans that might type "make check"?
<lifeless> spiv: lets say we don't, and if we're wrong change it again
<spiv> Heh.
<spiv> Fair enough.
<lifeless> its a fairly specialised interface
<lifeless> spiv: alternatively, we can add a variable PQM can set
<lifeless> but that seems like a round about way if few folk run 'make check'
<spiv> lifeless: right
<spiv> I'm ok with "just change it", as you say it's easy to undo if it causes trouble for someone.
<lifeless> BasicOSX: hi!
<lifeless> BasicOSX: I need feedback from you per bug ###(I forget, check your bugmail :P)
<BasicOSX> hello
 * igc lunch
<davidstrauss> lifeless: Nope, but I can put you in touch with people from Plone.
<spm> lifeless: spiv: fyi. that did it (ca-certs) have now moved onto a different problem, but progress :-)
<emmajane> davidstrauss, turns out lifeless just doesn't know the difference between plone and drupal.
<spiv> spm: cool
<emmajane> :)
<lifeless> davidstrauss: I don't really care about plone :P I was interested in the test discussion - see what emmajane and I covered after my gaffe
<emmajane> lifeless, oh you'll never get to live it down. ;)
<emmajane> davidstrauss, he was asking questions about the testing suite. I invented a couple of answers which may vaguely resemble the truth.
<davidstrauss> emmajane: :-)
<arkanes> are the pyrex-compiled C modules covered by the test suite?
<lifeless> davidstrauss: did you end up getting your hudson foo on ?
<lifeless> arkanes: yes
<arkanes> yay
<davidstrauss> lifeless: We're using Hudson for The Economist
<arkanes> I experimeted with compiling them using cython instead, and I ran the test suite and everything was fine, but I wasn't sure if that was a good way to exercise them
<lifeless> davidstrauss: yeah, when I ran into you in #hudson you were setting it up I think
<davidstrauss> lifeless: And I am in touch with the developer of Bazaar-Hudson integration
<arkanes> well, I ran bzr selftest, is that the right thing to do?
<lifeless> arkanes: yup
<lifeless> arkanes: as long as you've run make build
<arkanes> hmm
<arkanes> I did setup.py build insteadl
<lifeless> (setup.py build -i
<lifeless> it the inplace thats needed if you're testing in-tree
<arkanes> I installed first, tested later :P
<lifeless> thats fine
<arkanes> cython support is somethign like a 4 line patch, correct procedure is to file a bug on launchpad & attach patch?
<spiv> lifeless:
<spiv> -	$(PYTHON) -Werror -O ./bzr selftest -1v $(tests)
<spiv> +	$(PYTHON) -Werror -O ./bzr selftest -1v --subunit $(tests)
<lifeless> arkanes: doc.bazaar-vcs.org/en, developer docs are there
<lifeless> arkanes: that said, are you making it 'work with', or 'change it to use' cython ?
<spiv> lifeless: look ok?  I guess -v is probably irrelevant now.
<lifeless> spiv: -v is irrelevant
<BasicOSX> lifeless:  not seeing request for feedback, got bug number?
<arkanes> lifeless: work with
<lifeless> spiv: separately I'd like to discard the -1, but that may need discussion
<arkanes> lifeless: as in, fall back to cython if pyrex is not present
<spiv> lifeless: yes
<lifeless> arkanes: ok, cool. We don't want to depend on cython at this point as its not as widely available as pyrex (we support python 2.4 platforms)
<arkanes> yeah, I use cython and don't keep pyrex around so I just wanted it to work in that environment
<spiv> lifeless: if you make the test suite fast enough I'm sure people won't mind if -1 is left off ;)
<spiv> lifeless: ok, pqm-submitting that to bzr.dev.
<lifeless> spiv: well most submissions should land, and most failures may have multiple things wrong with them
<lifeless> spiv: :)
<spiv> lifeless: talk to oubiwann about PyCon, I think he knows stuff.
<oubiwann> lifeless: you gonna submit?
<spiv> lifeless: also, http://pqm.bazaar-vcs.org/: Running [ 3% 552 test(s) 3 failure(s) 5 errors(s) ] ...
<oubiwann> (tomorrow's the last day for proposals)
<spiv> Given the -1, I guess those are skips and known failures...
<lifeless> oubiwann: looking at the web site stuff now
<lifeless> spiv: \o/
<lifeless> sexy
<oubiwann> lifeless: awesome
<lifeless> oubiwann: I'm wondering about aid
<oubiwann> ah, yeah
<oubiwann> it's not granted for speakers, but speakers are encouraged to apply
<lifeless> 'we' don't seem to know who we'll send or not, so I have to work on the basis that I may be solo if I submit
<oubiwann> (for aid)
<lifeless> oubiwann: are you on TIP?
<oubiwann> lifeless: TIP?
<lifeless> testing in python
<lifeless> oubiwann: this is what I would submit a pycon talk about: - would you come to see it? http://rbtcollins.wordpress.com/
 * oubiwann checks it out
<oubiwann> lifeless: oh HELLZ YEAH
<lifeless> oubiwann: glad you like it :)
<lifeless> vila: aren't you meant to be sleeping?
<lifeless> spiv: I like the pqm output
<lifeless> feels much more usable to me
<lifeless> do you ?
<emmajane> beuno, just got feedback from someone who couldn't find the option to download builds on code.edge.launchpad.net/bzr. Not sure if you wanted a UI bug submitted for LP?
<arkanes> I've got a branch I'd like to submit back to bzr but the instructions on http://bazaar-vcs.org/BzrGivingBack conflict slightly with the launchpad UI, is "lp:bzr" the correct target branch?
<emmajane> arkanes, you'll upload things to your own workspace on LP and then submit a merge request.
<lifeless> oubiwann: http://us.pycon.org/2010/conference/proposals/127/
<oubiwann> lifeless: thanks!
<emmajane> arkanes, http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html#submitting-changes this has more info
<lifeless> oubiwann: its insane
<spiv> lifeless: yeah, it's much nicer to have the percentage.
<lifeless> it thinks canonical's homepage is rbtcollins.wordpress.com.  I don't know how to fix that
<spiv> lifeless: the non-zero failure and errors are a bit alarming, though.
<lifeless> oubiwann: ^
<spiv> lifeless: curiously, I saw "Current test: None
<spiv> " at one point.
<spiv> (67% of the way through)
<lifeless> spiv: yes, it means one test finished, the next had not started
<spiv> Yeah, not unreasonable.
<lifeless> oubiwann: oh, I get it.  The bio 'link' links to affiliation, not the author. BAH
<lifeless> >bah<
<emmajane> Stating the obvious: We don't have a .dmg for installing Explorer and we don't seem to have install instructions.
<emmajane> (on OSX)
<emmajane> igc, ping?
<igc> hi emmajane
<emmajane> igc, hey :)
<emmajane> igc, the woman who solved the nav bar problem for me is trying to install bzr! *woot!*
<igc> excellent
<emmajane> she's on OSX though and keeps getting errors that are getting progressively harder for me to google.
<emmajane> she's trying to get Explorer working
<igc> :-(
<emmajane> yeah
<emmajane> do you know anything about Explorer on OSX?
<igc> she ready needs to wait for the desktop installer to arrive
<igc> verterok is working on it
<emmajane> cool!
<emmajane> will it be ready "soon" or is it a long term project?
<igc> emmajane: installing Qt on OS X is easy
<igc> emmajane: but PyQt is a pain in the butt
<emmajane> she's getting errors about SIP?
<emmajane> yeah
<igc> igc: I have done it in the past but it wasn't fun
<emmajane> :/
<emmajane> that's what she's running into as well.
<igc> it's *ready* important verterok gets that installer done - hassle him when he's next online!
<emmajane> <jacine> jacinembp:PyQt-mac-gpl-4.6 jacine$ python configure.py
<emmajane> <jacine> Traceback (most recent call last):
<emmajane> <jacine>   File "configure.py", line 37, in <module>
<emmajane> <jacine>     import sipconfig
<emmajane> <jacine> ImportError: No module named sipconfig
<emmajane> that's as far as she got.
<igc> emmajane: I can't remember sorry
<verterok> emmajane, igc: hi :)
<igc> emmajane: emailing the bzr-mac list is a good idea though
<emmajane> verterok, hey ! :)
<igc> hi verterok!
<igc> I was hoping you'd pop up
<jacine> hi! :)
 * emmajane waves at jacine 
<igc> hi jacine
<jacine> hi emmajane, igc ;)
<verterok> jacine: hi
<emmajane> jacine is a designer/themer with Drupal and fixed the nav bar. We love jacine ! :)
<jacine> thanks for helping me get started :)
<jacine> hi verterok
<verterok> emmajane, jacine: here is a somewhat good step by step to get PyQt installed: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
<emmajane> verterok, can we get this added to the OSX install instructions either on the Wiki or in the Official Docs?
<jacine> hmm, reading
<verterok> igc: do you know if there is requirement on a specific pyqt/qt version? (for qbzr/explorer)
<igc> verterok: Qt 4.4 or later
<verterok> jacine: be carefull with the version ^ I don't know if qbzr works with PyQt 4.5
<verterok> igc: oh, ok. thanks! :)
<jacine> ok verterok, thx
<emmajane> verterok, jacine is involved with the Drupal design community as well. Having an .dmg would make it way easier to promote bzr within Drupal. Is the installer going to be ready "soon" for OSX? I have no idea how hard these things are.
<igc> verterok: Qt 4.5 should be fine - that's the version on jaunty
<verterok> emmajane: we could add this to the wiki...don't know in which place :)
<jacine> emmajane: ya, so far this is much harder to get running compared to CVS ;)
<emmajane> verterok, http://bazaar-vcs.org/QBzr ?
<emmajane> jacine, hehe
<emmajane> jacine, y'think? ;)
<jacine> hehe, and I have Xcode ;)
<emmajane> verterok, and http://doc.bazaar-vcs.org/explorer/en/install-osx.html ?
<verterok> emmajane: thanks to jfroy that showed me an alternative way of building the packages I think it's going to be easier than using the previous approach...but I still need to get it working ;)
<emmajane> I had igc 's branch downloaded and ready to update the docs and then we just kept getting more nad more errors.
<emmajane> \o/
<emmajane> easier is gooder :)
<verterok> emmajane, jacine: I'll work on this tomorrow, probably for OS X 10.5 first as I'll have access to my 10.4 ibook probably during the weekend
<jacine> cool
<emmajane> verterok, awesome. thank you! :)
<emmajane> igc, search is working thanks to kirkland and the nav bar is working thanks to jacine :)
<jacine> hehe ;)
<igc> emmajane: that's great news - well done
<emmajane> :)
<igc> verterok: I'm happy to test your installer on 10.4 when it's ready
<emmajane> I think jacine said she's on OSX?
<emmajane> erg 10.5 rather
<emmajane> <--- tired bear
<jacine> yeah, 10.5 :)
<igc> emmajane: must be time for some sleep soon :-)
<emmajane> igc, yeah. the anticipation of Explorer almost working for jacine is keeping me up :)
<jacine> haha ;) well, I'm gonna make it happen emmajane!
<emmajane> WOOT!
<igc> emmajane: another minor thing: the Bazaar logo is being clipped in ff 3.0 on jaunty. Can you move it right a bit?
<emmajane> igc, it's probably easier just to make the text smaller?
<igc> maybe left-align it with the Home area in the nav bar?
<emmajane> it should have loads of room though. hm
<emmajane> http://browsershots.org/screenshots/f8ab0781362b8fc8e1920f59c3cac3c4/ <-- from earlier tonight
<emmajane> igc, is it your fonts?
<emmajane> OOOoo. logo, not text.
<emmajane> how wide is your browser?
<igc> emmajane: how can I easily tell?
<emmajane> is it basically the width of the page?
<emmajane> the design rather
<emmajane> I shifted the logo to the left so that it pointed into the middle of "home"
<igc> emmajane: there's no horinzontal scrollbar fwiw
<emmajane> but on narrower screens the amount of shift can be clipped.
<kirkland> emmajane: \o/
<emmajane> kirkland, :)
<emmajane> kirkland, again, you rock! :)
<igc> emmajane: I'm on 9.04 btw
<emmajane> igc, I'm 9.04 FF 3.0.14.
<emmajane> igc, if you make your window a tad wider, does the clip go away?
<emmajane> I just want tomake sure I'm solving the right problem. :)
<igc> emmajane: wider fixes the problem
 * emmajane nods
<igc> emmajane: it is truly center aligned with "Home" - that just is too far left
<emmajane> let me add +30px to Home and leave the logo where it wants to be.
<igc> emmajane: left-aligned with the text below will look better
<emmajane> igc, uploaded
<igc> emmajane: fixed. Thanks!
<emmajane> awesome!
<emmajane> igc, I saw your note about the news too
<emmajane> I'm not loving it at the bottom, and don't mind if the headlines are in the banner space.
<igc> emmajane: ah good
<igc> emmajane: poolie wants it to look like news though
<emmajane> i'm still feeling a bit gunshy about posting things to the list after the stuff last week.
<igc> emmajane: so it needs a box and maybe some little news icon to highlight it if we move it there
<emmajane> bleh
<emmajane> dancing monkeys! :)
<igc> emmajane: wecome to my world :-)
<emmajane> lol
<igc> emmajane: open source development isn't kind on the ego :-)
<emmajane> igc, we still have some of the designer's time if you wanted me to ask him to solve it. but more direction is better than "be creative" ;)
<emmajane> igc, heh. y'think? :)
<igc> emmajane: there's a new critic every day!
<igc> emmajane: I think we need approval in principle from poolie first
 * emmajane nods
<emmajane> there is time left there, so don't feel that you or I *needs* to solve it. :)
<emmajane> to my eye I want the text on the left to be bigger so taht the news isn't lonely on the bottom right.
<emmajane> I wanted to keep the logos as a divider/end of page summary (which is why I took them out of the left side)
<emmajane> bigger/longer/other
<emmajane> (for left text)
<igc> emmajane: maajane: bumping the LHS up a text size is worth a try - it may stand out more then
<igc> typo sorry
<emmajane> kay
<igc> bbiab
<emmajane> hrm. if I do that the headings don't line up nicely. /me plays more
<spm> beating my head against the brickwall here. "bzr: ERROR: Connection error: Unable to authenticate to SSH host as" AFAICT, we have the right ssh setup and all; but clearly not. Suggested places I could/should be looking?
<spiv> As a bzr error?  I guess that means it's using paramiko...
<spiv> I'm a bit surprised its not using OpenSSH.
<spm> spiv: yeah, bzr info bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/ by way of example
<spiv> Not that it should matter either way.
<spm> spiv: ahhh. are you implying that's a different package we're missing? I don't have ssh (the binary) in this chroot so... ?
<spiv> Well, bzr will happily enough fallback to paramiko if /usr/bin/ssh doesn't exist.
<spiv> And judging from that error it appears to be doing so just fine.
<spiv> But presumably it's trying either the wrong username and/or key.
<spm> oh I dunno - it doesn't read as "happy" to me. fallback sure. ;-)
<spiv> The 'fallback-to-paramiko' part is happy.  That doesn't mean that the rest of it is ;)
<spm> heh
<spm> so is the paramiko side going to be doing the right ~/.ssh/config bits? or... ?
<spm> should i be adjusting in ~/.bazaar/authentication.conf ?
<spiv> I think it'll prefer authentication.conf
<spiv> I'm not sure if it will try use ~/.ssh at all.  I'm not very familiar with what config paramiko uses.
<emmajane> igc, the bigger font size on LHS ends up being distracting.
<spiv> (or our glue for it)
<jacine> igc: verterok, emmajane!  got it! :)  Thank you so much!
<emmajane> jacine, WOO! :)
<spm> hmmm. 'k.
<jacine> yay ;)
<spiv> I'd be inclined to just install openssh-client, personally, because I know the config for that quite well :)
<lifeless> paramiko doesn't use the ssh config, does it ?
<emmajane> jacine, let me know what can be added where to make the instructions easier. I'm not sure if the installer will include everything verterok ?
<jacine> emmajane: actually, this was perfect: http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
<spiv> lifeless: I don't *think* so, but I'm not at all sure.
<emmajane> jacine, cool!
<lifeless> ok, benefits of starting at 0630; gnight :)
 * lifeless waves ciao
<jacine> emmajane: i think we would just need to pull the other parts in...
<spm> spiv: heh; from what I can see, the only missing piece'd be the specifying of the IdentityFile, as it's not the default
<spm> night lifeless
<spiv> lifeless: move to NZ already :P
<spiv> lifeless: g'night :)
<jacine> emmajane: gonna save the links and summarize what I did before that part and send it to ya... after I create a test project.
<emmajane> jacine, awesome. I'm going to update the wiki right now to add that URL.
<spm> spiv: ARGH. cp id_rsa-ODDNAME id_rsa and same for the .pub == success. ARGH.
<emmajane> jacine, I updated the wiki to include that URL.
<jacine> where is the wiki, sorry, tab overload here...
<emmajane> http://bazaar-vcs.org/QBzr
<jacine> thanks :)
<emmajane> np
<emmajane> verterok, https://twitter.com/joncruz/statuses/4518006753 <-- you've got volunteers to help with the installer. :)
<emmajane> ok. sleep f'reals this time.
<jacine> emmajane: I'll e-mail u a link to what I'm writing
<jacine> thanks again for everything :)
<jacine> u guys rock!
<emmajane> jacine,  thanks for stickign with it. very very very much appreciated.
<jacine> ;)
<emmajane> jacine, also? thanks for fixing the nav bar. very^3 appreciated. :)
<jacine> anytime emmajane :)
<emmajane> :)
<emmajane> don't be making offers like that ;)
<jacine> hehe ;)
<bialix> hello bzr
<Peng_> Hi
<poolie> hello all
<poolie> hi jelmer?
<bialix> hi poolie
<poolie> hello bialix
<bialix> poolie: as I understand big announce is delayed so I'm planning to release qbzr 0.14.3 soon
<bialix> there is several important bug fixes
<bialix> I hope jam won't object to build another installer
<poolie> ok
 * bialix hopes there is still possible to update packages in Karmic
 * igc dinner
<poolie> sorry, back into meetings...
<poolie> bialix: with bug fixes, yes
<bialix> good
<jelmer> poolie: hi
<poolie> hi jelmer
<StyXman> I have an original branch/repo where I've been commiting all my changes so far. now I setup a project in savanah, which gives me a bazaar repo, and I intend to import all the history there. should I branch the savannah repo, then pull from my repo into this branch, and then push into savannah? did I get it right?
<Peng_> StyXman: Just push to Savannah from your original branch.
<naoki> hi jelmer
<jelmer> hi naoki
<naoki> jelmer: I can branch from git:// on Windows!  https://bugs.launchpad.net/bzr-git/+bug/382125/comments/10
<ubottu> Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New]
<naoki> I attached quick fix patch. Please confirm.
<naoki> I think bzr-git may be a killer-app for bzr on Windows, because git on Windows requires msys or cygwin. Gread job! jelmer.
<bialix> naoki: cool! \o/
<jelmer> naoki: thanks
<jelmer> naoki: couldn't we just eliminate that assert ?
<naoki> jelmer: I tryed it, but next line also uses  "self.index"
<jelmer> naoki: any chance you can try with current trunk?
<jelmer> I've pushed an alternative fix
<naoki> OK!
<naoki> It works!
<jelmer> naoki: great :-)
<jelmer> naoki: what about the other warning?
<jelmer> naoki: ?
<SamB_XP> jelmer: you really need to get together with whoever does the bzr nightly PPA and figure out what's going on with bzr-doc ...
<jelmer> SamB_XP: ? The PPA's are only for Ubuntu aren't they?
<abentley> jam or vila: Where is the 2.0.0 branch?  I can't find it on https://code.edge.launchpad.net/~bzr-pqm/ or bazaar-vcs.org/bzr
<jam> abentley: all pqm branches are now on launchpad
<jam> 2.0.0 is ~bzr-pqm/bzr/2.0.0
<jam> 2.0 stable is ~bzr-pqm/bzr/2.0
<jam> trunk is ~bzr-pqm/bzr/bzr.dev
<abentley> jam: Oh, I guess 2.0.0 is hidden because it's been merged into 2.0.
<abentley> jam: Thanks.
<jam> abentley: ah hidden from the main view?
<jam> thats a shame
<jam> given that we fully intend to continually 'merge up'
<jam> 2.0.0 => 2.0 => bzr.dev
<abentley> jam: Yeah.  I'm marking it as "development", which a new commit would do anyway.
<jam> I'm pretty sure we don't expect another commit on 2.0.0
<abentley> jam: I think the same thing won't happen to 2.0, because it's associated with a series.
<abentley> jam: getting perfect rules for this stuff is hard...
<jam> yeah
<macflag> does bzr support database version control?
<abentley> jam: The significance of 2.0.0 isn't the fact that it may or may not be under development, it's the fact that it corresponds with a release.
<jam> abentley: yeah, but I think lp only has that for a series, right?
<jam> macflag: not explicitly, though you can certainly version your sql dumps
<abentley> jam: Right.
<arkanes> so when I do "bzr pull" and there's some merges, is there a trivial option I can pass to bzr diff that's basically "diff this and the branch it was before I just updated", or do I have to look back and figure out what revision number that was?
<macflag> jam: how economical and accurate is that?
<arkanes> macflag: versioning databases is hard because they're running images, not something you can update with a textual diff
<abentley> arkanes: I don't think there's a direct way, because we don't keep a record of what pull did.
<arkanes> abentley: yeah I figured. i just do this so often, looking at the files changed in a pull and then wanting to know what got merged.
<macflag> arkanes: i'm working with reasonably small databases, does this change your answer?
<arkanes> macflag: not really
<abentley> arkanes: You want to know which of your local changes were merged?
<arkanes> macflag: the nature of a database is that it's a running image that you modify in place, rather than traditional development where you build something from an authorative source
<arkanes> abentley: I don't have local changes, it was just updates from the pull
<abentley> arkanes: When you say "wanting to know what got merged", what's an example of something that might have been merged?
<arkanes> abentley: well in this specific case i updated by bzr.dev branch
<macflag> arkanes: yeah i know, but *theoretically* there must be some format or "instantiation" to which i can convert a database, which is more suited for running diffs against, or am i wrong?
<arkanes> and there was a change to doc/developers/HACKING.txt and I'm curious to know what that was, since I just started contributing
<arkanes> macflag: sure, the sql dumps
<Lo-lan-do> macflag: SQL dumps could be that, if you added something to guarantee that rows always get out in the same order.
<arkanes> macflag: but without the cooperation of the database itself, and some smart diff tools (since a simple textual diff won't do), it can be awkward and error prone to do it
<arkanes> macflag: if you're using an embedded database like sqlite, just sticking the binary DB file in there works too
<abentley> arkanes: So I think you care about changes, not just merges.  Hmm, we've been talking about adding diff support to pull for ages, but it looks like that hasn't been done.
<arkanes> abentley: sorry, yes, I want to know what changed, not specifically was merged
<arkanes> I said merge because there was an M next to the file name :)
<abentley> arkanes: You can always do "bzr pull -c $REVISION" where $REVISION is the one that modified HACKING.
<abentley> arkanes: Sorry, diff -c ...
<macflag> arkanes: i am not familiar with bzr, so by "embedded" do you mean bzr has such sqlite support?
<arkanes> macflag: no
<arkanes> macflag: sorry, getting a little misleading
<arkanes> macflag: sqlite is a self-containted database, there is no server, so the single datafile contains the entire thing and versioning it as a binary file is sufficient to version the database
<arkanes> it sounds like thats not what you're using though so don't get derailed :)
<macflag> :)
<arkanes> abentley: hmm it looks like -c is basically exactly what I want
<macflag> arkanes: just curious, is "diff-able database support" something that we can expect vcs's to start to feature any time soon?
<arkanes> maybe it should default to your current revision instead of making you look it up
<arkanes> macflag: not really
<macflag> arkanes: no demand, or too difficult?
<arkanes> macflag: it's something that the database vendors need to start with, and they could use a vcs engine like BZR to implement
<abentley> arkanes: Cool.
<arkanes> yeah it gave me the diff I wanted
<macflag> arkanes: so the answer is "it's not what vcs's are supposed to do", right?
<arkanes> it's more that the way database engines are built makes them unsuitable for versioning by generic VCS tools
<Meths> At the end of the day if you want to version control the DB schema you just version control a SQL create script.  If you want to version control data, that's what backups are for.
<arkanes> versioning running objects in memory is a very different problem than versioning a filesystem tree
<arkanes> document based stuff like couchdb should be more amenable
<lifeless> abentley: would 'mature' work (for 2.0.0 ?)
<lifeless> davidstrauss: bug 276449, if you could comment that would be great
<ubottu> Launchpad bug 276449 in bzr "Bzr traceback when branching/pushing" [Undecided,Incomplete] https://launchpad.net/bugs/276449
<macflag> is any other vcs system equipped for database versioning any better than bzr?
 * lifeless crashes
<abentley> lifeless: I don't remember the implications, but it's easy to find out.
<Meths> macflag: Firstly you haven't defined "database versioning" - schema, data or both.
<macflag> Meths: both
<abentley> lifeless, jam: Mature looks like a good status for 2.0.0
<Meths> macflag: Secondly all VCSs are pretty much the same, they can all version a SQL script but none will version a binary blob.
<abentley> Meths: Most VCSes will version a binary blob, they just can't diff it.
<Meths> macflag: So either use the DB backup system for your database to create backups at version changes (or whenever you need them) or dump the SQL at various intervals
<macflag> Meths: also, what about data only?
<Meths> abentley: ah, true
<Meths> macflag: data can be dumped or backed up
<Meths> macflag: It's data that takes you to dumping or backing up for the "both" scenario too
<macflag> Meths: so i guess dealing with dumped data only would be absolutely fine, right?
<macflag> Meths: actually i don't need to deal with both
<Meths> macflag: Depends, the biggest issue with database versioning is that data for a new schema won't easily load back into an old schema, so versioning independently is just one big headache - hence all DBMSs support backups and none (AFAIK) support version control
<macflag> Meths: for example, when / how often does mediawiki generate a new schema?
<Meths> no idea, read their release notes
<macflag> not so often i think, so i guess i could deal with such steps manually
<macflag> and then i could stick to dumped data diffing
<Lo-lan-do> When merge requests are sent to the bzr devs, they go to a pqm, right?
 * Lo-lan-do thinks his 2009-05-07 patch should be either accepted or rejected
<macflag> Lo-lan-do: what's the third option?
<Lo-lan-do> Apparently, "simply ignored".
<Lo-lan-do> I'm tempted to add "presumed forgotten".
<luks> that's quite popular option, unfortunatelly
<Lo-lan-do> I thought pqm was there to keep track of merge requests?
<abentley> Lo-lan-do: No, merge requests are tracked on Launchpad.
<abentley> Lo-lan-do: PQM simply performs the merge when it's been approved.
<Lo-lan-do> Ah, got it wrong then.  But my bundle sent to the list was forwarded to Launchpad though, right?
<abentley> Lo-lan-do: No.  It would hopefully be tracked in bundle buggy, but that's not being used anymore.
<Lo-lan-do> O-kay, so the bundle's status *is* "forgotten".
<abentley> Lo-lan-do: Yes.  If you look at the list of unreviewed stuff on Launchpad, it's pretty short: https://code.edge.launchpad.net/bzr/+activereviews
<Lo-lan-do> I see.
<Lo-lan-do> I guess I'll rebase onto trunk and send a new bundle then.
<abentley> Lo-lan-do: Sure.  You'll want to use merge@code.launchpad.net as the address and specify the branch on launchpad you want to merge into.
<abentley> Lo-lan-do: I recommend lp:bzr
<Lo-lan-do> Will do.  Currently converting the local branch to 2a, which seems to take some time.
<abentley> james_w: I am making a custom "distribution" of bzr 2.0.0 with 4672:lp:/bzr/2.0 applied.  I am having trouble setting up the right version numbering so that zc.buildout likes it.  Any ideas?
<jam> spiv: are you still around?
<james_w> abentley: afraid not, I've never used buildout
<jam> abentley: it seems to me that if you just did a custom 2.0.1b1 or rc1 would be easier
<jam> take the current 2.0 branch, and package it
<abentley> james_w: It installs packages using the standard setup.py foo.  I just don't know if it's appropriate to change bzrlib.version_info to (2, 0, 0, 'launchpad', 0) or what.
<james_w> I think bzr will reject that
<james_w> you could tweak the last number, but that may not be enough
<james_w> you could make it (2, 0, '0lp', 'release', 0)
<james_w> but that might not sort correctly
<abentley> james_w: What's the right way to tweak a package number that has distro-specific changes?  Where your target version number is something like 2.0.0-ubuntu-1 ?
<james_w> we don't tweak the version in setup.py
<james_w> we just do it from the package version number
<jam> abentley: if you look it bzrlib.__init__.py _format_version_tuple
<jam> we only support 'alpha' 'beta' 'final' 'dev' and 'candidate' in that field
<jam> all others must be pure integers ('%d' formatting)
<jam> so I would recommend "2.0.1a1" if that works best for you
<abentley> jam: Okay, I'll give that a go.
<abentley> jam: Would deprecation warnings be suppressed for an alpha?
<jam> abentley: no
<jam> only for 'final'
<jam> bzrlib.commands.main:
<jam> # Is this a final release version? If so, we should suppress warnings
<jam> if bzrlib.version_info[3] == 'final':
<jam>     suppress_deprecation_warnings(override=False)
<jam> though I've noticed that it doesn't actually work with python2.6, because something on my path is also adding a deprecation warning
<abentley> jam: *facepalm*
<jam> so you actually need "override=True".
<poolie> hi jam, abentley
<abentley> poolie: Hi.
<jam> hi poolie
<abentley> jam: I think I'm going to replace bzrlib.__version__ with '2.0.0-lp-1' in setup.py.
 * Lo-lan-do ponders adding a --no-remember option to bzr push
<Lo-lan-do> Would that have a chance of being accepted?
<abentley> Lo-lan-do: bzr already has a --no-remember option.
<jam> abentley: though I don't think we pay attention to it...
<jam> in the case that there is no current default push location, it always gets set
<jam> Lo-lan-do: you could probably turn the 'remember' field into a tri-state boolean (True, False, None)
<jam> whatever you would call that other than boolean .. :)
<jam> Lo-lan-do: or are you looking for a --forget option?
<abentley> jam: We pay attention to it, it just disables a previous --remember.
<jam> abentley: I just mean that internally --no-remember is equivalent to not passing --remember
<jam> which is different than saying "don't remember this path even though there is nothing already set"
<jam> if you change the run(..., remember=None) then we can tell the difference
<abentley> jam: Sure.  I did write the code that adds those hidden inversion options.
<abentley> jam: When it gets up to trinary, I usually use strings: "yes", "no", "auto".
<Lo-lan-do> Sorry, my mum chose this particular moment to phone :-)
<vila> abentley: Isn't it ternary ? I ask before I jokingly use tri-lean in French as opposed to boo-lean...
<Lo-lan-do> I was thinking of making the remember a tristate, yes, *and* getting it not ignored when no default is set.
<Lo-lan-do> But a --forget option would be nice, independently.
<abentley> vila: It looks like ternary is preferred, but both are used.
<vila> but otherwise, I've a strong preference for True, False, None myself as the extended boolean, because it perfectly matches to "I know it's true, I know it's false or I don't know"
<vila> abentley: thks
<abentley> vila: If None didn't evaluate to False in python, that would be okay with me, but I think explicit description of behavior is clearer.
<vila> abentley: good point, my coding style generally compensates  that by using 'if xx is None' before attempting 'if xx'
<Lo-lan-do> How long does it usually take for merge requests to show up on https://code.launchpad.net/bzr/+activereviews ?
<jam> Lo-lan-do: usually fairly close to immediate, I believe
<jam> are you sure you had the right submission target?
<Lo-lan-do> I used "bzr send --mail-to merge@code.launchpad.net lp:bzr"
<Lo-lan-do> (As suggested by abentley)
<jam> Lo-lan-do: I have very little clue about merge-by-email, I always just push a branch up and click the "propose this branch for merging" link.
<jam> poolie: poke on https://code.edge.launchpad.net/~jameinel/bzr/2.0-cache-cix/+merge/11465
<jam> that, and you seem to have 2 branches 'approved for merging" on the active reviews page
<_oggy> hi, i need to interface with an svn repo. the repo uses svn:externals. i know that up until a few months ago, bzr (and hence bzr-svn) didn't support nested trees. with 2.0 out, what's the current status of that?
<Lo-lan-do> jam: I guess I could push my branch, but I don't see a link to propose it for merging.
<jam> if you look on my page: https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple
<jam> Branch Merges
<jam> Propose for merging
<jam> about in the middle of the page, towards the left
<jam> though you may not see it for *my* branches
<Lo-lan-do> Oh, so it needs to be on Launchpad?
<Lo-lan-do> I mean, I can't propose to merge a branch hosted elsewhere?
<jam> Lo-lan-do: well, you can have lp mirror it, but Launchpad certainly needs to know about it
<jam> I think you can register the branch to launchpad, and then propose it from there
<Lo-lan-do> I guess I'd need a Launchpad account anyway.
<jam> Lo-lan-do: you'd have to ask abentley for more info about sending requests by mail. I believe he does so regularly, I've *never* done so
<jam> Lo-lan-do: ah, I think you need to gpg sign your merge request with a key that LP recognizes
<Lo-lan-do> I'd rather stick with emails, yes.
<jam> so you still need an account for email access
<jam> so if you'd rather
<jam> send it to me, and I'll propose it
<poolie> hi jam, Lo-lan-do
<poolie> jam, poke for a review?
<poolie> ok, though probably not tonight :/
<jam> poolie: yeah, its been sitting there for ~1month
<poolie> sorry
<jam> someone else can do it, but I thought we wanted it in the 2.0.x series
<poolie> we should also have a look at moving reviews from bb
<jam> and I thought you explicitly requested it, thus I wanted to give you first dibs at reviews
<poolie> or finishing them off
<bialix> hello jam
<jam> hi bialix
<bialix> jam, I'm planning to release qbzr 0.14.3 very soon. In particular there is important bug fix for TBZR users (bug #433137). I'd like to know is you keen to build new installer or I should strongly suggest to windows people upgrade via qbzr installer
<ubottu> Launchpad bug 433137 in qbzr/trunk "[master] qcommit should support tree root as valid initial selection with pending merges" [Critical,Fix released] https://launchpad.net/bugs/433137
<bialix> anybody knows does 'root:' revision id is supported inside bzrlib or this is unrelated to bzrlib?
<jam> bialix: I believe "root:" is a generic file id for loggerhead indicating the root of the tree, but I'm not positive
<jam> I'll build an installer if this is serious enough
<jam> though I wonder about getting bugfixes in to the 2.0.1 release, rather than forcing everything into the 2.0.0-XXX releases
<bialix> jam: well, we have several duplicates of this bug already
<bialix> maybe 2.0.1 is better
<bialix> maybe
<bialix> I hope website stuff will be released soon, so 2.0 will go out officially
<bialix> but https://launchpad.net/bzr/2.0 does not provide any hints about ETA for 2.0.1
<jparker1> the release notes for 2.0 mention an "upgrade guide"; where is this?
<jam> bialix: official position is "when reasonable based on bugfixes landed in 2.0.x branch", but something like 1 month post 2.0.0, though again we are having difficulties getting 2.0.0 official announced
<bialix> jparker1: http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html
<jam> jparker1: note that on http://doc.bazaar-vcs.org/latest/en/ there is a Search box
<bialix> jam: official position is related to bzr core I suppose, right?
<jam> i believe it is the approved statement in 'cycle.txt'
<bialix> jam: any way I will build qbzr installer.
<idnar> argh
<idnar> do I have to add a new entry to locations.conf to override a more general one?
<idnar> I was hoping I could just do eg. bzr push --remember <differentlocation>
<hsn> how do i resolve Conflicting tags issue during push?
<awilkins> Anyone tell me an editor that doesn't append a line terminator to the last line?
<hsn> vim?
<awilkins> Nope. vim, gedit, and nano all seem to append line terminators where there were none before... trying to edit "location" in a transplanted lightweight checkout
<awilkins> But it doesn't like the linefeed
<awilkins> Appears the answer to my question is "cat"
<awilkins> cat > location
<awilkins> file:///home/adrian/branch/location^D
<fullermd> I woulda gone with `echo -n` myself.
<awilkins> I remember using that before too
<hsn> vim: help endofline ->  When writing a file and this option is off no <EOL> will be written for the last line in the file.
<fullermd> Though I think vim has a....   yeah, what hsn said.
<awilkins> hsn: I don't actually believe it though, did you read all the caveats in that
<awilkins> I don't think I got it to work
<awilkins> I remember wrestling with it
 * awilkins tries again
<fullermd> I've never tried using it, so it may be harder than it sounds.
<fullermd> Alternate crazy solutions include editing with $WHATEVER, then using dd or head to cut off the \n  ;)
<brmassa> guys, im getting bzr: "ERROR: Permission denied: "/bazaartest": [Errno 13] Permission denied"
<brmassa> what should i do?
<hsn> sudo
<brmassa> hsn: is it for me?
<awilkins> Aha, you have to pass -b to vim
<awilkins> Then it automatically remembers the no-line-endingness
<brmassa> ??
<antoranz> Hi, guys!
<antoranz> why doesn't bzr ask for ssh password (using bzr+ssh or sftp) on windows?
<antoranz> it says that the only available methods to authenticate are password and keys.... but it doesn't ask for the password in the first place
<bob2> sure the remote server supports paassword auth?
<SiDi> Hi there
<antoranz> well.... yes, I can login (server asking for the password) on that hohst by ssh
<SiDi> Is there a method to allow people to code without them to have an account with an actual shell defined ?
<SiDi> s/to code/to push code/
<antoranz> when it fails, bzr says: supported auth types: ['publickey', 'keyboard-interactive']
<antoranz> also, ssh password authentication works like a charm if I run bzr from a GNU/Linux box against that ssh server
<awilkins> SiDi: If you set their shell to /bin/false in the /etc/passwd file that will prevent them using a shelll
<awilkins> Or not .... http://www.semicomplete.com/articles/ssh-security/
<SiDi> awilkins: but that'll break bzr+ssh:// :/
<bob2> look in the contrib dir in the bzr source
<SiDi> will do, thanks
<awilkins> Which, /bin/false, or setting AllowGroups?
<awilkins> /bin/false shouldn't break bzr+ssh:// AFAIk
<awilkins> Ok, it does
<awilkins> I'm an idiot
<SiDi> awilkins: if it can make you feel better, i discovered it did by constating it
<abentley> awilkins: bzr+ssh runs bzr on the remote machine.  That's all it needs to be able to run.
<lifeless> moin
<lifeless> davidstrauss: bug 276449, if you could comment that would be great
<ubottu> Launchpad bug 276449 in bzr "Bzr traceback when branching/pushing" [Undecided,Incomplete] https://launchpad.net/bugs/276449
<davidstrauss> lifeless: Sorry, that's pretty ancient
<davidstrauss> lifeless: I'd have to contact that (former) client to get a copy
<tolstoy> Are the loggerhead devs here?
<tolstoy> Any reason loggerhead doesn't work using bzr 2.0?
<tolstoy> AttributeError: 'module' object has no attribute 'ProgressBarStack'
<igc> morning
<tolstoy> Hm. Looks like something changed in bzrlib 2.0 that broke loggerhead.
<lifeless> davidstrauss: no worries
<lifeless> davidstrauss: I've closed it
<zsquareplusc> tolstoy: i think launchpad uses bzr 2.0 and loggerhead. there should be a working version i'd guess
<tolstoy> zsquareplusc: I was trying to pull down the latest, but I think I see where I messed that up.
<lifeless> mwhudson: ^
<mwhudson> tolstoy: what version of loggerhead are you using?
<tolstoy> No idea.
<mwhudson> tolstoy: i thought the latest release had the fix for that, certainly loggerhead trunk does
<tolstoy> I think I have a "real" copy somewhere, and my running copy syncs with that, so I just need to figure out what directory I'm in. ;)
<tolstoy> mwhudson: I'll see what I can pull.
<tolstoy> Now on version 345, which is promising.
<tolstoy> Oh, wait, that's not right. That's the one I already have.
<tolstoy> Is this the right repo? http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/
<tolstoy> mwhudson: The last revision I can see is May 13, 2009. That can't be right.
<mwhudson> oh right
<tolstoy> Did the repo change?
<mwhudson> tolstoy: loggerhead trunk is now http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich
<mwhudson> tolstoy: we upgraded to 2a
#bzr 2009-10-02
<tolstoy> Hm. Startup like things seem to have changed.
<MTecknology> a cron to rotate images would have some issues
<MTecknology> * wrong chan
<tolstoy> Works!
<MTecknology> form?
<MTecknology> formapi?
<MTecknology> fine..
<mwhudson> tolstoy: cool
<tolstoy> mwhudson: I see it now displays tags.
<mwhudson> yes
<tolstoy> Headings are centered, but the data in the columns isn't. Now I can't remember if it's always been that way.
<MTecknology> ok - this shouldn't be too hard.....
<MTecknology> I'm getting this error   warning: mysqli_fetch_object() expects parameter 1 to be mysqli_result, array given in /var/www/d6/includes/database.mysqli.inc on line 144.    which seems to be coming from thsi line    $rslts = db_fetch_array(db_query('SELECT title, image, titlelink, content FROM {udsidebar} ORDER BY position'));
<Peng_> Wrong channel?
<MTecknology> yup....
<MTecknology> sorry
 * Peng_ /away!
 * igc out for a bit - bbl
<awmcclain> Is there no way to specify the umask for bzr+ssh, is there? How do other people set up servers with shared branches?
<tolstoy> We did it the hokey way. All our accounts on that machine have umask of 000, with the same group as the bzr repo.
<awmcclain> tolstoy: Hrm. How did you specify the umask? Altering the umask in /etc/profile doesn't seem to work with bzr+ssh. (new branches are still 755 instead of 775)
<awmcclain> We have the same group set up with everything as well
<tolstoy> Also set it in .bashrc
<tolstoy> Our repos are on Solaris. I think interactive shells source one, and non-interactive source the other.
<tolstoy> I can never remember, and maybe it varies from platform to platform.
<awmcclain> tolstoy: that's ~/.bashrc, right?
<tolstoy> yes, of the account that's doing the logging in.
<awmcclain> ok, i'll try that
<awmcclain> Nope.
<awmcclain> drwxr-sr-x  3 andrew dev 4096 Oct  2 01:22 badges3
<tolstoy> So, you're doing something like bzr push sftp://tolstoy@host/path/to/repo?
<tolstoy> ~tolstoy is the thing that should have the bashrc/profile/bash_profile umask setting.
<tolstoy> Er, the account.
<awmcclain> ah, no, we're doing it over bzr+ssh
<awmcclain> bzr+shh://host/path/to/repo
<awmcclain> ssh
<awmcclain> Heh. Ssh is somthing else entirely.
<tolstoy> I thought sftp was on top of ssh.
<awmcclain> Isn't pushing over bzr+ssh much faster than sftp?
<awmcclain> "Smart server" and all that?
<tolstoy> Maybe.
<tolstoy> You have a smart server running?
<tolstoy> We don't have that, so no doubt things are different.
<awmcclain> tolstoy: Well, smart server is basically invoking bzr on the server side. Nothing really runs, per se.
<tolstoy> Right. I thought it had a config file for perms and so on. But it's been a while.
<tolstoy> We didn't use it because a year or so ago, it was just one too many steps.
<awmcclain> ok, a tiny bit slower, but not by much
<awmcclain> oh? maybe that's why i'm missing.
<awmcclain> ug, and no, sftp:// still gives me 755. >:(
<tolstoy> Hm..
<tolstoy> What I ended up doing under similar circumstances was reading the bash man page on that particular server and trying to determine which files it sourced under which conditions.
<verterok> emmajane: around?
<emmajane> verterok, ish :)
<verterok> emmajane: hi, I have a *experimetal* pyqt4 installer for 10.5
<emmajane> verterok, oh! cool!
<verterok> emmajane: do you know of someone willing to try it?
<emmajane> verterok, let me see if jacine is around.
 * emmajane pings everyone she can find....
<verterok> oh, I can ask in the channel :) anyone with OS X 10.5 willing to try a PyQt4 installer?
<emmajane> hehe :)
<verterok> emmajane: don't worry, we can test it tomorrow :)
<verterok> emmajane: is just the first one that looks like it's working :p
 * emmajane hates waiting :)
<emmajane> I've got two peeps :)
<emmajane> litwol and dww are both on 10.5
<litwol|mac> hmm?
<emmajane> :)
<verterok> litwol|mac: hi
<litwol|mac> link me
<emmajane> \o/
<verterok> litwol|mac: http://verterok.com.ar/PyQt-4.5.4.dmg
<verterok> litwol|mac: it requires Qt installed (I used 4.5.2 for the build)
<litwol|mac> fail http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg
<verterok> litwol|mac: hmm, looks like it never prompted for admin password, right?
<litwol|mac> bingo
<verterok> litwol|mac: building a new one :)
<litwol|mac> k
<verterok> gimme 2'
<dww> verterok: emmajane just had me try your installer...
<litwol|mac> in the mean while maybe you can explain what am i installing ?
<dww> verterok: "Install Failed"
<dww> verterok: "The Installer could not install some files in "/".  Contact the software manufacturer for assistance."
<litwol|mac> dww: http://litwol.com/sites/litwol.com/files/Install_PyQt_4-20091001-214409.jpg
<verterok> dww: litwol|mac, it's a PyQt4 standalone installer, but if it works, it will be included in the bzr OS X installer
<verterok> dww: I'm uploading a new one 2'
<litwol|mac> brb
 * dww nods and agrees with litwol|mac's screenshot
<verterok> litwol|mac, dww: uploaded new version that ask for admin rights: http://verterok.com.ar/PyQt-4.5.4-1.dmg
 * dww tries again
<dww> "Mounting failed" ;)
<verterok> dww: hmm, looks like the upload did't finished yet :/
<dww> that'd explain it. ;)
<verterok> yeap, looks like the scp is stalled
<verterok> I'll cancel it and try again
<verterok> dww: now it fully uploaded
<dww> that's more like it...
<verterok> dww: do you have Qt installed right?
<dww> says it worked.
<dww> i'm honestly not sure... I don't write GUIs. ;)
<verterok> dww: ok, coo. could you try something?
<dww> sure.
<verterok> dww: in a terminal: python -c "from PyQt4 import QtCore, QtGui"
<dww> (is Qt included with osx and/or xcode at all?)
<verterok> dww: no, is a separate download
<verterok> dww: and not a small one :(
<dww> yeah, no Qt here.
<dww> ImportError: dlopen(/Library/Python/2.5/site-packages/PyQt4/QtCore.so, 2): Library not loaded: QtCore.framework/Versions/4/QtCore
<verterok> dww: ok, so it's working in some way...but wihtout qt we can't test it
<verterok> dww: thanks a lot!
<dww> where's the "uninstall" button? ;)
<verterok> dww: that was about to say :)
<verterok> dww: open thre installer again
<dww> ok, did so
<verterok> dww: Cmd + i
<dww> k
<verterok> dww: it expand the two items, those are the files installed
<verterok> dww: I can give a script to remove them ;) gimme a minute
<dww> so just manually purge them?
<dww> no, that's fine... i see them.
<verterok> dww: yes, nothing else is needed
<verterok> dww: ok, cool.
<dww> wow, except: ultra annoying the cmd-i window disappears whenever I make any other app (e.g. iterm) active. :(
<dww> verterok: also, might be nice if "sip" made its own subdir in site-packages instead of using the root...
<verterok> dww: I can't change the layout :(
<dww> drat
<dww> any idea how to keep the cmd-i window from disappearing? :(
<dww> i was about to take a screenshot of it. ;)
<verterok> dww: no ide :(
<verterok> dww: rm -Rf /Library/Python/2.5/site-packages/sip* /Library/Python/2.5/site-packages/PyQt4*
<dww> that was the easy part. ;)
<dww> it's the stuff in /System I'm being a little more careful about.
<verterok> dww: yeap :) rm /System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/sip.h
<dww> verterok: fear not, I have a screenshot now. ;)
<dww> working fine.
<verterok> dww: ok
<verterok> dww: thanks!
<dww> interesting: FYI: sip.h was installed chmod 664 instead of 644 like everything else in that dir...
<dww> verterok: not sure if that's something you control.
<verterok> dww: yes, I can change that. good catch
<litwol|mac> back
<dww> sadly, I didn't look closely at any others before I did.
<litwol|mac> what to test ?
<dww> verterok: but you might want to go through and check the perms on all the files...
<verterok> litwol|mac: dww already installed it, thanks!
<litwol|mac> cool
<litwol|mac> cheers
<verterok> dww: yes I just need to click one button in PackageManager: "apply recomendations" :)
<dww> good idea.
 * verterok is still learning this mac installers thing
 * dww shrugs
<verterok> dww: also I'll change the location of the sip stuff that it's in System/ to /Library
<emmajane> verterok, did you make it work? :)
<verterok> emmajane: partially :)
<emmajane> WOO! :)
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/427736
<ubottu> Launchpad bug 427736 in bzr "bzr1.17 on launchpad streams wrong data, causes "unknown object type identifier 60" in bencode pulling from pack into 2a repository" [Critical,In progress]
<lifeless> spiv: don't set 2.0.1 as a milestone in trunk; target to release 2.0, then milestone that task
<spiv> Oh, blah.  Right.
<lifeless> spiv: I've done it for you
<spiv> I guess I see how that makes sense.
<spiv> Thanks.
<lifeless> it lets use record what actual trunk release it makes it into
<lifeless> while still recording it as a blocker for 2.0.1 [thats what you intended, right?]
<spiv> As a user I just think "this should go into 2.0.1"
<spiv> And there's a drop down right there that lists 2.0.1.
<lifeless> in which case, don't set a milestone at all
<lifeless> yeah
<spiv> So I unthinkingly did the obvious thing :/
<lifeless> so, I've unmilestoned it completely now
<lifeless> I'll add a bug comment to explain the noise
<spiv> Thanks for cleaning my mess :)
<dww> verterok: anything else?  I'm about to flee.
<verterok> dww: no, thanks a lot!
<dww> no problem.
 * dww bows
<verterok> emmajane: dww didn't have Qt installed, and it's big install/download :)
<lifeless> spiv: you might like to eyeball how I've leftit.
<emmajane> verterok, that was the 1+Gig one that jacine had to wait for last night, IIRC
<verterok> emmajane: yes, actually. the non-sdk is a bit smaller ~140MB
<verterok> emmajane: if jancine wants to download, here is a direct link: http://get.qt.nokia.com/qt/source/qt-mac-opensource-4.5.3.dmg
<emmajane> verterok, she got Explorer working last night. :)
<verterok> emmajane: oh, good to know
<emmajane> she has fast internets
<emmajane> or rather: she got it *installed*
<emmajane> http://dl.getdropbox.com/u/912092/bzr-install.txt <--- I have to update the wiki with her instructions
<verterok> emmajane: cool
<emmajane> yah
<lifeless> spiv: UI bug filed
<igc> emmajane: fyi, I've changed the banner image to be explorer until you have the carousel going
<emmajane> igc, perfect
<spiv> lifeless: btw, I haven't updated the 2.0 branch to use subunit yet.  I'm not sure how to do it nicely while retaining the '[ascii]' prefix on the 2nd test run...
<lifeless> spiv: just nested progress would do it; there isn't a CLI for that yet
<lifeless> it would look like
<lifeless> echo "progress: 2"
<lifeless> before the tests run at all
<MTecknology> Is it possible to pull just the head of a bzr branch? I'd like to be able to pull it sometimes w/o the .bzr directory
<lifeless> but, may need testing to make sure it all hangs together correctly.
<lifeless> could also tag the second half, but I haven't put tags into the PQM UI
<lifeless> MTecknology: do you mean 'get a copy of the content of the head' ?
<MTecknology> ya
<lifeless> bzr export
<MTecknology> thanks :)
<spiv> spm: around?  Would you mind zapping my current PQM request?  It has an mildly embarrassing wrong commit message.
<spiv> I did specify a sane message to pqm-submit, but I forgot to write "-m"...
<spiv> And so pqm-submit silently ignored that argument and just used the last commit on the branch :/
<spiv> I should hack my copy of pqm-submit to require -m, the automatic behaviour is never what I want.
<lifeless> spiv: or update your local copy
<lifeless> I doubt you've done so in uhm 2 years
<lifeless> revno: 55 [merge]
<lifeless> timestamp: Tue 2008-04-01 18:00:47 +0800
<lifeless>   Merge John's changes to make --message mandatory.
<spiv> lifeless: Oh, hmm.
<spiv> lifeless: odd, I've definitely gone through and systematically updated all my plugins several times since that date.
<spiv> lifeless: "No revisions to pull.", and bzr plugins -v says it is using the copy I think it is.
<spiv> (I have revno 60)
<Nannu> hi
<Nannu> how to run bzr-gtk?
<spiv> lifeless: hmm, no spm it seems... I don't suppose you can kill that PQM job for me?
<spiv> Ah well.
 * spiv grabs some lunch.
<lifeless> spiv: no, I can't
<lifeless> spiv: pjdc can
<lifeless> spiv: want to merge 2.0 to .dev? or shall I?
<spiv> lifeless: I was about to :)
<lifeless> cool, shoo :)
<spiv> lifeless: I was going to use it as an opportunity to make my intended commit text appear somewhere, at least ;)
<lifeless> we need a report 'fixed in .dev fix committed in malone'
<spiv> Yes.  Or even better for LP to just do it...
<lifeless> do you mean change the status?
<lifeless> spiv: did you send it to pqm? I see rev 4722 from poolie yesteday, nothing playing,
<lifeless> spiv: I'm guessing it failed or you were distracted ;)
<lifeless> spiv: if it failed I'd like to help, if I can
<spiv> lifeless: you must have refreshed PQM a second too soon!
<lifeless> heh:)
<spiv> I did spend a bit of time puzzling over the NEWS conflicts and checking that I was supposed to duplicate them etc.
<lifeless> yeah
<lifeless> ETOOMANUAL
<spiv> I'm a bit puzzled by the current state of the 2.0 NEWS file, actually... why does it have apparently current sections for both 2.0 series and 2.0.1?
<lifeless> its not an obvious useful thing *today*, but once 2.1b1 is released the utility will be clear
<lifeless> spiv: grawk, possibly me. Possibly someone else
<spiv> Yes, I agree that the policy for lp:bzr's news file is sane.  I just needed to dig up the email to ensure that sanity was also the official policy :)
<lifeless> spiv: :) - I wasn't doubting that, just idly commenting
<vila> hi all
<vila> lifeless, spiv : just to help me wake up, can you remind me in a few (and slow) words what that policy is ?
<vila> numerical or chronological ?
<lifeless> numerical
<lifeless> I htink
<lifeless> it may not be strictly defined in fact
<spiv> vila: the policy I'm referring to is that when merging from 2.0 -> dev, NEWS entries for things added in 2.0 should appear in dev's NEWS in both the appropriate 2.0.x section, and the appropriate 2.1.x section.
<vila> lifeless: ha, good, I thought so and was wondering if I misunderstood something
<spiv> And, yes, I think numerical.
<spiv> But I haven't had cause to really care about that yet :)
<lifeless> vila: you've seen the pqm bling, I presume? :)
<vila> spiv: Hmm, I think I'm rather strongly against duplicating NEWS entries...
<vila> lifeless: ooooh yes
<spiv> vila: then you should reply to the relevant thread :P
<vila> only the screenshot so far
<lifeless> vila: the reason is that once 2.1b1 released, a NEWS entry in 2.0.1 (say) *doesn't* indicate that it was fixed in 2.1b1
<vila> spiv: damn, so I *missed* something or is that a today's thread ?
<lifeless> vila: weeks ago
<spiv> vila: but I think it's best to have the entry appear at the right point in each release series, so it's obvious what is fixed, and not fixed, in each release.
<lifeless> another good point
<lifeless> over and above inferred data
<lifeless> vila: which reminds me :)
<lifeless> vila: please refuse the temptation to guess about milestones for already fixed bugs
<vila> I did that ?
<lifeless> vila: its better to have it unknown than wrong, I think. Unknown means 'we don't know'. <VALUE> means 'buggy-before' to folk looking at the bug tracker
<lifeless> vila: yes, about 3 hours ago :)
<spiv> The duplication does grate a bit, but I think it's really just a natural consequence of the duplication of effort inherent in maintaining multiple concurrent release series.
<vila> I thought I rather mark fix released *without* milestone than putting an unverified one
<vila> lifeless: I slept this night, I'm sure, so 3 hours ago wasn't me, bug # ?
<lifeless> vila: you put 2.1b1 as the milestone for a report that came in
<lifeless> vila: uhm maybe you did it your evening. I noticed my afternoon :)
<vila> lifeless: hmm, that rings a bell, but I was 90% sure for that one, I'll double-check
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/363452
<ubottu> Launchpad bug 363452 in bzr "bzr revert crashes after shelving a file add on a new repo." [Undecided,Fix released]
<vila> lifeless: ooh, that one, ok
<vila> hmm
<lifeless> of course, I could be wrong;)
<lifeless> but, I fixed revert a while back now
<vila> well, I think in that case I thought that occurred in bzr.dev and things  are a bit blurry these weeks, so, yes, you're right I shouldn't have guessed,
<vila> but on the other hand, I *had* some rough idea of when...
<lifeless> spiv: btw, 3918 - don't close it ;)
<lifeless> the merge improves but does't complete i
<lifeless> t
<lifeless> \o/
<spiv> lifeless: I won't :)
<spiv> lifeless: as the commit message says, it's a fix "for" 3918, not necessary a fix *of* ;)
<lifeless> spiv: thanks, was just being preemptive, as its a grey area
<lifeless> thought I'd save you some overhead
<spiv> Yes, actually I was going to forget to update bugs at all until you said that!
<spiv> So it's good you did :)
<lifeless> :P
<lifeless> I've done 403322
<bialix> hello bzr
<lifeless> hai
<lifeless> bialix: I would appreciate if you could give dirstate2 a test spin; just to know how it behaves on windows (only use it on copies :))
<bialix> lifeless: ok, maybe this weekend
<bialix> what should I test specifically?
<lifeless> bzr commit
<bialix> just run some commit-status-diff?
<lifeless> # other window
<lifeless> bzr diff
<lifeless> bzr status
<lifeless> bzr diff | more
<lifeless> # go to editor
<lifeless> # put in commit message and have it do the commit
<lifeless> --- that sort of thing
<bialix> ok, I understand
<lifeless> try to break it; I expect you can
<lifeless> its a prototype, but I want to get a feeling for how far off it is
<bialix> I'll try
<lifeless> thanks ^^
<bialix> gary gary where are you
<lifeless> spiv: I'm fairly happy with: https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=dirstate - all the in progress are dirstate2
<lifeless> spiv: and I haven't found any other dirstate bugs in the bts
<spiv> lifeless: nice
<spiv> lifeless: very nice, in fact!
<spiv> Ok, I'm off.  Have a lovely weekend everyone!
<lifeless> ciao
<fullermd> Holy crow, I just typed 'bzrip2'.  There was some serious evil going on in the naming process somewhere...   :|
<lifeless> :)
 * igc dinner
<vila> lifeless: wow, nice bling on pqm... we lost the timings though, do you plan to do more than addressing the failures/errors mismatch there ? Like, hmmm, an option to get back the subunit output even for successful submissions ?
<lifeless> vila: no
<lifeless> vila: raw subunit should still be in the log
<lifeless> its just the status region that parses
<vila> ok, but there is no option to get that log back right ?
<lifeless> I think its rsynced around somewhere in the dc
<lifeless> you thinking for baseline timing stuff? The machine has other PQM instances on it.
<lifeless> so potentially noisy
<vila> yeah, no, not really the timing stuff itself, more generally have some reference about what tests are skipped, etc
<vila> and even if noisy, the timings can give some indications
<lifeless> Patchs Gratefully Accepted
<vila> :D
<vila> I can put that on my TODO list, but that does not mean it will occur any time soon :-/
<lifeless> vila: me neither which is why I'm not offering
<vila> lifeless: but no worries, the new feedback is *very* welcome, thks for that
<lifeless> I wanted '% complete', that was the main thing :)
<vila> sure, me too, that's what I'm thanking about :D
<vila> should I also thank spiv may be ?
<lifeless> vila: he took the 'risk' of turning it on once I had the pieces in place ;)
<lifeless> so perhaps yes
<vila> lifeless, spiv: seeing 97% is indeed soooo good :)
<vila> makes me hungry, will grab some food :)
<fullermd> Me, I usually get hungry by about 75%...
<vila> fullermd: Oh ! You're there
<fullermd> No I'm not, I'm here.  You're there.
<vila> fullermd: So I had more and more crash with the 8.0rc1
<vila> fullermd: and it seems that changing the IDE controller did the trick...
<fullermd> Same crash?
<vila> no, different ones, but I updated from beta4 to rc1
<vila> and from there I had a different failure mode: attempt to dump the core, encounter file system full 8-(
<vila> another new detail was that it rebooted on failure (Well I mostly suppose here because I was always late in the game...)
<SamB_XP_> my Debian box keeps doing that ... I'm thinking something is overheating, maybe ...
<SamB_XP_> ... there is definately a fan down :-(
<vila> SamB_XP_: hmm, I don't have virtual fans in my MVs :D
<SamB_XP_> vila: hehe
<SamB_XP_> didn't realize you were talking about VMs -- didn't know you could swap out IDE controllers in those ;-)
<vila> fullermd: So I commented dumpdev="auto" but I were wondering how to specify something else to avoid dumping in '/' !
<fullermd> Obviously, that's the problem.  If it had virtual fans, it wouldn't overheat   :p
<SamB_XP_> fullermd: lol
<vila> I didn't know I could, I just followed my intuition and tried :D
<fullermd> vila: Well, it dumps to the swap.  savecore(8) copies it into the filesystem on next boot.  $dumpdir sets where it's saved to (/var/crash by default; changing it or setting a symlink would move it)
<vila> fullermd: nope, /var/crash exists and doesn't point to /
<vila> and / and /var are on different volumes
<SamB_XP_> vila: but did you check whether there was a /var/crash hidden behind the mount point ?
<fullermd> vila: As for the rebooting, the kernel debugger is part of the debugging that tends to be taken out around the first RC.
<vila> df / /var
<vila> Filesystem            1K-blocks    Used   Avail Capacity  Mounted on
<vila> /dev/ad0s1a              507630  313616  153404    67%    /
<vila> /dev/ad0s1d             3027598 1338820 1446572    48%    /var
<fullermd> Shouldn't matter, the filesystems are mounted by that time.
<SamB_XP_> okay
<vila> I may be wrong, but the fact is I found a ps.core on / and a / full at 109% (haha, always love that one)
<vila> and the recipe to come back to a half-stable setup was to boot in single user mode, issue fsck -y and reboot
<vila> issuing fsck -y in "normal" mode didn't seem enough
<SamB_XP_> why -y ?
<vila> That may sound a bit hammer debugging (it was), but it worked and I had to do it once or twice a day only
<SamB_XP_> didn't have time to sit there and say yes ?
<fullermd> Wye -i?
<SamB_XP_> oh, it happened over and over again?
<vila> SamB_XP_: yes
 * SamB_XP_ missed that
<vila> fullermd: what -i ?
<SamB_XP_> that's for interactive, probably?
<fullermd> E -i E -i O.
<SamB_XP_> okay, now he's being silly ...
<SamB_XP_> fullermd: had some DUCKS
<vila> fullermd: so back to my initial question, why core dumps on '/', how to avoid that (while still having core dumps, just in case)
<SamB_XP_> vila: I don't suppose you could reapportion space such that there is enough space on / ?
<fullermd> Well, it doesn't...   on boot it copes into $dumpdir.
<fullermd> And copies, even.
<SamB_XP_> fullermd: where does it do that?
<vila> SamB_XP_: It's a default freebsd install, so no, I don't want to spend time on that
<fullermd> "Where" in what sense?
<SamB_XP_> I mean, what script or binary does it ?
<fullermd> savecore(8), as called from /etc/rc.d/savecore
<SamB_XP_> so, maybe vila should read that script and manpage?
<vila> fullermd: dumpdir is not set in *my* rc.conf, how can I check ?
<vila> SamB_XP_: sshhhh, I have a translator handy
<fullermd> The default is /var/crash (as seen in /etc/defaults/rc.conf)
<fullermd> Yes, I translate sh to IRC   :p
<SamB_XP_> well, I just mean I find it helpful to look at init scripts when they go wrong ...
<vila> dumpdir="/var/crash" in /etc/default/rc.conf :-/
<fullermd> There's a minfree file in that dir that savecore(8) checks and won't write if it would leave less than that much free.  But the default is like 2 megs, and surely you're not THAT close to the line.
<SamB_XP_> vila: how about adding a line to the /etc/rc.d/savecore to display the mounts at that time to make sure fullermd was right about the filesystems being mounted?
<fullermd> Well, let's back up; is savecore(8) actually what's giving you the error?  It should be in your `dmesg -a` if not scrollback.
<vila> fullermd: ETOOOLD
<SamB_XP_> vila: say what ?
<fullermd> They are.  It requires syslogd, which requires filesystems.  And if it didn't, it would have been seen _ages_ ago, since nobody would be able to get at their crashdumps.
<SamB_XP_> oh, TOO OLD
<SamB_XP_> fullermd: okay, okay
<vila> the last boots were clean, the last crash was yesterday when I tried the controller change
<SamB_XP_> don't boot logs get saved somewhere ?
<fullermd> Yeah, it'll probably be in the messages file.
<vila> I have a dmesg.yesterday
<fullermd> Actually, retract that, it's probably not...
<SamB_XP_> fullermd: why's that ?
<vila> it mention 6 python pid core dumped at the end of the file and nothing more
<fullermd> Because the rc messages don't end up in syslog.
<SamB_XP_> fullermd: nowhere ?
<SamB_XP_> is that configurable?
<NET||abuse> hey guys.. i have a branch on my machine, i'm pushing it up to an empty repo up on my web server outside of webroot. I then want to update the local WT on the web server and use that as a source to copy some of the subdirs in the WT out to operating locations in the web server,
<vila> pids: 1548 1549 1807 1808 1965 1966, so may be in several waves
<fullermd> They end up in the /dev/console output that dmesg -a holds, but that's not dumped anywhere by default TTBOMK.
<NET||abuse> can i copy directly from the WT without bringing bzr cruft along for the ride?
<vila> NET||abuse: bzr export ?
<fullermd> vila: I always seem to have a .core left from something after a selftest run.
<NET||abuse> i would consider it bad practice to allow bzr or svn hidden dirs to be published to the live website along with the code files.
<vila> fullermd: ps.core ?
<SamB_XP_> yeah, was about to say I thought there was a "bzr export" ...
<NET||abuse> vila, so export to a location adjacent to the WT, then copy from the export to the operational locations on the webserver?
<fullermd> No, python.core.
<SamB_XP_> NET||abuse: well, working trees aren't usually updated on push anyway ;-)
<vila> NET||abuse: you can also have a look at lp:bzr-upload
<NET||abuse> vila, bzr-upload doesn't allow for sub tree nodes to be pushed up seperately.
<SamB_XP_> NET||abuse: you can't symlink to the desired parts of the exported tree?
<vila> fullermd: wow, yeah, found one, but it's named python.core and in the right dir (at least the expected one
<vila> NET||abuse: ha, right, well, bzr export neither I think
<NET||abuse> SamB_XP_, hmm, symlinking eh....
<SamB_XP_> hmm, is there a way to refer to the parent branch of the parent branch of the branch I'm on?
<NET||abuse> SamB_XP_, haha, why?
<SamB_XP_> also ... I couldn't find any docs for e.g. :push or :parent when I tried ...
<SamB_XP_> I expect this is mostly because google is not very helpful on such queries ...
<SamB_XP_> NET||abuse: oh, I just want to check an SVN branch for new revisions
<SamB_XP_> and it happens that I'm in a bzr branch of a pull of that SVN branch
<fullermd> No, it's more likely because they're not documented anywhere...
<SamB_XP_> fullermd: well, okay, that would also do it
<SamB_XP_> I was expecting something in urlspec
<SamB_XP_> which is awfully hard to find
<SamB_XP_> you have to remember "no hyphen, no plural, spec not specification"
<vila> SamB_XP_: Don't file a bug about that  ? I saw one yesterday just about that
<SamB_XP_> vila: about which?
<vila> :<aliases> documentation missing
<SamB_XP_> ah
<SamB_XP_> I filed a bug about a need for "apropos", as well
<SamB_XP_> does that spelling plugin help with the spelling of help topic names?
<vila> NET||abuse: So, to come back to your initial question, you can copy from a working tree and since there is only one /bzr directory at the top you should never copy bzr data
<NET||abuse> ahhh, that's it the, you can copy out of the WT as long as you don't copy the .bzr dir at the root.
<vila> NET||abuse: keep in mind though that if you always override you may miss deleted files
<NET||abuse> hmm, that's a point.
<NET||abuse> well.,,, i can wipe the webroot and application dirs just before re-copying the WT versions over.
<NET||abuse> just don't delete the mysql store or log dirs
<vila> NET||abuse: sure
<NET||abuse> and tmp uploads.....
<NET||abuse> damn, theres upload in webroot.
<NET||abuse> hmm, could i use a relative symlink to a dir below webroot for uploaded images, and have that symlink tracked in bzr?
<NET||abuse> thereby have the webroot deleted without following symlinks, and the symlink is just recopied in from WT relatively?
<NET||abuse> .. hehe
<NET||abuse> hacky hacky..
<NET||abuse> i still have a jquery tabs problem..
<NET||abuse> content isn't showing up on last tab for safari and chrome,,,
<NET||abuse> hmm, bzr uploads on push to remote are slow..... 56KB/s  taken a while for 24MB.
<bialix> bonjour vila
<vila> hi bialix
<bialix> webdav plugin is yours?
<vila> yes
<bialix> one man complain (to me) it does not wrk with bzr 2.0
 * SamB_XP_ wishes bzr knew enough to help out zsh with it's completion of arguments
<bialix> version check said that bzr >= 1.12 required
 * SamB_XP_ wishes zsh would bother to ask bzr about flags, too
<bialix> vila ^
<vila> there were a glitch (fixed on trunk) in the version checking
<bialix> ok, glad to know
<SamB_XP_> there are often glitches like that that show up when a major version gets bumped ;-)
<vila> timestamp: Tue 2009-08-11 18:29:12 +0200
<vila> message:
<vila>   Fix version checking for bzr-2.0.
<bialix> oh, ok
<vila> bialix: it may well be that the fix didn't find its way into packaged versions though...
<bialix> I suspect so
<vila> what os was your man using ?
<SamB_XP_> hmm ... bzr missing --theirs-only seems to give the wrong message when nothing was missing
<SamB_XP_> since it's the local branch that would be missing stuff
<SamB_XP_> but it says "Other branch is up to date."
<vila> SamB_XP_: sounds correct to me: *they* miss nothing from me
<bialix> vila: I'm not sure, some Linux distro, maybe Ubuntu or Gentoo. I need to ask
<vila> bialix: ok, that would explain it
<Peng_> What does "bzr missing --mine-only" say?
<SamB_XP_> vila: but they are missing tons from me!
<vila> you used --theirs-only that means you're not interested by what they miss from you
<vila> you want --mine-only
<Peng_> I like hg's terms, "incoming" and "outgoing". I can never keep bzr's straight.
<Peng_> I finally added aliases for them. I don't think I've ever used them, though, heh.
<fullermd> Really?  Odd.  --mine and --theirs always seemed obvious to me.
<Peng_> I might've learned hg's first.
<Peng_> fullermd: Hmm, you're right. I just get into something like: "Their revisions? Does that mean revisions missing from their end, or their extra revisions, or blwaewryhkfdfklhwa what was I thinking again?"
<Peng_> If you think about it from the right direction, it's obvious. If not, you can get lost.
<vila> On the other hand, you generally get lost because you got wrong directions.... no ?
 * vila really goes for food now
<Peng_> Hmm, all I have is Cheerios, almonds and a banana.
 * Peng_ eyes vila
<fullermd> I wouldn't, if I were you.  He's really hard to pour over Cheerios.
 * vila has no idea what Cheerios are, and is gone anyway
<Peng_> vila: Cheerios are a heart-healthy, toasted whole grain oat breakfast cereal, made by the American General Mills company.
<GaryvdM> Hi - I have a branch that checkouts fine on my computer, but when I try do a checkout on my clients computer, it allways has stuff left in limbo dirs.
<fullermd> Also one of the few cereals robust enough to be able to handle the mornings when you're out of milk and have to pour beer on it instead.
<Peng_> Peng_ eats cereal dry. And usually out of the box. Cough.
<fullermd> Well, out of the box works too.  But that takes more beer   ;)
<GaryvdM> Here is a pastebin of the .bzr.log:  http://pastebin.org/32557
<Peng_> fullermd: Oh, god, that'd be awful. Hahaha.
<Peng_> Although pouring milk into the box would be even worse.
<GaryvdM> bzr check says the branch is fine.
<Peng_> GaryvdM: Maybe it's a case-sensitivity issue?
<bialix> hi GaryvdM
<GaryvdM> Hi bialix
<GaryvdM> Peng_: ok let me look at qbroswe.
<bialix> GaryvdM: well, something wrong, but you should get error earlier
<bialix> abentley is ,aster of limbo
<bialix> abentley is master of limbo
<bialix> does working tree is created 100%?
<bialix> perhaps this is error masking in finally block somewhere?
<bialix> I suppose it's a bzr.exe 2.0?
<bialix> GaryvdM: ok, looking at the code I see the error raised in finally block. So most likely there is either case-sensitivy clash or inability to create symlinks
<bialix> GarycdM: will you have a chance to update PPA at weekend?
<bialix> GaryvdM: and I think you need to file a bug. It smells like regression
<GaryvdM> bialix: I'l try - I have quite a busy weekend though.
<bialix> if not -- I won't wait then and make announce
<GaryvdM> Huh - It worked now, and all I have done in the mean time was to clear .bzr.log...
<bialix> sounds like a racing condition
<vila> jam: ping
<jam> morning vi
<jam> vila:
<vila> hello emacs
<vila> jam:
<vila> :D
<jam> and how does this fine morning/afternoon find you, vila?
<vila> good, wondering about has_changes() again because I'm fixing bug #438158 just because I thought it was a good way to do that
<ubottu> Launchpad bug 438158 in bzr "dpush should behave identically to push" [High,Confirmed] https://launchpad.net/bugs/438158
<vila> and I found a case where we don't want to unconditionally check the pending merges but still use has_changes
<vila> we use it in merge.py two times, and I'm running the test suite to see, but my feeling is that we shouldn't mess with pending merges there
<jam> vila: so I would think we would want a helper that helps the 90% cases first, and let the 10% of cases that need customization do it on their own
<jam> or add a flag
<vila> jam: 4 failures
<jam> if it really matters
<jam> vila: could be the tests fault :)
<vila> hehe, no way there, see:http://paste.ubuntu.com/283860/
<vila> I can add a has_commitable_changes() instead and use that in commands, leaving has_changes with a mandatory tree parameter and leaving merge case alone
<vila> jam: will that suit you ?
<jam> vila: +        if from_tree is None: +            if len(self.get_parent_ids()) > 1: +                return True +            from_tree = self.basis_tree()
<jam> sorry about the formatting
<jam> line 59 of your proposal
<jam> you don't handle the case where from_tree is None *and* there are no parents
<vila> done twice ? Don't wory
<jam> this is the initial commit case
<vila> oh
<jam> and the basis_tree should be the null tree then
<jam> hm... maybe not
<jam> I might have read it wrong
<jam> vila: yeah, I misread the 'if /return' line
<jam> however, I'd like to see the failing tests
<jam> to understand what is going on with merge
<vila> ok, not pretty anyway it was for a quick and dirty tests
<vila> do you see the call sites in merge ? That's what matter  I think, it's not relevant there if there are pending merges or not, we could be running under --force anyway
<jam> vila: if we are running under --force, then we shouldn't be checking has_changes()
<jam> but let me look
<vila> oh, good point :)
<vila> err, no, not at all, different has_changes() usage
<jam> so, line 292 is clearly this_tree vs its basis_tree
<vila> but pending merges are irrelevant
<jam> though there is something funny about the compariosn
<jam> if this_tree has pending merges then it != basis
<jam> that code path looks like an optimization
<jam> where it wants to see if it can grab stuff directly from the working tree
<jam> rather than having to read the basis tree
<jam> (for example the 'file_revisions()' function)
<vila> yet, the 4 failures are from it
<jam> however, I can't find any code that actually *calls* file_revisions() in the bzrlib code base
<jam> $ grep -rnI "\<file_revisions\>" bzrlib/
<jam> gives some 'version-info'  tests, which has a similar attribute
<jam> so how is it causing the failures?
<jam> as I don't 1) see it tested, 2) see any other code calling it
<vila> http://paste.ubuntu.com/283876/
<jam> similarly, 'ensure_revision_trees' is only called by file_revisions() and I don't see it anywhere else
<vila> meh 5 errors but selftest reports 4 8-/
<jam> all of those are in 'check_basis'
<jam> I think you should check with Aaron what the point of "file_revisions" is, as it should be slated for deprecation
<jam> if nothing calls it, and it is completely untested
<jam> that is code worth cutting
<jam> abentley: ping
<vila> check_basis *is* called
<jam> vila: sure, but of the call sites
<jam> it is clear that one of them doesn't matter *at all*
<jam> and as for 'check_basis' *that* function certainly says to me that it *should have* been checking for pending merges
<jam> considering that IIRC that used to be the choke point for 'bzr merge --no-force'
<jam> vila: so "test_uncommit. test_uncommit_octopus_merge"
<jam> is doing:
<jam>         wt.merge_from_branch(tree2.branch)
<jam>         wt.merge_from_branch(tree3.branch)
<jam> and was allowed to do so
<jam> but shouldn't
<jam> the second should require 'force'
<jam> so that is 1 test bogus
<vila> wow
<vila> that change will never land....
<jam> test_commit_template_pending_merges
<vila> at least I can't make it part of fixing bug #438158
<jam> also does the same action
<ubottu> Launchpad bug 438158 in bzr "dpush should behave identically to push" [High,Confirmed] https://launchpad.net/bugs/438158
<jam> and shouldn't
<jam> same for test_multiple_pending
<jam> and test_multiple_pending_verbose
<jam> and test_uncommit_octopus_merge is repeated
<vila> wrong copy/paste
<jam> vila: IIRC wt.merge_from_branch is a test helper, and isn't used in 'production' code.
<jam> it needs a 'check_clean = False' to allow these octopus merges
<jam> but since it was supposedly check_clean=True
<jam> it shows that check_clean wasn't doing what we thought it did
<jam> which is... prevent from merging when there is pending uncommitted state
<abentley> jam: pong-ish
<jam> we just happened to rely on that behavior in a couple places in the test suite
<jam> abentley: We're trying to find the point of Merger.file_revisions()
<jam> it isn't called within bzrlib code anywhere
<jam> not even by the test suite
<jam> Are you using it externally somehow?
<jam> (bzrlib.merge.Merger.file_revisions())
<abentley> jam: I don't think I am using it externally.
<abentley> jam: looks like it was added to support weave merge.
<vila> abentley: and ensure_revision_trees() ?
<abentley> vila: Same commit, actually.
<vila> abentley: yeah, sorry, fired qblame just after typing my question:-/
<abentley> vila: Intitially, we couldn't do weave merge on working trees-- it was an all-repository operation.  So we needed to ensure that the working tree was equivalent to a revision tree and then use the revision tree.
<jam> vila: so as I said in the beginning... :) all of your test failures are because of broken tests
<vila> jam: right, I'm finishing my submission and will file a new bug for that
<vila> lol, good one...
<vila> ERROR: per_intertree.test_compare.TestIterChanges.test_file_becomes_unversionable_bug_438569(InterDirStateTree(C))
<vila> Exception: unknown kind fifo
<vila> huh?
<vila> ooooh I merged trunk and didn't run make....
<vila> hurrah, we found a new way to catch people that don't recompile their extensions :D
<vila> Too bad, it requires running the full test suite...
<vila> beuno: if you're responsible for adding the small reminder of project >> bugs >> bugs # on all lp pages, be blessed ;-)
<beuno> vila, I am  :)
<beuno> I have a version 2 in the pipeline that will make it even better
<vila> beuno: smack on both cheeks :-P
<beuno> :)
<vila> beuno: I use that multiple times every day
<vila> on the other hand, it seems we lost the bug history link...
<eLBati> # bzr push
<eLBati> Using saved push location: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-doc/doc/
<eLBati> bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<eLBati> # bzr merge
<eLBati> Merging from remembered parent location /home/ubuntu/workspace/openerp/doc/openobject-doc
<eLBati> Nothing to do.
<beuno> vila, I'm very glad to year that
<eLBati> now ? :P
<beuno> as for bug history, it will come back, interleaved with the comments, like the rest
<vila> beuno: ha, I thought so more or less but it wasn't clear
<vila> eLBati: so what ? you don't merge from the same branch you're trying to push to it seems
<jam> eLBati: you are using different locations
<jam> dang, vila beat me by 1 s
<jam> eLBati: try 'bzr merge :push'
<beuno> vila, file bugs for the specific items you want so they get prioritized
<vila> jam: and with a longer sentence yeahhhhhhhh
<eLBati> yesterday I pushed
<vila> beuno: ok, I don't remember the specifics, I had a vague strange feeling and fullermd spotted the missing link
<vila> eLBati: most probably you use a local mirror which was uptodate yesterday
<beuno> vila, don't think about a missing link, think about missing data you need. File a bug for it, and I will make that information available to you
<vila> beuno: sure, I understand, just giving you context of the original remarks
<vila> beuno: by the way, any news for UDS
<vila> ?
<beuno> vila, I forgot, will ask now, one sec
<beuno> vila, lets do it
<beuno> edit the wiki
<vila> beuno: done
<eLBati> jam, what's the meaning of merge :push?
<beuno> vila, awesome
<jam> eLBati: merge from the location that I push to
<vila> beuno: finally we may find some time to discuss a bit :D
<beuno> vila, I will have my copy of bzr-uplaod up to date
<vila> hehe
<vila> jam: just checking, it's ok to remove methods deprecated in 1.13 when targeting 2.1b1 right ?
<jam> vila: from the discussion with poolie, it is okay to remove anything that is marked deprecated in 2.0* in the 2.1* branch
<jam> put another way
<jam> you can remove anything from trunk which is marked deprecated in stable
<jam> double check HACKING.txt, but that was my understanding
<jam> as the 6-months stability is given by the stable branch
<vila> makes sense
<jam> I *think* that means we can land a 'deprecation' for 2.0.1, and just delete it from trunk
<jam> but that may be a bit too hasty
<jam> but certainly anything deprecated in 2.0.0 can go
<vila> indeed, but 1.13 if far older
<jam> and poolie has been doing that very thing :)
<vila> And are such modifications considered trivial ?
<vila> jam: ^
<jam> vila: I would probably put it up for review, at a minimum put it up for post-merge review
<jam> but I do that for most trivial things
<jam> I may submit it, but I still send it in so people know about it
<macflag> if contributor ("C") has a separate copy of a central repo (which doesn't use bazaar yet, it has no versioning yet) and modifies and uploads the repo (without using bazaar) *after* the central repo started to use bazaar (and then suffered some changes itself), does bazaar know how to distinguish between differences caused by C contribution and differences caused by C'S original repo "not being up-to-date anymore"?
<vila> post-merge review ? You mean you send the diff to the ML ?
<vila> DO yo umean I should stop merging my trivial test cleanups ?
<macflag> vila: are you talking to me?
<jam> macflag: talking to me
<jam> vila: If it is trivial enough to just merge, I would send a merge proposal, and then submit it to pqm without waiting
<vila> wow, I never noticed you did that...
<jam> I would use an mp, because that is the standard "review area"
<jam> vila: I did it with bundle buggy
<vila> haa
<jam> I haven't had a trivial merge since we switched over
<jam> vila: I generally marked it as (trivial) in the subject line, to make it clear I was landing this.
<jam> I realize I can do post-merge reviews via bazaar-commits, but I prefer to keep things where people expect them.
<vila> jam: Yeah, I *always* add (trivial) when I send them to pqm
<jam> macflag: I'm not sure that I fully understand your set up.
<jam> With "copy of a central repo with no versioning"
<jam> I think 'repo' is confusing here, because you don't have a repository if you have no version control
<jam> Let me see if I can rephrase what you asked
<jam> and you tell me if it is correct
<macflag> jam: there was no bazaar and no versioning before C made a copy
<jam> macflag: If contributor "C" has a copy of my source code, and uploads a copy of that source code to a central location
<jam> while at the same time, we started to version that central location using bazaar
<jam> and someone made some changes and pushed them
<jam> at that point, the central location considers the working copy "out of date" because of the push
<macflag> yes ...
<jam> but there are also local modifications to the source code
<jam> because of contributor C
<macflag> yes
<jam> macflag: at that point, doing "bzr update" in the central location will apply the changes that were pushed
<jam> and leave the local uncommitted changes around
<macflag> and contributor C didn't use bazaar
<jam> so that you can "bzr commit" them if you chose
<jam> it will also generate appropriate conflicts, etc
<jam> if the changes from C have issues with the changes that were pushed
<jam> (so I'm pretty sure the answer you want is 'yes')
<der|> hi, how do I remove all the conflicting files in a tree ?   clean-tree --detritus is not removing the OTHER and THIS files
<macflag> jam: will "bzr update" be based on the modification time of the files in the uploaded (unversioned) repository?
<jam> vila: you have 2 spaces in the NEWS entry
<jam> +  (Vincent Ladeuil,  #438158)
<jam> macflag: bzr update will bring the lastest changes that were pushed into the working tree
<jam> regardless the stat values of any file
<vila> I don't believe for one second that you found that with your eyes only 8-)
<jam> vila: I saw it looked wrong, and then highlighted it to make sure
<jam> I use fixed-width fonts in my email
<jam> so it is pretty obvious
<jam> I'm surprised it wasn't obvious for you in emacs
<vila> oh it is now that you mention it...
<macflag> jam: what i mean is some files in C's uploaded copy will be different because they are not up-to-date, while others will look different because they are C's contribution. will bazaar be smart enough not to show me diffs/conflicts due to the former reason?
<jam> macflag: we don't know the basis for C's changes
<jam> so if a given file said "foo" in C's original copy, and then  was updated in the central location to say "bar" by another users
<jam> when C uploads his copy, it will look like a normal change reverting back to "foo"
<jam> and 'bzr update' won't touch the file
<jam> you can use things like "bzr status -r -5" to see the difference between the working tree and an older version of the tree
<macflag> yeah, that makes sense
<jam> but you pretty much have to "guess" to figure out what the basis of C's changes were
<jam> if you can guess that well
<jam> then your resolution probably becomes easier
<macflag> jam: what if C also happens to possess and upload the basis (the original copy of the source). would this help?
<jam> macflag: so if C posses the basis, what I would do is
<jam> cd $central_reop
<jam> cd $central_repo
<jam> bzr up
<jam> bzr revert # get rid of all of C's changed
<jam> cd C; diff -u C-basis C-current > a.patch
<jam> cd $central_repo
<jam> bzr patch a.patch
<jam> macflag: in other words, throw away all of C's changes on the central repo, and get him to give you a diff instead
<jam> there are other possibilities
<jam> but that is going to be the easiest on "macflag" :)
<macflag> :)
<jam> if you know the approximate date of the modifications
<jam> you could do some checking of 'bzr log' to see what an expected basis is
<jam> and then do some of the 'create a diff' work yourself
<macflag> i think your first solution is the safest
<macflag> or does it have some disadvantages that you think i may not see? i'm new to versioning stuff.
<jam> macflag: #1 problem is that it depends on user C to do the right thing
<jam> and C is *not* using version control
<jam> is it likely/unlikely that the basis for C was versioned?
<macflag> jam: isn't keeping the basis saved and uploading it together with the current version "the right thing"?
<jam> macflag: so "keeping the basis saved" is something you have to trust that user C did
<jam> many people wouldn't
<jam> this user might have
<macflag> unlikely, but the basis is certainly one of the previous versions in the bazaar repo
<macflag> jam: but if they did it, it would be absolutely enough, right?
<jam> macflag: if the user is ok using bazaar, I would tell them to do:
<jam> bzr branch -r BASIS_REV $central_repo local
<jam> cd local
<jam> cp -ar ../C-current .
<jam> bzr st
<jam> bzr commit -m "Turn my changes in to a bzr revision"
<jam> and then give that to you
<jam> possibly via
<jam> bzr send -o ../my-changes.patch $central-repo
<jam> macflag: if you take the difference from a known basis to the current version, that is "enough information".
<macflag> jam: what if they simply upload the repo?
<jam> macflag: that is fine, too
<macflag> so it seems bazaar is pretty powerful
<jam> macflag: we try :)
<macflag> :)
<macflag> is "bzr branch" necessary when using totally independent/isolated repositories?
<jam> macflag: versus what other command would you use?
<jam> anyway, i'll be back in 30 min or so, time to get food
<macflag> jam: well, versus simply copying the repo :)
<verterok> howdy
<james_w> hi verterok
<verterok> james_w: hi
<verterok> any mac user willing to test the shiny (and expmperimental) bzr.app standalone bundle?
<verterok> *experimental too
<arkanes> verterok: sure
<arkanes> verterok: do I need to do blow away my working bzr first?
<macflag> i want to create independent branches which are totally "amnesic" (except for what it's basis-version was, of course!). does what i'm saying make sense (as i said, i'm new to this stuff)? and is it possible?
<macflag> it's=its*
<macflag> and its=their* :)
<jam> macflag: generally no. Though you can do stuff like "bzr log -r ancestor:trunk..-1"
<macflag> jam: generally no, "it doesn't make sense" or "it isn't possible"? :)
<jam> macflag: a branch is a pointer to a complete history of revisions, it is not a 'set' of revisions outside of that
<jam> so while you can do stuff to compare two branches and see what is different
<jam> all branches will point to their full history
<jam> note that if you are using merging, the 'common basis' changes over time
<jam> and you can have N branches and ask each one what is common versus the other
<idnar> is there an easy way to figure out (programmatically) if a pull command pulled any revisions or not?
<idnar> I suppose I could add some kind of hook, but that seems like more effort than it's worth
<macflag> jam: then i guess i want something like a "snapshot" that only knows what version it is based on, right?
<jam> macflag: well, you could just never commit....
<jam> not very useful
<jam> idnar: 'pull -v' ?
<Meths> idnar: Can't you parse the output for "No revisions to pull"?
<jam> check the return code? (That may not give info, I'm not clear on pull's retcodes)
<Meths> you have to watch bzr's output though as some info goes to stderr rather than stdout
<jam> macflag: what is the *advantage* of only knowing the original version?
<jam> you might like something like "bzr branch --stacked" but it really depends on what you are trying to get out of the system
<macflag> jam: here's my use case: once in a while i want to email a "minimal" version of my repo to a friend that helps me with some correction and patching, and by "minimal" i mean i want my friend to know as little as possible (nothing, if possible) about the previous versions of my code (but the repo includes the full current version). then my friend will email it back to me and that will be "readopted" by my bzr.
<Meths> Just use tar then
<jam> macflag: bzr co --lightweight repo working_tree; tar cvjf working_tree.tar.bz2 working_tree
<macflag> Meths: not including the versioning info?
<jam> macflag: that will give you a working tree with pointers about what version it was at
<macflag> jam: oh, so --lightweight does just that?
<Meths> macflag: yeah, just leave out .bzr - looks like jam has a complete solution though
<macflag> jam: and that's totally usable in my friend's bazaar and then totally remergeable in mine?
<jam> macflag: the bit of confusion is that it isn't really a branch or a repository (by our terminology)
<jam> macflag: well, he can't commit in it, because it will point to a branch he doesn't have
<jam> but if you just want him to do his work...
<jam> including 'bzr commit'
<jam> then we need to think a bit more.
<macflag> jam: but then how do i receive his changes?
<jam> macflag: he tarballs it up and sends it back to you
<jam> that is the 0-history model
<jam> we are working on an idea called 'shallow branches' which would have some history but not much. (say 1 revision worth)
<jam> but that hasn't been implemented yet
<macflag> jam: i see, but will he be able to do his own versioning, totally mergeable into mine?
<jam> macflag: generally he won't do versioning
<jam> but when he sends it back to you, you can "bzr commit -m "his stuff" and merge that
<macflag> jam: i see. that sounds good enough.
<macflag> jam: um, actually it sounds perfect. or am i missing something?
<jam> macflag: just if he wants to be able to "Bzr commit"
<jam> otherwise a lightweight checkout is just what you want
<jam> since you said "I want him to have 0 history" that seems to fit
<macflag> jam: why would he want to be able to commit?
<macflag> jam: yes, this is what i want
<jam> macflag: to do his "own versioning"
<macflag> jam: oh, well, i meant apart from that :)
<jam> macflag: (I don't develop without a VCS anymore, myself)
<jam> sort of like using an editor without an undo button
<macflag> i know what you mean :)
<macflag> does bzr use meld by default?
<jam> I don't believe so
<LarstiQ> pfft, undo!
<jam> but I think we have built-in support for it
<jam> bzr diff --using meld
<jam> I think works
<jam> etc
<LarstiQ> including undo in Blender was the biggest mistake in it's development! *cough*
<macflag> what does it use by default instead?
<jam> macflag: to do what?
<macflag> LarstiQ: are there any people that hate undo?
<macflag> jam: dif
<macflag> jam: diff
<jam> macflag: 'bzr diff' just does an internal diff algorithm that compares lines and shows you the changes as a "unified diff"
<jam> there is also "bzr qdiff" which makes that pretty for display
<jam> in a GUI
<LarstiQ> macflag: hmm, not that strong I think. But the argument is that artists who know how to work without undo are better in some respects.
<macflag> i guess meld is preferable
<LarstiQ> macflag: thinking more of what their desired outcome is
<LarstiQ> macflag: knowing the tool better
<macflag> LarstiQ: maybe
<LarstiQ> macflag: talking specifically about Blender here
<LarstiQ> I myself am glad the undo is there :)
<macflag> i don't see how any of these reasons can be blender-specific.
<LarstiQ> they're not, but for a very long time Blender did have an undo feature
<LarstiQ> did _not_
<LarstiQ> and some people complained about that, and others didn't need it
<LarstiQ> after spending enough time with blender that they could work without
<jam> LarstiQ: have you ever read Penny Arcade (comic strip)?
<jam> he occasionally posts videos of him doing the drawings
<jam> generally with a Wacom Tablet
<macflag> undo is easy *not* to use, so now blender is ok for everybody
<jam> pretty amazing (for me) to watch
<LarstiQ> jam: not followed, but on occassion
<jam> and he uses undo fairly often
<jam> Painters generally use pencil and then ink/paint over that
<LarstiQ> macflag: that's not strictly true about crutches
<LarstiQ> jam: right
<LarstiQ> jam: yeah, it certainly is a liberating feature over analog
<jam> I would guess that a Wacom tablet is almost enough to ease the rest of the transition
<jam> since you get some pressure sensitivity, etc.
<jam> certainly keyboard + mouse is awful for painting :)
<jam> and a lot of online cartoonists still work in pencil, then scan and ink using photoshop
<LarstiQ> tablet is way nicer, but even without people can be amazing
<LarstiQ> jam: right
<macflag> LarstiQ: what are "crutches"?
<jam> macflag: http://en.wikipedia.org/wiki/Crutch
<macflag> jam: in blender :)
<jam> macflag: undo is a crutch
<jam> you don't *need* it
<macflag> oh :)
<jam> macflag: arguably a VCS is a crutch
<jam> you can do everything it does without it
<jam> you just have to be very careful in what you do
<LarstiQ> sure
<LarstiQ> wether something is a crutch depends on how heavily you lean on it, or could do the same without
<jam> I personally view it as more of a jet-pack :)
<LarstiQ> hehe :)
 * LarstiQ is with jam on that one
<macflag> then i was misunderstood, by "undo is easy *not* to use, so the new blender is ok for everybody" i meant "nobody can be forced to use it, so the anti-undoers have no reason to be discontent with its addition"
<flutherben> Ha all. Anyone know how can I set up a smart server that restricts access? I'm trying to use bzr --serve
<LarstiQ> macflag: I don't agree with that, but nevermind. I think having undo is a good idea, and some of the best blender artists I know use it.
<macflag> LarstiQ: i think having undo is a very good idea, too. i was just saying that nobody can be upset with its presence: if they don't want to use it, they are free to ignore it.
<jam> flutherben: 'bzr serve' has no access control built in. We recommend using either 'bzr+ssh' or 'bzr+http' and doing the access control in the ssh/http layers
<jam> macflag: artists are often not as rational as programmers
<jam> at least the argument LarstiQ brought up earlier was that undo allows people to do 'good enough' work, without learning enough to do *better* work
<flutherben> jam: how does performance compare with bzr+http? (I'm trying to setup a server so my other hosts can download during a deploy and not need a password)
<macflag> jam: yeah. i guess keeping themselves in good shape and spontaneous (and probably improvisational) is an important consideration/value for them.
<jam> flutherben: so you want auth with no password?
<jam> bzr:// should be approximately the same as bzr+http:// == ~ bzr+ssh://
<jam> the main issues with bzr+ssh is the ssh handshake overhead
<jam> and possibly the encryption overhead
<flutherben> jam: yeah... :) previously we were using apache2 to check domains as access
<jam> depending on your cpu overhead, etc.
<macflag> jam: or rather "forcing themselves to stick to an "irreversibilistic" approach ..."
<jam> in the end
<jam> it should be a small handful of round-trips and a lot of bulk data transfer
<jam> which is pretty independent between bzr:// and bzr+http://
<flutherben> yeah, we were just using http before with apache, and I want to try a smart server
<flutherben> but I'm having trouble finding a lot of explaination
<jam> macflag: there is a saying I've heard in theater. Movies make you money, TV makes you popular, and Theater makes you good... :)
<jam> flutherben: bzr+http:// should generally perform significantly better than http://
<flutherben> I suppose the other method would be to use bzr+ssh, and add all my servers to the auth_keys, but that is less appealing
<jam> primarily because of the "number of requests" aspect
<macflag> LarstiQ: can you agree to what i said?
<flutherben> jam: great, thanks. Let me see if I can find out more about how to set it up
<LarstiQ> macflag: no :) I get your stance that individuals can decide not to use it for themselves and that others can make a choice to use it without directly impacting the non-using ones.
<LarstiQ> macflag: but if you care about how the rest of your community develops, it's not just about wether you yourself use it or not
<jam> flutherben: http://doc.bazaar-vcs.org/latest/en/user-guide/http_smart_server.html
<LarstiQ> macflag: it's a bit more of a hardliner than an all-inclusive lookout
<jam> might be a little out of date
<macflag> LarstiQ: that's why i was implying that adding undo would benefit both categories, thus being the more rational choice
<flutherben> jam: thanks... looks like I might try mod_wsgi
<LarstiQ> macflag: undo would be detriment to ensuring everyone is trained to not use it
<LarstiQ> macflag: but this discussion is all very abstract and moot
<macflag> LarstiQ: that's a little too picky, i think
<jam> flutherben: that would be the general recommendation
<macflag> LarstiQ: do you use bazaar with blender?
<LarstiQ> macflag: mu?
<flutherben> jam: oops.. the mod_wsgi link in broken
<LarstiQ> macflag: I don't use blender
<LarstiQ> macflag: way way back I did some work on the blender code, back then the project was in cvs
<LarstiQ> macflag: more recent, I have done sysadmin work for the Blender foundation
<jam> flutherben: perhaps this is the right one? http://code.google.com/p/modwsgi/
<macflag> i see
<flutherben> jam: yeah, I'll try that
<LarstiQ> macflag: the introduction of 'undo' was from somewhere begin of the opensource period iirc
<jam> flutherben: I know there are some people using bzr+http, but it has been quite a while since I tried
<jam> if you get any tips/tricks I'm sure we'd be happy to get updates to the docs
<jam> (doc/en/user-guide/http_smart_server.txt)
<macflag> LarstiQ: what did you mean by "mu"?
<flutherben> jam: okay... I'll let you know
<LarstiQ> macflag: so is your question wether people use bazaar to version .blends, or use bazaar for the Blender project versioning?
<LarstiQ> macflag: "I can't anser your question because it is the wrong question"
<macflag> LarstiQ: to version .blends
<macflag> :)
<LarstiQ> macflag: http://en.wikipedia.org/wiki/Mu_(negative)
<LarstiQ> macflag: I know people who version .blends with bazaar, and I would too
<macflag> LarstiQ: i'm interested in versioning databases too, i know it's difficult
<LarstiQ> macflag: any specifics on that? Things like VisTrails?
<jam> flutherben: there is also this open bug #348308
<jam> which has a workaround in the bug posting
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<jam> but seems to need an actual fix in bzr
<macflag> LarstiQ: can i use vistrails with bazaar?
<LarstiQ> macflag: they don't interact meaningful right now
<LarstiQ> macflag: VisTrails keeps track of it's own versioning information, and stores that in an rdbms or in an xml file (zipped or not)
<flutherben> jam: hrm. I pretty sure we use a shared repo, which makes me think this won't work
<jam> flutherben: as mentioned, you can add some stuff in your wsgi file to make it work
<jam> though you shouldn't *have* to.
<jam> well, in python wsgi adapter you have to configure you can also poke at the jail configuration
<flutherben> hmmm, okay, might give that a try...
<Vittor> juego de boxeo online http://www.kobox.org/kobox-fande-Nourine.html
 * mneptok blinks
<mereandor> how do I get the diff for the last commit that was made? bzr help revisionspec does not show how to get the current version...
<mereandor> nevermind I worked it out
<mereandor> -2 not -1
<awmcclain> Hrm. I merged in a branch and forgot to check in the merge -- I made some changes to one of the files and then reverted -- which deleted the file. Is there a way to restore the orignal file from the merge without checking in first?
<awmcclain> sorry, i only reverted the one file.
#bzr 2009-10-03
<CameronP> Hi guys - is vila around?
<lifeless> CameronP: not for 5 or 6 hours
<CameronP> lifeless: Thanks..
<CameronP> Does anyone know how to "uninstall" bzr  - I think my installing from source has broken on x64 centos
<CameronP> python setup.py xxxx? etc?
<CameronP> I just deleted the bzrlib dir from lib64 and this seemed to do the trick
<CameronP> however the install doesnt seem to work for x64 on centos
<lifeless> CameronP: can you file a bug please?
<lifeless> CameronP: uninstalling - setup.py doesn't offer uninstall ><>
<lifeless> CameronP: you might like to use the rpm spec file and build a package rather than installing directly.
<CameronP> yeah ill just run from source
<CameronP> it should be ok
<lifeless> setup.py build_ext -i
<lifeless> will build the extensions for you for that
<lifeless> we'd like a bug though, if install isn't working, so we can document/fix it
<CameronP> yeah sure will file it
<ub3rst4r> hi, i am trying to merge the 1.4 source code with the 1.3.4 source code but when i go to merge it says "nothing to do" and then when i try to push it says "ERROR: These branches have diverged.  Try using "merge" and then "push"." what do i do?
<james_w> ub3rst4r: hi, are you just running "bzr merge"?
<ub3rst4r> ya
<james_w> it is probably merging from a different branch than you are pushing to
<james_w> "bzr merge :push" will merge from the branch that it tries to push to
<ub3rst4r> 31 conflicts encountered. what does that mean?
<james_w> ub3rst4r: http://doc.bazaar-vcs.org/current/en/user-guide/index.html#merging-changes
<ub3rst4r> wtf?
<ub3rst4r> now theres two different branches
<CameronP> do any of you guys use the upload plugin?
<CameronP> does anyone know how to change the text editor in bazaar explorer?
<ub3rst4r> wtf!
<ub3rst4r> why cant i get this branch to merge
<CameronP> having probs eh
<CameronP> me 3
<ub3rst4r> i think i got it now
<CameronP> Using bazaar explorer for version 2.0 on windows vista seems to break - cant ssl in at at all :(
<CameronP> all working fine, jsut user error
<meoblast001> i was just looking through some of my commits
<meoblast001> is it typical for someone to have their bazaar "email" field set to their real emal?
<meoblast001> email*
<Peng_> meoblast001: What else would you use?
<meoblast001> idk
<meoblast001> i just noticed my commits said "meoblast@aol.com" and thought "was it always that way?"
<meoblast001> figured out it was
<meoblast001> so i thought i'd inquire if that was the norm
<CameronP> Just started with bazaar explorer, and wondering if someone can explain something to me - Up until now I've been using the centralised  model
<CameronP> with checkouts and commits
<CameronP> to the server repository
<CameronP> in bazaar explorer, when i try and do an update, first
<CameronP> it seems to only do a local update, and doesnt pull it down from the server
<CameronP> does that make sense?
<Peng_> CameronP: If you're not using a checkout, that's what "update" does.
<Peng_> (Well, technically update is doing the same thing it always does: Updating the working tree to the tip of the branch; in this case, the branch is local, though.)
<CameronP> ok so Im getting stuck where another developer commits a change
<CameronP> it tells me i have to update first before commiting changes
<CameronP> but the  update, just says nothing to do (as its just doing it locally i think)
<CameronP> if i go to command line and do a bzr update from my working directory, then it works ok and connects to the server and pulls their changes and merges them and then i commit
<CameronP> i Just dont understand why that doesnt work through the gui
<fullermd> It might be that Explorer isn't doing quite what it should in that case.
<fullermd> igc might know better
<CameronP> thanks... guess I'll just wait and see what the go is -has been confusing me  all day ;)
<fullermd> igc: ^^  Explorer not properly update'ing a checkout?
<Keybuk> I'm having an enormous amount of errors with bzr 2.0
<Keybuk> branches that pass "reconcile" with previous version are now raising Exceptions when using 2.0
<Peng_> Keybuk: Pasteebin your exceptions.
<Keybuk> just filed bug 441105
<ubottu> Launchpad bug 441105 in bzr "bzr: ERROR: exceptions.KeyError: ('command.h-20061011134501-p0varet42063vbuy-1', 'scott@netsplit.com-20070106211437-hfvbhva2w9qextyd')" [Undecided,New] https://launchpad.net/bugs/441105
<Peng_> Oh. That works too.
<Keybuk> also bug 441120
<ubottu> Launchpad bug 441120 in bzr "bzr: ERROR: exceptions.KeyError: ('test_job.c-20060802025841-69d13b49cc35d5ec', 'scott@netsplit.com-20090709110153-7dcfrdmjwojak3ud')" [Undecided,New] https://launchpad.net/bugs/441120
<Keybuk> and bug 441125
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [Undecided,New] https://launchpad.net/bugs/441125
<dirving> I'm trying to move a project from bzr into a subversion repository, keeping the revision history.  I've tried a few things with bzr-svn but I'm not having any luck -- does anyone have any pointers?
<ronny> jelmer: say, did git/dulwich have something to push via http? (or should abuse something like a light pack + http push requests for the time being)
<visik7> is it safe to upgrade to 2.0.0 ?
<visik7> plugins will be broken  ?
<SamB_XP> visik7: some might
<SamB_XP> visik7: but most of them have been updated
<visik7> bzr webdav doesn't work
<SamB_XP> does it simply fail to load?
<visik7> yes with this error: not installing http[s]+webdav:// support (only supported for bzr 1.12 and above)
<SamB_XP> that would be an obvious bug in the plugin
<visik7> probably due to this if :    if major < 1 or minor < 12:
<SamB_XP> are you running from a bzr checkout, or an OS package?
<SamB_XP> (and is this bug reported?)
<visik7> SamB_XP: checkout and no it doesn't seem to be reported
<SamB_XP> well, I would (a) fix that line (b) push it to a launchpad branch and (c) request a merge
<SamB_XP> maybe also (d) report the bug
<SamB_XP> ;-)
<visik7> fixed
<visik7> now how can I create a branch on lp ?
<visik7> and request a merge ?
<SamB_XP> visik7: do you have an account on lp yet?
<visik7> yes
<SamB_XP> did you upload your SSH key?
<visik7> yes
<SamB_XP> did you do a "bzr lp-login"?
<visik7> no it says I haven't configured an user
<SamB_XP> bzr lp-login my-lp-username
<visik7> ok done
<SamB_XP> visik7: okay, I assume you committed the fix to the plugin and are in the working directory?
<visik7> yes
<SamB_XP> well, bzr push lp:~my-lp-username/bzr-webdav/version-checking-fix
<SamB_XP> assuming bzr-webdav is the right name for the launchpad project for the plugin
<visik7> yes is the right name of the plugin of the original developer
<visik7> but I renamed it
<visik7> (the directory)
<SamB_XP> yes, of course
<visik7> it says that bzr: ERROR: Invalid url supplied to transport: "lp:~visik7/bzr-webdav/version-checking-fix": No such project: bzr-webdav
<SamB_XP> hmm
<visik7> do I need to create it from my panel ?
<SamB_XP> oh, apparantly the project is called bzr.webdav for some unknown reason ???
<SamB_XP> so try that again with a "bzr.webdav" instead of "bzr-webdav"
<SamB_XP> man, this new launchpad theme is way too white
<visik7> :)
<SamB_XP> it needs some panels of some kind ...
<visik7> it's committing
<SamB_XP> hopefully it won't take too long
<SamB_XP> oh, wait, ... did you try just doing a "pull"?
<visik7> yes
<visik7> there was no updates
<SamB_XP> where did you have it checked out from ?
<visik7> Created new brench
<visik7> I check if there was any update a few minutes ago
<visik7> ok I pushed and everything is ok seams
<visik7> how to request for a merge ?
<visik7> found
<visik7> thanks for your support
<SamB_XP> the thing is, there was an attempt to fix the check for bzr 2.0 back in august ...
<SamB_XP> and yeah, it looks like that fix should have worked
<SamB_XP> so, I would try "bzr pull --overwrite lp:bzr.webdav"
<visik7> mmm
<SamB_XP> and if that also works fine, I would go to your merge request and apologize for wasting time ;-)
<SamB_XP> though of course at least now you learned what to do if you ever find a bug you could easily fix in another plugin
<visik7> yes infact
<visik7> anyway how can I discard the merge request ?
<SamB_XP> I'm not sure if you can ;-)
<SamB_XP> someone else may tell you soon
<visik7> ok np
<visik7> going out now thank you again now I'll use launchpad instead of github to do stuff like this
<jelmer> SamB_XP: no, there's no push over http stuff
<visik7> I have removed the branch
<SamB_XP> jelmer: say what?
<SamB_XP> I didn't mention push-over-http did I?
#bzr 2009-10-04
<jam> fullermd: known bug in 'qupdate' versus 'qgetupdates'
<jam> but it seems explorer switched because of other bugs in qgetupdates
<fullermd> Hmm?
<fullermd> Oh.
<jam> yeah, about 12 hrs ago :)
<fullermd> I left my long-term memory in my other pants   :p
<SamB_XP> see, this is why it takes me so long to change pants
<peso> I have a stupid question: How do I install a plugin? I'm trying to use the hgbzr plugin by copying it to %APPDATA%\bazaar\2.0\plugins\bzrhg but bzr plugins does not show it.
<bob2> what's in that dir (pastebin it)?
<peso> the contents of the tar.gz I downloaded from http://launchpad.net/bzr-hg/trunk/0.1/+download/bzr-hg-0.1.tar.gz
<peso> How do I pastebin?
<peso> I tried to reextract and copy the tar.gz again and this time it worked. Thanks. I think I had some trouble using xcopy.
<bob2> ah, good
<mdke> can I mark more than one bug as fixed using bzr commit --fixes? if so, what is the syntax? I can't find it in "bzr help bugs"
<Peng_> I think "bzr commit --fixes xxx --fixes yyy" works.
<mdke> Peng_: awesome, will give it a try
<Peng_> Don't thank me until you've tried it. ;P
 * mdke waits
<johnf> Can someone point me in the right direction of some docs of how I would pragmatically run "bzr add"
<Peng_> "Pragmatically"?
<johnf> damn spell checker programatically :)
<johnf> using bzrlib
<mdke> thanks Peng_ :)
<Peng_> johnf: I s'pose you could look at the source code for cmd_add.
<johnf> Peng_: doing that at the moment :)
<johnf> Ahh http://doc.bazaar-vcs.org/bzr.dev/developers/integration.html has all the magic I need
<Peng_> Oh, good.
<dsuch> jam: https://launchpad.net/~jameinel/+junk/bzr-file-locking - I understand it's not yet ready for using as a plugin?
<madin60> Hi everybody
<madin60> someone speaks french here!
<dsuch> jam: Not sure how to understand empty 'cmd_file_lock' or 'cmd_initialize_file_locks'.
<dsuch> madin60: Sorry, I don't speak French.
<madin60> I've some trouble with the pull command
<madin60> I can't pull on my sftp branch
<madin60> the access port isn't the traditionnal 22
<madin60> How can I succed to pull with an other port on sftp server
<bob2> ~/.ssh/config is the easiest way
<madin60> bob2 my problem is due to the firewall configuration!
<madin60> so I don't think that I can resolve it with the ssh config
<bob2> if you want to use an alternate port, and bzr is using openssh, you can do this by editing ~/.ssh/config
<bob2> if you need to use a bastion host, you can do that in ~/.ssh/config, too
<Peng_> Does putting the port in the sftp:// URL work too?
<Peng_> IIRC, it does.
<madin60> I try it
<madin60> thanks
<johnf> is there a plugin that solves the following problem?
<johnf> I'm working on a project and fixing multiple upstream bugs
<johnf> the patches for each bug are fairly independent of each other
<johnf> I want to have them all in a single tree
<johnf> but I want to be able to create branches for each patch that I can store in launchpad so I can create a different merge request for each
<johnf> I though bzr-loom export-looms would do the trick but each exported loom is cascaded
<jml> johnf, there's no plugin that I know of like that.
<SQlvpapir> does the latest bzr-gtk work with >2.0?
<meoblast001> hi, i accidently control+c'd in the middle of a push
<meoblast001> how do i unlock the repository?
<Meths> bzr break-lock ?
<meoblast001> the remote lock
<meoblast001> ok, got it
<meoblast001> thanks
#bzr 2010-10-04
<mwhudson> oh
<mwhudson> i guess my branch copying over vfs can screw this up
<mwhudson> jelmer: does bzr info -v on a locked branch tell you about the lock?
<jelmer> mwhudson: I'm not sure, I don't think t does
<jelmer> *it
<peitschie> hi... i was wondering if anyone might have the time to help me attempt to adapt https://code.launchpad.net/~spiv/bzr/chk-canonicalizer-613698/+merge/32294 to be targetable to specific revision set?  I have a repo that has been reconciled for all revisions bar 2 new ones which were accidentally checked in using a broken revision history... which is now sinking the shared repo again
<mkanat> peitschie: Do you think it would be a good idea to write a pre_change_branch_tip hook that rejects commits if they're going to do that to your repo?
<peitschie> mkanat: it'd likely have been useful if I'd anticipated it :)
<mkanat> peitschie: Yeah. I just mean since you indicated in your email that this sort of thing happens all the time.
<peitschie> mkanat: at this point though, reconciling and repairing the broken revs are my top priority
<mkanat> peitschie: Sure, I understand that. (I don't know much of anything about that area, though, so I can't help there.)
<peitschie> mkanat: not all the time :)... just since the update
<mkanat> peitschie: Ah, okay. :-)
<vila> hi all !
<mgz> morning vila!
<vila> mgz: hey !
<mgz> first, coffee, then I need to dump some of this bzr state I've been carrying in my head
<mgz> vila: what's the right way to set an env var for the duration of a test only? I'm blanking...
<vila> set_or_unset something, let me check
<vila> the tests themselves are isolated so you don't have to restore it
<vila> if you use the right base class that is
<mgz> I'm looking at that code, and it seems to isolate then reset certain env vars, but only those as far as I can tell
<vila> oh, hum, _captureVar does it. I'm not sure that's the right API to use or we should make it public maybe
<mgz> looks like TestCase._captureVar would do what I want, bar the underscore
<mgz> ...vilawins.
<vila> :)
<vila> defined in TestCase anyway, so you shouldn't be able to leak
<vila> hmm, yeah, don't use _captureVar
<mgz> calling it more than once for the same value would be bad
<vila> or you risk retoring the bad value
<vila> restoring
<mgz> in fact, I think it might already be broken on windows
<vila> osutils.set_or_unset_env is the one to use, may be not the best name though
<mgz> as it's case insensitive and the override dict has values differing only by case
<vila> weeeell, don't do that then :)
<vila> I don't know of a case where differently cased vars are set to different values on *nix, but _cleanEnvironment already list FTP_PROXY and ftp_proxy and the like
<mgz> right, that's a problem on windows
<mgz> because the first one resets the value
<vila> only for tests writers, but it may be wise to update the docstring then
<mgz> then the second one records that reset value as the right thing
<vila> yes, that's the possible failure I was referring to
<mgz> am I reasoning this thing right?
<mgz> anyway, doesn't matter much, you'd need to be caring your proxy still worked after running selftest for it to matter
<vila> but only if you use _captureVar, not if you use set_or_unset
<vila> not if you set an unknown env var.... you need to update _cleanEnv to have it tracked :)
<mgz> I'll think of some better way of spelling this, need to share the code with doctests anyway
<mgz> but... back to what I was doing
<vila> mgz: Any thought on http://wiki.hudson-ci.org/display/HUDSON/testng-plugin (I know I shouldn't divert you :)
<mgz> I know nothing about testng, so I'd need to find out more to have useful thoughts
<vila> mgz: no hurry, I'll keep it on my radar, reporting skips sounds like a nice addition
<vila> well, not applicable even more
<vila> the idea was more about, if we can do that for skipped and not applicable tests, may be we can also report leaks this way
<vila> maxb: regarding bug #636930 what should be our next move ? None ?
<ubot5> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 7, heat: 64)" [High,Triaged] https://launchpad.net/bugs/636930
<mgz> I think we have things to be fixing to get better results anyway
<mgz> see bug I'll be filing later when I get down my todo list a little further for instance
<vila> mgz: I'll look
<maxb> vila: Someone actually needs to produce test run logs of 2.2.1 on maverick, with each failure justified as occurring with 2.2.0-1 too
<vila> maxb: I see
<mgz> ...vila, does your new news script check the items are in the right slot? we have a bunch of mps up right now that'd merge but put their news under 2.3b1
<vila> mgz: fixed-in ? No, it doesn't do any check
<mgz> does anyone?
<vila> I warned the PP after releasing 2.3b1...
<mgz> this is why I never write any news!
<mgz> it's more trouble that it's worth :)
<vila> :-P
<vila> mgz: asking the RM to do that will be order of magnitude more trouble :)
<mgz> okay, I think only roryy's news needs moving of the bits that I merged
<vila> at least fixed-in should make such errors more obvious
<mgz> having some sensible means of doing the merge locally before handing off to pqm would also help
<vila> mgz: you need to use pqm-submit for local merges
<mgz> I remember you showing me that but don't actually remember how.
<vila> mgz: which is what feed-pqm is using under the wood
<mgz> ...I think 'wood' is the wrong noun, but I now can't remember the right one.
<mgz> hood.
<vila> "bzr pqm-submit -m '(nick)message(Name)'" as feed-pqm add nick/Name
<mgz> it's a car metaphor, not a furniture one
<vila> hehe, hood, 3 letters right out of 4, I can even pretend it was a typo :)
<vila> thanks for pointing this out :)
<mgz> ...just thought of a cunning manifest hack, and it appears to work
<mgz> bundling a dll in each dir would be ridiculous, but can put in more than one manifest, doesn't even seem to matter much what they contain
<vila> mgz: the last assumption sounds suspicious...
<vila> mgz: 'what they contain' sounds like you may be finding an irrelevant (even if correct) dll already loaded no ?
<mgz> yeah, don't really want to deploy it without some grounding in fact
<mgz> hm, maybe it matters a bit more thant I thought, does seem to want the ..\
<vila> hehe, funny how we tend to come here with vague beliefs to get them refuted ;)
<vila> which is a Good Thing :)
<mgz> well, it's not the actual location of the dll, but it's close enough apparently
<vila> yeah for DWIM paths: look there or close enough
<vila> bbiab
<zyga> how can I change the default log format for all commands that use log somehow? Do I need to add lots of alias commands?
<Glenjamin> what commands use log?
<zyga> Glenjamin, for example bzr missing
<zyga> I'd like missing to use git log format
<Glenjamin> i suspect the "easiest" way to do this would be a plugin
<zyga> !
<zyga> no configuration for such a preference?
<Glenjamin> ah, i was incorrect
<Glenjamin> "bzr help log-formats" indicates there is a preference
<Glenjamin> zyga: ^^
 * zyga checks
<zyga> Glenjamin, thank you that's exactly what I was looking for
<vila> bialix, GaryvdM: ping, I see you don't add a '-1' in the windows installer names, is that deliberate ? Do you add it only if you need to build a new one ?
<jam> morning all
<jam> hi vila
<vila> jam: hey !
<jam> mtaylor: still having the "missing inventories" problem?
<jam> vila: I'm trying to figure out how we generated 450 bug emails since last wed. It has been like 100 emails per day...
<vila> jam: huh, really ?
<jam> yep
<jam> at least in my inbox
<jam> it may be qbzr, etc
<vila> ha, right, if I look at my bzr-bugs box, 450 goes back to sept 22
<mgz> I have three more bugs to add to jam's mountain today as well
<mgz> just working out the last one now
<mgz> looks easy like the first rather than horrid like the second
<immy> hii.
<immy> why isn't anyone talking. :(
<dash> immy: did you have a question? :)
<immy> yes. :) what is this chtroom for. :)
<dash> immy: http://bazaar-vcs.org/
<dash> immy: a version control tool, mostly used by programmers. :)
<immy> oh right.
<immy> cool!
<immy> why is it used?
<dash> immy: did you ever save a file you were working on, then realize you deleted or changed some things you wanted to keep?
<dash> immy: bzr is a tool for remembering all the older versions of your files in a project
<dash> so you can look at its entire history, from the beginning up to now
<immy> ohhh i see.
<immy> cool!
<dash> for text files it can also show you the differences between different versions
<dash> and if you have a project that multiple people work on, it can merge together work done on different versions to make a combined version
<rubbs> immy: http://betterexplained.com/articles/a-visual-guide-to-version-control/  and http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ can explain about what this does on a more "zoomed out" level
<dash> the Ubuntu project uses bzr a lot as a tool to help programmers around the world cooperate on the same projects
<mgz> so, version control is cool and all, but where are the cute guys?
<vila> dash, rubbs, mgz : He's gone...
<dash> alas.
<mgz> ah, here's one.
<rubbs> vila: opps. that's what I get for ignoring quits...
<dash> i thought we had a new user ;)
<mgz> wow, that's a pretty crazy traceback in bug 654684
<ubot5> Launchpad bug 654684 in Bazaar "exceptions.KeyError: 'port' when doing Branch (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/654684
<vila> mgz: geez, that was fixed long ago...
<mgz> he says he tried 2.2.1 which suggests otherwise
<vila> weird, looks like bug #395714
<ubot5> Launchpad bug 395714 in Bazaar "Redirect to location protected by HTTP auth fails (affected: 1, heat: 0)" [Medium,Fix released] https://launchpad.net/bugs/395714
<mgz> the subprocess branch location is pretty unlikely, I doubt he's even trying to use http
<mgz> so there's probably a qbzr or explorer bug there as well
<vila> mgz: don't forget it's bencoded ?
<mgz> ah, yeah.
<mgz> he does say "local branch" but that could mean over the lan or something
<vila> hmm, checkout with http will not allow commits either or is it different with svn ?
<dash> vila: svn can do commits via http.
<vila> anyway, jelmer will kill me still haven't implemented OPTIONS in our http transports :-/
<vila> kill me for
<mgz> on the topic of svn, I need some user support...
<vila> dash: ha right, thanks
<mgz> tried to do `svn update -r 78554 a_file` on the python 2.7 maint branch, which used to be python trunk, and it deleted the file rather than change it to an old version
<mgz> presumably because the rev predated the name change which confused something?
<mgz> what keywords can I use to find a fix for that, everything's too generic.
<lifeless> mgz: 'svn UI doing as designed' ?
<mgz> lifeless: how do I get the old rev then? switch then update -r worked but switch is a big hammer.
<fullermd> Import into bzr, then...    ;)
<mgz> heh.
<maxb> mgz: As far as svn's concerned, a switch operation is strictly a superset of an update operation. Thus, you can switch -r
<maxb> and on that note, /me afks
<git__> anyone know what "PointlessCommit(No changes to commit)" mean?
<dash> it means you tried to do a commit with no changes in it
<git__> i made change to the file but still get the error message
<git__> is there a limit how many directories bzr can traverse?
<dash> git__: what does 'bzr status your/file/name' say?
<dash> no
<git__> doesn't say anything
<dash> git__: then the file is unchanged.
<git__> let me change the file now, and do bzr status [filename]
<mgz> or unversioned.
<mgz> do `bzr add yourfile`?
<dash> mgz: it'd say "unknown" if it wasn't added
<git__> even after changing the file, i did bzr status [filename], nothing return
<mgz> not if it's in the ignore list I think.
<dash> mgz: oh true
<dash> git__: what's the filename
<git__> category.tpl
<git__> every files in the directory have that problem
<dash> hmm well that won't be in the default ignore list
<mgz> what's the directory name? :)
<git__> product
<mgz> okay, that's not very ignorable either
<git__> I use bazaar explorer, it works
<gmpff> hi
<git__> is there any plan for bzr to support image differential?
<git__> i like bzr upload feature, that's the coolest
<dash> git__: you can use any diff program you like with bzr
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: vila | bzr-2.0.6, 2.1.3 and 2.3b1 are official | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<jam> \o/ I finally dug myself out of 450 bug mail message backlog. The big offender was james_w with his udd spam. (Not that those aren't worthy, but it generated a *huge* amount of emails over the week(end))
<jam> git__: "image differential"? I believe qbzr already supports showing images side-by-side when seeing them in a diff
<jam> (bzr qdiff, IIRC)
<james_w> jam: yeah, sorry about that
<jam> james_w: I just responded to your history email, I think you might be wrong about the analysis, but I could have messed something up myself.
<jam> I have to go now, but I'll try to follow up tomorrow.
<james_w> jam: thanks, I'll take a look
<jml> mgz: I promise, soon, I will review your branches.
<jml> mgz: thank you for them
<mgz> ha, do that then I just make you review more
<mgz> (they all kinda need input rather than rubber stamping, so I don't mind you taking a while)
<mgz> o, while I have you though, is it easy to give me triage rights on testtools?
<mgz> I've filed a few things and then can't prio them.
<jml> mgz: uhh, probably... I've made a note & will fix it if I can.
<mgz> it's a niggle only.
<jml> mgz: don't get me started on niggles
<jml> anyway, must retire. g'night.
<mgz> night!
<poolie> hi jml, mgz, good night
<mgz> hey poolie.
#bzr 2010-10-05
<spiv> Morning.
<poolie> hi there spiv
<jeremyw> jam: ping
<poolie> maxb: hi, still here?
<maxb> poolie: at 3am my time? unlikely :-)
<poolie> hi maxb
<poolie> i wasn't sure what tz you were in
<poolie> maxb, oops, i also had you confused with mkanat
<poolie> vila, so, regarding releases
<poolie> perhaps we can try to get more clear on what we desire
<poolie> high on my list is not wasting time on the release process itself
 * vila nods
<poolie> which is not to say that all release-type work is a waste; clearly it is useful, but any costs that don't gain an incremental benefit are a waste
<poolie> and that's got two parts: wasted actual labor, and also unnecessary delay
<vila> agreed
<poolie> on the other hand, we don't want to waste our users' time and attention by telling them about something that they can't actually install
<poolie> which in practice means its very good for binaries for various platforms to be available when it comes out
<vila> yup, that's why I want to change the process a bit so we can ensure we will successfully build the installers the day we announce the source freeze
<poolie> that would be good
<poolie> i guess really the ideal is to _automatically_ build them as a consequence of deciding to release
<poolie> but that seems a bit elusive
<vila> for naming reasons, we can't build them *before* freezing, but we can prepare for that and avoid last minute fixes
<vila> we are almost there for OSX minus 10.5 machine availability
<vila> well, I have one, but I plan to upgrade it to 10.6 soon
<vila> we made some significant progress on the windows front too with more people setting up their own environment, but there are still some glitches
<vila> thanks to maxb things are also clearer on the debian and Ubuntu fronts but still not fully automated (well as fully as possible, there will always be some manual steps
<vila> )
<poolie> so what broke in 2.3b1? i haven't read all my mail from the weekend
<vila> well, AIUI, for some users, a dll is missing and abort the installation
<vila> both GaryvdM and mgz have been hammering on it but I think we still haven't a fix
<vila> the number of affected users is also unclear
<vila> I'm very tempted to *not* announce 2.3b1 (knowing that ~600 downloads have already occurred so people are testing it anyway) and focus on 2.3b2
<vila> OR
<vila> announce it with with a warning about this dll bug
<poolie> ah, this one
<poolie> i think the second is strictly better than the first, isn't it?
<vila> 2.3b2 is planned for 2010-10-08 aka next Friday, we can change that to 2010-10-14 instead
<poolie> the only down side perhaps being that people may see too many announcements
<vila> yup
<poolie> we should make sure we have something clear explaining the different series
<vila> it's also why I didn't announce 2.0.6 and 2.1.3 on the assumption that the targeted population may be too small
<poolie> mm
<vila> which in turn raise the question about *how* we should package them (or not)
<poolie> i think we should try to do SRUs for them,
<poolie> but only if that can be done at a reasonably low cost
<vila> for OSX and windows where we (collectively) package more than just bzr-core, it makes sense to focus on 2.2 and 2.3 only
<vila> there is bug #525571 for 2.1.3
<ubot5> Launchpad bug 525571 in bzr (Ubuntu) "No locking when updating files in ~/.bazaar (affected: 7, heat: 75)" [Undecided,New] https://launchpad.net/bugs/525571
<vila> and bug #582656 for 2.0.6
<ubot5> Launchpad bug 582656 in bzr (Ubuntu) "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 36)" [Undecided,New] https://launchpad.net/bugs/582656
<vila> I don't expect much until maverick is out
<vila> oh, and for 2.2.1, based on a  discussion with maxb, I'm preparing a report about test failures differences between 2.2.0, 2.2.1 and 2.2.2 (not yet released :)
<vila> which I interrupted yesterday evening, but roughly 2.2.0 and 2.2.1 have the exact same failures but more tests are run for 2.2.1
<vila> I still need to check that we have no more failures with 2.2.2 which is a bit more involved as the env is different (running from the installed version as root is required and I encounter some failures I wasn't aware of)
<vila> I thought we got them all..
<poolie> bug 582656 is worth fixing in old distros
<ubot5> Launchpad bug 582656 in bzr (Ubuntu) "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 36)" [Undecided,New] https://launchpad.net/bugs/582656
<poolie> 525571 is a bit less so, i think, because it probably only comes up with bzr-svn and that's not so hot in karmic
<maxb> poolie: Is there anything in 2.0.6 that's important enough to make it worth bothering with SRUing into a release that's only got 7 months to run to EOL anyway?
<vila> poolie: indeed, but it seems that SRUs are a more heavy process than ppas... so for Ubuntu we already have an answer which is: use our last stable, 2.2
<vila> which kind of converge with the OSX and windows philosophy
<poolie> i think SRUs _ought_ to become quite lightweight
<poolie> with the microrelease exception etc
<poolie> and with maxb's help too
<poolie> for 2.0.6 perhaps we should see if anyone actually cares to ask on the bug
<vila> yup, I'm proposing to avoid them, just mentioning an alternative
<vila> eeeerk
<vila> yup, I'm *NOT* proposing to avoid them, just mentioning an alternative
<poolie> to avoid what?
<vila> SRUs
<poolie> ok
<vila> maxb: It would be nice if you could make a mail summary about the packaging branches status and what you think about the current process (including debian of course)
<poolie> so perhaps for old series, which at the moment means only karmic
<poolie> we should just wait for someone to ask for the sru
<vila> to trigger 2.0.7 you mean ? Or already for 2.0.6 ?
<poolie> but for newer ones, where we care more about pushing the update, i think SRUs are better than packaging them ourselves
<poolie> and they should converge more
<poolie> maxb asked if it was worth SRUing 2.0.6 and i'm not convinced that there is
<vila> well, I'm convinced we can build with no test failures for 2.2 (and of course 2.3) and comply with the MRE rules, but for 2.0 and 2.1, SRUs are still needed, we can wait a couple of weeks for maverick activity to settle a bit and see what ~ubuntu-sru do
<poolie> that works for me
<poolie> with regard to the betas, i think we should stick with, and stick more closely to, the plan that we will give a limited window to build installers
<poolie> and after that announce without them
<poolie> but perhaps you should post about this to the list and we can see if people object
<vila> yup, I will do that
<vila> oh and we haven't bump the 2.3 API yet
<poolie> we should do that
<vila> poolie: oh, and about releasing from *trunk*, both you and jam mentioned it but it isn't described in releasing.txt (which I followed closely hence the 2.3 pqm branch)
<vila> so I think I understand what it means
<vila> which is creating the tarball from trunk and create the pqm branch only when... when what ? First RC ? True 2.3.0 ?
<vila> in the mean time I will probably just ask a losa to pull --overwrite the pqm branch so no harm has been done
<maxb> ooi, why do we have a release structure that requires losa intervention all the time?
<vila> maxb: only when we create a new series
<maxb> it's still oddly inefficient
<poolie> it is
<poolie> it would be good to fix that
<poolie> it's oddly... distrustful of developers
<poolie> which might be a reasonable setup for archive builds
<poolie> but in this case seems strange
<poolie> i'm glad we enforce test suite checks but i'm not sure it needs to be quite so harsh
<poolie> we can reconsider this when we prototype tarmac
<maxb> Compared with, say, renaming the ~bzr-pqm user to ~bzr-pqm-daemon, creating a ~bzr-pqm team, renaming the branches back, and adding the ~bzr-pqm-daemon and trusted devs to ~bzr-pqm
<poolie> mm
<poolie> i don't think that will be quite enough
<vila> maxb: that won't give us access to the pqm instance
<poolie> because pqm itself needs to be told about the new branches
<maxb> oh, I see
<poolie> but that's just kind of a bug in pqm, which tarmac may either fix or make tractable
<lxsameer_> hi does bazaar allow to clone just a subdirectory under the main repo , and not the whole repo
<jelmer> sidnei: Nice blog post, interesting read!
<jelmer> lxsameer_: no, it doesn't support partial checkouts.
<jelmer> lxsameer_: there are some design docs about it but it hasn't yet been implemented.
<lxsameer_> jelmer, is it a DVCS that can do this ?
<jelmer> lxsameer_: none of the bigger ones can
<lxsameer_> jelmer, :( thanks
<Kamping_Kaiser> jelmer: you can do lightweight but not partial, is that correct?
<jelmer> Kamping_Kaiser: yep
<Kamping_Kaiser> jelmer: thanks for confirming :)
<uffiole> hi. Is it fine to rename the main project folder ?
<Glenjamin> uffiole: generally, yes
<Glenjamin> although you might get related branches trying to point to it, which obviously wont work anymore
<Glenjamin> is there any way to undo an update?
<uffiole> ok thx , found out it works
<uffiole> cu
<vila> Glenjamin: It depends on whether you had uncommitted changes or not
<vila> before doing the update
<codingrobot> how can i go back to a revision nummber X? bzr update -r X and bzr revert -r X doesn't seem to do the job. bzr revno shows the latest rev. number
<GaryvdM> codingrobot: update changes the basis tree, so it will show in qlog (not sure how to see this with cli)
<GaryvdM> codingrobot: revert leaves the basis tree, so bzr status shows what changes it has made.
<codingrobot> what?! i just want to get rid of the changes made in the previous 2 commits
<GaryvdM> codingrobot: bzr revert -r -3 ; bzr commit -m "Revert xxxx"
<codingrobot> and what is with bzr revno? should i ignore the output?
<GaryvdM> codingrobot:  the revno will only increment after you commit.
<codingrobot> ok
<GaryvdM> revert -r X does not commit the revert, it only modifies  the working tree.
<codingrobot> yes, thats how every other scm tool does it, but the revision nr. gets reverted too. thats what confused me a bit.
<jam> jeremyw: morning
<jam> hi vila
<jam> james_w: if you're around, I'd be happy to chat about the merge stuff. I'm writing up another email. It looks like you are inherently criss-cross by the nature of what has happened
<james_w> hi jam
<james_w> that's quite possible
<jam> james_w: just sent
<jam> let me know when you get it, since I'd like to chat and refer to those graphs
<maxb> james_w: Quick question for you: what do you think about an option for udd import-scripts which downloads source packages into a persistent BASE_DIR/downloads/PACKAGENAME/ instead of the transient BASE_DIR/updates/PACKAGENAME/ directory? It would be helpful for people testing on less-than-amazing internet connections.
<james_w> jam: read it
<james_w> maxb: I would be fine with that
<jam> james_w: so, the next step that I can think of, is trying to figure out if we can fake a common base.
<maxb> Great, MP will follow this evening, then
<james_w> maxb: great, thanks
<james_w> maxb: and I'll review your others today, sorry for the delay
<james_w> jam: the "fake" you can do to get to the ideal case you refer to in the email is what we are currently doing as I understand it
<jam> james_w: not from what you've said earlier, the issue is that the 3.0-1 import needs to be based on the fake 2.1-1 import
<maxb> james_w: No problem, you've amazed me by reviewing part of my initial batch before I'd finished submitting all of them :-)
<james_w> heh
<james_w> jam: in these cases we don't have A-B-C, or at least those cases weren't the terrible behaviours that led me to this originally
<james_w> we have B and C as two descendants of A, and the first thing we do is create a new revision that has B and C as parents, and the contents of whichever is later
<jam> sure
<jam> but I'm missing the other bits
<gmpff> Hi.
<gmpff> I'm struggling with a corrupted bzr repo. Any suggestions for where I start reading ?
<gmpff> MD5 hashes of one of the pack don't match.
<gmpff> s/pack/pack files/
<james_w> jam: thanks for your analysis though, it's pretty clear that we can never have a simple merge now
<jam> james_w: an open question is whether we can get convergence after another merge
<james_w> jam: my immediate concern was getting rid of the "you're in an intermediate state, and you have conflicts you need to resolve, but I can't really tell you where they came from, and I might ask you to solve the same ones again in a minute"
<jam> honestly, --weave or a per-file 3-way merge would probably handle the "ask you to solve them again in a minute"
<jam> but "where they came from" ?
<jam> how does that occur
<james_w> because that's a terrible user experience, but if doing the merge the other way leads to "worse" conflicts in the end then that might not be the best idea
<james_w> it's more just a phrasing thing in the UI
<james_w> it currently says: ('The upstream branches for the merge source and target have '
<james_w>             'diverged. Unfortunately, the attempt to fix this problem '
<james_w>             'resulted in conflicts. Please resolve these, commit and '
<james_w>             're-run the "merge-package" command to finish. '
<james_w>             'Alternatively, until you commit you can use "bzr revert" to '
<james_w>             'restore the state of the unmerged branch.')
<jam> well, it may give you more *honest* conflicts
<jam> which is a whole lot better than artificial ones
<james_w> yeah
<james_w> the main issue is that resolving twice is outside the normal workflow, so it's not comfortable for people, and we describe the problem really badly which doesn't help
<james_w> the second issue is that you can end up having to resolve the same conflicts when you do the final merge as you just resolved in that intermediate step, which is frustrating, and leaves people feeling that they did something wrong
<jam> james_w: I honestly wonder if you wouldn't find a big advantage to supporting "--weave" as the merge type
<james_w> jam: I'm trying to find an example so we can have a go
<Glenjamin> vila: yeah, it did.
<Glenjamin> I did bzr up, then got conflicts, and wanted to reverse that action
<jeremyw> jam: So I've created a very simple repository browser for bzr.  It's stupid fast, even without throwing bzr-history-db at it.
<GaryvdM> jeremyw: May we see it? How does it differ from loggerhead?
<jam> jeremyw: good to hear, congrats
 * GaryvdM waves at jam.
<jeremyw> I'm not trying to compete with loggerhead, and the UI is really minimal right now.  I'm writing a tool that needs a VCS agnostic repository browser so I'm writing one.
<jeremyw> Let me get you a screenshot.
<jeremyw> http://i56.tinypic.com/20urgap.png
<jeremyw> That's the root view of the bzr.dev branch.
<jeremyw> Very minimal but it does work.  Clicking a file shows contents while clicking a dir drills into that dir.  You can even specify a revno to browse a particular revision.
<jeremyw> It was done in a few hours so there isn't much effort into it.
<GaryvdM> That's cool.
<jeremyw> Eventually, you'd have a nicer UI and more features but for now, I'm going simple to flesh out my ideas.
<GaryvdM> Clicking on NEWS probably works, unlike loggerhead..  (/me ducks and runs....)
<jeremyw> It's like a frickin' rabbit hole though man.  You get something working and you realize the N things that need to be fixed/added.
<jeremyw> Single person teams suck.
<GaryvdM> Yhea - I known the feeling.
<GaryvdM> Would it not be possible to reuse bits of loggerhead?
<jeremyw> Maybe but the idea is to have a VCS agnostic repository browser.
<maxb> I have difficulty believing that such a thing is the right way to go. Different VCSes have different peculiarities which need browsing differently
<jeremyw> I can see the concern but my plan isn't to have the most feature-rich repository browser, although I'm not sure why I couldn't.  It's about providing a common UI and common features across different VCSes where applicable.
<jelmer> maxb: well, loggerhead works against svn, hg and git too :-)
<jeremyw> I didnt' know that.
<jeremyw> Hmm...
<jeremyw> And the real driver behind this is that the repository browser is only a small feature in the overall application.
<jeremyw> We'll see.
<jelmer> jeremyw: if it's blazingly fast then that's a big benefit over loggerhead though :-)
<jeremyw> This really is fast, but I'm not doing as much as loggerhead just yet.  I mean, this is the first working piece.  haha
<jeremyw> I think the speed right now is in the simplicity.
<jelmer> I don't think loggerhead can really justify its overhead though, it's not that advanced.
<jelmer> jeremyw: oh, I should clarify. loggerhead supports git, hg and svn because bzrlib does; it doesn't really have support for anything than bzrlib itself.
<jeremyw> jelmer: I got you.  Thanks for the clarification.  :)
<jam> james_w: thanks for the brltty link, though looking at it, it just seems like a regular conflicts to me. Specifically, ubuntu was at 4.0-8ubuntu1, but debian had a 4.0-9 before the 4.1-1 stuff. (though 4.0-9 looks a whole lot like the 4.0-8ubuntu1 changes +/- some stuff which is what causes the conflicts)
<james_w> right, but you saw the extra step of resolving conflicts?
<jam> I did see that merge-package dumps out with a conflict of some sort
<jam> is it meant that "upstream tags are new, and upgrading the upstream causes conflicts" ?
<jam> in this case, though, why did it need to do the extra merging upstream step?
<jam> upstream-4.0 is the direct parent of upstream-4.1
<james_w> take a look at the revision graph, it's more complex than that
<james_w> the "pristine" branches of the Debian and Ubuntu are diverged
<jam> ok, I see that now. but what is "import upstream version 4.0" if not "tag:upstream-4.0"
<jam> or put another way
<jam> why is there a "Import upstream version 4.0" which *isn't* the upstream-4.0 tag, but the "upstream-4.1" tag is based upon *it* and not "upstream-4.0" ?
<jam> though I note that there are *tons* of differences between "Import upstream version 4.0" and what is tagged "upstream-4.0"
<james_w> there are two "import upstream version 4.0" revisions, one of which has a slightly misleading commit message, as it isn't really an import, but a "merge" of the existing import in the other distro
<jam> so the one that is tagged is the merge of the existing import?
<jam> (as far as UI goes, why not just tell the user the tags involved? 'upstream-4.1 conflicted while merging into upstream-4.0', please try to resolve), however even once resolved, how is that communicated to future code?
<jam> (or maybe it doesn't as I do see 2 "Prepared upstream tree for merging into target branch" messages)
<bialix> C-S: ping
<bialix> hmmm, I'm not really sure is it bug? with bzr 2.2.0: `bzr branch lp:bzr-explorer-website` sets parent branch as: bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr-explorer-website/
<bialix> at least it weird
<maxb> bialix: It is a recent change in Launchpad
<maxb> Now, the SSH server is capable of resolving shortcut lp urls directly
<maxb> With the goal of making the initial xml-rpc lookup unnecessary
<bialix> ok, but bzr shows me this ugly %2B in URL
<maxb> *shrug*, that's URL-encoding for you
<bialix> I know, but it's weird anyway
<maxb> perhaps ugly, but not weird
<bialix> no, it's weird because there is bug somewhere
<bialix> if I do `bzr branch lp:~bzr/bzr-explorer-website/trunk` then I end up wth parent branch: bzr+ssh://bazaar.launchpad.net/~bzr/bzr-explorer-website/trunk/
<bialix> no %2B!
<GaryvdM> Hi bialix.
<bialix> heya Gary!
<bialix> will poolie be around today/tomorrow (depending on TZ)
<Meths> Is the website correct that 2.2.1 is the current stable release?
<bialix> ?
<bialix> Meths: yes
<Meths> Okay, thanks.  (It's not in /topic.)
<bialix> Meths: hmmm, yes. jam missed it
* GaryvdM changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | Release Manager: vila | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 are official | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<bialix> GaryvdM: it will be nice to review and land qdiff related patches
<GaryvdM> bialix: Yes - sorry
<bialix> GaryvdM: if you will look on them, then https://code.launchpad.net/~dorins/qbzr/qdiff-changes/+merge/34710 should be first; and https://code.launchpad.net/~s-dumbie/qbzr/ench_qdiff/+merge/33986 after that
<GaryvdM> I've got a branch that I've been working for 2 months that I really want land. Soon hopefully.
<bialix> logrefactoring?
<GaryvdM> yip
<GaryvdM> bialix: what do you think about this: http://www.youtube.com/watch?v=tMdE4GmFaDQ ?
<GaryvdM> from a separate branch
<GaryvdM> log refactor landed. :-)
<GaryvdM> I hope to use that selection behaviour to fix bug 412035
<ubot5> Launchpad bug 412035 in QBzr "qlog: Add ui to select parent to diff with. (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/412035
<bialix> GaryvdM: I'm not sure what you asking about that clip on youtube. either you gave ne a wrong link or I've lost my patience to see that asian boy after 1st minute
<GaryvdM> bialix: the asian boy is you tube's dumb suggestions
<GaryvdM> bialix: If you drag a selection, it only selects revisions that are ansestors of the top revision.
<bialix> in qlog?
<GaryvdM> Yes
<GaryvdM> Changes made by revisions that are not ancestors of the top revision don't show in the diff, so I think it is more accurate.
<bialix> I was looking at lp:~dorins/qbzr/qdiff-changes
<bialix> it's pretty nice
 * GaryvdM looks.
<bialix> GaryvdM: once I've used keyboard arrows on your qlog in trunk I've got traceback
<bialix> also you made bug labels dark red, why?
<bialix> GaryvdM: http://paste.ubuntu.com/506749/
<GaryvdM> I did not think I had changed the bug labels
<bialix> I think I've pressed right arrow and want to expand merge
<bialix> GaryvdM: maybe you don't but the text on the labels now black, it used to be white
<GaryvdM> bialix: ok I'll take a look.
<GaryvdM> bialix: Please could you check if bug 534963 still exists?
<ubot5> Launchpad bug 534963 in QBzr "qlog on shared repo: wrong twisty? (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/534963
<bialix> GaryvdM: re labels http://imagebin.ca/view/xaoMUEv.html
<GaryvdM> bialix: One thing I hope you will like is test_loggraphviz.py
<bialix> GaryvdM: re bug 534963: I don't have that tree around atm
<ubot5> Launchpad bug 534963 in QBzr "qlog on shared repo: wrong twisty? (affected: 1, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/534963
<bialix> maybe it at another computer, I'll check tomorrow
<GaryvdM> Ok, thanks
<bialix> vila should be happy about test_loggraphviz.py
<bialix> your ascii graphs are funny
<GaryvdM> bialix: keyboard nav bug fixed, and I think I've fixed the label color.
 * bialix is pulling
<bialix> GaryvdM: yes, now it's better
<bialix> GaryvdM: but I'm not sure what do you mean about dragging
<GaryvdM> bialix: the stuff from the vid not landed yet.
<bialix> ok
<GaryvdM> I think I pushed to lp. /me checks
<GaryvdM> lp:~garyvdm/qbzr/log_select
<GaryvdM> Hay, did they upgrade the mysql branches.
 * GaryvdM pulls out the sketches made together with bialix at uds for qdiff.
<GaryvdM> I should try scan them.
<GaryvdM> bla - no one we be able to read my handwriting. - Ill draw it in mockups.
<sven_oostenbrink> I have a bzr crash on a bunch of files in ./.bzr/repository/indices/ being empty (0 bytes).. Can I remove those files and try again?
<sven_oostenbrink> Since these are indices. I suppose they can be recreated again?
<sven_oostenbrink> I cant do anything with this repo anymore and I have a crapload of commits ready to push.. :( Anybody who might be able to help out?
<maxb> sven_oostenbrink: Last time someone asked this, the response was uncertainty whether they could actually be recreated, and a definite assertion that no code exists to do so
<sven_oostenbrink> maxb: as in, Im screwed...
<sven_oostenbrink> Besides that, what could be the reason for those files to be empty? I already submitted a crash report, but this is bad for me :(
<maxb> Filesystem corruption, perhaps?
<sven_oostenbrink> maxb: besides an fsck, the filesystem should be 100% ok,
<maxb> I suggest posting to the Bazaar mailing list, to get people more expert than me involved
<sven_oostenbrink> maxb: okay, thanks anyway!
<lifeless> sven_oostenbrink: did you have a system crash?
<lifeless> power failure? removed a hotplug drive without flushing?
<sven_oostenbrink> lifeless: mmmmmm, thinking about it.. my laptop froze about... 45 minutes ago.. happens every day these days, some hardware failure I need to look into... mmmmmmm...
<lifeless> thats the problem
<sven_oostenbrink> but even so, AFAIK, bzr wasnt busy, and AFAIK, kernel should flush on a 5 seconds interval, no?
<lifeless> you had file content in your OS buffer
<lifeless> sven_oostenbrink: depends on the file system
<sven_oostenbrink> lifeless: even so, there is no way to repair that?
<lifeless> sven_oostenbrink: and mount options etc. what file system?
 * lifeless bets on ect4
<sven_oostenbrink> lifeless: bingo... why betting on ext4?
<lifeless> sven_oostenbrink: because its very agressive about not writing to disk.
<lifeless> during development of it there was a -huge- discussion about this; it was breaking kde and gnome configs in this exact way, *all* the time.
<lifeless> sven_oostenbrink: I suggest mailing the list as maxb suggested; you may be lucky and be recoverable.
<sven_oostenbrink> lifeless: I guess thats the reason why chromium isnt storing my open pages either after a crash?
<lifeless> sven_oostenbrink: after a machine crash? yes.
<maxb> sven_oostenbrink: This repository - is it public or private code?
<sven_oostenbrink> lifeless: Meh, the WT is still okay, Im creating a new branch, copying the old WT there, and recommitting.. its a bitch, but I can recover..
<lifeless> sven_oostenbrink: basically ext4 isn't serialising file system operations for different files from the same process.
<sven_oostenbrink> maxb: this specific one is public
<lifeless> sven_oostenbrink: application authors then have a choice:
<sven_oostenbrink> lifeless: not serializing as in writing out of sequence?
<lifeless> yeah
<lifeless> the file is 0 bytes long because the rename operation of a tmp file got flushed
<maxb> well then, if you provide a tarball of the broken stuff, someone might be willing to poke at it and see if it is reparable
<lifeless> but the file content didn't get flushed.
<sven_oostenbrink> maxb: Not really needed I guess, Im already recommitting.. I had quite a few non-pushed commits, but thats life :) code is still preserved so
<sven_oostenbrink> lifeless: that sounds kind of like cra... No way to work aroud that?
<lifeless> sven_oostenbrink: if the pack got flushed, we -may- be able to recreate the index with enough effort, but if the pack didn't get flushed, we're boned.
<lifeless> sven_oostenbrink: we could fsync at every little step, but fsync is the wrong hammer (we don't care about temp files being flushed, we care about a barrier approach - we want all ops before X to complete, then we have a small number of critical ops we could fsync on, and then we don't care after that.
<lifeless> but user space barriers were slammed on lkml, so :(
<lifeless> oh, and fsyncing will destroy performance on ext3
<sven_oostenbrink> lifeless: well, again, no biggie.. I mean, having to re-commit this much isnt fun, plus I had multiple commits for single files, so now those multiple commits become one.. its not a huge deal, just an anoyance, Im working on fixing it now
<lifeless> sven_oostenbrink: if you're having regular crashes, I suggest lots of backups :(
<sven_oostenbrink> lifeless: well, its becomming regular on this @#$*( laptop... I need a new one
<peitschie> hi all :)
<mkanat> lifeless: The proxy that does load-balancing on launchpad server processes, can it be dropped in front of loggerhead without any changes to it?
#bzr 2010-10-06
<mgz> whoops, making a hash of bug editing, sorry for the spam nmb
<lifeless> mkanat: mkanat probably
<mkanat> lifeless: Okay. Does it need any information from the processes it's proxying, like information on which ones are busy/free?
<lifeless> mkanat: we tell it a policy about how deep to queue.
<lifeless> if we're going to deploy with single threaded instances, its easy - we set that to 1 ;)
<mkanat> lifeless: Okay, that's easy enough.
<lifeless> filing an RT for it now
<mkanat> lifeless: Okay. However, loggerhead isn't completely ready for single-threaded instances.
<mkanat> I'm not sure why, but it's very very slow in single-threaded mode. I think there's some cache that it's regenerating for each request or something.
<lifeless> do you mean
<lifeless> 'if you configure it with one thread and then run it locally its slow'
<lifeless> or
<lifeless> 'if you configure a cluster of lh's with 10 threads each but a 1-request-at-a-time cluster policy it is slow' ?
<mkanat> lifeless: The first one.
<lifeless> ok, so lets not do that
<lifeless> we can just use haproxy to limit it to one concurrent request
<mkanat> lifeless: That sounds like it could work, yeah.
<mkanat> lifeless: I also haven't yet tested to see if there are any concurrency problems with multiple processes.
<mkanat> lifeless: But if we can set up a sort of edge loggerhead behind haxproxy, that would probably work.
<mkanat> For testing purposes, that is.
<lifeless> that would be staging
<lifeless> edge is a production system :)
<lifeless> http://blog.launchpad.net/general/continuous-deployment-in-launchpad
<mkanat> lifeless: Okay.
 * mwhudson would expect strictly fewer concurrency issues running multiple processes compared to multiple threads
<mkanat> mwhudson: I would too, but there's the log and the sql caches.
<lifeless> mwhudson: rt 41762 if you'd like to review what I've asked for.
<lifeless> ok, stacking wood.
<mkanat> And launchpad-loggerhead specifically has code to disable locking the log, although that probably wouldn't matter anyway since I think the locks are mutexes.
<mkanat> I think that it all being a single fwrite will probably be enough.
<mwhudson> mkanat: i don't think sqlite cares at all whether the multiple accesses come from different processes or different threads
<mwhudson> similar for locking really, i hope...
<mkanat> mwhudson: I think that you're right, and jam's post to the bzr list pretty much confirms it.
<mwhudson> yeah, one line per fwrite
 * mwhudson needs lunch
<mkanat> lifeless: The current production loggerhead isn't using bzr-history-db yet, though, also, BTW.
<mkanat> lifeless: So putting that into one-request mode would be, basically, a miserable experience.
<poolie> hm, istr that sqlite requires you to lock yourself if you're going to use the same object from multiple threads
<poolie> this might be handled in the python layer though
<lifeless> poolie: its not
<lifeless> we already have something to do isolation of the sqlite dbs, I think?
<poolie> hello lifeless
<poolie> mwhudson, could you find some time to review https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 ?
<maxb> Hmm, I don't suppose one of you feels like running requeue_package.py deja-dup coreutils freeimage on pkg_import@jubany ?
<lifeless> mkanat:
<lifeless> ./requeue_package.py deja-dup coreutils freeimage
<lifeless> deja-dup has not failed
<lifeless> coreutils has not failed
<lifeless> freeimage has not failed
<lifeless> ba
<lifeless> maxb: ^
<mkanat> maxb: I think we clearly need to legally change our names, or something. :-)
<maxb> huh
<maxb> well why does the web ui say they have :-(
<lifeless> noidea
<mwhudson> poolie: i'll take a look
<maxb> lifeless: Could you try that again with --force ? Because those branches are definitely lagging reality
<lifeless> ./requeue_package.py --force deja-dup coreutils freeimage
<lifeless> Usage: requeue_package.py [options]
<lifeless> requeue_package.py: error: no such option: --force
<james_w> $pwd?
<lifeless> pkg_import@jubany:/srv/package-import.canonical.com/scripts
 * mwhudson stabs his launchpad development environment repeatedly with a rusty blade
<james_w> cd ../new/scripts
<mwhudson> james_w: to be followed by ../../newer/scripts ?
<maxb> eww
<lifeless> pkg_import@jubany:/srv/package-import.canonical.com/new/scripts$ ./requeue_package.py deja-dup coreutils freeimage
<lifeless> Traceback (most recent call last):
<lifeless>   File "./requeue_package.py", line 8, in <module>
<lifeless>     import icommon
<lifeless>   File "/srv/package-import.canonical.com/new/scripts/icommon.py", line 21, in <module>
<lifeless>     from debian_bundle import changelog
<lifeless> ImportError: No module named debian_bundle
<lifeless> james_w: ^
<maxb> !delegate james_w :-)
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> ubot5: hush
<james_w> ../newest.REALLY
<james_w> lifeless: pythonpath=python-debian
<lifeless> james_w: this needs a profile or some such
<james_w> Go ahead
<lifeless> maxb: requeued
<lifeless> james_w: I have 3.5 mÂ³ to finish stacking
<poolie> thanks mwhudson
<james_w> lifeless: I have a hard disk to repair :)
<maxb> thanks
<lifeless> james_w: ouch
<lifeless> james_w: that sounds ... delicate
<poolie> mkanat, hi?
<mkanat> Howdy poolie.
<chx> is it possible to change what a branch is stacked on?
<jbowtie> chx: Yes, see bzr reconfigure
<chx> jbowtie: thanks!
<poolie> hi vila, bialix, gary
<bialix> hi poolie!
<poolie> i'm going to turn back on expiry of old incomplete bugs, unless/until someone complains
<bialix> I was about to ask you about kicking update of explorer site, but it's updated this morning. thanks anyway
<poolie> it was failing to update because of a minor permissions problem
<poolie> i fixed it
<poolie> thanks anyhow
<vila> hi all !
<vila> poolie: +1 for expiring bugs
<bialix> \o_ _o/
<vila> bialix: :)
<poolie> hi there
<vila> grr, update requires reboot, bbiab
<vila> weird... what is the meaning of 't' in 'drwxrwxr-t' in the chmod bits on '/' ?
<vila> that's on OSX if that matters
<vila> nm, sticky bit for directory
<vila> os.listdir('/home') raises OSError: [Errno 5] Input/output error .... wth ? (I know OSX uses /Users, but the directory exists here, is empty and chmod bits are 'dr-x-rxr-x root wheel')
<poolie> at that point on linux i'd look in the kernel log for an actual io error
<vila> I have a parent_location set to a path inherited from branching from another host and bzr expects Errno 2 (ENOENT) and fails in this case
<poolie> i would say generally we should not swallow eio
<poolie> it often does indicate a real hardware error
<vila> that's what we do, but it occurs during a format probe so we fail to raise NotBranchError
<vila> I think we don't have to care about *this* exotic case, but I'd like to understand what is really happening here
<vila> hehe, trying to scare me this early in my morning ? No, not hardware related ;) I can 'cd' there and issue ls -al
<vila> nothing in log, I think I will just delete this '/home' directory
<vila> ha ha ! sudo rmdir /home: Resource busy
<vila> still busy after a reboot...
<vila> haaaa, automount...
<mgz> morning all
<vila> and can't be reproduced on 10.6, ok, exotic, Wontfix :)
<vila> mgz: _o/
<poolie> hi vila
<vila> argh, lp read-only, bug report lost !
<poolie> did you see my messages, or were you rebooting?
<vila> tell me there is some log somewhere I can get it back :(
<vila> poolie: nope didn't see them
<peitschie> hi... does anyone know if there is an easy awy to generate a reasonable-sized repository?
<peitschie> nm... i just used my bzr checkout :D
<Glenjamin> he guys, i'm getting Error received from smart server: ('error', 'bytes must be a string') when trying to access a certain branch
<Glenjamin> any idea's what I should be looking at to diagnose properly?
<Glenjamin> http://pastebin.com/bp8twuQm =/
<peitschie> mm
<peitschie> thas cool!
<peitschie> i have no clues sorry (but i dont know much :))
<peitschie> are there foreign languages in ur branch at all?
<Glenjamin> it's a very basic rails app, which includes some binary files
<bialix> Glenjamin: it seems your bytes are actually unicode string, but bzr expects them to be plain string
<bialix> check the input
<Glenjamin> my input is bzr push repo-url
<Glenjamin> i'm not really sure what to look at beyond that
<Glenjamin> I can push the same branch over ssh, but then I can't pull it back down over bzr+http
<bialix> is it with CLI bzr? or with your own tool?
<Glenjamin> CLI bzr
<bialix> that's bug then, can't say more
<bialix> peitschie: your patch landed, thank you
<peitschie> bialix: a pleasure :).  Thanks for the feedback and guidance... it's quite exciting to get my first commit to bzr & friends accepted :)
<bialix> :-)
<zyga> hi, does anyone around knows how to use tarmac?
<txdv> Can you give me some google keywoards for this kinda of problem: Branch b1 is 3 commits ahead of b2, I want now to apply all the commits to b2 but instead of 3 commits i want to use only 1
<peitschie> txdv: I think what you want is to do a "merge" from b1 to b2
<peitschie> see: bzr help merge
<peitschie> txdv: do you mean you want the 3 commits to appear as one commit in b2?
<peitschie> or that you want all three commits to appear in b2 with only one command?
<txdv> yes
<txdv> 1 commit
<txdv> i want those 3 commits to appear as 1 commit
<peitschie> txdv: definitely merge then :)
<peitschie> http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html
<txdv> Oo
<txdv> quite different then from git's merge
<Glenjamin> yeah
<Glenjamin> there's no direct equivalent of git's fast-forward merge in bazaar
<Kinnison> git's ff merge is just "pull" in bzr isn't it?
<peitschie> that does sound like pull or push to me definitely
<Glenjamin> not quite
<Glenjamin> pull makes your branch a copy of the other branch (same history ordering)
<Glenjamin> git pull gets the revisions you're missing
<peitschie> ahh
<Glenjamin> should bzr be buildable without pyrex?
<ddaa> well no
<ddaa> but it should be usable without compilation
<ddaa> actually, not pyrex, cython
<Glenjamin> ah right, i think i misread that as cpython in the install guide
<Glenjamin> my smart server is failing on a type check inside some pyrex code, so i'm trying to do a quick fix by building without pyrex stuff
<ddaa> you probably have a larger problem
<Glenjamin> i do, but I need something to work by 1pm
<txdv> and what if i WANT those commit messages to be existent in the other branch?
<Glenjamin> txdv: they will be, just nested
<Glenjamin> ddaa: http://pastebin.com/bp8twuQm
<ddaa> I won't be able to help you, but if you have red blinking lights on your dashboard, cutting the wires to the lights is usually not the right way to proceed
<Glenjamin> haha
<ddaa> Glenjamin: that look like the sort of thing that very much should not happen, as in "no such bug should exist, because the test suite would catch them"
<txdv> Glenjamin: bzr log won't show them
<ddaa> Glenjamin: so I'm inclined to think your build/package is somehow wrong
<Glenjamin> txdv: --include-merges or -n, see bzr help log
<ddaa> Glenjamin: what does bzr selftest tell you?
<Glenjamin> running now... the error only appears over http, not ssh
<txdv> Glenjamin: does it save the subcommits or does it just save the log text with merge?
<Glenjamin> txdv: it saves the nested history afaik
<txdv> so only the text
<ddaa> txdv: merge + commit adds the whole data of the merged revisions
<Glenjamin> no, all the revisions are stored in the repo
<ddaa> but bzr has a hierarchical history, and by default "bzr log" only shows the mainline
<ddaa> mainline = revision committed or pulled in this branch, but not revisions merged
<ddaa> contrast that with the default of git and hg, which show every revision
<txdv> i understand
<txdv> so maybe you know how I *compact*merge 3 revisions into 1?
<ddaa> if you really, really do want to discard the history of merged revisions
<ddaa> (but you probably do not really want)
<ddaa> then you can use "bzr revert --forget-merges" between merge and commit.
<txdv> No no, lets say i have a topic branch, i do minor one-line changes in it for example 4, but it solves my problem
<txdv> now 4 line changes for 4 entire commit entries is a little bit overkill, so i want it to summarize into one revision
<ddaa> well, no, it's not overkill in any meaningful sense
<ddaa> but anyway, you can "revert --forget-merges" to do what you want
<ddaa> or you can "bzr uncommit -r-4" then "bzr commit" on the feature branch before merging
<ddaa> but, and I can't stress that enough, this needless and potentially troublesome tweaking.
<txdv> hm ok
<txdv> What about a counterpart of git --amend
<ddaa> no idea what git --amend does
<txdv> it uses the current revision to add stuff instead of creating x+1
<ddaa> that would be "bzr uncommit" then "bzr commit"
<txdv> awesome
<txdv> that will do it
<txdv> ddaa: thanks
 * ddaa shrugs
<Glenjamin> ddaa: I managed to turn off one pyrex module, and the python fallback doesn't produce the error
<Glenjamin> running the testsuite gave me 5 fails and 36 errors - seems to be mostly pycurl
<ddaa> mh... maybe try disabling pycurl
<ddaa> AIUI bzr has a rather byzantine set of http transport layers
<ddaa> httplib might be less troublesome
<Glenjamin> yeah, i've done some stuff to switch the order about
<Glenjamin> but pycurl can't be turned off on ubuntu
<Glenjamin> and i'm pretty confident that the WSGI smart server app doesn't touch pycurl
<txdv> ok i have retought it
<hrw> hi
<txdv> why bzr uncommit && bzr commit inferior to gits commit --amend is
<txdv> it doesn't save the commit history, i have to type it again in
<hrw> which bzr tool allows me to select single hunks for commits? kind of 'git gui' does
<Glenjamin> hrw: bzr shelve --all might do what you want
<twb> Is there a good reason bzr is consuming all available CPU and memory when running "bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk emacs" ?
<txdv> Glenjamin: shelf?
<txdv> or shelve?
<Glenjamin> shelve
<twb> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
<twb> twb      21634 64.3 49.9 579588 507536 pts/3   R+   21:34  15:56 /usr/bin/python /usr/bin/bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk emacs
<hrw> Glenjamin: I do not want "git stash" replacement
<txdv> dunno to who he is talking
<hrw> Glenjamin: I want something which save me from reverting hunks in file in editor and do commit, revert edit, commit, revert edit, commit way
<Glenjamin> i'm not entirely sure what your workflow is here, but there's no interactive commit
<hrw> looks like 'bzr commit -i' is closest which I can get
<Glenjamin> or maybe there is
<Glenjamin> you both seem to be trying to apply git-specific workflows to bazaar here
<hrw> Glenjamin: I use git for few years and bzr for just few months.
<hrw> Glenjamin: before used monotone, bitkeeper, subversion, cvs, rcs and my workflow was similar
<Glenjamin> i'm just intruiged as to why you'd only commit part of a file often
<hrw> Glenjamin: because I did lot of changes unrelated to each other and now I want to commit them
<Glenjamin> i guess that makes sense, but why not commit between fixes?
<yann2> hello! I am unsure to understand the difference between doing a pull and doing a checkout, could someone enlighten me?
<hrw> Glenjamin: because lot of work is done in environments where all I have it editor
<hrw> Glenjamin: and so far I did not found good replacement for 'git rebase' in bzr
<hrw> so my workflow is: hack until it builds, then commit all changes in set of commits (where one commit may consume few hunks and leave few others for other commits)
<maxb> yann2: A pull pulls new changes into an existing branch. A checkout creates a new checkout (which is another term for a bound branch) and pulls all history into it.
<twb> Never mind, the kernel OOM-killed it.
<Glenjamin> hrw: there's a bzr rebase plugin
<maxb> bzr-rewrite
<maxb> twb: Savannah hasn't deployed a smart (bzr-aware) server, so Bazaar is using its dumb transport support (plain http against the repository files). The dumb transport method was never intended as a good way to host huge projects.
<twb> Ah, I did wonder about that.
<twb> So what should I, a poor end user, do?  Look for a lp mirror of emacs?
<maxb> Basically, it wasa a really bad idea to migrate emacs to bzr without first ensuring there was a decent hosting platform available
<maxb> and yes, use a lp mirror
<twb> Is it just lp:emacs?
<twb> Appears to be, per https://code.launchpad.net/~vcs-imports/emacs/trunk
<twb> maxb: I think it was probably also a bad idea to base a technical decision (which vcs?) on political metrics (bzr has "GNU" in its name)
<maxb> I'd like to think Bazaar could work well for Emacs if it was deployed the way it's supposed to be, but yes, that's a poor rationale for the choiec
<twb> Does lp penalize me for not logging in?  bzr is actually reporting a slower I/O rate from lp:emacs
<maxb> Ah
<maxb> Yes, LP only supports the smart server over ssh
<twb> Sigh
<twb> You'd think the emacs people would have written this down somewhere
<twb> or the sv people
 * twb grumbles about having to provide an identity to a private corporation in order to clone Emacs in reasonable time
<twb> Aaaand apparently my launchpad login has expired because I haven't used it for four years
<twb> Fuck this, I'll just keep using the git mirror.
<Kinnison> lp: needs to offer smart server for non-logged-in people
<yann2> maxb > is there a command with which I can deploy a specific version, without any bzr files?
<yann2> like from bzr server to prod?
<awilkins> yann2, bzr-upload plugin, or just the bzr export command
<yann2> export sounds good :) I ll give it a try
<twb> maxb: by chatting with #launchpad I managed to find a version of a tty browser that launchpad supports, and log in, and find out my launchpad username was actually "twb" not "trentbuck@gmail.com".  Armed with this knowledge, "bzr lp-login twb" and "bzr branch lp:emacs" Just Work.
<twb> And I wrote down the results, so hopefully I won't have this problem again in another three years
<txdv> is it possible to undo a specific revision?
<txdv> the tutorial talks only about *last commit, last revision, last multiple revisions*
<dash> you can make a new commit that undoes the change of a previous one.
<awilkins> txdv, What you can do is reverse-cherrypick that revision and commit that as a new revision
<txdv> dash: what if i changed 100lines?
<dash> txdv: OK!
<txdv> awilkins: your solution was aproved, thank you very much, needed just a keywaord ;)
<dash> txdv: 'bzr merge -r Y..X'
<dash> where Y is the revision you want to undo, and X is the one before it
<txdv> thanks
<hrw> hi
<hrw> sorry for stupid questions but how to cherry-pick changeset (changes+commit)? "bzr merge -r130..131" picked changes but not commited them
<dash> 'bzr commit' like normal :)
<hrw> sure, and have to dig for commit message too?
<dash> "dig"?
<hrw> dash: do "bzr log PROPERBRANCH" and copy paste commit message
<dash> oh
<dash> well if that's what you want, sure
<hrw> thx
 * hrw arghs again
<hrw> and "bzr merge -r128..130" will squash all changes into one and leave me to commit?
<dash> yep
<hrw> so how to merge 128..130 as set of revisions?
<hrw> with their commit logs etc
 * hrw -> food
<twb> OK, now I *really* give up.
<twb> After a couple of hours, "bzr branch lp:emacs" finally caused the kernel to OOM-kill its child process (ssh), and then hang the entire machine.
<jam> morning all
<jam> twb: what version of bzr?
<twb> Prior to the OOM it (bzr) was consuming a good 58% of the 1GiB of RAM.
<twb> jam: 2.2.0-1, Debian Squeeze
<twb> Oh, and I have carefully nice'd and ionice -c3'd it.
<twb> The git clone of the emacs git mirror, incidentally, completed successfully in around half an hour.
<jam> killing ssh because of OOM is very strange
<twb> jam: it was a child of bzr
<twb> The oom killer tries to kill children of hogs before the hogs themselves.
<twb> What's strange is that after killing SSH it didn't then kill bzr and restore my system to working order.
<twb> (Which is what has happened in the past when the OOM killer killed off things like firefox and polipo.)
<twb> I also did a "bzr branch http://bzr.sv.gnu.org/emacs/trunk" or so on another host, which had 4GiB of RAM and a quad-core 3GHz CPU, and that eventually finished.  So we can probably say that bzr branch on the emacs repo requires more than 512MB and less than 4GiB of memory at peak consumption.
<jam> twb: I'm sure it requires less than 2GB, I think it is less than 1GB, but it could be 800MB or so.
<jam> also note that branching over http:// will have a different memory profile to branching via bzr+ssh://
<twb> Right.
<jam> (I would think the latter would use less memory, but I won't guarantee it)
<twb> I tried http first and ran into problems, so I spent a couple of hours getting lp:emacs to work over ssh
<twb> According to free -m, in my fresh boot, I'm using 193M (after ignoring swap/cache).
<twb> So if it is 800MiB or so, it could have OOMed for that reason
<jam> twb: you could run with -Dmemory or "echo debug_flags = memory >> ~/.bazaar/bazaar.conf" and it will show you memory consumption on process exit (peak memory, etc)
<jam> not that it helps you a lot here, but if you are interested
<twb> Well, I'm not going to run it again right now :P
<Glenjamin> someone's accidentally pushed a branch to the repo root, is there any way I can undo this?
<jam> Glenjamin: rm .bzr/branch -rf
<Glenjamin> of course, ty!
<jam> touch .bzr/branch (if you want to prevent it for sure in the future, though the failure messages won't be perfectly clear)
<Glenjamin> will that confuse loggerhead?
<twb> jam: I was assuming that 800MB was unexpected, so I was dutifully reporting it (read: bitching)
<jam> Glenjamin: shouldn't. Loggerhead might try to open it, but it should fail as it would with any other directory
<Glenjamin> that was the problem i had so far, it didn't list the branches because the parent was a branch
<jam> Glenjamin: right, touch .bzr/branch doesn't make it a branch, .bzr/branch/format does
<jam> by creating a *file* there you prevent a directory from being created there
<txdv> i start not to like bzr
<txdv> bzr push just wont work :(
<txdv> the solution is very inuitive
<txdv> edit the file in .bzr/branch/branch.conf and change http to bzr+ssh
<txdv> bzr could do better, i mean even git is more verbose about failures and it's written in C
<vila> txdv: what server were you trying to push to ?
<txdv> vila: launchpad
<vila> txdv: didn't you get a warning about http not allowing write operations when you initially branch ?
<vila> jam, twb: branching emacs from lp completed in ~11 minutes here: http://paste.ubuntu.com/507301/
<vila> the peak seemed to occur very late
<jam> vila: vmpeak = 665
<jam> probably building the working tree?
<jam> I would guess the slowness was swapping
<jam> that, and vila has a very big pipe
<vila> jam: and it looks like we are better at saturating it these days
<twb> In case it isn't obvious from the talk of OOM killing, I run without wap
<twb> *swap
<vila> jam: but not during the whole transfer though
<vila> twb: 1GB without swap ? Unusual, why so ? (Just curious, I realize there are valid reasons to do that)
<twb> It's a netbook with a small SSD
<vila> indeed
<vila> twb: I'm pretty sure there have been related fixed in 2.2.1 but may be only in trunk...
<twb> And more to the point, my experience on 2.6 is that, when you have swap, during memory consumption your system becomes unresponsive to the point of being unable to fix it, whereas the OOM killer has maybe a one in two or three chance of recovering
<twb> linux-2.6, that is
<vila> twb: yeah, nightmarish
<vila> twb: may be even more with 12GB RAM 24GB swap system :-/
<vila> or rather a mis-configured 12GB *without* its 24GB swap
<vila> jam, twb : wasn't there a recent merge proposal calling meliae for this king of trouble ?
<jam> vila: yes, I don't think it has landed yet, though, and you have to supply "-Ddump_memory"
<twb> vila: I dunno, man, I don't track the kernel
<vila> twb: not in the kernel, in bzr
<vila> https://code.edge.launchpad.net/~kbielefe/bzr/551391-log-memory-usage/+merge/37086
<twb> I don't track bzr either :-)
<vila> twb: I realize you may not be able to use it though :-/ (Requires more deps and running from source)
<vila> twb: hence the url above :)
<twb> The only bzr users I know (apart from Emacs) either migrated from arch and got stuck, or are canonical employees.
<vila> So you came here to extend your horizon ?
<twb> I came here to bitch about the OOMing :P
<vila> bug reports and new people are always welcomed :)
<twb> Yeah, well.  I've gotta jump through hoops to use lp
<vila> you shouldn't have to, especially if you register an ssh key to launchpad
<twb> I mean malone, not bzr lp:foo
<twb> You *do* use lp/malone for your BTS?
<vila> we use lp yes (I'm not sure a lot of people remember the bug part was named malone ;)
<vila> as for people using bzr: https://code.edge.launchpad.net/ubuntu says there are ~200.000 active branches just for ubuntu
<twb> Is that counting all the mirrors of upstream projects? ;-)
<vila> certainly, but I think it's only a small fraction
<sender> All of a sudden my bzr pull from a SVN repo isnt working anymore. This is the error: http://pastebin.com/2vuM2Qk4
<sender> BZR version: Bazaar (bzr) 2.1.1 on Ubuntu 10.04
<vila> sender: sounds like a known bug in bzr-svn, what does 'bzr plugins' says for it ?
<jam> sender: -Derror would include a traceback, or you can get it from ~/.bzr.log
<jam> It looks to me like a mismatched revno-for-last-revision stuff, but I'm not positive
<sender> villa, jam: thanks. bzr plugins: svn 1.0.2
<vila> sender: could be bug #480102
<ubot5> Launchpad bug 480102 in Launchpad Bazaar Integration "assert len(tview) == tview_len (affected: 15, heat: 96)" [High,Fix released] https://launchpad.net/bugs/480102
<vila> sender: said to be fixed in bzr-svn 1.0.4
<sender> vila: great, i was looking for the fixed version info... going to try this.
<sender> vila: hmm ubuntu did not update its packages yet. Will see how I can override the version.
<vila> sender: you can use the bzr ppa which always carry the stable versions of bzr and some plugins (including bzr-vsn)
<vila> sender: https://edge.launchpad.net/~bzr/+archive/ppa
<sender> vila: that sounds excellent
<vila> sender: which OS vesion ?
<vila> rhaaa, which Ubuntu release I meant
<sender> vila: Ubuntu Lucid Lynx, 10.04
<sender> vila: with what argument do I run sudo add-apt-repository?
<vila> sender: right, so given the policy there, the stable ppa is your best bet
<vila> 1101qr51
<vila> lol, sry wrong window
<sender> vila: password for your breadtoaster? ;)
<vila> sure, try it :)
<awilkins> sudo make-me-a-toasted-sandwich
<sender> lol
<vila> sender: I think it's ppq:bzr/ppa
<vila> ppa:bzr/ppa
<vila> sender: if the password doesn't work it's because I made yet another typo in it
<sender> vila: thick fingers? ;)
<sender> vila: this looks good: bzr-svn/lucid upgradeable from 1.0.2-2 to 1.0.4-1~bazaar1~lucid1
<vila> yup
<vila> sender: not really, I've lost 20 pounds in the last year :D
<vila> sender: I just... make typos, it's... tied to my very first contact with bzr, I don't even try to cure it any more, I just try to minimize the fallouts :)
<sender> vila: :D
<vila> sender: hint: HHTPS_PROXY is not how you configure a proxy :D
<sender> vila: well, actually there should be some typo-forgiving feature to configuring a proxy ;)
<sender> vila: too bad the update didn't solve this issue. I still have a pending restart in Ubuntu... maybe that's related
<vila> hehe, sudo cat "hht\t80/tcp" >> /etc/services
<vila> sender: did you read the bug report ? There may be more steps involved ? (I don't know the details, I've just seen reports that seem similar to yours)
<vila> sender: so, run with '-Derror' to ensure you get a similar traceback and check with 'bzr plugins' that you got the right version
<sender> vila: svn 1.0.4
<vila> sender: good, and the traceback ?
<sender> vila: didnt & should. Cant wrap my head around it being broken all of a sudden.. With -Derror: http://pastebin.com/wQ3DB4xe
<vila> sender: bingo
<vila> https://bugs.launchpad.net/bzr-svn/+bug/336467 may help more ?
<ubot5> Launchpad bug 336467 in Bazaar Subversion Plugin ""AssertionError: base checksum mismatch" with svn-import (dup-of: 480102)" [Low,Triaged]
<ubot5> Launchpad bug 480102 in Launchpad Bazaar Integration "assert len(tview) == tview_len (affected: 15, heat: 96)" [High,Fix released]
<vila> sender: it's a dupe but it's said there that you may need to clear the ~/.bazaar/svn-cache
<vila> sender: read it, I'm not a bzr-svn user myself so I don't really know if it applies to your case
<sender> vila: ok, thanks. I'll start with a reboot as ubuntu is nagging me for that anyway, and silently I have hope that this will be solved...
<knighthawk> I'm working with svn for the rest of my team but I think I want to keep a personal bzr repos on my system. I'm hoping bzr-svn and bzr-rebase can help me with this. But I'm *very* new to bzr and pretty new to version control in general anyone have a resourse that would explain the workflow I'm looking for?
<knighthawk> also any suggestions on using bzr inside of Zend Studio?
<dash> knighthawk: no need for rebase
<dash> knighthawk: just install bzr and bzr-svn
<dash> then 'bzr co http://svn-server/svn/your-repo/trunk' or whatever
<knighthawk> thanks dash
<LeLutin> hello
<LeLutin> I'm wondering something: commits in Bazaar have a unique identifier (roughly e-mail + hash). is there a way to obtain such a unique id for tags?
<fullermd> No, they don't have one.
<LeLutin> fullermd: oh I see. thanks.
<LeLutin> I'll have to come up with something a little bit more arbitrary, then for this new bzr-fastimport bug that I found today :\
<vila> LeLutin: there is a revid associated with each tag but otherwise a tag is just a name
<knighthawk> anyone know if you can use bzr-rvn with bzr-eclipse? or am I just buying trouble?
<dash> i use bzr-svn with eclipse.
<dash> the eclipse plugin does very little, i mostly use the command line or emacs
<knighthawk> thanks again dash
<LeLutin> vila: yes, I'm thinking of using something like tag_name:revid.
<LeLutin> well, thanks for the info, fullermd and vila
<LeLutin> vila: do you know if the function in bzrlib that creates unique ids for commits is able to generate an id from an arbitrary string?
<roryy> bug 202374 has been fixed asof r5455 - should i change it's status from in progress to something else?
<ubot5> Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 3)" [Medium,In progress] https://launchpad.net/bugs/202374
 * awilkins sends an application for the job in the topic and wets himself with anticipation at receiving an automated response
<peitschie> morning everyone
<poolie> hi there
#bzr 2010-10-07
<spiv> Good morning.
<poolie> hi there spiv
<spiv> The cold seems to have mostly subsided today, thankfully.
<peitschie> poolie: do you know much about bzr reconcile behaviour?
<poolie> that's great
<poolie> peitschie: a bit, what do you want to know?
<peitschie> poolie: i've been running into issues where the canonicalize-checks take around 20hrs to run over my repository at work
<peitschie> i was trying to come up with some ways of speeding things up a bit
<peitschie> i did notice that the process seems to be very heavily cpu bound... but it's only single-threaded
<peitschie> as far as you know, does reconcile require sequential repair work (i.e., the next revision requires all previous revs to be fixed) or are chunks of it disconnected (i.e., multiple revs could be farmed out to be repaired by each core and then updates sequentialized back to the main thread)?
<poolie> normally you should only need to run it to recover from a previous problem?
<poolie> did someone or some program actually tell you to run it?
<poolie> i think it probably could be parallelized
<peitschie> poolie: at the moment I'm still trying to recover from https://bugs.launchpad.net/bzr/+bug/522637 and https://bugs.launchpad.net/bzr/+bug/485601
<ubot5> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 96)" [Low,Triaged]
<peitschie> poolie: I ran reconcile last weekend, but found someone checked in on monday without getting the "reconciled" repo... which broke things again
<peitschie> poolie: because of the amount of time it takes to run things, I don't have a big enough space to really do a full reconcile during the week, as it takes a full day to do it :)
<peitschie> it's one of the things I think is important to a corporate environment... any repair job needs to be able to happen over night
<peitschie> because I know programmers a not infallible, and there is always a chance there will be another repo-breaking bug...
<peitschie> i've been considering spending some time trying to speed up reconcile, so recovery from future bugs of this nature can be achieved during the working week without stopping all dev work during the day
<poolie> :?
<poolie> yuck
<poolie> one good way to start might be to be able to select particular types of reconciliation to do
<peitschie> yep... those were some of the other things i was going to look at
<poolie> similarly for check for that matter
<peitschie> i figured a lot of time is likely spent calculating sha's and similar tho as well... so if I can potentially just multi-thread *that* part slightly, I think there might be a reasonable gain to be made
<peitschie> I started playing with some profiling last night to see, so I don't really have any clear ideas on it yet :)
<peitschie> but just thought i'd ask in case you were aware of much around it :)
<peitschie> the other thing i'm considering is how we might potentially be able to generate more useful debug information for the previously listed bugs as well
<peitschie> in the case of both of those, they have proved exceedingly hard to track down and verify because of the requirement of having it occur on a publically available repo
<peitschie> again... i have no real plans at this point... just pondering some things that would make my adoption here a little less risky a prospect
<poolie> mm, again maybe having a task-specific check output some non-sensitive debug data would be good
<poolie> it's a bit hard to predict ahead of time what would be useful
<poolie> but it is possible
<peitschie> i figured that there is always some things taht would be missed
<peitschie> i'm wondering if perhaps dumping things like revision history, sha's, ancestry... i.e., mainly the repo and branch histories might be sufficient to get a head-start
<peitschie> my thought is to try and work out what info would have helped track down the previously listed bugs... see how hard it is to produce... then potentially wrap that up in a command/tool of some sort (potentially even as part of check)
<poolie> that would be good
<peitschie> so even if we don't get everything next time, *hopefully* future issues like these (that seem to revolve a bit around shared repo => shared repo) might be a bit easier to track
<dOxxx> Good evening.
<dOxxx> Anybody here know about bzr-explorer internals?
<poolie> hi there
<dOxxx> In particular, the way it invokes qbzr commands?
<poolie> not a lot, but what's up?
<dOxxx> I'm working on my mergetools thing and it looks like explorer is using my system installed bzr to run qbzr commands instead of the dev version of bzr that I invoked explorer with.
<dOxxx> So I get an ImportError because my qbzr references a module (mergetools) which doesn't exist in bzr 2.2.0
<dOxxx> but which does exist in my dev bzr
<poolie> hm, interesting
<poolie> that sounds right
<poolie> hi, spiv, so what are you up to today?
<dOxxx> poolie: what sounds right? that it uses the system bzr to invoke qbzr?
<poolie> i mean, that sounds like a correct diagnosis, but i agree it's a bug
<poolie> it should use the matching version, i would say
<dOxxx> poolie: http://paste.ubuntu.com/507655/ is the relevant section of bzr.log if you could double-check my diagnosis?
<dOxxx> I'll be damned if I can think of how to search for this bug to see if it already is known :)
<poolie> i don't recall hearing of it
<poolie> dOxxx: i think there is a bzr symbol to find the right executable
<poolie> because the tests do the same thing
<poolie> i'd just file a new bug; we can always dedupe later
<dOxxx> I thought I remembered some discussion about it on the bzr mailing list in the last month or two.
<dOxxx> yeah I'm typing up the bug now
<spiv> poolie: so far mainly catching up on a week's worth of email
<poolie> oh, wow
<poolie> it has been a while
<poolie> good luck :)
<poolie> dOxxx: if you want to talk about where the bug is or how to fix it just ask, otherwise i'll leave it with you
<dOxxx> poolie: no I'm good, just writing it up. :)
<spiv> Thanks :)
 * spiv -> food
<mkanat> Is there a plugin that will just run a particular external command before "commit"?
<lifeless> sure there is a externals hook plugin
<lifeless> or you can just trivially do a custom one yourself.
<mkanat> lifeless: Yeah, I figured it would be trivial, I just wanted to know if it already existed.
<poolie> spiv, what do you think we should do about news?
<poolie> one news file per series?
<spiv> I think so.
<poolie> do you want to split it up then, while you're there?
<spiv> I can do that, what's the exact path names you're after?
<poolie> hm, possibly we should just move it into doc/en now, and perhaps just leave a pointer in news?
<poolie> that would be similar to whatsnew
<poolie> and everything else
<poolie> s/in news/in NEWS in the root
<poolie> whatever we do, we'll need to update the doc builds rules
<spiv> Right.
<spiv> It would be nice to have something fairly visible in the root.
<spiv> But not nice to accumulate clutter for every historical release in the root.
<spiv> I suppose we could have the current series in /NEWS, and everything else in doc/en/old-news/*, but that feels a bit weird.
<poolie> istm just a pointer there would be ok
<spiv> Ok, phew :)
<spiv> I'll do that.
<vila> hi all !
<spiv> Hey vila!
<vila> spiv: Welcome back !
<vila> spiv: can I have paramiko package from your ppa for maverick with my pony ? Pretty please :)
<vila> *a paramiko package
<spiv> vila: hmm
<spiv> vila: I'm not sure at a glance why my last attempt to do so failed: http://launchpadlibrarian.net/52203585/buildlog.txt.gz
<spiv> (https://code.edge.launchpad.net/~spiv/+recipe/paramiko-test/+build/340)
<vila> spiv: the point is that there is only one test failing on babune for the maverick slave
<vila> ha, yeah, I forgot that, you mentioned it at the time though
<vila> spiv: sudo build-my-package ?
<vila> spiv: hmm, rather obscure... "they" did manage to build it for maverick so there should be a way...
<spiv> I'll hit the button again and we'll see what happens.
<vila> aptitude command not found ??
<poolie> hello vila
<vila> hey poolie, hopefully I'd feel better today :-/
<poolie> and do you?
<vila> well, so far, yes
<vila> but yesterday and the day before I went down without notice :-/
<fullermd> Maybe the universe is corrupted.  Look at the checksum?
<vila> quantic checksums make my head hurt, bad idea
<fullermd> Just pick a worldline where they don't.
 * vila facepalms
<vila> ouch
<fullermd> Also, don't smack yourself.  It hurts less that way   8-}
<spiv> vila: apparently it built and uploaded okay this time
<vila> fullermd: you should have said so earlier
<vila> spiv: yeah just noticed !
<fullermd> Well, I did.  You just heard me later.  Speed of light and all that, y'know.
<vila> fullermd: yeah sound travels slower than light around here
<fullermd> Naturally.  Sound is heavy.  Light is...  well, you know.
<vila> spiv: http://ppa.launchpad.net/spiv/packaging-test/ubuntu/dists/ not updated yet, I suppose I should wait a bit
 * fullermd cranks up his sound to compensate.
<fullermd> Luckily, nobody around minds if I do that at 0130   :p
<vila> spiv: ha right, the details at https://code.edge.launchpad.net/~spiv/+archive/packaging-test/+packages shows that it's still pending publication
<vila> fullermd: :)
<fullermd> (on that topic, I wish Youtube would sort out their 34/18 formats, so that one was consistently the better, rather than random, or even more often, one having sucky audio and decent video, and the other being the other way around :|  )
<mgz> hm, not sure whether to send this to the list or file a bug
<mgz> vila: can I request a full babune run on windows of a branch?
<vila> mgz: sure, just name it
<mgz> http://float.endofinternet.org/bazaar/bzr/hack_get_transport
<mgz> sorted out what from your leaks branch was causing me problems, but I'm not sure why it's not broken for other people, or the best way to fix it.
<vila> mgz: hmm, looks like your bandwith will suffer :)
<vila> mgz: push to lp next time ;)
<mgz> it's a five line diff, how badly can bzr... oh, are you not stacking?
<vila> mgz: nah, it's ok, I did branch it locally to look at it...
<vila> mgz: err, this fix changes what exactly (in behaviour) ? It looks like you're working around some import aliasing bug here
<mgz> ha, good guess. I'll post to the list.
<vila> mgz: note that the current approach is hackish, we should define a hook triggered when a transport *connects*
<mgz> that sounds like a good suggestion.
<vila> mgz: running: http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/
<mgz> thanks!
<mgz> okay, sent email.
<poolie> mgz, nice mail
<poolie> i thought there already was a way to disable laziness but imbw
<poolie> that babune report is great!
<mgz> to be fair on that front, by the time I realised it was lazy import causing issues not something else, I didn't need to test anything else
<mgz> it was the getting to that point which was the hard bit :)
<mgz> (so it may well be that I could have found a way to disable lazy import, if I'd thought to(
<mgz> ))
<mgz> poolie: can mgordan be added to the contrib agreement group? I landed his first branch already as I got cced.
<poolie> will do
<bialix> heya poolie, mgz
<poolie> hi there
<vila> mgz: you run finished: FAILED (failures=2, errors=3)
<mgz> not bad for a hack, and 45 mins rather than 77 is the great bit :)
<vila> mgz: I see to... what's the message... this test would have hang or something, right ?
<vila> s/to/no/
<bialix> bonjour vila
<vila> which means the leak fixes were correct except they didn't catch some import aliases right ? (I confess I focused on the ones in tests...)
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/190/ <- Took 1 hr 32 min on xp-32bits.local
<vila> bialix: hey !
<mgz> http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/ <- Took 45 min on xp-32bits.local
<vila> right, most probably the cause is that we don't wait for threads to finish anymore
<mgz> basically yeah, complete for fix and all the "thread ('127.0.0.1', 2265) -> ('127.0.0.1', 2263) hung" goes away
<vila> shudder
<vila> care to comment on https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 ?
<mgz> no. :P
<vila> I think I failed to convey some hard numbers about time spent to debug such obscure crazyness
<vila> anyway, thanks for pointing out the obvious fix, but that's still a hack on top of a hack, so we should implement a hook
<vila> I went out of steam on the subject at the time, may be we can pair on this ?
<vila> mgz: A most probably related topic being the test suite still can't be run on OSX because some sockets are still leaking, I will try your branch there
<poolie> vila can you try to help a bit with reviews/landings?
<poolie> i realize i'm pp and i've done some but it's still queued
<vila> poolie: yup
<vila> poolie: I think it's fine that PP ask for help when needed
<mgz> ^I agree merging namespaces can cause bugs like this, but it's also useful. I don't think we can coding style it away.
<poolie> hm, i just did a parallel test and got ebadf again
<vila> poolie: and I wonder if we should not *all* focus on getting the queue back into control, it's awesome to have so many contributions but it will collapse fast if we don't address them
<vila> poolie: for an https one ?
<poolie> vila, sftp actually, inside paramiko
<mgz> I'll happily have a crack at fixing this the right way, especially if you're offering help/
<poolie> running parallel=fork seems to be the only time my machine's fan spins all the way up :)
<vila> hehe
<poolie> it would probably be an even stronger effect on apple hardware
<mgz> vila's the one most in need of reviewing I think, you'll need to press gang someone else as well :)
<vila> poolie: sry I can't remember without a tracback, what's the failing test ?
<poolie> i appreciate yours
<spiv> I have a pselftest='selftest --parallel=fork' alias
<vila> spiv: tss
<vila> :)
<poolie> vila, for the ebadf thing?
<mgz> though neil's on a roll too.
<vila> spiv: bzr alias tss="selftest --parallel=fork" :-D
<vila> poolie: yup
<spiv> Hopefully now I'm back from a week of leave + virus I'll be able to help with the queue too.
<spiv> Help reduce it, rather than grow it, that is ;)
<vila> mgz: and you've helped a lot too, thanks for that
 * spiv -> dinner
<mgz> I still need a lazr.restfulclient reviewer if anyone can dig one of those up.
<vila> poolie: on a related note, we have an RT asking for an upgraded testtools on pqm that seem to be blocked by a desire to upgrade to lucid, I'm a bit lost about the whys here, can you summarize ?
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/656170
<ubot5> Launchpad bug 656170 in Bazaar "EBADF in paramiko during parallel selftest (affected: 1, heat: 6)" [High,Confirmed]
<poolie> vila, sorry, i don't know many specifics
<poolie> i know the GSAs are in the process of upgrading some boxes
<poolie> suggest you ask in canonical is
<vila> BIG RED FLASHING WARNING: lp read-only
<poolie> no warning?
<vila> poolie: ha, that one, but it doesn't make the test fail right ?
<spiv> IIRC when I asked spm last week the RT wasn't blocked, merely some way down the queue?
<vila> it's been announced, but I lost a bug report yesterday, so I'm warning others ;)
<vila> poolie: I'll comment on the bug, but roughly, yes, it's a bad timing, but no it's really a bug
<vila> poolie: the fix would be to catch the exception like we do for our threads, but this one is private to paramiko and injecting our class here can't be done cleanly, so it's way down my TODO list and I would even make the bug importance a wishlist, the test doesn't fail
<spiv> vila: i.e. the bug is (partly?) in paramiko?
<vila> spiv: hmmm, IMHO, the bug is partly in python: there should be a simpler way to handle exceptions in threads than redefining the Thread class
<vila> spiv: and a way to kill a thread by throwing an exception too (and a pony)
<vila> spiv: that won't give us a direct way to tell paramiko to ignore EBADF for its threads either though, but that will become easier
<vila> the problem here is that we want to ignore this exception before stopping the thread but *not* when starting it
<vila> mgz: so the idea for the hook is that we want to replace the hackish overideAttr with a hook that will do roughly the same thing: keep track of the transport and disconnect it when tearing down the test
<spiv> vila: you don't need to subclass Thread
<spiv> vila: you just need to wrap the function you pass as the target
<vila> there is more than one way to do it :)
<spiv> vila: unless you mean monkey-patching the threading.Thread globally to change the behaviour of *all* threads... which seems risky.
<vila> spiv: the most convenient is to be able to say to a running thread: from now on, swallow these exceptions
<spiv> I mean, it is a bit weird to me that the main thread has sys.excepthook, and the other threads don't.
<spiv> Just because it's inconsistent.
<spiv> (Or does sys.excepthook intercept unhandled exceptions from all threads...?)
<vila> interesting approach...
<spiv> (Nope, it doesn't.)
<vila> too bad :-/
<spiv> But anyway, in principle you don't need any special facility to deal with top-level exceptions.  You can already write "try: ...; except: top_level_exc_hander()" at the top-level of the code.
<vila> spiv: for a third-party library ?
<spiv> Well, how a 3rd-party library runs its threads is ideally its own business.
<vila> hehe
<spiv> It's like how you can't really add logging to a 3rd-party library from the outside
<spiv> Either it already does that (and ideally allows you to have some control over where/how much it logs), or it doesn't and you need to get it fixed upstream.
<vila> spiv: right, in this sense, yes, this could be seen as a paramiko bug, but given the time it takes for your fix about the wrong address families to be taken into account, I'm not holding my breath for something that impact only tests :-(
<spiv> vila: well, being clear about the causes and deciding what to do about the problem given the circumstances are different issues.
<spiv> vila: maybe there's a workaround we ought to do, but that doesn't magically make it not paramiko's fault :)
<vila> well, paramiko rightly raises the EBADF exception, *we* want to be able to ignore it in *some* cases and even there, we change our mind *after* asking paramiko to start its thread
<vila> that's the cause
<vila> there is indeed more than one way to deal with it
<vila> and like the other problems encountered with the leaks, the fact that we run the server and the client in the same process is something that hasn't been taken into account in the design
<vila> it works better for paramiko than for SocketServer though
<spiv> vila: the bug isn't that paramiko raises EBADF, it's that it spews it to stderr rather than giving the app a chance to know about it.
<spiv> Probably the obvious thing for paramiko to do would be log the exception.
<vila> spiv: well, if I was the paramiko author I could answer: hey, that's Thread that is spewing on stderr :-P
<spiv> Seeing as it already uses the logging module.
<spiv> Sure, that's the mechanism.
<spiv> But that doesn't make "unconditional spew on stderr" the right behaviour for a library.
<vila> and whatever happens in this thread is supposed to be conveyed to the user via the channel object (or whatever, don't remember the details)
<spiv> (Especially given that in general paramiko takes a fair bit of care to use logging rather than unconfigurable spew on stderr)
<vila> spiv: my suspicion is that reproducing this without running the server and the client in the same process is non trivial (if possible)
<spiv> Sure, I'm not arguing about that point.
<Glenjamin> do you know where abouts in the paramiko code it's printing directly to stderr?
<spiv> (In fact, if robey had encountered it himself already I bet he'd have fixed it to be suppressed or logged, rather than let the Python threading bits spew it to stderr)
<vila> Glenjamin: lol, nowhere in this specific case, it's a side effect of using a thread and having an uncaught exception bubbling up to the top level
<Glenjamin> that sounds broken
<Glenjamin> the thread's exception has nowhere to bubble up to, and can't kill the master process i guess?
<spiv> It doesn't kill the main thread, no.
<spiv> The Python VM just writes a traceback to stderr when an unhandled exception happens in a thread.
<spiv> So if you don't want that, make sure you never have unhandled exceptions in your thread.
<vila> well, that's my main grief against python threads, the interpreter takes a great care to handle them but the exception handling is left to the user, requiring him to be ready for it in the function given to the thread
<spiv> Which isn't that hard, really.
<Glenjamin> So the only fix is to wrap the thread contents in an except block
<spiv> vila: I really don't see the difference with the main thread
<vila> well, the exception in the thread is not propagated there for one
<vila> so if you change your design to use threads your callers are suddenly doomed
<spiv> Propagated where?
<spiv> They have a separate call stack, that's kinda the point ;)
<vila> I started a thread, I want a simple mean to know that something bad occurred
<spiv> vila: you started the thread, so you can
<spiv> vila: just pass in a function that reports that
<vila> mgz: wooohhoooo, yeeeehaaa, test suite passes on OSX ! Pfew, my last attempt was depressing, I thought there was some more unknown leaks...
<vila> spiv: that's not simple enough, see my previous point: callers have to care now
<spiv> It's not hard to write a generic wrapper ("try: foo(); except: report_error()") to help you
<mgz> vila: you're better than you thought you were :)
<vila> mgz: yeah, something like that ;)
<mgz> spiv: isn't the problem that it's not "you" it's paramiko, and we can't raise the maintainer currently anyway
<spiv> So that your start thread call becomes Thread(target=err_wrapper, args=(func,)) rather than Thread(target=func)
<spiv> Which isn't exactly onerous.
<vila> spiv: and you also need to provide this to the caller which itself, etc
<spiv> I mean, it would be nice to have it more convenient.
<vila> exactly
<spiv> Perhaps even have Thread.get_result that blocks (i.e. calls join), and then either returns the value the target func returned, or reraises the exception it terminated with.
<spiv> (And in Twisted, you can use blockingCallFromThread for something like that)
<mgz> ..or are we on testing now, not the EBADF bug?
 * mgz went off to get food
<spiv> But it's really not hard to roll your own :)
<spiv> mgz: right, the problem is in paramiko, that's my point :)
<vila> mgz: and I argue that paramiko can point the finger at python :)
<vila> ThreadWithException was my answer for bzr :)
<spiv> Eh, it can point the finger at python for making it merely simple, rather than trivially easy.
<vila> ..where the exception is re-raised by join()
<spiv> So pardon me if I don't consider that a great excuse :)
<vila> spiv: well, if you require all thread users to implement such a mechanism, why not implementing it in thread ?
<vila> spiv: the try/except/finally is not always enough, you also need a guarding event in most cases and this event should be set to ensure the caller is not blocked
<hrw> hi
<vila> mgz: to be precise, there are still 3 failures on OSX (plus some tweaks of LC_ALL) but at least it *completes*
<vila> mgz: which is *huge* from my POV :)
<spiv> vila: the standard library has many deficiencies
<spiv> vila: this is just one of them :)
<hrw> I have been trying to use git-bzr-ng plugin to get two way git<>bzr bridge so I will not have to learn bzr and can use git for it. clone works but push works only if there were no changes done. push with change ends with http://pastebin.com/XA8LJgVv reported.
<hrw> can someone look at pastebin and comment?
<hrw> it works when changes are pushed to new bzr branch but not when pushed to existing one
<vila> hrw: by git-bzr-ng you mean bzr-git ?
<hrw> no
<vila> hrw: and you seem to be using bzr-fast-import...
<hrw> http://github.com/termie/git-bzr-ng/
<hrw> git-bzr-ng uses bzr-fast-import in backend
<hrw> bzr-git is to get git repo in bzr. git-bzr-ng is to get bzr repo in git
<vila> hrw: why don't you try to use bzr-git instead ? I never heard about git-bzr-ng so I'm not sure you get a lot of answers in *this* channel...
<hrw> vila: http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/ summaries my feelings about bzr
<hrw> vila: in short: I do not like bzr.
<vila> hrw: I'm not discussing whether you like bzr or not, just trying to point you to the right place to get the right answers
<hrw> sure
<vila> but coming here saying that don't like what we do doesn't sound like the best start :) Welcome anyway
<hrw> I know - just wanted to ask for help to understand where from error comes.
<vila> the traceback tells it's from fast-import, try adding BZR_PDB=1 in front or your command and poke at parts and self_git_to_bzr_name for a start
<hrw> thx, will check in few minutes
<mgz> vila: to be clear, mac osx needs hack_get_transport to complete, or have you just not tried since your previous fixes?
<vila> mgz: I tried with my fixes, the hack is needed, so the remaining leaks were caused by calls to the original get_transport, defeating the override
<mgz> ha.
<vila> mgz: I ran with the hack and a live open-files windows and I never seen such a clean run :)
<mgz> yeah, we're getting there!
<mgz> a bit more chipping away and we'll have a clean suite on all the platforms we try and support
<vila> your hack ensures get_transport is properly overridden so it validates all the fixes, I just wished I thought about it myself ;)
<vila> the bit I don't get though, is why this made such a huge difference between windows/OSX on one side and all the other on the other side...
<mgz> I'm just answering poolie's question on the list, my understanding is it's how the different socket libraries work
<vila> and no cheap joke about proprietary softwares leaking resources :)
<vila> mgz: oooh, let's try it on FreeBSD
<mgz> and naturally that the tests are written by people on nix, so when there are problems there it's fixed before it ever lands
<vila> in the *socket* library...
<mgz> windows at least has diverged rather from its start, not sure what osx uses.
<mgz> but still worth seeing if we get a speed up on freebsd
<txdv> awesume
<txdv> git-bzr-ng - ill have to check it out
<vila> mgz: yup, that's the idea
<mgz> I want to know what the ng is for. Does it do time travel into the victorian age as well?
<txdv> there is already some git-bzr hack, so he wanted to make it sound new and cool
<vila> hrw: Your post is not very specific about what is missing in bzr, filing bugs at https://launchpad.net/bzr/+filebug would get you more attention and better hope that we address your needs
<hrw> ok
<txdv> it's missing a proper remote managing interface
<mgz> the stuff you said in here the other day was actually more enlightening
<txdv> those half backed branches which are tied to remote branches are buggy as shit
<mgz> you were trying to adapt your git-y workflow to bzr and struggling
<txdv> i can adapt to new bzr'ish workflows
<txdv> no problem
<mgz> that was aimed at hrw, but either way.
<mgz> hacking up a giant change then splitting it into little bits to merge on the current trunk isn't something bzr supports particularly well, but there are ways
<Glenjamin> hrw: re: your blog post - the first link on related is a similarly exasperated post about git from 3 years ago (which i presume is when you started using it)
<hrw> Glenjamin: yes, related posts are often crazy
<Glenjamin> my point being, maybe you'll get used to it :)
<hrw> who knows.. maybe in 2014 I will use bzr more often
<mgz> heh, good point Glenjamin. I do "graaa, new thing I don't want to adapt to" all the time.
<Glenjamin> for instance, I wouldn't generally try and re-organise a patch before trying to get it upstream, i'd just supply a mergable branch
<Glenjamin> but presumably cleaning up a patch like this is common in git
<mgz> yeah, it's standard workflow for a bunch of projects.
<Glenjamin> my assumption is the reviewer would look at the final diff
<vila> mgz: 22min on FreeBSD, nothing spectacular nor unseen
<vila> unless
<vila> no, parallel=fork in both cases
<DaffyDuck_`> Hello
<mgz> the slowness there does seem to be a little all over from disk access rather than lots in smart server tests, so shouldn't be suprised
<DaffyDuck_`> I had some breakage in a repository earlier today, so I thought I'd take the opportunity to upgrade bzr to 2.1.2 (on Windows).
<DaffyDuck_`> With the previous (2.0.0) version I got a bazaar directory with a bzr.exe file, but with this new version, I have not bzr.exe.
<DaffyDuck_`> ..and not bzr.py along the path.
<DaffyDuck_`> Do I need to do some post-installation set up to get a command line "bzr" in Windows?
<mgz> okay, #1 did you use the right installer? and #2 were there any error messages during the install process?
<DaffyDuck_`> No error -- and I'm certain I used the correct installer.
<DaffyDuck_`> Oh, just found it. I think. There's no dedicated bazaar directory any longer, but it has placed a bzr.bat under c:\python26\scripts.
<DaffyDuck_`> I assume that's what I'm supposed to use instead.
<mgz> called -setup.exe rather than .win32-py2.6.exe right?
<mgz> okay, so you did use a different installer.
<DaffyDuck_`> Hmm.. I wasn't aware there was more than one. :)
<mgz> that's fine (and often actually preferable if you have python installed anyway), but you do need to add the scripts dir to your path manually for some reason
<mgz> the actual python installer should do it for you really.
<DaffyDuck_`> So the *-setup.exe contains a full python installation too?
<mgz> it does.
<mgz> and various bundled plugins as well.
<DaffyDuck_`> Hm.. Seems overkill since I already had it. Well, that's one mystery less.
<DaffyDuck_`> Well, time to get back to work. Thanks for the clarification.
<vila> meh, I meant 2.2.1 not 2.1.2 right ?
<mgz> you typoing release notices still vila? :)
<vila> errr, *he* meant, DaffyDuck_
<mgz> nope, I think they really meant 2.1.2 as was upgrading from 2.0
<mgz> and had done it long enough ago not to remember the installer looked different last time.
<vila> shudder
<mgz> okay, so about this hook.
<mgz> we want something that runs just before an actual connection is established?
<vila> or just after ?
<mgz> or a generic transport setup thingy?
<vila> no, I think at connection, so that it gets called if we re-connect too
<vila> both pre and post can be useful, but I think we want post first
<mgz> currently I see there's no one connect method like the disconnect you added, instead it's all connect_something
<vila> right, unifying this may come later, since we're talking about connection, the hook may be specific to ConnectedTransport, but generally adding stuff there is not worth avoiding adding it as unimplemented as the Transport level
<vila> I mean, define the hook at the Transport level even if it's called only by ConnectedTransport
<vila> And ConnectedTransport defines _set_connection that should be used by all relevant classes as part of their connect_something
<mgz> hm, yeah, after the connection has been established
<vila> yes, post_connect
<vila> spiv: ......and lp finally made your maverick package available, I installed it on the babune slave which turned blue for the first time. Pfew, just in time ;)
<sender> bzr-svn is giving me problems since a day, bzr pull https+urllib://svn.uitburo.nl/Website/trunk barfs at me: http://pastebin.com/PZUuaHyU
<sender> Bazaar (bzr) 2.2.1 / svn 1.0.4
<sender> Ideas are very welcome
<sender> :)
<maxb> hmm
 * maxb tries
<maxb> oh, private repo
 * maxb shrugs
<maxb> sender: Your subvertpy version is what?
<maxb> (dpkg -l python-subvertpy)
<sender> maxb: thanks! 0.7.3-1ubuntu0~bazaar1~lucid1
<maxb> hmm. That's recent
<sender> It broke yesterday 'all of a sudden', I was using svn 1.0.2, and upgraded.
<maxb> In that case, there's a fair chance you've found a bug somewhere
<maxb> Is this repository proprietary/confidential?
<sender> maxb: well, yes. nothing changed on the repository side...
<maxb> nothing, other than new revisions?
<sender> maxb: that's right
<jelmer> sender: can you try a clone into a fresh repository ?
<sender> jelmer: so you mean locally, using bzr branch? or using svn?
<jelmer> sender: using bzr branch, but cloning into a fresh repository, not reusing your existing local branch.
<sender> jelmer: ok, understood. Trying now
<sender> jelmer: taking a while...
<sender> jelmer: do you think the local copy has corrupted in a way?
<sender> jelmer: bzr check dies with an error aswell..
<txdv> muahahahaha die bzr die
<sender> txdv: *grin*
<jelmer> sender: yes, older versions of bzr-svn had a bug
<sender> jelmer: too bad, error (dies) too
<jelmer> sender: same error?
<sender> jelmer: http://pastebin.com/nNebXdHE
<jelmer> sender: hmm
<jelmer> sender: can you try again but remove the cache for your svn repository first ? It should be in ~/.cache/bazaar/svn
<sender> jelmer: try the branch again?
<sender> jelmer:  rm ~/.cache/bazaar/svn/* -Rf ?
<sender> jelmer: ok, here goes again
<sender> jelmer: thanks for helping me out :)
<sender> jelmer: darn, it still crashes after a long time
<sender> jelmer: it even throws an ubuntu report the problem thingy, never seen that before. Oh and it complains that the problem cant be reported (typical...).
<sender> arg! how am I going to work with this repo again :S
<jelmer> sender: what error do you get this time?
<jelmer> still the same?
<sender> jelmer: what do you exactly want to know? bzr: ERROR: exceptions.AssertionError: 408 != 619
<jelmer> sender: so, the last resort is to try lp:bzr-svn and do the fresh clone again (with cache removed). If you can still reproduce it with that, plesae file a bug and I'll have a look at it tonight.
<sender> jelmer: ok, thanks. So I go: sander@ubuntu:~/.bazaar/plugins$ bzr branch lp:bzr-svn
<sender> Do I need to remove the package bzr-svn?
<sender> What version am I pulling in right now? So I can check with bzr plugins?
<sender> jelmer: are you Dutch :)
<jelmer> sender: bzr branch lp:bzr-svn ~/.bazaar/plugins/svn
<jelmer> sender: there's no need to remove the package
<jelmer> sender: jup, ik ben ook Nederlands :-)
<sender> jelmer: great, now bzr plugins gives me: svn 1.0.5dev :)
<sender> jelmer: locale hulp, fantastisch, zeer bedankt!
<sender> jelmer: dan zeggen die url's in pastebin je iets meer :)
<sender> jelmer: ok here goes again: bzr branch https+urllib://svn.uitburo.nl/Website/trunk uit-website
<sender> jelmer: unfortunately, an error again: bzr: ERROR: exceptions.AssertionError: 408 != 619
<sender> jelmer: :(
<Glenjamin> hrm, what's 619 in base 8?
<jelmer> sender: :-(
<jelmer> sender: can you try the whole process again after applying http://samba.org/~jelmer/fileids.diff ?
<sender> sander@ubuntu:~/.bazaar/plugins/svn$ patch -p0 < fileids.diff \ patching file revmeta.py
<sender> jelmer: ~/.bazaar/subversion.conf of any influence?
<jelmer> sender: no, that shouldn't be relevant - the cache is, though
<sender> jelmer: ok, applied patch, cleared cache, branching again.
<sender> jelmer: too bad. bzr: ERROR: exceptions.AssertionError: 408 != 619
<sender> jelmer: I don't know what could have changed..
<sender> jelmer: can I give you more information to work with in any way?
<jelmer> sender: can you at least file a bug about it on launchpad? It's clearly a bug that's still present in current bzr-svn.
<jelmer> sender: it would be interesting to have a look at the "svn log --xml --with-all-revprops -v" output of the revision that triggers this issue
<sender> jelmer: hope it's not a problem caused by corruption on the repository side... svn checkout seems to work fine
<sender> jelmer: how do I proceed to find the revision?
<jelmer> sender: I doubt it's a problem on the svn side
<jelmer> sender: if you run the command again but set BZR_PDB=1 in the environment it should put you into a python debugger
<sender> jelmer: I'm waiting for the svn checkout to finish, it's taking extremely long.
<sender> jelmer: I might as well start the branch while it's still running. So: export BZR_PDB=1; bzr branch https+url://svn.uitburo.nl/Website/trunk uitwebsite
<sender> jelmer: und jetzt?
<jelmer> sender: yep
<jelmer> sender: how much python experience do you have?
<sender> jelmer: virtually zero :|
<lvh> Hello :-)
<jelmer> hi lvh
<lvh> Can someon reccomend a code review tool for use with bzr?
<lvh> So far I've come across lp merge requests, which are super awesome.
<lvh> (I'm just scoping out what's available.)
<lvh> I've thought about doing code review as commits, since that makes it easy to programmatically verify as well
<lvh> (ie, stuff gets proposed for review, I add # XXX: No, fix this in the code)
<lvh> the only thing I can think of that would make merge proposals better is a side-by-side view like bzr qdiff or rietveld, but I suppose this is not the right place to suggest that
<jelmer> lvh: I don't have experience with the integration in other tools, but I know there's been work done to support bzr in rietveld and reviewboard
<lvh> jelmer: Yeah, bzr is supported in rietveld
<sender> jelmer: output is getting throttled
<sender> jelmer: zie je de output?
<poolie> hi all
<bzrnewb> hello. i'm planning on using bazaar for a single-user project but I have some questions about how it actually works. Anyone able to enlighten me?
<GaryvdM> bzrnewb: sure.
<GaryvdM> bzrnewb: Please don't ask to ask, just ask :-)
<GaryvdM> Hi poolie
<bzrnewb> cheers. I want to edit and maybe create my own scripts in Unrealscript for UDK. Everything is under a folder named src in UDK main folder and if I move it somewhere else the engine won't read them.
<poolie> hi gary
<bzrnewb> so if I set up a repository somewhere else how does it work with these files? are the files stored in repository or remain at the original folder but changes,  etc go to repositroy?
<peitschie> mornin all :)
<bzrnewb> repository*
<poolie> bzrnewb: (nice nick) there are basically two directories you need to know about
<poolie> there's the repository, which holds a bunch of pack and index files etc, which stores the history of the project
<poolie> and then there's the working tree, which holds the actual checked out copies that you can edit, run, etc
<poolie> in your case you just need the working tree to be under UDK
<poolie> perhaps the easiest thing is to just do 'bzr init' in that directory then the repo will be there too
<GaryvdM> bzrnewb: I would just "bzr init" in that dir. That will create the working tree and repo there
<poolie> then if you want to back it up, you can 'bzr push' from there to somewhere else
<bzrnewb> hmm can I select the entire UDK as the worktree and ignore the files/folders I won't need so I can only work with src files I want to edit.
<bzrnewb> but also include assets etc.
<poolie> yes
<GaryvdM> bzrnewb: Yes, with bzr ignore
<GaryvdM> or just add the files you do want.
<poolie> if you want to ignore most of it and just version a few files, i'd do
<bzrnewb> awesome. When I make a change in code does it store the original file somewhere else or does it just save a change history which I can do rollback. Just trying to understand if it will create loads of files for each change and pollute the UDK folder
<poolie> 'bzr ignore *'
<poolie> (or the equivalent in the gui) then add the rest
<bzrnewb> yeah I'll probably stick to gui for now :)
<poolie> it stores it into the repo dir, which in your case will be .bzr/repository/....
<poolie> in a database
<bzrnewb> I tried svn before bazaar and it was a bit complicated which is why I'm trying bazaar, but bazaar sounds a lot easier for single-user use.
<mwhudson> i would certainly agree with that
<bzrnewb> the whole server thing was overkill for what I'm intenting to do
<bzrnewb> does bazaar only support code comparison or can it preview/compare doc, excel and image files?
<bzrnewb> like perforce
<bzrnewb> or alienbrain
<GaryvdM> bzrnewb: bzr qdiff does compare images side by side
<bzrnewb> sounds like it's perfect for me. I'll set it up and see how it goes. Thanks for clearing things up for me
<GaryvdM> bzrnewb: You can use any diff tool that accepts 2 files with bzr diff --using alienbrain-diff
<bzrnewb> cool. I might come back if I run into any problems :) Cheers guys
<jam1> poolie: I'm heading out now, but I figured I would at least /wave at you
<poolie> hi jam1, thanks!
<poolie> have a good weekend
<jam> poolie: well, only Thurs here, but thanks for the day off :)
<jam> (yes, I plan on working tomorrow)
<poolie> i probably won't see you though :)
<poolie> so i'm just queueing up the good wishes
<poolie> i'm going for a ride tomorrow
<mwhudson> jam: hey, btw, can you run 'make lint' in lp-service?
<jam> mwhudson: I can before I push again, but not tonight.
<mwhudson> there's a bunch of irrelevant stuff, but the unused imports can be fixed at least
<mwhudson> jam: fair enough
<jam> (spent a fair amount of time getting pyflakes-vim working, since it seems to require a new python which requires a new vim, ...)
<mwhudson> argh
<jam> mwhudson: I'll probably be back around in another hour or so, would it be possible to work with you a bit and tie up any loose ends here?
 * jam really leaves for now
<mwhudson> jam: should be, give me a ping
<GaryvdM> mwhudson: Is there a way to get pydoctor to syntax a bit of example code? The rst docs suggest .. python::, but that does not work in pydoctor
<GaryvdM> *syntax highlight
<mwhudson> GaryvdM: uh, don't know off hand
<mwhudson> GaryvdM: you are using --docformat restructuredtext i assume?
<GaryvdM> mwhudson: Yes
<mwhudson> GaryvdM: and what does 'does not work' mean, doesn't highlight or errors?
<GaryvdM> mwhudson:  I assume that  --docformat restructuredtext is what is used for http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html
<mwhudson> GaryvdM: it is
<GaryvdM> mwhudson: Does not highlight
<GaryvdM> mwhudson: Ok, don't worry. I'll dig a bit myself.
<mwhudson> GaryvdM: if it's doing the highlighting with css it might be generating the appropriate output but pydoctor isn't including the necessary css?
<mwhudson> GaryvdM: view source should make that pretty clear
 * GaryvdM checks
<GaryvdM> mwhudson: nope.
<mwhudson> hm
<GaryvdM> mwhudson: I think that .. python:: is maybe a feature of spinx
<mwhudson> ah, that could be
 * GaryvdM tries to find where me read that
<mwhudson> but i'd really expect it to blow up in that case
<GaryvdM> mwhudson: Oh - It was in the eypdoc docs: http://epydoc.sourceforge.net/manual-othermarkup.html#colorized-snippets-directive
<mwhudson> GaryvdM: well pydoctor uses the epydoc routines to do the formatting, so i've no idea why that wouldn't work
 * GaryvdM tests if it works in eypdocs
<GaryvdM> mwhudson: Ah - It is working, but it dose not highlight much, and css missing. I try submit a patch for the css.
<mwhudson> GaryvdM: ah
#bzr 2010-10-08
<jam> mwhudson: I'm back
<mwhudson> jam: i hate twisted.conch
<jam> I'll go handle make lint, and then ping you again
<mwhudson> ok
<jam> mwhudson: can't say as I'm a huge fan :)
<jam> It doesn't seem terrible, but the adapter stuff is a bit "magical" for me, and the Interfaces would be interesting if they were actually a complete spec
<mwhudson> it's inheritance graph is a bit wonky, and it blurs the distinction between protocol and transport in confusing ways
<dOxxx> how would I print a stacktrace to the console so I can tell where a function is being called from?
<dOxxx> ah nevermind, I think I found what I was looking for
<jam> mwhudson: I think make lint is a bit overzealous. It seems to be finding a ton of stuff in files I didn't touch
<jam> Is it meant to only run on the local branch modifications?
<jam> (I saw it ask something about "bzr: pipes unknown command"
<mwhudson> jam: yeah, it's meant to do a st -r submit: and do it on the files reported changed, i think
<mwhudson> jam: so about the 'blocking' code you added to session.py
<jam> (it seems to use "bzr info | sed..." to find the parent branch, but my parent is 'devel' but I've merged 'db-devel' and all hell has broken loose
<mwhudson> jam: :(
<mwhudson> jam: maybe just run pyflakes on the files you know you've changed
<jam> bzr pull --remember ../lp-branches/db-devel seems to sort it out
<mwhudson> ah ok
<jam> still a lot of noise
<jam> (Makefile: line exceeds 78 chars, about 20 times)
<mwhudson> yeah, i saw that
<mwhudson> i don't think we care
<jam> and do we *really* want (foo, ) vs (foo,) ?
<dOxxx> GaryvdM: any idea why run_app doesn't do the appropriate bzr executable substitution but relies on callers to do so?
<mwhudson> gar, conch seems to conflate "a subprocess has been requested" with "a subprocess has been launched and is connected"
<mwhudson> which is a very non-twistedy sort of thing
<dOxxx> GaryvdM: this is in bzr-explorer, bug 656072
<ubot5> Launchpad bug 656072 in Bazaar Explorer "explorer should invoke qbzr with same bzr (affected: 1, heat: 8)" [Undecided,In progress] https://launchpad.net/bugs/656072
<jam> mwhudson: well, instantiating Process means it has forked
 * GaryvdM opens code
<dOxxx> GaryvdM: it seems like a logical DRY place to put it
<mwhudson> jam: yeah, but it makes it hard for us to do the right thing in our execCommadn
<jam> mwhudson: what do you consider "the right thing"?
<jam> I guess I'm not sure where you think we shouldn't be blocking? Because of _spawn connecting to another service to request the fork?
<mwhudson> jam: use twisted apis to do the communication with the forking service
<jam> mwhudson: right. And what you're finding is that "spawnProcess" wasn't a deferred, so we can't build up a new deferred based on responding to the socket interaction
<jam> Is that correct?
<mwhudson> jam: something like that
<mwhudson> well, it's not really "is a deferred", it's more that conch expects that by the time execCommand returns, it's ok to try to write data to the client
<mwhudson> er
<mwhudson> s/client/protocol/
<mwhudson> the thing is, there's _almost_ support in conch for doing the right thing
<GaryvdM> dOxxx: I agree that that makes sense, but I'm not sure that is the cause of the bug.
<dOxxx> GaryvdM: indirectly it is. the edit_config_file function which invokes qconfig doesn't do the bzr executable subsitution, thus it just executes "bzr qconfig"
<GaryvdM> dOxxx: Where do we call run_app with out using _get_bzr_executable?
<GaryvdM> Ah - ok
<GaryvdM> I agree with you then
<dOxxx> GaryvdM: and the bzr executable replacement is different at different call-sites.
<dOxxx> GaryvdM: for example, the tool menu uses qrun --ui-mode sometimes
<dOxxx> GaryvdM: hopefully I can make run_app handle all the cases
<GaryvdM> So maybe instead of having to call run_app(['bzr', 'qconfig']) make it so you just do run_app(['qconfig'])
<GaryvdM> DRY
<GaryvdM> dOxxx: ^
<dOxxx> GaryvdM: the tools menu can be anything, not necessarily a bzr command
<GaryvdM> Ah
<GaryvdM> def run_bzr
<GaryvdM> I don't actually know the BE code that well.
<dOxxx> changing the way the app suites like qbzr are defined and executed, i.e. if I were to create a run_bzr_app funciton would be a somewhat disruptive change
<dOxxx> I'm more inclined to make run_app more intelligent about replacing the executable
<dOxxx> it's a more localized change
<jam> mwhudson: (well, given that spawnProcess returns an IProcessTransport, but Process isn't one, and conch expects it to support .write() which isn't part of IProcessTransport anyway...)
<GaryvdM> ok
<dOxxx> I'll give it a shot and see how it goes
<mwhudson> jam: whee
<mwhudson> jam: it also turns out that twisted doesn't support connecting to a fifo
<jam> mwhudson: I don't know where, but before I implemented "def write" it didn't work
<mhall119> bzr is giving me connection errors trying ot use launchpad
<jam> mwhudson: it certainly does support it, read my code :)
<mwhudson> jam: "in a non blocking way"
<jam> mwhudson: it is non-blocking, using the "dataReady" stuff
<mwhudson> jam: os.open isn't!
<jam> mwhudson: it is selectable
<mwhudson> jam: but the open syscall itself blocks, doesn't it?
<jam> so while the specific read is blocking, it won't be requested until the file descriptor says it is ready
<jam> you can supply O_NBLOCK, but yes, it is blocking
<mhall119> bzr: ERROR: Connection error: while sending CONNECT xmlrpc.edge.launchpad.net:443: [Errno 111] Connection refused
<mhall119> anybody know what's going on with that?
<jam> (and you can't use O_NBLOCK for writing or it raises an exception, and if you do use it for reading it will force all future reads to be non-blocking)
<spiv> mhall119: http proxy issue of some sort
<jam> mwhudson: how, in twisted, do you actually open a file without blocking?
<mhall119> oh nevermind, tried the command in a new terminal and it worked....
<jam> hi spiv, care to join the lovely twisted conversation?
<mhall119> thanks spiv, but have some env variables set wrong
<mwhudson> jam: good question
<mwhudson> i think you don't basically
<spiv> jam: been reading along, but not much to add
<jam> s/conversation/bashing/ whatever :)
<spiv> Basically, mwhudson has been saying everything I would :)
<spiv> Twisted in general has no support for non-blocking local disk IO
<spiv> Because OSes generally don't support it, apart from "do it all in threads"
<LeoNerd> Mostly because it doesn't fit the POSIX F_NONBLOCK etc.. model
<poolie> hi spiv
<LeoNerd> Most POSIXes do have an aio system but it's generally not integrated with the rest of the IO nonblock primatives (select et.al.)
<LeoNerd> So it generally sucks
<spiv> LeoNerd: ...and is typically just "do it all in threads" under the hood anyway ;)
<LeoNerd> Er...
<LeoNerd> AIO is a real in-kernel system
<LeoNerd> Atleast, on Linux Solaris and *BSD
<LeoNerd> (and if you can name any other non-dead POSIXalike still alive today probably that too)
<spiv> Twisted programs generally assume that disk IO is "fast enough", which is often true for many use cases.  If it's not, well, threads, sorry :(
<mwhudson> jam: although these calls "block" in some sense, they're not very likely to block for a noticeable length of time
<jam> spiv: so I should be doing "callInAThread(os.open)" ? :)
<jam> mwhudson: well, if the remote process does something bad, they'll block forever
<LeoNerd> What is it you are open()ing?
<spiv> jam: sorry, I was off on a small tangent.  This isn't disk IO IIUC?
<LeoNerd> The problem is that most of this logic was thought through before things like NFS, CIFS, etc... started moving people's local-looking files to be not so local, and thus dependent on network latency just like anything else
<dOxxx> GaryvdM: looks like that's fixed it
<jam> spiv: it is connecting to the fifos for the newly spawned process
<jam> so 'disk-ish'
<jam> but open() will block until the other process has done the open()
<GaryvdM> dOxxx: Cool !
<LeoNerd> That's what O_NONBLOCK is for, but also, why opening an on-disk pipe rather than calling pipe(2) ?
<jam> so if the forking service dies in the middle, (after accepting and returning the path, but before the child process has forked and opened the fifos) then it would hang the Conch process indefinitely
<spiv> To share the pipe with a pre-existing process.
<dOxxx> GaryvdM: I'll remove the adhoc executable replacement at the run_app callsites except I think I'll leave the tool menu one alone since it does some extra funky stuff according to tool type
<dOxxx> GaryvdM: and since it will then be passing a executable which is not 'bzr' to run_app, it will just pass through the executable replacement logic I've added
<LeoNerd> Hrm.. Sharing ondisk pipes by more than one process each end doesn't sound too healthy; sounds like a recipe for mangled messages due to nonatomic write()s
<jam> the child can't open them before reporting the path, because... it blocks
<mwhudson> jam: but if the forking service dies, the conch process arguably becomes useless
<jam> which is actually a way we get synchronization
<jam> mwhudson: except for whatever processes are currently active, yes
<jam> and if we implement fall-back-to-regular spawn
<spiv> LeoNerd: *a* pre-existing process, not multiple :)
<GaryvdM> dOxxx: is _do_open_tool == ' tool menu one'
<mwhudson> jam: true
<LeoNerd> Ahh
<jam> which I asked spm if that was something we should be doing, but I haven't gotten a response yet
<dOxxx> GaryvdM: yes :)
<LeoNerd> Could you pass FDs over a UNIX socket? ;)
<dOxxx> GaryvdM: just looking at it now, I think I might be able to adapt it to work with the modified run_app
<dOxxx> GaryvdM: and still keep it's logic for using qrun
<dOxxx> its*
<spiv> LeoNerd: one bound to the filesystem? ;)
<LeoNerd> Sure
<LeoNerd> You can bind a UNIX socket to filesystem, then pass FDs across it
<GaryvdM> dOxxx: Yes, it's not that funky.
<LeoNerd> I'm surprised to this day there isn't a standard Linux service to do that anyway, so that e.g. ping could get an ICMP raw socket without having to bet setuid root... But now that's a complete tangent ;)
<mwhudson> using sendmsg, right
<spm> jam: yeah sorry; I'm not too good at 3am replies :-P
<dOxxx> GaryvdM: funky logic preserved :)
<maxb> LeoNerd: sysadmins around the world would curse you when they couldn't ping anything because their socketserver wasn't running :-)
<LeoNerd> maxb: Admins around the world already curse that the LVM2 userland tools aren't in the initrd so they can't mount their rootfs on boot, or 10,000 other sorts of weird interdependencies anyway
<LeoNerd> Personally I'd love not having to start a bunch of services as root just so they can bind() a port, thne drop privs.
<LeoNerd> E.g. apache could run -as- wwwdata and obtain a port80 socket from the socketserver
<jam> spm: lazy, lazy man :)
<spm> something ilke that
<jam> spm: I assumed you were in another time zone, just mentioning that it was a question in the queue, good to see you around, btw
<spm> heh
<jam> and thanks for participating in the discussion
<spm> fwiw, we can use the makefile. i think some of the soyuz services start that way. generally the twisted stuff is "funky" so we have to control it betterer
<spm> generally, you tell us "here guys, do THIS to make it go" and we'll make it happen
<spm> monitoring and alerts is a fun topic.
<jam> mwhudson: now make lint (cleaner)
<mwhudson> jam: great
<spm> Gist is: if you *need* a human to DO X to make it happy again; that's an alert state; if it's more "you should know about this" that's not. It may be a warning state; but oervwhelming us with essentially noise alerts is not a good thingâ¢
<mwhudson> jam: the stuff in _sendMessageToService can definitely be done in a more twisted way
<jam> mwhudson: it can, but in the end you want to block before returning....
<mwhudson> yeah
<mwhudson> that, and conch's interference makes me think we should be optimistic and assume the blocking won't be for very long
<jam> spm: well, there is a "functionality fallback activated, running at half-speed" alert that needs a human to fix it, and there is "fully dead"
<jam> if you don't distinguish them
<jam> then I won't bother trying to set it up :)
<spm> ha. no that's actually useful in a "this is broken (AAAA); but it's broken here vs totally" separation
<jam> spm: for a specific example, if the new service dies, we could fall back to the old code and it would be slower but working. But I don't want that state to remain for long, but "let the sysadmin do it when he wakes up" would most likely be fine
<spm> eg. if lpnet4 dies; that's bad; but we have lpnet1-15; so in the list of priority AAA's; lpnet4 being dead can be dropped in priority to focus on something more critical.
<poolie> LeoNerd: i agree about lvm2; in fact last time i tried a boot cd it wasn't there either
<spm> jam: do you mean dies, as in we'd manually flip back to an older revno? or some smarts in the code?
<spm> you seem to be impling code, but to be clear?
<mwhudson> i guess it depends where and how it dies
<jam> spm: currently both code paths exist, as part of a "feature flag rollout"
<spm> Oh I see!
<spm> mwhudson: :-)
<jam> if the conch machine can't connect to the forking service, it could switch code
<mwhudson> jam: heh, interesting: Under Linux, opening a FIFO for read and write will succeed both in blocking and non-blocking mode.  POSIX leaves this behavior undefined.  This can be used to open a FIFO for writing while there are no readers available.
<jam> mwhudson: not in my testing
<jam> at least the python one raises EAGAIN
<mwhudson> oh really?
<mwhudson> boo
<jam> I can open for *reading* with O_NBLOCK and it succeeds (but sets the descriptor to non-blocking mode)
<jam> writing will fail right away
<mwhudson> bah
<spiv> LeoNerd: sounds a bit like authbind, although I don't known which mechanism that actually uses.
<mwhudson> it's somewhat crazy that there are (lots and lots of) syscalls that block that don't take timeouts
<jam> I did spend a fair amount of time getting a handle on the various bits of this service in order to get it to work
<mwhudson> jam: yeah, if i'm implying otherwise
<jam> mwhudson: write(fd, 100MB) will block
<jam> that certainly surprised me
<jam> (I think I was testing with 1GB or so, and you can't even kill it, at least not with ^C)
<mwhudson> jam: if fd is a pipe and the pipe buffer is full right?
<jam> mwhudson: I'm not sure about with pipes for that one. that was for disk io
<mmclark> quick question - I'm looking for the bzr equivalent to hg's "outgoing" and "incoming" commands, which tell you what changes would be pushed or pulled to/from another repo.  Is there such a beast?
<jam> but yes, write() to a pipe when the pipe is full will block, too
<spiv> mmclark: 'bzr missing'
<jam> spm: so how would we tell nagios about the difference?
<mmclark> spiv: thanks much
<jam> or how could I make that information available to you so you can do whatever you want with it
<mwhudson> jam: did you consider doing the 'pass fds over the socket' trick?
<jam> mwhudson: the most recent change was switching from a port socket to an AF_UNIX one, and you can't do the socket trick until then
<jam> I'm not 100% sure what that would actually gain you
<mwhudson> well, it would get you away from having a potentially blocking open
<jam> mwhudson: I honestly think the hole is pretty small here. If we find it is serious, then we can do something about it.
<jam> remember that the service has to be running successfully until the exact point and then fail
<spiv> It leaves the FS a little tidier ;)
<jam> which is possible
<mwhudson> jam: right
<mwhudson> jam: i think you should land the branch as is
<jam> spiv: the fs stays tidy all the time, I delete everything fairly persistently (killing the master process and not connecting to the child you requested can trigger it, I guess)
<mwhudson> and then if we need to improve we can
<jam> mwhudson: well, I *do* need some help landing it, too
<mwhudson> jam: oh ok
<spm> jam: grab nagios-plugins* as a how did they do it starter; the gist is "we" predetermine that THIS is OK, THAT is WARN and everything else is CRITICAL. kinda thing. sometimes we want to adjust params. so eg, 0.5 secs was ok, but is now warn, and we crit on 0.1 sec response times.
<spiv> jam: "delete quickly" is still inferior to "never put on FS"
<jam> spiv: I thought the point in *nix was that everything was linked into the fs as a namespace
<jam> I mean otherwise, what is up with /proc and /dev
<jam> :)
<spiv> jam: those at least tidy themselves ;)
<jam> spiv: so does /tmp if you enable temp reaper, or let the master forker do it :)
<jam> spm: are you someone who can make it so that when I create branches of lp-production-configs they are private?
<jam> spm: and is nagios-plugins private as well?
<spm> jam: they should private by default (lp-prod-configs) and nagios-plugins is the default ubuntu packages
<jam> spm: they *should* but going to "code.edge.launchpad.net/lp-production-configs" tells me that by default the branches will be public
<spm> gawd I hope not.
<jam> for mwhudson I think it says private
<jam> for *me* it said public
<jam> yep
<jam> still does
<jam> (I can screen shot it for you if you like)
<mwhudson> i'm surprised it's not a private only policy
<mwhudson> in which case you wouldn't be allowed to make branches
<jam> mwhudson: which would at least be better
<spm> he's been manually subscribed. ??
<mwhudson> spm: to trunk?  yes
<jam> spm: I was manually subscribed to trunk
<jam> I at least had the forethought to wonder, and mwh showed me where to look
<mwhudson> jam: so to be clear, you'd like me to throw https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 at ec2 land?
<spm> yeah. everyone else picks it up via ~launchpad
<mwhudson> although i guess pqm is closing
<jam> mwhudson: well "lp:~jameinel/launchpad/lp-service", and make sure it is targetting db-devel, but yes, please
<mwhudson> jam: ok, i think we'll have to wait until after the rollout
<jam> *sigh* since I was trying to get it in before...
<mwhudson> (yay things getting in the way of development!)
<jam> but at least we could land it into 'devel' at that point
<mwhudson> jam: sorry
<mwhudson> i think we want at least a few weeks of battering it on staging
<jam> that's fine, but then again, that is what I was shooting for.
<mwhudson> (though i'm not going to apologise too much, it's not like i'm in launchpad-code any more...)
<jam> the flag should make it safe enough to deploy whenever
<mwhudson> right
<poolie> ok i'm going to try to set up a hottest100 bot
<poolie> on a web page, that is, not here
<jam> poolie: if I didn't know better, I would be really concerned
<jam> that certainly *sounds* naughty
<poolie> :)
<lifeless> jam: in .au thats a collection of songs each year ;)
<jbowtie> Looks like librsync can handle 25G binary diffs without eating all available memory. Maybe we should look at using it for very large files?
<mwhudson> GaryvdM: thanks for the branch :-)
<spiv> jbowtie: heh, I expect poolie knows a bit about librsync ;)
<GaryvdM> mwhudson: :-)
<poolie> jbowtie: that could be very good, i'd be happy to see about that
<poolie> ah
<poolie> there's no pure-python version but we could cope without that
<poolie> it might also make committing new versions faster
<poolie> it may compress less well than groupcompress... maybe...
<poolie> a naive use might be worse
<spiv> poolie: I'd guess it's at least partly "it depends"...
<jbowtie> poolie: I think it should definitely be considered for anything over, say, 250MB - that's where we start potentially breaking.
<poolie> it would be interesting to try a new repo format that way
<jbowtie> And is compression really an issue? Usually very large binaries are already compressed as far as they can go.
<poolie> the other alternative is to just store them loose or gzipped
<poolie> well, there is that
<poolie> but the question is, do these things change (a) basically never; (b) totally, with no similarity from one to the next or (c) incrementally
<poolie> if the first, you might as well store them unpacked
<poolie> and the second for that matter true
<poolie> b is likely to be true if they're already binary-compressed
<poolie> but isos or large databases are likely to be like c
<poolie> and there you do want delta compression
<jbowtie> Generally if they're in version control it's because you expect c.
<poolie> istm that in principle you could groupcompress c
<poolie> and the limits are in code, not the format or the basic design
<poolie> but perhaps not
<jbowtie> I don't know about b, there are a few fair compression formats that do most of the changes at the end of the file.
<jbowtie> I'm looking at, say, game development, where all the art assets are massive binary files. And you want to diff and merge those alongside the code.
<jbowtie> Right now you can't even check them in because you break the repository.
<jbowtie> And the memory usage for, say, merging looks totally unrealistic.
<jbowtie> You can kind of sidestep it for diff/merge if you dump to the filesystem, but commit ATM requires you to read in the entire file.
<poolie> hm, but it really shouldn't
<poolie> those apis are designed to deal with iterators of chunks
<poolie> obviously this is not being perfectly followed at the moment, but it should be a matter of adjusting them, not huge changes
<poolie> i'm off to get some lunch, biab
<vadi2> I upgraded to Ubuntu 10.10 and bzr gcommit fails to commit now: http://paste.pocoo.org/show/272521/
<vadi2> Is there anything I can do?
<spiv> vadi2: hmm
<spiv> vadi2: that paste only shows warnings
<spiv> What else happens, i.e. how does it fail?
<vadi2> It gives me a dialog of "Unknown error" when I try to press Commit
<vadi2> So the commit action fails. It doesn't crash or anything, dialog is still there, but the button is non-funtional
<spiv> Hmm.
<spiv> vadi2: using 0.99.0-1ubuntu1 of bzr-gtk?
<vadi2> uh huh
<vadi2> Installed: 0.99.0-1ubuntu1
<spiv> I can't reproduce here with bzr-gtk 0.99.0 and latest bzr 2.2 (I have bzr installed from the PPA, so I can't easily install that bzr-gtk package...)
<spiv> I don't get the warning, and the commit Just Works.
<spiv> Are there any tracebacks or other hints in ~/.bzr.log?
<spiv> Does 'bzr --version' and 'bzr plugins -v' report what you expect for bzr and bzr-gtk? (i.e. right versions, and using the system-wide installs?)
<vadi2> that file is big
<vadi2> no particular errors related to this time though
<vadi2> http://paste.pocoo.org/show/272558/
<vadi2> Both versions correspond to package versions
<spiv> Thanks for the screencast
<spiv> Hmm, I have a theory, I'll just test it.
<vadi2> Alright
<spiv> Ok, got it.
<spiv> Run 'bzr whoami' in the terminal
<spiv> You haven't told bzr who you are, so it can't commit because it has no committer name to record in the commit.
<vadi2> I did do launchpad-login!
<spiv> And so bzr raises an error, and bzr-gtk tries to display that error
<spiv> But because the error includes something that looks a bit like gtk-specific markup it breaks.
<vadi2> Thanks, it worked now. I guess that could be polished.
<spiv> So the warnings were relevant.
<spiv> Yes, definitely.
<spiv> I'll file two bugs
<vadi2> Thanks for your help
<spiv> One on bzr-gtk's handling of this error
<vadi2> RIght
<spiv> And another about the "I did do launchpad-login!" aspect: you had reason to expect that this was already sorted, and so we should clearly do better there
<vadi2> The other about whoami to be auto-set from launchpad-login if whoami isn't set yet?
<spiv> Right
<spiv> Well, auto-setting *might* be hard
<spiv> It could in principle use your name + email address as set in Launcphad
<vadi2> Yeah
<spiv> But I couldn't say off the top of my head if there's any impediments with the LP API
<spiv> And it probably shouldn't auto-set if you've already set it manually
<vadi2> Of course.
<spiv> ...but maybe it should warn if the LP info doesn't match the manual?
<spiv> etc :)
<spiv> So a few issues to think about to make it fully polished, but in principle it's a good idea and straightforward :)
<spiv> Thanks very much for the report
<vadi2> Sure, and thanks again for helping. See you later
<jbowtie> New  sphinx template nearly ready -- http://imgur.com/kmLGQ.png
<jbowtie> Just need to adjust the top navigation a bit and place the search box correctly.
<spiv> jbowtie: looks nice, although it looks completely different to the main website.
<jbowtie> spiv: In theory it will line up with the main website overhaul.
<jbowtie> spiv: It will of course live in a branch until that lands.
<spiv> *nod*
<jbowtie> Right now I'm just basing it off the Ubuntu branding guidelines, colors will ahve to be adjusted to whatever we actually end up using.
 * spiv -> lunch
 * poolie is going to fix the failures in his scriptrunner branch
<poolie> does anyone here at the moment have experience with the trac plugin?
<poolie> spiv, still here?
<poolie> can anyone spot why https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/35386 would cause a failure in test_delta?
<poolie> it seems totally unaffected
 * spiv looks
<poolie> it seems like i must be mutating some global state but i really can't spot what it would be
<poolie> it doesn't fail when only the affected tests are run alone
<spiv> poolie: wow, must be something obscure
<spiv> pastebin the failure?
<vila> then you're not going to find the problem without some bisection (at least that's how I found the isolation problems myself)
 * vila not there yet :)
<poolie> http://pastebin.ubuntu.com/508536/
<poolie> i just changed it to make that failure more obvious
<poolie> so i guess something is making the changereporter give the wrong results
<spiv> poolie: is_quiet I think is the likely suspct
<poolie> i see it does default to using trace.note and that could easily be staying intercepted when it shouldn't be
<poolie> something like that
<spiv> poolie: In fact I think it's almost certainly that:
<spiv> 1) because the only obvious behaviour change in your patch is to add -q to some calls
<poolie> so this test should probably get the results back as lines
<spiv> and 2) because bzrlib.trace._verbosity_level is a global
<poolie> mm i think so too
<spiv> oh, and 3) because report checks the global is_quiet() first :)
<spiv> vila: no bisection needed :P
<poolie> well spotted
<poolie> that's a bit gross
<spiv> Yeah.
<spiv> The bandaid I guess is to make TestCase reset it to some default every time.
<poolie> hm, so probably run_bzr should reset verbosity when it's done
<poolie> eventually we should get rid of it
<spiv> That's probably a good idea too.
<poolie> and thereby stop delta relying on it
<spiv> +1 for eventually get rid of it
<poolie> bug 656694
<ubot5> Launchpad bug 656694 in Bazaar "should delete global is_quiet/is_verbose (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/656694
<poolie> so just an overrideAttr on _verbosity_level in TestCase
<vila> poolie: yup
<poolie> probably run_bzr should be doing this too
<poolie> it shouldn't carry over from one command in a script runner to another
<spiv> Right.
<spiv> Although probably each run through the run_bzr machinery would set it?
<spiv> Yeah, Command.run_argv_aliases always calls trace.set_verbosity_level
<spiv> Oh, ew.
<spiv> Look at the _verbosity_level_callback in bzrlib/option.py
<spiv> The level of quietness/verbosity might carry over between commands.
<poolie> exactly, that's what i'm concerned about
<spiv> I don't know that we ever treat -vv differently to -v (or -qq vs. -q)
<poolie> i don't think so
<poolie> some programs do of course but i don't think we ever have
<spiv> But if we did, it's a clear problem :)
<spiv> Plugins hypothetically could, I guess.
<poolie> wow that is a bit of a messy
<poolie> *mess
<poolie> so, i think we should make sure it's reset after running a command
<poolie> then i'll try to land this, then maybe delete it entirely
<spiv> Anyway, to be strict, you have to deal with the global in bzrlib.option as well as bzrlib.trace
<poolie> yuck
<spiv> Yes, a lovely booby trap you tripped over there :(
<vila> poolie: I was willing to freeze bzr-2.3b2 *today*, as planned, any reason you want to delay that to next week ?
<vila> geez, where are my manners...
<vila> Hello all !
<poolie> :)
<poolie> we'll gradually defuse them
<poolie> and stop laying them for ourselves
<poolie> vila that's fine with me
<poolie> spiv, i hope you're feeling better btw
<vila> poolie: ok
<poolie> vila i think as much as possible releases should not cause disturb development, and ongoing development should not disturb releases
<vila> +2
<vila> poolie: you say that in general or in reaction to something recent ?
<poolie> in general
<vila> k
<vila> worth writing done somewhere
<poolie> not every project can actually do this but i think it's desirable to steer for it
<poolie> and we actually get pretty close
<vila> yup
<vila> on both counts
<poolie> you can add it to the RM docs while you're in there :)
<vila> poolie: hehe, just did so with big XXXXX until I settle on where this goes
<poolie> ok, https://code.edge.launchpad.net/~mbp/bzr/656694-verbosity/+merge/37933 removes the coupling
<vila> poolie: please land
<poolie> i really hope to get tarmac up soon so we don't need more than just approval in the ui
<poolie> maybe next week
<spiv> poolie: yes, finally
<spiv> poolie: the only drug I needed today was caffeine, which doesn't require visiting a pharmacy :)
<spiv> poolie: Also another +1 from me on your release philosophy
<poolie> thanks
<poolie> you don't want any more dependencies or blocking than you need
<poolie> spiv would it be too crude in http-messages just to truncate in the unhtml thing?
<spiv> poolie: I don't think so
<spiv> Well, it's no cruder than what you're already doing :)
<vila> poolie: fine with me (agreed with spiv, what you're doing is already crude)
<poolie> would our http tests make it easy to test this? probably
<spiv> Hopefully!
<vila> poolie: If I need to debug from there, I will dive in the code and modify it to suit my needs, having a rough idea of what is already reported by the server is good
<spiv> poolie: btw, seeing you add a tech-debt tag to a bug reminded me of this: http://compoundthinking.com/blog/index.php/2010/10/05/technical-debt-isnt-always-debt/
<spiv> (Not because of the specific bug, just because I thought it mildly interesting)
<vila> poolie: I'm not sure the http tests ever tried to match the bodies, expect for the recorded ones
<poolie> :)
<poolie> i don't think 'debt' is a very good word for it
<poolie> it's more like friction
<vila> yeah, you should address them when they start itching too much
<vila> spiv: did you start working on splitting NEWS ?
<spiv> vila: yep
<vila> spiv: oh, and did you see maverick turned blue on babune thanks to your paramiko package ?
<spiv> vila: I did, thank you!
<vila> spiv: great
<spiv> vila: My NEWS split branch is probably 80% done, but it's just struck weekend-o'clock here.
<vila> spiv: sure, no problem
<vila> Also, I'll be patch pilot next week so expect me to ask for some reviews for *my* proposals :-D Consider this a gentle nudge already ;)
<poolie> good idea
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 are official | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> lol
<poolie> vila i feel like in test_http it's a bit hard to understand which parameters control each test
<poolie> perhaps we should split it into per_http_client_impl tests
<poolie> or maybe make the parameterization more clear in each test
<vila> poolie: jam filed a bug about that
<poolie> which would need some more infrastructure
<poolie> mm https://bugs.edge.launchpad.net/bzr/+bug/597791
<ubot5> Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 2)" [Wishlist,Confirmed]
<vila> my gut feeling is that test classes should be able to parametrize in one of their methods.... but it kind of conflicts with the fixtures idea
<spiv> vila: hehe, sure
<vila> spiv: sure about the method of the conflict ?
<vila> s/of/or/
<spiv> vila: about doing some reviews next week
<vila> lol
<spiv> vila: regarding test_http, I have a vague recollection that we had an extended discussion about that in a review thread already
<spiv> vila: so probably we don't need to repeat that :)
<vila> hmm, I remember many discussions but not precisely where they occur, anybody finding pointers about them should add them in the bug comments...
<vila> I think I've spend far too much time in test_http to not be biased :)
<vila> rhaaa, libsll update... reboot...
<poolie> oh, this looks really good
<spiv> poolie: the output of your patch?
<poolie> no, my refactoring of test_http
<spiv> Ah, that'll do :)
<vila> poolie: yum
<poolie> with the http errors i just hope for "better than nothing" :)
<vila> poolie: hmm, on the paranoiac side, I'd make sure unhtml_roughly catch any exception and returns maybe_html (truncated) in this case
<vila> about releasing from trunk:
<vila> since I asked for a 2.3 branch on pqm too soon, I can now either:
<vila> - ask a losa to pull/push overwrite from trunk for betas, or
<vila> - release from trunk and create a lp:~bzr/bzr/2.3b2  for reference and forget about the lp:bzr/2.3 branch until the last beta
<vila> thoughts ?
<poolie> why would you even make a 2.3b2 branch?
<poolie> wouldn't a tag be enough?
<poolie> vila ,re the ssh failure, i may be a little out of date
<poolie> on my branch
<vila> ha, that would be a good news
<poolie> but only a few days at most
<poolie> did he just fix it?
<vila> no, I'd say a week at least of not 2
<vila> if
<vila> hmm, a tag on a revision not in the mainline, yeah, that should work
<spiv> vila: btw lp:~spiv/bzr/split-NEWS is the work-in-progress, pushing the latest now
<vila> spiv: great
<poolie> so i'm heading towards having you just say, on a test
<poolie> class
<poolie> variations = [VaryByHttpClientImplementation()]
<poolie> and that's enough
<poolie> it's a pretty straightforward change from here, i think
<vila> poolie: does it fly with multi-levels of parametrization in test_http ?
<poolie> yes, you just list the ones you want and it multiplies them
<vila> good
<vila> there was a related bug on testtools I think... let me check
<poolie> i might have filed it
<poolie> test_http is in a nice spot of being quite ugly but in an organized way
<poolie> so the cleanup is within reach
<vila> hehe, yeah, that sounds like what my daughter is saying about her bedroom :)
<poolie> :)
<vila> I think it's a good example of code not updated to the latest standard because the main author didn't feel it was necessary :-)
<vila> Which the other authors tend to disagree with :D
<vila> can't find the bug on testtools...
<poolie> :)
<poolie> i may split this into testtools when i'm happy with ti
<vila> poolie: don't rush :) We are already struggling with testtools updates...
<vila> ha, https://bugs.edge.launchpad.net/testscenarios/+bug/393394 is the one I was thinking about
<ubot5> Launchpad bug 393394 in testscenarios "No way to assign bound methods to tests (affected: 1, heat: 0)" [Critical,Triaged]
<vila> hmm, not clearly related though
<poolie> critical?
<vila> testscenarios
 * mgz asks vila what the word 'bumbep' means
<vila> that's bumped with a 180 degrees rotation on the last letter because it makes many heads spin
<mgz> ehehehe
<poolie> mgz, hi
<poolie> mgz, vila, let me know what you think of http://bazaar.launchpad.net/~mbp/bzr/597791-http-tests/annotate/head:/bzrlib/tests/test_variations.py
<poolie> and http://bazaar.launchpad.net/~mbp/bzr/597791-http-tests/annotate/head:/bzrlib/tests/test_http.py
<mgz> hey poolie.
<poolie> if you like :)
<poolie> and now, i think i can just delete load_tests from test_http
<vila> assert(expected, actual) is preferred
<vila> assertLength gives better feedback
<vila> no comment on importing symbols :)
<vila> the above remarks were for test_variations
<vila> wow, test_http looks nice
<poolie> it may be more lines but it's much more straightforward
<poolie> and you could squash it if you wanted
<vila> one comment though: how could a plugin reuse that ?
<vila> squash ?
<poolie> which bit?
<mgz> the concept looks good to me. would you change scenarios methods into variations attributes, or is the latter intended just to be a simple way of handling the former?
<poolie> i mean, you could take the variation lists and assign them to globals, then reference them from every test that needs them
<poolie> mgz i'm not sure what you mean
<spiv> poolie: looks interesting!  But it's also time for dinner...
<poolie> me too :)
<vila> right, so variations can be reused and are declarative, very good
<poolie> mgz i'd hope to clean up a lot of the existing load_tests into this
<mgz> well, there are some tests in test_http which look like they'd work as SimpleVariation subclasses
<poolie> ah, that's true
<vila> now, the possible attribute values are still disconnected from the test classes... on the other hand, the scenarios are cleanly separated, easier to reused, still hard to extend
<poolie> you could also have one that varies across a registry etc
<poolie> vila, why hard to extend?
<poolie> you're talking about where a plugin wants to get some existing tests applied to more scenarios?
<poolie> i think in that case you should have a variation that goes over a registry or similar
<vila> my remarks didn;t really apply to test_http but imagine tests that want to run against all type of repo/branch/wt
<vila> or some plugin wanting to ensure it respects some API, so it want to inject itself in the scenarios
<poolie> at the moment we have eg all_repository_format_scenarios() as a function
<poolie> i would simply lift that into being VaryByRepositoryFormat.scenarios
<poolie> you might not need to even change the code
<ciss> hi, how can i export only those files that have been changed or added in a specific revision?
<vila> could be, just raising the issue, not saying it's not addressed
<poolie> for existing things where we have a per_repository directory it may not be worth changing it
<vila> I'm thinking about plugins wanting to use a config registry for example (not yet implemented ;)
<vila> or adding a new transport (though this case is already addressed in a ad-hoc way)
<vila> or hook implementation that want to ensure they respect some API without clearly knowing what the API is
<vila> and where is the 'variations' class attribute handled ? ha right multiply_tests_by_their_variations
<vila> ha, right, so you don't inherit from the base class variations attribute right ?
<vila> slight risk of errors... on the other hand you get the ability to change what the base class is proposing...
<vila> I was thinking about a multiply_tests *method* instead of a multiply_tests_by_their_variations *function* but I never dug (digged ?)...
<poolie> arguably it should be a test method
<poolie> the unittest hierarchy is a bit strange
<vila> yeah :-/
<poolie> eg the insistence on TestSuites not just lists, and that you should not dircectly construct a suite, but rather ask the loader
<vila> well, a TestSuite is really a tree, *we* flatten them in many places...
<poolie> right
<vila> and the loader build many TestSuites automatically is the root cause I think
<vila> building
<vila> it fits pretty well with the --starting-with/load_tests design
<vila> which want to be able to prune early instead of filtering after the fact
<GaryvdM> Hi all.
<vila> Hey GaryvdM
<poolie> deletion of load_tests now pushed
<GaryvdM> Is there a way to get BZR_TEST_PDB to break in the stack where the error was raised?
<GaryvdM> not /testtools/testresult/real.py(423)addFailure()
<vila> GaryvdM: mgz will answered this one quite precisely I'm sure :)
<mgz> ehehe, pull bzr.dev Gary :)
 * mgz marks bug 504070 fixed while he's at it
<ubot5> Launchpad bug 504070 in testtools "testtools change broke BZR_TEST_PDB (affected: 1, heat: 7)" [Wishlist,Triaged] https://launchpad.net/bugs/504070
<GaryvdM> ok
<spiv> ciss: hmm, not sure there's a convenient way, although the bzr-upload plugin presumably does something similar internally...
<vila> ciss: what is your use case ?
<Fuu> Anyone aware of research papers that discuss bazaar, or dvcs in general?
<poolie> ok, good night all
<kmdm> Hi all, just wondering how 'bzr shelve' works / where it stores the deltas... since I'm now getting "bzr: ERROR: Unknown record type: 'n'" when trying to unshelve and a search & replace I did might have touched those files so I might need to manually revert that...
<mgz> kmdm: in .bzr/checkout/shelf
<kmdm> mgz: perfect - thanks, fixing the replacement got my changeset back :)
<GaryvdM> mgz: You rock. BZR_TEST_PDB Woking again.
<mgz> cunning time machine use :)
<txdv> does bzr have an equivalent to git's staging area?
<txdv> lets say i modified 10 files but i want to commit only 6 modified files
<kmdm> bzr shelve?
<txdv> it shelves all changes
<txdv> doesn't it?
<kmdm> nope, you can give it a list of files... and it'll commit a subset of deltas from any file
<txdv> i see
<kmdm> err, s/commit/shelve/
<soren> txdv: You can also just specify the files you want to commit... "bzr commit foo.c python/bar.py ChangeLog otherstuff" or whatnot
<txdv> hmm
<txdv> i see
<txdv> kthnx
<kmdm> yea, and that xD
<txdv> hm it would be awesome if i could specifiy the exact line numbers i want to commit
<txdv> (or have a tool better suited for this kind of ction)
<mgz> run `bzr shelve` and it'll interactively prompt you on diff hunks
<txdv> o rly? do i have to select a proper tool for that?
<soren> The 'y' and 'n' keys on your keyboard.
<txdv> i can't select it linewise
<txdv> that what i was talking about
<maxb> yes, it's only hunkwise
<txdv> it would be awesome to have it linewise, git doesn't support it too
<txdv> for once bzr would have a feature that git doesn't
<mgz> even lines isn't really enough for breaking a change into two bits
<mgz> quite often change one is editing some code and change two is reindenting it or something
<mgz> at which point, you just need to use your text editor anyway
<Glenjamin> not trying to start a fight here, but what's the advantage of splitting up commits like this?
<mgz> retrospectively you mean? some people just work that way, start with a big mess, then tidy it up.
<mgz> other people can manage little neat bits one at a time.
<Glenjamin> well yes, but what is gained by splitting the commits restospectively?
<mgz> it makes person of type #1 look like a person of type #2 :D
<Glenjamin> it's fairly unlikely that you can untangle a finished product to a halfway-house that works
<ddaa> it's sometimes important for code review
<ddaa> then you usually want to move some of the changes to different branches
<ddaa> so you can have one branch for "quick bug fixes"
<ddaa> on for "stylistic cleanups"
<ddaa> and one for the feature one was supposed to code in the first place
<Glenjamin> that makes sense, i guess in my general work I know it'll be merging it all into trunk - so if I forgot to make my commits granular I live with it
<Glenjamin> *it'll be me
<rubbs> I've used shelf/splitting my commits for a couple of reasons. I try to commit when I have one complete "idea" done, but if, in getting that idea done, I had to work slightly on something else, it's nice to keep things insular
<rubbs> also, I frequently get into a groove and bash out a lot of stuff, and then later realize that anyone else looking at my log would be really confused, so I break it down so it's easier for a third party to follow
<rubbs> it basically allows people to show their line of thinking, so if a big thing lands people can understand what's going on.
<Glenjamin> I guess i've mostly worked on either small fixes for open source, or closed source stuff where the log doesn't have to be perfect
<Glenjamin> Can anyone explain to me what "bzr push" into Git repositories does not work, although it is possible to use "bzr dpush". means?
<Glenjamin> I can push to git but i'll lose some information?
<jelmer> Glenjamin: yes, you'll lose revision properties for example.
<jelmer> as well as rename information
<CcxCZ> is launchpad broken with py2.7?
<CcxCZ> http://paste.pocoo.org/show/272702/
<mgz> fixed on trunk.
<mgz> there are various issues with Python 2.7 on the current release version on bzr, you're better off staying with 2.6
<vila> CcxCZ: ... mgz was faster, I was going to say exactly that
<achiang> hello, i have two branches that diverged from each other at some point. what's the best way to have branch B pick up branch A's changes? i'd like to review each change from A to make sure it's appropriate for B
<mgz> `bzr merge --preview A`
<achiang> thanks, i'll try that
<vila> achiang: start by 'bzr missing' to see how they diverged, then 'cd B ; bzr merge A' will merge everything at once,
<mgz> if it's a giant diff, you could merge each revision in turn.
<vila> achiang: to limit what is merge do: 'bzr merge A -r<last_rev_to_merge>
<vila> mgz: ok, I let you explain :) I need to release 2.3b2
<mgz> and remember you need to commit after merging and resolving any conflicts.
<mgz> ack, already vila?
<achiang> mgz: vila: thanks, much appreciated
<mgz> we're not frozen after that are we? how many betas are planned?
<vila> mgz: time-based releases suffer no delay :) What is ready is ready
<vila> mgz: argh, saying it again, not release, freeze
<mgz> I wasn't suggesting delay, just wondering where the time had gone
<vila> in a bunch of little tasks all building up ;-P
<mgz> okay, I need to leave shortly but will try and get through more of my todo list over the weekend
<achiang> the merge went very nicely. it even merged binary files correctly. thanks again.
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is frozen, build the isntallers ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> GaryvdM: ping
<vila> d0xxx: ping
<GaryvdM> Hl vila
<vila> GaryvdM: I just froze 2.3b2, I expect some plugins will need an update
<GaryvdM> ok
<vila> I've sent an mp for bzr-rewrite that has already landed and I've pushed a fix on bzr-gtk
<vila> I don't have anymore info about the other plugins at this pont
<vila> point
<GaryvdM> Ok
<vila> I'll pass around during the week-end to try to catch d0xxx and build the OSX 10.5 installer from what he'll told me
<vila> I'm going to update http://wiki.bazaar.canonical.com/Releases/2.3b2
<GaryvdM> vila: It would be nice to make a ical of expected releases. I'll try do that soon...
<vila> hmm, check that there isn't an existing one first
<vila> istr that poolie created one long ago, may be for the sprints or something but it should already be public
<vila> GaryvdM: ^ and that's a .... good idea ;)
 * vila pfew I managed to mistype the F ...
<vila> GaryvdM: but let's add only a few dates there so we can adapt
<samgee> I've got a tree with a large tar.bz2 file in it. I made a bzr branch out of that tree and committed. Then I unpacked the tarball, deleted some files and repacked it. Then I did the second commit and tried to push it to a server. A few hours later the client seems to be hanging and the server reports a MemoryError: http://dpaste.com/255095/
<samgee> Anything I can do about this?
<mgz> ideally, Don't Do That. you can use something like pristine tar and avoid versioning a giant binary blob
<samgee> Ideally, indeed. Sadly, the situation is less than ideal. :)
<dobey> how do i make an edit to an existing revision in bzr? like if i typoed --author argument or something? i'm having trouble finding documentation about how to do that
<davidstrauss> We're running into this bug on the Drupal.org infrastructure repositories: https://bugs.launchpad.net/bzr/+bug/483388
<ubot5> Launchpad bug 483388 in Bazaar "merge lies about lacking common ancestors when it has multiple choices (affected: 4, heat: 6)" [Medium,Confirmed]
<davidstrauss> Can we manually fix the merge tracking data?
<davidstrauss> vila, any idea ^^
<davidstrauss> poolie, do you have a minute to help me with a merge tracking issue that's blocking us on drupal.org?
<vila> davidstrauss: I was afk and just pass around, try --weave or add a comment to the bug, if you have accessible branches that help reproduce the problem, you'll get better feedback
<davidstrauss> vila, even when you use --weave, bzr still tries to find an LCA first
<vila> davidstrauss: still a bit early for poolie: 6:19AM
<davidstrauss> ah
<vila> then add a reproducing recipe to the bug, this is hard to diagnose without actual data
<davidstrauss> vila, is there a way for me to just force bzr to acknowledge two branches that are fully synched via merging?
<vila> (for pretty high values of hard)
<davidstrauss> vila, these branches aren't public, but we can give bzr people accesss
<vila> if the merge doesn't succeed ? Hmm
<davidstrauss> vila, i just want to cherry pick to consistency and then mark the branches as having no missing revisions versus each other
<dash> davidstrauss: do 'bzr merge' and then use 'bzr revert .'
<davidstrauss> dash, bzr merge fails
<dash> that'll keep the merge but remove any changes.
<dash> davidstrauss: what kind of fails, though
<vila> well, if you cherry-pick in both branches then you've address your immediate problem no ?
<davidstrauss> vila, yes, but that doesn't update any tracking data
<davidstrauss> vila, nor does it mark the revisions as merges
<davidstrauss> vila, i'm happy to cherry pick *once* to fix this, but i want merges to work properly from that point
<vila> davidstrauss: right, we need to fix a bug for that no ? I'm just proposing a workaround to unblock you
<vila> If we don't have a reproducing recipe this makes it harder to fox
<vila> fix
<vila> bah, last typo of the week
<davidstrauss> vila, there's been a reproducing recipe on the LP bug for a very long time
<vila> davidstrauss: you misread it, this is a case where there is no valid answer: the branches doesn't have a common ancestor
<davidstrauss> vila, i've run into this bug on multiple projects at this point
<davidstrauss> vila, that bug is for when they have two or more
<vila> davidstrauss: I understand that but I can only repeat: give me a reproducing recipe among any of your multiple projects
<davidstrauss> vila, and in the case of both projects i've had trouble with this on, it's been the same: multiple common ancestors
<davidstrauss> vila, how is the description on that bug not a reproducing recipe?
<vila> davidstrauss: sorry, as I said above I'm only passing around
<davidstrauss> vila, the description on the bug includes a shell script that demonstrates this problem
<vila> davidstrauss: if you want to help you later, give a reproducing recipe that, unlike the one in the bug report, have a common ancestor which is not NULL
<davidstrauss> vila, i can give access to individuals to the actual branches
<davidstrauss> vila, but i can't just make them public
<vila> fine, put that in the bug comment
<vila> there should also be some -Dmerge debug flag but I don't remember the details about what is output (but that may be something you can add to the bug report)
<davidstrauss> vila, ok, done. thanks.
<vila> oh, and mention which bzr version you're using too (and try trunk, just in case)
<vila> davidstrauss: nm, thanks for providing the info
 * vila off
<kklimonda> hey, I have a question about how to use bzr.. ok, how to use bzr in a specific way. I'm working on a branch of a library, adding some new features to it that I've discussed with the main developer. Now, I'd like to create a new branch based on this one to write some stuff I haven't yet discussed but what I need right now. The first branch is going to get merged, the second one may (or may not) but it
<kklimonda> depends on the first one. How can I work on both branches in parallel, merging the first one into the second in a way that make it possible to present the second one for the merge at the later date if the idea is accepted?
<mgz> are the things you're working on actually interdependant?
<mgz> of not, just use two branches from the current trunk.
<mgz> if they are, branch from your original branch rather than trunk, and if you commit something you need for your second branch, merge the first one back in again
<kklimonda> mgz: how is launchpad's merge system interpret the second merge request?
<kklimonda> how is it going to*
<mgz> merge proposals have a "mark as dependent on another branch" thing you can use.
<mgz> just paste the lp link of the first branch in there on the second merge proposal
<kklimonda> mhm, makes sense. thanks
<mgz> (and probably mention it in the description, as that can be a little easy for the maintainer to miss)
#bzr 2010-10-09
<peitschie1> mornin all
<aa_> hi everyone, bzr just handled a really nasty merge for me really impeccably. So just to say thank-you for the hours you just saved me! Thank-you!
<bzrnewb> Hello I am having a minor issue with bzrignore. It won't ignore some of the folders I added to it's list.
#bzr 2010-10-10
<git__> is there such thing as whitelist for bzr upload ?
<gour> hello
<gour> i see that, according to the posts on ml, 2.2.1 performs much better...we're looking for a dvcs (excluding git) to use for open-source project...i played with monotone and i like it, but it's not much supported/widely_used...how does bzr compares with hg on Mac (linux will be main platform, and i know about explorer and tortoise hg for non-gui users, so wonder about Mac OS)?
<vila> gour: have you tried the OSX installer ?
<gour> vila: no, i'm not using Mac..any gui tool there? (i'm fien with cli, but for other potential devs)
<vila> gour: bzr-explorer is included
<gour> vila: ohh, that's great...
<gour> btw, how in general does bzr compare with hg today?
<vila> gour: I'm not a big fan of general comparisons, one has to use tools for his own needs to compare and decide, there are far too many differences in perfs and perceived ease of use to get a clear cut
<vila> that being said, I think the 2a format closed the gap with both hg ang git in terms of repo size
<gour> vila: i'm aware of bzr's ease of use, and although i like darcs/monotone, here i'm thinking about making it easy for others...performance was something bzr was always complained about, so i'm just questioning about bzr's adoption these days in comparison with hg
<vila> bzr has still a lot of potential areas for improvements, we'll get there when time permits ;)
<gour> ok..but not some big perf. holes in 2.2, iow, in par with hg?
<vila> well, if you ask *me*, I'd say perfs are roughly the same between hg abd bzr
<vila> yup
<gour> thanks
<vila> you're welcome
<vila> gour: the most important one I'm aware of for bzr these days if annotate with huge histories
<gour> i'm sad ian is not around any longer to see bzr's harvest :-(
<vila> :-/
<gour> vila: have you ever tried monotone?
<vila> no. AIUI the data model is an interesting one, but implies that you can run into combinatorial explosions without notice
<vila> iow, it doesn't scale. But there are certainly interesting ideas for small scale sort of stuff (including a single submission from a single dev even for big projects)
<gour> security model with signed certs is really nice
<vila> oh, we have a pending bug for that in bzr ;-) Not a big amount of work, but nobody stepped up for it so far (well, I remembered one attempt but it was blocked because the contributor didn't want to sign the agreement :-( )
<awilkins> git gives you those properties for signed commits
<vila> awilkins: I think gour is referring to a different part of the workflow, you *can* sign your commits with bzr
<gour> awilkins: i simply cannot stand git's 'design'
<gour> right. monotone allows you to have kind ogf QA
<vila> certs are supposed to be used to control access to repos in broader terms: can you push a set of revisions including ones you didn't create yourself
<awilkins> gour, I have found bzr much easier to grok than git ; I'm currently in the learning process for git because it has some properties that Hg and bzr do not in terms of a particular use case
<gour> bzr kind a 'favors' left branch during merge, right?
<gour> awilkins: git is ungrokable for me :-)
<awilkins> gour, I had a three day headache for Bazaar because I'd been using SVN for so long .... I kept checking merges very carefully because I couldn't actually believe it was that easy
<gour> he he...svn
<awilkins> git is rather the next step on that ladder - it does so many things silently and quickly, you're not sure anything actually happened
<awilkins> Makes one nervous
<gour> even shooting you in your own feet...silently :-D
<awilkins> gour, I'm having to tutor people on VCS this week - the management are insisting that I focus on SVN "because it's what we already use" rather than break new ground and help people to be more productive with DVCS
<gour> awilkins: :-( tell them about monotone as well ;)
<awilkins> Despite my last project having a team of 10 using Bazaar on a daily basis (these are non-programmers too, a few shell scripts to walk them through the merges and they are just fine 95% of the time)
<gour> awilkins: otoh, bzr can be used almost like svn
<awilkins> gour, I tried Monotone, I wouldn't go back to it
<gour> awilkins: why not? 1.0 is around the corner...actually 0.99
<awilkins> gour, The bzr-svn plugin is excellent too ; by far the most seamless SVn interaction of any DVCS
<awilkins> gour, Although git-svn copes with boneheads who can't use VCS better
<awilkins> gour, It's mostly a question of popularity - I liked the properties of Monotone, but I honestly found it harder to pick up than Bazaar, and it's nowhere near as popular as git
 * gour nods
<awilkins> So in terms of my VCS "portfolio", I'm going to pick the best-in-class for given roles and ignore the rest
<gour> bzr?
<awilkins> SVN - old fogies who want CVCS ; Bazaar - nearly everyone else ; git - For when you need Phenomenal Cosmic Power
<gour> lol
<gour> git - for Suicidal inclinations
<awilkins> e.g. - I'm looking at using git for the version control of object counts in the 10's of millions ; probably needs a lot of new porcelain but I can't imagine the inventory-based DVCS systems (Hg, bzr) coping with that.
<awilkins> git, OTOH, means that commits can re-use tree objects so where the edit rate is low the number of objects you have to add for a new commit shouldn't be too bad
<gour> monotone & sqlite3 back-end?
<awilkins> gour, I'd need to review the monotone data structure a bit and see if I thought it was a good for for this
<vila> awilkins: feedback on where in the merges people encounter problems highly welcome
<gour> awilkins: do it...
<awilkins> vila, Does Bazaar store inventories as deltas?
<vila> awilkins: with 2a we started seriously to stop requiring manipulating the inventory by using chk maps
<vila> awilkins: roughly yes
<vila> meh, *store* yes, but I think some parts of the code base still doesn't use it optimally (imbw though)
<awilkins> vila, The reason I'm only considering git for this 10s-of-millions-of-objects thing is that if you break the keys for the objects into "trees", then a new commit will re-use most of the existing tree objects ; only the trees with changed objects and their ancestors will need to change, so the revision storage size will be smaller
<vila> awilkins: yes, that's what drove the chk introduction
<awilkins> vila, Plus the project is hostile to reciprocal licenses and jgit has a liberal license
<vila> awilkins: but it mostly apply to inventories
<vila> awilkins: EPARSE reciprocal licenses ?
<awilkins> vila, GPL, anything with copyleft
<awilkins> vila, Government IT projects seem to have been convinced that GPL is evil by their corporate partners (who naturally want to be able to take all our hard work and sell it back to us)
<vila> awilkins: ...  "viral" nature of GPL applying to versioned content non-sense ?
<awilkins> vila, No, I've not seen the "GPL applies to the data!!!" fallacy yet
<vila> pfew
<vila> I'm certainly biased, but my feeling is that more and more people start to grok the floss implications...
<awilkins> vila, But the last internal report I saw was rather biased, uses language like "permissive" for BSD-style and "non-permissive" for GPL, and had a number of inaccuracies
<vila> right, that's a small incremental progress :)
<awilkins> What I can't understand is the willingness to pour public funds into projects under a license that allows corporate types to take the code and make proprietary projects out of it
<vila> hehe, exactly
 * gour will use gpl3 licence for upcoming project
<vila> the day people will realize that people money is so better use when funding public projects (which GPL is *all* about), things will change
<awilkins> I know that the perception is that the companies will take their ball and go play somewhere else... but - really? They are going to turn down a slice of the Â£12 Billion NHS IT budget?
<vila> s/use/used/
<awilkins> Even our internal open-source advocates are nervous about copyleft
<vila> I've yet to see companies *losing* by turning GPL, whereas new ones *win* every day
<vila> and following Oracle moves these days is... interesting :)
<awilkins> I'll use GPL for internal tools in preference to proprietary code, even if we already have licenses for it, just because it means I can fix the bugs myself and not have to wait for support
<vila> community support is a reality hardly denied these days...
<awilkins> And I'm presently operating a policy of turning down requests for Office documents as output formats for reports unless they can justify a 5-fold increase in costs for that module :-P
<awilkins> Just an estimate. But I know for sure that it's harder than CSV or HTML.
<vila> oh, you mean the *other* Office, not the open one ? <grin/>
<vila> I give my best wishes to http://www.documentfoundation.org/ ...
<awilkins> Not tried ODF exports
<awilkins> We have the input filters installed so I guess they'd be able to view them in Office.
<awilkins> We just cancelled our NHS-wide agreement for MS products, so everyone is having to audit themselves
<awilkins> Or so I hear... Mentioned it to Mr Shuttleworth (shameless-namedrop) in the release party channel and he wanted the phone number for our IT director :-p
<vila> hehe
<awilkins> An "office of open office migration investigation" would cost us much less than our Software Assurance I'm sure
<awilkins> Naieve numbers would be say, 1M licenses at SA rates of 29% of retail - ~ Â£125M per annum
<awilkins> For Office Pro
<awilkins> For Â£62.5M I'll fork, maintain, support and train  NhsOpenOffice, and run a "MS addiction clinic" for people with VBA Macros and Access databases.
<gour> rotfl
<awilkins> (and buy a place in the Maldives :-P )
<vila> hehe, yeah, think about giving  even part of that to http://www.documentfoundation.org/ instead of forking....
<vila> if only to make other organizations think about doing the same...
<awilkins> Indeed. My fork would be a thinly branded branch of the official one - and I'd probably subcontract a lot of that cash to documentfoundation.org :-)
<vila> and compare what has been invested in the MS one and what we got in return...
<awilkins> A few NHS useful plugins like ... oooh,  GPG support for confidential patient records.
<vila> people always ask me: but how is floss making money ? To which I like to answer: look, it works, you use it more and more and you didn't put *any* money in it, now, think about giving a small percentage of what you gave to proprietary software... What do you think you will get in return ?
<vila> And by the way, when was the last time you found you couldn't open one of those documents you created 10 years ago ?
<awilkins> The answer is - exactly what you wanted, instead of what the focus groups in Richmond wanted.
<vila> ..and more ;)
<awilkins> FOSS offers you the opportunity to engage in patronage again
<vila> with the guarantee that nobody will be able to steal it anymore.. what did you say about GPL again ? :-D
<awilkins> Only you get to build on the shoulders of giants, unlike Michaelangelo or Da Vinci
<awilkins> Who were great but had to start from scratch
<vila> growing giants :)
<roryy> is the output of 'bzr status -S' supposed to match that of 'svn status' closely?  'bzr help status' isn't too clear.
<awilkins> The status columns aren't wide enough to match SVN
<awilkins> So I'm guessing no
<awilkins> SVN has more columns out front (6 AFAIK)
<roryy> yeah, 7
<roryy> actually a little different from SVN; e.g., for a new file svn shows 'A      foo', bzr st -S '+N   foo'
<CcxCZ> launchpad is broken with py2.7; it's fixed on trunk (allegedly); trunk is on launchpad :-[
<Glenjamin> can you bzr export trunk from another machine?
<CcxCZ> maybe, let me try
<CcxCZ> yes, the tricky part will be getting it into system without breaking anything
<CcxCZ> maybe it's sufficient to replace the plugins/launchpad directory?
<Glenjamin> Depends what the problem is i guess, but sounds like it should work
<Glenjamin> in fact, you might be better off grabbing the launchpad plugin folder and putting it into ~/.bazaar/plugins
<CcxCZ> Glenjamin: is there separate project/repository for that?
<Glenjamin> afaik, no - you'll have to grab the whole bzr trunk and copy it out (or symlink it)
<CcxCZ> nope, it still causes error with xmlrpclib
<Glenjamin> what OS are you on?
<CcxCZ> gentoo linux ~amd64
<CcxCZ> but maybe I grabbed wrong version of bzr
<Glenjamin> if you built it from source, you should just be able to grab trunk and make && sudo make install
<Glenjamin> or if you have multiple pythons installed, you might be able to force the bzr executable to use 2.6
<CcxCZ> Glenjamin: hmm, but I don't have paramiko installed for 2.6, is that necessary for pulls from launchpad?
<Glenjamin> if you set BZR_SSH=ssh i think you can fall back to the system ssh executable
<Glenjamin> i havent' done that for a while though, so no promises
<CcxCZ> lp:bzr is supposed to be the trunk, right?
<Glenjamin> typ
<Glenjamin> *yup
<CcxCZ> I still get this: http://paste.pocoo.org/show/273593/ can you confirm that this is the fixed error?
<Glenjamin> yeah, thats the issue
<Glenjamin> https://code.launchpad.net/~toshio/bzr/python27-lp-fix/+merge/35487
<Glenjamin> thats the fix
<CcxCZ> so it's not bug with launchpad but with bzr http transport
<CcxCZ> that explains it
<CcxCZ> so I slapped the patch on top of source package and it seems to work, thanks
<CcxCZ> btw when is next release scheduled?
<Glenjamin> not a clue, i'm just a user :)
<bkgood> anyone have a good cia hook? the only one I can find relies on bzrlib.delta.compare_trees which has apparently been deprecated quite a while ago and since removed
<jelmer_> bkgood, hi
<jelmer_> bkgood, the bzr-cia plugin on launchpad should be up to date
<jelmer_> if that raises deprecation warnings, please file a bug
<bkgood> jelmer_: no deprecation warnings, thank you! might want to update http://doc.bazaar.canonical.com/plugins/en/cia-plugin.html
<peitschie> mornin all
#bzr 2011-10-03
* 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
<vila> hi all !
<jam> morning all
<mgz> morning all
<Riddell> hello
<mgz> hey Riddell
<jam> vila: https://code.launchpad.net/~jameinel/bzr/2.5-no-hanging-teardown/+merge/77870 should handle the hanging tests issue
<jam> both some fixes to the testing infrastructure to avoid future hangs, and fix the actual trigger
<jelmer> vila: did you see https://code.launchpad.net/~bryan-tongminh/bzr-webdav/ctype-fix/+merge/77824 ?
<vila> jelmer: yup, on my TODO list
<jelmer> vila: great, just checkin' :)
<jelmer> we should really get some of those inactive projects out of the "bazaar" project on Launchpad
<vila> yeah, this one have been rumored to be merged into core but the maintainer is slacking ;)
<jelmer> hehe
<jelmer> Riddell: just noticed, the changelog entry still says a "get-tar" command was added rather than get-orig-source
<jelmer> sorry for not catching that during review
<Riddell> jelmer: oh aye, fixing
<rom1> hi all
<rom1> I have a functional question about branches merges : is it possible to do a "merge revision" without merging the files, but selecting the OTHER code ?
<rom1> Or in other words, is it possible to do a pull/push --overwrite with the creation of a revision that bundkles all the pulled/pushed revisions ?
<jelmer> rom1: I'm not sure I follow entirely - is this to e.g. land a branch on trunk?
<rom1> jelmer : not sure what land means... In fact, i have some developers requesting a workflow a la gitflow.
<rom1> in this workflow, i can have hotfixes in the master
<jelmer> rom1: Can you give a concrete example ?
<jelmer> rom1: There is no one git work flow afaik :)
<rom1> but to merge the develop revisions to the master, i want to forget about the hotfixes changes : either they have been merged into the develo branch, and no problem, either not, and it means that it has to be replaced by the develop branch
<rom1> jelmer : i talk about this one : http://nvie.com/posts/a-successful-git-branching-model/
<jelmer> rom1: I'm still not sure if I follow but I think you mean "bzr merge OTHER && bzr ci -m 'Merge other'."
<poolie> o/ jelmer
<poolie> (not really here, should go to bed)
<jelmer> hey Martin
<jelmer> Ah, right.. labor day in .au ?
<jelmer> Or I guess that would be labour day?
<nigelb> lol
<poolie> in NSW
<jelmer> ah, that explains why wgrant and wallyworld were still around. I figured they just forgot ;-)
<jelmer> hey mrevell, back on the interwebz?
<mrevell> ja!
<mrevell> :)
<rom1> jelmer : in fact, i do not want  to merge the files, i want to get exactly the code from OTHER (just like the ush/pull --overwrite) but in a single revision...
<nigelb> jelmer: forgetting is entirely possible :)
<jelmer> rom1: so you want to discard the changes in the current branch, but have history indicate they're present?
<jelmer> nigelb: you're talking to somebody who has once accidentally worked on a holiday :)
<nigelb> jelmer: hahaha
<nigelb> I guess that happens when you work from home :)
<rom1> jelmer : well, discussing about that, i notice that it isn't very clear even for me.
<rom1> :p
<jelmer> rom1: is there a specific git command that does the same thing that you're looking for?
<rom1> jelmer : when we create a hotfix on a production branch, it may be a dirty quick patch to quickly resolve the issue. When we release a new version containing a quick fix of the issue, i do not want to merge the dirty patch and the clean fix, but only take the clean one.
<jam> rom1: bzr merge $OTHER; bzr revert -r -1:$OTHER; bzr commit -m "Merge and reset the tree state to $OTHER" ?
<jam> Or just simply:
<rom1> Yep ! i didn't think about revert !
<jam> bzr revert -r -1:$OTHER; bzr commit -m "Set the tree state to exactly OTHER but don't mark it as merged"
<jam> I don't really think you want to set it to other without merging, but you could, if you really want to throw away all of OTHER's history.
<rom1> jam : i understand. I haven't validated so far this workflow. I wanted first to see if it was feasible with bzr and our release management. I understand that a "merge without merge" is somehow surprising...
<rom1> sorry, in my post to jelmer, i was meaning : "When we release a new version containing a CLEAN fix of the issue[...]"
<jam> rom1: the issue is just what exactly you mean by "pull --overwrite" with only a single revision
<jam> doing a merge, and revert, will create a single new mainline revision
<jam> however
<jam> this also assumes that you don't have any state in mainline that you want to keep
<jam> specifically, say that you emergency fix X, then you do a normal fix of Y, then you finally finish the real fix for X
<jam> doing the revert will throw away the updates to Y.
<jam> Which is why I would suggest just doing "bzr merge && bzr commit"
<jam> *but* you know your process better than I do
<jam> Assuming that the dev branch always supersedes the production branch sounds a bit risky, but if that is your process, you can stick to it.
<rom1> jam : you're right, a temporary hotfix hasn't to be released in a production branch. Just branching it in a dead end branch, and keeping my proudtcion branch with merges only.
<rom1> Thx jam and jelmer
<systemclient> is bzr 0.18.0 usable with current repos at all?
<poolie> systemclient, it won't be able to read the default format created by recent bzr releases
<poolie> pre-1.0 is pretty old
<systemclient> poolie: isn't pre 2.0  old already?
<poolie> yeah, therefore 0.18 is really quite old
<poolie> 2.1 and later are still in support
<jam> poolie: I know you aren't really here, but if maybe your ghost is around, I have an initial prototype up for https://bugs.launchpad.net/bzr/+bug/819604
<ubot5> Ubuntu bug 819604 in Bazaar 2.1 "when an idle ssh transport is interrupted, bzrlib errors; should reconnect instead" [High,In progress]
<jam> And it would be nice to get some feedback about where it is going.
<mgz> okay, lunch before caches confuse me any more
<jelmer> I never go caching before lunch either.
<jelmer> vila: thanks!
<jam> vila: I replied to your review. I tried to run the babune jobs, but it just told me the servers are unavailable, and it looks like you deleted the requests. (Perhaps I entered them wrong?)
<vila> ha, whic requests did you enter on which jobs ?
<jam> vila: freebsd, natty, lucid
<jam> selftest-subset-*
<vila> jam: I' jusr recovering from a babune crash and *I* was typing text in a firefox, unlikely to crash...
<vila> jam: for which tests ?
<jam> vila: I was running all of them, since the failing tests tend to be randomly distributed. I know which ones to suspect if you don't want a full test run.
<vila> I'd prefer that, yes, especially if something is crashing
<vila> jam: the freebsd slave is running a fsck, leave it some time to recover
<jam> vila: So, after the changes, nothing should crash or hang :). The issue is that the test was hanging once it hits 4.0s of runtime. So you need a bit of load to slow the test suite down enough. Here they normally finish in about 2.5s
<jam> (Which is why it seemed so random, a given test has to get some sort of hiccup and go over the 4.0s mark.)
<vila> no test takes 4s to run on babune AFAIK
<jam> vila: I'm pretty sure it did, though not consistently
<vila> did you find reports to back that up ?
<jam> vila: I can trigger the test suite hang by making the test take longer than 4.0s
<jam> is that good enough for you?
<vila> meh, of course not, I mean, this is certainly a bug but it doesn't mean it explain the ones we encountered on babune
<vila> a test taking 4 seconds is already a bug and we've never seen such huge variation without a good reason
<jam> vila: aka, this diff: http://paste.ubuntu.com/701706/
<mgz> load vila?
<jam> vila: its already at 2.5s here on my reasonably fast laptop
<jam> it isn't *that* far from 4.0s
<mgz> how careful are you to only be running one test suite on a box at once?
<vila> mgz: I rely on jenkins for that (don't remember the details)
<jam> vila: didn't you have to implement locks to reduce the load spike at midnight?
<jam> I was pretty sure you schedule all jobs to run daily, and then you restrict it via some sort of inter-locking to something like 2 concurrent runs.
<jam> also, you are running --parallel, right?
<jam> if you had per-test timing (which I really had hoped you would), we might have been able to see something like that
<jam> I realize it doesn't get exposed via our junit xml adapter
<vila> inter-locking is on slaves
<jam> though again, it may not strictly matter, since once a test hit 4.2s it would hang, and we wouldn't see it. But we could see that in the past, some test happened to spike higher than 4.0s.
<vila> jam: look at the Test results, the timings are there for all tests (consolidated by prefix)
<jam> vila: ah, just only for successful runs, right?
<vila> yup, but it would very weird that a spike *never* occurred
<jam> vila: http://babune.ladeuil.net:24842/job/selftest-chroot-lucid/lastSuccessfulBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/
<jam> has a test that takes 2s
<jam> vila: note that it only started failing if you have a 4.0s spike with the ConnectionTimeout patch
<jam> so it certainly could have been spiking in the past, and just didn't cause a failure/hang
<jam> vila: http://babune.ladeuil.net:24842/view/FreeBSD/job/selftest-freebsd/lastStableBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/ has a test that takes 5.5s
<jam> test_fetch_from_stacked_smart_old(InterDifferingSerializer,RepositoryFormat2a,RepositoryFormatKnitPack6RichRoot)Â 5.5 secPassed
<jam> test_fetch_parent_inventories_at_stacking_boundary_smart(InterDifferingSerializer+get_known_graph_ancestry,RepositoryFormatKnitPack1,RepositoryFormatKnitPack6RichRoot)Â  took 5.4s
<vila> can you paste the precise URL instead of letting me find it in ~100 line pages ?
<jam> and the ones after it are taking 6.x *
<jam> vila: I was trying to show you the overview
<jam> http://babune.ladeuil.net:24842/view/FreeBSD/job/selftest-freebsd/lastStableBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/test_fetch_parent_inventories_at_stacking_boundary_smart_InterDifferingSerializer_RepositoryFormat2a_RepositoryFormatKnitPack6RichRoot_/?
<jam> there is a direct test
<jam> 'took 6.7s'
<jam> which also explains why the freebsd was more likely to hang
<vila> ha, ok
<vila> but why spuriously then ?
<jam> vila: you have to have 4.0s of idle time on a given connection, and then get another connection after that 4.0s. So it isn't strictly a 'test takes >4.0s'.
<vila> jam: if you look at this same test in the previous builds, it always above 4.0s
<jam> Say you get the last connection at 3.9s, and then spend 2.7s working with the last connection.
<jam> so, vila, even if I'm slightly wrong with my analysis (though I've spent the last 3 days on it), I'm sure that this change makes behavior more friendly, and fixes the "time.sleep(4.0)" problem.
<jam> it certainly should change behavior so rather than hanging, we at least get a failure/exception when appropriate.
<vila> jam: we can spend days discussing, if you know exactly how to trigger the hand, you should be able to make the test fail in a simple way to demonstrate it, you don't need to change all test servers for that leaving the doubt about whether you shake the code enough to make the hang go somewhere else
<jam> anyway, EOD, here, I'll see if we can start talking about it earlier tomorrow.
<jam> vila: I *did* change the tests to prove it
<vila> indeed, and focus on smart server only if that's where the issue is
<jam> client.read() was hanging
<vila> but you din't use this
<jam> vila: the test didn't do it
<jam> in fact, you had the test set a client timeout
<jam> *because* it was hanging
<jam> I was able to fix the test to just read and get a closed connection
<vila> in test_test_server only, that's not used anywhere else !
<jam> vila: test_server is the base implementation of SmartTCPServer_for_testing which is used in every test that calls make_smart_server()
<vila> no  !
<vila> test_test_server not test_server
<vila> your change is in the former not the later
<jam> vila: TestingTCPServerMixin is the class that needed updating as it was the part that implemented the code that SmartTCPServer_for_testing uses
<jam> the tests for that class are in "test_test_server"
<jam> there aren't any tests in "test_server"
<jam> it is the implementation of the "TestServer"
<jam> vila: if you go to "bzrlib.tests.__init__" you can see that we add "bzrlib.tests.test_test_server" but not "bzrlib.test_server" to the test suite.
<jam> anyway, really, I need to go pick up my son. I'm not sure why you don't believe me
<vila> that's what I'm saying, I know how these files are named, I created them
<mgz> okay, I think this has just made my morning worthwhile.
<mgz> >>> om[3062558728]
<mgz> str(3062558728 4194212B 1par 'f\xe7_chknode:\n65536\n1\n1382\n\n\x00\x00sha1:6d13c15b49497a74b59b064e0f1bb074dd05b3be\n\x01\x00sha1:ce73daef8871866fd78')
<mgz> >>> om[3043770376]
<mgz> str(3043770376 4194212B 1par 'f\xe7_chknode:\n65536\n1\n1382\n\n\x00\x00sha1:6d13c15b49497a74b59b064e0f1bb074dd05b3be\n\x01\x00sha1:ce73daef8871866fd78')
<jam> vila: I fixed "test_server.py" to close connections on an exception, or when validate_request() returns false. I updated the tests in test_test_server to test those cases. If you just run the updated tests without the fixes, the test suite hangs.
<jam> I'm not sure what else you want.
<jam> mgz: do you need some help understanding those?
<mgz> of the 25 LRUSizeCache objects over repository packs, two have duplicates
<jam> That is a groupcompress record contain CHK nodes.
<jam> If you open a repository twice, you'll get duplicates
<vila> jam: I want your fix to be specific to the smart test server not invading other servers
<jam> if you open a source and a target, they both might have a copy
<jam> you can check the parents to see who is referencing them.
<mgz> jam, as I understand that readout, there are two different GroupCompressBlock objects with the same content
<jam> vila: I think the other servers are poorly behaved, because they will also cause clients to hang when the server gives up on talking to them
<jam> mgz: also certainly possible
<jam> vila: the tests you have today actually were hanging, but you forced the client to use a socket.timeout to avoid it
<vila> jam: you can't say that without evidence, I told you last friday this is don't happen *except* for the smart server which uses daemons threads
<jam> mgz: you can ping me tomorrow after standup and I'll poke around with you if you want.
<jam> vila: I can
<vila> jam: don't generalize from a single test specifically designed
<jam> I have evidence
<jam> vila: if you take out the socket.timeout ... the test hangs
<jam> reliably
<jam> the comment is that the "server doesn't get cycles" is false
<jam> it is because the server "doesn't close the connection" until teardown
<jam> sorry "socket.settimeout"
<mgz> jam, thanks. I'll plug on for a bit longer now and see where I get.
<jam> vila: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/bzrlib/tests/test_test_server.py#L166
<jam> but for now, I'm gone
<jam> see you all tomorrow
<jam> have a good night
<mgz> bye!
<abentley> jelmer: some time I'd like to get up to speed on co-located branches and their implications for pipelines.
<vila> jam: the comment says "whether our reads or writes may hang" this test *requires* a timeout
<jelmer> abentley: the colocated branch format hasn't landed yet, so it might still be a bit too early. As far as I can tell pipelines just use the regular bzr APIs, in which case I think
<jelmer> pipelines will just work out of the box with colocated branches.
<abentley> jelmer: pipelines can create and use bzr-colo-style branches using "reconfigure-pipeline".
<jelmer> abentley: colocated branches in core are different from bzr-colo
<abentley> jelmer: Once colocated branches in core are usable, I think reconfigure-pipeline should switch to them.  And "add-pipe" will need to support them too, I imagine.
<mgz> looks very hopeful for some duplicate elimination: <http://pastebin.ubuntu.com/701737/>
<jelmer> abentley: It should be able to support both, if you're ok with having the extra code to do so.
<abentley> jelmer: I'm okay with that.
<jelmer> vila: hi, still there?
<vila> jelmer: oh sorry, yes
<AuroraBorealis> hiya mgz/wgz whatever you are today
<AuroraBorealis> i dunno how hard it is to fix whatever was going wrong with the meliae dumps but if one could figure that out then maybe we could fianlly get somewhere xD
<mgz> after you went to sleep I succeeded in loading the dump by getting meliae to ignore ids that are not present,
<mgz> which there's a TODO over but I'm not sure of the neatest way of doing
<mgz> ...and was on the other box
<AuroraBorealis> lol
<mgz> but if you add something similar the dump will at least load
<AuroraBorealis> remember what file i should look in?
<mgz> I've also been looking at where memory is used this morning, so have a generally better idea of what I'm doing
<mgz> sec, nearly done for the day here, will transfer down below
<AuroraBorealis> ah ok
<wgz> okay.
<wgz> workaround: <http://paste.ubuntu.com/701810/>
<AuroraBorealis> that works
<wgz> can still fall over later, but gets the thing loaded
<wgz> so, can you also do `om.summarize()` now? if so, we can progress.
<AuroraBorealis> i shall work on that now
<AuroraBorealis> finally got i t
<AuroraBorealis> it
<AuroraBorealis> it wasn't repacking during this, but doing the fast-import again (2 gigs of memory)
<AuroraBorealis> http://paste.ubuntu.com/701828/
<wgz> omg.
<wgz> well, that's only finding 440MB usage at that point
<wgz> but 120MB in frozenset is pretty crazy
<wgz> do `om.get_all("frozenset")[1]`
<wgz> `om.get_all("frozenset")[0]` even.
<AuroraBorealis> even though the memory usage was 2 gb in the process the dump file was only 1 gb
<AuroraBorealis> which was weird
<wgz> it's possible fast-import has 1.5GB of unfindable allocations
<AuroraBorealis> frozenset(37820232 2272B 31refs 1par)
<AuroraBorealis> and frozenset(1340577832 736B 15refs 1par)
<AuroraBorealis> for [0] and [1]
<wgz> hm, that's not big, it's just lots of teeny ones adding up to pain then.
<wgz> use _.c to see what's in one.
<AuroraBorealis> after the get_all()[1] call?
<wgz> in the python terminal _ just refers to the last object
<AuroraBorealis> oh
<wgz> you can bind one to a name instead of you want
<AuroraBorealis> getting "address not present" again
<wgz> try some other indexes, see if they're all missing contents
<wgz> might be were some of the extra mem usage is to be found
<AuroraBorealis> [0] worked
<AuroraBorealis> http://paste.ubuntu.com/701837/
<AuroraBorealis> just look like strings o.o
<wgz> heh, yeah, [0] is likely not typical
<wgz> try some other numbers nearer the middle
<AuroraBorealis> 2-7 all return KeyError >.>
<wgz> there are 562876 frozenset objects, so pick some bigger indexes
<AuroraBorealis> oh
<AuroraBorealis> lol
<wgz> if lots of them have the same problem, it's likely there's our meliae bug to fix
<AuroraBorealis> yeah
<AuroraBorealis> 200,000 does it, 300,000, 400,000
<AuroraBorealis> all keyerror
<wgz> try in the other direction, use .p rather than .c
<wgz> and find out what's holding on to them
<wgz> keep going up with _.p[0].p ..etc as needed
<wgz> (.c is 'children' - the list of object this object references, and .p is 'parents' - the list of objects that reference this object)
<AuroraBorealis> http://paste.ubuntu.com/701839/
<AuroraBorealis> tried some numbers
<AuroraBorealis> oh
<AuroraBorealis> seems to be the same dictionary tho
<wgz> yeah, dict is too generic, go up again till you find a class or something more signpost-y
<wgz> it's all the same dict at least
<wgz> hm... actually, I think I may know where in the code this is
<AuroraBorealis> [bzrlib._known_graph_pyx.KnownGraph(170691824 72B 2refs 1par)]
<AuroraBorealis> they all say that
<wgz> okay, so that's the entire history in memory.
<AuroraBorealis> that seems bad
<wgz> well, fastest way provided it fits, probably
<AuroraBorealis> fast importing the linux kernel does seem like an extreme case
<wgz> AuroraBorealis: get that KnownGraph object and look at its children
<wgz> and also maybe summarize it (with `om.summarize(kg)`)
<AuroraBorealis> i think this is right
<AuroraBorealis> http://paste.ubuntu.com/701847/
<wgz> think there was one to many .c to get kg, but gives the right idea
<AuroraBorealis> yeah without the .c it still shows the same thing
<AuroraBorealis> actually i lied
<wgz> we've lost the giant dictionary with the frozenset objects somehow in that output
<AuroraBorealis> http://paste.ubuntu.com/701848/
<AuroraBorealis> that?
<wgz> there he is.
<wgz> so, that's big, but not huge. however, we seem to have no content for any of those containers, which is apparently where the dump went wrong
<AuroraBorealis> is that something wrong with meliae?
<AuroraBorealis> that it didn't dump everything
<wgz> yup, I'm guessing, will try and repo so it can be fixed.
<AuroraBorealis> ok
<AuroraBorealis> i should be around
<AuroraBorealis> well i have school, and i am probably going to be at school late cause some company is coming and i want to sit in on their talk
<AuroraBorealis> you can email me with stuff to do at markgrandi@gmail.com though :D
<poolie> jam, hi, i see your mail
<poolie> hi all
<jelmer_> hi poolie
#bzr 2011-10-04
<lifeless> wow
<lifeless> enough recipe mail today?
<AfC> lifeless: I know about bzr builddeb's import-upstream, but I heard you mention 'import-tar' (sic) once. Is that something different?
<lifeless> yu[p
<idnar> so I'm trying to push a pipeline to somewhere else with bzr sync-pipeline
<idnar> but "bzr sync-pipeline bzr+ssh://lorien/path/to/dir" gives me "bzr: ERROR: Pipeline has no pipe named "dir"."
<idnar> I guess I'm doing it wrong?
<AuroraBorealis> whats a pipeline? o.o
<idnar> http://wiki.bazaar.canonical.com/BzrPipeline
<idnar> mmm, okay, did bzr init on the remote location
<idnar> and now sync-pipeline seems to have worked
<AuroraBorealis> yay
<idnar> hmm, spoke too soon, that made a complete mess
<AuroraBorealis> i dont know much about pipelines =/
<idnar> okay clearly I don't understand how to use sync-pipeline :/
<AuroraBorealis> someone more knowledgable can probably help
<AuroraBorealis> although they might be in bed o.o
<idnar> I should be in bed too, it's 06:40 here
<AuroraBorealis> lol
<AuroraBorealis> bed
<vila> hi guys !
<vila> meh, hi girls and guys !
 * idnar attempts to learn bzr-colo
<idnar> hey vila
 * fullermd is shocked at the discrimination against neuters...
<vila> fullermd: :)
<jelmer> hi *
<mgz> morning all
<mgz> meeting now or in an hour?
<poolie> hi jam, jelmer, mgz
<poolie> good question
 * jelmer was wondering about that too :)
<vila> hey .
<poolie> according to my mail it would be in an hour
<jam> I'm around, but officially we were keeping the UTC time
<poolie> but, if everyone's here, we could go now
<vila> wfm
<jelmer> wfm, although I still have to finish the mumble setup dance..
<vila> jelmer: I can see that ;)
<jelmer> hah, it works :)
<mgz> is Riddell on yet? he's an hour later with me
<vila> mgz: good point, should we just wait then ?
<idnar> Branches are also hidden if they have the option "bzr.branch.status" set to
<idnar> "Hidden", "Merged" or "Abandoned".
<idnar> how does bzr.branch.status get set?
<poolie> vila, i don't see riddell yet so we should wait
<poolie> idnar, i guess you can set it through 'bzr config bzr.branch.status=Merged', and i think explorer (?) has a thing to set it
<idnar> ah okay, so no way to get it from launchpad or whatever
<vila> glitch in the matrix, both mgz and wgz are online
<mgz> ha ha, no more.
<AfC> jelmer: ping (low priority, just to chat when you get a moment)
<poolie> idnar, no, not hooked up
<jelmer> AfC: hi
<AfC> jelmer: yo
<AfC> jelmer: so, I tried, a number of ways, to bzr branch "that tree". They all failed, until I drove it down to
<AfC> $ bzr branch -r 1 foreign import
<AfC> admittedly it didn't help there is only 1.5 GB of physical memory on that machine, but they all got wedged at ~3.2 GB virtual memory and, interestingly, 315 minutes of CPU time.
<AfC> at that point, it was endless swapping.
<AfC> I haven't tried it against the tree at the remote server; that's next, but I'm getting closer to feeling I'm going to have to give up. Now that I've got revno 1 it might get a bit better to pull 1 or 10 or 100 revisions at a time.
<AfC> end
<jelmer> AfC: What kind of foreign tree is this with?
<jelmer> AfC: and what versions?
<AfC> jelmer: git
<AfC> jelmer: daily
<jelmer> AfC: hmm, that's odd
<jelmer> AfC: the launchpad importers probably have about the same resources and can handle the linux kernel
 * jelmer tries locally
<jelmer> jam: hi
<jam> hi jelmer
<jelmer> jam: Goeiesmorgens deze morgen!
<jelmer> jam: I'm trying to figure out something with stacking, perhaps you have an idea
<jam> stacking doesn't work? :)
<jam> sure, go ahead
<jelmer> jam: in some situations :)
<jelmer> jam: In short, I'm finding that if I have some revisions in a stacked-on repository and then try to fetch some ancestors of that into the stacked repository things go boom.
<AfC> jelmer: [it turns out that I was, in effect, duplicated what vcs-import already did, since `bzr missing --line --mine` reported the same revs. But that's one of the things I needed to establish before using launchpad's branch]
<AfC> duplicating*
<jelmer> AfC: yeah, the imports should be deterministic
<jelmer> jam: I'm getting an exception from pack_repo during commit_write_group() saying one of the parent texts was missing
<AfC> jelmer: In any event, I'm also going to have a go at `bzr import-upstream` across the range of trees that I'm interested in
<jelmer> AfC: import-stream?
<AfC> bzr-builddeb's import-upstream ?
<jam> jelmer: do you have a traceback I can peek at?
<jam> My immediate thought is that fetch doesn't work very well in this situation, because revision discovery will think you already have the data
<jelmer> jam: http://pastebin.ubuntu.com/702120/
<jelmer> jam: fwiw this is with foreign branches
<jelmer> AfC: Do you mean in addition to importing from Git? Since they do very different things.
<jam> jelmer: from that traceback it looks like all of the logic of what needs to be transmitted is in bzr-svn (the layers of 'fetch' are all svn, just the 'commit_write_group' is bzr)
<AfC> jelmer: in addition (separate branch family) yes
<jam> it looks like you fetched the revision texts but failed to fetch the associated file content
<AfC> jelmer: lifeless was telling me that I should also look at `import-tar` which is something I'm not familiar with. Not sure what plugin its in, even. But when I find it, I'll try that too
<jelmer> AfC: Do you mean "bzr import" from bzrtools perhaps?
<AfC> jelmer: ah, maybe. Don't [normally] have bzrtools installed.
 * AfC wonders whether I'll have more luck with bzr-builddeb or bzrtools's take on this
<jelmer> jam: The file content is in the stacked-on repository
<jam> jelmer: just getting static from you
<jam> jelmer: so the immediate thought is that the "do you have references filled in" is only checking the newly created pack files.
<jelmer> jam: I think that's the crux of the problem. What does filling in the references mean exactly?
<jam> jelmer: looking at the code it sure looks like it is properly checking everything that is in the stacked repo (so not the fallback, but everything in the repository)
<jam> 'filling in the references', if you have a revision it needs an inventory, and it needs all referenced file texts
<jelmer> jam: ah, hmm. and I shouldn't rely on those being present in a stacked-on repository?
<jam> (well all referenced file texts that aren't in the parent revisions, etc)
<jelmer> That makes sense, and I'm not doing that at the moment.
<jam> jelmer: well, you said that they were, but Bazaar is saying they aren't
<jam> jelmer: ah, you mean they are in the fallback?
<jelmer> jam: yes
<jam> no, that is not sufficient
<jam> If a stacked repo has revision X, it needs to have the texts introduced in X
<jam> otherwise it cannot create a stream containing revision X
<jam> without talking to the fallback
<jam> which we require
<jelmer> but what about texts that weren't introduced in X but are present in X?
<jam> (remote smart server does not have access to its fallback)
<jam> jelmer: if you have rev A parent of rev B, and you have (file_1, A) you don't have to have that content in a stacked repo with just B
<jam> *if* you have the inventory for A
<jam> so that we can tell whether (file_1, A) was present in the parent
<jam> so what you need is set(present_revision_texts) - set(parent_revision_texts)
<jelmer> jam: So I should fetch the rev A inventory into the stacked repository, even if it's already present in the stacked-on repository?
<poolie> Riddell, could you clean up and post those notes?
<Riddell> poolie: can do
<poolie> ta
<Riddell> poolie: I think I should take a day off bzr sometime this week to check up on Kubuntu, it's their release week
<poolie> oh good diea
<poolie> *idea
<poolie> or even more if necessary
<jam> jelmer: yes
<jelmer> jam: ok, that makes sense
<jam> jelmer: so if you want to put rev B in a stacked repository, you need to have inventory of A, and all of the texts that are in B that aren't in A
<jam> and B's inventory, of course
<poolie> mgz, vila, so https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348
<jelmer> jam: What's the easiest way of doing so (fetching an inventory into a repository if it isn't present yet, while excluding any stacked-on repos)?
<jelmer> vila: sorry, I missed that. What will I disagree with?
<vila> jelmer: making bzrlib.intialize() mandatory
<jelmer> ah
<jelmer> yes (though I wouldn't mind make it implicit and warn if it wasn't explicitly called)
<jelmer> Jelmer's bug? There's just one ? :P
<jelmer> (I lost my unity panel so I can no longer unmute :P)
<mgz> bug 863401 jelmer if you're not already there
<ubot5> Launchpad bug 863401 in Bazaar "library state now requires explicit initialization" [Critical,In progress] https://launchpad.net/bugs/863401
<vila> Riddell: thanks for sending the standup notes !
<Riddell> how can I see collision merge proposals?  launchpad times out on https://code.launchpad.net/~ubuntu-branches/+activereviews
<jelmer> poolie: it's calm and relaxing to have some typing going on in the background.. :)
<poolie> jelmer :)
<poolie> like those CDs of sea sounds
<jelmer> heh, indeed
<poolie> jelmer, it's kind of nice, maybe we should stay on mumble during the evenings
<poolie> especially if we either get noise suppression right or ptt
<jelmer> poolie: yeah, it is. I put getting a new headset on my todo list.
<mgz> likewise.
<mgz> ooh, fancy oops pages with my new team membership
<poolie> oh, tracebacks
<poolie> "fix me!"
<poolie> https://bugs.launchpad.net/launchpad/+bug/866100
<ubot5> Ubuntu bug 866100 in Launchpad itself "bug search with affects_me=on times out" [Critical,Triaged]
<nigelb> poolie: Is that the bug you just "fixed"? :D
<nigelb> ah, exposed as part of the fixing
<poolie> nigelb, now you can get to that page but it may not render :/
<nigelb> poolie: Ouch!
<nigelb> poolie: why does that happe? I thought search was fast.
<nigelb> Or at least more efficient.
<nigelb> oh. I see you're talking to stuart already :D
<poolie> jam, i'd appreciate if you can try to help the ohloh guy some more
<poolie> with his memory leak
<jam> poolie: sure, I'm guessing it is us just caching more of the indexes, but I'll try to poke at it with him
<mgz> hm, I wonder if what I was looking at yesterday was relevent then
<mgz> just doing switch created 5 repository instances, 4 of which persisted through the operation, each with five LRUSizeCache objects with a 50MB limit
<mgz> that's nearly a gig of potential cache, were they all doing stuff
<mgz> (in practice only the texts cache is *that* large)
<mgz> but if they're doing things with repos and bzr is giving them new caches each time and the old ones are being hung on to...
<vila> mgz: last warning from PP, if you don't land these proposals, I will ;)
<vila> mgz: more seriously, you proposed a fix for http://bugs.python.org/issue12544 what happened ?
<mgz> it landed, but did onieric ever move from the problem python revision?
<mgz> and yes yes, I'll land 'em... after lunch
<vila> mgz: Bon appÃ©tit !
<jam> mgz: 50*4 = 200, not quite 1GB
<jam> mgz: also, we tend to have Repository objects that live a bit long because of reference cycles.
<jam> but it would be good to understand why we would have 5 repos opened
<fullermd> "each with 5..."
<jam> fullermd: 4 persisted
<jam> ah
<jam> 5*5
<jam> sure
<vila> mgz: yup, oneiric seems to have your patch too (or its moral equivalent:  self._type_equality_funcs = {})
<mgz> okay, just one more branch to bother the rm before lunch
<mgz> ...dammit, lynx why won't you play nice with launchpad
<mgz> s/rm/patch pilot/
<mgz> jam: each time control_dir.anything happens, you get a new repo
<jam> mgz: there are some cases where we allow passing in something new
<jam> I don't remembe rexactly where
<vila> mgz: they happen to be the same this week ;)
<jam> mgz: were bugs #866107 and bug #866111 supposed to be assigned to you?
<ubot5> Launchpad bug 866107 in Bazaar "Use testresources for bzr selftest" [Medium,Confirmed] https://launchpad.net/bugs/866107
<ubot5> Launchpad bug 866111 in Bazaar "Run tests against out of process smart server" [Medium,Confirmed] https://launchpad.net/bugs/866111
<mgz> ...I'll take the first one
<mgz> the second one I find a little more scary
<mgz> okay, patch pilot bothered, lunch must be had.
<vila> mgz: approved
<jam> mgz: I just didn't know whether you were only filing them, or they were supposed to be assigned to you
<jam> not a big deal
<jelmer> jam: what's the easiest way to make sure inventory X is present in a repository itself (rather than any of its stacked repositories) ?
<jam> jelmer: X in repository.inventories._index.get_parent_map([X])
<jam> or you can use the "inventories.no_fallbacks().get_parent_map()"
<jelmer> jam: Ah, and just call repo.add_inventory() if it's missing?
<jam> jelmer: generally i would add it as part of the record stream, but I'm not sure how it works with bzr-svn
<jam> doing add_inventory is going to be a serialization/deserialization overhead
<jelmer> jam: ah
<jam> maybe add_inventory_by_delta?
<jelmer> jam: I'm already using add_inventory_by_delta to add the revision I'm fetching
<jam> jelmer: then you can chain that to add the parent inventory
<jam> I believe that add_inventory_by_delta can use any basis
<jam> it doesn't have to be a direct parent/child/sibling
<jelmer> jam: This is about making sure the basis is in the repo I'm calling .add_inventory_by_delta on
<jam> jelmer: note that delta basis can also be 'null', but that is the same as doing just raw add_inventory()
<jam> jelmer: so you are adding the inventory for B, what is the basis for that delta?
<jelmer> jam: A, but A could be in my target repository or one of A's stacked repositories
<jelmer> jam: A, but A could be in my target repository or one of A's fallback repositories
<jelmer> sorry, not sure what's up with my typing today
<jelmer> jam: A, but A could be in my target repository or one of my target repository's fallback repositories
<jam> mgz: do you have 'feed-pqm' set up from hydrazine? I'm just going through and sending your approved patches to pqm
<jam> hopefully not stepping on toes
<jam> but I'm there already
<jam> vila: it says your 863401-library-state has been sent. Did it bounce?
<jam> I don't see anything in pqm right now
<vila> look again ?
<jam> vila: I see 2 that I submitted
<jam> neither is yours
<jam> vila: maybe it bounced but you didn't get the reply?
<jam> want me to submit it?
<vila> looks landed to me
<jelmer> jam: Please have another look at https://code.launchpad.net/~jelmer/bzr/more-foreign-tests-fixes-7/+merge/76776 when you have a moment
<jam> vila: it was still in "sent to pqm" on feed-pqm, maybe it just hadn't updated yte
<jam> yet
<jam> yep, looks like
<jam> I just hit it inbetween pqm finishing it, and launchpad noticing
<mgz> hm, the release notes file could do with some sorting out
<mgz> maybe I shouldn't try and sneak in news pqm lands the next branch
<mgz> +before
<jam> mgz: pqm only takes about 30min, you can just put up a news fix
<mgz> ah, missing the day of slow pqm...
<mgz> ah, I see the ohloh thing now, twas a question not a bug
<mgz> if he's running cmd_cat repeatedly, he's going to be getting a new cache each time, no jam?
<jam> mgz: he isn't
<jam> he changed it
<jam> if you read the follow up
<jam> but yes, the original suffered from stuff like that
<mgz> yeah, I'm behind, getting there...
<mgz> hm, landing the server hangs branch and the test cleanup branch so close to each other may have not been a good idea
<jelmer> vila: more-foreign-tests-fixes-{7,9} are both ready for review
<vila> jelmer: on them
<vila> jelmer: balloon ? :)
<vila> jelmer: is that some kind of crocodile to check the reviewer actually read your proposal ? ;-P
<jelmer> vila: that test was already there, I just moved it :)
<vila> oh, ok, not there yet then ;)
<vila> ha right, just after
<vila> jelmer: -9 approved
<mgz> why so forceful vila?
<vila> hehe, took me two readings :)
<vila> jelmer: -7 approved
<jelmer> vila: merci!
<jam> jelmer: your foreign-tests-7 has 3 errors
<jelmer> jam: thanks, having a look now..
<jelmer> hmm, the other one also has 3 failures
<mgz> the pqm failure for my cleanup testcases branch is the stuff of nightmares
<mgz> there's one failure. it's on *one* of the three iterations of test_random_seed and the other two pass. the failure output make no sense at all.
<vila> mgz: you ignored the expected failures right ?
<mgz> yup, though they still confused me at first
<mgz> found one actual issue with the code, the way tests get counted needs sorting out after adopting Robert's method of injecting extra testcases
<vila> mgz: where is this test ?
<vila> mgz: oh, the one about selftest itself ?
<mgz> I'll paste in the mp.
<vila> k
<mgz> posted.
<mgz> okay, result.shouldStop is getting set somehow...
<mgz> which still doesn't really explain the weirdness, but needs afixing
<vila> ubuntu is making fun of me: The program 'selftest' is currently not installed.  You can install it by typing:
<vila> sudo apt-get install yagiuda
<vila> mgz: can' reproduce locally, any hint in stderr ?
<mgz> nope. straight up unrepoable.
<mgz> but I'm fixing this other bug, and may do one more tweak before trying PQM again
<vila> get rid of it, file a bug if you wish unless you're really using it to trigger more related issues, almost nobody use random
<vila> but in any case, it doesn't sound worth delaying the bulk of the patch just for that
<mgz> okay, got this one.
<mgz> does PQM fork vila?
<vila> no
<vila> we'd like to eventually
<vila> ... but we recently went from several hours to 30 mins, we need to recover a bit from the shock
 * vila EODing
<vila> almost :)
<jonnor> Hi. I have changes in my working tree, however I don't want to commit them to the branch I'm currently on.
<jonnor> However, bzr switch will not let me switch with "unmerged changes" and bzr shelf --all says "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-8'), ('missing parent', 'new-2'), ('missing parent', 'new-3')]"
<jonnor> What to do?
<briandealwis> jonnor: see the shelve command
<jonnor> briandealwis: shelve is what I tried, and failed as show above
<briandealwis> oops sorry jonnor â missed that :/
<briandealwis> actually, I've seen that before too, and neglected to file a bug
<jonnor> my changes are actually from an uncommitted commit if that matters
<vila> jonnor: bzr version ?
<jonnor> vila: Bazaar (bzr) 2.4.1
<vila> >-/
<vila> jonnor: please file a bug
<vila> jonnor: 'shelf' was a typo right, you really meant 'shelve' (there was a shelf command long ago in bzrtools)
<jonnor> vila: yes
<jonnor> I have no idea on how to reproduce this issue though
<vila> jonnor: file a bug anyway, adding the relevant part of your .bzr.log file will give some data
<jonnor> vila: ok
<jonnor> Is it expected that bzr commit after an attempted merge does not have any metadata like the commit message of the commit that failed to merge?
<jonnor> it seems probable that https://bugs.launchpad.net/bzr/+bug/611739 is the bug I experienced
<ubot5> Ubuntu bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside" [Medium,Confirmed]
<mgz> blast, didn't get to reviewing benoit's branch today.
<mgz> ah well, tomorrow
<vila> mgz: Just crossed my mind, you know pqm is running old versions of testtools and subunit right ?
<aidos> hello all. how do you run the tests (or better, a specific test) from the bzrlib testsuite ?
<vila> aidos: bzr selftest -s bzrlib.tests.blackbox.test_push will run only the tests whose name starts with bzrlib.tests.blackbox.test_push
<vila> aidos: some short prefixes are available: bt -> bzrlib.tests, bb -> bzrlib.blackbox, bp -> bzrlib.plugins
<aidos> vila: thanks. but is that going to run the testsuite from my installed bzr version, or from the branch I got from launchpad ?
<aidos> vila: it seems strange that I need to call bzr to run tests, especially for bzrlib where i just want to add a test to some osutils.py functions
<vila> aidos: ./bzr will run from sources, but you probably want to run 'make' before to build the extensions
<aidos> vila: thanks, now my test fails as expected, now onto the bugfix :)
<caravel> Hellooooo there :) Is there any list of apps (eg wikis) that can *sit* on a DSCM like Bazaar (using it as underlaying storage) ? Myself in particular, I'm looking for a collaborative task manager ^^
<beuno> caravel, there's wikkid
<beuno> which is a wiki engine backed-up by bzr
<caravel> beuno: yes thanks, I found this one indeed -- somehow I didn't find any ref on it at bazaar website (google helped me find it).
<caravel> Besides, it doesn't advertise to be stable yet.
<caravel> Are you people aware of more tapps of this knd, especially oriented to manage *tasks* ?
<caravel> *apps
<caravel> *kind (etc., sorry typing too fast)
<james_w> ikiwiki too
<caravel> james_w: hey thanks, I had "lost" that one ^^
<caravel> here we go, I'm lost in its plugin list again :=
<caravel> would you reckon a wiki could be turned to an efficient-enough task manager somehow ? ^^
<caravel> http://ikiwiki.info/todo/interactive_todo_lists/
<jonnor> caravel: I'd recommend an issue tracker instead
<jonnor> and I do not see any reason to care about whether the underlying storage tech on a dscm
<caravel> jonnor: well, I do. :) To start with, stricly speaking about SCM, what are your reasons to use a DSCM ?
<jonnor> caravel: so I have full access to the history, and can add to the history without having to make these changes public or be connected to a central location
<caravel> jonnor: well, I have the same requirements for managing tasks, simply ^^
<caravel> plus the will to push my changes, obviouly
<jonnor> caravel: how will conflicts be resolved?
<caravel> jonnor: how do you solve conflicts with bzr, rsync, iFolders (...) or these 2 wikis running on top of a DSCM ? Well, you need conflifts brought to your attention, access to history, then manual resolution. How is this different to files ? A task manager that would store each task and each category as a single file on disk, would suit I think. But I didn't find any ^^
<jonnor> caravel: it is just something you need to thing about when you decide on the solution. If it is OK for your users having to resolve conflicts line-by-line in text files, then something on top of dvcs might work ok
<ccxCZ> icalendar files are pretty readable
<ccxCZ> I used conics for todos for a while, replicated with bzr, I even forked it to add yaml export/import for easy editing
<poolie> hi all
<caravel> ccxCZ: thanks for your hints, will investigate
<ccxCZ> for issue tracker I find roundup interesting, but that's mail-based mostly
<wgz> hey poolie.
<poolie> hi there
<wgz> what's the current contributor agreement arrangement?
<wgz> I got Florian to do a more comprehensive version of his fix, hopefully that doesn't mean he now needs to print a pdf and find a scanner
<poolie> wgz, just an email with an attachment is enoguh
<poolie> the page is wrong and will soon be updated, if it's not already
<wgz> that's a relief.
<poolie> yes
<jelmer> 'morning poolie, É¯gz
<Riddell> poolie: how do I find merge proposals filed by udd importer?
<wgz> ehe jelmer, I'm not sure freenode would let me have that
<poolie> Riddell, funny you should ask, i was just adding that to the bug
<poolie> it even doesn't always time out
<Riddell> I tried various likely pages under ~ubuntu-branches and they all timed out
<poolie> https://code.launchpad.net/~ubuntu-branches/+activereviews does seem to work for me at the moment
<poolie> it's a quiet time of day for lp
<Riddell> Timeout error here, a curious case of launchpad working better for australia than for britain
<poolie> hit reload a few times :/
<wgz> urk, there's lots of fallout from my commit message change in bzr-builddeb jelmer?
<jelmer> wgz: oh?
<wgz> I'm looking at bug 865753 and bug 867808 and wondering if they're running versions with that change
<ubot5> Launchpad bug 865753 in bzr-builddeb (Ubuntu) "bzr-builddeb: UnicodeDecodeError" [High,Triaged] https://launchpad.net/bugs/865753
<ubot5> Launchpad bug 867808 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError in _escape_cdata(): 'ascii' codec can't decode byte 0xc5 in position 11: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/867808
<jelmer> Riddell: with the number of ~canonical-bazaar staff folks around at midnight UTC it doesn't quite seem like quiet time ;)
<poolie> http://sp.reddit.com/heavy-mallet.gif
<jelmer> ubot5: your change is only in bzr-builddeb 2.7.9
<jelmer> wgz: your change is only in bzr-builddeb 2.7.9
 * wgz is a bot too, the real mgz is sensible and already asleep so he can get up on time tomorrow
<jelmer> bug 86708 is with 2.7.0, so it shouldn't be relevant to your change
<ubot5> Launchpad bug 19066 in firefox (Ubuntu) "duplicate for #86708 Pango-enabled firefox breaks MathML support" [Medium,Fix released] https://launchpad.net/bugs/19066
<jelmer> perhaps it's even fixed by it
<jelmer> wgz: the other bug doesn't seem related to your fix either, apart from being a unicode issue too
<wgz> hm from the debian report, that first is different indeed.
<wgz> and maybe I'm just being paranoid about the second.
<jelmer> wgz: your nickname is really annoying, xchat keeps suggesting "wgrant" :)
<jelmer> wgz: see the BzrPlugins.txt attached on the second
<wgz> ah yes, 0 is not 9. woho!
<vila> . o O (No wonder I can't sleep, they are all up too)
<jelmer> whoa :)
 * Riddell offers vila some coffee
#bzr 2011-10-05
<stewart> hi! is there any way to merge in a tree but take none of the changes from it?  i.e. the merge revision reverses any changes in the branch i'm merging. (i'm trying to clean up some old release trees and have tags for each release instead of different trees, and, well, things are a total mess)
<spiv> stewart: "bzr merge FOO ; bzr revert ."
<spiv> (Then commit, of course)
<stewart> spiv, awesome!
<stewart> spiv, it's obvious now that i think about it :)
<spiv> :)
<spm> o/ spiv
<_habnabit> how can I unset pending merge tips?
<_habnabit> specifically, I have a checkout from a few years ago that I'm trying to dissect and turn into smaller commits, but apparently there's pending merges and as such I can't commit only a subset of the files
<spiv> _habnabit: bzr revert --forget-merges
<_habnabit> that'll only forget the merges and nothing else?
<spiv> Yes.
<spiv> As the help says "Remove pending merge marker, without changing any files."
<_habnabit> okay, thanks.
<Kamping_Kaiser> http://paste.debian.net/134214/ can this issue be trivially resolved (a rich root conversion somehow?) or do i have to rebranch?
<spiv> Kamping_Kaiser: looks like you just need to do "bzr upgrade" in your local branch (or delete your local branch and rebranch if you prefer; it can be faster sometimes)
<Kamping_Kaiser> spiv: thanks, i'll give it a crack. the error made it seem much more complicated then that
<Kamping_Kaiser> lightning fast conversion, thanks
<AuroraBorealis> darn, gz isn't here >.>
<_habnabit> bzr revert is giving me 'bzr: ERROR: The file id "plugins-20091211215309-7pl7ljzyayqv3ifa-2" is not present in the tree [...]'
<_habnabit> (snipped the repr of the tree)
<_habnabit> is there a fix for this?
<vila> hi all !
<vila> poolie: care to unblock https://code.launchpad.net/~vila/bzr/861472-migrate-log-format/+merge/77570 ?
<cinerama> hi vila, can i get you to do me a favour?
<vila> cinerama: hehe, probably, but ask first :)
<cinerama> vila: i need help testing a french tollfree number.  i can't dial it from here :)
<vila> cinerama: yeah, that make sense (they are often restricted to local callers)
<cinerama> vila: i'll just msg you the number if that is OK?
<AuroraBorealis> hmm, when does mgz get on? o.o
<vila> AuroraBorealis: give him an hour
<AuroraBorealis> kk
<AuroraBorealis> might be in bed then >.>
<poolie> hi vila
<AuroraBorealis> also: it seems that if you interrupt any fast-import
<AuroraBorealis> and then try to resume it, you hit this bug: https://bugs.launchpad.net/bzr/+bug/541626
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Triaged]
<AuroraBorealis> that would seem very annoying if you have to restart the entire import cause of a bug o.o
<jelmer> moin
<vila> poolie, jelmer : _o/
<jam> morning vila, jelmer
<jam> and poolie, if you're still around
<poolie> hi jam, i'm still here
<mgz> morning all
<poolie> hi mgz
<AuroraBorealis> hi.
<jelmer> poolie, jam: What do you think about landing colocated branch support in an experimental format?
<jelmer> that way we can polish the UI and actually have it tested, before we decide we're happy with the format change.
<jam> jelmer: sounds reasonable to me. My main concern was having a semi(poorly?)-supported default format
<jelmer> once we're happy we can backport the format change to 2a
<jelmer> jam: cool
<vila> jelmer: my main concern with using a dev format is that we'll get less exposure and need some migration path later, so more work for less feedback. But if that's the only way to get progress, I'll vote for progress ;)
<jelmer> vila: migration *should* be a matter of rewriting the format file
<poolie> jelmer i'm sorry it's stalled
<poolie> an experimental format seems like an ok step forward
<jelmer> cool, I'll have a look at getting it into an experimental format
<nigelb> Hrm.
<nigelb> Bzr is behaving weirdly
<nigelb> I did a bzr push to an LP branch. Its taking forever.
<jelmer> nigelb: ... bizarrely, would you say?
<nigelb> heh
<nigelb> oh bah. Nevermind.
 * jelmer wonders if he can collect a prize for being the 1 millionth person to make that pun
<jelmer> nigelb: what was it?
<nigelb> jelmer: Normally I just create a new branch, which I think is faster because of stacking.
<nigelb> This time I pushed a new branch to the top of an old branch
<nigelb> And I forgot --overwrite
<mgz> bb.test_branch.TestBranch.test_branch_broken_pack is a known random failure, right
<poolie> ok good night all
<jelmer> mgz: yes, though I thought it ought to be fixed now. Vincent landed something that should've fixed it recently.
<jelmer> have a nice evening poolie
<poolie> thanks
<mgz> vila: you landed the fix for the random fail on dev only?
<vila> mgz: what random fail ?
<mgz> ^
<vila> ECONTEXT
<jelmer> vila: 6 lines up :)
<vila> yeah, got that, but still doesn't ring a bell, searching the mps
<mgz> bug 807032
<ubot5> Launchpad bug 807032 in Bazaar "blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly on pqm" [High,Fix released] https://launchpad.net/bugs/807032
<vila> ha, that one ! Yes, apparently dev only
<vila> mgz: do you encounter it for 2.4 ?
<mgz> yup, just then.
<vila> that's the nice thing with spurious failures isn't it :-}
<vila> mgz: do you want me to make a mp targeted at 2.4 ?
 * vila re-reads the mp... so I wasn't the only unlucky guy :-}
<mgz> sec, just seeing when it originated
<vila> not sure I daggy-fixed that one :-/
<mgz> yup, 2.4 only, 's from r5954
<mgz> okay, updated some bugs and created more work for the patch pilot :)
 * fullermd reckons that's the #bzr national sport.
<vila> mgz: as in I should do a mp targeted to 2.4 ?
<vila> mgz: or just submit it directly
<mgz> I'd do an mp, but go ahead and land it.
<vila> k
<mgz> jam already reviewed the change and it looks okay
<mgz> why is blame saying "extracting 0/330/33" at me...
<mgz> something progress bar-y has messed up again
<jelmer> vila: resubmitted metadir-goes-colo, with the metadir support in a new format
<vila> jelmer: just got the mail, will review a bit later (~lunch)
<vila> jelmer: you overwrote your previous proposal with https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/78221 ?
<vila> jelmer: I can't find the previous one anymore 8-}
<jelmer> vila: true
<jelmer> vila: the previous one is pretty pointless though, it adds the colocated branch support in BzrMeta1
<vila> jelmer: sure, I just wanted to quickly re-read it
<vila> jelmer: no big deal if you don't have one easy way to provide it
<vila> should be in my mail somewhere
<jelmer> vila: for the changes, up to r6091 in the same branch
<vila> ha excellent
<jelmer> vila: for the mp and discussion: https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/72451
<vila> jelmer: approved (under the assumption you'll wait for 2.5dev3, is that correct ?)
<vila> jelmer: oh, and thanks for the pointers above, I used them !
<jelmer> vila: any particular reason you'd want me to wait for 2.5b3?
<vila> jelmer: not really
<vila> your "beginning of the cycle" was ambiguous and I read it as 2.5b3,
<vila> and my RM hat had a knee-jerk reaction thinking about tomorrow's freeze,
<jelmer> vila: oh, I didn't realize I'd left that in there. I think I meant when 2.5 opened
<vila> but that's silly :)
<vila> argh, crossing messages :) I meant my knee-jerk reaction was silly
<jelmer> ah :)
<jelmer> vila: so you're happy to have it land now?
<vila> yup
<jelmer> vila: great, thanks! :)
<vila> . o O (Now, mister PP and mister RM, would you please settle on what you want ?)
<vila> . o O (PP: land !, RM: ok, land...)
<vila> :)
<jelmer> :))
<vila> really lunch time now
<jml> I want to add boolean options to lp:udd's config
<vila> jml: I've added them to bzr >= 2.5 :-/
<jml> vila: ahh. I see.
<jml> vila: I guess it would be nice to be running more recent versions of bzr on the production machine.
<vila> jml: don' be cruel :-)
<vila> jml: in the mean time, you should be able to get_user_option_as_boolean ?
<jml> vila: not from iconfig
<vila> jml: gimme a se
<vila> c
<jml> vila: so far, I'm just doing config.get('option') == 'true'
<vila> good enough for you ?
<vila> jml: who are the intended users ?
<jml> vila: me :)
<jml> vila: so it's ok for me
<vila> cool :)
<vila> sorry for the... compatibility issues :-/
<jml> vila: no worries.
<mgz> vila: what's you're solution for getting paths out of envvars in config?
<vila> mgz: hehe, glad you mention it :)
<vila> mgz: env vars in config are used to provide default values
<vila> mgz: so the plan is to have a specific option type for paths which can define how their corresponding env vars should be decoded
<mgz> okay. and for things like BZR_LOG that don't go through config?
<vila> mgz: make them go through config ?
<vila> :)
<mgz> do we want a bottom level osutils.path_from_environment() ?
<vila> that certainly won't hurt !
<vila> mgz: oh, let me guess, you're looking at bialix's bug about the unicode home dir ?
<mgz> that, and thinking about jelmer's blocked mp
<vila> mgz: LOL
<vila> I was about to mention that too !
<mgz> and looking at the current bb.test_version tests, which are, to put it mildly, a mess
<vila> but ff has quit (why ?) and I was waiting for it to refresh to paste the url :)
<vila> mgz: +1 to clean them up, especially as a separate mp
<mgz> okay, lunch, where I shall ponder further.
<vila> mgz: briefly looking, they are very old and may even be redundant with other tests
<vila> mgz: there are a couple of strongly related topics I'd like to discuss, ping me when you're ready (and not before your lunch ;)
<vila> bad jelmer
<vila> in https://code.launchpad.net/~jelmer/bzr/deprecate-revision-history/+merge/78242 you have a === added file 'bzrlib/tests/per_repository/test_fileid_involved.py.OTHER'
<vila> o.O How did you manage that... I thought bzr add was complaining now when trying to add such a file...
<jml> this code needs a little stylistic cleanup.
<jelmer> jml: which code
<jelmer> vila: argh, looking now
<jelmer> jml: ?
<vila> jelmer: BB:tweak, the conflicts don't seem serious
<jml> jelmer: lp:udd. Nothing major, just moving stuff that's in scripts into modules, making them import safe etc.
<jelmer> vila: the odd thing is that "bzr send -o - lp:bzr" doesn't show them
<vila> jml: $deity bless you
<jelmer> vila: ah, it's a conflict.. nevermind
<jelmer> vila: dankuwelmerci!
<vila> jelmer: of course ! *You* didn't bzr add ! lp is.... misleading
<jam> vila: I wanted to check with you, does it look like I squashed the hanging issue? I just checked on babune, and everything seems to be pretty blue in the last 12 hours or so
<jam> only gentoo is 2days12hrs
<vila> jam: feel free to dig the gentoo failures
<jam> vila: yeah, it looks like gentoo is failing because it is timing out
<jam> but at least it isn't hangnig
<jam> hanging
<jam> the failing tests look like they are all taking 8-14 seconds
<jam> vila: I'm curious on your thoughts. Should we just increase the timeout, the original goal was to ensure that tests always progress, and a 4s test case seemed really long.
<jam> I don't know why they would be *legitamately* taking 14s
<jam> this test, for example: http://babune.ladeuil.net:24842/view/%20High/job/selftest-gentoo/lastFailedBuild/testReport/junit/bzrlib.tests.per_branch.test_stacking/TestStacking/test_fetch_copies_from_stacked_on_and_stacked_RemoteBranchFormat_default_/
<jam> took 14s
<jam> running it here takes 738ms
<jam> so about 20x slower on gentoo
<jam> I could set the test suite timeout to 2 minutes, but I'm still curious why gentoo is taking that long
<jam> hmm.. seems something else funny is going on as well. as the previous runs on gentoo were also under the 1s mark
<vila> jam: I wrote long explanations about my thoughts already no ? long story short: I didn't understand how you addressed the timeout leaking into the test server, your fix was supposed to address that so we have no more hangs (turned into failures)
<vila> *if* these failures are related, you didn't fix the race
<MvG> vila: Yesterday I got a mail from LP about you requesting a merge, but the linked page doesn't exist:
<MvG> https://code.launchpad.net/~gagern/bzr/bug842575-rm-resolve/+merge/78102
<MvG> Have you somehow withdrawn the merge request or something like that, or is this a bug in LP?
<ubot5> Ubuntu bug 78102 in libflash (Ubuntu) "[Merge Request] libflash 0.4.13-9 from debian unstable" [Wishlist,Fix released]
<vila> MvG: sorry about that, I deleted it after looking at it
<MvG> Who's responsible for training ubot? The above doesn't make as much sense as one might expect.
<vila> MvG: and commented on the bug, short story: you've been bitten by 'bzr resolve --all' being... not what it seems
<MvG> vila: OK, explains the missing page.
<jam> MvG: yeah, ubot doesn't understand mp links
<MvG> jam: Can it be told to understand enough to know that it doesn't understand them? I.e. ignore anything with /+merge/ in it?
<jam> MvG: I really don't know much about it, but I agree with your point
<MvG> vila: I must confess I didn't really see the connection to the other two relatives of bug 842575 you mentioned. Although I'll still trust you that there is one, besides them all mentioning conflkict resolution.
<ubot5> Launchpad bug 842575 in Bazaar "Missing file reported after resolved removal conflict" [High,Confirmed] https://launchpad.net/bugs/842575
<jam> MvG: https://wiki.ubuntu.com/IRC/Bots
<jam> vila: I'm trying to run another gentoo test run, to see if it is static failures or transient, but it just says gentoo is offline. Does it come online manually, or only at certain times of day, or?
<vila> MvG: yeah, the linl is 'bzr resolve --all' which, without an action specified, consider that the conflict has been resolved and delete the conflict and its helpers *even* if that's not true
<vila> jam: the slave is started if there is a run requiring it
<MvG> jam: Wrote a line about the bot in #ubuntu-bots-team. Let's see.
<MvG> vila: What do you mean "even if that's not true"? In the context of that bug, with a local modification and an incoming delete, what more can one do to resolve the conflict than remove all the helper files?
<MvG> jam, vila: you need any test run on Gentoo?
<vila> MvG: internally the code is different
<jam> MvG: it ran on babune, I just wasn't sure about the timing of things. You make a request, it then spins up the machine and runs it.
<MvG> vila: You mean the code for --all vs. a specific file?
<vila> MvG: that's why I didn't mark yours as a duplicate because even if they are related they are still different enough
<vila> MvG: yes
<MvG> OK, I see.
<MvG> wrt bug 842695: vila suggested discussing that on the mailing list. But as I'm not subscribed to the bazaar list, would one of you start the discussion there and summarize any results back on the bug report? I don't fancy subscribing to a high-volume mailing list just for this discussion if there is another way.
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,Confirmed] https://launchpad.net/bugs/842695
<jam> jelmer: the latest run of babune is about 2x slower than previous runs, and seems to only include your change
<jam> 6190 Patch Queue Manager       2011-10-04 [merge]
<jam>      (jelmer) Add load_plugin_translations() function. (Jelmer Vernooij)
<jam> Do you think that could affect test suite performance at all?
<jam> It doesn't seem like it should, so I'm suspecting something 3rd party
<jelmer> jam: I'd be very surprised if that slowed things down
<jam> vila: I'm trying to understand the duration things, like hree: http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/241/testReport/history/?
<jam> here
<jam> it says the test suite took 55 minutes
<jam> however, the time listed here: http://babune.ladeuil.net:24842/
<jam> for selftest-chroot-maverick is only 7m59s
<jelmer> jam: it just adds another utility function that only gets called by plugins, and has one test
<jam> is one wall-clock time and the other is test-suite time?
<jam> I see the same discrepancy between http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastBuild/testReport/history/? and http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/buildTimeTrend
<mull> hi, all.  I'm still a bit new to bzr, and wondering if there's a simple way to create a branch which is a subset of its parent (by ignoring/filtering/blacklisting files).  is this possible?
<jam> mull: there is a little bit of 'it depends'. you can do "bzr split SUBDIR", and it will create a branch that now only includes that subdirectory.
<jam> However, it won't rewrite the history, so the older revisions of that new branch will be for the whole tree
<MvG> jam: the console text appears to report the shorter time. Is that output from bzr itself or from subunit2pyunit? If it is from bzr, is it wall-clock time?
<jam> If you want to create a new history, then you want to look at the 'bzr-fastimport' plugin and stuff like bzr fastexport, bzr fastimport-filter(?) , bzr fast-import
<vila> jam: --parallel explains the difference
<jam> vila: right, so the buildTimeTrend is wall-clock, and the test suite trend is the sum of times spent in each test
<mull> jam -- ahh, fastimport sounds like the right thing.  yes, ideally I'd be rewriting the history
<mull> thanks
<jam> vila: do you know of any particular reason why babune would be slower on the recent runs? My patch landed about 4 runs ago, so I don't think it is directly responsible.
<jam> And pretty much all of the runners I've checked show a significant slowdown in the last 1-2 runs
<jam> (maybe you were using babune to do other work at the same time or something.)
<jam> like I *just* requested a full gentoo run, and it finished in wall-clock 7min57s, but the one that tried to run this morning took 24min
<jam> http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/buildTimeTrend
<mgz> jam: re test timing discrepency
<mgz> one number is how long it took from the starting the test suite to the finish
<mgz> the other is the sum of all test times
<mgz> when forking, the first can be several times smaller
<jam> mgz: yeah, that's been sorted out.
<jam> i'm calling it 'wall clock' time vs test case time
<jam> the question is why did the last test runs across maverick natty, oneiric, gentoo, freebsd all suddenly take 2-4x longer than previous
<jam> and when requesting a run of them manually, they drop back to their original time
<mgz> have you looked at the individual test timings?
<mgz> are they uniformly or by and large slower?
<mgz> or are there specific problem tests?
<jam> mgz: fast run just requested by me:http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/
<jam> mgz: slow run from a 12 hrs ago: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/529/testReport/
<jam> you can sort of "duration"
<jam> the slowest subset is the same "test_commit_builder"
<jam> but it goes from 5min to 19min
<jam> test_repository goes from 1m17s to 6m11s
<jam> test_controldir doesn't seem much affected
<jam> test_stacking is 1m6s to 4m40s, etc
<jam> digging into individual tests, you can no longer sort them by time
<jam> however, if you open both in tabs and then switch between them, they should line up
<jam> for example: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/bzrlib.tests.per_repository.test_commit_builder/TestCommitBuilder/
<jam> vs
<jam> http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/529/testReport/bzrlib.tests.per_repository.test_commit_builder/TestCommitBuilder/
<jam> some tests are roughly the same time
<vila> jam: have you looked at the dates and times ?
<jam> I don't know whether "3ms" vs "34ms" is significant
<jam> vila: across the board this seems to be the runs from this morning
<jam> ~12 hours ago
<jam> that are slower
<vila> if they all run at the same time then you've got your explanation no ?
<jam> I haven't manually requested re-runs from anything but gentoo yet
<mgz> busy disk would have an effect something like that
<jam> vila: the history trend doesn't seem to agree, wouldn't they all be starting at the same time over history?
<jam> mgz: on the TestCommitBuilder, this test test_commit_unchanged_root_record_entry_contents
<jam> in its permutations is consistently 80ms vs 300ms
<jam> note that the Remote tests seem particularly affected
<jam> going from .22s to 2.5s
<jam> vila: so yes, the test suites could be competing with eachother, but if that was the case, I would have expected that to be happening every day, wouldn't it?
<vila> no idea
<vila> jam: if the tests are not meant to cope with a server timeout, I think the server should not timeout for these tests
<vila> but that's just one more reason to use the real server... so feel free to ignore it too
<mgz> let's see what happens next auto build.
<jml> https://code.launchpad.net/~jml/udd/symbol-import/+merge/77312
<james_w> I'm guessing that what Colin reports in https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/dbus/oneiric-201107131641/+merge/67862 isn't instructive as to the cause?
<james_w> but I've seen that on a few UDD branches recently, so there is likely a bug somewhere
<jam> jelmer: I just got a email bump from your mail host:
<jam> "quota exceeded"
<jelmer> u
<jelmer> jam: oops, I'll delete some more mail
<jelmer> jam: thanks for letting me know
<jam> jelmer: I was replying to your revision_history change, which I thought I had already commented on
<jam> did you resubmit it/
<jam> ?
<jam> the issue is that it is ~ just moving the O(history) code into all the calling locations, rather than having them not actually doing it
<jam> i'm trying to think of a happy medium where we don't add new callers
<jam> but we keep the bad code in one place, rather than putting it in lots of places in the code
<jelmer> jam: there is only one place where we use it outside of the testsuite, and that's in revisionspec
<jam> jelmer: what do you think about a separate function (not a Branch method) to consolidate the code, and make it easy to find?
<jelmer> jam: I'm not sure that's actually necessary, it's just 6 calls to iter_lefthand_ancestry in the testsuite, all with known small histories
<jam> sure, just more not having to repeat ourselves 6 times
<jelmer> jam: fair enough
<Sebboh> Hi. I'm not a regular bzr user, but some source I want to check out is in a bzr repo.  I'm using the bzr that comes with cygwin. I'm on Windows 7.  I get an out of memory error when I try: "bzr branch lp:leo-editor".  Now what?
<jam> jelmer: anyway, it isn't critical, if you feel its too much work, I mostly wanted to discuss it a bit, since it seemed odd
<jelmer> Sebboh: hi
<jelmer> Sebboh: I'm not sure, it seems to work fine here with reasonable resource usage
<jelmer> Sebboh: are you actually running out of memory or does that just happen to be the error message you're getting?
<bpierre> hit
<bpierre> *hi
<Sebboh> Jelmer: I'm not running out of system memory.  But bzr.exe is 32bit.  http://pastebin.com/rXTq6fcg
<Sebboh> I switched away from the cygwin bzr, I'm using 2.5b1 (standalone installer) from http://wiki.bazaar.canonical.com/WindowsDownloads now.
<jelmer> hi bpierre
<jelmer> Sebboh: ah :-(
<jelmer> jam: I've removed one of the uses of iter_lefthand_ancestry; the other 4 seem hard to factor out sensibly so I'll keep them in for now.
<Sebboh> jelmer, after playing around with it for a while, I was able to get the repo downloaded (probably. the last stage is still running).  I used this method: bzr branch -r 2000 lp:le-editor; cd leo-editor; bzr pull -r 3000; bzr pull  ...(There are 4500 revisions total.)
<Sebboh> I did get an out of memory error in the middle when I tried bzr pull to get me from r2000 to r4500.. it was too much.  So hopefully my workspace isn't corrupt or anything crazy. (I presume not because the subsequent bzr pull -r 3000 worked without error.)
<Sebboh> So I was wrong about it working.  Turns out that pulling revision 3086 runs me out of memory, every time.  I watch bzr.exe memory usage spike from 60megs to over 500megs in less than a second, then it terminates.
<jelmer> Sebboh: that's odd, that revision isn't particularly big
<jelmer> charis:/tmp/leo-editor% bzr log -r3086 -p | wc -l
<jelmer> 1898
<Sebboh> I was thinking, maybe it just happens to be the revision that pushed the repo over some threshold.
<Sebboh> I've seen a lot of talk about using 64bit python..  That's fine, and it might work for me, but, it sure as heck doesn't address the root issue. :)  (This is a huge bug.)
<jelmer> So bzr pull -r3085 works but -r3086 breaks?
<Sebboh> Yes.  With my w ... Sorry, I have to go.
<Sebboh> jelmer: http://pastebin.com/XKJ15pJR
<Sebboh> Work has been over for half an hour; bye! :)
<MarkAtwood> hi!  i occationally get an error that looks like this:
<MarkAtwood> bzr: ERROR: No such file: u'/home/hudson/hudson/.bzr/repository/indices/c38c25468e66e50956fd947035bf3ec6.rix': [Errno 2] No such file or directory: u'/home/hudson/hudson/.bzr/repository/indices/c38c25468e66e50956fd947035bf3ec6.rix'
<MarkAtwood> when this happens, i have to delete all my branches that use that shared repo, delete that shared repo .bzr tree, and then do init-repo and start over
<MarkAtwood> this is non-optimal
<MarkAtwood> is there a better way to check and repopulate a corrupted shared repo?
<jelmer> MarkAtwood: please file a bug about this
<MarkAtwood> i jsut did
<MarkAtwood> i wish the repo wouldnt get corrupted
<MarkAtwood> but if it does, it would be nice if there was a way to have the repo grab "missing stuff" from launchpad
<jelmer> I think there's an open bug about having a command that can regenerate an index file
<jelmer> but indeed, the more interesting question is why that index is missing in the first place
<jelmer> MarkAtwood: what's the bug #?
<MarkAtwood> heh, and i just closed that tab, too
<MarkAtwood> https://bugs.launchpad.net/bzr/+bug/868785
<ubot5> Ubuntu bug 868785 in Bazaar "occasional corrupted shared reposatory" [Undecided,New]
<MarkAtwood> we run bzr under hudson, so it's constantly checking out the source of the project and rebuilding it
<MarkAtwood> so bzr branch is running many many times a day on many machines
<MarkAtwood> (which is why it uses a shared repo, to cut down on network traffic)
<MarkAtwood> when this happens, that jenkins node "jams"
<jelmer> I'm not too familiar with the repository internals but hopefully one of the other devs will have an idea tomorrow
<MarkAtwood> thank you jelmer
<spiv> jelmer: sounds like it may be the same issue the Twisted folks saw under buildbot
<spiv> jelmer: that simultaneous pulls of identical updates into a shared repo can cause symptoms like that: deleting an index file that's needed, etc.
<spiv> jelmer: it's probably possible to at least provide a repair tool to just drop the missing pack/indices from pack-names
<spiv> jelmer: but of course it'd be good to fix the root cause.  jam has a thorough understanding of the issue I believe
<spiv> jelmer: the workaround for affected users to avoid configuring their CI tools to have multiple workers doing the same work simultaneously in the same shared repo
<spiv> jelmer: e.g. no share a repo between build slavese.
<poolie> o/ spiv, jelmer, all
<Kamping_Kaiser> o.0
<Kamping_Kaiser> er, echan
<jelmer> spiv: ah, thanks
<jelmer> g'morning poolie
#bzr 2011-10-06
<GungaDin> Hi
<GungaDin> I'm trying to update my checkout and I get a "bzr: out of memory" error.. any ideas how to solve this?
<poolie> GungaDin, tell me more
<poolie> do you get a traceback in ~/.bzr.log?
<poolie> is the tree unusually big or the machine unusually small?
<GungaDin> perhaps both.
<GungaDin> it's in a virtual machine with about 1G
<GungaDin> of ram
<stewart> lifeless, question on subunit.... can "test: A\ntest: B\nsuccess: B\nsuccess: A" be valid? (e.g. executor is executing tests in parallel"
<lifeless> stewart: otp
<lifeless> stewart: hi
<lifeless> that B will be ignored
<lifeless> stewart: to do parallelism, feed the streams through a demux (e.g. the one in testr, which has its source code in testtools)
<stewart> lifeless, ahh... cheers.
<lifeless> stewart: (think about write clipping etc, even if it 'was' ok, a single pipe won't do the right thing
<lifeless> even with line buffered files, if you exceed a page in size for a single backtrace...
<lifeless> stewart: ^
<lifeless> stewart: if you're parallelising drizzlet, for instance, consider using testr (apt-get install testrepository) - it can track fast/slow tests and give you equal partitions
<vila> hello all, hellaustralia !
 * fullermd double-checks his hemisphere.
<poolie> hello vila
<vila> poolie: hello !
<vila> I'm freezing 2.5b2 right now
<poolie> it's kinda cold here too
<vila> hehe
<vila> We have a nice late summer here (crossing fingers)
<poolie> vila is bug 82555 the same as bug 242175?
<ubot5> Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555
<ubot5> Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175
<vila> Such a hard question so soon in the morning ? /me looks
<vila> poolie: possible, can't say for sure without digging, I asked Aaron about them (IIRC) at the time but I can't find his  answers there
<poolie> vila it's not a big deal
<poolie> i just thought i'd empty the new bug queue
<vila> poolie: great ! I had it on my radar but only triaged some of them last week
<poolie> 21 is enough i can feel pleased for getting them done
<poolie> but few enough i can actually get them all done today
<vila> argh, news entries added for 2.5b1 instead of 2.5b2 :-/
<jam> hey poolie, i realized I forgot to say hello today :)
<poolie> hi there jam
<idnar> how do I move some uncommited changes from one pipe to another in a pipeline?
<idnar> oh, maybe I can shelve/switch/unshelve?
<idnar> hmm, no
<mgz> morning all
<idnar> oh, no, I just messed the shelve up the first time somehow
<vila> idnar: there are some rough edges when moving this kind of changes from one branch to another, filing a bug with your actions and why you didn't end up with the desired result can help us fix them (the rough edges, not your actions ;)
<idnar> vila: as far as I can tell, I ran into a bug with bzr shelve's interactive change selection
<idnar> absolutely nothing to do with pipelines or switching branches
<idnar> filing a bug report now
<idnar> or, rather, trying to reproduce now
<idnar> *facepalm*
<idnar> okay, so I think the original problem was just user error
<idnar> although the output from bzr shelve is confusing, so I'm still going to report that
<idnar> but now I found another bzr shelve bug
<idnar> filed #868974 and #868976
<vila> ubot5: tells us more about bug #868974 and bug #868976
<ubot5> Launchpad bug 868974 in Bazaar "Confusing output from bzr shelve for the addition of a file" [Undecided,New] https://launchpad.net/bugs/868974
<ubot5> Launchpad bug 868976 in Bazaar "Traceback trying to unshelve in empty branch" [Undecided,New] https://launchpad.net/bugs/868976
<ubot5> vila: I am only a bot, please don't think I'm intelligent :)
<idnar> ah, I forgot to say "bug" I guess
<vila> ubot5: thanks nevertheless
<ubot5> vila: I am only a bot, please don't think I'm intelligent :)
<idnar> heh
<vila> good bot
<mgz> the second one Parth ran into a while back, and I see that some other people have as well
<mgz> and yes, the output of the first makes perfect sense to me because I understand all the bits, but I can see how it's confusing
<vila> poolie, jelmer, mgz, RIddell, jam: RM.takes_social_lock(lp:/bzr) for at most 2 hours, please don't land there (the source is already frozen and your landing will be wrong anyway. I'm running 'make check-dist-tarball' before submitting to pqm)
<mgz> vila: have you merged up 2.4 yet?
<mgz> because that would be useful
<mgz> but... I guess isn't the end of the world if you didn't
<vila> mgz: oh, if you want me to talk about that ... :)
<vila> mgz: yes I did, small conflicts easy enough to resolve
<vila> mgz: but in the general case, it's easier for the dev landing fixes in the previous releases to merge up to trunk, if conflicts occur, he is the one with the best knowledge to handle them
<vila> mgz: I've added a note in releasing.txt about doing the check nevertheless
<mgz> cool, thanks vila.
<vila> make check-dist-tarball succeeded, submitting to pqm, social lock taken
<vila> mgz: my pleasure ;)
<vila> poolie: regarding lazr/restfulclient while running check-dist-tarball, I usually ignore http://paste.ubuntu.com/703271/ as harmless, I never dig that, I've seen related discussions (AIUI) about it, do you know if doing a new release will solve it ?
<poolie> jelmer, re bug 868981, is there any point filing a memory usage bug?
<ubot5> Launchpad bug 868981 in Bazaar "Failed to branch git repository (invalid record 0x03)" [Undecided,New] https://launchpad.net/bugs/868981
<poolie> vila, i think that noise is caused by https://bugs.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/796992
<ubot5> Ubuntu bug 796992 in lazr.restfulclient (Ubuntu) "pth file overrides pythonpath" [High,Triaged]
<poolie> i don't understand why that code is there and the bug is not fixed so merely doing a new release will probably not help
<vila> poolie: ha, right, yeah, that's the bug I had in mind, thanks, I'll subscribe
<jelmer> poolie: yeah, it shouldn't be trying to load everything into memory
<vila> poolie: you landed on bzr.dev :-/ That won't be included in 2.5b2
<mgz> I think it'd been sent before you said vila.
<vila> mgz: yes, but after I said I was freezing :-/ I can't check everything everywhere *and* freeze :-(
<vila> poolie, mgz: no big deal, bug mark fixreleased in 2.5b3, lp:bzr history will disagree but the tarball is authoritative and doesn't include the fix, I'll open 2.5dev3 now
<vila> social lock still held
<vila> sent
<vila> social lock released. Waiting for the current submission to succeed will be a good idea though
<vila> 2 hours between announcing I was freezing and releasing the lock, probably the fastest release I ever made despite having to merge 2.4 and fix the news
<vila> if the social trick doesn't work, we'll have to find another solution
<vila> freeze announce for 2.5b2 sent, for the benefit of packagers and build installers present here: the tarball has been uploaded, you can't push the build button (I know some buttons are harder to push than others ;)
<vila> s/can't/can/
<jam> vila: thanks for the heads up
<jam> and good job on the release
<jam> having PQM run in 30 minutes certainly helps
<vila> yup, it's a direct factor for the social lock
<vila> duration
<jam> ugh, poolie, I accidentally left the ec2 instance running after the last build. I wonder if there is something we could do to help me remember.
<jam> I usually shut it down same-day.
<jam> Maybe a cron script that sends a daily email?
<poolie> could be good
<poolie> can you schedule a shutdown for 24h in the future when you start it?
<jam> poolie: I don't see any way to do so, do you know of one?
<jam> poolie: http://www.cyberciti.biz/tips/schedule-windows-server-to-reboot-or-shutdown-automatically.html ?
<jam> I'm a little hesitant to do it via 3rd party tools
<jam> this one might work: http://www.computing.net/answers/windows-2003/schedule-shutdown-the-server/5216.html
<jam> just set up the instance to always shutdown at midnight my time.
<jam> so if it is "up" it gets stopped
<poolie> jam, i haven't done it for a while but i thought there was a built in option
<jam> poolie: the second link tells how to set up a scheduled job that runs 'shutdown.exe'
<jam> looks like it will work, I'll give it a shot.
<poolie> yeah, from the command line, i thought so
<jam> vila: we have 'lp:bzr/2.5' is there a reason it doesn't have bzr-2.5b2 tag in it?
<vila> we shouldn't have lp:bzr/2.5
<jam> hmmm... I dont't see one in lp:bzr either
<jam> vila: https://code.launchpad.net/bzr/2.5 is actually pointed at trunk
<jam> so it exists, but for now it is just the trunk branch
<jam> just an *alias* for trunk
<mgz> oo, aix buildbot offer
<jam> regardless, I don't think we have bzr-2.5b2 available as a tag to build from
<jam> so I can't actually build the windows installers easily
<jam> I suppose I can pick a rev instead of a tag
<vila> jam: thanks for the heads-up, looks like I missed a step
<jam> vila: do we have a patch pending? We could get it to merge trunk and add the tag
<jam> vila: I have one, I'll go do the tag dance.
<vila> jam: sent
<jam> Do you want your rev or PQM's rev to have the tag?
<vila> jam: I just sent a submission to fix that
<jam> vila: sure, though I don't see it in PQM yet
<vila> shouldn't be long now
<vila> here it is
<jam> there it is
<idnar> oops, apparently I didn't search hard enough for dups
<fullermd> Oh, frew.  It just occured to me to wonder "Jeez, why haven't I seen any bzr commits in a month?"
<mgz> yeah, you need to join a new team fullermd
<fullermd> No, apparently the last round of PQM changes changed how the emails were generated.
<fullermd> So they fell through my existing filters and wound up bitbucketted.
<mgz> ah.
<fullermd> At least, that's my best guess...
<mgz> you have PQM telling you about bzr commits?
<fullermd> The -commits list.
<vila> bazaar-commits.lists.canonical.com, right
<vila> fullermd: just curious, I didn't have issues here, what filter were you using ?
<fullermd> Which makes it half-suck, 'cuz it means I don't even get to work up a good blood pressure overload about LP's emailing over it...
<fullermd> Throwing away everything that wasn't from pqm@pqm.ubuntu.com.
 * fullermd waits for the next submission to run through to try and figure out how to discriminate now...
<vila> meh, correction, I don't get them anymore either since 2011-09-07 :-/
<vila> oh, I think I know, probably due to the migration to a new hardware
<fullermd> You mean it's not actually sending them anymore?
<fullermd> Well, that makes me feel better about my filters anyway...   :p
<vila> fullermd: seems like it, thanks for the heads-up
<vila> not that I read these emails with a great attention but it's a good heart-beat under some circumstances
<fullermd> I use them to keep track of "all the back-branches are merged to .dev, time to pull again"   :p
<vila> fullermd: reported, fix seems easy, should be back soom
<vila> soon
<poolie> night all
<mgz> night poolie
<vila> poolie: night
<jam> night poolie
<jam> I'm trying to decide how well "Precise" works as a release name. "We need to get this into Precise" doesn't seem to fit as well as backporting it to hardy and lucid.
<jam> Maybe it is just repetition that makes the others ok
<fullermd> They all sound equally weird to me, if that helps   :p
<fullermd> I always find myself waiting for the next line when people end sentences with adjectives like that...
<mgz> bug 84822 and the linked debian bug are straight up fixed by the inclusion of the bash-completion plugin, no?
<ubot5> Launchpad bug 84822 in Bazaar "bash completion should use shell-complete" [Medium,Confirmed] https://launchpad.net/bugs/84822
<jelmer> vila: can we land stuff again?:
<vila> jelmer: yup
<vila> 11:22 <vila> social lock released. Waiting for the current submission to succeed will be a good idea though
<vila> I forgot to prefix my msg though
<vila> mgz, Riddell: go ! Land ! :)
 * mgz swoops down
 * fullermd chooses to Sea instead.
<mgz> I want at least one more babune run with the current trunk before landing my cleanup testcases branch
<vila> mgz: looks like you're right about bug #84822
<ubot5> Launchpad bug 84822 in Bazaar "bash completion should use shell-complete" [Medium,Confirmed] https://launchpad.net/bugs/84822
<vila> mgz: hehe, I wasn't reminding you about that, just making sure you knew I wasn't locking bzr.dev anymore ;)
<vila> jam, mgz: speaking of babune, freeBSD and OSX failed, different tests than gentoo yesterday
<mgz> who've we got that can mark debian bugs fixed? jelmer?
<jam> vila: for this failure: http://babune.ladeuil.net:24842/view/OSX/job/selftest-osx-10.6/lastCompletedBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/test_fetch_parent_inventories_at_stacking_boundary_smart_old_InterDifferingSerializer_RepositoryFormatKnitPack1_RepositoryFormatKnitPack6RichRoot_/
<jam> the patch should have just landed in bzr.dev
<jam> 6197
<jam> the other one I have to think about
<jam> I think I know a fix
<jelmer> mgz: Everybody can mark debian bugs fixed
<vila> huho babune consuming 300% CPU without any job running, bad stuff
<fullermd> Isn't that what java stuff is _supposed_ to do?
<vila> fullermd: right.
<vila> fullermd: but they don't do it usually :)
<vila> jam, mgz : Are you querying unusual stuff ?
<jam> vila: i'm not doing anything on babune atm
<jam> I did go look at the tests a few secs ago
<vila> including browser queries I meant
<vila> nothing in the logs, scary...
<vila> CPU is back to normal but something is still reading at 12MB/s
<vila> done
<vila> weird
<jam> vila: I'm going to do a test run on OSX, in case this is specific to osx
<jam> (specifically, we .accept() and then .close() right away, which OSX might trigger as an error on the client)
<jam> but I think that test has passed on OSX before, but I'll check
<jam> vila: there isn't a "selftest-subset-osx" am i just missing it?
<vila> s/osx/macadam/ hysterical raisins
<vila> http://babune.ladeuil.net:24842/view/OSX/job/selftest-osx-10.6/lastCompletedBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/test_fetch_parent_inventories_at_stacking_boundary_smart_old_InterDifferingSerializer_RepositoryFormatKnitPack1_RepositoryFormatKnitPack6RichRoot_/history/? is... quite weird
 * mgz touched nothing babuney
 * vila blames gremlins
<fullermd> The whole "don't feed them after midnight" instruction was frustratingly unclear about the effect of timezones and leapseconds...
<vila> fullermd: WHAT ? It's not UTC ??? OMG
<fullermd> Well, is it UTC, or UT1, for instance?
<vila> NFC or NFD ?
 * fullermd is pretty sure "NFC" contributed significantly to the damage caused by gremlins   :p
<jam> vila: sure, the specific failure of that test was a timeout, but as you can see the time spent is *all* over the map
<jam> 5s, 2 min, 4s, 2m11s, 2m38s, 4.3s, 1m28s
<jam> now *that* is variability
<vila> it's so huge I'd be surprised if there isn't a bug behind that for quite some time
<vila> but the test succeeded... I can imagine it was starved by other threads... but that implies quite a sucky scheduler
<vila> oh, wait, mgz, wasn't there a bug about testtools/subunit outputting bogus timestamps ?
<mgz> er, hm?
<mgz> don't think I've seen it.
<jam> vila: at one point it was mixing the timestamps from multiple streams
<jam> but that wouldn't be strictly 'bogus'
<vila> yeah, something like that
<vila> mgz: I lost track about bug 807032, is there something I should do ?
<ubot5> Launchpad bug 807032 in Bazaar 2.4 "blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly on pqm" [High,In progress] https://launchpad.net/bugs/807032
<vila> wow, nice touch ubot5, indeed, only the 2.4 bugtask is relevant here
<vila> eeerk ! lunch !
<mgz> oo, good idea vila
<mgz> vila: you should cherrypick the fix back to 2.4
<mgz> (as ubot5 told you)
<jam> ugh, jelmer is missing
<jam> his version-info change is actually incorrect
<jam> it *doesn't* change the revision that is analyzed (the working tree)
<jam> it only changes what revision gets *reported*
<jam> which is pretty badly broken
<jam> (So it will say the files are at state X, but the Revision is at state Y)
<vila> Riddell: regarding https://code.launchpad.net/~benoit.pierre/bzr/ui.confirm/+merge/77826 , what's the best practice for i18n ?
<vila> Riddell: more precisely
<mgz> good poke vila, getting Riddell to look at it is sensible
<vila> Riddell: we have a list of choices to translate with the constraint that a shorcut should be available for each choice (so unique)
<vila> Riddell: what do translators prefer ? A single string with all choices ? Separate strings but somehow (for what value of somehow ?) grouped so they can respect the constraint ?
<jam> jelmer: I think you missed my earlier comments. Your fix for bug #238705 isn't quite correct
<ubot5> Launchpad bug 238705 in Bazaar "version-info command should take branch argument and -r option" [Low,In progress] https://launchpad.net/bugs/238705
<jam> changing _get_revision_id just changes what revision is reported
<jam> but doesn't change what tree is analyzed
<jelmer> jam: Sorry, I did indeed. I just saw Vincent's approved message
<jam> yeah, I sent it after it was merged
<jam> I didn't see the proposal earlier
<jelmer> jam: it does seem to influence the tree here, but perhaps not for all formats
<jelmer> charis:~/src/bzr-svn/trunk% ~/src/bzr/version-info-args/bzr version-info -rtag:bzr-svn-1.0.0
<jelmer> revision-id: jelmer@samba.org-20090924110140-gl7z957rc35m0csc
<jam> jelmer: sure, but that is only the *revision* that is reported, not the tree state
<jam> you probably have to pass --include-file-revisions
<jam> or --check-clean, etc.
<jelmer> the date and revno that's reported is also from 2009
<jam> I was originally going to say that "--check-clean" shouldn't be allowed with --revision
<jelmer> jam: Ah, hmm
<jam> and then tracked it down to see that file revisions, etc wasn't touched
<jelmer> I'll follow up to your comment
<jam> and I'm not sure about "--revision-history"
<rawtaz> hi, i would like to ask you guys if anyone can comment on the state of the bzr plugins for IntelliJ IDEA - are they up to date and covering current bzr features, or is there anything missing?
<jam> rawtaz: I haven't heard much about them for a while, so they are probably a bit out of date
<rawtaz> i see bzr4idea is 2009-07 the latest, and Bzr4IntelliJ is from 2011-02
<jelmer> jam: I need to go into the city for a bit, will follow up once I get back.
<jam> k
<rawtaz> thanks jam
<Riddell> vila: I don't think it matters much for translators if it's all separate or in one string
<Riddell> I think translators will want a comment to know the restrictions but we don't current support comments on our translations
<vila> Riddell: how do they know they are related on must define different shorcuts for each ?
<vila> s/on/and/
<Riddell> vila: we should support comments on translation
<vila> Riddell: the menus are likely to have the same requirements no ?
<vila> hmm, may be not, may be the first (or last) shortcut in a menu is taken into account... We can't afford that in the general case... but may be waiting for bug reports will be enough ?
<vila> >-/
<Riddell> what menus?
<vila> any application menus
<Riddell> in GUIs?  Qt is usually smart enough to sort out the shortcuts for you
<vila> hehe, bad choice vila, try again
<vila> Riddell: the mp I referred proposes a special char to identify the shortcut, no smarts ;)
<Riddell> alternatives = '&yes\n&No'  so the ampersand is used for the shortcut?
<vila> yup
<Riddell> that's the same as GUIs so most translators will know about it already
<vila> so better stick with a single string ?
<Riddell> I don't think it matters either way
<Riddell> single string is fine
<Riddell> if char == 'y':  that isn't working with translations though
<vila> yup, the proposal returns an index but I raised the issue that requiring the callers to get back the shortcuts untranslated is awkward.
<Riddell> shouldn't it be smarter and know what the shortcut char is for the option rather than hardcoding 'y'?
<vila> Either the callers should use the indices directly or we should find an easier way
<vila> Riddell: the issue with using the shorcuts in the caller is that we want to keep using the english ones
<vila> Riddell: but if it's too hard I'd rather use indices (or constants ?) instead or just a simple string listing the shorcuts alongside the choices themselves... bah, shelve have an optional 'e' that will break that too...
<mgz> `bzr clean-tree --force --ignored -q` is a bit annoying to type
<vila> bzr alias ?
<fullermd> Just needs a M-x in the middle somewhere.
<vila> :)
<mgz> the errors in <http://paste.ubuntu.com/703377/> are because the branch that was landed to check the version of testtools and use different assertions is busted in some respect
<vila> ok
<vila> so kind of related to the bug as it may blow up if pqm is upgraded ?
<mgz> yup, dependencies suck.
<vila> mgz: meh, I asked the question in the wrong channel 8-)
<vila> mgz: and you replying here didn't help me realize :)
<mgz> but due to the magic of highlights I saw it anyway
<vila> hehe
<mgz> jam: do I need to do something extra to turn on more cython warnings?
<mgz> because just running build_ext (in a clean tree) isn't complaining about uninitialised variables
<mgz> maybe they reverted a change on trunk?
 * mgz looks at changelog
<mgz> maybe: <http://trac.cython.org/cython_trac/ticket/714>
<mgz> ...seriously, their only changelogs are on their wiki?
<mgz> and for 0.15.1 their release notes consist of a link to trac and a link to github
<mgz> that looks like the answer though, frivolous warnings were disabled
<vila> compiz, 1GB is just too much, give some back or I'll kill you
<mgz> compiz won.
<mgz> the OOM killer got vila instead.
<james_w> vila, hi, not sure if you're getting mail for https://code.launchpad.net/~jml/udd/symbol-import/+merge/77312
<vila> james_w: I think I do, but I opened the page yesterday and missed your review :-/
<vila> james_w: oh, you did review more, wth ?
<james_w> I think it may be that you got a notification through being asked to review via a team
<james_w> when someone does that review LP no longer mails that team
<vila> crap
<james_w> this bites me all the time, as all you see in that case is a request for you to review, and you don't see that someone else has done it
<james_w> and yes, I've filed a bug
<vila> james_w: subscribed, thanks for the heads up
<mgz> hm, tree transforms are hard, I'll go back and look at cython warnings instead
<marienz> I have two branches that do not currently share history that I want to combine. Should I branch one into a temporary subdirectory of the other, "bzr join" that, and then "bzr mv" everything to its proper place? Or is there some neater way?
<marienz> oh wait, I guess "bzr join" doesn't commit, so I can just do the join and the following moves and merging of toplevel files in one commit? Does that make sense?
<marienz> I should just try instead of bugging you folks :)
<briandealwis> thx vila for #861472
<vila> briandealwis: my pleasure (your timing was perfect ;) Feedback welcome !
<briandealwis> The only thing that springs to mind, since you're looking at the config format, is that it would be nice to have some way to override variables on a per-command basis.  For example, to cause log_format=line for pull only.  I have a datetime_format var for tiplog, but I call it tiplog_datetime_format to ensure it won't stomp on any other toes
<vila> briandealwis: option expansion may address some cases (but it's not fully there yet): pull.log_format = {log_format}
<briandealwis> that'd be very useful
<vila> briandealwis: you can also use aliases
<briandealwis> That's what I do now.  Doesn't work when you execute a command remotely through ssh or within an editor though
<vila> briandealwis: but abusing -O will render all other config files useless so... time will tell
<vila> briandealwis: also, if you start introducing config options, the stack based design have a registry so you're either /guaranteed to have your own option/ or /your plugin won't load/
<briandealwis> vila: okâ¦ I think. You mean I'll *have* to put something like 'tiplog.datetime_format = {datetime_format}' somewhere or else the plugin won't load?
<vila> briandealwis: no, you have to config.option_registry.register(Option('tiplog.datetime_format', ....))
<vila> briandealwis: EOD here, but feel free to ping tomorrow for more
<briandealwis> ok
<mathrick> re: bug #838469, should improvements to mini-tutorial be submitted for released versions as well, or will they only be accepted for bzr.dev?
<ubot5> Launchpad bug 838469 in Bazaar "Mini tutorial doesn't explain repository directories" [Low,Confirmed] https://launchpad.net/bugs/838469
<rawr> good question.
<mathrick> also, do we have history horizons (aka shallow checkouts) yet?
<mathrick> heh, "Say a project FOO is running for 30 years, accumulated 100 000 revisions and the repository has grown to 1GB1."
<mathrick> also known as 'emacs' :)
<jelmer> mathrick: there are stacked branches, and it's possible to do commits on top of stacked branches in newer versions of bzr
<mathrick> jelmer: yes, I (re)discovered that a bit after I asked
<JordiGH> How can bzr avoid using hashes for commits? I don't get it, heh.
<jelmer> JordiGH: I'm not sure I follow, avoid hashes where?
<JordiGH> Hm, this doc gave me the impression that bzr didn't use hashes, only revision numbers: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html
<mathrick> in the UI, yes
<jelmer> JordiGH: it uses globally unique identifiers to identify commits too, but those aren't generally shown in the UI
<mathrick> in the underlying trees, no
<JordiGH> Does "UI" mean "GUI"?
<mathrick> any user interface
<mathrick> if you type "bzr revno", it's a type of user interface too
<jelmer> e.g. "bzr log --show-ids" will show the UUIDs too
<JordiGH> Ah.
<JordiGH> I don't know, it sounds like revision numbers would cause a lot of problems for a distributed workflow to the point of being useless.
<JordiGH> Is there some clever solution here?
<jelmer> JordiGH: in practice they work reasonably well
<mathrick> JordiGH: yes, you always refer to revnos in the context of a specific branch
<jelmer> JordiGH: if I saw r4343 of trunk, that has meaning
<mathrick> which is how you work in practie
<mathrick> *practice
<JordiGH> I don't see in "bzr" a concept of clones like in git or hg. What is a "branch" in bzr? Is it a clone? A path in the DAG? A ref?
<JordiGH> When you delete a "branch", what do you delete? A ref? A filesystem tree? The entire repository?
<mathrick> what are you trying to accomplish by asking that?
<JordiGH> Trying to understand bzr.
<mathrick> read the user guide, it has more info than you can wish for!
<mathrick> bzr has really solid docs
<JordiGH> "branch" means something very different in hg and git. I want to know what it means in bzr.
<mathrick> http://doc.bazaar.canonical.com/en/
<JordiGH> Can I see a bzr definition of "branch"? I don't see it in the docs. Seems to be a concept you have to osmose instead.
<mathrick> branch is a DAG with a specified tip
<JordiGH> So if I delete a branch, I delete a whole path in the DAG?
<mathrick> depends on where the revisions are stored
<JordiGH> Wait, there is more than one DAG? Or is it the same DAG, just disconnected?
<JordiGH> Can a repository have more than one DAG?
<mathrick> bzr branches might have their working trees and their repositories physically separated
<mathrick> JordiGH: a repository *is* a DAG. But it need not be connected, no
<mathrick> a branch is, in practical terms, a tip plus a bunch of metadat
<mathrick> a
<JordiGH> Uhm.
<JordiGH> So it's a ref?
<mathrick> you need to ask jelmer, he understand git terminology :)
<mathrick> but I think so, yes
<JordiGH> A tag? A bookmark? Just metadata, like in git? So when you remove a branch, you only remove metadata?
<wgz> <JordiGH> Can I see a bzr definition of "branch"? I don't see it in the docs. Seems to be a concept you have to osmose instead. <- <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/core_concepts.html>
<mathrick> depends on where you stored the repository. If it's a standalone branch, then it will have its data stored in the same dir as its working tree, so if you delete this directory (which is what bzr would call "removing a branch"), you will kill these revisions as well
<mathrick> if it used a shared repo, which is the recommended setup for large-scale usage, then no, it won't touch the stored revisions
<JordiGH> wgz: Thanks.
<JordiGH> Okay, a branch is a path in the DAG. I'm ok with this.
<JordiGH> Not like git.
<mathrick> actually multiple paths potentially, since there's no limit on the number of parents a revision can have
<JordiGH> Right, a tip plus all its ancestors. That's a branch, right?
<mathrick> yes
<mathrick> JordiGH: git's branches are somewhat similar to bzr's lightweight checkouts
<JordiGH> bzr's branches sound more like hg's branches.
<mathrick> there's a plugin emulating git-style (aka "collocated") branches with a shared repo + checkouts
<JordiGH> No, I don't want git. :-)
<JordiGH> I just want to understand bzr.
<mathrick> I'm giving information
<JordiGH> I'm writing a long diatribe on how much I hate git, but to be effective, I have to understand what other DVCSes do and hence why git is so weird and badly designed. ;-)
<mathrick> what do you use instead?
<JordiGH> I use hg. But bzr seems like someone actually stopped to do a user-friendly design too, which is already a big ++ over git.
<mathrick> JordiGH: actually git's model of multiple-branches-inside-a-dir is effective in practice and bzr is moving to adopting that officially in the future. We just avoid requiring you to have a PhD to work with bzr
<mathrick> and yeah, bzr's design was "get it right first, then make it fast"
<mathrick> which is the exact opposite of how git's went
<JordiGH> That seems like a minor implementation detail? I don't care too much about that. I care about what is actually exposed to users. Is the one-branch-per-directory (is that how it is now, right?) a burden on the user? It doesn't sound so bad to me.
<jelmer> yeah, it's one branch per directory at the moment
<mathrick> JordiGH: in heavier usage it's somewhat unwieldy and that's why the direction is to expose multiple collocated branches by default in the future
<mathrick> but currently it's still one-per-dir
#bzr 2011-10-07
<poolie> hi all
<mathrick> hiya poolie
<mathrick> poolie: <mathrick> re: bug #838469, should improvements to mini-tutorial be submitted for released versions as well, or will they only be accepted for bzr.dev?
<ubot5> Launchpad bug 838469 in Bazaar "Mini tutorial doesn't explain repository directories" [Low,Confirmed] https://launchpad.net/bugs/838469
<poolie> hi mathrick
<poolie> we can take doc updates for released versions
<mathrick> poolie: great, should I then make a patch against the 2.4 braching point, or should I rebase it, or should it rather be cherry-picked for release branches?
<poolie> just do a revision based off lp:bzr/2.4 tip
<mathrick> OK
<vila> hi all ! Happy Friday !
<AuroraBorealis> yay
<jam> morning all
<jbicha> hi, is there already a bug open for bzr-builddeb's lack of support for .tar.xz? that's going to be especially annoying since GNOME 3.3 won't ship other tarballs
<mgz> morning all
<poolie> jam, hi - you're feisty today! :)
<jam> mgz: I have some ideas about bug #869366, are you looking at it, or just reporting it for posterity?
<ubot5`> Launchpad bug 869366 in Bazaar "TestTCPServerInAThread.test_server_crash_while_responding random failure" [Medium,Confirmed] https://launchpad.net/bugs/869366
<mgz> just reporting, as I ran into it EOD yesterday
<mgz> I seem to be getting lucky with random failures on PQM
<mgz> looking at the test, it seems possible for the subthread to not do any futher work after the sync
<vila> mgz: yes, that's the race I was mentioning the other day, the same one exists for the test just above, it triggers very rarely and it took quite a while to put my finger on it
<vila> mgz: the main thread really want to wait for both the connection thread to raise the exception *and* to the server thread to re-raise it
<mgz> I'm not even sure what tools python gives us to resolve such problems
<mgz> I guess in this case try:/raise/finally:/sync2 would work?
<mgz> because the exception won't propogate until the test looks for it?
<vila> mgz: the test looks for the exception to be swallowed :)
<jam> mgz: for that particular test, you could call 'server.stop_server()" instead of "server.pending_exception()"
<vila> mgz:  the previous test (test_server_crash_while_responding) looks for the exception
<jam> stop can be called twice
<jam> and that way it will have joined its threads
<vila> which is not what the test is about: test_exception_swallowed_while_serving
<vila> this a test about the server not about the client
<vila> we don't want the server to shut down, we want it to keep serving (swallowed_while_serving)
<jam> vila: that is the other test
<jam> "test_server_crash_while_responding" wants it to raise the exception
<jam> we can just change pending_exception to stop_server and it will sync with the clients
<jam> client threads
<jam> maybe connection threads is a better term
<jam> though I guess that doesn't make the tests symmetric except for the exception being ignored.
<vila> with 'that' == test_server_crash_while_responding, this test is about crashing the server, not shutting it down
<vila> pending_exception is what is used to implement shutting down
<vila> which illustrate why I disagreed with your modifications which were about client behavior and as such replacing these tests instead of adding your owns
<vila> bug mgz encounters the issue in 2.4 so your modifications are out of scope here
<vila> mgz: by the way, thanks for filing that bug, I thought I did as this failure has been seen on babune on several occasions (rare enough to not trigger a fix)
<mgz> hm yes, I might not have said that in big enough letters in the bug, but this was a landing on the 2.4 branch
<vila> mgz: ... and *never* triggered on pqm AFAIK... before you claimed the unlucky badge :)
<mgz> two different random failures in about four landings on 2.4 PQM is pretty good going
<vila> mgz: yup, don't let them go ! :)
<mgz> oh hey, looking at babune, lucid is red
<mgz> and guess what the failing test is :)
<vila> mgz: but can we assume the cause is the same now that the test is not ?
<mgz> ...one thing going for testtools is seeing both tracebacks makes this miles clearer
<mgz> vila: if there's still just the one sync before the raise, then yes I think
<vila> mgz: I was kidding ;) test_server_fails_while_serving_or_stopping shouldn't suffer from the same race because it explicitly call stop_server I think...
<poolie> hi mgz, vila
<vila> helli pooloe
<vila> meh
<vila> hello poolie ;)
<mgz> hellipolis?
<vila> mgz: so the ' Wait for the exception to propagate' is a lie, it waits for the exception to be 'about to be raised' and just doing 'sync.wait()' is not enough to guarantee that. That's where the race is. A possible fix will be to connect with another client and get served properly (i.e. yes, the server is still up and running)
<vila> mgz: trying to be more precise would require hooking somewhere the server really swallows
<vila> mgz: hehe, but that's in fact required as this test server cannot server properly (by test design :)
<AuroraBorealis> is there a way to force bzr to use its built in ssh rather then another ssh that is on the path?
<AuroraBorealis> (installed git, and of course it has an ssh.exe that causes bzr to just hang for some reason)
<jam> AuroraBorealis: "export BZR_SSH=paramiko"
<AuroraBorealis> where do i put that if i'm on windows?
<jam> if you're on Windows it is spelled
<jam> set BZR_SSH=paramiko
<jam> but you can set it in global env vars
<jam> right click My Computer, Properties, Advanced System Settings, Environment Variables
<AuroraBorealis> ah kk
<AuroraBorealis> user or system variable, does it matter?
<jam> AuroraBorealis: doesn't matter for you
<jam> depends if you have more than one user on the machine
<AuroraBorealis> but python getenv can access both ?
<AuroraBorealis> (guess just a python question now =P )
<mgz> bug 641330 is the shelve issue
<ubot5`> Launchpad bug 641330 in Bazaar "unable to unshelve shelved root-id change" [Medium,Confirmed] https://launchpad.net/bugs/641330
<mgz> bug 82555 looks like the root cause
<ubot5`> Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555
<mgz> bug 242175 is the mitigation for that Riddell added for the merge case
<ubot5`> Launchpad bug 242175 in Bazaar "ValueError: WorkingTree.set_root_id with fileid=None when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175
<mgz> AuroraBorealis: windows merges them before starting a process as your user
<AuroraBorealis> k
<AfC> Do bzr-builddeb's `import-upstream` and bzrtools's `import` use the same change detection / file-id (ie, file checksum, perhaps) algorithms?
<AfC> (anyone know?)
<AuroraBorealis> not me :>
<jelmer> AfC: hi
<jelmer> AfC: change against what?
<AfC> jelmer: hi
<AfC> jelmer: so, in both cases, there's considerable work done to detect (for example) renames, right?
<AfC> [so I infer]
<jelmer> AfC: no, no renames are inferred in either case as far as I know
<AfC> oh
<jelmer> I could be wrong, I don't have much experience with either
<jelmer> actually, "bzr import" could help
<jelmer> since it doesn't commit
<jelmer> so you can do "bzr import ..; bzr mv --auto; bzr ci -m 'import x'"
<AfC> jelmer: ok, well, it's doing *something* for the minutes of CPU time its sitting there burning away
<AfC> mv --auto, yeah, that might be interesting
<jelmer> AfC: which one is burning CPU? import or import-upstream?
<AfC> [both]
<AfC> I just now did an import; import-upstream was taking ~9 minutes each.
<jelmer> AfC: what are you importing?
<AfC> :)
<AfC> that large well known project prominently using someone else's version control system that I've been blundering along with this p
<AfC> past week
<AuroraBorealis> if its git, we are already seeing that fast-import or whatever is taking huge amounts of time / memory.
<AfC> AuroraBorealis: so I'm not working with bzr-git in this case; I've instead used bzr-builddeb's facilities against the upstream project's release tarballs.
<AuroraBorealis> ah
<jelmer> AfC: I don't think either import or import-upstream have been optimized for kernel-sized trees..
<jelmer> AfC: any particular reason you're not using the launchpad imports, or are you just seeing how far you can get?
<AfC> jelmer: that's ok, I'm not bitching about import performance per se
<AfC> jelmer: so, having established the deterministic behaviour, I tried the lp imports branch
<AfC> jelmer: but I kept getting swap thrash. I'm sure I'll be able to make use of it at some point, though
<jelmer> AfC: you're getting swapping trash even just running "bzr branch lp:linux linux" ?
<AfC> yeah
<AfC> [anyway, that's done, I let it run overnight or whatever]
<jelmer> AfC: what version of bzr are you running?
<AfC> jelmer: daily
<AuroraBorealis> is lp:linux already a bazaar repo?
<AfC> yes
<AfC> AuroraBorealis: ^
<AuroraBorealis> weird that its thrashing when its just branching.
<AfC> it just took a long time; it was quite a few days ago; I've had bigger problems since then doing other stuff, but as I said, it's here now should I need it.
<AfC> bzr tags
<AuroraBorealis> might be related to the uhh
<AuroraBorealis> bug i'm having when importing the git linux repo
<AuroraBorealis> where its using so much memory (therefore thrashing if you don't have enough ram) cause its keeping the entire history in memory
<jelmer> AuroraBorealis: where are you getting that? using bzr-git, bzr-fastimport, regular clone?
<jelmer> none of them should really be  keeping all history in RAM
<AuroraBorealis> https://bugs.launchpad.net/bugs/864217
<ubot5`> Ubuntu bug 864217 in Bazaar "MemoryError when repacking repository with large numbers of revisions " [Medium,Confirmed]
<AuroraBorealis> doing fast-import of the git linux kernel uses about 2 gigs of memory , and it wasn't even done
<AfC> jelmer: well it is attempting to keeping 3.0 GB of something in memory. This doesn't go down well :/
<AuroraBorealis> and mgz said something about it was keeping history in memory
<AfC> jelmer: (this was even with bzr branch -r 1 URL; I never could get it to finish with -r > 100)
<AfC> (I imagine looping one revision at a time over n days would have worked out, but having established it was deterministic and didn't have missing revision relative to the lp import, I knew I could trust that)
<jelmer> AfC: did you see the bug I filed earlier about -r1 not actually doing that?
<mgz> jelmer: from a (partial) memdump AuroraBorealis had from fast-import, there was a _KnownGraph taking up a bg chunk of memory
<mgz> that may well be a bug, there's a _known_heads cache dict that seems essentially unbounded
<mgz> it only ever gets cleared on a couple of error paths
<AuroraBorealis> have you worked on meliae not actually dumping all the objects?
<AuroraBorealis> so we can see more of whats in the dumps?
<mgz> nope, but I've got that down as a project for this weekend
<AuroraBorealis> kk
<AuroraBorealis> i should be around, although you seem to be on the other side of the world from me so hours will be interesting =P
<mgz> on Monday I saw a reproducable segfault, some type errors, and the issue with missing objects causing the dump to not load
<mgz> fixing all those should get us somewhere, but the incomplete dump may still be a win64 size/alignment issue which will be a pain to work out from here
<AuroraBorealis> oh gee ;<
<AuroraBorealis> do you have access to a win64 computer?
<mgz> no, that's the fun bit :)
<mgz> the code has the wrong size of all the pointer->int casts though, so there's some hope I can just fix things till it magically works
<AuroraBorealis> i'll mail you my crappy 500 dollar laptop with windows 7 64 bit on it thats collecting dust behind me
<AfC> jelmer: no, I didn't; I'll look
<mgz> where on the other side of the world are you AuroraBorealis? :)
<AuroraBorealis> arizona, usa
<AfC> I would have thought you would have to go a bit further north than that to see the aurora borealis. Unless we just got spanked by a giant gamma ray burst...
<fullermd> Plate tectonics.  Just takes a little longer.
<AfC> ah, yes, of course :)
<AuroraBorealis> yes
<fullermd> ('course, it does make you wonder what kinda nutcase would be in AZ, awake, and on IRC at this hour   :p)
<AfC> [I only ever saw it once. I was rather far up, as I recall. Was pretty]
<AuroraBorealis> the nutcase who was procostinating on his small prolog assignment
 * mgz thinks fullermd isn't one to talk
<fullermd> Saying 'prolog' isn't helping your case!
<AuroraBorealis> haha
<fullermd> Hey, I'm a solid hour ahead of him.  That makes me totally sane.
<AuroraBorealis> haha
<AuroraBorealis> anyway, bed time for me. school in a few hours
<AuroraBorealis> chat with you this weekend i guess mgz
<jml> james_w: would you mind merging my branch?
<james_w> sure thing
<vila> jml, james_w : sry about that, I planned to do it but get interrupted longer than expected
<jml> vila: np
<sponge-> is there a way to do a sparse/bare checkout in bzr? in svn i'd do --depth immediates and then svn up --set-depth infinity on the folders i wanted, looking for something similar
<elmo> when merging someone else's branch, should I commit, then do fix ups, or can I merge, fix + commit result and still be able to usefully differieniate the two sets of changes?
<lifeless> elmo: difftastic/difftacular - I never remember the name - can untangle them for you
<lifeless> so sure, do whatever ;)
<wgz> lifeless: can I pester you for your thoughts on bug 866107 at some point?
<ubot5> Launchpad bug 866107 in Bazaar "Use testresources for bzr selftest" [Medium,Confirmed] https://launchpad.net/bugs/866107
<lifeless> sure, not right now sadly
<wgz> I shall ping again over the weekend at some point.
<wgz> and in other news, I have once again made PQM fail in some weird way
<wgz> this time... all the tests pass but...
<wgz> star-merge succeeded at Fri Oct  7 16:26:04 2011 (0:24:02.142211)
<wgz> 'Exception processing merge: [Errno 2] No such file or directory'
<vila> O.o
<wgz> stderr has the slightly suspicious:
<wgz> Fri Oct 7 16:02:43 UTC 2011 : selftest starts
<wgz> failed to open trace file: [Errno 13] Permission denied: '/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
<wgz> Fri Oct 7 16:26:01 UTC 2011 : selftest ends
<wgz> but there's no mention of a test with that issue in the test suite output
<hazmat> is there a cli command to get the latest revid out of a repo... ie. analogue of revno?
<vila> red herring, it's a leak somewhere, has been there for ages
<vila> wgz: ^
<wgz> okay, so it's the merge failing somehow that's the issue
<wgz> but... after all the tests run, which is just weird
<vila> wgz: more precisely some TestCase should be a TestCaseInTemp... err, yeah, that's what the path says ;)
<wgz> hazmat: `bzr revision-info`?
<vila> wgz: could be related to the issue with the lack of mails to bazaar-commits
<wgz> I'll post to the mp so MvG knows I'm not just holding out on him.
<lifeless> wgz: anyhow, testresources is good; I plan to supercede its model with testfixtures once I or someone else implements a fixture graph with reasonable introspection semantics (such that you can do the testresources planning on unsetup fixtures)
<wgz> lifeless: do you have any particular opinions about what bzr needs on this front?
<lifeless> wgz: I'd write your stuff as fixtures and use a shallow fixture->resource-manager shim
<lifeless> as I don't expect you to need deep route planning, merely aggregation of all the tests using a given external server
<wgz> one part of your fixtures readme really confused me
<wgz> resources had a clear part about dependent resources
<hazmat> wgz, perfect thanks.. didn't show up on a bzr help commands | grep rev
<wgz> whereas fixtures had a long example about how you couldn't share a tempdir if there were also a db and a webserver
<wgz> which... I didn't get at all
<lifeless> fixtures is a simpler model
<wgz> but that seems simpler to the point of not being useful
<lifeless> fixtures has seen more use in less time
<lifeless> this is one of the paradoxes of design :)
<wgz> if I can't share the tempdir created by TestCaseInTempDir (with some added carefulness in reset), I can't build any other fixtures of use on top of it
<lifeless> of course you can, if you want to
<wgz> nearly everything thats expensive enough to want to share between tests first derives from TestCaseInTempDir
<wgz> does testresources basically get around this by running all webserver tests together, then all db tests, and if it can't do that tearing down the lot between?
<lifeless> well back up a step
<lifeless> I think you have some conflation
<wgz> this is likely.
<lifeless> TestCaseInTempDir using unique temp dirs for each test case
<wgz> it shares a ROOT_DIR
<wgz> this is a bad thing, because it's global state
<lifeless> yes
<lifeless> its something we were working to nuke
<wgz> this is something I'd like to nuke with one of your nice packages :)
<lifeless> anyhow, fixtures describes an extended context manager basically
<lifeless> which happens to be very useful for tests because it exposes things like getDetails
<lifeless> and a convenient addCleanup for the code within it.
<lifeless> testresources describes an optimisation framework for expensive things; each of which could be a fixture (but needs a graph which fixtures doesn't expose)
<lifeless> the fixtures README talks about using just fixtures in similar situations to what testresources is targeted at - and in that world its kludgy, because of the lack of an introspectable graph
<lifeless> (you can't tell that the webserver and db are going to be using the same temp dir, and you can
<lifeless> 't (if they use addFixture) cleanup just the webserver or just the db, because that will implicitly cleanup the tempdir, hurting the other user
<lifeless> so
<lifeless> this is why I was saying to use testresources, but write the resources as a manager shimming across to a fixture
<lifeless> now, as far as test dir reuse, I think you want an external server to have the following properties:
<lifeless>  - totally decoupled from the test process
<lifeless>  - but managed by it
<lifeless> so I don't think you want testcaseintempdir to have anything to do with the server
<lifeless> just have the server make its own temp dir, for its logs etc, and each test case can tell the server where the test case is rooted etc
<wgz> well, often the tests that need a server have their own local branch for the client
<wgz> which then chats to the server
<wgz> so, it would have a server resource, and some other resources for the actual test
<lifeless> definitely a server resource, but unless you intend to share the other resources, they don't need to be exposed to testresources
<wgz> I think it would be worth sharing the safe-contain-in-filesystem infrastructure
<lifeless> and can be just fixtures (which bzr already uses though without using the library)
<wgz> the branch and trying to escape test isolation stuff
<wgz> which is basically just some state on disk, that doesn't change unless something goes wrong (and could then be reset)
<lifeless> sure
<wgz> fixtures does have the advantage of not needing the actual package
<wgz> and bzr may not really need the fancy graph stuff
<lifeless> I think bzr should use the packages :)
<lifeless> the fixtures package has very useful helpers
<wgz> the existing test arrangements may be enough without whole test suite reordering
<wgz> as much as I like your graph code :)
<lifeless> and the testresources graph stuff will be needed if you want a single reused server for each of the server types
<wgz> well, we really only need it shared 'enough'
<lifeless> bzr tests are currently totally isolated except for the safety mechanisms
<lifeless> wgz: I -really- wouldn't do 'enough' - do it right, don't NIH
<wgz> starting a new one per module rather than per test method is still a win.
<lifeless> wgz: with the in-test servers, thats not at all clear when compared to an out of test server
<lifeless> wgz: starting in-test servers is pretty darn cheap
<wgz> yeah, I feel very fearful of the NIH, but I'm also wondering if I'm going to need as much plumbing as doing something dumb like that would be anyway
<wgz> I think I actually like the testresources api better (except for that ugly hack you have at the bottom to sniff out a TestResult), but if leaning towards fixtures I guess I need to work out how they could actually be used instead
<wgz> ...I don't really like context managers with unittest, doesn't fit with the seperate methods for setup/teardown style
<wgz> +you
<wgz> in one of those malformed sentences somewhere
<wgz> okay, thanks for your time lifeless, I'll try some things out and see where I get
<lifeless> wgz: so my point was you need two things, you should use both of them
<lifeless> testresources takes care of the ordering and external bringup-takedown aspects
<lifeless> fixtures takes care of easy code for encapsulated services
<lifeless> wgz: tearDown should be deleted, can't be for compat, but don't use it.
#bzr 2011-10-08
<glen> hey, i did bzr merge ../some/other/branch; removing changes i did not want to merge this time with bzr revert. but i want to merge from branch again, i.e the same changes i did revert in first place :(
<jelmer> glen: bzr will think it has already merged those revisions which you partially reverted
<jelmer> you can still merge those changes by explicitly specifying the range of revisions you want to merge
<glen> jelmer: thanks. will try
<poolie> glen, hi, you should just give explicit revision numbers for the bits you want to merge again
<poolie> eg bzr merge -r 9100.. ../other
<daveb_> so, what does bzr do when it finds a device file?
<poolie> hi daveb_, i guess it depends where it finds it
<poolie> if if it's in the working tree it should be just skipped
<poolie> you can't add them
<daveb_> thanks poolie
<fullermd> Well, there go my hopes of branching /dev/zero to work on some optimizations...
<wgz> anything else people find annoying about hydrazine while I'm there?
<fullermd> Getting the hazmat placards right for shipping it?
<wgz> hm, okay, maybe just one more.
#bzr 2011-10-09
<wgz> hi AuroraBorealis.
<AuroraBorealis> sup
<wgz> if you've got some time, can you try some debug things on meliae?
<AuroraBorealis> sure!
<wgz> okay, what's your current diff on the meliae install?
<wgz> I want to go back and work out why the IO wasn't functioning without the hack first.
<AuroraBorealis> that might be difficult cause i downloaded the tarball
<AuroraBorealis> any suggestion on how to do it? o.o
<AuroraBorealis> can i somehow diff it against the original tarball?
<wgz> hm.
<wgz> maybe step one should be working out why your setup is borked so you can't branch lp projects then.
<AuroraBorealis> i think i can do that now
<AuroraBorealis> its just that one day launchpad was being iffy
<wgz> okay, branch a fresh lp:meliae and delete the currently installed one from Python27\Lib\site-packages\meliae
<wgz> I've got the hacks here anyway so we can re-apply them as needed :)
<AuroraBorealis> k did that
<wgz> okay, run setup.py on that, then the testsuite bit we got to crash and see if that's still happening.
<AuroraBorealis> what was the command to build the test suite again?
<wgz> http://irclogs.ubuntu.com/2011/10/02/%23bzr.html#t11:57
<wgz> there's actually a script to run the tests I realised after, but what we did before works too.
<AuroraBorealis> yeah crashes python still
<wgz> okay, great.
<wgz> well, not great, but you get the idea.
<AuroraBorealis> yes!
<wgz> okay, instructions: <http://paste.ubuntu.com/704848/>
<wgz> ....I should have wrapped some lines
<wgz> ask if anything doesn't make sense
<AuroraBorealis> k
<wgz> otherwise, paste me things as you go
<AuroraBorealis> where is python.dll?
<wgz> possibly in C:\Windows\system32\python27.dll but adapt for win64
<wgz> something like process explorer will tell you exactly which dll files get loaded if you run python the import meliae.scanner
<AuroraBorealis> yeah its in SysWOW64
<wgz> if that has different C runtimes loaded it's a sign something's gone wrong
<wgz> ^*then import
<AuroraBorealis> hmm
<AuroraBorealis> "link.exe: the program can't start becamse mspdb80.dll is missing"
<AuroraBorealis> let me google this...
<wgz> you probably need to run your vcvars bat file first
<wgz> though the fact that says 80 not 90 makes me worry.
<AuroraBorealis> well
<AuroraBorealis> that was with the 9.0 sdk
<AuroraBorealis> ok that worked
<wgz> I have Microsoft Visual Studio 8\Common7\IDE\mspdb80.dll - which isn't the right VS version for Python 2.7
<AuroraBorealis> with running 9.0's vcvarsall
<wgz> cool.
<wgz> wait, I also have it in  Microsoft Visual Studio 9, no worries.
<AuroraBorealis> python's dumpbin
<AuroraBorealis> http://paste.ubuntu.com/704851/
<wgz> you need the /IMPORTS flag
<wgz> dumpbin /IMPORTS python27.dll
<AuroraBorealis> scanner dump: http://paste.ubuntu.com/704853/
<AuroraBorealis> pythondll: http://paste.ubuntu.com/704854/
<wgz> okay, you see our problem there? :)
<AuroraBorealis> compiling with 10 instead of 9?
<wgz> yeah, _scanner is linked against a newer C runtime
<wgz> really distutils shouldn't let that happen, but I'm guessing we can work around it easily enough
<AuroraBorealis> can i force a version?
<AuroraBorealis> cause the microsoft sdk installed both 9 and 10
<wgz> yup, just looking to see how.
<wgz> so, running meliae `setup.py build_ext --help" gives a bunch of options
<AuroraBorealis> does build_ext actually put it in the sitelib folder?
<wgz> by default it puts its output in a subfolder of ./build
<wgz> then install moves the stuff to site-packages
<wgz> so, start by deleting meliae from site packages again, and deleting the build folder under meliae
<wgz> in fact, it may be worth clearing out all of site-packages and re-installing if every built extension has this problem
<wgz> you can double-check by running dumpbin on other pyd files.
<AuroraBorealis> k, let me check..
<wgz> I wonder if the hacks we needed to get distutils to work in the first place were entirely correct
<wgz> can you pastebin the contents of ..\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd maybe?
<wgz> and run meliae `setup.py build_ext` and paste me the contents so we can see where it's linking the wrong thing
<AuroraBorealis> http://paste.ubuntu.com/704860/ thats setenv.cmd
<wgz> okay yeah, that's referencing "Microsoft Visual Studio 10.0"
<AuroraAustralis> hmm
<wgz> is there another .cmd as well? because that one isn't right.
<wgz> would be annoying if it required actually installing an older SDK.
<AuroraAustralis> this is setup.py build_ext
<AuroraAustralis> let me look for another cmd
<AuroraAustralis> and that seems to be the only .cmd file in that folder
<AuroraAustralis> did i somehow make it use the 10 compiler?
<wgz> well,
<wgz> either that's just the wrong SDK version, and we need an older one
<wgz> or we just need it to not set the paths to point at VS 10
<AuroraAustralis> well i have a Microsoft Visual Studio 9.0 folder
<wgz> yup, but running that SDK script makes distutils look at VS 10 instead, which it shoudln't
<wgz> so, start by undoing the addition to vcvarsamd64.bat which added the call to that .cmd
<wgz> we can then manually set the LIB, LIBPATH, and INCLUDE if needed
<wgz> I suggest:
<wgz> start a new cmd window, call that problematic cmd and do `echo %LIB%` and the same for LIBPATH and INCLUDE, and paste it
<wgz> then we can copy that with corrections straight into a distutils conf file rather than messing the vcvarsamd64 at all.
<AuroraAustralis> i dont seem to have a lib, libpath or include env variable as it just prints out %libpath% or whatever
<wgz> hm, maybe run vcvars pre-edit and try?
<AuroraAustralis> http://paste.ubuntu.com/704870/
<AuroraAustralis> ran the vcvars in the 9.0 folder
<wgz> hm, and if you then run the v7.1\Bin\SetEnv.cmd file?
<AuroraAustralis> with calling the vccars64.bat file (which calls SetEnv.cmd) http://paste.ubuntu.com/704876/
<wgz> okay.
<wgz> so, if you have the 9.0 equivalent of those paths, we can just change the versions
<wgz> eg C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64 -> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Lib\amd64
<wgz> and we can set them in setup.cfg rather than editing bat files
<AuroraAustralis> there is a lib folder but no amd64 folder inside of it
<wgz> meh, then this is our problem, and short of building python itself against 10.0 I'm not sure what the fix is.
<AuroraAustralis> why did installing visual studio install 64 bit of 10 but not 64 bit of 9
<wgz> this I don't know.
<wgz> okay, I need to do some cooking, work out a way of getting the 64bit versions of the msvc9 runtimes, that would solve things.
<AuroraAustralis> yeah
<AuroraAustralis> i need to get to bed, i'll google around and see if i can get those
 * AuroraAustralis reinstalls the windows 7 sdk
<AuroraAustralis> hoping for magic
<AuroraAustralis> the reinstall has defeated me
<AuroraAustralis> going to bed, night
<Pilky> is there anyone around with any experience getting bzr to work with Jenkins/Hudson for CI? I'm using the plugin they list but I'm getting errors when I try a build that says it can't find bzrlib
<wgz> vila would be your man but he's not around currently.
<Pilky> wgz: thanks
<lifeless> Pilky: the plugin shells out to bzr
<lifeless> Pilky: so if its not working, your bzr isn't installed correctly (e.g. you've installed it to ~/bin but PYTHONPATH isn't export) or something like that
<Pilky> yeah, I had to mess around with the location as bzr is in /usr/local/bin on my machine as I used the Mac installer
<Pilky> I think I might have got it now though, just required some messing around with settings
<jelmer> 'morning
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<wgz> ...is it jelmer?
<jelmer> 'evening wgz :)
<wgz> are you somewhere far away currently? :)
<jelmer> ah, heh
<jelmer> no, I'm at home
<jelmer> I'm used to saying 'morning around this time of day since thats when the Ozzies and Kiwis show up :)
<fullermd> In my mind, it's always morning...
<wgz> jelmer: did you get anything exciting back from PQM?
<wgz> see the comment at the end of <https://code.launchpad.net/~gagern/bzr/bug869915-mkdir-quiet/+merge/78601>
<ubot5> Ubuntu bug 78601 in Ubuntu "[Sync] marble (NEW) from Debian experimental" [Undecided,Fix released]
 * wgz bops ubot5 on the head
#bzr 2012-10-01
<delinquentme> hey all .. is there a bzr command something akin to gitk?
<delinquentme> like a way I can graphically view the commit history?
<lifeless> delinquentme: bzr viz
<mgz> morning all!
<christiank> Hi! Our development team uses Bazaar in combination with Launchpad. I have filed a bug report on Sept. 11th and haven't had any replies. Is this the correct avenue to get help with it?
<christiank> It is bug https://bugs.launchpad.net/bzr/+bug/1049124
<ubot5> Ubuntu bug 1049124 in OpenPetra.org "bzr log -rxxx crashes out with 'ghost' in branch, but not in trunk" [Undecided,New]
<bob2> how old is the repo
<christiank> Good question, let me check
<christiank> It got created on May 30th, 2009
<christiank> bob2: Have you got any ideas as to why this bug might happen?
<pled76> hello all
 * christiank is away: Lunch
<pled76> failed to enable bzr via ssh
<pled76> server: ubuntu 10.04
<pled76> clients: Windows (putty and pageant)
<pled76> error:
<pled76> Connected (version 2.0, client OpenSSH_5.3p1)
<pled76> Authentication (publickey) failed.
<pled76> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xcf in position 0: ordinal not in range(128)
<pled76> putty ssh logins working ok
<pled76> server encoding utf-8
<pled76> clients are cp1251
<pled76> pls, help to troubleshoot
<mgz> pled76: please pastebin the corresponding section of your .bzr.log (running `bzr version` will tell you where to find that)
<pled76> can provide full error message -- seems as python stack
<mgz> !pastebin
<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.
<pled76> mgz: log from client or from server?
<mgz> client, but both wouldn't hurt
<mgz> it looks like you've just not got your keys configured correctly, but have a knock-on problem trying to print a localised error message
<pled76> keys are working -- putty can login from client
<mgz> you probably haven't told bzr to use putty
<mgz> by, eg setting envvar BZR_SSH to the path to your putty executable
<pled76> http://paste.ubuntu.com/1253636/
<pled76> thanks, will try to set BZR_SSH on client
<mgz> heh: "0.078  looking for plugins in C:/Documents and Settings/PâPâPjPÃ«PSPÃ«CâCâCâPÂ°CâPsCâ/Application Data/bazaar/2.0/plugins"
<mgz> that's pretty mangled
<pled76> thats Russian in ibm866 converted to cp1251
<pled76> the word there is "/ÐÐ´Ð¼Ð¸Ð½Ð¸ÑÑÑÐ°ÑÐ¾Ñ/"
<mgz> so, your problem is just that it's falling back to calling 'ssh' as you haven't configured it to use putty
<mgz> but the locale mangling is also confusing things
<pled76> will try setting BZR_SSH to "plink"
<mgz> because it's trying to prompt for a password, but can't encode the tranlated prompt in whatever it thinks your locale is
<mgz> pled76: what does the locale bits at the bottom of that error in the terminal say?
<mgz> fs_enc and so on.
<pled76> encoding: 'cp1251', fsenc: 'mbcs', lang: None
<pled76> on client I get:
<pled76> D:\Temp\3>set BZR_SSH=D:\Tools\plink.exe
<pled76> D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox
<pled76> D:\Temp\3>bzr co bzr+ssh://192.168.5.113/grp/bazaar/TandemUni/module_ramecox/ ramecox
<pled76> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<pled76> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<mgz> but `plink 192.168.5.113` works?
<pled76> plink 192.168.5.113 -l mikmer
<pled76> works correctly -- does not prompt for password and logins to linux shell
<mgz> you need to tell bzr about `-l mikmer` too.
<pled76> but how?
<mgz> can either stick it in the url, or in authentication.conf
<mgz> read `bzr help authentication`
<pled76> mgz: will try now, thanks
<pled76> mgz: thanks a lot -- now it works!   :)
<mgz> pled76: ace! did you add the details in authentication.conf or in the url?
<pled76> mgz: I added section with host and user to authentication.conf
<pled76> mgz: seems that adding user to url wiil do the trick also -- will try lately
<mgz> right, the conf option is generally best, otherwise it's easy to forget :)
 * christiank is back (gone 01:40:09)
<bob2> probably want to turn that off
<jelmer> hi jam, mgz
<jam> hi jelmer, I just mentioned you in the other channel :)
 * w7z is eating lunch
<jelmer> jam: :-) I was first though; have just caught up on email
<jam> w7z: still focused on sampledata, right?
<w7z> yeah, though I left juju trying to deploy folsom when I went to put the pasta on
<w7z> so I might have a cloud in a cloud by now (though more likely, a bunch of errors)
<mgz> was an install error...
<christiank> bob2: Hi, you have responded to my question from 11:02 Central European Time this morning (regarding a bug) with another question, but haven't come back to me since I provided the answer. Have you had an opportunity to look into that issue?
<bob2> nope
<bob2> <- not a bzr dev
<christiank> Ah, OK
<christiank> Is there somebody on the chat who might be able to have a look then?
<mgz> christiank: you need to talk to the launchpad maintence squad, who can be found in #launchpad on mostly AUS/US timezones
<christiank> OK, thanks!
<christiank> Will do
<mgz> was the branch derived from an SVN repo, or was it always bzr?
<christiank> The code was originally in a git repository and got then into a Bazaar repository
<mgz> jelmer: were there git ghost bugs, or is this a stacking issue?
<jelmer> mgz: ghosts shouldn't occur with git imports; bugs could cause them to appear though
<mgz> but, unlike svn there's not a well-known previously reported bug that causes ghost issues?
<mgz> because otherwise it's probably from branches moving around and breaking a stacking relationship or something
<jelmer> mgz: for svn ghosts aren't a well known bug; they are intentional behaviour
<christiank> The thing is that we don't get problems when we use Bazaar Clients of Version 2.4.2. The problem exists for Bazaar Clients V 2.5.0 and V 2.5.1.
<christiank> We find 2.4.2 quite buggy, it leaves a lot of 'dead' processes in memory all the time and would like to use 2.5.1, but then we get the issues I reported in the bug report
<christiank> That is all on Windows
<mgz> christiank: the bug you reported has two different issues
<mgz> one of them (the binary junk from the smart server) is a seperate issue and has been fixed on trunk and 2.5 branch
<christiank> Aha
<mgz> having ghosts on an branch is still something that needs fixing though, most likely in the launchpad hosted repos
<mgz> s/an/a/
<christiank> We think that we were using Bazaar 2.5.x clients and didn't run into the issues reported until two or three days before I reported the bug, but aren't 100% sure about that. Could a Bazaar Server upgrade on Launchpad have caused the problem?
<mgz> christiank: it caused at least the second issue
<christiank> You mean the 'binary junt from the smart server'?
<christiank> junt -> junk
<mgz> yes, that's bug 1046265
<ubot5> Launchpad bug 1046265 in Launchpad itself ""Could not understand response from smart server" when diffing lightweight checkout of smart server branch" [High,Triaged] https://launchpad.net/bugs/1046265
<christiank> Do you think a 'brz reconcile' on trunk might help with the 'ghost' problem that 'brz log' reports in recently created branches when we use 2.5.x Clients?
<mgz> probably not, but creating a fresh repo might, but that's involved and affects all stacked branches
<christiank> I'm just wondering the bug doesn't surface when using Version 2.4.2, and hence if there really is a problem with our repo, or if it's rather a problem of Bazaar 2.5.x Clients
<mgz> christiank: so, as I understand it, you work in checkouts from launchpad rather than local branches
<christiank> Correct
<mgz> in 2.4 this was massively inefficient, because most actions end up fetching large chunks of the repository pack files when doing anything involving hitory
<maxb> Out of curiosity, I ran bzr check -v on a local branch of lp:openpetraorg - am I misremembering that bzr check reports ghosts? This run did not
<christiank> We use Bazaar Explorer to create the Branches, not the Launchpad web interface for that, though
<mgz> maxb: there are no ghosts on trunk
<mgz> the rev reported as a ghost exists on trunk
<mgz> 2.5 added some optimsations that use specific smart server verbs that do the work server side and send just a small ammount of data back
<christiank> I realised that 2.4.2 is slower when I stepped back from 2.5.2
<mgz> but deploying the smart server code to launchpad revealed a few issues
<mgz> this seems like something specific wrong with how launchpad is doing branches/stacking/?
<christiank> I'm sorry, I need to take part in a meeting now. Are you available in let's say two or three hours or so?
<mgz> but if you make a local branch and push back up to that ghost-reporting branch in your bug, that might affect things
<mgz> christiank: I'll be around.
<christiank> OK, great
<christiank> Will come back later to you then
<christiank> Thanks for helping
<mgz> ...or not, a copy of that branch in my namespace is similarly borked
<christiank> mgz: Hi, I am back from the meeting.
<christiank> mgz: You write '...or not, a copy of that branch in my namespace is similarly borked'. Do I understand it correctly that you did a local checkout of one of our branches and can reproduce the issue I reported?
<mgz> christiank: I branched the one from your bug report, and pushed it back up as lp:~gz/openpetraorg/dev_branching_OK_test1
<mgz> which has the same issue
<mgz> running `bzr log -r revid:christian.kendel@om.org-20120911071731-5eips99nkud84v3o` in the local branch is fine though, obviously
<mgz> so it's checkout/stacking related
<christiank> Aha
<christiank> mgz: And you are running Bazaar 2.5.1?
<mgz> that was 2.6b2 but yes basically
<christiank> OK.
<mgz> basically, using lightweight checkouts of remote branches was never really recommended
<mgz> so has not been as well tested or debugged in general
<christiank> mgz: Maybe you could try to a fresh branch from our trunk and try to push it back up as you did with the branch from my branch. That way we could see if you could create a 'healthy' branch from our trunk, or not
<christiank> mgz: I see
<mgz> your trunk seems healthy anyway
<mgz> it's the branches created stacked on top that are unwell
<christiank> mgz: I see. And the '51223 inconsistent parents' that bzr check reports on trunk - should we not worry about those, or is that report wrong?
<mgz> how did you create them exactly? modify your local trunk then push back to a new location?
<mgz> the inconsistent parents are probably just a side effect of the code import, and may or may not be related
<christiank> mgz: We create new branches from within Bazaar Explorer, using the 'Bazaar' -> 'Start' -> 'Branch...' facility, giving 'lp:openpetraorg' as the 'From' and e.g. 'lp:~christian-k/openpetraorg/dev_branching_OK_test1' as the To Locations. After that we do a checkout of the new branch to a local directory of our Windows machine, using the 'Bazaar' -> 'Start' -> 'Checkout..' facility.
<christiank> mgz: then we do modifications to the source files on the branch and check them in regularly, occasionally doing a merge from trunk to keep things up-to-date in the branch. Finally we merge that branch into trunk once we are done with development. We do all operations with Bazaar Explorer.
<mgz> okay, that first step is a little funky, I'll see if I can reproduce
<christiank> mgz: Thanks
<mgz> hm, nope, trivial case works fine.
<mgz> if there's anything else in common broken branches have, it may be worth looking at .bzr.log to see what the exact operations you did were (`bzr version` will tell you where to find that)
<christiank> mgz: The problem is that I have now V 2.4.2 installed and not V 2.5.x so I can't do that
<christiank> mgz: You write: 'hm, nope, trivial case works fine.' --- So did you create branch 'lp:~gz/openpetraorg/testborkedness' in the way you described with V 2.6b2 on Windows using Bazaar Explorer and you don't see any 'ghost' issues?
<christiank> mgz: sorry - 'in the way you described' should have been ' in the way I described'
<mgz> christiank: using the underlying bzr commands that explorer uses, yes
<christiank> mgz: OK, that's good to know. Is there a release date for 2.6 yet?
<mgz> christiank: to be clear, I suspect it's my steps to reproduce the problem are incomplete, rather than an issue fixed in 2.6
<christiank> mgz: I'm having a break but will be back later
 * christiank is away: Break
<trashbird1240> hello
 * christiank is back (gone 01:03:40)
<christiank> mgz: I am back again
<mgz> I'm nearly gone (well, I'm on downstairs as well)
<christiank> mgz: Could you perhaps try to do the steps I outlined earlier really with Bazaar Explorer rather than the commands that Bazaar Explorer would use to create a new Branch in the way that I described? We hardly ever use the commandline commands but Bazaar Explorer. I did use the steps I outlined earlier to create the branch that I mention in the bug, lp:~christian-k/openpetraorg/dev_branching_OK_test1
<mgz> christiank: for the first two steps, which were the most specific, I'm pretty confident they're entirely equivalent
<mgz> explorer does just call into the bzr commandline for that underneath
<christiank> OK
<mgz> do other people also branches that also exhibit this problem?
<mgz> I'm not clear if it's all branches made after a period, or just some of them
<christiank> mgz: For Branch lp:~christian-k/openpetraorg/dev_branching_OK_test1 I did ONLY the first two steps and can produce the problem described in the bug
<christiank> mgz: Yes, all developers who used V 2.5.x had the problems in branches that were created from a certain point in time on. Working on branches they had created earlier caused no problems.
<trashbird1240> mgz: can you show a link to the bug? (I'm also having a problem)
<mgz> christiank: okay, I'll try with the exact steps, and not from within the datacenter
<mgz> trashbird1240: bug 1049124
<ubot5> Launchpad bug 1049124 in OpenPetra.org "bzr log -rxxx crashes out with 'ghost' in branch, but not in trunk" [Undecided,New] https://launchpad.net/bugs/1049124
<christiank> trashbrid1240: Sure: https://bugs.launchpad.net/bzr/+bug/1049124
 * mgz won! :)
<trashbird1240> I think I"m having a different problem
<mgz> trashbird1240: what's the error message you're getting?
<christiank> mgz: One developer who was still on v2.4.2 had no problems whatsoever, also not with newer branches he created after the time the other developers who were on 2.5.x had created branches that exhibet the problem
<trashbird1240> I'm getting "bzr: out of memory" when trying to pull to my laptop
<trashbird1240> I have narrowed it down to one particular revision
<christiank> mgz: Thanks for trying the exact steps.
<mgz> ah, you have the good ol' bloated repo problem
<trashbird1240> mgz: that appears to be the problem ;)
<mgz> if you know which rev it is, and are an admin of the branch,
<trashbird1240> which I am...
 * trashbird1240 is waiting with baited breath
<mgz> you can pull till just that rev, then rewrite the subsequent commits, then push up a new unbloated branch, and retarget trunk at that
<trashbird1240> okay
<mgz> so, `bzr branch -rLAST_GOOD lp:PROJ`
<trashbird1240> is there any other way that would not require reversioning?
<trashbird1240> I know that's my real problem, but is there any way to dump the branch to a file or something like that?
<mgz> trashbird1240: depends, if it's in your history, nope.
<trashbird1240> okay
<trashbird1240> I really appreciate the help
<trashbird1240> the annoying thing is that it's only this one machine
<trashbird1240> and it didn't happen until I upgraded the operating system
<trashbird1240> I therefore think the problem is somewhere outside bzr
<trashbird1240> firefox keeps crashing too
<trashbird1240> e.g. this same problem doesn't happen on Debian (on the same machine)
<trashbird1240> it happens on Arch
<w7z> ...that does sound like an issue just with that machine that bzr is tickling then
<w7z> perhaps something else is sucking up memory and leaving scraps for everyone else?
<w7z> try the normal nixy diagnostic things, top and so on
<trashbird1240> w7z: thanks; I'm currently trying to get firefox to crash ;)
<trashbird1240> I appreciate the help y'all!
<trashbird1240> okay, this is weird
<trashbird1240> it appears the pull actually worked this time
<trashbird1240> that's strange, since it errored out
<christiank> mgz: Have you had a chance to try the exact steps out?
<w7z> just considering how exact I need to be... I don't have Qt on this box yet
<w7z> okay, branch from lp->lp did it, using 2.5.1 from command line
<w7z> http://pastebin.ubuntu.com/1254594/
<christiank> w7z: Thanks. So what exactly does this prove - that 2.5.1 creates a broken branch from our trunk, I suppose?
<w7z> that just the doing that operation is broken, probably server side. I'll try a few other things.
<christiank> w7z: Thanks
<christiank> w7z: Need to go for today. Please add any findings to the bug report. Will be on bzr the IRC channel tomorrow.
<mgz> christiank: so, it's not specific to your project, and log against any cross-pushed stacked branch fails
<christiank> mgz: Ah!
<mgz> so, probably just a bug in the smart server log code
<mgz> `bzr log -r6567 lp:~gz/bzr/tmptest` also fails
<christiank> OK, so we found a wider problem
<mgz> the simple workaround is not to use lightweight checkouts from launchpad
<mgz> have a shared repo locally, and a real branch of trunk (perhaps without a tree)
<mgz> then other branches for your feature work that you push back up to launchpad
<christiank> Not sure what other consequences that has - we always used lightweight checkouts so far, I think
<christiank> Will check with a colleague of mine if we want to go that way, or not (and wait for the bug to be fixed)
<mgz> a few changed commands, easier merges, and faster responses :)
<mgz> and backups on everyone's machines
<christiank> Not to bad, then ;-)
<christiank> And what about administration overhead on each developer's machines?
<SamB_MacG5> christiank: that would be the aforementioned backups
<christiank> OK, really need to go now. Thanks for your efforts, mgz and w7z!
<mgz> probably a few extra commands to setup, and some additional initial data transfer
<mgz> later!
 * christiank is away: I'm busy
<mgz> okay, this isn't perfect but I can mostly repo
<mgz> have a local copy of lp:bzr, bzr serve --port 0 --allow-writes, bzr branch --stacked bzr://localhost:PORT/bzr bzr://localhost:PORT/bzr-stacked, bzr log -r1 bzr://localhost:PORT/bzr-stacked
<mgz> server side traceback: <http://pastebin.ubuntu.com/1254742/>
<mgz> jam: if you have any ideas on lp:~gz/bzr/hpss_log_stacked_ghost_1049124/ shout, I need to get some sleep
<mgz> basically the code isn't looking up stacked on revs, but I don't know the right magic incantation to fix
#bzr 2012-10-02
<mgz> morning!
<jelmer> moin
<christiank> mgz: I will be in this channel today in case you have further questions regarding the bug we discussed yesterday.
<mgz> christiank: thanks. I won't be able to do anything else on it till this evening.
<christiank> mgz: Thanks for letting me know. I will try to be on this channel tomorrow as well then.
 * christiank is away: Lunch
 * christiank is back (gone 01:04:14)
<mark06> why has bzr set a wrong time for my commit? http://bazaar.launchpad.net/~renatosilva/pidgin/windev/revision/12
<mark06> right time was 1h earlier, 23h39 GMT-3
<delinquentme> https://gist.github.com/ff315efc13d0582ed809  <, I've got this guy and I was assuming that bzr would make a fast forward commit here
<delinquentme> but it didint
<delinquentme> SO
<delinquentme> OK another user has branched my redesign branch ... they've made edits .. and pushed up
<delinquentme> i had subsequenly made another commit
<delinquentme> we're both on revno 150
<delinquentme> bzr merge gives me "Nothing to do."
<mgz> mark06: I wouldn't trust bzr for an alibi, but I'd be surprised if it was an issue there rather than with your system time
<mgz> mark06: pastebin the section of your .bzr.log (find it with `bzr version`) that corresponds to the commit?
<mgz> delinquentme: are you trying to merge the right thing?
<mgz> create a local copy of his version of your branch, merge that into your branch, then push the result
<delinquentme> mgz, so i should branch his branch
<delinquentme> merge
<delinquentme> and then push to mine?
<mgz> yup, though you can do the merge in either direction
<delinquentme> ok so mgz im a bit confused here ... so I'm running a merge between two branches right?
<mgz> yes.
<delinquentme> however I thought with bzr branches correspond to file
<delinquentme> files*
<delinquentme> right?
<delinquentme> so if there are two branches .. there then would be two files?
<mgz> ...that doesn't mean anything to me
<delinquentme> I mean that if you've got a project
<delinquentme> that project has a primary branch ( canonically named trunk ) as well as b1 b2 b3
<mgz> right, but that's just convention
<mgz> there's nothing special about any of those
<mgz> if I have a change on trunk, someone else pushes a change to trunk, I can merge his change and push my branch with:
<mgz> `bzr merge -d trunk lp:PROJECT && bzr commit trunk && bzr push -d trunk lp:trunk` (with 'trunk' being my copy of the branch in the cwd)
<mgz> lp:PROJECT in both places, rather
<fullermd> And then he can show up on #bzr wondering why bzr lost his commit  ;p
<mgz> well, yes, but the merge should be pretty obvious :)
<mgz> I'm not going into append_revisions_only fun
<drostie> I don't know the technical term for this, maybe 'underlying object structure' or so -- can anyone point me to a doc on the 'physics' of how bazaar conceptualizes versions/branches and stores them and so on?
<drostie> I'm trying to build an accurate mental model of what's going on 'behind the scenes' in various revision control systems.
<mark06> mgz: I'll need to do some test as I don't use .bzr.log, but this is later as the PC with problem is not at hands
<mgz> drostie: see <http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/core_concepts.html> and the bits under <http://doc.bazaar.canonical.com/bzr.2.5/developers/> and the docstrings in the source as needed
<mark06> mgz: that was bzr in windows + mingw msys, any clue? even if date command mistakenly swicthed to DST, I wouldn't think bzr would reply on it
<mark06> mgz: or is bzr sensitive to TZ env var?
<mgz> mark06: .bzr.log happens automatically, or do you mean you redirect it to /dev/null
<mark06> s/reply/rely
<mgz> probably windows knew the correct tz adjustment then but mingw was confused, I'd guess
<mark06> mgz: yes, BZR_LOG=nul (under Windows)
<mark06> mingw is not confused
<mark06> everything is allright, only bzr is doing abd things here
<mgz> bzr uses whatever the python gets from the system, which is different on native windows an emulated nix
<mark06> the only exception would be some mistake in TZ so that DST has been activated earlier (which I need to check later), but even so it's crazy bzr relying directly on TZ or even date, no?
<drostie> mgz: thanks, will look at it! :D
<mgz> if `python -c "import datetime;print datetime.datetime.now()"` prints the right thing, I think that's what we go from
<mgz> or, specifically, look at local_time_offset/format_date in bzrlib.osutils
<mark06> I'll check later mgz, thanks
<diddly> hi, i'm trying to set up a centralized repo following http://wiki.bazaar.canonical.com/SharedRepositoryTutorial but I don't think the SGID part is working, directories don't inherit the g+w bit
<fullermd> sgid doesn't make them inherit g+w, it makes [SysV-ish filesystems] inherit the group ownership.
<diddly> then i'm misunderstanding the instructions I think?
<fullermd> No, you're probably more stepping outside of them.
<fullermd> And/or you're hitting the bug where bzr doesn't propagate perms on newly created branches.
<diddly> fullermd: so i'll need to manually set it when branches are created?
<diddly> (ie on the server-side)?
<fullermd> Simplest solution.  In some cases you can also get away with playing umask games, etc.
<diddly> yea, I want to avoid that, it would probably make worse issues :)
<diddly> what bug id# are you referring to?
<fullermd> Dunno.  Lemme see if there's one filed.
<diddly> fullermd: ohh, no thats ok I thought you had already looked it up
<fullermd> Only insofar as it's a long-standing shortcoming that I know about.
<fullermd> bug 403250 talks about it, looks like.
<ubot5> Launchpad bug 403250 in Bazaar "branching in a shared repo doesn't inherit permissions" [Medium,Confirmed] https://launchpad.net/bugs/403250
<diddly> fullermd: wow thank you much for helping me with this!
<delinquentme> get the last commited version of a file?
<delinquentme> IE undo the edits made in the working tree?
<mgz> `bzr revert file`
<mgz> `bzr cat file` if you just want to look at it
<zyga> vila: ping
<zyga> anyone around, could I get a pair of eyeballs on https://code.launchpad.net/~zkrynicki/bzr/find_ancestors/+merge/127610
#bzr 2012-10-03
<ant384> Hello. New to Bazaar. Is there a way to only commit if the file was modified ? I'm trying to use Bazaar for some config file management, and I want to run a script periodically on a bzr repository, but I only want it to commit a file if it's contents are different from the current revision version of the file.
<jelmer> ant384: commit will fail by default if the file hasn't changed
<mgz> morning!
<jelmer> hey mgz
<ant384> Thanks
<bob2> ant384, ps use etckeeper instead
<christiank> mgz: I will be in this channel today (again) in case you have further questions regarding the bug we discussed the day before yesterday.
<mgz> christiank: thanks
<christiank> mgz: You're welcome!
<ant384> bob2: seems like etckeeper is what I need. It has however a problem, it won't allow me to specify a message for commit, if I use "etckeeper commit -d /my/folder", it opens my text editor. If I want to do "etckeeper commit "some msg" -d /my/folder", it says /etc is not init-ed yet.
<mgz> ant384: it has an equivalent of -m surely?
<mgz> ant384: you probably just want the -d and path before the message
<ant384> I'll just commit using bzr
<LarstiQ> ant384: I only ran the etckeeper command to initialise, and after that I commit with bzr
<LarstiQ> ant384: also, I disabled the automatic commits when installing packages/dailies, but ymmv
 * christiank is away: Lunch break
 * christiank is back (gone 00:55:26)
<ant384> Trying to invoke bzrlib.builtins.bzr_cat with a revision number. Without a revision number, I get the content of the current revision of the file. But I can't figure out how to specify the revision number. I tried revision=1 or "1", but in both cases I get errors. Not sure I can find the relevant docs.
<mgz> ant384: calling builtin commands directly takes some knowledge of internals, they're not really an api
<mgz> in this case, you either want to construct a revision spec, or there's a method on Command that does parsing from strings that will get the arguments right as-per called with argv
<jelmer> ant384: what are you trying to do exactly? If you're trying to get the contents of a file it might be easier to use the API rather than invoking the UI commands
<mgz> and yes, you probably want to use the actual api more closely rather than the command level stuff
<ant384> I'm trying to get the content of a file given a certain revision.
<jelmer> ant384: in that case you probably want to retrieve that particular tree from the repository and call tree.get_file_text()
<ant384> I looked at the get_file_* documentation and none seem to accept revision numbers. Am I missing something ? Should I just run bzr as a system command from within Python ?
<jelmer> ant384: you should resolve the revision number to a revision id first; the branch has a method for this
 * ant384 bangs his head against the desk
<mgz> ant384: less banging more posting code if you get stuck :)
<mark06> hi mgz, I tracked the time problem down, it's python behaving in a crazy manner in presence of a TZ env var
<mgz> mark06: thanks for reporting back
<mgz> it might be worth seeing if there's a related python bug open or fixed already
#bzr 2012-10-04
<mgz> real morning!
<christiank> Here too ;-)
<leo2007> any idea how to get bzr-grep installed?
<mgz> leo2007: two ways
<leo2007> please
<mgz> get bzr-grep, install as a plugin per the normal way:
<mgz> <http://doc.bazaar.canonical.com/plugins/en/plugin-installation.html>
<mgz> or as it's been merged into core recently, get the bzr trunk and test that :)
<mgz> https://launchpad.net/bzr-grep has tarballs, or you can branch lp:bzr-grep
<leo2007> is it in 2.6b2?
<mgz> ...I think not, will check
<mgz> nope, that was r6536, grep merged r6555
<hikiko> hellp
<hikiko> hello
<hikiko> anybody available?
<hikiko> i want to resolve a conflict from renaming files
<hikiko> but
<leo2007> is there a snapshot source tarball available
<hikiko> first of all i can't see anything in the bzr status
<mgz> leo2007: of bzr? I can generate one trivially if you want
<leo2007> mgz: I just installed the plugin for now. will upgrade when 2.6 is released. Do you know when it is going to happen?
<mgz> leo2007: ideally shortly, we're just lacking manpower to do it.
<leo2007> i see
<leo2007> I can wait ;)
<mgz> leo2007: http://people.canonical.com/~gz/bzr-2.6.0dev3.tar.gz.sig (which isn't gziped... silly server) and without the .sig for a current tarball
<leo2007> cheers
<mgz> signed with my key `gpg --recv-keys 0CDBF91C`
<leo2007> mgz: thanks, I am teaching ack.el to accept 'bzr grep' output and it is now done http://imagebin.org/230861
<mgz> leo2007: ace!
 * christiank is away: Lunch
 * christiank is back (gone 00:30:56)
<bob2> christiank, probably want to turn that off
<christiank> bob2: thanks for the tip, should be off now. Testing...
<christiank> bob2: nothing should have appeared, I assume.
<delinquentme_> OMG HAI ALL! I'm needing a way to take a look at some commits ... without actually editing my local code
<delinquentme_> or perhaps ... to pull down a few branches from trunk ... and then revert to a previous commit :D
<delinquentme> how to drop back to a particular revno?
<delinquentme> bzr revert -r 19
<fullermd> Depends on what you mean by 'drop back'.  update may be better suited.
<delinquentme> how about a diff between two revnos?
<delinquentme> $ bzr diff -r revno:1:http://bazaar-vcs.org/bzr/bzr.dev/..revno:2:http://bazaar-vcs.org/bzr/bzr.dev/
<delinquentme> this seems silly.
<delinquentme> why do you run a diff and need to specify two files?
<delinquentme> ok so it seems thats for two branches
<delinquentme> how about two files?
<delinquentme> bzr: ERROR: Path(s) are not versioned: application.html.erb
<delinquentme> does this mean I cant diff a file?
<delinquentme> $ bzr diff -r 155 app/views/layouts application.html.erb
<abentley> delinquentme: It means there's no such file.  Perhaps you're not specifying a relative path?
<delinquentme> OK so bzr branches .. DONT correspond to their own files for each branch?
<delinquentme> Im used to git .. where everything it stored within a single directory
<bob2> well you will need to read docs for each new tool you use, yes
<delinquentme> bob2, this is a discussion channel no?
<bob2> sure
<fullermd> I'm still really not sure what you mean by branches being files...
#bzr 2012-10-05
<mgz> morning!
<christiank> Morning!
<mgz> :)
#bzr 2012-10-06
<_kbulgrien> me wonders if anyone has a good quick link to some description of how to let branches diverge.  I have several branches that mostly follow each other, but I don't know how to skip over some changes when pulling, etc.
<fullermd_> No such thing as that; any change implies all its ancestors.
<_kbulgrien> um. well am I asking the wrong question then, because it seems a given that branches should be able to be different.
<fullermd_> Sure, but it happens by one going off one way and the other not (generally going off another).
<fullermd_> Can't happen that you take change n+1 from some branch without getting n.  Unless you add a n+2 that's (~n), say.  But then the other side will get that when they sync you, and it gets messier from there.
<fullermd_> Nobody can do that sort of thing except darcs, since they don't have ordered changes, and are messy from the getgo  ;p
<_kbulgrien> so once you diverge you can never merge from the source again without becoming a clone of it again?
<fullermd_> Mmm.  You can't merge without sorta undiverging, since that's what merge _is_; an elimination of divergeance.
<fullermd_> Once you merge, you've got everything they do.  Of course, you'll still have extra stuff, so you could say you're diverged from them, in that you're now a proper superset.
<fullermd_> But then when they merge you, they've got everything you have and now they're a superset.
<_kbulgrien> I'm thinking that mostly I want to follow a source, but I want to be able to let certain files diverge.  It seems like that should be possible.  I guess I have a broken concept of what DVCS was supposed to allow.
<fullermd_> By "let" you mean "make changes to them versus what upstream has".  So you wind up with always a superset of them.
<fullermd_> (well, right after you merge anyway.  You wind up both diverged in between while they move ahead between your merges, but...)
<_kbulgrien> yes
<_kbulgrien> Well, not necessarily superset I guess.  I want to track changes in this file, but where I branched from has a different one.  I'm good with getting the one from upstream, but I'd like to maintain my own history downstream on that one file.
<fullermd_> Well, that _is_ a superset.  You've got every change upstream does, plus some of your own.
<_kbulgrien> Ok, yeah.
<_kbulgrien> Is there a way in the VCS to send patches to them without them having to take all my changes?
<_kbulgrien> I'm sort of thinking along the lines that in CVS, one can selectively merge on a file by file basis without having to merge the branches in entirety.  Perhaps the language is different between CVS and DVCS... (shrug)  I don't know how to translate that to Bazaar.
<bob2> well of course, you can not accept changes
<bob2> probably making life hard for yourself, though
<exarkun> I want to write a post_change_branch_tip hook that updates itself.  So I figure I can have the hook check out the new version of the branch and copy itself into the plugins directory.
<exarkun> Also, it has configuration, so I want to copy a new version of the branch.conf into place.
<exarkun> It doesn't look like the bzr developers particularly want me poking around here, though.  The only way I've found to discover the path beneath which I'll find branch.conf is `params.branch.bzrdir.transport.base
<exarkun> And that's not even a real filename, but a file:// uri.
<exarkun> Am I barking up the wrong tree?
<fullermd_> _kbulgrien: Not as VCS data, no.  You can send patches of course; whether they'll apply will depend.  And they won't have any relation to your changes, so you may get some odd conflicts when you merge their application of them.
<exarkun> Gah.... filtered-143716140:///~/highscores/.bzr/ is not a very nice path :(
<exarkun> Surely there must be some way to find the branch on the filesystem?
<_kbulgrien> so then I guess I'm asking if the vcs facilitates that sort of thing... upstream agrees my change is good to incorporate, so I send them some kind of spec that they can use to pull the changes from my branch without a merge, or do I have to do the old-style here's my set of patch files, apply it to your branch please?
<fullermd_> Well, the ideal is that you make a branch of _just_ their stuff, plus that change of yours.  Once its entwined with other stuff you don't want to send, you're down to the old-style patch sending.  Or using darcs  ;p
<vila> exarkun: I think you're indeed barking up the wrong tree
<vila> exarkun: avoid the direct file access and just use the API: branch.lock_write() ; conf = branch.get_config.stack() ; conf.get() ; conf.set() ; conf.remove() ; branch.unlock()
<vila> err, conf = branch.get_config_stack()
<poolie> o/ vila
<vila> poolie: hey :)
<exarkun> vila: Thanks.
<dr3mro> hello , I have a project on launchpad and i use bazaar and there is urgent merge propsal and i have no access except to windows PC can any one help me do the merge by installing bzr on windows
<dr3mro> i have installed bzr using cygwin !! but it fails to merge ?
<bob2> unclear what 'failes to merge' means
<dr3mro> Value "/etc/ssl/certs/ca-certificates.crt" is not valid for "ssl.ca_certs"
<dr3mro> No valid trusted SSL CA certificates file set. See 'bzr help ssl.ca_certs' for more information on setting trusted CAs.
<dr3mro> See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
<dr3mro> Pass -Ossl.cert_reqs=none to disable certificate verification entirely.
<dr3mro> bzr: ERROR: _ssl.c:323: No root certificates specified for verification of other-side certificates.
<dr3mro> this is error message
<bob2> fix your bzr config file
#bzr 2012-10-07
<exarkun> Uh, what's this supposed to mean?  http://codepad.org/doDaxWiE
 * exarkun goes to do dishes while waiting for the answer
<exarkun> aw, come on :/
<\u03b5> Hmm I just had bzr try to write a change twice
<\u03b5> I pulled a revision from a work branch into a mainline branch bound to launchpad
<\u03b5> It gave an error that I had already acquired a lock on the repo seconds ago, but bzr update brought in the revision anyway
<\u03b5> I can't seem to reproduce that with only local branches
<\u03b5> hm
<\u03b5> now it applied cleanly on a test branch :(
 * fullermd_ takes credit for fixing it.
<\u03b5> that was quick, fullermd_!
<fullermd_> That's why I get paid the Big Bucks(tm).
<\u03b5> well damn it, I still get it on the real branch
<fullermd_> exarkun: If you use -Dhttp to trace the requests, you'll find the last one that works is grabbing .bzr/branch/location, which contains that filtered:/// string.  Which I think means that the "branch" there is actually a branch reference (light checkout) or something else.
<fullermd_> exarkun: (no idea why it has a filtered:/// location to be sure, but at any rate, it's likely that whatever the path in there is, it won't make much sense over dumb http)
<fullermd_> \u03b5: Well, stop breaking it again!  ;p
<\u03b5> I'm not sure what I can do to distinguish the two branches...
<fullermd_> What's the exact error it's throwing, and see if there's anything revealing in .bzr.log.
<fullermd_> (and I may not respond too quickly; I'm just running away from my computer for a bit right now)
<\u03b5> I can't find any *bzr.log* files in .bzr or ~/.bazaar, did it get deleted when I ran another command?
<\u03b5> nope, still no log
<fullermd_> No, in ~
<\u03b5> what's the preferred pastebin here?
<exarkun> fullermd_: Thanks
<\u03b5> http://paste.ubuntu.com/1265900/
<\u03b5> scratch that, http://paste.ubuntu.com/1265901/
<exarkun> fullermd_: How do I use that -Dhttp thing?  Neither "bzr -Dhttp pull" nor "bzr pull -Dhttp" shows me anything extra.
<\u03b5> the test branch commit looks similar, without the lock exception
<\u03b5> I'll try printing a stack trace on that log entry
<\u03b5> http://paste.ubuntu.com/1265936/
<exarkun> `JailBreak: An attempt to access a url outside the server jail was made:Â´?
<exarkun> Server jail?
<fullermd_> \u03b5: Do you have write permission to the lp: branch?
<fullermd_> exarkun: I did "bzr -Dhttp info" on it.  The trace drops in your ~/.bzr.log
<\u03b5> yes in fact the revision pushed fine
<fullermd_> Yes, the smart server jails itself.  chroot()-like.
<exarkun> fullermd_: Ah, I see, it did indeed log there, thanks.
<\u03b5> I didn't have it locally but bzr update brought it home
<exarkun> fullermd_: I just changed my post change branch tip hook from doing a lightweight checkout to doing a regular checkout.  The lightweight checkout worked fine, but the regular one is a jail break attempt?
<fullermd_> exarkun: Got me.  I'd guess at some oddity in the env happening around the hook (the heavy would try to potentially write into the repo frex), but that's well outside of my ken.  You'd need somebody who knew internals better for that.
<exarkun> Okay, thanks.
<exarkun> Where _is_ writing allowed?
<fullermd_> \u03b5: Mmm.  Well, in the earlier trace it looks like you're pull'ing into a checkout (heavy probably) of the lp: branch, and something in that process is getting screwy when it tries to write the revs up to LP.
 * exarkun bets it's allowed at a location that's undiscoverable
<fullermd_> Wherever it got jailed at.  In the case of bzr://, it's whatever dir you aimed bzr server at.  For bzr+ssh, I think it's at the FS root.
<exarkun> I'm using bzr+ssh, and I tried to do a checkout to a directory in ~, which is a sibling of the branch location
<fullermd_> But again, this is really pushing the bounds of my knowledge.  It may be a somewhat spurious result too, of just doing something unexpected deep inside the stack.
 * exarkun nods
<fullermd_> You're pretty deep in the middle of commit/push/whatever with that hook.  I'm not sure anybody's tried doing a lot of fiddling down there before, so...
<\u03b5> My outsider guess would be that pull is trying to push the branch while the local bound branch already knows to do that
<exarkun> :(
<quotemstr> How do I get bzr to give me the original hunk in addition to TREE and MERGE-SOURCE?
#bzr 2013-09-30
<exobit> Is there a recommended code review tool for bazaar users?
<jelmer> exobit: I think the main options are launchpad and reviewboard
<exobit> Thanks jelmer.
#bzr 2013-10-01
<Andy80> hi guys. Suppose I've modified 3 files after last commit, then I've done a commit. I want to undo JUST the commit from the log, without loosing any of the changes I've just done. (I want to split the commit in 2 different commits). How can I do it?
<LeoNerd> bzr uncommit
<Andy80> LeoNerd, thank you so much :)
#bzr 2013-10-02
<icebrain> Hi! Is there any way to pass ssh options for the bzr+ssh connection without using ~/.ssh/config?
<icebrain> I'm trying to do an unattended configuration that branches a remote repo, and I need to pass a private key, but I want to use something temporary (e.g. generate keypair, copy private key, branch, delete key)
<icebrain> and I don't want to mess with any existing .ssh/config files, if there is any
<jelmer> icebrain: you can override the ssh command to run, and specify options there
<jelmer> I don't know off the top of my head what the config variables are
<maxb> BZR_SSH environment variable might work here?
<jelmer> maxb: yep, that might do it
<mgz> can't put ssh plus args in there, but can reference a mini script that is ssh plus some args
<mgz> eg, `echo "ssh -blah" > ~/myssh` `export BZR_SSH=~/myssh`
<icebrain> ok, thanks
<jelmer> I thought there was also a configuration option for the ssh command?
<mgz> not to exec the contents I think
<thumper> jelmer: I plan to get to the wikkid branch next week as I have a week leave
#bzr 2013-10-03
<Wiz_KeeD> Hello fellas
<Wiz_KeeD> small question, I have pulled a branch from a server and updated the config file to connect to my mysql database with user and password
<Wiz_KeeD> but I want to be able to pull all the changes except that file
<Wiz_KeeD> so the password stays the same
<fullermd> As in "I keep pull'ing upstream stuff as an otherwise-unchanged local copy without making local commits"?
<Wiz_KeeD> yeah something like that
<Wiz_KeeD> I don't make the changes locally
<Wiz_KeeD> just pull and want to keep the config file
<Wiz_KeeD> I could just bzr ignore that file?
<fullermd> No, ignore doesn't do anything like that.
<fullermd> But pull always merges forward uncommitted changes, so I don't see that you need to do anything.
<Wiz_KeeD> i usually do overwrite, but if in this case it does not work merging would mean showing both sides of the code
<Wiz_KeeD> and I have to delete every time, messed up
<fullermd> As in pull --overwrite?  As a regular thing?
<Wiz_KeeD> Yeah, to have the fresh code without what I might have accidentaly overwritten
<fullermd> Well, make up your mind, do you wanna make local changes or not?  ;p
<fullermd> But no, there's no way I know of to express --overwrite-oh-but-not-this-part
<fullermd> Doubly so because it's really sorta peripheral what --overwrite does to the WT anyway.
<exarkun> I can't push my branch: bzr: ERROR: Option 1,2 is not defined while expanding "lp:~exarkun/pyopenssl/tlsv1_{1,2}".
<exarkun> Can I work-around that somehow or do I have to pick a different branch name?
<mwhudson> you can't call a branch that on lp
<mwhudson> but that error is pretty special
<mwhudson> is it coming from curl or somethign?
<mwhudson> no, that makes no sense
<exarkun>   File "/usr/lib/python2.7/dist-packages/bzrlib/config.py", line 3758, in _expand_options_in_string
<exarkun>     raise errors.ExpandingUnknownOption(name, string)
<exarkun> ExpandingUnknownOption: Option 1,2 is not defined while expanding "lp:~exarkun/pyopenssl/tlsv1_{1,2}".
<exarkun> with `return self.get_config_stack().get('push_location')` up above it on the stack
<mwhudson> huh huh
<mwhudson> yeah, it's something in the bzr config machinery
<mwhudson> anyway, if you made it work client side, pretty sure lp would tell you to FOAD so try another name i guess
<exarkun> Yea okay.  Thanks.
<mwhudson> valid_branch_name_pattern = re.compile(r"^(?i)[a-z0-9][a-z0-9+\.\-@_]*\Z")
 * mwhudson remembers with amusement changing the $ to the \Z at the end in a mad panic
<exarkun> huh I had to look up \Z just now and got the impression it was the same as $...
<exarkun> Oh... something about newlines...
<exarkun> nice
 * exarkun imagines every regexp he's ever seen in a Python program is probably has one more bug than he previously realized
<mwhudson> yes, someone somehow managed to create a branch called "trunk\n"
#bzr 2013-10-04
<jfcaron> Is there a way to find out how large (i.e. in bytes or something) will be a push to launchpad, before pushing?
#bzr 2013-10-05
<mark06> hi, are commit date and times stored as UTC in the case the detected timezone is incorrect?
<mark06> for example, when using bzr from MinGW MSYS under a non-English Windows
<mark06> more info: http://stackoverflow.com/questions/12765650/mingw-msys-msvcrt-and-the-tz-environment-variable/13126574
<mark06> what's the exact behavior of log's --timezone=utc? will it just shift the time by the stored timezone?
<mark06> or is the time stored as utf with a timezone shift indicator? for example, if summer time ends today at midnight and clock is reverted one hour back, we got two 23:00-0:00 periods in the current timezone, one for summer time, and another for standard time
<mark06> say my standard time is -03:00, so if I commit something in one of the two 23:00-0:00 periods, I'll get either a -02:00 or -03:00 indicator in the log, right?
<mark06> now consider that for some reason bzr could have detected the timezone incorrectly at the time of commit (like described in the post)
<mark06> so can I rely on --timezone=utc for telling me the real UTC not just shifting stored time by the stored timezone?
<mark06> please help! :(
<vila> mark06: bzr uses whatever timezone is set to derive utc. It doesn't matter how it's stored, there is no way for bzr to 'detect that the timezone is incorrect'. Garbage in, garbage out. Now, bzr doesn't care about commit times because there is no way to decide that your clock is correct, TZ or not.  A revision comes after another revision because there is parent/child relationship, no matter what the revision dates are. Why do you care about
<vila> those commit times ?
<mark06> I have a script that detects incorrect timezones in bazaar commits, I don't want bazaar to work properly, it's rather a bug fix for MSYS as explained in that post
<mark06> If they're not important, why not remove commit times at all? That's why I care about them
<mark06> what I want is what I asked,  what's the exact behavior of log's --timezone=utc? just shift the stored time by the stored timezone, OR show the UTC time which is actually how the time is stored (that is, the shift operation happens on display time only, not on store time)
<mark06> take as example commit date "2013-02-16 23:00 -02:00", will  --timezone=utc just show "2013-02-16 01:00 UTC" (just a shift with the stored value), or will it show *either* "2013-02-16 01:00 UTC" or "2013-02-16 02:00 UTC" (those being the two possibilities for when (1) timezone was correct on commit and it's the "first" 23:00 -- before adjusting clock backward one hour, or (2) timezone is incorrect with daylight period just having started, the time b
<mark06> ah sorry, *"2013-02-17 01:00 UTC"
<mark06> *"2013-02-17 01:00 UTC", *"2013-02-17 01:00 UTC"
<mark06> *"2013-02-17 02:00 UTC"
<mark06> the mentioned script is here, as you can see in the comments there, I appreciate if anyone can clarify (with arguments) about --timezone=utc: http://bazaar.launchpad.net/~renatosilva/+junk/scripts/view/head:/check-brst-commits.sh
#bzr 2013-10-06
<Noskcaj> Does bzr-gtk still add a "commands" python package?
<SamB> I thought bzr-gtk was on the way out ...
<Noskcaj> SamB, it is, but bug 1037671
<ubot5> bug 1037671 in TestDrive "Test Drive won't start with AttributeError" [Undecided,New] https://launchpad.net/bugs/1037671
<mark06> please send me a memo if you can help with the top notice here, thanks: http://bazaar.launchpad.net/~renatosilva/+junk/scripts/view/head:/check-brst-commits.sh
<wedgwood> ls
#bzr 2014-09-29
<LeoNerd> bzr: warning: The commit message is a file name: ".bzrignore".
<LeoNerd> Hah.. lovely
#bzr 2014-09-30
<slspencer> Hi. I have a question about a git to bzr import error
<slspencer> UnknownCommitExtra: Unknown extra fields in <Commit 56ead206c93f1ed9d6f1d46cbfa2a8e79cdad63c>: ['HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename'].
<slspencer> Anbody seen this error before?
<slspencer> I'm looking at https://bugs.launchpad.net/ubuntu/+source/bzr-git/+bug/1084403 on gpsig tags.
<ubot5> Ubuntu bug 1084403 in bzr-git (Ubuntu) "no support for gpgsig tags" [High,Triaged]
<slspencer> This isn't the same root cause, but it's a similar error message.
<slspencer> In any case, I'm interested in learning how to set up a fast-export/fast-import daily pull from git
<slspencer> How is a fast-export/fast-import (as recommended in the bug report) specified in Launchpad import request form https://code.launchpad.net/+code-imports/+new ?
<jelmer> slspencer: hi
<slspencer> Hi
<jelmer> slspencer: note that bzr-git is not related to fast-export/fast-import
<jelmer> they're two completely different approaches of importing from git into bzr
<slspencer> Right, hence the confuseion as to why this is rhe recommended work-around in the bug report
<slspencer> Is there a better solution?
<jelmer> slspencer: bzr-git can't handle those fields it doesn't know about, so until it does you can't use bzr-git
<jelmer> slspencer: hence the suggestion to use a completely different way of doing imports
<slspencer> I'm not seeing any intructions on how to implement the fast-export/fast-import on Launchpad
<slspencer> How is this done?
<slspencer> I'm willing to check it out
<jelmer> slspencer: you can't do fast-export/fast-import on Launchpad
<slspencer> ah
<slspencer> So my project's Ubuntu build is completely hosed
<jelmer> slspencer: what project is this?
<slspencer> Valentina
<jelmer> slspencer: those fields are unsupported by C git too I suspect
<slspencer> unknown
<slspencer> They're mercurial rename commit tags
<slspencer> Imported from bitbucket to git, then from git to bzr
<jelmer> slspencer: I don't think Mercurial should be setting those..
<slspencer> HG:rename tags are created with the 'hg rename' command
<slspencer> So I can't use fast-export/fast-import on a daily pull from git
<slspencer> I'll keep looking for something to fix this problem
<slspencer> jelmer: thanks for your time!
<jelmer> slspencer: yeah, hg-git should not be setting this field...
<slspencer> Hi
<slspencer> I was in #bzr earlier today
<slspencer> Previously working import from git into bzr is now returning error message about extra fields in commit
<slspencer> raise UnknownCommitExtra(commit, [item[0] for item in commit.extra]) bzrlib.plugins.git.errors.UnknownCommitExtra: Unknown extra fields in <Commit 56ead206c93f1ed9d6f1d46cbfa2a8e79cdad63c>: ['HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename', 'HG:rename']. Import failed:
<slspencer> When I checked with the hg-git dev team, they stated that these fields should be there for hg-git interoperability
<slspencer> they also said that bzr-git should ignore metadata fields that are not defined or are not understood
<slspencer> The fields were created by the 'hg rename' command and traces the history of the file, so they should stay, but bzr doesn't need them
<slspencer> Is there anyway in Launchpad to import the git repo and tell it to ignore undefined metadata fields?
<slspencer> My Ubuntu app is dead until we get this solved
#bzr 2015-09-30
<uelo> Hi, is it possible to push a branch to launchpad with no messages/new revision, and by using the --fixes lp:XXXX ?
#bzr 2016-10-04
<lifeless> jelmer: just saw a very suspicious email from you
<lifeless> jelmer: passed SPF, failed DMARC - could be spoofed...
<lifeless> jelmer: but in case its more insidious thought I'd let you know
<fullermd> It's his name, but note that it's bialix's address.  Similar to another one about a month back.
<lifeless> oh, heh :/ thanks!
<fullermd> (and both came through apparently random paths, so I suspect it's probably actually sourced from neither   :|
<fullermd> (other similar ones came through Jul 1, May 4, and May 11.  Though all have +0300 TZ spec'd, which _is_ Ukraine summer time)
#bzr 2017-10-03
 * jelmer waves
#bzr 2017-10-06
<Derperperd> hey guys
<Derperperd> is bazaar dead?
<LeoNerd> Define "dead"
<Derperperd> is it being actively updated?
<LeoNerd> That's an odd definition of liveness
<Derperperd> how so? if a project hasnt been updated in 3 years most would consider it to be dead
<LeoNerd> I find it works fine for me, anyway
<Derperperd> seems dead
<LeoNerd> I don't think there's much active direction on people adding/changing stuff, no
<LeoNerd> But the same can be said of many projects, which have reached the stage of being useful and get used for realworld work all the time
