#bzr 2008-06-23
<lifeless> hi
<uws> Ok, so I'm trying to branch mysql-server/5.1 from launchpad
<uws> I've set my launchpad login using "bzr lp-login" previously
<uws> but now the branching fails with a   Permission denied (publickey)    error message
<uws> I just want a checkout, nothing fancy.
<lifeless> uws: its using bzr+ssh
<uws> so?
<Jc2k> uws: the lp: foo doesnt know whether your pulling or pushing, so always goes through bzr+ssh
<lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh
<uws> note that I'm not involved with mysql, is that a requirement?
<lifeless> no
<mwhudson> mkanat: having fun yet?
<mwhudson> uws: not at all
<lifeless> uws: 09:01 < lifeless> uws: and your public key is either not registered with lp, or no available to your local ssh
<uws> mwhudson: I thought it might be trying my login first, and failing in falling back to anonymous checkout.
<uws> anyway, I'll check my ssh keys\
<uws> ah, there we go. Launchpad only knew about my laptop's ssh key
<uws> thanks
<mwhudson> cool
<lifeless> _argh_ evolution
<awilkins> gcc -version
<awilkins> oops
<awilkins> jelmer: Those C extensions are not compiling for me.
<lifeless> poolie_: I'm going to try to finish stacking-kints today
<jelmer> awilkins: what errors do you get?
<lifeless> mwhudson: I get
<lifeless> Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
<awilkins> initializer element is not constant
<jelmer> lifeless: Hmm, looks like it's failing to do proper caching in the case of bzr-search
<lifeless> mwhudson: when trying server-branches
<jelmer> lifeless: Looking into it further...
<lifeless> jelmer: thanks
<lifeless> jelmer: its lock_read'd, and fast on bzr branches
<mwhudson> lifeless: hm
<lifeless> 500MB/hour now
<awilkins> jelmer: core.c (73) ; looks like it doesn't like the sizeof call setting the initial value
<awilkins> jelmer: This is gcc 3..4.5
<mwhudson> lifeless: more details?  which directory are you running from, what url are you trying to view?
<lifeless> mwhudson: http://www.robertcollins.net/
<lifeless> mwhudson: I cd'd to that dir on the fs; ran python ~/source/loggerhead/bzr-search.integration/serve-branches.py;
<lifeless> mwhudson: clicked on config-manager
<lifeless> (note my html pages are woefully old; ignore that aspect :P)
<lifeless> config-manager/ has a subdir trunk that is a branch
<lifeless> config-manager/ is not a repository
<mwhudson> i wonder if this is dir -> dir/ redirection going strange then
<poolie_> lifeless: hi
<lifeless> the url that it wanted was config-manager/, yes
<lifeless> poolie_: ho
<jelmer> awilkins: Hmm, that's an old version
<jelmer> awilkins: core.c is not there anymore
<jelmer> awilkins: What branch are you using?
<awilkins> lp:bzr-svn
<jelmer> awilkins: the mirror is probably out of date
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
 * awilkins pulls
<mwhudson> lifeless: i can't reproduce here
<mwhudson> lifeless: are there proxies involved or anything?
<lifeless> http://rafb.net/p/q5BkUZ65.html
<lifeless> mwhudson: not yet
<awilkins> jelmer: Darn, more setup.py blues
<mwhudson> lifeless: paste version?
<lifeless> feisty
<mwhudson> lifeless: as in, which version of python-paste
<mwhudson> hmm
<awilkins> jelmer: apr-config naturally doesn't run on Windows so I have this awesomely bad patch to make it work :-|
<lifeless> mwhudson: 1.1.1-1
<mwhudson> ok, that's definitely older than what has been tested so far
 * mwhudson goes to try to find a changelog
<lifeless> its on my todo to upgrade
<lifeless> but, time.
<mwhudson> yeah
<awilkins> jelmer: Right, It's too late to hack this into shape, I'll get back to it. Gnight
<mwhudson> lifeless: changes from 1.1 -> 1.2:
<mwhudson> * Regression in 1.1 fixed, where Paste's HTTP server would drop
<mwhudson>  trailing slashes from paths.
<lifeless> mwhudson: fuckers.
<lifeless> why can't all software have /tests/
<mwhudson> like loggerhead, for example...
<lifeless> mwhudson: this is a bit of a show stopper though ;P
<mwhudson> lifeless: i don't really have any good ideas
<lifeless> for starters, document paste 1.1 as fuxored and check it at startup
<mwhudson> python-paste is pure python, there's a good chance the deb from hardy will install fine i guess
<lifeless> mwhudson: na-uh, python-central
<lifeless> mwhudson: pure python doesn't mean what you think it does in a binary distribution world
<mwhudson> well, perhaps
<mwhudson> but getting a newer version installed somehow shouldn't be difficult
<lifeless> it would be a backport
<lifeless> I'm not terribly interested in doing that; I'll just not play with loggerhead for a while
<mwhudson> 'for a while' -- until you get around to dist-upgrade?
<lifeless> yes
<lifeless> probably august or so
<lifeless> doing an adhoc backport is a nuisance; its a local delta, the package manager will try to uninstall it under various circumstances, i need to setup a temp archive, or build it in a ppa
<mwhudson> well, you could probably just untar a paste release and use PYTHONPATH
<lifeless> which then becomes a sysadmin thing-to-remember
<lifeless> and for my home server I want as close to 0 of them as possible
<lifeless> its not a _high_ burden, but they sum
<lifeless> and it deifnitely raises the effort past what I'm willing to do to experiment with loggerhead
<lifeless> - its not 'easy' at this point
<mwhudson> well, ok
<lifeless> mwhudson: I guess I should note that having spent days+ of effort on loggerhead for squid-cache.org, I'm not enthused about more time
<mwhudson> i can't really see anything i can do to help here
<lifeless> mwhudson: as a consumer of it, its a different feel to a developer
<lifeless> mwhudson: I don't think there is much to do; I guess loggerhead could in theory ship a fixed paste function and monkey patch affected versions; but thats quite a lot gross
<mwhudson> gutsy has paste 1.4 that i suspect will work
<mwhudson> _my_ interest in supporting feisty is not so large
<lifeless> I have a sinking feeling about freebsd though
<lifeless> I'm not looking forward to finding out what version it has
<lifeless> fullermd: feel free to give me good news about now
<fullermd> [19:12:09] mortis:/usr/ports/www/py-paste                                       (ttyp9):{550}% make -V PORTVERSION
<fullermd> 1.6
<lifeless> ok, thats good news
<fullermd> It's usually pretty good about being up-to-date on things.  It's just the occasional exceptions like TG that really monkeywrench things   :|
<mwhudson> i'd like to monkeywrench tg
<lifeless> fullermd: to be fair, I suspect that's tg's fault
<mwhudson> i guess it's not a problem for me any more
<lifeless> mwhudson: what would it take to make bb not need tg ? :)
<mwhudson> lifeless: oof
<mwhudson> don't know, probably quite a bit i guess
<lifeless> because BB is still not properly operational for squid
<abentley> lifeless: It would require an alternative identity layer.
<mkanat> mwhudson: Sorry, was away for a bit there.
<mkanat> mwhudson: I'm back now, I'll try that patch.
<lifeless> abentley: thats a tg supplied thing ?
<abentley> Yes, it handles users, groups, permissions, passwords, that sort of thing.
<lifeless> k
<abentley> lifeless: believe me, I've thought about it.
<lifeless> abentley: :>
<mkanat> mwhudson: Yep, that does it. I have to make webpath = '', though, not actually comment it out.
<mwhudson> mkanat: hm, strange, but glad you've got something working
<Verterok> mornin'
<mkanat> mwhudson: Without it I get: http://pastebin.ubuntu.com/22252/
<mwhudson> mkanat: with this patch? http://pastebin.ubuntu.com/22228/
<mkanat> Oh, hmm.
<mwhudson> but anyway, it works, good :)
<mkanat> mwhudson: Ah right, when I use teh *actual* patch it works, yes. :-)
<mkanat> Now let's see if I can figure out what's causing those tracebacks.
<mkanat> mwhudson: Unfortunately GoogleBot doesn't send referers. :-(
<mwhudson> mkanat: yeah :/
<Verterok> abentley: hi, did you notice the mail/branch about BB on mysql? :-)
<mwhudson> mkanat: can you see what the file id in the url is for?
<abentley> Verterok: I see it now.
<Verterok> abentley: in case you want to migrate it to mysql, I already have the env setup, etc...and I'm willing to do it ;-)
<abentley> Verterok: I want to migrate to postres
<Verterok> ups :P
<mkanat> mwhudson: It's for a file.
<mwhudson> mkanat: any particular one?
<Verterok> I can abstract the scripts to have multiple dest. engine
<mwhudson> or is it a variety?
<mkanat> mwhudson: It's a variety.
<mwhudson> hum
<mkanat> mwhudson: However, they're all in the same branch, which might actually have errors in it, since it was made by cvsps-import.
<mwhudson> i can't really imagine how a branch could be _this_ broken :)
<markh> abentley: re that "Trivial UI Change" patch - it seems to me that the 2 strings are actually 2 params - so the spacing was correct in the initial patch
<mkanat> mwhudson: Hmm, might be a race condition--I can open that URL fine.
<mwhudson> mkanat: ??
<mwhudson> but i thought you said it was a file id for a file?
<abentley> markh: You're right.  I saw what I expected to see, not what was there.
<mkanat> mwhudson: I picked out one of the URLs that caused a traceback, and when I open it, there's no problem.
<markh> and while I'm here :)  In my case at least, that message really means "your bzr package is missing something that allows you to do successful ssh" - but strangely, the log in that case does mention that the 'ssh implementation is Putty's plink.'
<markh> if I use a bzr.exe from a binary package, it works correctly
<mwhudson> mkanat: that's really odd
<mkanat> mwhudson: Hmm, or something is wrong with logging--my on-disk debug.log contains no tracebacks, I only saw them with -f -- that could be coincidental, though.
<markh> my bzr is probably not finding paramiko - is there a recommended way to enable debugging messages for that kind of thing?
<abentley> markh: So the problem is that the orig_error param is being misused.
<markh> abentley: yes, that that seems true
<markh> well, that is *a* problem, not *the* problem ;)
<abentley> markh: There are other problems remaining?
<mkanat> mwhudson: Well, it's not causing any visible problem anyhow.
<mwhudson> mkanat: ok
<markh> well - the original problem was simply the recommendation to "-D..." - thats independent of the orig_error abuse :)
<markh> A possible remaining problem is that bzr is being less than helpful - the problem appears to be some inability to auth or otherwise do something related to ssh.
<mkanat> mwhudson: So let's take the one last visible problem that I see--my auto_publish branches have their on-disk path as their bzr URL on the frontpage.
<mkanat> mwhudson: My non-auto-publish branches have the correct URL.
<markh> I do see a message "No supported authentication methods left to try!" so putty is trying to do someting
<mkanat> mwhudson: Because I specified it, of course.
<markh> but my "connectivity and permissions" are fine (which is what bzr suggests I check)
<mwhudson> mkanat: this is probably my url_prefix fix being wrong
<markh> abentley: so even if that isn't really a bug in bzr, any suggestions how I can diagnose what is missing myself?
<markh> (to be clear - putty etc is all setup fine - it works perfectly if I use 'bzr.exe' instead of a source distro)
<lifeless> have you tried -Dtransport?
<markh> hi lifeless - tried nothing yet, still fishing for clues.  I'll try it!
<markh> Output appears identical with -Dtransport
<markh> log too
<lifeless> ok
<lifeless> uhm
<lifeless> python -c 'import paramiko'
<markh> yeah, I'm confident that will fail
<markh> but how could I have bzr tell me that? :)
<markh> ie, I'm not sure what else I don't know I don't have!
<abentley> markh: the suggestion to use D... was orig_error abuse.
<markh> abentley: yeah - I was just saying that the original error was the text itself with is largely independent of the abuse that was uncovered while looking at it
<mwhudson> mkanat: try this: http://pastebin.ubuntu.com/22255/
<markh> as usual, take one bug, get a few for free!
<abentley> markh: If you want to act clever, that's fine.  But I don't need to be involved.
<markh> abentley: sorry, that wasn't my intent
<mkanat> mwhudson: Yes, that works! :-)
<mwhudson> mkanat: cool, i'll commit it then
 * markh gets back in his box...
<abentley> markh: If you want to diagnose why putty can't make a connection, I'd start by running putty.
<mwhudson> mkanat: i'll try to work on the server.webpath thing too, that's going to take a bit more thinking though i expect
<markh> putty can connect fine
<mkanat> mwhudson: No, that works.
<mkanat> mwhudson: I just had read the patch wrong (I did it manually).
<abentley> markh: I wasn't even aware that putty could be used for this.  I would have thought plink
<mwhudson> mkanat: i'd like to remain compatible with old loggerhead.conf files
<mkanat> Ahh.
<abentley> But I guess the next step would be to find out what line bzr is emitting to connect.
<markh> yes, putty's plink
<abentley> So to be clear: plink can connect just fine?
<markh> yes, plink can connect fine.  Putty's pageant is the only program with my ssh key loaded
<markh> so when bzr.exe successfully does ssh, I expect that is also via plink
<markh> but when 'python bzr' does not connect via ssh, the bzr log still indicates it is using putty's plink
<abentley> markh: I wouldn't be surprised if bzr.exe is using paramiko.
<abentley> bzr can use pagent.
<markh> yes, which uses plink :)  I'm not aware of enough of the internals to know if bzr will attempt to use putty *without* paramiko.  I'm not even 100% sure paramiko missing is the problem :)  I was hoping to find something that might tell me so I'm not playing a game of trial-and-error is all.
<lifeless> markh: we use paramiko for sftp logic, not encryption
<abentley> markh: What makes you say pagent uses plink?  I would have assumed that plink uses pagent, not the other way around.
<markh> I meant paramiko uses plink (or at least it has *some* interaction with putty's suite - it talks to pageant's window iirc)
<abentley> markh: It interacts directly with pagent AIUI.
<abentley> It does not have to invoke plink to do it.
<markh> ok - but I'm confident pageant/plink/putty etc are all configured correctly
<lifeless> abentley: how does make_mpdiffs returning a dict sound to you?
<lifeless> abentley: (that or (key, diff) tuples)
<abentley> lifeless: I'd prefer key, diff tuples, so the API doesn't demand loading many file versions in memory at once.
<lifeless> abentley: ok
<abentley> markh: So you probably want to look at bzrlib.transport.ssh.PLinkSubprocessVendor
<lifeless> abentley: I won't guarantee to get to it; but it irritated me to have to zip() in bzr-search over the weekend
<lifeless> abentley: and as we have a massive api break occuring this would be timely
<abentley> lifeless: If we're breaking the API, maybe it should accept keys instead of revision ids.
<lifeless> hmm
<lifeless> poolie_: can I call ?
<lifeless> hmm EAFTP I guess :P
<ToyKeeper> What's this?  API changes which could reduce memory use?  :)
<ToyKeeper> (last time I did a "bzr branch lp:bzr", it failed until I allocated 200+MiB RAM for it)
<lifeless> ToyKeeper: heh. I have test cases that chew up 3-4GB of ram
<ToyKeeper> I finally got around to setting up a bzr server on my openvz host, and was surprised to see branching fail due to memory limits.
<ToyKeeper> It's easy to bump up the limit, at least.  :)
<beuno> hey mwhudson_
<mwhudson_> hi beuno
<beuno> I did notice it. Scratched an itch I had  :)
<beuno> how was your weekend?
<mwhudson> fine, fine
<mwhudson> we're moving this week, so lots of packing and tidying
<beuno> ah, and maybe a better ISP?   :)
<mwhudson> we shall see
<mwhudson> beuno: i played with the merge proposal stuff in launchpad, you probably got some mails about that
<beuno> mwhudson, ah, yes. I was about to ask if you really wanted me to review it or it was a proof-of-concept
<mwhudson> beuno: i'd like you to look at it, yes
<lifeless> so
<lifeless> the big thing remaining for gnome seems to be branding?
<lifeless> Jc2k: ^?
<beuno> mwhudson, cool. That reminds me, now that I can commit to trunk, how would you like the workflow to be?  Commit trivial stuff directly, review bigger changes?  Review everything?  I don't want to step on any toes  :)
<mwhudson> beuno: i think trivial stuff is ok to push directly, but if in doubt get it reviewed
<mwhudson> (not necessarily by me, i suppose)
<Suigintou> anyone have any experience serving a repository over bzr+ssh on a chrooted shell?
<lifeless> not directly; but in theory yes
<lifeless> whats up
<Suigintou> I tried setting it up with jailkit, but bzr doesn't like the new root directory permissions enforced by jailkit (the root dir must be owned by root)
<lifeless> I don't see why bzr would care about that
<Suigintou> me neither, hehe
<lifeless> well, why do you think it is the root dir owner thats the problem?
<Suigintou> I was getting an error message along those lines in auth.log
<Verterok> jelmer: around?
<lifeless> whats auth.log
<lifeless> its not a bzr file
<Suigintou> it's the log file that ssh logs error messages to, located in /var/logs
<Suigintou> er, /var/log
<beuno> mwhudson, I get OOPS-905EB7 when reviewing your merge request  :)
<lifeless> sounds like ssh is having the problem then
<mwhudson> beuno: :)
<lifeless> [I need more detail - I can't guess at what an error message I haven't seen means]
<beuno> mwhudson, seems it works if I specify the *optional* subject
<mwhudson> beuno: oh that
<lifeless> poolie_: ping
<mwhudson> it's a known bug, to be fixed soon
<beuno> does this merge automagically?
 * igc lunch
<mwhudson> beuno: no
<mwhudson> oh, this does remind me
<mwhudson> serve-branches.py currently just sticks the cache in some temporary directory
<mwhudson> this probably isn't totally smar
<mwhudson> t
<beuno> serve-branches.py doesn't use anything from loggerhead.conf, right?
<Suigintou> haha
<Suigintou> now that I'm looking through auth.log, I see that someone has been trying to brute force their way into my server, time to run ssh on a non standard port :)
<mwhudson> beuno: right
<beuno> mwhudson, is that out of choice or just "was faster at the time"?
<mwhudson> beuno: a bit of both, but mostly the former
<beuno> so the plan is to use something else for configuration?
<Suigintou> co
<mwhudson> beuno: you perhaps do me a bit too much credit to assume i have a plan :)
<beuno> hahaha
<beuno> I may be still a bit naive, I'll get over it eventually
<mwhudson> wee
<mwhudson> well
<mwhudson> i guess the first thing to decide, in fact, is: what configuration do we actually need?
<mwhudson> s/we/people/
<beuno> what port to run, where to cache, and what to publish, for starters
<beuno> I suppose then it would get expanded to *what* to cache (search, ie), and new features like exporting tarballs and serving repos
<mwhudson> proxying details
<beuno> is there something very wrong about the current conf file?
<jamesh> maybe it still has some turbogears stink on it
<mwhudson> i find it's way of listing which branches to show and where in the url hierarchy to show them to be almost entirely bogus
<mwhudson> i think that's my main complaint
<mwhudson> and yeah, it's a bit tg-ish
<beuno> right. I've been avoiding getting into some parts of the new code because I'm not sure where it's headed.  Is there some config file you where thinking of making it similar to?
<mwhudson> no
<mwhudson> to be honest, the main use cases i've been thinking around are
<mwhudson> ...
<beuno> uhm, my X restarted for no apparent reason
<mwhudson> beuno: wb
<beuno> L)
<beuno> so, last I read was what you where thinking of
<mwhudson> (1) zero configuration (serve-branches.py)
<mwhudson> (2) Launchpad (custom WSGI glue)
<mwhudson> i'm less sure of a good answer for a middle ground
<mwhudson> someone who has a bunch of branches they want to serve using ProxyPass from their site and who doesn't really want to write code
<beuno> I think that's a bit too drastic. It should be easy to enable/disable certain features, at least if we want to keep building on top of it
<lifeless> poolie_: whhat do you think; committing against a revision only present in a stacked-on repository; should it delta [always], delta[usual algorithm], never-delta?
<beuno> adding per-branch configurations seems to me like a normal operation
<mwhudson> hmm?
<beuno> (2) Implies coding, right?
<beuno> tweaking a .py file?
<mwhudson> i'm not saying that these are the only things we should support
<mwhudson> but rather that these two cases are where the bulk of my thinking has gone so far
<beuno> ah, ok. Well, maybe we can work something out on a wiki page or something
<beuno> zero configuration is good to have, will get people using it faster
<mwhudson_> sigh
<lifeless> mwhudson_: I believe you can buy it in a box
<beuno> it's a bit odd to get an email for a merge request, and then for a review request
<beuno> isn't a merge request a review request by itself?
<igc> reviewing jam's iter_references patch now
<beuno> mwhudson, LH is misbehaving in LP again.  "Please try again" pretty often
<lifeless> 14:03 < beuno> mwhudson, LH is misbehaving in LP again.  "Please try again" pretty often
<lifeless> mwhudson_: who is your ISP
<mwhudson> lifeless: ihug
<lifeless> oh
<mwhudson> i think it's problems with the line, but i'm moving in three days
<lifeless> I don't know that it is :P
<mwhudson> hm, it's codehosting that's bashing vostok currently
<mwhudson> beuno: so re bug 240512, i think your change will sort symlinks after directories and files
<ubottu> Launchpad bug 240512 in loggerhead "Files view should show/sort directories before files" [Medium,In progress] https://launchpad.net/bugs/240512
<mwhudson> beuno: is that what we want?
<mwhudson> beuno: and also, i don't think we want to still put directories first when the user is trying to sort by name
<lifeless> I don't think we want that
<jml> So I've been working on a thread in a loom.
<jml> And I've realised that the top thread should actually be the next-to-bottom thread.
<lifeless> make a new thread over it it
<lifeless> merge -r thread:thing..thread: . into it
<lifeless> commit
<beuno> mwhudson, well, ideally, no. A more complex ordering way would be better, but I cherrypicked that off my new-theme branch, since it's so ugly to see it ordered as currently. Nautilus orders directories before files by name ordering, so that seemed natural to always have
<lifeless> combine-thread the one you want to get rid of
<lifeless> up-thread and commit till its all resolved
<lifeless> get on wif ur life
<lifeless> hmm
<jml> lifeless: that merge will lose my commit history, right?
<lifeless> actually, I think you need to do a reverse merge too into the one you're removing the change from
<lifeless> there is a TODO about making this easier
<lifeless> jml: yes, see under 'its a cherrypicking problem'
<jml> lifeless: just checking. I'm ok with losing history this time, I think.
<mwhudson> beuno: well i think that's crazy :)
<lifeless> I think matching nautilus is ok
<beuno> mwhudson, all other applications I've fired up do it that way
<beuno> what kind of ordering is "directories first then"?
<beuno> as in, how would I go back to it once I order by name?
<mwhudson> the finder doesn't put folders first :)
<mwhudson> but i guess i don't care very much
<beuno> mwhudson, it doesn't order directories first by default?
<mwhudson> no
<beuno> and that doesn't feel wrong to you?
<mwhudson> when you order by name, it put things in ... name order
<beuno> and how do you go back to ordering by directory-first?
<mwhudson> i have to admit, i don't use a graphical file browser very much at all on any system
<mwhudson> beuno: you don't
<beuno> that's what I was worried about  :p
<poolie_> lifeless:  oh my client had disconnected that's why i didn't see it
<lifeless> poolie_: ah
<lifeless> poolie_: you use a irc poxy?
<poolie_> ssh to a server
<poolie_> running screen
<thumper> how do I make a thread in a loom between two?
<thumper> does create-thread make it directly above the current thread?
<lifeless> yes
<thumper> ta
<Peng> With PrefixMiddleware in serve-branches.py, shouldn't there be arguments passed to it? Is it just example code?
<mwhudson> Peng: no, it works off x-forwarded-server
<mwhudson> you might need to add a prefix
<Peng> Oh.
<Peng> Yeah.
<Peng> I am using a prefix.
<mwhudson> then yeah, you need to edit code
<mwhudson> if you can tell me how you'd like to specify this sort of thing, then i can see what i can do :)
<Peng> Oh, I dunno.
<Peng> Maybe just a "prefix = None" line you can edit.
<Peng> Though, since I need the prefix middleware, I'd probably take out the try...except to force it to error out so I'd see it.
 * Peng wanders off. 24 is on!
<thumper> when I up-thread in a loom, should I commit?
<thumper> hmm
<thumper> status seems to indicate I should
<lifeless> if there were unintegrated changes, yes
<lifeless> up-thread is 'switch and then merge '
<Suigintou> ahh, I fixed my problem with getting bzr+ssh working from a chrooted shell, I forgot to make python available to the shell, lol
<lifeless> Suigintou: that would cause bzr some trouble, yes.
<thumper> lifeless: I am quite enjoying my first use of looms-in-anger
<lifeless> thumper: great
 * thumper makes note to write about it
<igc> looking at spiv's patch re Remote-2 tests now
<beuno> mwhudson, sorry for the spam on merge-proposals. It confuses me a lot
<Peng> Hmm, I think the latest changes caused Loggerhead to use more RAM on startup.
<Jc2k> morning lifeless
<beuno> Peng, how "latest"?
<Jc2k> the guadec-web module seemed to choke bzr index - it was at it all night
<Peng> beuno: trunk as of an hour ago vs. trunk as of...a few hours ago.
<Peng> r166 vs. r171.
<beuno> Peng, interesting. Can you revert to 169 and see if the problem persists?
<lifeless> Jc2k: interesting. how big is that modules .bzr/repository ?
<Peng> Urgh.
<Peng> beuno: It used to use 11856 KB. 171 uses 12544 and 169 uses 12244.
<spiv> igc: thanks for the review
<igc> spiv: no problem
<beuno> hrm, so it's not the author bit. mwhudson_, any idea what could of caused the jump since rev166?
<beuno> maybe urlparser import, but 1mb is quite a jump
<Peng> This is odd.
<Peng> 166 is using 12244 too.
<beuno> did your repos get bigger?
<Peng> Does Loggerhead end up importing Bazaar's plugins?
<lifeless> yes
<lifeless> I don't think it loads them all
<lifeless> but it will try for ones it uses itself
<Peng> I upgraded bzr-svn recently..
<Peng> Nothing else though,
<Peng> Anyway, there was still a 300 KB increase between 169 and 171, I think.
<beuno> it may be due to trying to get the author, if there is one. It may be a fair tradeoff  :)
<beuno> I'm off to bed
<beuno> g'night everyone
<Peng> It's right after startup, without any hits.
<Peng> Good night. :)
<vila> beuno: don't go to bed yet ! Just send me a quick reply :)
<Peng> Did someone forget to write a template for the directory index page?
<beuno> damn! I knew I should of closed the laptop  :p
<Peng> :D
<beuno> vila, I'll get to it now
<beuno> Peng, directory index?
<vila> beuno: great :)
<beuno> vila, chmod bits?
<vila> yup, working version already pushed
<Peng> beuno: Like, when you're outside of a branch, and it just lists directories. http://bzr.mattnordhoff.com/loggerhead/
<igc> that's it for me today - off to see a doctor
<igc> see you all tomorrow
<beuno> Peng, ah, that's mwhudson_'s black magic. We probably will need to wrap that around a template
<Peng> loggerhead.apps.filesystem.BranchesFromFileSystemServer.directory_listing
<beuno> vila, sent
 * beuno is off
<lifeless> bye beuno
<beuno> Peng, could you file a bug for that
<lifeless> beuno: also any word on theming for gnome-mirror?
<Peng> beuno: okay
<vila> beuno: thanks, sleep well :)
<Jc2k> lifeless:
<Jc2k> x469yq@isshin:/srv/bzr/guadec-web/.bzr$ du -s repository/
<Jc2k> 338308  repository/
<beuno> lifeless, not yet. It turns out that the current theme is a bit sucky to edit. I will get something reasonable in the next few days, if Jc2k can wait that long  :)
<lifeless> beuno: cool
 * Jc2k can't wait
<Peng> Theme of what?
<lifeless> Jc2k: how many commits is that in ?
<mwhudson_> Peng: the directory listing was written at about 1am i think :)
<lifeless> Jc2k: (bzr revno in the branch you were indexing)
<Peng> mwhudson_: Heh.
<Jc2k> lifeless: only 962
<lifeless> Peng: loggerhead, for http://bzr-mirror.gnome.org
<Peng> mwhudson_: Want me to file a bug?
<Peng> lifeless: Ah.
<mwhudson_> yes please
<Peng> ok
<Jc2k> lifeless: 964, even. but still. it indexed gtk+ with ease, and just gets stuck with no progress bar on guadec-web.
<lifeless> so, it was indexing 300MB of content in one go
<lifeless> Jc2k: try dropping the group count down to 100
<lifeless> that will give it 30MB chunks
<Jc2k> kk
<lifeless> (roughl)
<Jc2k> lifeless: not right now, the git stuff is repacking so they can claim its "smaller and more efficient"
 * Jc2k skuttles off to make an lzma(7z?) repository format for bzr
<lifeless> Jc2k: :P
<Peng> Jc2k: With no fulltexts!
<Peng> Filed as bug 242270.
<ubottu> Launchpad bug 242270 in loggerhead "Directory listing page doesn't use a template" [Undecided,New] https://launchpad.net/bugs/242270
<lifeless> meh, we will do better on size over time; but I really find it hard to credit that that is a significant objection
<lifeless> because, its like claiming gnome 1.2 is what gnome should be judged on
<Jc2k> yeah
<lifeless> rather than (e.g.) focus on usability, direction, responsiveness
<Jc2k> you would think that bzr would be GNOMEy
<Jc2k> i mean it just works
<Jc2k> if GNOME had as many dials and sharp edges as Git, for example, the HIG people would cry.
<lifeless> right
<Jc2k> (actually, someone had the nerve to complain that bzr-gtk could do more to adhere to the hig :P)
<lifeless> and if you want contributors to a friendly system, I think its reasonable to expect the toolchain to be friendly too
<lifeless> Jc2k: turn it into a bug :)
<Jc2k> i think if bzr had rebase -i and the everything-in-one-dir repository format, we could turn a few big names at guadec.
<Jc2k> regardless of whether they are good ideas or not.
<lifeless> jelmer: ^ what are your thoughts on -i?
<lifeless> Jc2k: how hard is -i?
<Jc2k> lifeless: i dont think too hard. the rebase plugin generates a script - we just need to make the script human readable on the -i path and have actions like edit, squash and kill
<lifeless> so,
<Jc2k> lifeless: if you edit though.. you need to be able to commit
<Jc2k> so you can break a commit up in to pieces
<lifeless> I'd like to have everything that gnome folk are calling showstoppers filed as bugs
<lifeless> on the relevant bzr components
<Jc2k> kk
<lifeless> if you think its a good idea, also tag them gnome
<Jc2k> i was just going to say :)
<lifeless> but if we have the bugs, we can track their acceptance/progress more coherently
<Jc2k> i have to head off in a bit, first day at codethink woo, but i'll make sure its done before sleepy time
<lifeless> cool
<mwhudson_> Peng: thanks for the bug, but if you think loggerhead's current look is nice and slick i want some of what you're smoking :)
<Peng> mwhudson_: Hahah.
<Peng> a
<Peng> mwhudson_: Want me to change it to "hideous, overcomplicated, bloated and slow"? :)
<Peng> In all seriousness, I do like Loggerhead's theme.
<Peng> But, I like hgweb's too.
<eMBee> good afternoon
 * eMBee is looking for help on using bzr on an svn repo. is there a howto or manual somewhere? (i am new to bzr)
<RAOF> eMBee: Hi!  It should be pretty simple.
<eMBee> my main concern is that i need to get the trunk and a branch from the svn repo, then commit my changes to the branch and then merge into the trunk (all on svn side)
<RAOF> Hah!  there it is. http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn
<RAOF> That should work, with the bonus that you get to use bzr for the merge :)
<eMBee> oh, nice
<eMBee> is there a way to get all branches from the svn repo?
<RAOF> I don't believe so, no.  Unless the multi-pull plugin works with bzr-svn.
<eMBee> ah, ok, so at least bzr knows about the concept :-)
 * eMBee is used to git, where this is the default
<RAOF> Right.  Whereas bzr has quite a different idea.
<RAOF> You really, really want to create a repository to store the branches you check out from svn, though.
<RAOF> (Basically bzr-init repo svn-branches-go-here; cd svn-branches-go-here; bzr branch svn://mysvn.com/svn/branches/foo)
<eMBee> so i make one repo, and add the branches as i need them?
<eMBee> and then they all live in the same place
<RAOF> The bzr repository is just a space and time saver.  You don't _have_ to have one, but they make it much faster and much smaller.
<RAOF> Branches are everything, one branch per directory.
<eMBee> yes, well, i like the idea of having everything in one repo. that's one thing that is nice about git
<eMBee> can you explain this: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#python-subversion-1-5
<eMBee> what does that mean? (don't answer if it's in the faq, didn't read that yet)
<RAOF> Wheras I really dislike git's branch handling :)
<eMBee> ok, i don't want to do a git-bzr comparison now, just enough to get me started with bzr :-)
<RAOF> That's about bugs in subversion's python bindings.  Particularly, there's a huge memory leak IIRC.
<lifeless> jelmer just committed branch new python svn bindings to bzr-svn trunk
<RAOF> Oh, that's right, true.
<lifeless> eMBee: bzr svn-import will get all branches
 * gour dislike git's all-in-one as well
<eMBee> oh
<RAOF> lifeless: Cool.  Learn something new every day :)
 * eMBee will leave the git-vs-bzr discussion for another day :-)
<RAOF> Awww :)
<lifeless> eMBee: please excuse us vis-a-vis that discussion; we get some advocates here that are +convinced+ there is only one true way
<lifeless> eMBee: svn-import will give you all the branches, and I think it creates everything sensibly for you - e.g. cd /tmp; bzr svn-import svn://blag output
<RAOF> Gah.  Why must clutter's svn be down when I want to branch clutter-sharp?
<lifeless> is clutter gnome?
<eMBee> lifeless: i prefer to convince myself of the better way after i have tried all of them
<RAOF> No, but it might be soonish.
<eMBee> or at least studied someone else try
<lifeless> RAOF: it might be on bzr-mirror.gnome.org
<lifeless> eMBee: I think thats a good idea
<RAOF> lifeless: No, but thanks :(
<strk> help help help !  :)
<lifeless> hi
<strk> moving from cvs to bzr for gnash project
<strk> lifeless: glad to see you up :)
<lifeless> whats up?
<strk> so, I used your suggested init-repo; checkout
<strk> then I've been offline
<strk> so I tought to try 'unbind'
<strk> to commit locally
<strk> and I did
<strk> now (I guess) my changes are in my local repo, right ?
<lifeless> yes
<strk> bzr status doesn't tell me anymore what's different between my copy and the online one
<lifeless> local branch specifically, because you've unbound
<lifeless> as you're working in a checkout style, you should bind again
<lifeless> (just 'bzr bind')
<strk> bzr: ERROR: No location supplied and no previous location known
<lifeless> ok, bzr bzr bzr+ssh://..../trunk
<strk> can it --remember ?
<lifeless> it will after this
<lifeless> (note that you could just have done 'commit --local'
<strk> but it *was* bound before...
<strk> why did it discard in the first place ?
<asabil_> strk: you can use bzr missing in unbound mode
<lifeless> yes, I smell a bug I think :P
<lifeless> asabil_: thats more of a branch-branch workflow
<strk> ah, maybe it's bound already
<lifeless> asabil_: strk is just been thrown in the deep end :P
<strk> after 'bind bzr+ssh...'
<strk> if you 'bind' again (no args)
<strk> it'll give you taht message
<asabil_> lol ok :)
<lifeless> strk: ok
<strk> confusing message
<lifeless> strk: so, 'bzr update; bzr commit'
<strk> request-for-improvement: could it tell you 'already bound to xxxxy' ?
<lifeless> strk: sure; care to file a bug?
<strk> url ?
<lifeless> https://launchpad.net/bzr/
<strk> rob suggested 'pull' in the past, what's the difference between 'pull' and 'update' ?
<lifeless> pull maintains a mirror
<lifeless> but you have local changes
<lifeless> so you need to integrate those with trunk
<_zou> how to uninstall bzr? I'v no experience with python.
<lifeless> there are two ways to integrate - 'update' when you have a checkout(aka bound branch), and 'merge' when you have separate branches
<lifeless> _zou: setup.py uninstall I think. Not sure how good it is
<lifeless> _zou: if you installed via apt/synaptic/rpm use the package managers method for uninstalling
<strk> lifeless: after 'update' I got that message telling me that local commits are now shown as changes, and I have to commit. sounds good.
<strk> problem is, I seem to have 'pending merges'
<strk> no idea what they are
<lifeless> strk: thats your local commit
<lifeless> strk: do 'bzr st'
<gour> jelmer: there will be new bzr-svn release soon?
<_zou> I installed it with "python setup.py install".  "python setup.py uninstall" doesn't work.
<strk> lifeless: unfortunately not only
<strk> I issues a 'merge' before, and got something else
<strk> (things from nelson)
<strk> lemme pastebin 'bzr status' output
<_zou> error: invalid command 'uninstall'
<lifeless> _zou: oh.
<strk> http://rafb.net/p/Kdt8Bz59.html
<lifeless> _zou: you can just remove the bzrlib directory it created, and the bzr binary then
<_zou> can I just reinstall again? I just want to do a uninstall + reinstall.
<strk> lifeless: from that output above, modified and added are my duty, pending merges I'd like to ignore :)
<lifeless> _zou: sure, just install
<lifeless> strk: ok; uhm.
<strk> except for a thing: pending merge include (twice) my own commits :?
<lifeless> strk: I think update should warn then :P
<strk> file another bug ?
<lifeless> strk: lets dig a little deeper irst
<lifeless> you are Sandro ?
<strk> FYI: bug for the other is https://bugs.launchpad.net/bzr/+bug/242284
<ubottu> Launchpad bug 242284 in bzr "confusing error on 'bind'" [Undecided,New]
<strk> yes, I'm Sandro
 * strk belives he made too much noise shooting in the dark
<lifeless> so
<lifeless> I think we should peek behind the scenes a little
 * strk is all ears
<lifeless> can you start up python?
<lifeless> $ python
<lifeless> >>> from bzrlib import workingtree
<lifeless> >>> tree = workingtree.WorkingTree.open('.')
<lifeless> tree.lock_read()
<strk> yep
<lifeless> print tree.get_parent_ids()
<strk> ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv']
<lifeless> strk: ok, you are suffering a bug that is fixed in trunk
 * strk has no idea how did the nelson's desktop got in
<lifeless> tree.unlock()
<lifeless> strk: it was committed to trunk already
<strk> what was committed ?
<lifeless> strk: nelson's change
<lifeless> strk: 'bzr log bzr+ssh://bzr.savannah.gnu.org/gnash/trunk -r -1
<lifeless> strk: bet you his change is the most recent
<strk> ehm... I'm on a gprs connection, would rather avoid bandwidth intensive things
<lifeless> strk: anyhow, see the three duplicates - thats the symptom of the bug, it should just be: ['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv']
<lifeless> strk: shouldn't be that intensive :P
<lifeless> anyhow
<lifeless> do this
<lifeless> tree.unlock()
<lifeless> tree.lock_write()
<strk> ops, got out of python
<strk> doing the 'log' thing
<lifeless> tree.set_parent_ids(['nelson@nelson-desktop-20080623043405-tklw4wtrzmdazxkn', 'strk@keybit.net-20080623082147-9m1vg0o54uotuxfv'])
<lifeless> tree.unlock()
<lifeless> ^D
<eMBee> in order to branch from svn i need to prefix the svn url with svn? or will the original svn url (which is https://...) do?
<strk> ok, killed the log and did the set_parent_ids
<lifeless> eMBee: for most svn repositories the original url will do
<strk> nelson things are gone from 'status' now
<eMBee> most? :-)
<lifeless> eMBee: sometimes (due to bugs/code interactions) you need svn+
<strk> pending merges only contain my own now
<lifeless> strk: 'bzr commit'
<strk> why are then nested ? (mine)
<eMBee> so the svn+ can't hurt? how will i know if it fails?
<strk> http://rafb.net/p/zvJQ3Z11.html <-- this is output
<lifeless> eMBee: it will error at you
<lifeless> strk: they are nested because they are from one parent
<lifeless> strk: if you had two parents, with 5 each you'd see
<lifeless> merge1
<lifeless>   nested2
<lifeless>   nested3
<lifeless>   nested4
<lifeless>   nested5
<lifeless> merge2
<lifeless>   ...
<lifeless> etc
<eMBee> hmm: bzr: ERROR: Unsupported protocol for url "svn+https://...
<eMBee> am i missing the bzr-svn plugin?
<lifeless> you have more than 2 parents when you do what git calls an octopus merge
<lifeless> eMBee: do 'bzr help svn'
<eMBee> this is debian etch with bzr from backposrts
<eMBee> backports
<eMBee> no help found, looks like it's missing
<strk> lifeless: I find that indenting confusing too :)
<eMBee> where do i get the svn plugin for etch/backports?
<strk> it looks like 'nested2' is somewhat 'contained into' 'merge1'
<lifeless> strk: hmm, we'll need to look at making it better. but that is what it means
<lifeless> strk: merge1 is the tip of the branch being merged; neste2..nested5 are other commits on that branch
<strk> but the change log for first-level (what you call 'merge1') only talks about a change which is on the same level of the change advertised in log for 'nested2'
<lifeless> strk: topologically, merge1 is a child of nested2; and nested2 is being indirectly merged, rather than directly referenced
<eMBee> looks like bzr-svn is not in backports yet. can i risk installing the lenny version?
<strk> indeed 'Add test for global/local registers
<strk> was committed locally *after* 'Make registers access safer and more general
<lifeless> eMBee: I would say it should be fine; you'll want svn too
<lifeless> strk: right
<lifeless> strk: thats what its showing you
<eMBee> lifeless: what do you mean? i want to update svn?
<strk> confusingly :)
<lifeless> eMBee: bzr-svn needs certain versions of the svn python bindings; many bugs in those were found while writing the plugin
<eMBee> ah, right, i was asking about that earlier (maybe missed the reply then)
<lifeless> if you are running packaged bzr-svn, its dependencies sould force this update anyway
<eMBee> right
<eMBee> thanks
<lifeless> np
<strk> commit is taking a lot, should transfer ~ 120 kb for a new file and 4/5 Makefile.am change
<strk> and, mmm.. I guess 2/3 lines of commit log
<lifeless> strk: check ~/.bzr.log
<_zou> What I did at step1: bzr branch  bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck
<_zou> step2: I modified a local file named MatrixTest.cpp
<lifeless> strk: there is a thing called autopack which will kick in about 1 time in 10 (and in the next release of bzr hopefully never)
<lifeless> strk: that may have occured
<_zou> step3: bzr commit MatrixTest.cpp (seems succeeded)
<strk> 63.403  Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('bzr+ssh://strk@bzr.savannah.gnu.org/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>)
<lifeless> strk: oh yeah, waht version of bzr do you have ?
<strk> _zou: I guess you've committed to local branch, not remote
<strk> _zou: bzr info should tell you the kind of tree you have
<strk> lifeless: 1.3.1
<lifeless> strk: right, 1.5 is substantially faster; 1.6 should be even more so
<_zou> strk: "Committed revision 9422"   I guess so, I haven't see any mail notifications.
<lifeless> that reminds me
<strk> _zou: mail notification doesn't work yet it seems
<lifeless> I was going to nag
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> strk: centralised ones are tricky, *decentralised* work just fine - the bzr-email plugin :)
<lifeless> spiv: ^ email notifications && smart server && HOWTO
<strk> _zou: I guess you should 'bzr bind' to make commits go to the master repo
<strk> lifeless: I don't have a working outputing mail system
<strk> it's easier when done centralized...
<lifeless> strk: sure, and there are a couple of answers for it
<strk> we likely don't want to get mail on each local commit anyway
<lifeless> first I interrogate spiv
<spiv> lifeless: first server-side notifications need to work :(
<lifeless> spiv: you had a patch I thought ?
<spiv> They're close, but when I did a quick experiment they aren't there yet.  Probably fixed by accident by one of my push-acceleration patches in BB atm though.
<lifeless> spiv: ah
<_zou> strk: There should be a commands list to follow. And some feedbacks to confirm if I have done it successfully.
<spiv> (IIRC the current problem is that the client does not actually invoke a set_last_revision RPC)
<lifeless> strk: I'll mail rob and sylvain the alioth solution tomorrow
<strk> _zou: we're all trying to find out :)
<strk> _zou: the simplest seems to be 'checkout; add; commit;'
<spiv> lifeless: the next issue after that is making sure the configuration isn't terrible :)
<strk> _zou: warranty void since you did 'branch' instead of 'checkout' I guess :P
<lifeless> spiv: I want it to be 'install bzr-email on the server; set a config just like you would on your own machine'
<spiv> lifeless: me too, I think.
 * strk commit is still hung with high network traffic
<lifeless> I think mtaylor has some stuff for email on push/pull with bzr-email
<spiv> lifeless: I'm sure that's a great first cut at least, and no doubt user feedback will help refine from there.
<_zou> strk: "bzr branch  bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunck" that's what I did.
<strk> is an upgrade of bzr planned in Feisty ?
<lifeless> strk: we'll probably get something into a backport
<strk> _zou: that should have created a local repository, to which your commit would go (I think)
<lifeless> strk: but we already offer a ppa
<lifeless> _zou: that has made a new branch
<strk> ppa?
<lifeless> _zou: and your commits are isolated in that branch until you merge them into trunk
<lifeless> _zou: to merge them into trunk:
<lifeless> 'bzr co bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk trunk; cd trunk; bzr merge OTHERBRANCH; bzr commit'
<lifeless> _zou: or, do exactly what I did with strk above - bind the branch, then update and commit
<strk> ouch, sounds expensive
<_zou> lifeless: tree.lock()?
<lifeless> strk: well, a shared repository - which you all should have - means that that has almost no network overhead
<strk> _zou: no, that's just debugging stuff
<strk> _zou: bzr help; bzr help bind;
<lifeless> _zou: what bzr version do you have
<lifeless> http://bazaar-vcs.org/Download
<strk> bzr bind bzr+ssh://zoulunkai@bzr.savannah.gnu.org/gnash/trunk
<_zou> lifeless: 1.5
<strk> argh!
<strk> 956.587  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x85efbcc>, which has 33 pack files, containing 9971 revisions into 26 packs.
<strk> it kicked in, it's my day !
<lifeless> strk: congrats, you get a prize
<lifeless> strk: its going to be combining 7 packs, should be 1 commit each and small - but if you want to cancel, just hit ctrl-C
<lifeless> strk: actually, don't
<_zou> lifeless:  "bzr merge OTHERBRANCH" I don't know any other branches. I want my commit to be in head.
<lifeless> strk: I just remembered, you're commiting :)
<lifeless> _zou: you made a new branch when you ran 'bzr branch'
<lifeless> _zou: the 'branch' command always makes a new branch
<strk> lifeless: how should the /etc/apt/source.list line look like to get a new version ?
<strk> deb https://launchpad.net/~bzr/+archive <-- this is reported to be malformed, never learned exact format
<strk>  http://bazaar-vcs.org/DistroDownloads <-- this page doesn't tell exactly
<lifeless> strk: click on the ppa repository link
<strk> beta ?
<lifeless> no
<strk> k
<lifeless> 'ppa repository' I think it says
<strk> the intrepid stuff ?
<lifeless> well, there is a drop-down
<lifeless> change the drop-down to feisty :)
<strk> is that 'bzr' specific ?
<strk> or would I get new versions of other packages too ?
<strk> or, what does 'ppa' stands for ? :)
<Kinnison> personal package archive IIRC
<Peng> indeed
 * strk Committed revision 9422. (hurray)
 * strk_ hates gprs ...
<strk_> 9422 committed ...
<strk_> so, I was asking, will the ppa addition in source.list pull-in other experimental packages beside bazaar ?
<lifeless> strk: no
<lifeless> strk: only what we upload there, and we only put bzr + plugins
<strk_> is there a way to tell apt-get update to only fetch from the new url (to reduce bandwidth)
<lifeless> strk: no, but it does HEAD's anyway
<strk_> ok
<strk_> safe to upgrade to 1.5 ? any preparatory work I need ?
<lifeless> go for it
<strk_> uhm... Get:6 http://us.archive.ubuntu.com hardy-updates/main Packages [258kB] <--- my day.. taking time
<strk_> is it normal to have 'hardy' stuff in a 'feisty' system btw ?
<lifeless> strk_: uhm, thats unusual indeed
<lifeless> strk_: are you sure you haven't upgraded to hardy already ? :)
<lifeless> strk_: 'lsb-release -a'
<strk_> uhm...
<strk_> I guess I did, I tought feisty was more recent
<strk_> what's this fever to give releases a name ?! gah
<lifeless> 'f', 'g', 'h'
<lifeless> you should use the hardy line for the ppa too :P
<strk_> oh, that helps, thanks :)
<strk_> alright, I hope it won't break everything (pm are so weak)
<strk_> 30minutes to go...
<strk_> so, about 'bind/unbind' .. is that a good habit for switching between online-offline work ?
<lifeless> its designed to support that
<lifeless> a better one would be to create a new branch
<lifeless> and work in the branch all the time
<lifeless> then when you are online and ready to put your work in trunk
<lifeless> cd $trunk
<lifeless> bzr update
<lifeless> bzr merge ../your-other-branch
<lifeless> bzr commit
<strk_> good. I guess the alternative would be keeping two different trees, which would mean reconfiguring all build trees
<strk_> bzr merge $mybranch.
<Ng> if I have two branches, one of which is suppoesd to be a clone of the other but has somehow diverged, can I get some useful information as to how they have diverged? or should I just diff them?
<lifeless> Ng: bzr missing
<strk_> right
<lifeless> Ng: bzr diff -r branch:other
<lifeless> Ng: bzr merge --preview other
<strk_> but all the build trees point to a single source tree
<Ng> lifeless: hmm, missing is interesting, thanks :)
<lifeless> strk_: ok
<strk_> if I have the build trees point to my own branch I'll have to keep it up to date too when it seems safe. sounds too complex atm.
<lifeless> strk_: you might find having the build tree not be a branch at all
<lifeless> strk_: consider this:
<lifeless> ~
<lifeless> repo/trunk
<lifeless> repo/mybranch
<lifeless> source/working
<lifeless> build/treea,treeb etc etc
<strk_> working symlinking to trunk/mybranch as needed ?
<lifeless> if you create source/working by doing 'bzr checkout --lightweight
<lifeless> and in repo/trunk and repo/mybranch there is no source code files at all
<lifeless> you would use the 'bzr switch' command to point working at either trunk, or mybranch, as you desire
<bob2> lifeless: how crack-headed do you think a git-ish-all-branches-in-one-dir repo format would be?
<lifeless> bob2: I don't think its crack-headed, but I think its really less nice to work with
<Kinnison> bob2: my 2Â¢ is that it'd be nasty :-)
<strk_> I don't get the 'no source code files at all' part
<lifeless> strk_: ok
<strk_> you mean no 'working' files, but 'in-repo' only ones ?
<lifeless> strk_: I think doco is the best thing at this point
<lifeless> bzr help working-trees
<lifeless> strk_: I mean that there would only be a .bzr diredctory at repo/trunk and repo/mybranch
<strk_> there would be two repos with no working trees in them
<lifeless> strk_: 1 repo. 2 branches. no working trees
<strk_> or, two branches
<lifeless> it might be easiest to show you
<lifeless> you made a repo already correct?
<strk_> yes, and I just tried 'remove-tree'
<strk_> unfortunately, it didn't clean everything up (./autogen.sh created files left)
<strk_> would a rm -Rf * be safe ?
<lifeless> yes (as long as .bzr stays around, its fine)
<strk_> then I'm doing:
<strk_> cd ../gnash-head; bzr checkout --lightweight ../bzr-local-repository/trunk
<strk_> bzr-local-repository/trunk
<strk_> gnash-head
<lifeless> right
<strk_> ok
<strk_> now, the local branch
<strk_> cd bzr-local-repository; bzr branch trunk mybranch ?
<lifeless> yes
<lifeless> exactly in fact
<lifeless> because your repository is set to create trees you'll want to remove-tree right away
<strk_> k
<strk_> ops
<strk_> what tells me when the repository is set to create trees ?
<strk_> and how to change it ?
 * strk_ running remove-tree in 'mybranch' meanwhile
<lifeless> touch .bzr/repository/no-working-trees
<strk_> alright, I have trunk and mybranch with no working trees now
<lifeless> ok
<lifeless> and your builds all can point at gnash-head. (actually I'd rename it gnash-working or something)
<strk_> I'll need multiple 'working' trees
<lifeless> strk_: you will?
<strk_> with cvs, I had one each branch
<lifeless> (I got the impression you wanted just one)
<strk_> usually only using head and release branch
<strk_> well, just one each 'set' of build trees
<strk_> I usually work with 2 ones, head and release branch
<lifeless> you can have as many working trees as you want
<strk_> actually, I also have a third one, which I used to call 'gnash-head-backup'
<strk_> that's for when I made local changes and wanted to use plain trunk
<lifeless> now there is a new command that you can use
<lifeless> cd to the working tree
<lifeless> and run 'bzr switch mybranch'
<strk_> ok, gnash-head is now my working tree:
<strk_> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<strk_> Switched to branch: /home/strk/src/gnash/bzr-local-repository/mybranch/
<strk_> Switched to branch: /home/strk/src/gnash/bzr-local-repository/trunk/
<strk_> nice :)
<lifeless> now when you commit the commits will go to mybranch
<lifeless> and now trunk
<lifeless> so to work offline:
<lifeless> switch mybranch
<lifeless> hack commit hack commit hack commit
<lifeless> come oneline
<lifeless> bzr shelve/revert/commit (so that 'bzr st' shows no changes)
<lifeless> bzr switch trunk
<lifeless> bzr update
<lifeless> bzr merge ../bzr-local-repository/mybranch
<lifeless> (run any tests etc)
<lifeless> bzr commit
<lifeless> make sense?
<strk_> I guess so
<strk_> this is assuming 'commit' on a trunk-bound working tree will push online ?
<lifeless> yes
<strk_> even if 'trunk' is local...
<lifeless> its assuming trunk is still a bound branch
<strk_> trunk info: Repository bound branch (format: pack-0.92)
<lifeless> yup
<strk_> mybranch info: Repository branch (format: pack-0.92)
<strk_> bzr @ 1.5 now
<strk_> now, lemme try to do the 'gnash-head-backup' equivalent
<strk_> that'd be a working tree bound to the local 'trunk' which is bound to the online 'trunk'
<strk_> which I'll use for in-source-tree building
<strk_> still --lightweight ?
<lifeless> yes
<strk_> bzr checkout --lightweight bzr-local-repository/trunk
<strk_> can I give an additional arg to name the created dir ?
<strk_> bzr checkout --lightweight bzr-local-repository/trunk gnash-head-backup ?
<lifeless> yes
<strk_> I guess last thing would be release branches
<strk_> is there a command to query a repository for the list of branches available there ?
<lifeless> bzr branches
<lifeless> (with URL for a remote list)
<strk_> with no URL what does it use ?
<lifeless> '.'
<lifeless> hmm, probably could give it some heuristic love
<lifeless> make it aware of being in a checkout
<strk_> mmm... I guess I have no branches locally, since I only have trunk...
<lifeless> strk_: and mybranch
<strk_> oh
<strk_> still bzr branches lists nothing when issued inside 'trunk' or inside the working tree
<lifeless> yeah, its a very literal commanda t the moment
<strk_> it does when isued from top-level dir
<strk_> makes sense
<strk_> trying it remotely
<strk_> sloooow :(
<strk_> bzr branches bzr+ssh://strk@bzr.savannah.gnu.org/gnash
<strk_> isn't it just 10/15 strings to transfer ?
<lifeless> there is no specific RPC for it yet
<lifeless> so its listdir + open_branch per dir
<lifeless> which is another way of saying 'no but it will be in the future'
<strk_> still not done fetching branches...
<strk_> 6 minutes later
<lifeless> its recursed into the tags and branches dirs
<lifeless> you're paying GPRS latency :(. This is all predictable (and frustrating)
<strk_> ? how many ssh connections ?
<lifeless> one connection
<lifeless> and it should be one round trip per branch/tag
<lifeless> back in a sec
 * strk_ realizes he didn't pipe to less :!
 * strk_ gets the videocam ready ;P
<strk_> nah, I kill, don't care about branches now anyway
<strk_> thanks for your time lifeless, I'll be offline
<shai_hulud> hi. how do I merge pending merges. I did bzr merge --pull <repo> and had a conflict on the way. now I'd like to continue merging, but I get a message that i have uncommited changes
<mlh> what's 1.6 got over 1.5?
<mlh> I'm about to d/l for windows and curious about the difference 1.5 -> 1.6b2
<mlh> and didn't find release notes / roadmap
<mlh> hrm, never mind, there is no 1.6b for win
<lifeless> :P
<mlh> :-)
<mlh> you just got mail on a trivial wiki change
<mlh> Bialix's last name
<jelmer> Verterok: hi
<Verterok> jelmer: hi
<jrb_> In a shared repository if I don't need some branch anymore: is it enough to just delete the branch (rm) to remove all traces of the branch?
<radix> jrb_: the revisions that the branch pointed to will still be in the repository
<radix> jrb_: mostly that's fine since generally those revisions become a part of trunk or whatever
<Verterok> jelmer: while playing with bzr-svn new bindings (I must say, cool!), before building the mac OSX package/installer I encountered with a known bzr tests problem in os x, http://rafb.net/p/MbdV9D77.html
<radix> if you've got a branch with a commit of a 8GB file and you don't want that sitting in your repository, though, it can be a problem
<jrb_> radix: So what happens if I create a branch with the same name later on? Is there no remove-branch command?
<radix> jrb_: the name of the branch won't matter at all
<lifeless> jrb_: just delete the directory, that gets rid of teh branch
<radix> jrb_: what's your concern, exactly?
<nysin> Is there a way to bzr diff (without making basically a shell program to use --using or --diff-options with) ignoring certain files and directories? Mainly certain big ones that are in one branch but not another and just clutter up a diff uninterestingly.
<jrb_> since the name of the branch does not matter it isn't much of a problem to me. I was just wondering.
<lifeless> nysin: well you can use filterdiff
<radix> jrb_: cool
<nysin> oh IIRC in difftools or something, a separate package, right?
<lifeless> nysin: but there is a bug option to support --exclude or some such as part of bzr diff
<nysin> Ah, well, I look forward to that, in the meantime I'd forgotten about filterdiff
<jrb_> radix: thanks for the info and bye
<nysin> lifeless, have a link to that bug?
<lifeless> nope, just remember someone talking about it last week
<nysin> okay
<lifeless> nysin: if you can't find it, feel free to open another
<jelmer> Verterok: what sort of thing were you pushing?
<nysin> yup; I'm sure someone will mark it as a dupe, but that's just as good
<Verterok> jelmer: the bzr-eclipse, just for testing....it contains ~160 mainline commits
<nysin> https://bugs.launchpad.net/bzr/+bug/53992
<ubottu> Launchpad bug 53992 in bzr "diff should have an -x option (exclude certain files)" [Wishlist,Confirmed]
<jelmer> Verterok: you seem to've hit an endless loop somehow
<jrb_> radix: oh wait. one more question. since the history of the deleted branch is still available in the repository how can I get it back after I have deleted the branch. just in case I ever need that.
<jelmer> Verterok: _dir_process() should be run for each level of directories that's being committed
<lifeless> jrb_:  there is a heads() plugin
<radix> jrb_: If you've merged the branch into another, it's much easier
<radix> oh
<radix> or maybe you can use something called the heads() plugin, but I have no idea what that is.
<lifeless> jrb_: you can just run heads --all (IIRC) and it will list the revision ids
<radix> I know how to get a branch that's been merged into another
<jrb_> lifeless: okay I look into that, thx
<lifeless> jrb_: I think there is an option to list only the invisible heads, which will be your deleted branch
<Verterok> jelmer: oh, I see. bzr-eclipsse structure conatins lots of empty and nested, directories, i.e: core/org/vcs/bazaar/eclipse/foo/bar,java
<Verterok> jelmer: could that be a problem?
<jelmer> Verterok: that probably explains why svn needs that many open file handles
<jelmer> Verterok: if your limits are very conservative atm you may want to consider increasing them
<Pilky> is bzr pull --overwrite just meant to replace what is on my branch with whatever is on the branch I'm pulling from?
<Pilky> because I tried it yesterday but got conflicts
<lifeless> Pilky: you shouldn't have, unless a directory with non-versioned files in it was deleted
<Verterok> jelmer: ok, thanks. I'll try to increase the limits
<Pilky> lifeless: all I'd done was change some files, and then want to replace them with the ones on my server
<lifeless> Pilky: had you committed those changes?
<Pilky> nope
<lifeless> then thats why
<Pilky> ah
<lifeless> pull preserves local edits
<lifeless> they were local edits (as opposed to commits which can be overriden)
<Pilky> so in future, revert and then pull
<Pilky> if I want to replace what I have
<lifeless> for this scnenario, yes
<Pilky> ok, thanks
<nysin> It appears that using --diff-options doesn't even work
<nysin> because bzr seems to special-case new files
<nysin> so if e.g. I tell it to use --using=cat, then most files are just cat'd, but wholly new files are done internally (because they still look vaguely diff-like)
<lifeless> uhm
<lifeless> --using
<lifeless> and --diff-options
<lifeless> are mutually exclusive options
<nysin> oh
<lifeless> --diff-options says 'pass these options to diff'
<Verterok> abentley: the script to move from sqlite, now also works in postgres :-)
<lifeless> --using says 'use this script to do diffs'
<nysin> Er, right. Whoops. Well right now I'm acutally only specifying --using
<nysin> So my comment above still applies except just to --using I guess
<lifeless> I'm not sure they /should/ be mutually incompatible, but thats what I recall reading in a bug report
<Verterok> abentley: sorry, to move BB db from sqlite
<jelmer> beuno: hi
<nysin> And --diff-options seems problematic because it (as determined by forcing it to throw an error to see commandline) uses randomly named files in /tmp and just --labels them so -x and -X don't seem to work (I've tried the very simplest cases, where it's not in a directory, has no spaces in the filenames, etc)
<Jc2k> beuno, lifeless: lo
<Jc2k> i was talking to robtaylor and we wondered....
<Jc2k> could we have a "wall of outstanding"
<Jc2k> e.g. get all fixmes in the whole of gnome :p
<Jc2k> laggy laggy
 * Jc2k back to work
<abentley> lifeless: Well --diff-options is unnecessary when using --using
<abentley> And what are you doing up?
<mlh> is there anyway to get a branch over http if the http server hides dot files?
<mlh> (Im thinking maybe bzr has an alternate name for .bzr - _bzr perhaps?
<jelmer> Jc2k: that sounds like a nice idea
<mlh> if not,  thats ok , I can get via ftp with password
<nysin> (filterdiff ended up working fine, though there would be substantial network win if the filtering could be done before retrieving megabytes of stuff...)
<nysin> doing it locally for the moment means it doesn't really matter though
<Pieter> is bzr under windows really slow or is it possible it hangs without giving any output?
<jelmer> mlh: you should be able to fetch that branch even if it's not included in directory listings
<Peng> mlh: Server-generated directory listings really don't matter. They're nothing magic, just another HTML page. Of course, the server could actually access to dot files too...
<beuno> jelmer, hey
<jelmer> beuno: I'm still interested in uploading bzr-upload's Debian package
<beuno> jelmer, ah, yes. I have an email about no bein able to branch that...  can you give me the URL again?
<jelmer> http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable
<jelmer> e.g. bzr builddeb http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable
<james_w> you might need nosmart+ to access bzr.debian.org until 1.6 is out.
<james_w> hi jelmer
<james_w> hi beuno
<beuno> howdy james_w
<beuno> jelmer, thanks, I'll pass that on now
<jelmer> hi James
<jelmer> james_w: Ah, bzr builddeb nosmart+http://bzr.debian.org/pkg-bazaar/bzr-upload/unstable fails for me atm because the tree isn't locked
<james_w> ok
<jelmer> adding a lock in cmd_builddeb() fixes it. I'll send you a patch
<james_w> thanks
<jelmer> sent
<jelmer> beuno: so it may be necessary to create a local copy of that branch first
<jelmer> rather than using bzr builddeb on the remote url
<beuno> jelmer, ah, ok. Just sent that off in another email too.
<emgent> fog: hi
<lamont> No handlers could be found for logger "bzr"
<lamont> what's that mean?
<fog> emgent: hey
<quicksilver> if you did a bzr update (or bzr pull) which yielded some conflicts
<quicksilver> and you decide you don't really want to resolve them now
<quicksilver> can you undo it?
<beuno> quicksilver, bzr revert
<quicksilver> I don't think so.
<quicksilver> I think bzr rever will throw away my local changes.
<jelmer> quicksilver: You mean, commit with conflict markers?
<quicksilver> precisely the opposite of what I wish to do.
<quicksilver> jelmer: rollback the update/pull.
<quicksilver> previously my local copy was on revision 10 (say).
<quicksilver> I had local changes.
<jelmer> quicksilver, maybe something like "bzr merge --force -r43..41"
<quicksilver> pulling revision 11 lead to lots of conflicts I don't wish to resolve today.
<quicksilver> instead I wish to return to my previous situation
<jelmer> if the changes you merged in were revno 41 to 43
<quicksilver> (revision 10 + local changes)
<jelmer> hmm, I doubt that'd help with conflicts though
<beuno> can you merge with uncommitted changes?
<beuno> if so, you shouldn't  :)
<beuno> and then use revert
<jelmer> beuno, you can't merge
<jelmer> but you can pull
<quicksilver> you can both pull and update with uncommitted changes
<quicksilver> as long as you're tracking fairly closely it's quite a sane thing to do
<quicksilver> btu I believe it lacks the ability to undo if it goes wrong
<quicksilver> which is why I asked the question here ;)
<quicksilver> it's a bit unusual since most bzr operations are undoable.
<jelmer> yeah, reversibility ftw
<jelmer> quicksilver: I wonder what the sanest UI for this would be though
<strk> lifeless: so I did 'commit' when bound to 'mybranch', then 'switch', 'merge ../mybranch', cleanup stuff, commit
<strk> taking forever as usual :)
<awilkins> Once again, win32 packages lag behind the bleeding edge....
 * awilkins waves his neatly set up win32 build environment that takes about 10 seconds to build both Python-style packages
<jelmer> hi awilkins
<awilkins> jelmer: Hello jelmer, after dinner I can spend some time trying to get those extensions to build
<awilkins> I think maybe I should install a 4-series GCC in my MinGW
<awilkins> Anyhow, time to cook some chicken soup ; back later
<cr3> how can I reverse a commit between release 530..529? too late for an uncommit
<beuno> cr3, you want to go back to the state of 529?
<cr3> maybe bzr diff -r530..529 | patch -p1 or somesuch
<beuno> cr3, bzr revert -r 529
<cr3> beuno: only reverse that commit, not all the commits since then
<fullermd> No, you don't want that...   merge can do it.
<fullermd> bzr merge -r530..529 .
<cr3> fullermd: excellent, thanks!
<melat0nin> hi all
<melat0nin> got a simple question.. how do i download a branch from a revision other than the most recent?
<beuno> melat0nin, bzr branch -r revno
<melat0nin> beuno: then the branch url?
<beuno> melat0nin, yeap, the order doesn't matter really
<melat0nin> beuno: great, thanks :)
<beuno> as long as -r is followed by the revno
<melat0nin> cool
<quicksilver> jelmer: bzr backtrack -r123 ?
<quicksilver> jelmer: meaning backtrack repo to revision 123, keep uncommitted working changes
<tethridge> where is the mailing list for bazaar?
<tethridge> found it
<tethridge> I was looking on launchpad
<tethridge> it's not on there.  :-)
<awilkins> jelmer: Ping?
<jelmer> awilkins: pong
<awilkins> Which compiler are you using on these extensions?
<jelmer> quicksilver: Hmm, what if you do two pulls in a row and then want to back both of them out?
<jelmer> awilkins: I'm using gcc
<awilkins> Which version?
<awilkins> The MinGW 4-series GCC is marked as "Warning: This is an alpha testing release.  That means the build may
<awilkins> contain major missing functionality and serious bugs, including silent
<awilkins> incorrect code compilation.
<jelmer> awilkins: 4.3.1
<jelmer> awilkins: I'm on Linux though
<awilkins> I think some of the C idioms you are using are not liked by the 3 series compiler
<jelmer> which ones? Can you pastebin the output?
<awilkins> Sure
<awilkins> jelmer: Going to be a little while, the last revision busted my windows setup script
<jelmer> awilkins: k
<awilkins> jelmer: Are the PAR ldflags very important?
<awilkins> *APR
<jelmer> awilkins: depends on what they are exactly :-)
<jelmer> here on Linux, they're actually empty
<awilkins> jelmer: On windows, it's hard to tell because apr-config is a bash script :-)
<jelmer> awilkins, ah :-)
<jelmer> awilkins, I think you should be able to get away with ignoring them
<lifeless> Jc2k: interesting ide
<lifeless> abentley: it was 23:20 or so;
<lifeless> *now* its 0640 and wtf am I doing up is what I'm asking myself
<abentley> hehe
<Jc2k> thinking about implementing the wall of GNOME ;)
<beuno> goooooooood morning lifeless
<beuno> Jc2k, if everything goes as planned, I'll get to theming for Gnome in about an hour or so
<beuno> then we have to see if that actually brings any useful results  :)
<Verterok> mornin'
<lifeless> beuno: cool!
<mwhudson> mornings
<beuno> seÃ±or mwhudson, good morning
<Jc2k> beuno: awesome :)
<beuno> I have a few things to bounce off you when you're past your morning coffee
<beuno> remember=revid is bugging the hell out of me
<mwhudson> ah haha
<beuno> it doesn't seem to work, the UI for it sucks badly, and it breaks the beautiful new theme
<mwhudson> hm, if it's broken it broke recently
<beuno> so it's down to "fix it" or "remove it, make plans for something much better soon"
<beuno> mwhudson, well, it's broken on LP
<mwhudson> it's a terrible terrible ui though
<mwhudson> beuno: oh
<mwhudson> :)
<mwhudson> maybe it works in trunk then
<beuno> let me try, I think not
<beuno> it does not!
<beuno> oh
<beuno> it does
<beuno> ew
<mwhudson> i think it may just be even harder to use than you expected :)
<beuno> it works on LP too
<beuno> yes
<beuno> it's an extra step
<beuno> worse UI then I thought then
<beuno> ugh, ok, I'll change the bug si it's "make it better"
<quicksilver> jelmer: I don't know. I don't know enough about how bzr stores stuff.
<Verterok> abentley: hi
<quicksilver> jelmer: I don't even know if the data exists to unmerge the local changes.
<Verterok> abentley: done, the migration scripts now support postgresql ;-)
<quicksilver> jelmer: or if you'd have to explicitly 'save' state when doing a 'bzr update'.
<abentley> Verterok: Thanks.  I saw that this morning.  Haven't had a chance to try it.
<quicksilver> jelmer: maybe that is the simplest solution; have 'bzr update' (or pull) explicitly save the local diff and the revision number in an undo history.
<Verterok> abentley: np, glad to help, in case you find any problems with the scripts drop me an email or ping me
<beuno> abentley, that would be a cool link to add to "merge request" in LP. A link to the diff between the missing revisions.
<abentley> beuno: Yes, showing diffs is on our roadmap.
<beuno> abentley, cool  :)  That would make it much more BB-like
<abentley> beuno: In fact, today I've been working on adding the ability to show a diff of "x merged into y assuming z is already merged into y".
<beuno> abentley, It's getting more advanced, yay!  :)
<awilkins> jelmer: Ok, first problem, no svn_client_commit_item_2_t in 1.4.6 (although now 1.5 is live I suppose I ought to use it ...)
<jelmer> awilkins: Strange, it works fine here
<awilkins> Is it in the headers?
<jelmer> ahh, it's a typo
<jelmer> awilkins, please pull from the 0.4 branch
<jelmer> It was part of an assert() that wasn't being compiled on my machine
 * awilkins pulls
<jelmer> because I was using -DNDEBUG
<awilkins> Bugger, more conflicts :-(
<mwhudson> beuno: your update of the description on 242469 made me chuckle
<beuno> mwhudson, some frustration may of passed on to there  :)
<awilkins> jelmer: Same error, line 85 of client.c
<awilkins> jelmer: Ok, typo fixed
<awilkins> jelmer: And now back to our friendly "initializer element not constant"
<awilkins> client.c:750
<awilkins> I think it's the sizeof()
<jelmer> awilkins: You may want to change the &PyType_Type to just NULL
<awilkins> jelmer: Same in editor.c:[63,135,139,35-,354,444]
<awilkins> jelmer: Changing to NULL fixed some of those (where the &PyTYpe_Type was)
<awilkins> But not all
<awilkins> http://pastebin.ca/1054359
<jelmer> awilkins: you may want to try setting tp_dealloc to NULL in some of these cases where I've set it to PyObject_Del
<awilkins> jelmer: Wahey, next .c files worth of errors :-)
<awilkins> Same things again , methinks
 * awilkins hands out the NULL pointers
 * awilkins updates paste
<awilkins> OK, C errors fixed, now back to Python ones :-)
<mwhudson> if the objects go through PyType_Ready you can leave ob_type and tp_dealloc to null (and maybe some other fields too)
<awilkins> Distutils is choking now :-(
<lazy1> is there a way to preview what "bzr push" will do?
<mwhudson> missing, sorta
<mwhudson> lazy1: what sort of answer do you want?
<mwhudson> a diff?  a list of revisions?
<lazy1> bzr push --preview
<lazy1> :)
<lazy1> is there a shortcut for "last pulled revision"? (so I can use "bzr log")
<LarstiQ> lazy1: yes, but what would you like the output of that to be? (Ie, are you after `bzr missing push/location`?)
<awilkins> jelmer: Would you happen to know whether you need to build things with the same compiler used to build the SVN and APR libs... because it's become VERY unhappy now
<lazy1> I about to push my changes and would like to know which revision will get pushed
<jelmer> awilkins: I'm not sure
<LarstiQ> lazy1: I'd recommend `bzr missing` for that scenario
<awilkins> jelmer: From the output, SVN and APR I have were built with MSVC
<james_w> lazy1: hi, "bzr diff -r submit:" will show you a diff of your changes compared to the branch "bzr push" will push to
<james_w> bzr diff -r ancestor:.../wherever will do it for other branches
<james_w> "bzr send -o-" will show you something like the first.
<lazy1> thanks
<awilkins> jelmer: MSVC hates you because you used stdbool.h though :-)
<lazy1> james_w: is there a way to set the submit branch? (not with bzr pull --remember)
<jelmer> awilkins: heh, ok
 * awilkins pastes in a simple stdbool.h
<awilkins> Heh, MSVC also hates you for using those funky dot things (sorry, my C is virtually absent) on client.c:724
<lazy1> works like a charm, thanks
<beuno> mwhudson, downloading bundles from LH (trunk and LP) seems really broken. It outputs a binary file which is unmergeable: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/revision/argentina%40gmail.com-20080622180415-9ognqtaiptt58z7p?start_revid=argentina%40gmail.com-20080623155739-je1svgi6ikjyudfq&remember=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib&compare_revid=argentina%40gmail.com-20080623052141-lr31t9rjdbsuqfib
<beuno> am I doing something wrong this time too?
<mwhudson> i wouldn't be at all surprised
<mwhudson> it's a bit of a crazy feature really
<jelmer> awilkins, wow, that's quite an old C compiler
<awilkins> I'm using the VS2003 compiler because of all the warnings in the distutils files about having to use the same compiler that Python was built with
 * beuno files a bug
<mwhudson> beuno: here is somewhere where i really think "delete the feature" is a viable choice
<awilkins> jelmer: I had a terrible time finding a package for it, and poking all the magic values into the registry that the full Visual Studio install shoves in so msvccompiler.py can read them and set it up
<jelmer> awilkins: It's not very easy to work around that :-/
<beuno> mwhudson, fair enough. I'll clean it up after I finish going through the last bits for today for the new theme
<jelmer> awilkins: Specifying these member values in the right order is a pain
<awilkins> I suppose I can keep trying the mingw compiler
<awilkins> jelmer: Have a shufty at the mingw output
<awilkins> http://pastebin.ca/1054520
<beuno> jelmer, bzr.debian.org seems to hate people, so I'm going to send a tarball to the DD
<jelmer> beuno, ah, ok
<jelmer> beuno, there's also a tarball and all that up on my site
<beuno> doesn't work with nosmart either  :/
<jelmer> http://samba.org/~jelmer/debian/unstable
<beuno> (it does for me)
<beuno> jelmer, I don't see it on there, but I sent it off anyway, so no worries
<jelmer> awilkins, yikes
<jelmer> awilkins, yeah, that doesn't look like it's going to work
<jelmer> awilkins, you don't have a newer msvc?
<awilkins> jelmer: Yes, but is that going to link properly with Python?
<jelmer> awilkins: Not sure :-/
<awilkins> I have the latest windows SDK, which is MSVC 9
<awilkins> Python 2.5 was built on MSVC 7
 * awilkins has very few clues as far as C goes
<awilkins> I mostly stick to languages that link dynamically and don't whine about it.
<jelmer> I think it's worth a try to check with MSVC9
<awilkins> jelmer: I'm not convinced IU've got the libraries right ; they all have different names on Win32
<awilkins> But I got the object files to build
<jelmer> alternatively, you could avoid the dot notation, but that's quite a lot of work
<tethridge> anybody know the size of the mysql repository?
<awilkins> jelmer: MSVC 9 hates that syntax too
<jelmer> hmm, it's standard C99
<jelmer> awilkins, what's the error exactly?
<mwhudson> msvc will probably never support c99
<awilkins> I'll paste
<mwhudson> for fun and games echoing down the years
<awilkins> http://pastebin.ca/1054580
 * awilkins switches back to mingw
<awilkins> Hmm, are warnings like "defined locally after being referenced with dllimport linkage" relevant?
<beuno> hrm...
<beuno> anyone know what this could be:
<beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead.no_bundles$ bzr push lp:loggerhead
<beuno> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<beuno> bzr: ERROR: Pack '13c6ba3d1a8d731ec8f18bfb908585d6' already exists in <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x89eb72c>
<beuno> I've never seen that  :/
<beuno> hm, while autopacking...
<mwhudson> beuno: try again i think
<beuno> abentley, I see you worked on a bug related to that, is this what it fixed (I'm running bzr.dev, but maybe it's on the LP side): http://paste.ubuntu.com/22456/
<beuno> mwhudson, that worked, thanks
<igc> morning
<beuno> mornin' igc
<igc> hi beuno
<beuno> Jc2k, incidently, while working on the gnome theme for LH, I found you have an unclosed <li> in the header:    <li><a href="http://live.gnome.org/BzrForGnomeDevelopers"><span>Bazaar wiki page</span></a><li>
<lifeless> beuno: oh!
<lifeless> beuno: that bug is biting pqm for launchpad developers
<awilkins> jelmer: Look like libraries ; I don't the the auto-library-finding is quite so luxurious on Win32 ; you can look at the horrible pathes I've had to do afterward
<lifeless> mthaddon: ^^^^
<lifeless> beuno: could you make sure there is a bug exactly matching that, and grab all log details possible etc
<beuno> lifeless, sure. I see two of them, but it could be related to either
<beuno> bug #165293 and #212908
<ubottu> Launchpad bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed] https://launchpad.net/bugs/165293
<ubottu> Launchpad bug 212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Fix committed] https://launchpad.net/bugs/212908
<mwhudson> neither of those bugs mention autopacking
<lifeless> beuno: the thing is, push shouldn't trigger either under normal circumstances
<beuno> alright, new bug, here I come
<lifeless> beuno: either we're hitting md5 collisions in loggerhed (a possibility)
<lifeless> or, something is funky
<lifeless> mwhudson: can you grab a copy of the launchpad data for the branch beuno was pushing too
<lifeless> beuno: can you take a copy of your branch & repository that you pushed from, so we can reproducce
<mwhudson> lifeless: i think when beuno pushed again, it worked
<beuno> it did
<lifeless> mwhudson: we can rollback one push
<mwhudson> lifeless: ok
<lifeless> mwhudson: through the magic of robert
<jam> abentley: I have a question about bzrlib.merge.transform_tree
<lifeless> (but only if we have the obsolete packs etc). Its not guaranteed but should be doable
<mwhudson> beuno: which branch was it?
<jam> abently: If I do: merge.transform_tree(tree, tree.basis_tree(), [file_id]), shouldn't it revert that text to the value in the basis?
<beuno> mwhudson, a branch I did lh.dev -> lh.feature -> commit -> push to trunk
<mwhudson> beuno: can you not push over non-lefthand parents to trunk please?
<mwhudson> if that's what you did
<mwhudson> lifeless: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk, er, interesting
<lifeless> mwhudson: set allow_append_revisions_only=True (or whatever the setting is - 'bzr help configuration')
<beuno> mwhudson, you mean, merge in trunk and push?  Ah, yes, I can see how that's annoying, sorry
<lifeless> mwhudson: you'll want to uncommit the tip
<beuno> mwhudson, that's now what I just did though
<lifeless> mwhudson: or push --overwrite, to restore it
<mwhudson> beuno: can you clean it up?
<mwhudson> feel free to push --overwrite or whatever
<lifeless> mwhudson: did you get a copy of the repo already ?
<beuno> mwhudson, sure, I'll clean it up now and overwrite
<mwhudson> lifeless: so i have two tarballs of the branch, one from the push area, one mirror
<beuno> well, after you copy whatever you need to debug  :)
<mwhudson> lifeless: ye
<mwhudson> s
<mwhudson> lifeless: what did you want me to do with them?
<lifeless> mwhudson: thanks, drop them on devpad
<lifeless> beuno: can you mail me the copy of your repository & branch too
<beuno> mwhudson, sure, on it's way
<mwhudson> beuno: thanks
<beuno> er, lifeless
<lifeless> beuno: thanks
<beuno> just finishing filing the bug
<lifeless> I'm so tempted to repeat by mini-python-dbs-suck rant
<tolstoy> If I tag in a repo, push it to a server, then, from somewhere else, pull  from that server, how come I don't get the new tags?
 * mwhudson gets confused by network reachability in the data centre
<bob2> tolstoy: iirc push doesn't push tags unless it also has some other data to push
#bzr 2008-06-24
<tolstoy> bob2: I actually does push the tags, though.
<tolstoy> If I do a branch, they show up.
<tolstoy> Pull doesn't pull them, it seems.
<bob2> oh
<tolstoy> Yes, it's odd.
 * lifeless repeats it
<lifeless> you know what sucks
<tolstoy> If I do a tag, and the push, I get the "No revisions to push."
<lifeless> I can't find a good clean reusable B/B+ index for python
<tolstoy> But it still pushes the tags.
<lifeless> all the 'pure python' databases are either csv, the moral equivalent of csv, or dbm
<lifeless> NIH time
 * beuno goes clean up the revision mess
<bob2> tdb + ctypes!
<lifeless> beuno: tdb wants more file system semantics than we offer
<lifeless> s/beuno/bob2
<bob2> ah, remote, right
<lifeless> bob2: which is the problem with dbm too
<jml> what does one need to provide to have a fully functional TestCaseWithTransport subclass?
<lifeless> I went on a code search trying to find a python index module that was, well, modular.
<lifeless> no such freaking luck
<lifeless> jml: class foo(TestCaseWithTransport): def test_me(self): pass
<beuno> mwhudson, do you have a copy of loggerhead before I pushed 173?  I'm not sure how to get them back as left-hand history
<jml> lifeless: in particular, I would like to be able to use make_branch.
<tethridge> anybody know the size of the mysql repository?
<jelmer> re
<jml> When I do, I am told: AttributeError: 'TestFoo' object has no attribute '_TestCaseWithMemoryTransport__server'
<mwhudson> beuno: bzr pull -r some.dotted.revno . --overwrite probably?
<lifeless> jml: you have replaced setUp() and not called it
<jml> well spotted.
<lifeless> tethridge: 300MB I think. or maybe its 500MB.
<lifeless> jam: ^
<jelmer> awilkins, still there?
<awilkins> jelmer: Yes
<lifeless> back in 45 or so.
<jelmer> awilkins, any luck?
<awilkins> jelmer: I've reduced the size of that error log a lot, but still plenty of problems
<lifeless> Jc2k: did you file bugs? please say yes :P - and feel free to subscribe me to them
<tethridge> lifeless, nice
<awilkins> jelmer: Library discovery is really crippled on this build platform
<awilkins> http://pastebin.ca/1054527
<jam> lifeless: I'm not quite sure what you are pointing me to
<lifeless> jam: 'how big is a mysql branch'
<jam> 500+ MB for 6.0, 300 ish for 5.0
<lifeless> ok, time to put this pc in for repair.
<jam> tethridge: my copy is 591MB, with most of their branches
<tolstoy> Is there a discussion of permissions anywhere? Like when different processes and/or users are pushing to a central locations? Oy. I'm not sure wide open umasks are the solution.
<jelmer> awilkins: ouch
<jam> bug #240262
<ubottu> Launchpad bug 240262 in bzr "No repository present error when using bzr+http protocol talking from bzr 1.5 client to a 1.3.1 repository" [High,Confirmed] https://launchpad.net/bugs/240262
<awilkins> jelmer: I remember having more success with those Pyrex bindings using MSVC ; how hard is it to ditch the dots?
<awilkins> jelmer: Previously managed to get as far as having built .pyd files (even if they didn't actually work)
<jelmer> awilkins: basically, it's changing all structs that use the dotted notation to explicitly set all member variables, and in the right order
<awilkins> I'd guess that's quite a few
<jelmer> yeah, indeed
<jam> tolstoy: you may want to look at contrib/bzr_access, which would be a good place to work out multiple user keys for a shared repo, and proper umask, etc.
<tolstoy> jam: Okay, thanks.
<beuno> hrm, LP hates me today:
<beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead.fix_dirs$ bzr pull lp:~beuno/loggerhead/bug-240512
<beuno> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<beuno> bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 502 Bad Gateway
<mwhudson> :(
<mwhudson> try again again
<mwhudson> i think
<beuno> yeah, already did, but it's *extremely* slow
<beuno> it's stuck at: 0.198  opening working tree '/home/beuno/bzr_devel/loggerhead.fix_dirs'
 * beuno tries again with Dhpss
<awilkins> jelmer: Those traces are full of MSVC symbols.....
<awilkins> Or rather, the lack of them
<jelmer> awilkins: probably a different ABI or something
<jelmer> some sort of compiler mismatch at least
<awilkins> PLus things like _chkstk which is apparently shoved in when big stack frames are in there etc.
<awilkins> Darn
<jelmer> ok, so fixing the dotted structure notation is the only solution?
<awilkins> I hate to say it, but probably
<awilkins> THe other solution would be building Neon, SVN and all the other stuff on MinGW and I can't find much help for that
<awilkins> There's a reason I'm using the pre-archive developers pack of SVN libraries and headers
<beuno> LP is autopacking LH again
 * beuno crosses his fingers
<awilkins> jelmer: Right, it's 0033 here, I'm going to bed.... if there is any simple drudge work I can do to help, let me know.
<jelmer> awilkins, will do
<awilkins> jelmer: But bear in mind my C is rather rusty.
<jelmer> awilkins, g'night
<awilkins> Goodnight
<RichW> Is this error serious? or can i ignore it? ï»¿This transport does not update the working tree of: sftp://...../trunk/. See 'bzr help working-trees' for more information.
<beuno> RichW, that means the the actual files aren't been updated, so it depends on what you're using it for
<beuno> is that in launchpad?
<mwhudson> beuno: so loggerhead/trunk looks better again thanks
<beuno> mwhudson, yeah, sorry about that. I was used to the bzr workflow, where PQM is always left-hand. I'll be more careful from now on
<mwhudson> no worries
<beuno> autopack worked fine now  (took almost 20 minutes though(
<mwhudson> autopack still mostly happens client side i think
<mwhudson> there's a patch floating around to fix that
<beuno> yeah, but it doesn't take 20 minutes to push the full branch, so I suppose it should take at most that long, right?
<beuno> anyway, it's done now, so no use in complaining  :)
<mwhudson> i can imagine there being a silly amount of roundtrips
<mwhudson> beuno: for bug 242466, how does this look? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png
<ubottu> Launchpad bug 242466 in loggerhead "Log view should show sub-revisions" [Medium,Confirmed] https://launchpad.net/bugs/242466
<mwhudson> (this is something i did ages ago in a branch which has gone to the big hard disk crash in the sky, but i think i know how to do it again)
<beuno> mwhudson, that looks pretty good. I remember now you emailed that a while back to the list.  I had in mind maybe trying to show them like collapsed revisions, and being able to expand them too
<beuno> ok, trunk should be back to before the left-hand-side-plus-collapsing-packs mess
<mwhudson> beuno: you mean, making less distinction between the mainline and off-mainline revisions?
<mwhudson> that probably makes sense
<beuno> mwhudson, yes. I feel it makes merged revisions seem like something different, when they're not. Users already get confused with DVCS in that sense, and that may not help
<beuno> I'll try to get a mockup for that once we're through with the new theme, if you'd like
<mwhudson> beuno: swings and roundabouts, i think having _some_ emphasis on the mainline revs is ok
<mwhudson> (this is one of the things i find incomprehensible about bzr-webserve)
<beuno> mwhudson, alright, two mockups  :p
<mwhudson> beuno: heh
<mwhudson> let's get the new theme done
<mwhudson> first
<beuno> mwhudson, I had something in mind similar to "This revision is composed of N revisions. Show revisions"
<beuno> and expand on-screen
<beuno> if that's possible without making the UI a mess
<fullermd> Well, the big problem is that having high emphasis on the mainline revs is perfect in some workflows, but with others having ANY emphasis is bunk.
<beuno> lifeless, FWIW, second time Loggerhead auto-packed, after going back a few revisions, it worked out fine
<mlh> Peng: true (re server generated index html).  I hadn't even tried it.  (smacks forehead)
<mwhudson> fullermd: but it makes sense in a workflow that involves pqm, which is the right workflow, so qed
 * mwhudson runs away and has lunch
<fullermd> pqwhat?   :p
<mlh> and ... IT WORKS!@
<mlh> now to get around the ~ since my work blocks access to 'personal pages' ie those with a tilde :-(
<mwhudson> beuno: btw, are you running the tests before committing to trunk?
<mwhudson> beuno: the tests suck, but they do occasionally catch problems
<mlh> don't s'pose bzr does ntlm proxy auth?  :-)
<beuno> mwhudson, uhm, 50% of the time, tbh. I'll bump that up to always  :)
<fullermd> Well, if the tests cover 50% of the code, and you run them 50% of the time, the two add up to 100% coverage!
<mlh> if it used curl, it could
<beuno> I do go through all pages in UI, before pushing, which may catch more than tests. But I will do both until we have better tests
<beuno> mwhudson, just checked though, haven't broken any tests  (which just goes to show how little we're testing  :P)
 * beuno goes back to gnome-theming while mwhudson eats his well-deserved lunch
<tolstoy> Hm. On solaris, the xmloutput plugin says that encoding is "646". I've never heard of 646 as an encoding.
<fullermd> Unicode is ISO-10646
<fullermd> Well, UCS technically.  But who can keep track of all the acronyms and subacronem?
<tolstoy> It's odd. I'm trying to integrate this with bamboo (oy) and its jdom parser rejects the xml output because encoding="646".
<tolstoy> Interesting. On this version of python (that I compiled myself), on Solaris (hail mary), sys.getfilesystemencoding() returns '646'.
<mlh> weird
<tolstoy> Just as a user, rather than an ops staff, or whatever, Solaris leavs much to be desired.
<mlh> yep, checked
<mlh> I've got two pythons installed on solaris, site compiled, and one installed from blastwave
<mlh> both have '646'
<tolstoy> It's good to know I didn't mess up the compile.
<fullermd> I would guess that means UTF-8.  But it could be UCS-2 or some such insanity.
<mlh> solaris has got a lot to be desired frmo an ops view too
<mlh> first thing I do is install a swag of freeware
<tolstoy> I guess I'll have to "fix" the xmloutput plugin.
<fullermd> s/ frmo.*//
<mlh> well, 2nd thing, after jass.  (here's ends the OT)
<tolstoy> mlh: I'd just erase the whole OS and install something else, but then I don't have root, and people get tired of such suggestions. ;)
<mlh> :-)
<fullermd> Luckily, these days, there's vmware and such   ;>
<tolstoy> We compile java apps, and people are afraid that if we compile on linux and deploy on solaris, Bad Things Will Happen.
<mlh> we have smiilar superstitions here
<mlh> even though, people have compiled on windows and deployed on solaris and it's just worked dandily
<beuno> Jc2k, ping
<beuno> Jc2k, lifeless, I've got some integration for the gnome theme: http://intranet.pentacorp.net:8080/changes
<beuno> it could probably be nicer for the LH menu navigation/search bar, but not sure how to cram everything together
<mlh> is there a proggy to generate index.html that DOES include .bzr?
<mlh> it'd be pretty simple to make one I guess; just checking if there's an option or plugin
<mlh> bzr ls --html  mebbe
<mlh> tiny bug in bzr help status:
<mlh> s/bzr -SV/bze status -SV/
<beuno> mlh, I see:
<beuno>   to Subversion's status command. To get output similar to svn -q,
<beuno>   use bzr -SV.
<mlh> yeah
<beuno> which seems correct. What version of bzr are you using?
<spiv> beuno: right, there's a command name missing
<mlh> 1.5 on fedora9
<beuno> aah  :)
<beuno> mlh, you can either file a bug and/or send a patch
<beuno> thanks spiv
<mlh> er too small for a bug
<mlh> one of you can just sneak it in with other fixes :-)
<beuno> Jc2k, lifeless, I'm off in a few minutes to have dinner, but, screenshot up in: http://beuno.com.ar/random/gnome_themed.png  and pushed it to: lp:~beuno/loggerhead/gnome_theme
<lifeless> beuno: cool
<lifeless> beuno: does it have bzr-search ? :P
<poolie_> hello beuno etc
<gambler> are there any java or csharp lang bindings to bzr?
<AfC> gambler: look at the bzr-eclipse plugin; the work done there is relevant.
<gambler> AfC, is it stable?
 * igc lunch
<lifeless> gambler: do you mean 'is it done' or 'does it work well'
<gambler> does it work well
<lifeless> gambler: I don't use eclipse; but various folk that do tell me it works nicely
<mlh> not completely tangentally, jython 2.5 alpha is out
<gambler> meh another time sink. ill investigate it then
<lifeless> gambler: 'Verterok' who hangs out here is one of the primary developers
<lifeless> he's in argentina though, his nighttime now
<mwhudson> i installed eclipse yesterday!
<mwhudson> then it confused me
<lifeless> gambler: also, SoC last yerar, someone wrote some c# bindings
<lifeless> dunno how good they are
<gambler> linky?
<lifeless> Jc2k: ironic that you are having to hack on git :)
<Odd_Blok1> poolie: At some point this week, I'd like to talk about the PQM work I'm going to be doing this summer, so I can start next Monday with clear targets and rewards.
<poolie> Odd_Bloke: that'd be good, could you start by putting down your thoughts on the list about what to do, so others can get involved
<poolie> also the dates you'll be working on it
<Odd_Bloke> poolie: I'll do that tomorrow.
<xz> would someone like to help me figure out how to organize a project? I'm having trouble with the bazaar concepts
<poolie> xz, sure
<lifeless> gambler: sorry, was away from keyboard
<lifeless> Verterok: btw - gambler is asking about accessing bzr from java
<Verterok> lifeless: thanks for pointing it :)
<lifeless> gambler: I'm not sure about where the c-sharp bindings are
 * Verterok looking the backlog
<lifeless> I don't even remember the students name sorry :(
<xz> poolie: my project is a single directory with a number of subdirectories. I want people to be able to work on the subdirectories independently, and then the parent can use various versions of them
<Verterok> gambler: to access bazaar from java, there is a library I'm working on (and using it bzr-eclipse), https://launchpad.net/bzr-java-lib
<xz> poolie but it should also be possible to move a file from one subdirectory to another, and that is a change to the parent
<Verterok> s/it/in/
<poolie> xz, this is the subtrees feature
<poolie> well, hm
<poolie> there is a feature called subtrees which lets you commit independently in all the subdirectories and link them into the parent
<Verterok> gambler: the current trunk of bzr-java-lib, is based on a CLI wrapper, so it's performance isn't quite good
<poolie> it is a bit rough atm
<xz> poolie I guess a single versioned branch (the parent) is a possibility, and to work on a subdirectory, you branch the whole thing, work on the inside, then merge back - is that the way to do it?
<Verterok> gambler: I'm working in a branch that uses a xmlrpc backend,  provides far better perfomance and mantain API compatibility with the CLI based one.
<poolie> xz, yes, and that's probably simpler for many uses
<poolie> igc, still around?
<igc> poolie: yep
<poolie> igc, i guess we should just consider it settled that there will be a file in the tree for preferences
<poolie> i still think that's the best option but your quoted message from john makes me want to get more certainty that it is so
<igc> poolie: I did :-)
<poolie> did consider it settled?
<igc> the issue now IMO is format marker syntax and optional vs required
<poolie> right
<poolie> i'm replying on that
<igc> thanks
<lifeless> I should reply still :( but don't block on me
<beuno> hey poolie
<beuno> lifeless, search isn't my choice, but if Jc2k wants it, I'd b happy to help him out with that too
<lifeless> beuno: I believe he is running search already :P
<lifeless> beuno: also, what time is it for you ?!
<beuno> lifeless, ~1:30amish
<beuno> early  :p
<beuno> I've been going to when mwhudson_ stops working, which is usually ~3am here
<beuno> so, if he's running search I should probably make it auto-index...  :/
<mwhudson_> beuno: maniac
<beuno> mwhudson_, hehehe, well, it's the only way to do *both* things (my current work and bzr/LH)
<lifeless> beuno: but it already auto indexes
<lifeless> beuno: so I really don't understand why you want to do that at all :P
<beuno> lifeless, well, it autoindexes once it has indexed  :)
<lifeless> beuno: right
<beuno> so, I'd like to provide an egg for the chicken
<beuno> shouldn't be too hard
<beuno> just juggling quite a few things at a time
<lifeless> beuno: which means lh doesn't need a config item saying to index or not - it can just detect if there is an index, and only show Search when there is
<lifeless> beuno: I'm not sure I agree, because it will add the need for a knob for people that don't want a search index
<beuno> lifeless, right, I suppose that can be the default behaviour (which is what it currently does), but it would be nice to be able to tell it to index everything
<beuno> it'll probably be 50/50 of people wanting and not wanting
<beuno> it's a very cool feature  :)
<lifeless> beuno: wouldn't it be better to have bzr-search have an option which when set causes 'bzr branch' to create an index too ?
<lifeless> (and init etc)
<beuno> lifeless, that would be nice, yes. And it has the bonus that it falls on your court, and not mine!
<lifeless> beuno: you've got patches in bzr-search too :P
<beuno> heh, true.
<lifeless> bug filed
<poolie> igc, ok, reply sent
<poolie> that increased my conviction that adding one will not really help anything
<poolie> to me it seems like an overgeneralization from what we had before
<poolie> s/what we had before/from bzrignore and internal database versioning
<igc> thanks for the detailed reply poolie. I hadn't considered the idea of introducing a new file as the way to bump the format. Interesting.
<jml> loom question.
<jml> two commits went to the wrong thread. between now and then I've made 5 other commits.
<jml> what can I do about this?
<jml> cherrypick out those two wrong commits?
<lifeless> jml: so thread A should have got commits 1 and 2
<lifeless> and thread B got them instead
<lifeless> jml: where did commits 34567 go ?
<jml> thread A
<lifeless> whats thread B's position relative to thread A?
<jml> immediately above.
<lifeless> ok
<lifeless> because B has content A doesn't, you can't just merge them in, you'd get B as well
<lifeless> so yes - cherry pick merge them down to A
<jml> sorry. I misread something you said.
<jml> let me answer your questions again.
<jml> jml: where did commits 34567 go ?
<jml> thread B
<jml> whats thread B's position relative to thread A?
<jml> thread A
<jml> err, thread B is immediately below thread A
<lifeless> so
<lifeless> switch to B
<lifeless> bzr up-thread
<lifeless> that will merge them to A, commit.
<lifeless> then, switch to B
<lifeless> and bzr cherrypick 1 and 2 out of B
<lifeless> (e.g. by bzr merge -r -5..-7 .)
<lifeless> commit
<lifeless> bzr up-thread
<lifeless> (which will back the commits out)
<lifeless> and bzr revert .
<lifeless> which will put them back and keep the merge record
<lifeless> then bzr st (should show a pending merge)
<lifeless> bzr commit
<jml> thanks
<Jc2k> hellow all
<beuno> mornin' Jc2k
<beuno> Jc2k, http://200.127.6.219:8080/changes
<Jc2k> now that is quite pretty :D
<Jc2k> beuno: can you make the plain pages that serve-branches serves equally shiny?
<beuno> Jc2k, ah, yes. That would involve templating those bits, which will close a bug. I'll bump that up on my priorities
<beuno> Jc2k, you can get the branch from: lp:~beuno/loggerhead/gnome_theme
<beuno> we can play around with the tabs to make LH's navigation seem more integrated, but I didn't want to change anything substantial
<gour> have you read http://adam.gomaa.us/blog/thoughts-on-dvcss/ (reddit) ?
<eMBee> good afternoon
<eMBee> is there a nice tool to display branches as a graph?
<gour> eMBee: bzr vis
<beuno> gour, it's an interesting read, although he seems to know nothing about bzr, and a lot about git/hg
<beuno> eMBee, that would be part of bzr-gtk plugin
<gour> beuno: heh, i really like such kind of posts :-/
<eMBee> ah, thanks
<beuno> alright, that's it for me today
<beuno> g'night everyone
<beuno> Jc2k, I've got theming the remaining bits of LH on my list, make sure to poke me if you need something else  :)
<eMBee> bzr vis does not seem to exist, and bzr-gis only in lenny, not in etch or backports :-(
<beuno> eMBee, bzr-gtk is the package, not sure if it's in etch ot backports, but you can install it with:   bzr co lp:bzr-gtk ~/.bazaar/plugins/gtk
<beuno> of course, you have to have gtk installed  :)
<eMBee> so it just uses pygtk or something?
<beuno> yes
<eMBee> ok, then that's good enough for testing
<eMBee> normally i prefer to have the packages installed
<eMBee> eeeks, need a launchpad login for that
<beuno> eMBee, actually, check out the manual installation: http://bazaar-vcs.org/bzr-gtk
<beuno> eMBee, you shouldn't need a LP login, no
<beuno> anyway, I'm really off to be now  :)
<gour> jelmer: there will be new bzr-svn release soon?
<eMBee> bzr branch http://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk ~/.bazaar/plugins/gtk; seems to work
<gour> good
<eMBee> i guess lp references my local setup and assumes launchpad access
<eMBee> where does bzr vis come from? is that part of the gtk plugin?
<gour> eMBee: part of gtk plugin, it's alias for visualize
<eMBee> thanks
<gour> does it work?
 * gour likes bzr vis although comfortable with cli 
 * ToyKeeper ponders working on some vis improvements
 * eMBee is still loading the source
<eMBee> i like the cli. but i do like to visualize the branch graph
<eMBee> it really helps me to see where i am and if the operation i do has the desired outcome
<ToyKeeper> I like browsing changes and diffs in the GUI, and sometimes committing changes in the GUI, but everything else seems easier on the command line.
<gour> right. it's very helpful
<gour> (sometimes)
 * gour comes from non-gui world of darcs
<eMBee> heh, with darcs i was always confused about the state of my branch
<ToyKeeper> I liked the patch-based concept of darcs, but never really did much with it.
<lifeless> Jc2k: are you running bzr-search version of loggerhead?
<lifeless> Jc2k: beuno needs to know, to know to memrge it in or not :)
<gour> i used it almost exclusively for several years, but had issues with it as well
<eMBee> hmm: bzr: ERROR: exceptions.ValueError: need more than 1 value to unpack
<lifeless> eMBee: from bzr viz?
<lifeless> eMBee: I blieve that was a specific version issue
<eMBee> yes
<gour> eMBee: it must be something wrong with your repo :-)
<eMBee> i just checked out trunk
<lifeless> eMBee: and what bzr are you runnin?
<gour> i mean, the repo you want to 'vis'
<eMBee> bzr is 1.5 from debian etch backports
<lifeless> I suspect trunk of bzr-gtk needs trunk of bzr
<eMBee> hmm, can i check out a version of gtk that works with the released 1.5?
<AfC> eMBee: you mean the bzr-gtk plugin?
<eMBee> yes
<spiv> eMBee: you could try -rtag:bzr-gtk-0.94.0, it might work with 1.5
<AfC> eMBee: or the GTK+ library?
<ToyKeeper> eMBee: You could just update your branch to a released revision.
<gour> eMBee: you need trunk of bzr, if i understand
<spiv> (that's just a guess though, I'm not sure if that release works with 1.5)
<eMBee> but i don't want to get the trunk of bzr, i prefer to stick to the debian package
<AfC> Huh. I have bzr-gtk 0.93.0 here plugged into my bzr 1.5; I guess it's time for me to poke at that.
<AfC> eMBee: why would you want to do that?
<eMBee> why would i want what?
<AfC> stick with out of date Debian packages of a project which is iterating quickly?
<lifeless> eMBee: if you are using the debian packaged bzr, you should also use the debian packaged bzr-gtk :)
<eMBee> because i can not recommend others to use bzr if they are expected to get the latest revision. it just means that bzr is not yet stable for use
<eMBee> lifeless: that is true, unfortunately, there is no bzr-gtk backport for etch available yet
<lifeless> eMBee: have you requested one?
<eMBee> only lenny, which is equally not something i can recommend
<ToyKeeper> bzr pull -rtag:bzr-gtk-0.94.0 lp:bzr-gtk ~/.bazaar/plugins/gtk  ?
<ToyKeeper> You do have python-gtk2 installed, yes?
<ToyKeeper> bzr-gtk requires python-central, python-glade2, python-gtk2
<lifeless> eMBee: have you requested a backport?
<gour> i run bzr-gtk-0.94 with bzr-1.6b3 - no problems
<eMBee> lifeless: i just discovered that it wasn't backported, and i am not aware of any place where i could request a backport
<gour> but used it with pre1.5 as well
<gour> eMBee: do you have seahorse installed?
<eMBee> what's seahorse? (i guess no)
<gour> there was (is) issue that bzr-gtk requires it
<gour> try to install it
<gour> for managing gpg keys
<eMBee> installing seahorse does not make the error go away
<lifeless> eMBee: I believe you file a bug on debian.org to ask for a backport
<eMBee> lifeless: i'll look into that, thanks
<lifeless> eMBee: http://lists.backports.org/lurker-bpo/list/backports-users.html is the users list
<lifeless> eMBee: I would start there
<eMBee> heh, thanks
<eMBee> the backport is not a priority, since i need to get this working now. in the worst case i can make my own backport later, but that's to much effort now
<gour> eMBee: can you paste error?
<ToyKeeper> Is it expected that bzr trunk branching from LP complains about the server not supporting network protocol 3?
<lifeless> ToyKeeper: yes; protocol 3 is new and lp hasn't been upgraded to support it yet
<eMBee> yes, hold on
<ToyKeeper> lifeless: Okay, that's what I figured.  Just wanted to check.
<lifeless> bbiab
<igc> poolie: ok, you've convinced me I think. I've replied with another idea for your consideration
<eMBee> http://pastebin.ca/1054962
<gour> eMBee: have you seen https://bugs.launchpad.net/bzr-gtk/+bug/237205
<ubottu> Launchpad bug 237205 in bzr-gtk "error starting webbrowser.GenericBrowser in python2.4" [Medium,In progress]
<eMBee> not yet, looking now
<eMBee> so i run into this problem because of python 2.4 in etch, ok
<gour> right, python-2.5.2 here
<eMBee> bzr vis uses a webbrowser?
<ToyKeeper> Ah, I had that exact problem on edgy.
<eMBee> so i just get that branch that contains the fix?
<gour> i'd say so
<eMBee> can i update the existing branch somehow?
<ToyKeeper> bzr's gui does seem a little heavy on dependencies.  I'd rather it not talk to my browser, ever.  :)
 * eMBee is not yet familiar with bzr
<gour> there are conflicts maybe
<gour> eMBee: try merging, although i'd rm old branch and pull new one
<eMBee> i don't want to merge, but just get the different revisions
<ToyKeeper> eMBee: You could "bzr pull lp:~iacobs/bzr-gtk/browser-detection" (instead of using trunk) or "bzr merge lp:~iacobs/bzr-gtk/browser-detection" (into trunk) to get the fix.
<eMBee> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<eMBee> ok, i expect that,
<gour> heh
<eMBee> but why is it an error?
<jml> is there an easy way to see a log of all commits made on a thread since it was created?
<gour> eMBee: by design
<ToyKeeper> eMBee: You can't pull one branch on top of another.  It has to be merged instead.  (I'm guessing you did a 'bzr branch' or 'bzr pull' inside the trunk dir, but 'bzr merge' is correct)
<gour> eMBee: this is not darcs ;)
<eMBee> but i don't want to merge, i want to switch and get the new branch just as it is
<eMBee> but i don't want to waste bandwith and get the whole branch from scratch either
<ToyKeeper> This is, admittedly, confusing.  In hg, the command is 'hg pull -u', but in bzr it'd be 'bzr merge --pull'.  It sounds like darcs also uses 'pull' to merge things.
<eMBee> the divergion (is that aa word?) should be small
<jml> eMBee: what do you know about shared repositories?
<eMBee> nothing in terms of bzr
<eMBee> did i just create a shared repo?
<jml> eMBee: they are a way for bzr branches to share data. they can help a lot with not wasting bandwidth
<eMBee> right, that's what i want
<jml> eMBee: you create one by doing 'bzr init-repo path/to/repo'
<jml> eMBee: then you fetch branches inside that repo
<jml> eMBee: you can 'prime' one for bzr-gtk by doing something like this:
<jml> bzr init-repo bzr-gtk
<jml> cd bzr-gtk
<jml> bzr branch ../../path/to/existing/bzr/gtk/branch-name
<jml> and then you can fetch the branch ToyKeeper mentioned.
 * jml hasn't been following the conversation in detail.
<jml> lifeless: did you see my loom question?
<spiv> eMBee: if you have a checkout, you can just do "bzr switch" to point it to a different location.  If you have a branch that you want to overwrite with another branch, you can use "bzr pull --overwrite".
<thekorn> hi, I've got one   bzr pull   related question:
<thekorn> is bzr pull lp:~<location> suppose to work?
<spiv> eMBee: but if you want merge changes from one branch into another, then "bzr merge" is the command to use :)
<spiv> thekorn: yes
<thekorn> spiv, hmm,ok for me it returns:
<thekorn> $ bzr pull lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge
<thekorn> bzr: ERROR: Not a branch: "/media/disk-1/python-launchpad-bugs/intrepid.merge/lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge/".
<jml> thekorn: what version of bzr are you using?
<thekorn> jml, 1.3.1
<jml> how odd.
<jml> wait
<jml> thekorn: what does 'bzr st' show you?
<thekorn> jml, http://paste.ubuntu.com/22535/
<jml> thekorn: sorry, I meant 'bzr info'. my bad.
<thekorn> jml, np, http://paste.ubuntu.com/22537/
<jml> thekorn: ok, that definitely weirds me out.
<spiv> thekorn: that's bug #181945
<ubottu> Launchpad bug 181945 in bzr "bzr pull lp:upstart fails" [Critical,Fix released] https://launchpad.net/bugs/181945
<spiv> thekorn: it's fixed in 1.4 and later
 * jml unweirded.
<jml> I'll see you all later.
<thekorn> ok, thanks spiv and jml, do you know if there will be a backport of bzr > 1.3.1 for hardy
<spiv> thekorn: there's a PPA: https://launchpad.net/~bzr/+archive
<thekorn> spiv, ok, thanks
<gour> eMBee: have you managed to get 'vis' working?
<thekorn> is there a tool/script available in bzr which expands adresses like  lp:~<location> for me, so I can see where this location is redirected with my configuration?
<james_w> only in bzrlib I think
<james_w> I think it is in bzrlib/plugins/launchpad/directory_service.py
<thekorn> hi james_w, thanks, looking
<spiv> thekorn: yes, bzr >= 1.4 ;)
<spiv> thekorn: bzr info lp:FOO is a bit slow, but will tell you I think
<spiv> thekorn: if you don't mind writing python code, james_w has pointed you in the right direction
<james_w> hi spiv
<spiv> Good evening.
<thekorn> spiv, bzr info works thanks
<jelmer> gour, hi
<jelmer> gour, yeah, around the same time as bzr 1.6
<spiv> jelmer: I still can't pull python trunk with the current 0.4 branch btw
<spiv> jelmer: Twisted trunk works fine now, though.
<jelmer> spiv: whu, ok - what error?
<spiv> jelmer: http://rafb.net/p/A02Y3L67.html
<spiv> jelmer: I took a quick peek but no obvious error jumped out at me
<spiv> jelmer: I tried blowing away the relevant svn-cache, but that didn't help
<spiv> (It was pleasingly fast to regenerate though!)
<gour> jelmer: thanks
<jelmer> spiv: does it work better if you make _is_http_transport() return False and throw away the cache?
 * spiv tries
<jelmer> lifeless: Stacking is going to require a new repo format, isn't it?
<jelmer> lifeless, or just a new branch fmt?
<eMBee> how can i see which branches i have in my repo?
<spiv> jelmer: it is still running, but it seems to be doing better
<spiv> jelmer: i.e. it's doing lots of added revision_id {...} rather than breaking :)
<spiv> It's taking ~4s per revision.  I guess that's what happens when you convert via intercontinental internet.
<spiv> jelmer: thanks
<jelmer> spiv: Heh, probably
<spiv> jelmer: oh, and memory consumption is a little high (155MB resident)
<spiv> High, but apparently stable.
<spiv> (Or at least, growing quite slowly)
<jelmer> spiv: yeah, I'm working on freeing more of it
 * spiv nods
<spiv> It's much much better than it used to be :)
<spiv> jelmer: great work
<jelmer> spiv: Thanks :-)
<eMBee> gour: vis is not working yet, need to figure out how to switch the branch. i did bzr branch bzr-gtk/trunk, and then inside that bzr pull branch-with-fix; not sure if that was a good idea. can i change a plain branch into a repo?
<ToyKeeper> jelmer: Sorry for the redundant bzr-svn bug.  I didn't realize it was already fixed, and don't know where to find unreleased packaging for it.
<jelmer> ToyKeeper, no worries
<jelmer> ToyKeeper, branches for most bzr packages are up at http://bzr.debian.org/pkg-bazaar
<ToyKeeper> eMBee: Perhaps the simplest approach is to "mv ~/.bazaar/plugins/gtk /tmp" then "bzr pull lp:~iacobs/bzr-gtk/browser-detection ~/.bazaar/plugins/gtk".
<ToyKeeper> eMBee: That will just replace your trunk branch with the fixed branch.  It might be missing some updates from trunk, but it'll probably at least work.
<ToyKeeper> Er, s/pull/branch/ :)
<eMBee> ToyKeeper: but then i am regetting 95% of the commits which i already have in trunk, that's what i want to avoid. network is slow here
<ToyKeeper> Ah.
<ToyKeeper> In that case, you should be able to merge the fixed branch into trunk.
<eMBee> merge seems to complex, can't i just somehow get the missing commits and then switch to the branch?
<eMBee> figuring out how to do this is also a way for me to learn about bzr
<ToyKeeper> That basically is what merge does.  It grabs the missing changes and applies them.
<eMBee> how about i create a new repo and then pull both branches (the one i already downloaded and the new one into that?
<eMBee> but i don'
<eMBee> ooops
<eMBee> i don't want the changes to be applied to the working tree
<eMBee> that would mean i'd have to resolve conflicts etc
<ToyKeeper> I just tried it, and it works.  There were no conflicts.
<eMBee> that's not the point. there could be conflicts if i do this in another situation
<eMBee> i want to get at the pristine state of the branch without redownloading all of it
<ToyKeeper> Ah, so you want to grab the other branch, create a local copy with two heads, and then switch to the other head?
<eMBee> exactly
<eMBee> sorry, i am not so sure about the right terms to be used here
<eMBee> the local copy with two heads is a shared repo, right?
<ToyKeeper> I'm not sure bzr allows multiple heads like that, but I'm fairly new to bzr myself.
<eMBee> well, there is a concept of shared repos, but i can't figure out how to change a simple in-branch repo to a shared one
<ToyKeeper> I could tell you how to do it in hg, but that doesn't help.  :)
<eMBee> ToyKeeper: heh, my git experience does not help me either, here
<james_w> eMBee: if you just want the other branch then "pull --overwrite" will get you there.
<james_w> obviously be careful if you have local commits or uncommitted changes
<james_w> "bzr reconfigure" may be able to turn a branch in to a shared repo, I can't remember
<ToyKeeper> I've been wondering about multiple heads in bzr for a while now...
<eMBee> james_w: ah, ok, i did a pull (but not with overwrite) does the pull add a second head or does it replace the head?
<ToyKeeper> I haven't seen a way to do it in a single dir, but I haven't looked very hard.
<james_w> eMBee: replaces it
<james_w> "bzr pull" is "make this branch exactly the same as that one over there". If they have diverged then you need --overwrite to force it to prevent you from hiding your work.
<eMBee> ok, but the other commits are still there? so if i pull again from trunk it should not need to get much over the network?
<eMBee> ahh, now i understand why i got an error
<james_w> yep, but if you were to "branch" or "push" that branch somewhere else those extra trunk commits would not be taken as well.
<eMBee> yes, of course, it should only get/push what's related to the branch
<eMBee> ok, i am slowly starting to understand what's happening. makes me feel more confident now, thank you
<eMBee> ok, i did the overwrite thing, now i get bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link_button_set_uri_hook' when running bzr viz
<james_w> sounds like a bug in that branch of bzr-gtk
 * gour <--- lunch
<gour> eMBee: strange you have those bzr-gtk problems :-(
<ToyKeeper> Sounds like the version of python-gtk may not be new enough.
<eMBee> maybe a amd64 issue?
<eMBee> or it is not even installed in the first place
<ToyKeeper> New in PyGTK 2.10, the docs say.  What version (if any) do you have?
<ToyKeeper> http://www.moeraki.com/pygtktutorial/pygtk2reference/class-gtklinkbutton.html
<eMBee> 2.8.6
<eMBee> then you are right and i am out of luck, because i can't install the newer one from lenny
<ToyKeeper> Gah, google gave me the right content, on the wrong domain.
<ToyKeeper> Can you add a newer debian feed via apt-pinning, and use it only for a few packages?
<gour> eMBee: i'm on amd64 as well
<gour> pygttk-2.12.1
<eMBee> gour: running etch?
<jelmer> I guess we could optionally disable that code if it's not available
<eMBee> that would be cool, at least as long as people stull use etch
<eMBee> still
 * eMBee needs to go. thanks for all the help so far
<ToyKeeper> eMBee: to do pinning, put newer feeds in sources.list, add some stuff in apt/preferences, and then you can grab newer packages when necessary.
<gour> eMBee: no, i'm on archlinux
<ToyKeeper> eMBee: sources.list ( http://rafb.net/p/T9LNRV23.html ), preferences ( http://rafb.net/p/R0MX1K64.html )
<ToyKeeper> eMBee: then, "apt-get -t testing install bzr-gtk" should work.
<ToyKeeper> It's a lot easier than trying to make a backport.  :)
<ToyKeeper> (assuming the new packages don't have drastic dependencies, like a newer libc)
<lifeless> jelmer: new repo format
<jelmer> lifeless: Any chance rich-root-pack can be lumped in with that?
<lifeless> jelmer: no; stacking on existing repos would be impossible
<lifeless> jelmer: this is orthogonal to the 'what is default' discussion. I'd like to see rich root become default
<jelmer> it just seems to multiply the number of formats we need
<jelmer> since we'd also end up with rich-root-stacking / subtree-stacking / etc
<AfC> oh, yeay
<lifeless> jelmer: like we have for knits as well
<jelmer> the number of formats in bzr seems to be a major point people are criticizing us on
<lifeless> jelmer: its not /desirable/ but its seems the lesser evil than saying 'you cannot stack unless project X goes through a one-way watershed change for you first'
<jelmer> lifeless, hmm, that's a good point
<jelmer> lifeless: Maybe having both rrp as default and stacking in the next version would help
<lifeless> that would be ideal
<jelmer> lifeless: So small projects and the like can skip one upgrade
<gour> in any case, stabilizing of repo-format is desirable
<lifeless> gour: that will happen naturally when we have less improvements to make
<jelmer> hmm, sqlite3 is now the main memory leaker in bzr-svn
<jelmer> 1476 ==5449== 25,854,223 bytes in 171,239 blocks are possibly lost in loss record 98 of 99
<jelmer> 1477 ==5449==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
<jelmer> 1478 ==5449==    by 0x577255D: sqlite3_malloc (in /usr/lib/libsqlite3.so.0.8.6)
<gour> lifeless: sure...however plethora of formats is confusing, at least
<lifeless> gour: stabilising for stabilisations goal is like ABI freezing so that you can say you have frozen
<lifeless> gour: its like 'best practice' - a death knell for continual improvements
<gour> lifeless: nothing against improvement...but then getting rid of old formats
<lifeless> gour: right, so we can hide formats that are old, and remove support for very old ones
<gour> backward compat. is pita
<jelmer> gour: pita for developers mainly - it's generally good for users
<lifeless> we can also use development formats as a way to batch up a number of changes that are not ready for general adoption
<gour> right, dev-time is wasted...users can upgrade
<beuno> hey jelmer, I see you got BB back up  :)
<jelmer> james_w: apt_pkg is leaking memory and imported even when bzr-builddeb isn't used
<Kinnison> gour: Depends what you consider more important -- Your users' comfort, or cheap developers.
<jelmer> james_w: Objections to importing it at the only spot where it's being used rather than always?
<Kinnison> gour: A good developer will cope easily with back-compat if it's engineered well.
<sabdfl> we can certainly be more aggressive in deprecating and removing formats
<dato> jelmer: "It generates inefficient code - it generates proxy classes that" <-- it gets cut off there
<sabdfl> i don't think we should keep more than three in play at any time
<jelmer> gour: The backwards compatibility bit only causes overhead when the interface changes, the implementation would generally stay the same
<gour> Kinnison: i consider it's reasonable for users to upgrade to newer & better formats so that old & dead code can be removed
<lifeless> sabdfl: our /big/ bugbear is the transition to rich roots
<lifeless> sabdfl: as soon as thats done it will get a lot easier
<Kinnison> gour: Users are notoriously slow in moving forward.
<lifeless> sabdfl: but I agree, every format users can see in 'bzr help init' adds confusion and documentation and so on.
<Kinnison> Is there not a way to hide the older formats unless the user knows to look for them?
<gour> Kinnison: they're if you allow them to be lazy
<lifeless> sabdfl: ideally we'd be down to one
<lifeless> Kinnison: yes
<Kinnison> gour: It's not a question of 'allow' -- they *are* lazy.
<lifeless> gour: consider dapper
<Kinnison> gour: It's a very bad software engineering practice to expect the user to conform to your software.
<lifeless> gour: it has what, 0.11?
<sabdfl> if bzr tells them "this format is deprecated, and will disappear, please type bzr update now" then they will do so much more
<gour> Kinnison: you can say: from bzr-1.6, format X won't be supported any longer...fire! move on
<Kinnison> gour: Much better to expect the software to conform to users.
<jelmer> dato, whoops, I'll fix that
<james_w> jelmer: none, it's used pretty rarely.
<jelmer> beuno, yep :)
<beuno> having LP tell users they are still using knit there would be a good start. That bites people frequently
<sabdfl> just got to test the hell out of the conversion processes, and make them not too slow
<lifeless> gour: we can expect many users of stable distros to be using old bzr's, and allowing new users to interoperate freely and smoothly with those users helps make the ecosystem work well
<beuno> jelmer, Verterok finished my sqlite -> pg conversion, and uploaded a branch. May be worth trying to see if that's more stable
<gour> Kinnison: it's ok if they want to stick and use old releases, otherwise it does not make sense. how m$ can force users to upgrade their office & OS so often
<gour> lifeless: is there something older that debian? what's current bzr there?
<lifeless> gour: RHE I think :P
<gour> :-)
<beuno> lifeless, btw, have you gave your talk on bzr-search yet?
<gour> lifeless: what version is in RHE?
<lifeless> no, friday
<lifeless> gour: I don't know
<lifeless> well, I'm heading off
<lifeless> later all
<beuno> lifeless, cool, I'll have the javascript quirks worked out by then
<beuno> cya lifeless
<Kinnison> gour: just because microsoft do it doesn't make it right :-)
<jelmer> beuno, the problems are mainly the IP of that machine changing, reboots and mail handling in bb
<jelmer> beuno: I'd rather avoid messing with the db if I can
<gour> Kinnison: i believe it's reasonable that in order to enjoy new features in software, one should upgrade it. atm, bzr brings new features but keeps old formats (too) long which does not make much sense. either users should stay with old releases or upgrade
<beuno> jelmer, ah, so it's different from bzr's problems. Would you like to move that to a more stable server?  I may be able to set it up on one of mine, if I can get Red Hat to install the proper dependencies
<jelmer> beuno, yeah, having a more stable server would be useful
<beuno> jelmer, ok, I'll see if I can get it running, and open up an account
<ToyKeeper> Hmm, looks like bzr-1.3 is in EPEL for RHEL5 / CentOS5.  That makes etch (bzr 0.11) and dapper (bazaar-ng 0.8.2) the oldest.
<dato> EPEL?
<gour> ToyKeeper: so, some formats could go away?
<ToyKeeper> dato: bzr isn't in RHEL, but it's in EPEL (Extra Packages for redhat Enterprise Linux).
<dato> ok
<beuno> ToyKeeper, so I suppose it would only be fair to compare it against backports
<ToyKeeper> I didn't see it in dapper-backports.
<jelmer> it's in sarge and etch backports
<MvG> Is bundle buggy ill today? I get error messages about a locked db when trying to fetch the list of pending merges.
<MvG> I'm also curious about the state of my setlocale merge request. poolie had voted for resubmit after a partial review, abentley and jelmer had participated in the discussion, but now it's seen no activity for almost a week, except for one more post by me where I tried to get things moving again by posting a different approach for the main concern of the previous discussion.
<abentley> MvG: I've fixed bundle buggy.
<MvG> abentley: Thanks!
<MvG> Is anybody planning on reviewing the setlocale branch? Or perhaps has even started?
<fog> how does one know that a file is under version control and not just ignored?
<Kamping_Kaiser> bzr status tell you?
<fog> if the file is not changed no, it does not print anything
<spiv> fog: "bzr file-id FILE"
<fog> spiv: oh, nice. thanks.
<fbond> Anyone had any luck playing with the bzr reviewboard back-end?
<statik> hi jelmer, i'm getting bus errors with bzr-svn when i build on hardy 64-bit. do I need to build against subversion 1.5?
<jelmer> hi statik
<jelmer> statik: No, 1.4 should work as well
<jelmer> statik: Somebody else reported issues with that as well on Mac OS X
<statik> strange. the last thing in .bzr.log is opening SVN RA connection to 'http://bungeni-portal.googlecode.com/svn/trunk'
<statik> I got it working on OS X by building against 1.5 last night
<statik> but this is different
<statik> maybe I can get a core file
<fbond> statik: you aren't using any funny filesystem are you?
<statik> fbond: nope
<statik> how would the filesystem come into play?
<fbond> statik: Okay, I've seen bus errors on Mac OS X when the FS doesn't support mmap and the client program makes an mmap call.
<fbond> statik: Sorry, sounds like it's not relevant.
<statik> fbond: interesting though, I'll file that away :) the bus error is on Ubuntu 8.04 64bit
<fbond> statik: yuck, probably a 64-bit issue... maybe a bug in the python-svn bindings...
<jelmer> statik: have you tried running it under valgrind?
<jelmer> statik: you may want to try running "make valgrind-check" in the bzr-svn directory
<statik> jelmer: not yet, just grabbing debug symbols now
<statik> excellent, will do
<statik> jelmer: make valgrind-check complains about unrecognised instruction vex amd64->IR: unhandled instruction bytes: 0xF 0x1F 0x44 0x0
<statik> i'll poke at this more later
<jelmer> statik: Another thing you could try is "make gdb-check"
<statik> jelmer: ok. that drops me into gdb right away
<statik> oh, type run :)
<jelmer> statik: yep :-)
<statik> jelmer: that looks more useful! http://paste.ubuntu.com/22623/
<jelmer> ah, found the problem
<statik> you rokc
<jelmer> statik, I've pushed a fix
<jelmer> s/I have pushed/I am pushing/
<statik> awesome!
<jelmer> oh, somebody else also reported a bug about this
<statik> i prefer to talk to the man himself, with incredible bug-fixing turnaround speed. i couldn't get this level of service if I paid for it
<jelmer> (-:
<jelmer> abentley: ping
<abentley> jelmer: pong
<jelmer> abentley, is there an easy way of checking whether a merge directive still applies?
<abentley> jelmer: You mean applies without conflicts?
<jelmer> abentley: Sorry, yeah
<jelmer> abentley, preferably without having to create a working tree
<abentley> merge --preview should tell you about any conflicts encountered.
<jelmer> abentley: Ah, thanks
<jelmer> abentley: I'm working on a plugin that checks the status of a bunch of merge directive files
<jelmer> turns out to be quite easy to write
<abentley> jelmer: What's the motivation?
<jelmer> abentley: Making sure none of the merge directives I send to projects get dropped silently
<abentley> jelmer: Sounds similar to the purpose of BB, though reversed, I suppose.
<jelmer> abentley: yep, and not every bzr project uses bb
<jelmer> abentley: It would also be nice to be able to use this for svn stuff, though I guess it's hard to verify that a patch was applied without revids
<abentley> jelmer: Yeah, you'd have to use a different strategy.
<abentley> Like iterating through new revisions and seeing if any incorporate the patch's changes.
<madduck> bzr is hating me again
<madduck> "bzr: ERROR: Tags not supported by BzrBranch5('file:///home/madduck/code/unperish/'); you may be able to use bzr upgrade --dirstate-tags.
<madduck> "
<madduck> +lapse:..unperish|bzr:unperish@170|% bzr upgrade --dirstate-tags.            #1609
<madduck> bzr: ERROR: no such option: --dirstate-tags.
<madduck> oh, the final dot. cut-n-paste. :)
<jelmer> hi madduck
<madduck> hi
<madduck> sorry for the noise
<beuno> madduck, if possible, you should upgrade to the latest storage format, packs  (--rich-root-pack, I believe). Not sure what verson of bzr you're using
<madduck> tracking debian unstable
<beuno> jelmer, you have more experience in this area  :)
<jelmer> beuno: rich-root-pack is a bad idea at this point
<beuno> jelmer, really?  knits with tags is better?
<beuno> I should really stop giving advice to people then...
<jelmer> beuno: No, pack-0.92
<beuno> jelmer, pack support tags by default?
<jelmer> beuno, yep
<beuno> ah, that goes to show how much I use tags
<jelmer> beuno: rich-root-pack is a watershed format. It's impossible to downgrade from rich-root-pack to something older
<beuno> madduck, it's easier then. if you have bzr 0.92+, then just 'bzr upgrade' should do it
<jelmer> I really wish we had less formats
<beuno> me too  :)
<beuno> madduck, either way, packs format is *way* faster/solid
<beuno> jelmer, shouldn't bzr recommend upgrading to packs rather than dirstate-tags?
<jelmer> beuno: yeah, it should
<beuno> so...  rock paper scissors to see who files the bug?  :p
<jelmer> beuno, s/bug/merge request/ >-)
<beuno> well, my day is just starting to begin, so it will be a while til I can start fiddling with bzrlib
<Jc2k> jelmer: whats the incantation to have svn-import make working tree less branch directorys in a rich root pack repository?
<jelmer> Jc2k, that's the default
<jelmer> or should be, at lesat
<Jc2k> hmm
 * Jc2k must be doing it wrong
<Jc2k> *tries again*
<jelmer> Jc2k: if there already is a repository present, it will use the working tree policy of that
<Jc2k> jelmer: this is making a new repo
<Jc2k> jelmer: my existing mirrors are a bit.. mutanty :P
<jelmer> Jc2k: So there's no repo there when you run svn-import ?
<jelmer> Jc2k: or do you run init-repo first manually?
<Jc2k> init-repo --rich-root-pack && branch trunk && remote-tree trunk && svn-import
<madduck> well, glad to have started a discussion. :)
 * madduck must run
<Jc2k> is kind of what happened in hte past
<Jc2k> *remove-tree
<jelmer> Just svn-import should do it
<Jc2k> thats what i thought
<jelmer> that will create a new repository without trees (unless you specify --trees)
<jam> Jc2k: the initial "init-repo ..." doesn't have "--no-trees"
<jam> jelmer: no
<jam> jelmer: 'init-repo' defaults to --trees now
<jam> remember?
<jelmer> jam: svn-import doesn't
<jam> jelmer: but his line involved "init-repo"
<Jc2k> jam: my original script did no-trees
<jam> ï»¿(10:02:25 AM) Jc2k: init-repo --rich-root-pack && branch trunk && remote-tree trunk && svn-import
<jelmer> jam: yes, but "just svn-import" wouldn't involve init-repo
<jam> I'm just mentioning what I've seen in IRC
<jam> If I missed some scrollback, that's fine
<jelmer> jam: Yeah, you seemed to've missed a line
<Jc2k> jelmer: eh, well, it works. jeez. i wonder what i did wrong the first time
<jelmer> So, summing up: bzr init-repo will default to creating trees unless --no-trees was specified
<jelmer> svn-import will not use trees unless --trees was specified
<jelmer> and if there's a repository already there it will use the policy of that repository
<jam> I see you saying that svn-import *should* create it for you, but I see jc2k saying that he did it manually without --no-trees, but that his script actually did supply --no-trees
<jam> I missed where you clarified that "svn-import" defaulted to --no-trees
<jelmer> jam: I was saying that the init-repo and branch commands weren't necessary
<jelmer> only the last command (svn-import)
<jelmer> anyway, we seem to agree on what the situation is
<jelmer> sorry if my explanation of it was a bit confusing
<Jc2k> ok, my mistake
<Jc2k> did something silly after the svn-import
<jam> jelmer: I'm not worried about myself being confused, and it seems that jc2k followed you :)
<fbond> statik: Hey, you are the reviewboard support author?
<fbond> statik: Care to comment on the state of the code?
<statik> fbond: no, i had worked on something a long time back but the current backend i have not looked at
<fbond> statik: oh, okay...
<fbond> statik: I saw https://code.launchpad.net/~statik/reviewboard/bazaarsupport ...
<fbond> Is that dead?
<statik> yes, i should delete that
<statik> sorry :)
<fbond> That's okay.
<fbond> Is there a new bzr backend in reviewboard itself?
<statik> i think so
<statik> the backends were refactored to make it a lot easier
<statik> there should be backends for bzr, git, hg
<jelmer> statik, does "make check" pass for you now on 64bit?
<statik> jelmer: I don't see any new revisions on the 0.4 branch
<statik> last rev is 1339
<jelmer> statik: are you using launchpad? It probably hasn't mirorred yet?
<statik> jelmer: yes, i'm using launchpad. ok, i'll try pulling directly
<statik> jelmer: running tests now
<statik> jelmer: it got a lot farther before core dumping but did eventually crash about 551 test in
<statik> seems usable though, i'm trying to pull from google code now
<jelmer> statik: what error did it crash with?
<statik> [551/875 in 7m42s, 151 err, 49 fail] bzrlib.plugins.svn.tests.test_repository.TSegmentation fault (core dumped)
<statik> re-running under gdb
<statik> jelmer: when i ran make gdb-check, it ran 875 tests without crashing (53 failures, 189 errors)
<jam> statik: gotta love it when it *doesn't* crash under gdb, but does manually :)
<jam> my guess is an uninitialized variable
<jam> anyway, rebooting again
<RichW> I have olive 0.93 and i get Unexpected Error: unsupported operand type(s) for /: 'float' and 'NoneType'
<RichW> I get it when merging from a task branch to trunk
<RichW> Any ideas?
<LarstiQ> RichW: does olive support -Derror?
<LarstiQ> RichW: the first thing I'd try to determine if the problem lies in bzrlib or in olive itself. ~/.bzr.log might be helpful
<RichW> Merging from terminal works fine
<RichW> I see no errors in log
<LarstiQ> RichW: where do you see that error, on the terminal, or in a popup window?
<RichW> Popup window
<LarstiQ> RichW: it doesn't include a backtrace also?
<RichW> I will run from terminal and try to get it.
<james_w> what's the best way to get commits done on a branch to another branch in order to bind against it?
<RichW> No backtrace in terminal
<james_w> I'm trying to explain to someone how to use checkouts to work like subversion, but then gain offline commits. I want to explain how to get back to a bound branch when connectivity comes back.
<james_w> hey LarstiQ
<LarstiQ> james_w: not staved by experience, but I'd expect this to work: don't unbind when offline but commit --local; `update` when back online.
<LarstiQ> james_w: please do confirm that that pivots the local commits into pending merges :)
<LarstiQ> _and_ gets any new commits from master
<LarstiQ> hi, btw :)
<james_w> RichW: https://bugs.edge.launchpad.net/bzr-gtk/+bug/221414 sounds similar
<ubottu> Launchpad bug 221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,Fix committed]
<james_w> and indeed https://bugs.edge.launchpad.net/bzr-gtk/+bug/185869
<ubottu> Launchpad bug 185869 in bzr-gtk "gcommit fails with central bzr smart server" [Medium,Triaged]
<RichW> What does it mean its been committed? Does it mean its in updates now?
<RichW> I have latest updates as far as i know
<prtk> Hello! I am trying to push a branch into launchpad, but I am getting an error  - Permission denied (publickey).
<prtk> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<prtk> I have made my SSH key and have updated launchpad but i am still getting the error. I am a n00b. Can someone tell me what I am doing wrong
<LarstiQ> prtk: are you sure you are using the correct user to connect to launchpad?
<james_w> RichW: updates from where?
<LarstiQ> prtk: the error it is giving you tells you that your (user, publickey) password doesn't match what launchpad expects.
<RichW> Hardy hearon official repos and ive tried the official bazaar ppa.
<prtk> LarstiQ: yes, "prtksxna"
<LarstiQ> prtk: and the key you're trying to login with matches https://launchpad.net/~prtksxna/+sshkeys ?
<prtk> LarstiQ: Where exactly am I supposed to put my key?
<james_w> RichW: no, it means that it is fixed in the development branch of bzr-gtk. Ubuntu hasn't got involved at this point. Your's sounds more like the second bug that I pasted, for which there is no fix available yet.
<LarstiQ> prtk: I presume you're using openssh, so that would be something like ~/.ssh/identity or ~/.ssh/id_rsa.pub
<LarstiQ> prtk: btw, I hope I'm not rude asking this, but are you perhaps related to Deepak Saxena of Linux ARM fame?
<LarstiQ> prtk: how long ago did you upload your ssh key to launchpad?
<prtk> LarstiQ: I don't know any Deepak Saxena, but we sure have the same surname, could be related
<prtk> LarstiQ: i tried one time with the one i uploaded yesterday, then with the new one
<LarstiQ> prtk: launchpad only seems to know one key
<prtk> LarstiQ:  I am guessing that I supposed to put these files in a particular place for bzr to be able to see them (it maybe obvious to you, not me)
<prtk> LarstiQ: Yeah i deleted one of them
<LarstiQ> prtk: that one won't work then ;)
<LarstiQ> prtk: what did you generate the key with?
<prtk> LarstiQ: ssh-keygen (on my terminal) (I am on a Mac)
<prtk> LarstiQ: So, sounding really stupid, to I need to put the files that ssh-keygen generated in a particular folder?
<LarstiQ> prtk: by default it will put them in the right spot, afaik
<LarstiQ> prtk: what files are there in your ~/.ssh ?
<prtk> It puts it in the on top/root
<prtk> .ssh, that would be hidden...
<prtk> its empty...
<prtk> Its asks for the file in which I wish to save it, then created to text files, one of them with extension .pub,
<RichW> james_w: apllied fix in first launchpad bug manually and it works.
<LarstiQ> prtk: ok, try ~/.ssh/identity then
<james_w> RichW: great.
<prtk> prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$ cd identity
<prtk> -bash: cd: identity: No such file or directory
<LarstiQ> prtk: if you know where to find the key you already uploaded to launchpad, rename that one
<LarstiQ> prtk: right
<LarstiQ> prtk: I'm thinking something like 'mv ~/previous_key ~/.ssh/identity; mv ~/previous_key.pub ~/.ssh/identity.pub
<prtk> That key both private and public are in the ~/myproject/ as lp and lp.pub
<LarstiQ> prtk: ah ok
<LarstiQ> prtk: so move them from myproject to ~/.ssh/
<prtk> LarstiQ: and rename them to?
<LarstiQ> prtk: do you know if it is an rsa or dsa key?
<LarstiQ> we can make it work regardeless, but it's nice to stick to the default convention if you can
<prtk> LarstiQ: DSa
<LarstiQ> prtk: cool
<LarstiQ> prtk: you want to end up with ~/.ssh/id_dsa for the private file, and ~/.ssh/id_dsa.pub for the public one then
<prtk> ok, lemme move things around (new to the Terminal as well). Gimme a minute
<davidstrauss> How can I install bzr 1.5 on RHEL 5? EPEL only has 1.3, and epel-testing has nothing.
<LarstiQ> davidstrauss: I'm not familiar with RHEL specific packaging, if you want to know how to do it straying out of that I can tell you though.
 * LarstiQ does a quick search for it
<davidstrauss> LarstiQ: the instructions are wrong on the bzr site
<davidstrauss> LarstiQ: enabling epel-testing doesn't allow me to get the latest bzr
<LarstiQ> davidstrauss: I don't think http://bazaar-vcs.org/DistroDownloads says epel-testing will have the latest bzr, but that it has better chances of having newer than regular epel.
<davidstrauss> LarstiQ: well, current epel has 1.3
<LarstiQ> davidstrauss: If you want to do the Right Thing (TM), I'd get the epel people to package a newer bzr. Are you interested in doing that?
<LarstiQ> or do you just want to have it working now.
<davidstrauss> LarstiQ: both, i guess :-)
<davidstrauss> yes, i know i could install from source
<LarstiQ> davidstrauss: ok, then I'll entrust you with chasing the EPEL people :)
<davidstrauss> and i may do that
<RichW> I downloaded the trunk version of olive "0.95" and I get this traceback when clicking "Statistics --> Log...".. pastebin: http://pastebin.com/m24964be
<LarstiQ> davidstrauss: it is possible to run bzr from it's sourcedir, without installing anything. Depending on your needs.
<LarstiQ> davidstrauss: ie, just unpack it and run <unpackeddir>/bzr
<davidstrauss> then i'll just copy it to /opt and add it to the path
<LarstiQ> davidstrauss: if it is just one user you need to do this for for a limited time, that may be a good option
<davidstrauss> sticking it in /opt is perfectly clean
<LarstiQ> davidstrauss: ok, for that case you might want to actually install it in /opt, that way it can compile some C code as well for speedups.
<davidstrauss> LarstiQ: I think I just said I'd be doing that ;-)
<LarstiQ> not entirely sure how that works with were it expects other python packages to be though, hmm
<LarstiQ> davidstrauss: ok :)
<LarstiQ> davidstrauss: 'copy' to me implied just that and no installing
<davidstrauss> LarstiQ: Oh, I see
<LarstiQ> but I may be weird in that I always run bzr from it's source dir ;)
<prtk> LarstiQ: I did all that but still I get the same error
<davidstrauss> LarstiQ: I have the base python system installed with EPEL
<davidstrauss> LarstiQ: so that should all be in normal places
<LarstiQ> prtk: can you confirm id_dsa.pub matches what is in https://launchpad.net/~prtksxna/+sshkeys ?
<LarstiQ> davidstrauss: ok
<prtk> LarstiQ: Yes
<LarstiQ> prtk: ok, to what url are you trying to push?
<prtk> bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject
<LarstiQ> davidstrauss: could you try that and let me know how it goes?
<LarstiQ> prtk: and it still says permission denid on the public key?
<prtk> prateek-saxenas-computer:~/myproject prateeksaxena$ bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject
<prtk> Permission denied (publickey).
<prtk> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<LarstiQ> prtk: can you access launchpad with the sftp utility? Try running 'sftp prtksxna@bazaar.launchpad.net'
<davidstrauss> LarstiQ: I just did a python setup.py install
<davidstrauss> LarstiQ: Slightly dirty, but OK
<LarstiQ> davidstrauss: so it operates fine now?
<davidstrauss> LarstiQ: I think
<LarstiQ> ok :)
<prtk> Connecting to bazaar.launchpad.net...
<prtk> Permission denied (publickey).
<prtk> Connection closed
<LarstiQ> prtk: ok
<LarstiQ> prtk: and 'sftp -oIdentityFile=~/.ssh/id_dsa prtksxna@bazaar.launchpad.net' ?
<prtk> LarstiQ: same error :(
<jam> RichW: 'committed' means someone has written a fix, 'released' means it is in a mainline branch (generally)
<jam> oops, forgot to scroll to the bottom :)
<prtk> prateek-saxenas-computer:~/myproject prateeksaxena$ cd .ssh
<prtk> prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$ ls
<prtk> id_dsa          id_dsa.pub
<prtk> prateek-saxenas-computer:~/myproject/.ssh prateeksaxena$
<LarstiQ> prtk: that looks good to me
<LarstiQ> prtk: just to be sure, can you paste the contents of id_dsa.pub on http://rafb.net/paste/ ?
<prtk> LarstiQ: Yeah! But I still dont understand why it isnt working
<prtk> LarstiQ: How do I open filed thru terminal?
<prtk> LarstiQ: dont answer that
<LarstiQ> prtk: well, for some reason launchpad doesn't think things match. So either it doesn't have the right key, you have a different key than it knows, or there is a mismatch on username. But we've gone over all those before.
<LarstiQ> prtk: :)
<prtk> LarstiQ: http://rafb.net/p/cQzPrp43.html
<prtk> LarstiQ: Its seems to be the same
<LarstiQ> prtk: yup, so that can't be the problem.
<LarstiQ> prtk: have you tried doing the push with -Dhpss, and then look at the ~/.bzr.log output?
<prtk> LarstiQ: Its empty
<prtk> http://rafb.net/p/v7CcEO63.html
<prtk> LarstiQ: http://rafb.net/p/v7CcEO63.html
<LarstiQ> prtk: two things. You specified -Dpss instead of -Dhpps (dropped the h), and you should look for a file called '.bzr.log' in your homedir
<LarstiQ> so 'mate ~/.bzr.log' instead of 'mate .bzr.log' from myproject would do the latter
<prtk> Its it empty
<LarstiQ> ok, that is very strange.
<prtk> LarstiQ: Does the process differ for Mac in any way?
<LarstiQ> prtk: not as far as I know, so I _really_ expect ~/.bzr.log to be there.
<LarstiQ> prtk: instead of reading it from the log, you could try adding -Derror, but I'm not sure that actually gives the hpss logging on the console, instead of just the traceback
<LarstiQ> prtk: so that would be bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dpss
<LarstiQ> eh
<LarstiQ> prtk: so that would be bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dpss -Derror
<prtk> LarstiQ: http://rafb.net/p/ZD1dfw35.html
<prtk> LarstiQ: Does that help?
<LarstiQ> dang it, where did my h go?
<LarstiQ> prtk: yes, but I apoligize for giving you a slightly incorrect commandline to try
 * LarstiQ tries again
<LarstiQ> prtk: bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject -Dhpss -Derror
<prtk> -bash: bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject: No such file or directory
<LarstiQ> now with an h, as the error message said it should be
<prtk> LarstiQ: wait
<prtk> LarstiQ: http://rafb.net/p/SYi1Rr16.html
 * prtk is frustrated with Bazaar and myself
<LarstiQ> prtk: I can understand that, although it isn't really a Bazaar problem right now.
<LarstiQ> prtk: could you try using the key to login to another system?
<prtk> LarstiQ: Like, this is the 1st time I have used SSH and any Subversion software
<LarstiQ> you could try localhost for starters, you'll need to add (or if it doesn't exist, just copy to) id_dsa.pub to ~/.ssh/authorized_keys
<LarstiQ> prtk: you do have ssh experience though?
<prtk> LarstiQ: None whatsoever
<LarstiQ> prtk: ah, yes, that doesn't make things easier on you.
<prtk> LarstiQ: Not at all :( . But I am eager to learn
<prtk> LarstiQ: So I should make another folder inside of .ssh and copy the public key inside it. Note: All this is happening in /Users/prateeksaxena/myproject
<LarstiQ> prtk: no
<LarstiQ> prtk: you should have a file /Users/prateeksaxena/.ssh/authorized_keys
<davidstrauss> prtk: authorized_keys is not a folder
<LarstiQ> prtk: it's contents should be the same as /Users/prateeksaxena/.ssh/id_dsa.pub
<prtk> ok
<davidstrauss> and it cannot be writable by group or world, or it will be ignored
<LarstiQ> prtk: do you mean to say you have /Users/prateeksaxena/myproject/.ssh/, and not /Users/prateeksaxena/.ssh/ ?
<LarstiQ> prtk: also, what davidstrauss said
<prtk> LarstiQ: YEs
<LarstiQ> prtk: ah, that is not what should happen
<LarstiQ> prtk: whenever I say ~/<foo>, that expands to /Users/prateeksaxena/<foo>
<LarstiQ> prtk: so, move /Users/prateeksaxena/myproject/.ssh/ to /Users/prateeksaxena/.ssh/ (your shell will expand ~ for you)
<prtk> Ok, but the files that I need to push are in the /Users/prateeksaxena/myprojects folder...
<LarstiQ> prtk: that is fine
<LarstiQ> prtk: ssh will look in ~/.ssh/ for its configuration, it doesn't care where it is started from
<prtk> LarstiQ: ok
<prtk> LarstiQ: Done
<prtk> LarstiQ: http://rafb.net/p/t0ABWi80.html
<LarstiQ> prtk: ok, now that the key is in the place where ssh expects it, lets see if it wants to log in directly (or if it tells you the permission on it aren't right, or some such)
<LarstiQ> prtk: 'sftp -v -o IdentityFile=/Users/prateeksaxena/.ssh/id_dsa prtksxna@bazaar.launchpad.net'
 * LarstiQ notes that the -o IdentityFile.. isn't even needed when the key is at .ssh/id_dsa, it will try it by default
<LarstiQ> but it doesn't hurt
<prtk> LarstiQ:  I think it worked http://rafb.net/p/1eHYsg84.html
<prtk> LarstiQ: I now get sftp>
<LarstiQ> prtk: cool, that is what we want
<LarstiQ> prtk: what did you change inbetween the failing and working attempts?
<prtk> when copying to the ~ it chansed my
<prtk> LarstiQ: When copying to ~ it changes my DSA public key, so I updated it again on LP
<LarstiQ> okay
<prtk> prateek-saxenas-computer:~/myproject prateeksaxena$ bzr push bzr+ssh://prtksxna@bazaar.launchpad.net/~prtksxna/+junk/myproject
<prtk> Created new branch.
<prtk> Yat
<LarstiQ> cool :)
<prtk> YAY
<prtk> LarstiQ: https://code.launchpad.net/~prtksxna/+junk/myproject WoW
<LarstiQ> prtk: so to summarise, Bazaar uses openssh as it's underlying transport when you give it bzr+ssh:// urls, and openssh expects its config to be in ~/.ssh/ (the .ssh/ dir in the users homedir)
 * prtk is glad that everything is working now and will push the actual code tomorrow
<prtk> LarstiQ: Thanks a lot
<LarstiQ> prtk: glad to be of help.
<LarstiQ> prtk: will you take this up with matsubara?
<prtk> LarstiQ: As in tell him/her what the problem was
<LarstiQ> prtk: yes, so he can update the FAQ
<prtk> LarstiQ: Ok, but wasnt the problem very stupid wont normal developers know all this?
<LarstiQ> prtk: maybe, but it would have helped you if it explicitly stated these things.
<LarstiQ> matsubara will have to balance that against how long the FAQ is etc
<LarstiQ> prtk: he already mentioned other people asking about this, so apparently it's not an uncommon problem (whether the cause in their cases is the same I can not say, but I'd wager it is in at least a subset)
<prtk> Check #launchpad, he doesnt think its required
 * LarstiQ leaves home for the night
<abentley> jam: is iter_entries_by_dir meant to guarantee a particular sort order within a directory group?
<jam> abentley: I'm pretty sure it is supposed to be lexicographical within a directory
<jam> not 100% positive, but pretty sure
<jam> abentley: Inventory does sort them
<jam> for child_name, child_ie in sorted(cur_dir.children.iteritems()):
<abentley> jam: Ordering isn't guaranteed in the docstring.  I have an implementation that doesn't lexicographically sort, but it fails a test because of that.
<jam> abentley: I believe it is supposed to
<jam> otherwise you can't iterate 2 trees side-by-side
<jam> You can update the doc string if you like
<abentley> Okay, will do, then.
<jam> abentley: by the way, this didn't work like I would have expected "bzrlib.merge.transform_tree(tree, tree.base_tree(), [file_id])" I would have expected it to do the equivalent of "tree.revert([file_id], tree.base_tree())" any ideas why it isn't?
<abentley> jam: Our revert isn't a platonic revert, so there will be differences.
<abentley> In the way directories are preserved, backups are made, and so forth.
<jam> abentley: well, specifically, it didn't actually revert the file, it left it untouched
<jam> I was trying to get it to clean up the working directory
<jam> I cribbed it from 'bzr remerge'
<jam> but found that it didn't do it
<jam> It caused a lot of confusion when I was remerging a text which should not have brought in a delta, and the delta wouldn't disappear
<abentley> jam: No, off the top of my head, I'd expect that to work.
<jam> yeah, that's why I thought there might be something more fundamentally wrong going on
<jam> like file_id isn't matching up properly or something
<jam> but I was using a list of file_id ('[file_id]', not 'file_id')
<abentley> A list of lists of file_ids?
<abentley> ['x', 'y', 'z'] should work.  [['x'], ['y'], ['z']] will not.
<jam> well, it should have just been a list of a single file_id
<jam> sure
<jam> I'll try double checking
<RichW> ï»¿With svn, I can use svnserve and assign people usernames and passwords. With bazaar its making me use a ssh account.. and appears that i need to make more unix accounts to give access.. but wont there be permissions problems if i want to give >1 user access to the parent branch with a seperate username and password?
<RichW> How does the security model for bazaar work exactly?
<jam> RichW: we expect that something else has done authentication
<jam> aka, ssh, http, etc.
<jam> and from there it is filesystem permissions for the given user
<jam> RichW: you may want to look into 'contrib/bzr_access' (you'll want the dev version), to possibly assign permissions based on an ssh_key (at least readonly versus read-write per user)
<RichW> so for example you use the http authentication?
<jam> however, note that users can pretty much do whatever they want in their own branches
<RichW> okay
<abentley> jam: for iter_entries_by_dir, are the children groups required to appear in the order that their parents appeared?
<jam> abentley: off-hand I would say yes
<jam> For the same reason
<jam> abentley: well, maybe not depending on what you mean exactly
<jam> For example: " a/, a/b/, a/b/c, d/, d/e"
<abentley> I mean if I iterate through "a", with contents "b" and "c", am I required to iterate through "b"'s contents before "c"'s
<jam> you will see [a/, d/], then [a/b/], [a/b/c]
<jam> and only later will you see [d/e]
<jam> even though you saw "d/" before "a/b/"
<jam> abentley: otherwise, yes, for two siblings, you should see all of the first siblings children before you see the second sibling's children
<abentley> Okay.
<abentley> ubottu: paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<abentley> jam: I have updated the docstring thusly: http://paste.ubuntu.com/22670/
<jam> abentley: "preceeded by the parent of *the* directory" is probably the only change I would make
<jam> Though I have some other ways of saying it, I don't know that they are clearer
<etank> what is the process for creating a branch of a project on launchpad?
<etank> i did the "bzr branch" command
<abentley> jam: It's actually the directory itself, rather than the parent of the directory, no?
<etank> then went to LP and selected the register branch option
<etank> but i can not push to it
<jam> abentley: what about: http://paste.ubuntu.com/22672/
<jam> I was a bit confused what you were trying to say about the "preceded by" stuff
<abentley> jam: Much clearer.  (The "preceded by" was the original text).  I'd leave out "The order that they are yielded is: "
<jam> abentley: http://paste.ubuntu.com/22674/
<jam> That one has an example
<jam> which are always nice to have around :)
<jam> though we may need to play a small trick with the names
<jam> so that they aren't strictly sorted
<jam> (the top-level directories could come *before* the subdirs in pure lexicographical ordering)
<abentley> I don't follow.  Don't top-level directories come before subdirs anyway?
<abentley> Oh, you mean that strict lexicographical would yield the contents of a subdir before yielding that subdir's sibling.
<abentley> Anyhow, I think that's a vast improvement and will put it in.
<jam> abentley: we've had weird edge cases with "foo/bar" and "foo-bar"
<jam> that gets yielded [foo, foo/bar, foo-bar]
<jam> sorry, "foo, foo-bar, foo/bar"
<jam> see, I got it wrong the first time :)
<abentley> hee.  But the second one is the order I now expect.
<abentley> When I misunderstood earlier, it's because I tend to assume that the only important ordering is that parents are emitted before children.
<jam> sure, it is a over-all strict ordering
<jam> so that each iterator would yield the names in a known order, and you know at all times which one is "ahead"
<jam> I believe the sort key is effectively:  dirname, basename = os.split(path), (dirname.split('/'), basename)
<jam> abentley: we have a helper in "bzrlib.dirstate.cmp_path_by_dirblock", you can see the python code
<jam> in bzrlib._dirstate_helpers_py._cmp_path_by_dirblock_py
<abentley> jam: My implementation now passes the tree_implementation tests.
<jam> abentley: nice, probably good enough?
<jam> You can just do something like: "list(output_iter)"
<jam> assert list == sorted(list, cmp=cmp_path_by_dirblock)
<abentley> That's nice.  I'll add it.
<jam> abentley: of course, that is just on the paths :) not on the (path, entry) tuples :)
<abentley> jam: Sure.  If we're going to use it in the test suite, I think we should hoist it out of _dirstate_helpers.py
<jam> well, you can, but they are compiled modules, so it requires moving things around a bit
<jam> not really worth it, IMO
<abentley> jam: Actually, iter_entries_by_dir is unicode paths, but _cmp_path_by_dirblock is str.
<jam> ah... well they sort the same :)
<jam> sorted(unicode_list).encode('utf8') == sorted(unicode_list.encode(utf8))
<jam> by definition of utf8
<asabil> etank: bzr push lp:~username/project/branch-name
<etank> asabil: i tried that
<asabil> etank: you don't need to create a branch first on LP, it is not required
<asabil> just push, and things will get setup
<etank> aah
<etank> ok
<etank> i will try that then
<etank> elake@asgard:~/Code/memaker_etank$ bzr push lp:~ericlake/memaker/memaker_etank
<etank> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<asabil> ah
<asabil> etank: bzr launchpad-login
<asabil> iirc
<asabil>  bzr launchpad-login ericlake
<etank> yup. seems to be working now
<etank> thanks asabil
<asabil> :)
<asabil> you are welcome
 * abentley shakes fist impotently at gtk and loom for having broken test suites.
<jam> abentley: I had an lca question for you
<jam> I'm looking at putting together LCA logic for path names, instead of always using merge3
<abentley> jam: sorry, I'll be a minute.
<jam> abentley: np, I'll write it up, and you can comment later
<jam> ï»¿when all bases == eachother, you trivially switch back to merge3
<jam> if bases are different, you can still short-cut if 'this == other'.
<jam> but is there anything we can do but conflict if this != other and all bases are not the same
<jam> For "weave" we would do "if other in bases and this not in bases: this" "if this in bases and other not in bases: other"
<jam> (with the idea that if one side is considered unchanged, but the other side *is* changed, then it supersedes both bases)
<jam> And then if other not in bases and this not in bases, then you have a genuine conflict
<beuno> james_w, blog post -> lol
<james_w> hi beuno, glad you like it :-)
<beuno> and thanks  :)
<davidstrauss> How are permissions handled when using the "Smart Server"?
<Peng> Wow, Loggerhead's /changes page gzips from 82 KB to 5 KB.
<davidstrauss> The smart server process theoretically has full write access.
<Peng> davidstrauss: Only theoretically?
<davidstrauss> Peng: and even in practice!
<davidstrauss> Peng: Just theoretically because I have yet to set it up
<davidstrauss> Peng: Although I may make the smart server process have only read-only access if I can't control what people do over bzr:// otherwise
<james_w> davidstrauss: there are no internal permissions in the smart server, everything is based on the filesystem permissions, or something that comes before the smart server.
<Peng> davidstrauss: bzr:// does no auth, so yeah, make it read-only.
<davidstrauss> ok
<Peng> davidstrauss: (Well, the smart server never does auth, but with bzr+http or bzr+ssh, it's easy to have the web server or sshd do it.)
<davidstrauss> so bzr:// for read-only and bzr+ssh for write
<james_w> over raw bzr:// it's not a good idea to allow write access unless you are on a locked down network where everyone is trusted
<davidstrauss> understood
<Peng> davidstrauss: You can use bzr+ssh for read access too, of course.
<davidstrauss> Peng: of course, but i need a way for people to get data without me installing a key for them
<Peng> Okay. :)
<Peng> For anonymous read-only access, then, bzr:// is great.
<davidstrauss> ok
<davidstrauss> i was hoping to not need ftp or http
<davidstrauss> good
<abentley> jam: that sounds like it ought to be a conflict.  If the bases differ, that would imply different merge resolutions.
<fbond> jelmer: If I have two trees with some common ancestry in an svn repository, /trunk and /branches/foo, say...
<fbond> And I use bzr-svn to like:
<fbond> bzr branch svn+http://.../trunk
<fbond> bzr branch svn+http://.../branches/foo
<fbond> Does bzr think these two new branches have shared ancestry?
<fbond> jelmer: Like, will bzr missing tell me what I would expect it to?
<Jc2k> fbond: if you did svn cp trunk branches/foo at some point, then possibly
<fbond> Jc2k: that's assumed.
<jam> abentley: sorry, X just crashed
<jam> anyway, I think if "this in bases and other in bases and this != other" that is a conflict, because they disagreed on resolution
<Jc2k> fbond: if there was lots of manual merging, i don't know how will it would cope, but otherwise the answer is yes
<jam> but if "this in bases and other not in bases" then it is clear that "other" should supersede both bases, right?
<abentley> ï»¿jam: that sounds like it ought to be a conflict.  If the bases differ, that would imply different merge resolutions.
<jam> abentley: if bases differ and this == other, then there is no problem
<jam> I'm not sure why it isn't clear if one side supersedes
<fbond> Jc2k: Well, the reason I'm asking is because that's not what I'm seeing...
<fbond> Jc2k: What kind of "manual merging" would cause this?
<abentley> I was reposting my reply.
<jam> abentley: sure, but I think that was my original comment as well
<abentley> I wasn't clear that you were saying "this in bases, other not in bases, bases not equal"
<jam> it is certainly *possible* that this merged and picked one base, other merged and picked a different base, and then this superseded the result
<jam> abentley: ok, lets start from the beginning :)
<jam> if bases are equal, then we have simple 3-way, right?
<Jc2k> fbond: i'm not very good at explaining, sorry.
<Jc2k> fbond: what are you seeing?
<abentley> jam: right.
<jam> so the rest of this is going to assume that one of the LCA's disagreed
<abentley> If bases differ, then you have different conflict resolutions.
<jam> if this == other, then you have "this" without a conflict
<abentley> jam: right, convergence.
<jam> whether they are a base value or not, both sides obviously agree at the final result
<jam> now, imagine both merge and pick base 1
<jam> and then OTHER changes it to "foobar"
<jam> that should supersede, right?
<abentley> That's a case where bases agree.
<jam> abentley: no, because LCA's disagree
<jam> and we don't share the same merge node
<abentley> When both merged and picked base 1, they created new LCAs.
<jam> aka, there is a Revision X from A & B which picked 1, and a revision Y from A& B which picked 1
<jam> but this doesn't have Y in its ancestry, and OTHER doesn't have X in its ancestry
<jam> s/1/A/ might be a bit more obvious
<fbond> Jc2k: my trunk branch thinks that it is missing *all* of the revisions in foo.
<fbond> I should mention that this is what I really did:
<fbond> bzr branch svn+http://.../trunk
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<fbond> [make a bunch of changes to trunk]
<fbond> [commit to trunk, send changes back to svn trunk]
<fbond> bzr branch svn+http://.../branches/foo
<fbond> So there were commits, merges, etc. to the trunk branch, and some of those commits and merges got sent back to the svn repo (with the special bzr-svn properties).
<fbond> Some of those revisions eventually got merged into the svn's branches/foo before branching from foo with bzr...
<fbond> So it's a little complicated...
<jam> abentley: graphs for comment: http://paste.ubuntu.com/22692/
<abentley> jam: for the last case, the two sides may agree that 'bing' has precedence over 'bar', but they don't agree that 'bar' has precedence over 'foo'.
<jam> but they should agree that 'bing' has precedence over 'foo'
<jam> or at least certainly one side asserts that
<jam> (and certainly I can channel my inner Guilheim and see it that way, though I'm willing to be convinced otherwise)
<abentley> jam: only one side asserts that.
<jam> abentley: but in any 3-way scenario, one side is asserting something that the other side accepts
<jam> other != base and this == base means that other > this
<jam> abentley: I can understand where you are coming from, but I do think it is a case of "intelligent people can disagree"
<abentley> jam: Right.  We agree that it should have been "a", and I'm changing "a" to "b"
<jam> And while I sort of like falling on the side of caution and issuing a conflicts
<jam> mere mortals have problems with lots of conflicts
<jam> as in... days of work to resolve
<jam> I think some of these took a guy a week or two to resolve
<abentley> jam: I think this is a UI problem, not a merge algorithm problem.
<jam> so perception is that we are getting in the way when we don't have to
<jam> *right now* I'm not specifically hitting this point with paths
<jam> what we are generally hitting is "LCA's agree, but the path is not in the unique LCA base"
<jam> which causes truly spurious conflicts
<jam> so fixing that is a good step forward
<jam> for now, I'm just conflicting whenever this != other and bases are not all the same
<abentley> jam: In the last case, if you replace "bing" with "foo2", do you still assert that "foo2" ought to win?
<jam> abentley: it would be the same reason to win
<jam> I don't see how "foo2" is different than "bing"
<abentley> jam: The point being that foo2 might be a single-character change of foo, basically eqivalent to foo.
<abentley> I think you're right about the middle case.
<jam> abentley: Right now, the texts are unimportant (IMO) other than which one supersedes which
<jam> there is also another case:
<abentley> In designing LCA merge, I was assuming that the lines didn't change after the criss-cross.
<jam> there is also another case:http://paste.ubuntu.com/22695/
<jam> but it is just the mirror
<jam> abentley: oh... they change alright :) In lots of interesting ways
<abentley> jam: The reason I'm making a point about the texts is that I think you can agree that "foo" should not win-- we should get a conflict.
<abentley> But from the perspective of A-B-D, "foo2" may be just as wrong as "foo".
<abentley> They have spent effort, doing a correct fix, and they wouldn't want it silently obliterated.
<jam> abentley: this is what I just heard from you: http://paste.ubuntu.com/22696/
<jam> Which certainly shouldn't conflict, as THIS == OTHER (convergence)
<abentley> jam: I'm sorry.
<abentley> I should have said bar2 all along.
<jam> abentley: do you mean: http://paste.ubuntu.com/22698/
<jam> I would expect that to "win" for F versus D
<jam> (under the Guilhem rules)
<abentley> I don't know who this Guilhem is.
<guilhembi> abentley: hi! it's me, just a user from Sun/MySQL
<jam> abentley: I'm just using a term for it, but guilhem is the mysql guy
<jam> abentley: Under the "if it is in my ancestry, and I supersede it, I win"
<abentley> jam: But D is not in the ancestry of E.
<guilhembi> jam: btw, this is out of scope and I'll shut up, but I *really* appreciate the diligence and quality work you put into these support issues. eof.
<jam> abentley: but the *value* at D is
<jam> as D == B
<abentley> Sure, but D is an assertion that B is wrong.
<jam> so there was "no change"
<abentley> That C is worng.
<jam> technically it is an assertion that C is wrong
<jam> and F ends up agreeing :)
<jam> C is wrong
<jam> guilhembi: are you following the discussion? Do you feel like I am representing your position?
<abentley> jam: But F is based on C.
<guilhembi> jam: uh, I didn't follow it, and I was rather heading to bed :/
<guilhembi> but I can read it from irc logs tomorrow
<abentley> And A-B-D thinks that C is wrong.
<jam> guilhembi: no problem, sleep tight
<guilhembi> thanks
<abentley> And so they likely would consider F to also be wrong.
<jam> ï»¿abentley: so... it may just be a UI thing, but I know that when guilhem comes to me to ask why this is conflicting, he uses stuff like gannotate, and notices that everything that conflicts was already in the merged ancestry
<guilhembi> yes, gannotate or annotate.
<jam> we don't have any way of showing them "this conflicts because of D".
<abentley> jam: right.
<guilhembi> and also, "another RCS automerged it fine" (TM)
<jam> in fact, 'bzr annotate' will never mention D
<jam> because its text matches the parents
<jam> guilhembi: I think the retort is "just because another VCS is broken, doesn't mean we need to be" :)
<guilhembi> jam: yes, I knew you would say that :)
<abentley> jam: so there are things we can do.
<jam> abentley: in fact, D could be a conglomerate of B and C, and as long as it doesn't introduce new texts, it won't get shown
<jam> aka, D is a completely unique text, but doesn't get any lines attributed to it
<jam> as it is just a mash up of existing texts
<abentley> One thing is to distinguish between conflicts and conflicting resolutions in our merge output.
<abentley> another thing is to provide ways for the user to pick one resolution over another.
<jam> abentley: you mean a "bzr remerge --this" ?
<abentley> jam: or even merge --this.
<jam> abentley: sure, though I would hope that you wouldn't want to do it to *all* of your files
<abentley> If you believe it's suitable for one file, why wouldn't it be suitable for all?
<jam> abentley: because some files conflict while others have genuine changes
<jam> in ways described here
<jam> --this would ignore all the real changes you are merging
<abentley> Are you now talking about three-way conflicts compared to conflicting resolutions?
<jam> abentley: well are you saying that '--this' is only active for conflicting resolutions?
<jam> Or is it active for all conflicts?
<abentley> jam: That's what I was thinking, yes.  Similar to how weave behaves.
<jam> abentley: also, there is a problem that the "middle case" is one that can't really be distinguished from the contentious case without inspecting the intermediate nodes
<jam> which is something that I'm trying hard to avoid
<abentley> I think it's impossible to distinguish the middle from the bottom without inspecting D and E.
<abentley> But maybe *only* D and E need to be inspected?  Not sure about this.
<jam> abentley: well, you could have E == 'XXX', Echild='foo', when you decided that the other was really correct after all
<jam> abentley: hmm... I have another small problem with paths on disk...
<jam> In one LCA, it has name "Foo", in 2 others it is not present
<jam> in this it is named "prefix_Foo"
<jam> and from what I recall, guilhem was thinking it would be named "Foo" in THIS.
<jam> which doesn't fit *my* best guess
<jam> oh, maybe it is just because the conflict renames it
<jam> and he didn't know which name it should have
<lifeless> moin
<jam> good morning lifeless
<lifeless> Jc2k: hi
<Jc2k> lo lifeless
<Jc2k> google bot seems to have found bzr-mirrors loggerhead!
<lifeless> cool
<lifeless> did that search finish ok with the reduced threshold ?
<Jc2k> ah, i forgot to rerun that
<lifeless> also, did you file a bunch of bugs for the things ou mentioned
<lifeless> about what some gnome devs are crying out for
<Jc2k> now that i didnt forget, i just passed out after first day at codethink :p
<lifeless> how was it?
<Jc2k> awesome
<Jc2k> its quite twisted though, im hacking on a fork of git..
<lifeless> yah, I read
<lifeless> ironic, no?
<Jc2k> indeed
<bkor> Jc2k: what are they crying out for?
<Jc2k> hopefully it will make my cries of "no git!!" more valid
<lifeless> "My name is John, and I'm powerless"
<Jc2k> bkor: robtaylor wants rebase
<Jc2k> (--interactive)
<lifeless> -i specifically yeah?
<Jc2k> yep
<bkor> Jc2k: that is it?
<Jc2k> hell no
<lifeless> ahha
<Jc2k> its just one that sprang to mind.
<Jc2k> the other one is, some pople really want the combined single folder for working tree and all branches
<Jc2k> i can perhaps see usefulness of that when we couple it up to jhbuild
<bkor> yeah.. they want the existing compilation thingy
<bkor> meaning: branch for just a small change.. then it is handy when the compilation is as fast as possible
<lifeless> did you guys see the http://kubasik.net/blog/tag/bzr/ post ?
<lifeless> bkor: we have that small change thingy though via switch
<lifeless> bkor: implementation vs interface difference I guess; the key thing is 'I have two branches and I can switch'
<lifeless> but... I suspect that it may be more efficient to say 'ok here is a plugin that makes it look like git; now when you know the system more you may appreciate what we do'
<Jc2k> indeed
<Jc2k> bzr-gitmode
<bob2> gitanamo!
<bkor> lifeless: btw, in one of the 'should use git' posts (IIRC on planet ubuntu), someone showed a not too descriptive bzr error msg
<lifeless> bob2: groan
<bkor> I don't like the advocacy style though.. 'found an unclear error msg and git it better, so git is great'
<bkor> and the 'everyone knows git' + 'every dvcs is hard to understand'
<lifeless> I related that one to martin
<lifeless> he fell over laughing
<lifeless> "its true though, *IF* every vcs were as hard to learn as git"
<mwhudson> Jc2k: hello
<mwhudson> Jc2k: have you seen any problems like https://bugs.edge.launchpad.net/loggerhead/+bug/242580 ?
<ubottu> Launchpad bug 242580 in loggerhead "Current trunk tends to peg CPU at 100% after running a while, for no obvious reason" [Undecided,New]
<lifeless> Jc2k: so yes, please file bugs for -i and having an optional all-branches-in-one-dir facility
<Jc2k> mwhudson: no i havent
<mwhudson> Jc2k: thanks
<Jc2k> lifeless: will do
<mwhudson> it's probably a bug in the config support, /me hopes
<lifeless> Jc2k: and any other things that you think are important
<jam> lifeless, Jc2k: I've been running with a "multiple branches, 1 working tree" for a bit now, and while there are some things missing still, I think it works rather well
<jam> the big missing thing is a "bzr clone" that gets multiple branches
<jam> I also find that I often *need* several live trees at once
<jam> so having the flexibility of both is pretty nice
<jam> (like, what was that really in bzr.dev, and working on multiple features at once, and neither is quite ready to commit)
<lifeless> jam: yes; the point here is not that we have an alternative implementation; its that we're facing folk who argue for an implementation not a facility
<jam> abentley: In "_merge3" you use "iter_changes(include_unchanged=True)" why do you want unchanged files here?
<jam> sorry, that is "Merge3Merger._entries3"
#bzr 2008-06-25
<poolie> hello jam
<jam> hi poolie, a little late for "before the standup call" :)
<poolie> yeah :)
<strk> I have two branches in a repository. One I use for dev, standalone. Another I use for trackign trunk, bound upstream.
<strk> a working tree switches between the two
<strk> bzr diff ../bzr-local-repository/trunk # shows nothing
<strk> bzr diff ../bzr-local-repository/mybranch # shows nothing
<strk> from the working tree
<strk> is that enough to tell 'trunk' and 'mybranch' don't differ ?
<strk> bzr diff ../bzr-local-repository/trunk ../bzr-local-repository/mybranch # gives me:
<strk> bzr: ERROR: sorry, u'..' not allowed in path
<strk> what does the << u'..' >> part mean ?
<strk> typo in bzr code ?
<emgent> heya
<spiv> strk: the u'' is Python's way of indicating a unicode string.
<strk> thx, any idea about previous question ?
<strk> i'm having troubles figuring out a good workflow, as it seems every merge puts my working tree in a non-up-to-date status
<strk> even if there's nothing to merge (apparently, since diff gives no diffs)
<spiv> Well, there are different types of differences :)
<spiv> There's difference in content, that's what "bzr diff" does.
<strk> it seems I basically got an 'empty' commit in mybranch
<spiv> There's also difference in history.  "bzr missing" can report on that.
<strk> which I guess is the commit that a merge to trunk is showing as a "pending merge" again
<strk> the two branches obviously have a different history
<strk> if, from a trunk-bound tree I call 'bzr missing mybranch'
<strk> I get that annoying missed revision
<strk> message:   trunk merge ?
<strk> that's a commit after a merge of trunk to mybrach
<strk> seems silly to merge back to trunk, as it came from trunk initially!
<spiv> You might prefer "bzr merge --pull"
<strk> kind of an egg & chicken
<igc> morning
<lifeless> strk: this is a bug actually;
<lifeless> strk: the graph fails to converge correctly
<strk> is there something I can do to help tracking it ?
<lifeless> uhm
<lifeless> for now
<lifeless> if when you merge
<lifeless> bzr st shows nothing other than pending merges
<lifeless> just revert
<strk> I'm afraid I failed in that when merged trunk into mybranch
<strk> how can I check that ?
<strk> like, how can I get bzr log tell me exactly which files were changed, if any ?
<spiv> bzr log -v
<strk> ouch
<strk> looks terribly wrong
<strk> http://rafb.net/p/yWqEyF12.html <-- bzr log -v -l 10 (from mybranch-bound working tree)
<lifeless> spiv: this is gnash btw
<lifeless> spiv: who have just migrated
<strk> shouldn't the indented entries under revno: 9430 show "composition" of that commit ?
<strk> (first rev)
<spiv> lifeless: ah, nice
<lifeless> back soon; bacon and eggs are calling
<strk> it seems that was my first backward merge
<strk> so far I've always merged mybranch *into* trunk
<strk> but for the first time, to commit something to trunk w/out reverting or committing my changes ... I did the commit from another working tree
<mwhudson> beuno: are you around?
<strk> then I tought I had to merge trunk to mybranch, and the log above shows what happened
<spiv> strk: I'm not sure what you mean by "composition"
<strk> spiv: I'm still trying to understand 'bzr log' output
<strk> my current interpretation is based on 'bzr log' output from trunk, which seems clearer
<strk> by "composition" I mean a kind of commit trackback history
<strk> for example
<strk> http://rafb.net/p/oatno492.html <-- thise is bzr log for trunk
<spiv> Right, so r9430 merged in trunk (which had 4 revisions you didn't have, which are shown indented).  The only text changed by the merge was .bzrignore
<strk> hold on
<strk> r9430 merged in mybranch
<strk> *from* trunk
<spiv> strk: you might find a graphical layout helpful, e.g. "bzr viz" if you have the bzr-gtk plugin installed.
<strk> I'll get it immediately
<spiv> In http://rafb.net/p/yWqEyF12.html it shows r9430 in mybranch is a merge from trunk
<spiv> Note that the revnos in different branches can and do point to different revisions.
<strk> right, r9430 is a merge from trunk to mybranch
<strk> r9430 in mybranch, that is
 * strk looking at 'viz' now
<strk> mm... timestamps are all bogus (ok, let's forget about that now)
<strk> ok, the graph from 9425 on is pretty spaghetti :)
<spiv> Yeah, I thought it would be :)
<strk> lemme see if the viz for trunk makes more sense
<strk> :'(
<strk> less spaghetti, but still unclear
<spiv> So the first paste shows r9430 (of mybranch) merged in trunk, and at that time trunk had four revisions mybranch didn't.  Most of *those* revisions were merges from mybranch.
<spiv> So, I'm not sure what specifically isn't clear to you atm.
<strk> ok
<strk> the point is, the four revisions mybranch had all
<strk> see 9429
<strk> r9429 of mybranch
<spiv> mybranch's r9430 merged in the changes in trunk which were a) some merges from mybranch (and thus no changes vs. mybranch), and b) a change to .bzrignore
<strk> "Fix missing libgnashplugin.so glib link...."
<spiv> So I see it.
<strk> ok, my point is that (a) is confusing
<strk> what does it mean to merge changes that were merges from here ?
<spiv> Ah.
<strk> the missing libgnashplugin.so thing
<strk> was committed in mybranch
<spiv> Look at the bzr viz for mybranch again.
<strk> yes, I'm looking at it now
<spiv> And/Oo try "bzr log --show-ids"
<spiv> "And/or", rather
<strk> there I see that mybranch r9429 was...
<strk> ok, restarting with --show-ids
<spiv> The history of a branch is a DAG
<strk> bzr: ERROR: no such option: --show-ids
<spiv> strk: bzr log --show-ids?
<strk> http://rafb.net/p/3IJBae18.html (--limit 120
<spiv> (you can already see the ids in bzr viz by clicking on a revision and looking at the information below the graph)
<spiv> A regular commit makes a branch with just one parent.
<spiv> (so just one "parent:" line in the log --show-ids output, and just one downwards line in the bzr viz diagram)
<spiv> A merge adds another parent.
<spiv> So when you commit a merge, you're not just recording what files were changed by the merge, but exactly which revision was merged onto another.
<strk> mm
<spiv> This is what lets bzr automatically figure out which revisions to process when you do "bzr merge".
<strk> do you have viz window in front of you too ?
<strk> ops, I guess you ca'nt wout access to mybranch ?
<spiv> e.g. if you get conflicts, and resolve them, then that resolution is recorded.
<spiv> strk: right
<strk> I have a r9425.1.1 (branch nick:trunk)
<spiv> I see that in your first paste, yep.
<strk> which was supposedly (I tought it was) the merge of a sum of 3 commits I made in mybranch
<strk> specifically, r9426,r9427 and r9428
<spiv> It was.
<strk> the 'giz' graph shows r9425.1.1 in trunk having 2 parents
<strk> or, two lines ...
<spiv> Right 2 parents.
<strk> one is r9428 and the other is r9425
<spiv> Hmm, make sure you turn off View->Show Compact Graph in bzr viz.
<spiv> (not sure if that's on by default)
<strk> is off
<spiv> If you compare the graph of those two parent revisions, you'll see that there are three revisions in mybranch that aren't in trunk.
<strk> uh ?
<spiv> In fact, try this: "bzr viz -r 9426" in trunk.  the top revision will be that merge.
<spiv> And what you should see will look like this: http://rafb.net/p/1KTfVR17.html
<strk> yes
<spiv> i.e. two lines going down out of that revision, that's two parents.
<strk> trilling
<spiv> But three revisions along the right-hand line that aren't on the trunk (which is always on the left-most side in bzr viz, just like log)
<strk> is the graph info all trunk has about those 3 revisions ?
<spiv> It has the full contents of those revisions in its repo.
<strk> k
<spiv> e.g. in bzr viz you can double click on any one of them and get the full diff.
<strk> great!
<strk> so, back to mybranch viz
<strk> r9430 in mybranch brought in .bzrignore changes only
<strk> which was r9425.1.4 in trunk
<strk> what I don't understand is the graph I guess
<spiv> Well, the only changes in trunk that weren't already in your branch were the .bzrignore changes.
<strk> in that it *seems* to have brought in also r9425.1.3,1.2,1.1
<spiv> Right, those are new revisions, but those revisions don't have any text changes that mybranch didn't already have -- because those revisions were merges from mybranch.
<strk> oh, maybe r9425.1.2 AND r9425.1.4 did actually get in
<strk> the other two didn't because they had revisions in branch as parents
<strk> namely, r9425.1.3 (trunk) came from r9429 (branch)
<spiv> Right, .1.1 and 1.3 were merges from mybranch.
<strk> and r9425.1.1 (trunk) came from r9428 (mybranch)
<spiv> All good now? :)
<strk> not yet :)
<strk> if I now merge mybranch into trunk
<strk> there's somehting unclear
<strk> status gives pending merges:   Sandro Santilli 2008-06-25 trunk merge ?
<strk> but no changes
<spiv> Right.
<lifeless> this is a case we should actually detect and cancel a merge on
<spiv> That's because there's a new revision, but for this branch that revision has no new changes to merge.
<spiv> lifeless: +1
<lifeless> with --force allowing it to be done anyhow
<spiv> lifeless: (probably allow --force to override)
<strk> alright, I'll take that as a bug
<spiv> lifeless: snap!
<strk> another thing. 'viz' shows me info about things I tought I reverted
<strk> r9422.1.2 in mybranch
<strk> shown in 'viz' for trunk
<strk> shown in cyan color
<strk> never mind, too late to think ... 2:30 am
<strk> thanks a lot for your time
<mdmkolbe|work> I have a repository in my home directory at the departmental machines, how do I check out from my home machine?  (e.g. like svn's svn+ssh://host/path)
<mdmkolbe> I have a repository in my home directory at the departmental machines, how do I check out from my home machine?  (e.g. like svn's svn+ssh://host/path)
<lifeless> mdmkolbe: bzr co bzr+ssh://host/path
<mdmkolbe> cool, thx
 * mwhudson adds 'logging' to the pile of things loggerhead does appallingly
<lifeless> :P
<mwhudson> lifeless: did you see https://bugs.edge.launchpad.net/loggerhead/+bug/242806 ?
<ubottu> Launchpad bug 242806 in loggerhead "log rotation actually doesn't save old logs (it truncates them)" [Undecided,New]
<Peng> Heh.
<lifeless> mwhudson: rotfl
<mwhudson> in better news, i can run 'ab -n 10 -c 5 'http://localhost:8080/revision/158' on ubuntu-desktop-course-beta (which is a laaarge revision page) and have the loggerhead process use 300 megs at the end
<jml> lifeless: is there a way to view a log of all commits made to a thread?
<mwhudson> whereas with kid, just rendering that page once got the oom killer into action
<lifeless> jml: 'bzr log'
<lifeless> mwhudson: excellent
<jml> lifeless: that shows messages from before the thread was created
<mwhudson> that page is still a DoS on the user's browser of course
<lifeless> jml: bzr log -r thread:..
<jml> lifeless: that shows messages from the last merge from the lower thread.
<lifeless> jml: how about this; rather than me guessing what exactly you mean, you pastebin something, and say 'I want X Y and Z from there, and nothing else'
<jml> lifeless: ok. probably later though.
<lifeless> k
<Peng> Quick!
<lifeless> jam: still around ?
<jam> lifeless: current waiting for leo to die (WW), but somewhat around :)
<lifeless> jam: I'm onto annotate
<lifeless> and I'm at a complete loss as to what to do
<jam> oops.. :)
<jam> the code you care about is in knit.py
<jam> if you want to do the simple thing
<jam> just feed the fulltexts into annotate.reannotate()
<lifeless> I'm hesitant to touch it because I know its been performance tuned
<lifeless> and I have no benchmarks or other things to check I don't break it entirely
 * igc lunch
 * lifeless goes looking for jml's test for stacking on remote repos
<jam> lifeless: I was planning on letting you make it slow, in exchange for having it *work* :)
<lifeless> jam: :). Its on my list; I'm getting the stacking repo stuff polished first
<lifeless> as annotate is not as strict a blocker
<jam> sure, I would have thought some tests would fail, but there may not be a lot of per-xxx annotate tests
<lifeless> well
<lifeless> none that know to setup a basis repository, do a shallow branch precisely cross history lines and then annotate
<lifeless> there is one XFAIL, that I wrote :P
<lifeless> Jc2k: is loggerhead up on bzr-mirror yet ?
<mwhudson> seems to still be on 9876
<lifeless> yay:
<lifeless> :!bzr commit -m "Implement generic stacking rather than pack-internals based stacking."
<lifeless> jml: ping
<jml> lifeless: pong.
<lifeless> do you remember where you put the patch that tests stacking on bzr+ssh ?
<lifeless> like was it mail, a bug, or ?
<jml> lifeless: I grepped around in my sent mail and couldn't find it.
<jml> lifeless: I might have it on disk in a branch.
<jml> lifeless: once I finish this review I'll look again.
<poolie> lifeless: yay, way to go
<poolie> beuno, if you're still up, that demo site is *amazing*
<lifeless> and on the 7th day
<poolie> well done
<lifeless> poolie: the bzr-search one ?
<lifeless> beuno: also, the download link, for a dir, could output a tarball :)
<lifeless> jml: march 5 I found an email that describes the problem
<jml> lifeless: yes, I found that.
<lifeless> thumper: there are branches being created in the web ui for the bzr project that appear to be pure noise
<thumper> lifeless: unfortunately that happens, a question on launchpad-bazaar is one way if you get no response form the owner, editing the whiteboard to tell the branch owner that it isn't appreciated is another
<lifeless> thumper: putting aside my preference for not having that feature; I would be happy if branches that 'have never been pushed too' didn't show up on https://code.edge.launchpad.net/bzr
<jml> lifeless: so, I think the tests are uncommitted changes in a working tree :\
<lifeless> jml: ><
<lifeless> pastebinned ?
<jml> lifeless: I'll do so now.
<jml> http://paste.ubuntu.com/22781/
<jml> lifeless: I seem to remember you narrowing the test down on your laptop.
<jml> lifeless: but the memory is not trustworthy.
<lifeless> I loath the ui of paste.ubuntu.com
<lifeless> argh
<lifeless> :!bzr patch http://paste.ubuntu.com/22781/plain/
<lifeless> bzr: ERROR: http://paste.ubuntu.com/22781/plain is permanently redirected to http://paste.ubuntu.com/22781/plain/
<lifeless> abentley: where do you want bzrtools bugs?
<abentley> lifeless: bugs.launchpad.net/bzrtools
<lifeless> abentley: thanks
<lifeless> jml: bingo:
<lifeless> jml:  02: bzr: support (but failing, RemoteRepository is not a PackRepository)
<jml> lifeless: is this in a local branch of yours?
<spiv> lifeless: pqm seems to be confused; it processes a request, the log in the web ui shows it succeeded, but no change happens to bzr.dev and I get no email.
<lifeless> its shelved
<lifeless> spiv: gpg key expired
<lifeless> hangon
<spiv> lifeless: ah.  Thanks.
<lifeless> spiv: resubmit
 * spiv presses the magic button
<lifeless> jml: and it passes!
<jml> gsap
<lifeless> which means, we're gtg
<jml> sweet.
<jml> that makes the stuff I'm working on now all that more pressing.
<lifeless> poolie: you gotta relax a bit more :P
 * jml makes another coffee and dives to hacking level
<lifeless> jml: pushing an updated loom
<poolie> lifeless: uh?
<lifeless> poolie: you were stressing about stacking this morning
<jml> lifeless: cool. I won't be looking at your branch today unless I am suddenly endowed with the nine rods of eternity.
<lifeless> nein rohds huh
<poolie> lifeless: oh ok
<poolie> that's an interesting comment but remind me of it over that beer sometime
<lifeless> ok
<lifeless> I was intending to tease was all
<lifeless> anyhow, I'm about to send in a final review request for Development1
<jml> lifeless: yeah
<lifeless> I'm now, finally, completely happy to land it
<jml> lifeless: of course, if that happens I may have more pressing concerns than fast distributed version control.
<lifeless> then I'm going to drink some caffiene, and look at making annotate stack correctly
<mwhudson> if you want to stream out a file's contents is some version of iter_file_bytes() your best bet?
<mwhudson> or is get_file_lines() likely to work well too?
<beuno> poolie, thanks  :)
<mwhudson> hi beuno
<beuno> hey mwhudson
<mwhudson> beuno: did you see https://code.edge.launchpad.net/~mwhudson/loggerhead/streaming ?
<beuno> lifeless, downloading tarballs is on the bug list :)
<beuno> mwhudson, I haven't. Let's take a peak
<beuno> mwhudson, oh, cool!  That will make big diffs and annotates seem more responsive  :)
<mwhudson> yeah, and it keeps memory usage under control a bit more too
<mwhudson> e.g. it can render my 24 meg horror test case revision page with ~70 megs resident
<mwhudson> it's a bit slower on that page though
<beuno> mwhudson, looks very good. We should do some benchmarking before release to compare the improvements, but it sounds like it's going to be a pretty big leap
<beuno> also, our dependencies are down to python-paste and python-simpletal. How cool is that?
<mwhudson> yeah, i'm pretty happy about that
<mwhudson> though really, the streaming is a hack in some ways, we simply shouldn't be generating 24 meg pages
<mwhudson> ah, cool
<mwhudson> so it turns out a little bit of buffering is a good thing :)
<beuno> no, we shouldn't. I'd like to experiment a bit on not using templates to generate the diff text and annotate content when we're past 1.6
<beuno> should be a lot faster and a lot smaller
<mwhudson> beuno: <blink>+1</blink>
<poolie> :)
<beuno> but that can only be done with the new HTML. I'm scared of the current one
<mwhudson> sure
<mwhudson> and we should really be focusing on getting to a releasable state i think now
<mwhudson> there's so many improvements in trunk...
<beuno> yeah, next on my list is do something sensible with setup.py
<beuno> and, well, get the new theme landed  :)
<ferringb> beuno: refering to loggherhead from above, or...
<mwhudson> beuno: so with a little bit of buffering to send ~1k at a time to the browser (rather than ~10 bytes) my torture test completes in 28 seconds
<mwhudson> vs. ~40 on trunk
<beuno> mwhudson, 12 seconds is a *really* big improvement
<mwhudson> yeah, i'm amazed, tbh
<beuno> ferringb, I'm sorry?
<beuno> mwhudson, does it pass the tests?  :p
<ferringb> beuno: "mwhudson, looks very good. We should do some benchmarking before release to compare the improvements, but it sounds like it's going to be a pretty big" ...
<mwhudson> beuno: yes :)
<ferringb> asking if that's in reference to loggerhead (presume it) or something else
<beuno> ferringb, yes, Loggerhead
<mwhudson> at one point it was only transmitting ~1% of the data to the client but that was a simple typo :)
<beuno> hahaha
<beuno> are we still removing whitespaces?
<mwhudson> i feel a bit sad at having to write this though: http://pastebin.ubuntu.com/22785/
<mwhudson> beuno: er
<mwhudson> beuno: probably not
<beuno> mwhudson, well, that gave us big savings on large files, but I'm not sure what the memory/cpu tradeoff was for that
<mwhudson> hm, i can probably do it on the 1k chunks reasonably
<krow> Quick question... what is the command with bzr to remove all files from a directory which are not in source control?
<ferringb> bzr clean-tree
<spiv> bzr clean-tree
<spiv> ferringb: beat me :)
<krow> [brian@piggy drizzle-1.0]$ bzr clean-tree
<krow> bzr: ERROR: unknown command "clean-tree"
<krow> No wonder I did not find it in the help drop down :)
<ferringb> part of bzrtools then
<poolie> is it in bzrtools?
<poolie> you should be able to apt-get install that, or follow the instructions on the plugin page
<poolie> depending on your system
<krow> Fedora, so no apt-get.
<poolie> i think it is packaged
<krow> There is a python tool for grabbing the latest bzr right? I can never remember what it is.
<mwhudson> beuno: seems to still be worth it
<poolie> i think that's ezsetup?
<lifeless> yum on fedora
<lifeless> or apt-get if you install it
<beuno> mwhudson, does it shave off a few more seconds?
<krow> Nah... there is some python tool... I always forget its name... anyways. Thank for the help :)
<mwhudson> no, it takes a little longer
<mwhudson> but makes the page 30% or so smaller for my torture test
<mwhudson> more like 40%
<beuno> yeah, worth it on 24mb pages  :)
<mwhudson> right
<lifeless> hi beuno
<beuno> evening lifeless
<poolie> krow: probably the easiest thing is
<poolie> mkdir -p ~/.bazaar/plugins && bzr branch lp:bzrtools ~/.bazaar/plugins/bzrtools
<beuno> mwhudson, I get 53sec vs 41sec for my big diff in trunk vs streaming. And, more importantly, browsing seems much further
<mwhudson> i haven't dared load up my big one in firefox :)
<mwhudson> but cool
<mwhudson> i mean, still ridiculously, insanely long to wait for a web page
<mwhudson> but progress is progress
<beuno> yeah, it comes up fairly quickly with streaming now, so, if we compare against 1.2, this is light years better
<mwhudson> oh man
<mwhudson> with 1.2 your machine would have fallen over :)
<jamesh> 41 seconds for a web page wasn't so bad 10 years ago
<beuno> ahahah, that can be our tagline for 1.6  :p
<mwhudson> :)
<mwhudson> beuno: ok, https://code.edge.launchpad.net/~mwhudson/loggerhead/streaming is at revno 182 now
<mwhudson> beuno: can you read through the diff and let me know what you think?
<beuno> mwhudson, yeap, pulling now
<mwhudson> i guess things will be messy if an error occurs mid-page render
<mwhudson> not much we can do about that though
<beuno> not really. And that is probably better than nothing at all
<beuno> mwhudson, diff looks good. Stripping whitespace on flush seems like a much better thing to do
<mwhudson> ok to merge?
<beuno> absolutely
<mwhudson> beuno: i see you found the logging bug -- that's a real laugh/cry dilemma
<beuno> mwhudson, hehe, yeah. Poor guy really thought it rotated
<marianom> sorry to bother everyone, just gonna say hi to beuno :)
<beuno> hey marianom!  What are you doing up?
<marianom> I bet you know! :)
<beuno> marianom, :)  let me know if I can help
<marianom> on my way to sleep now. see you tomorrow, beuno (everything's ok btw) good night everyone and keep the good bzr rocking!
 * mwhudson merges & pushes
<mwhudson> ... and stops
<beuno> mwhudson, sounds good
<beuno> btw, did you roll out on LP today?
<beuno> LH on LP is getting worse by the minute. I'm not sure what's been going on
<mwhudson> beuno: erm, tricky question to answer :)
<beuno> ah, is it better at least?
<mwhudson> we should rollout a new loggerhead tomorrow with good luck and a following wind
<beuno> that would be with tg + simpletal I assume?
<mwhudson> there will probably be a general launchpad rollout early next week
<mwhudson> edge has been back and forth repeatedly :)
<mwhudson> beuno: nope, paste
<beuno> yeah, storm issues I hear
<beuno> mwhudson, oh, very cool. Se that will be a good way to iron out any remaining peformance issues  :)   (good for us, don't know about users)
<mwhudson> yeah, i wonder about trying to wedge this latest branch in
<mwhudson> anyway, emma is back from work so really stoppoing now
<beuno> cya tomorrow mwhudson
<Jc2k> lo
<lifeless> i
<lifeless> hi
<beuno> mornin' Jc2k
 * Jc2k yawns
<Jc2k> beuno: i have a feature request :)
<Jc2k> beuno: show the author in loggerhead somehow
<beuno> Jc2k, where specifically?
<Jc2k> this i'm not sure of :)
<Jc2k> i just want to blog about bzr-svn storing the author property, and loggerhead seems like the right thing to show it off
<beuno> Jc2k, LH already shows whatever you specify in --author
<Jc2k> where abouts :O
 * Jc2k to work
<beuno> Jc2k, it shows that instead of the committer
<Peng> Is LH supposed to use any old-style classes?
<beuno> in changelog/revisioview/annotate
<Jc2k> beuno: then bzr-svn must have failed..
<beuno> Peng, not any new ones, no  :)
<beuno> Jc2k, it's fairly new in trunk, do you have the lastest and greatest?
<Peng> beuno: Well, it has 4, and loggerhead/controllers/__init__.py's BufferingWriter is new.
<beuno> Jc2k, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
<beuno> revno 170
<Peng> Hmm, thanks to the whitespace stripping, /changes went from 82 KB to 63, and gzipped it went from like 4.65 to 4.3.
<beuno> Peng, can you file a bug and/or provide a patch for that?  :)
<beuno> (old-style classes)
<Peng> beuno: All of them or just the most recent one?
<beuno> Peng, all of them. We do want to start cleaning up our code base
<lifeless> ok, annotate across stacking boundaries working
<Peng> Crapcrapcrapcrap
<Peng> (Entirely OT, but I just accidentally ran a blanket "commit" instead of one file")
<jml> bzr uncommit?
<Peng> It was with hg, actually.
<Peng> And I pounded ctrl+c and I think I broke my repo a little.
<lifeless> heh
<lifeless> ctrl-c isn't safe?
<Peng> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/trivial/new-style-classes
<Peng> lifeless: I think it was.
<beuno> Peng, you rock!  thanks  :)
<lifeless> Peng: it was safe, or it was not safe?
<Peng> lifeless: If you don't know, when you hg commit, it commits to the live repo. When you hit Ctrl+C, it aborts the transaction and truncates the file changes. But I hit Ctrl+C a bunch of times, and got some "failed to truncate file" messages. But it exited successfully, so hopefully it tried again.
<Peng> BTW, ack rocks. "ack-grep --python 'class [^(]+:'" :)
<lifeless> ack?
<Peng> lifeless: It's like grep, only in Perl, and with colors. http://petdance.com/ack/
<lifeless> ah
<lifeless> apt-cache show ack-grep helped me :)
<Peng> (Eh, seems grep has colors too.)
<Peng> lifeless: Heh, right.
<Peng> I tried it out just for fun. The "--python" thing is fun. (There are arguments for other languages too.) It's a lot shorter than "find . -name '*.py'".
<lifeless> Peng: bzr search class :P
<Peng> Heh.
<Peng> Another nice thing is that it ignores things like *~ files and .bzr and .svn by default.
<spiv> Peng: "grep -Irn foo *" is pretty close :P
 * spiv -> yoga
<poolie> lifeless: ready, call me?
<lifeless> poolie: it rang out
<poolie> huh
<lifeless> twice now
<visik7> I've some problem with the new bzr-svn
<Peng> go on
<visik7> I got this error: http://dpaste.com/58999/
<visik7> with an active bzr-svn branch (branched with an older version of bzr-svn)
<lifeless> Jc2k: ping
<lifeless> Peng: I feel your pain re: data corruption
<lifeless> Peng: is it your mozilla config branch?
<Peng> lifeless: Homedir.
<Peng> lifeless: The branch has already probably had some sort of corruption for months. I think this really may have made it worse though.
<lifeless> Peng: time to try bzr again ? :P
<Peng> Perhaps.
<Peng> I've been liking "hg commit -X" though.
<lifeless> -X?
<lifeless> oh, auto-everything ?
<Peng> exclude
 * igc dinner
<Peng> There's one file I do version, but it changes frequently and I don't need to record each one.
<Peng> Anyway, like I said in #mercurial, I was gonna go to sleep too. Bad things always happen when I'm about to go to sleep. :(
<lifeless> Peng: we should have exclude for diff and commit et al
 * Peng goes to bed.
<Peng> Good night, lifeless.
<lifeless> night Peng :)
<visik7> I got that issue on all my svn-bzr branches
<visik7> ok it's officially dead even with a clean branch
<visik7> svn-bzr doesn't work here anymore
<visik7> for example:  bzr checkout http://google-gadgets-for-linux.googlecode.com/svn/trunk/ gg4l
<lifeless> jelmer: ^
<visik7> it doesn't recognize anymore svn branches
<lifeless> mwhudson: why do you use sqlite2 rather than 3?
<garyvdm> Hi. I'm having a problem pushing to a ftp site.
<garyvdm> I'm getting this error:
<garyvdm> bzr: ERROR: File exists: '/.bzr': 550 /.bzr: Access is denied.
<jelmer> visik7: that works fine here
<jelmer> visik7: when did it break?
<garyvdm> I've checked the .bzr does not exist. So it seems that bzr is interperating the ftp incorrectly
<lifeless> garyvdm: what path are you giving bzr? that leading / suggests its trying to mkdir at the root
<garyvdm> What is the best way to try and fix this?
<gour> eMBee: hi, any luck with bzr-gtk ?
<garyvdm> lifeless: yes - Command used:
<garyvdm> C:\Inetpub\wwwroot>bzr push ftp://usr:pass@www.squarepegs.co.za/ --use-existing-dir
<lifeless> garyvdm: so, I suspect you actually want something like ftp://usr:pass@www.squarepegs.co.za/home/garyvdm/public_html/xxx
<garyvdm> I want to put the branch in the root, but I guess I can put it in a sub folder.
<garyvdm> Let me try that.
<lifeless> garyvdm: the root may not be what you think it is
<lifeless> if you ftp to www.squarepegs.co.za, and do ls / - does it show you your files, or something like 'usr', 'bin', 'lib' etc
<garyvdm> I did check that. The root is the root of the website.
<lifeless> garyvdm: ok, then its likely that the ftpserver has a policy stopping you making .bzr
<visik7> jelmer: today
<jelmer> visik7: still there?
<lifeless> garyvdm: try pushing to /test
<visik7> yes, today
<garyvdm> Ok
<lifeless> garyvdm: if that works, ftp in and mv test/.bzr .bzr
<visik7> jelmer: on revno: 1345
<jelmer> visik7: bzr-svn shows up in "bzr plugins" ?
<visik7> yes
<jelmer> visik7: have you built it?
<visik7> yes
<jelmer> what happens if you prefix the http url with "svn+" ?
<jelmer> e.g svn+http://google-gadgets-for-linux.googlecode.com/svn/trunk/
<visik7> same problem
<visik7>  ERROR: Not a branch: "svn+http://google-gadgets-for-linux.googlecode.com/svn/trunk
<jelmer> anything in ~/.bzr.lo g?
<jelmer> anything in ~/.bzr.log ?
<visik7> yes I'll dpaste it
<visik7> http://dpaste.com/59005/
<mwhudson> lifeless: it's what was installed on vostok at the time i think
<jelmer> visik7: hmm, it should be impossible to get into that situation
<jelmer> train leaves
<jelmer> bye
<visik7> jelmer: I'm a lucky  man :)
<lifeless> mwhudson: I've already given you a patch to upgrade :)
<lifeless> 3 is faster
<visik7> jelmer: so am I tfu ?
<garyvdm> lifeless: I tried that. Unfortunatly it did not work.
<garyvdm> http://pastebin.com/m7f8c0cf9
<garyvdm> From the pastebin you can see, I did a ls to check that /test does not work
<garyvdm> Then I tried to push to /test, and it say /test exists
<garyvdm> Then I tried to put to /test --use-existing-dir - and it says /test does not exits.
<garyvdm> Huh?
<garyvdm> Ok  - time to download wireshark.
<lifeless> oh, microsoft ftp server again
<lifeless> garh
<lifeless> garyvdm: can you try:
<lifeless> "ls /"
<lifeless> just for my peace of mind
<garyvdm> ok
<garyvdm> Ah - ls / gives me a compleatly different list...
<lifeless> I thought it might
<lifeless> do 'pwd'
<garyvdm> "/ftptrudi" is current directory.
<garyvdm> ok push to /ftptrudi
<lifeless> yes
<garyvdm> It's working now. Thanks lifeless.
<lifeless> np
<beuno> lifeless, bug #242035 fixed. Half a bug to go  :)
<ubott2> Launchpad bug 242035 in loggerhead "[search] Javascript for searching isn't included in every page" [Medium,Fix released] https://launchpad.net/bugs/242035
<beuno> (that would be half of #242034)
<beuno> Jc2k, I didn't quite understand where we stand on the --author bit.  Are you using past revision 170?
<lifeless> beuno: cool
<poolie> vila, are you here by any chance?
<Jc2k> beuno: i have r 262 of the branch for loggerhead + bzr search
<lifeless> Jc2k: 'bzr search author'
<Jc2k> eh
<lifeless> Jc2k: it will give you an answer quickly :P
<beuno> Jc2k, ah, so you're using search. Let me integrate the latest changes into it, and I'll push that
<beuno> Jc2k, pushed revno 267
<beuno> has many improvements
<Jc2k> cool
<beuno> speed amongst one of them  (from mwhudson's streaming work)
<Jc2k> whats the URL again? parent isnt set
<beuno> should show authors and such
<lifeless> lp:~bueno/loggerhead/bzr-search_integration
<beuno> Jc2k, not that I'm hurt or anything, but you haven't added the gnome theme on it...  :p
<beuno> I can provide a branch with trunk + search + gnome theme, if that's what you've been waiting for
<Jc2k> that would make be a very happy GNOME beuno
<poolie> lifeless: vf bounced due to conflicts, i'm updating them
<lifeless> poolie: trivial stuff?
<lifeless> Jc2k: so, bugs for gnome
<lifeless> Jc2k: I'll file them I guess as you are busy with new job :)
<Jc2k> eh, awesome. cheers.
<lifeless> Jc2k: but the list - rebase -i; an in-place-branches mode; anything else ?
<poolie> basically just conflicts on the get_data_stream stuff
<Jc2k> crap, i thought of one in bed
<beuno> Jc2k, I'll push that in a minute for ya'
<lifeless> Jc2k: thats the idea, to capture them
<lifeless> bug 242661
<ubott2> Launchpad bug 242661 in bzr "Cherrypick without merge needed" [Undecided,New] https://launchpad.net/bugs/242661
<lifeless> that guy is having a conversation with himself
<Jc2k> lifeless: the stuff that bkor filed, and cleaern urls
<Jc2k> cleaner
<lifeless> needs some response / love :)
<lifeless> bkor: loggerhead changes are all in progress I think; I'm worried about CLI stuff not getting sufficient attention
<james_w> lifeless: hi. I've read it a couple of times, but haven't understood it yet. I thought of asking them to have another stab on the mailing list.
<lifeless> though loom on its own is a pretty good answer to branch lists
<pygi> hi hi
<lifeless> if you ignore 'record, up-thread and down-thread', then you get N branches at one spot with switch between them
<beuno> Jc2k, lp:~beuno/loggerhead/gnome_theme  should make you happier
<Jc2k> that confused me - its changed ports!
<Jc2k> beuno: http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/changes
<lifeless> james_w: I want: a bunch of bugs, in lp, tagged gnome, that if we solve will help address the various things gnome would like
<lifeless> james_w: both the misguided ones, and the good ones like bkor filed on lh
<james_w> lifeless: was that one from a GNOME person?
<beuno> Jc2k, right, I think mwhudson set it back to 8080
<beuno> javascript/css not being added correctly, that's odd...
<Jc2k> yeah..
<beuno> Jc2k, you're running this through apache, right?
<beuno> /static/* dir isn't being exposed
<Jc2k> beuno: nope, mwhudson always told me to just run the serve-branches
<beuno> ah, right, 8080, missed that
<Jc2k> so i should run it with mod_rewrite [P] foo?
<beuno> no, should work out of the box
<AfC> I believe the correct term when it comes to mod_rewrite is "voodoo"
<beuno> Jc2k, branch works fine here:  http://200.127.6.219:8080/changes
<lifeless> Jc2k: was which one ?
<Jc2k> lifeless: ?
<lifeless> Jc2k: sorry, mt
<lifeless> james_w: was which one ?
<james_w> lifeless: I was responding to your comment that 242661 needs some love
<Jc2k> beuno: i just branched the url you gave and ran the serve branches script
<lifeless> james_w: no, I don't think its a gnomer
<beuno> ah, it's doing something weird, by serving the static dir from each branch: http://bzr-mirror.gnome.org:8080/epiphany/trunk/static/javascript/collapse.js
<beuno> Jc2k, right, it's probably our fault. Let me debug this for a bit...
<Jc2k> cheers
<poolie> lifeless: i realize you've finished, so rst this question if you wish
<poolie> but, you've deleted the get_data_stream_for_search and the Fetcher that calls it
<poolie> i'm guessing that should just be carried across in the merge?
<poolie> and then eventually a new form of something similar needs to be written?
<lifeless> poolie: that was my intent yes
<lifeless> poolie: its what I've been saying spiv should be looking into as a priority :P
<beuno> Jc2k, can you try branching trunk and see if the same thing happens?  lp:loggerhead
<beuno> I can't reproduce the problem locally
<poolie> lifeless: yeah i thought so :)
<poolie> easy to resolve
<Jc2k> beuno: http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/changes
<beuno> Jc2k, ok, so it's something from trunk
<Jc2k> are you using the serve-branches.py script? (looks like your using start-logerhead?_
<beuno> Jc2k, I'm not: http://200.127.6.219:8080/
<beuno> or am  :)  (using serve-branches.py)
<Jc2k> lucky git
<beuno> I don't understand why it misplaces the /static/ dir...
<lifeless> poolie: spiv may be unhappy at the recent optimisations being disabled :P
<beuno> Jc2k, this is a linux box it's running??
<beuno> python 2.4 or 2.5?
<poolie> i'll try to help him get them back
<lifeless> beuno: you know you don't need to call load_plugins to load a plugin :)
<lifeless> beuno: you can just 'import bzrlib.plugins.search'
<lifeless> beuno: load_plugins loads /all/ plugins
<beuno> lifeless, I didn't  :)
<Jc2k> beuno: debian etch, python 2.4
<beuno> Jc2k, it works with 2.4 here too...  :/
<beuno> mwhudson, you're not still around and bored, are you/
<poolie> ok i'm going to sign off
<beuno> lifeless, thanks. Pushed revno 268
<beuno> Jc2k, I'm heading to the office, but I'll try and get to it in a while. It shouldn't be placing /static/ dir on each branch's dir
<beuno> it has something to do with mwhudson's voodoo to generate that with serve-branches  :)
<lifeless> beuno: http://bazaar.launchpad.net/~lifeless/loggerhead/search
<thekorn> hi, I'm using the editor feature of bzr commit (running bzr commit opens my editor for me and let me write down my message)
<poolie> lifeless: it landed
<thekorn> is it possible to predefine a a text for the part above the ---bar---
<thekorn> so I have like a default message-body for all my commit-messages
<james_w> hi thekorn
<thekorn> hi james_w!
<james_w> it's possible in bzrlib, but I'm not sure that there is any way to do it.
<lifeless> poolie: woo, the eagle is in!
<lifeless> thekorn: as in a template ?
<thekorn> james_w, ok, I just found the related functions, they are having a lots "TODO"s in __doc__, too bad
<thekorn> lifeless, best thing would be if it could list all my changed files there
<lifeless> thekorn: well, TODO's just reflect bug plans :)
<thekorn> because I'm always starting my messages with the files I changed
<lifeless> interesting
<lifeless> uhm, there might be a plugin already
<lifeless> what I do is use --show-diff
<thekorn> and right now I'm copieing the part under the ---bar---
<lifeless> because I copy various bits of details
<thekorn> and comment on each item
<lifeless> thekorn: could you file a bug? It seems to me doing this would be a nice thing
<thekorn> ok, will do
<thekorn> thanks lifeless, james_w
<lifeless> thekorn: after the bug is filed, if you want to work up a plugin or patch, I'd be happy to make suggestions
<thekorn> lifeless, are there some docs on howto write a plugin somewhere
<vila> poolie: just arrived, but launch break in a few minutes
<lifeless> thekorn: there are some; but not enough :)
<lifeless> thekorn: docs/en/developers/plugins.txt I think is one spot
<lifeless> thekorn: there are using bzrlib thigns on the wiki too
<lifeless> thekorn: but for this, I think a patch to the core is entirely suitable
<vila> poolie: I just read you were about to sign-off though, so maybe in 10/12 hours ;-)
<thekorn> lifeless, ok, cool, I will have a look at the general structure of bzr and bzrlib and try to understand how such a patch could look like
<lifeless> thekorn: In my head is something like a 'template' setting in the config for commits
<james_w> thekorn: I added start_message to get_commit_message for doing exactly this
<lifeless> e.g. %s would mean 'include status', %d would mean 'include diff' etc
<lifeless> thekorn: but we can start with just what you need
<thekorn> ok, cool, I will file a bugreport, think about it a bit, and come here again to discuss this further,
<thekorn> or directly on the bugreport, of course
<lifeless> sure
<lifeless> I'll see it if you discuss there too
<beuno> lifeless, cool, thanks. Mergeing now.
<lifeless> beuno: in my testing it makes a branch with no index work (but get no hits)
<beuno> lifeless, that's exactly the behaviour I want, so it's perfect. I have been puttin it off, so it's great
<lifeless> beuno: it should also do the same if the plugin is missing, but I didn't actually test that
<pypas> bonjour a tous, Il y a t il des francophone sur le channel? (cause my english is too bad :(
<lifeless> beuno: *I* would like it to say what is wrong if there is no index/no bzr-search, but thats not something I know the best way to do offhand
<lifeless> vila: ^ pypas
<beuno> lifeless, I'll test that before pushin. It should return no results because it can search other things (revnos, dates)
<pypas> petite question : puis-je supprimer un repertoire, commiter et au besoin faire un revert pour recreer les fichiers supprimes?
<vila> pypas: oui
<pypas> j'ai essayer la suppression via bzr delete : pas fonctionne puis en supprimant via mon explorateur et pareil, marche pas
<lifeless> beuno: hmm, bzr-search will be growing such searches too; in future perhaps I can change your mind :)
<vila> plus precisemment ?
<pypas> la supression fonctionne mais c'est le revert qui ne recreer pas mes fichiers
<beuno> lifeless, sure, my mind is very changeable
<vila> la suppression par 'bzr rm' ?
<vila> pypas: que dit 'bzr st' avant et apres la suppression ?
<vila> pypas: juste pour etre sur, on parle bien de supprimer des fichiers et/ou des repertoires qui sont deja connus de bzr (i.e. ajoutes et commites)
<pypas> ils sont deja connu et j'ai fait un bzr remove path/vers/mon/rep
<pypas> bzr delete
<beuno> lifeless, works fine without bzr-search installed. Pushed.
<vila> 'bzr delete' c'est quoi ? Quelle version de bzr utilises-tu (bzr version) ?
<pypas> 1.5
<vila> bzr delete
<vila> bzr: ERROR: unknown command "delete"
<pypas> tu es sous ng?
<pypas> moi pas
<pypas> au temps pour moi, c'ets un remove que j'ai fait
<vila> pypas: ouch, tu parles de 'baz' donc, pas de 'bzr'
<vila> pypas: ghaa, 'bzr version' dis quoi ?
<pypas> 1.5
<pypas> merci de ton aide vila mais je dois quitter, ma progeniture se reclame. je repasserais tantot
<pypas> merci encore
<vila> pypas: pareil, a plus
<Sub_Zero> Hey all. I had a (hopefully) easy question about bazaar. Essentially, I want to alias 'bzr reset' to 'bzr revert' and 'bzr clean-tree', but I don't believe bzr aliases support multiple commands. I'm hoping there is an easy way to do this.
<beuno> Sub_Zero, I suppose you could do a bash alias instead
<Kinnison> Are bzr aliases core?
<lifeless> beuno: what else needs going to make the search branch mergable?
<Kinnison> Sub_Zero: I'd be tempted to write a plugin to do it
<Kinnison> Sub_Zero: given the two commands you want to combine take differing arguments
<Sub_Zero> beuno: Yeah, that does work. But I was hoping there would be a little more "integrated" way to do it.
<beuno> lifeless, off the top of my head, just the remaining javascript bit, and looking into what I can/should use of the new streaming feature
<beuno> I suppose we're almost there  :)
<Sub_Zero> Kinnison: I think the plugin is the way to go, but I don't know any phython :(
<beuno> I do want to add some context to the search results, but I don't think it's worth waiting for that
<Kinnison> Sub_Zero: aah
<Kinnison> Sub_Zero: always a bit of an issue, given my other suggestion was going to be to modify the alias plugin :-)
<lifeless> beuno: sounds like 'merge it now' to me :)
<Kinnison> Do it!
<lifeless> beuno: because the streaming thing can be done later; and the remaining javascript bit is not worse that the old search facility
<beuno> lifeless, well, one thing we do need to add, is for the <div> not to show if no results are returned, or search is not enabled
<Sub_Zero> Kinnison: I've been meaning to sit down and get my feet wet in Python, but being mostly ignorant how hard would it be to write a plugin to execute those two commands?
<spiv> lifeless, poolie: well done!
<Kinnison> Sub_Zero: Not *certain* but I wrote commands for bzr reasonably easily, so I'd guess not too hard
<beuno> lifeless, that's the part that's worst then now. If my day isn't too hectic, I can probably get that done before mwhudson wakes up and can review it
<lifeless> beuno: I try to split 'need to' from 'want to'
<lifeless> beuno: if its not worse than the old code in any regard, I look for reasons not to merge, rather than reasons to merge :)
<lifeless> spiv: thanks
<lifeless> spiv: no excuses on looking at the new api now :)
<spiv> lifeless: :)
<spiv> I've *looked* at it...
<spiv> I just need to use it :)
<beuno> lifeless, agreed. I'll make the div behave sanely if bzr-search isn't present or no results are returned, and put up a merge request
<lifeless> spiv: I will be in hornsby at 7am tomorrow for a physio visit
<beuno> ah, thought of one more thing. It doesn't search revnos now. That should be fixed too.
<lifeless> spiv: that will probably finish around 8am; If you wanted to hack together I'm happy to stay around in hornsby for a few hours
<lifeless> beuno: as in '52' ?
<beuno> lifeless, yeap. Which is the only thing that currently works properly  :)
<spiv> lifeless: I'm tempted, but my flat looks embarrasingly like a bomb site at the moment.
<spiv> (Even more than usual)
<lifeless> spiv: so you've cloned my house?
<spiv> Worse :)
<lifeless> spiv: we could sit at $pie_shop, drink caffeine and eat pie
<lifeless> spiv: or I can just head home during rush hours
<spiv> There's no decent pie shop anymore, but I'm sure we can manage something.
<lifeless> spiv: how about - I give you a ring around 8:30, that should be close enough to civilised given the 9am stand-up; and I'll be esconced somewhere westfieldy
<lifeless> spiv: and we can discuss go/nogo/details then ?
<spiv> lifeless: works for me
<lifeless> kk will do then
<poolie> vila, i am signing off now, will mail you or try to catch you tomorrow
<AfC> spiv, lifeless: it's too bad you're talking about Hornsby. I've been meaning to have you two over for lunch but with Robert fleeing the country I guess we're out of time. Andrew, the invitation is open.
<spiv> AfC: we should definitely arrange something on your side of the harbour one day
<vila> poolie: ok, no problem (just coming back from launch :)
<vila> beuno: ping
<beuno> vila, pong
<beuno> I owe you a reply
<beuno> I'm way behind on replies  :(
<vila> beuno: did you give a try to bzr-upload with the chmod bit handling ? Are you happy with it or do we need more ?
<vila> beuno: given that ftp doesn't work yet
<beuno> vila, I haven't gotten around to testing it yet. I'll stick it into my main server today and see if anyone complains  :p
<beuno> (and, well, eventually do real testing)
<beuno> past few days have been very crazy
<vila> beuno: ok, I have a patch for bzrlib to make ftp support chmod, I still need to test it against a real server
<vila> beuno: ok, no problem, I was unsure about taking your last reply as valid for my mail bombing or if I should be waiting for mor replies ;)
<beuno> vila, if you need an ftp/sftp server to test against, let me know, I'll set up an account for you on one of my webservers
<vila> beuno: thanks for the offer, but I'm close to have one test server available using te local-test-server plugin so I will quickly be in position to test against any ftp server I can install on Ubuntu
<lifeless> AfC: I have another week; and would like to do something
<lifeless> AfC: I've been unwell recently; I'm starting to feel human again
<AfC> lifeless: sooner rather than later would work well, actually
<lifeless> AfC: are you GUADECing?
<AfC> lifeless: no
<Sigma> hi. I've got a little problem. "bzr push" says bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<Sigma> on the other and, "bzr merge" says "Nothing to do." :-)
<Sigma> s/and/hand/
<Sigma> any idea is welcome :-p
<beuno> Sigma, maybe your push location is different than your merge location?
<spiv> Sigma: I think bueno is right.  Check the "bzr info" output.
<Sigma> hmm actually they are, but, the source of merge should be up-to-date with my push location. let me check :)
<Sigma> I'm merging from launchpad/http and pushing to launchpad/sftp
<beuno> Sigma, try "bzr missing"
<beuno> and see what that says
<Sigma> it says I have 1 extra revision
<beuno> Sigma, maybe try pushing and specifying the URL. It may be pushing somewhere else
<pypas> |/commands|
<Sigma> I've got this error when merging : bzr: ERROR: Revision {yann.hodique@gmail.com-20080601233200-8sufw6rintulemn6} not present in "KnitVersionedFile(sftp://yann-hodique@bazaar.launchpad.net/%7Eyann-hodique/%2Bjunk/dotemacs/.bzr/repository/knits/f4/195%408a708873-67e9-0310-be3a-b2333ca284a8%253atrunk%253alib%25252%2546icomplete%25252%2542.el)".
<beuno> ah, that doesn't look good
<beuno> you're using knits for starters. What version of bzr are you using?
<Sigma> 1.5, but this message relates to the storage in launchpad, no ?
<beuno> yeah
<beuno> it may be bug #205156
<ubottu> Launchpad bug 205156 in bzr "KnitRepository.insert_data_stream() copies data in improper order" [Critical,Triaged] https://launchpad.net/bugs/205156
<Sigma> hmm
<beuno> https://code.edge.launchpad.net/~yann-hodique/+junk/dotemacs/
<beuno> Sigma, you have the full repository locally?
<beuno> you can probably to push --overwrite to fix that
<beuno> and, I'd recommend upgrading the storage format with (but after we fix this)
<Sigma> yes, I can overwrite, I'll try that
<beuno> Sigma, that sould fix it, and, after that, I'd recommend doing:  bzr upgrade && bzr reconcile
<beuno> both locally and remotely
<beuno> (it may take a while to do it on LP)
<Sigma> but locally I'm already at the latest format
<Sigma> ah ok
<beuno> and, it's *much* faster if you use bzr+ssh instead of sftp
<beuno> Sigma, if you branched off LP, it probably brought in knits format
<Sigma> Standalone tree (format: pack-0.92)
<beuno> cool
<beuno> then, push --overwrite
<beuno> and upgrade afterwards
<beuno> shouldn't happen every again with packs  :)
<Sigma> ok thanks
<Sigma> btw, when I re-branch from LP, I get Standalone tree (format: dirstate)
<poolie> guilhem, https://answers.launchpad.net/bzr/+question/37308
<poolie> guilhembi: ^^
<beuno> Sigma, right. You must of upgraded at some point, or used a shared repository. Upgrade in LP and it should all go away
<poolie> this is the person -> https://edge.launchpad.net/~xuekun-hu
<Sigma> beuno: how am I supposed to upgrade on LP ? a simple "bzr upgrade bzr+ssh://yann-hodique@bazaar.launchpad.net/~yann-hodique/+junk/dotemacs/" doesn't seem to do the job
<beuno> Sigma, ironically, for upgrades you need sftp
<Sigma> I see :)
<beuno> but, for the rest, bzr+ssh is much faster
<beuno> morning jam
<jam> 'morning beuno
<LeoNerd> I find it's a tough call sometimes between sftp and bzr+ssh
<LeoNerd> At home, I have a fast 100Mbit network to a slow server... sftp becomes faster, even though it has mmore network overhead, just because it's lighter on server CPU load.
<Sigma> since it's taking ages, I suppose it's working :) thanks a lot
<beuno> Sigma, you're welcome
<poolie> Sigma: do you get an error over ssh?
<guilhembi> jam: hi! Posted some test results of your latest bzr branch; and also: ha_ndbcluster.cc "false conflicts" is the most burning issue I believe
<poolie> if you're going from knits to packs it will take a while
<poolie> statik: can we talk briefly?
<Sigma> poolie: bzr+ssh gives me "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." which is quite confusing :)
<poolie> hm ok
<poolie> could you file a bug please?
<Sigma> yep, will do
<GaryvdM> Hi. I'm having a problem branching a branch. I'm getting this error:
<GaryvdM> C:\Inetpub\wwwroot\squarepegs>bzr pull http://www.squarepegs.co.za/
<GaryvdM> bzr: ERROR: No such file: 'http://www.squarepegs.co.za/.bzr/repository/indices/e07e8982d90a74ddd63781f8e3fb20a7.rix'
<GaryvdM> The branch was pushed with bzr 1.5 , and I'm an trying to branch it with a copy of bzr.dev
<Sigma> hmm, the upgrade finally failed :/
<Odd_Bloke> GaryvdM: Can you check if the file actually exists via non-HTTP means?
<GaryvdM> Ok
<beuno> Sigma, with what error?
<Sigma> same as before : bzr: ERROR: Revision {yann.hodique@gmail.com-20080601233200-8sufw6rintulemn6} not present in "KnitVersionedFile(sftp://yann-hodique@bazaar.launchpad.net/%7Eyann-hodique/%2Bjunk/dotemacs/.bzr/repository.backup/knits/f4/195%408a708873-67e9-0310-be3a-b2333ca284a8%253atrunk%253alib%25252%2546icomplete%25252%2542.el)".
<beuno> Sigma, and you already did push --overwrite?
<Sigma> yes
<beuno> hmr
<beuno> jam, any idea on how to fix that  ^
<beuno> it looks like bug #205156
<ubottu> Launchpad bug 205156 in bzr "KnitRepository.insert_data_stream() copies data in improper order" [Critical,Triaged] https://launchpad.net/bugs/205156
<GaryvdM> Odd_Bloke: hmmm - it's working via ftp. But not accessible through http. I think my host has changed something.
<GaryvdM> Thanks
<Odd_Bloke> GaryvdM: Yeah, that's probably a permissions issue.
<jam> beuno, Sigma: Is this happening during a bzr upgrade? (Since otherwise I don't know why it would trigger in "repository.backup".
<Sigma> beuno: btw, it looks like my LP repository is now broken : Branched 0 revision(s). :/
<Sigma> jam: yep
<jam> I *believe* the appropriate answer is that you need to upgrade with <= 1.5 (maybe 1.4) and then do "bzr reconcile" with that version
<jam> and then it will work with bzr.dev
<jam> The old fetch code could handle missing data
<jam> the new stuff can't
<jam> so if you have missing stuff, you need to upgrade with the old code first
<jam> and reconcile to fill in appropriately.
<jam> At least, that would be my 1-min recommendation.
<Sigma> jam: sorry, I was not able to test it. the LP branch was not usable anymore after broken upgrade. I had to delete/recreate it. Thanks anyway :)
<jam> Sigma: well, you probably just needed to mv .bzr/repository.backup .bzr/repository, but as long as you are back to functioning
<Sigma> yep. it looks like there is room for a feature in LP to upgrade formats via the web interface
<beuno> yes, and probably a warning when the repo is in an old format
<LarstiQ> beuno: do consider older clients
<beuno> LarstiQ, well, it's just a warning, not a death threat  :)
<beuno> it seems the bug requesting it was already filed as #179035
<beuno> most users don't even know they're using knits, so informing them may push more upgrades
<beuno> (in fact, Loggerhead was using knits until recently)
<Verterok> moin
<beuno> howdy Verterok
<Verterok> beuno: morinin'
 * Verterok still sleepy
<beuno> Verterok, I woke up at 3am, so I'm...  odd
<beuno> went to sleep at 5pm, so I guess it's ok, but still, odd  :)
<Verterok> beuno: good timing to work with the australian folks ;)
<beuno> actually, british folks, but yes, that worked out good too
<Verterok> beuno: right, (remember I'm still sleepy :-D)
<beuno> hahaha
<abentley> Verterok: I don't know if you saw, but I got the main BB instance onto Postgres this morning.
<beuno> abentley, it seems much faster to me now. Especially when loading the merge requests
<Verterok> abentley:  reading the mail ATM. yay!! :D
<abentley> beuno: I'm not noticing a great improvement, but for me it's about thread-safety and easier schema migration.
<beuno> right, having it not hang frequently will be good
<abentley> Verterok: The gotcha I encountered was that the sequences for the primary keys weren't set properly.
<abentley> So it would try to re-use ids that had already been used.
<Verterok> abentley: I was about to asking if you find glitches with the scripts
<abentley> Verterok: The main thing was just figuring out all the stuff outside the scripts-- creating the user, creating the db, creating the tables.
<abentley> And some server configuration stuff too.
<nandersson> Verterok: I'm just curious. Is your bzreclipse-plugin ready for Eclipse 3.4?
<Verterok> abentley: I see, about the ids, I'll search if I can force the reuse using sqlalchemy
<Verterok> abentley: regarding the configuration part, I can extend the README and add some guidelines about server configs, etc
<matkor> was fix "division by zero" fix commited to bzr-gtk trunk ? I got such impression but still having problem with comiting / updating ...
<abentley> Verterok: Also, you didn't do pkg_resources.require, so it didn't find the right versions of some packages.
<abentley> Verterok: I've merged your changes into trunk, and included written a script that does most of it.
<abentley> The other glitch was that I had one listing that displayed items in database-insertion-order.
<abentley> And suddenly, that order changed.
<Verterok> abentley: ups, I'll start fixing the first issues
<Verterok> about the ordering, I don't quite fully understand
<Verterok> nandersson: it should work
<Verterok> nandersson: I didn't test it, but it *should* work :)
<nandersson> Verterok: Thumbs up! I'm looking forward to try it out. Excellent job :)
<abentley> Verterok: Instead of sorting by date, I sorted by database-insertion-order.
<abentley> But in the migrated version, database insertion order doesn't match the original, and doesn't correlate with date.
<abentley> So I changed it to sort by date.
<Verterok> abentley: ah, ok
<nelson> Does Bazaar really find lost socks?  Can it find lost gloves, too?
<Verterok> abentley: I'll keep working on my branch to fix those issues, I'll send you a merge request when I'm done
<abentley> Verterok: I suggest merging from trunk, since I did tweak a few things.
<Verterok> abentley: ok, I'll :)
<nelson> Do CVS ''tags'' become Bazaar ''branches''  in principle?
<guilhembi> jam: hi! Don't know if this reached you: I posted some test results of your latest bzr branch; and also: ha_ndbcluster.cc "false conflicts" is the most burning issue I believe
<jam> guilhembi: yeah, I saw that, are you done for the night?
<guilhembi> jam: ahah yes, I woke up a while ago :)
<jam> guilhembi: yeah, timezones can be a pain. Anyway, hopefully I'll have something you'll like when you wake up.
<jam> I can't guarantee that the false conflicts are actually false
<guilhembi> jam: if they are correct (which would be a pain), we'll need super-detailed explanations:
<guilhembi> "this revision id changed this line from X to Y, and that revision id changed X to Z, and A was merged into B", etc.
<guilhembi> Otherwise people will just do the gannotate analysis that I do and not understand why bzr conflicts.
<guilhembi> and complain it's a bzr bug, and the sky will fall down or almost :)
<guilhembi> That is, most people at MySQL are on the line of: "if it was already merged I should not see it again".
<jam> guilhembi: well, we might need to add a "--ignore-the-fact-that-people-actually-disagreed-here" flag for you
<guilhembi> :)))
<guilhembi> jam: of course, if you can educate us, it's valuable. We're just users of RCS software, we can learn.
<guilhembi> bbl.
<mkanat> Is there any way to see the actual commits made against this branch that weren't against an ancestor?
<mkanat> Or even bundle them (that would be ideal)?
<mkanat> Hey, that's great about MySQL! :-)
<jam> mkanat: "bzr send ../ancestor" should create a bundle against that ancestor
<jam> "bzr diff -r ancestor:../branch"
<jam> or
<jam> bzr missing?
<mkanat> jam: I'll try send.
<mkanat> I'm porting a bunch of customizations from one branch to another, and I'd like to do them as their own commits.
<jam> mkanat: you should be able to use "-o" if you want to put the output in a file "-o-" puts it to stndout
<jam> mkanat: "bzr merge ../other/branch -r X..Y; bzr revert --forget-merges; bzr commit ?"
<mkanat> jam: The customizations aren't a sequential series of commits.
<mkanat> jam: Send seems to do it. :-)
<jam> mkanat: hence the 'x..y'
<jam> but whatever works for you
<mkanat> jam: Are those a literal X and Y?
<jam> mkanat: no, numbers
<mkanat> That's what I figured.
<mkanat> Yeah, send is easier.
<jam> so you can select what patches you want included
<asabil> anyone ever took a look at accurev UI for cherry picking and merging changesets from a branch to another ?
<asabil> I think it would be really neat to have the same kind of tool in bzr-gtk
<beuno> asabil, would you happen to have screenshots of that?  :)
<asabil> 1 minute
<asabil> let me find it again
<mkanat> jam: Yeah, that makes sense.
<asabil> beuno: http://www.accurev.com/images/screenshots/4.6/streambrowser.png
<asabil> basically you can drag and drop stuff :)
<beuno> asabil, ah, so you would drop revisions into another branch?
<asabil> beuno: that's what I think can be done for bzr
<beuno> asabil, could you file a detailed bug for it?  Sounds like a good idea, and I'd hate to loose it
<asabil> beuno: if you don't mind flash: http://www.accurev.com/virtualbooth/2min-demo/2min-demo.html
<asabil> beuno: I will try to do that later
<beuno> asabil, thanks. That really looks very nice
<asabil> :)
<sabdfl> seems we've regressed on status performance
<jam> guilhembi: if you are still around, could you check which bzr you used to  do 'gannotate'?
<jam> If you used "bzr.dev" can you try my custom bzr? It annotates slightly differently and *might* provide a different insight
<quicksilver> vila: ping?
<quicksilver> anyone uses dvc/emacs with bzr?
<vila> quicksilver: pong
<quicksilver> vila: you ever use emerge to resolve conflicts?
<quicksilver> I have before.
<quicksilver> I'm sure there was a way to run it on a dvc-conflict
<quicksilver> btu I can't find it now
<vila> I use smerge, it's triggered by just opening a file which contains conflict markers
<quicksilver> ah yes
<quicksilver> smerge-ediff will launch emerge :)
<vila> once the conflicts are resolved, don't forget M-x dvc-resolved
 * quicksilver nods
<vila> quicksilver: yup, but I find it less clear now that I'm used to read diffs... go figure
<quicksilver> I'm happy reading diffs for simple stuff
<quicksilver> for some complex conflicts a side-by-side view is nice
<vila> Yup,  but I rarely encounter really complex ones... In the worst cases, I'm happy to hack the most close version at hand
<vila> .. without using two/three buffers screen estate :)
<gour> vila, quicksilver: so DVC is useful with bzr?
<vila> gour: sure
 * vila thinks I *really* should update the wiki about my usage :-/
<vila> gour: the most useful command is: dvc-diff
<gour> it would be nice
<gour> DVC docs is *cough* a bit...
<vila> it presents you a buffer containing, roughly, the output of 'bzr st' and 'bzr diff'
<vila> from there, on any line, doing C-c C-c jumps to the modified line in the file itself
<vila> so, hack, hack, hack, where am I: dvc-diff, Oh I see, let's go back to that part, hack hack
<gour> :-)
<vila> since my workflow includes reviewing before commit, it just flows naturally and allows me to fix details with just one keystroke
<dato> hm, that's indeed nice
<jam> vila: well, technically 2 keystrokes
<jam> Unless your C-c C-c is different from mine :)
<gour> cool, cool. i used to use darcsum when working with darcs 'cause DVC support for it is not the best. now, i believe DVC is tool-of-choice for emacs & bzr
<vila> jam: :-) I tend to call any emacs command shortcut a keystroke, even if I should type 3 our 4 chrods :)
<vila> chords ?
<jam> most likely chords
<jam> chrod sounds like a unix command
<vila> Escape Meta Alternate Control Shift ftw :)
<vila> you mean chroad which is a well know alias for bzr branch
<vila> s/know/known/ damn typos ruining jokes !
<dato> heh, chroad
<quicksilver> yes, DVC is very useful
<quicksilver> C-x V L and C-x V = and C-x V c ftw!
<quicksilver> what does "M*" mean
<quicksilver> in the output of update/pull ?
<vila> modified and x bit modified ?
<vila> quicksilver: wow, C-x V L .... never used that one :) I guess I've been bzr viz infected :)
<quicksilver> C-x V L is annoying because it's the abbreviated log
<quicksilver> I never want to see the abbreviated log
<quicksilver> merge messages matter
<quicksilver> but it's useful because you can hit "=" on any revision
<quicksilver> and see the local diff
<vila> can you limit it somehow ? I tried C-1 C-2 C-x  V L but it still display the whole log
<quicksilver> if you can't I don't know how to :)
<vila> quicksilver: yeah, '=' is double-click in bzr viz
<vila> but I think there is a plan to display it in the same window with a single click
<beuno> how do I specify a different port for bzr+ssh?
<dato> bzr+ssh://host:port/path does not work?
<beuno> dato, it does, thanks   :)
<dato> .ssh/config is also handy for that
<dato> np
<bobesponja> hi
<bobesponja> is there a ruby lib to interface with bzr?
<jelmer> I think somebody was working on one
<LeoNerd> bzrlib is in python, but maybe ruby can use a simimlar trick to perl, and embed a python 'terp?
<LeoNerd> I've been playing with using bzrlib from perl using Inline::Python lately.. it's quite fun :)
<beuno> bobesponja, or, you can use the xmloutput plugin to get data from bzr
<bobesponja> ok, thanks for the info
<bobesponja> LeoNerd: what's a python 'terp? :)
<LeoNerd> "interpreter" for people like me who often mistype long words
<bobesponja> ok
<LeoNerd> Inline::Python is a perl module that pulls in libpython, and marshalls data between perl and python representations..
<fullermd> Hm.  Does that actually work well?
<LeoNerd> This makes it very easy to use python libraries from perl. Something similar may exist for ruby
<LeoNerd> Ish...
<LeoNerd> One thing it doesn't do ((yet)) is object attributes.
<LeoNerd> Which is kinda essential to using bzrlib, since I notice various things use it
<LeoNerd> So where python could just use   revision.repository   I have to   getattr(revision, 'repository')
<james_w> someone's adopted bazaar in Debian, so it looks like it's not going to be removed from lenny.
<LeoNerd> That being the 'baz' implementation of TLA, yes..?
<beuno> james_w, and the FTBS?
<james_w> fixed apparently
<james_w> LeoNerd: yup
<beuno> james_w, so now we have to pursuade that fellow to do the transition...
<james_w> ah to "baz" package name?
<beuno> yes
<dato> james_w: who adopted it?
<beuno> and make that trickle down to Intrepid
<james_w> beuno: it's gone in Ubuntu.
<beuno> james_w, I know, but lifeless wanted it so baz -> bzr repos could be migrated
<beuno> AFAIK, removing it was a temporary thing
<james_w> beuno: the failure we saw was apparently due to "dash". A lot easier than we thought, but there were apparently other problems.
<beuno> james_w, really?  Argh, we spent quite a while on it...
<beuno> it would be cool to be able to do the transition
<james_w> I'm going to send a mail to the bug report now.
<beuno> thanks  :)
<bobesponja> http://rubyforge.org/projects/bzrwrapper/
<bobesponja> 	0.1  	August 24, 2007
<dpm> I've published a branch of an upstream project hosted at launchpad on my personal Launchpad page. The way I've been working is doing commits on my working copy and then pushing them to my LP branch. Now upstream has merged my changes and has made some new ones. What's the correct way to get the latest upstream changes now? 'bzr update' fetches the changes from my personal LP branch, not upstream. I've been using git in the past, which stores a refer
<dpm> ence to the remote repo which was initially cloned. Is there something similar on bzr, or do I have to explicitly give the upstream branch as in 'bzr merge lp:upstream'?
<james_w> dpm: yup, but then you will only have to give the  url to "merge" once
<james_w> it only stores a single URL though, so if you regularly merge from two different places it's a bit annoying.
<dpm> ok, I understand. Thanks
<jam> abentley: a couple questions if you have time? I seem to be getting "foo.OTHER" rather than "conflict adding foo, moving existing foo => foo.moved". I'm probably doing something wrong, but if you have a hint as to what?
<abentley> jam: Give me a few minutes.
<jam> np
<jjcroftiv> Hello - I am new to bazaar and have been using it for about a week.  So now I have a local repository with a number of revisions, and I a want to move this to a central server.  Can I simply tar up the whole repository, move it to the server, and continue to use it from there, or is there some other action required? TIA
<beuno> jjcroftiv, tar and movinf is perfectly acceptable
<beuno> you can push it to the remote location too
<jjcroftiv> bueno, thanks for the response:)
<abentley> jam: back.  I was implementing path_content_summary on TT, and it's not as simple as you might think.
<abentley> We seem to have got switched around.  I work on the APIs you added to Tree, and you work on merge.
<jam> :)
<jam> So I *think* what is happening is that the same file/directory got added by two different branches
<jam> so when you merge them together, you get a path conflict
<jam> and one of them gets .moved out of the way
<jam> abentley: I'm trying to figure out why I would be getting a bath of "foo.OTHER" instead of a conflict and "foo.moved".
<jam> Would you get that if it looked like a rename instead of an add?
<abentley> are both foo and foo.OTHER versioned?
<jam> abentley: after the merge, yes
<jam> +N  .bzr-mysql.OTHER/
<jam> +N  .bzr-mysql.OTHER/default.conf.OTHER
<jam> ^- my code
<jam> v- bzr.dev
<jam> +N  .bzr-mysql/
<jam> +N  .bzr-mysql/default.conf
<jam> R   .bzr-mysql/ => .bzr-mysql.moved/
<abentley> Oh.  I thought you were talking about bzr.dev the whole time.
<abentley> using OTHER suggests it's happening in the merge code, not the filesystem conflict resolution.
<jam> abentley: oh, and I'm cheating a bit about the criss-cross merge stuff. http://paste.ubuntu.com/22937/
<abentley> If you have two files with the same name in your transform, and you do the conflict resolution, you'll get the .merged.
<jam> abentley: you mean .moved
<jam> But why would I be getting .OTHER ?
<abentley> Yes.
<abentley> Not sure yet.
<jam> I believe some part of my code is wrong (earlier I was running into "no final name for XXX" a bit)
<jam> some of that turned out to be using something other than None to represent not there.
<jam> some of it was getting the ordering of from => to wrong in iter changes
<abentley> so I think foo.OTHER can be created if THIS deletes foo and OTHER creates it.
<abentley> No, if OTHER keeps it.
<jam> abentley: OTHER merges THIS and resolves it as a keep?
<abentley> Is this being listed as a contents conflict?
<jam> abentley: yes contents conflict
<jam> Now, it may be because of base selection
<jam> why I'm getting .moved rather than .OTHER
<jam> um, vice versa
<jam> I'm now getting .OTHER because of a closer base
<jam> oh... it could also be because of what I posted about the "cheating" and how I'm handling None in the bases.
<abentley> Yeah, if BASE has the file, THIS doesn't, and OTHER changed it, then you might get foo.OTHER.
<abentley> Then if THIS added a new foo, you'd get foo and foo.OTHER.
<abentley> jam: The logic is in merge_contents@778
<jam> abentley: the "contents_conflict()" section?
<jam> abentley: ahh, I think I'm also screwing with it in a different way
<jam> You have:
<abentley> jam well, that doesn't decide to emit the conflict.
<abentley> It just implements it.
<jam> if this_pair == base_pair: elif this_pair == 'file' and other_pair[0]' == 'file'. else contents_conflict()
<abentley> jam, right.
<jam> and I'm adding if not self._is_criss_cross  and this_pair == base_pair
<jam> though I don't think that specifically would be the problem
<abentley> It sounds like this may not be a bug.
<jam> abentley: maybe, though it doesn't help the mysql guys...
<jam> though guilhem may not realize that the alternative was to create a .moved
<abentley> If you've got a non-None base.
<guilhembi> jam: you want me to retry annotate or gannotate? I could do diff between  "bzr annotate sql/ha_ndbcluster.cc" with bzr.dev and your bzr?
<jam> guilhembi: that would probably be interesting, (welcome back, btw)
<jam> it can be on the same merge
<jam> just do the annotate between the two
 * guilhembi starts that; results in 2*5 minutes
<jam> guilhembi: I'm surprised it is that slow for you
<jam> it is about 2min here
<guilhembi> uh
<jam> guilhembi: oh, you might also do "bzr annotate --show-ids"
<jam> that will help a bit
<jam> it uses revision-ids rather than trying to work out "nice" values for it
<jam> but they have about as much info
<guilhembi> jam: Intel(R) Core(TM)2 CPU         T7400  @ 2.16GHz 2GB RAM opensuse 10.2
<guilhembi> (laptop)
<jam> guilhembi: laptop here as well
<jam> T7500 @ 2.2GHz, 2GB
<jam> It might be the number of pack files in your repo
<jam> $ time bzr annotate --show-ids sql/ha_ndbcluster.cc >/dev/null
<jam> real    0m19.441s
<guilhembi> I use a shared repo, have several MySQL branches. But all of them are more or less included (as far as revision history) is concerned in 6.0-ndb, which is a recent branch.
<jam> guilhembi: as you do commits, we create new pack files. Occasionally we autopack them together into larger ones
<jam> having 1 large one is a lot faster than 20 small ones
<jam> (at the moment our index code isn't scaling correctly with the number of packs, it should be log(N) at most, but it seems closer to N)
<guilhembi> ahah, so one could write a plugin which forces a pack?
<jam> guilhembi: just run 'bzr pack'
<guilhembi> wah wah
<jam> We expose it as a command
<jam> we *want* to fix the problem, but it is a decent workaround for the moment
<jam> guilhembi: however, I'm trying to work out if my tree is properly treating that file
<jam> but 20s is vastly different than 5 min
<guilhembi> ok, I do a pack...
<jam> guilhembi: before you do, just do "ls .bzr/repository/packs | wc -l"
<guilhembi> too late
<jam> or you can do it while it is processing
<jam> it won't change until it is done
<guilhembi> jam: output is : 52
<guilhembi> (ran this in shared repo)
<jam> guilhembi: yeah.... that's pretty bad
<guilhembi> jam: that's a lot you mean?
<jam> I start noticing around 10+
<guilhembi> ahah
<jam> it is probably valid for the mysql tree and how many revisions you have
<jam> but a pack should help quite a bit
<guilhembi> maybe I should send this advice to my colleagues who have slow gannotate.
<jam> guilhembi: well, try it first :)
<jam> just to give a bit of info, as a trade off between number of packs and how often we have to autopack, the code uses the 'digits' to figure out the pack layout. So if you have 53,281 revisions , then it tries to create 5 10,000 entry packs, 3 1,000 entry packs, 2, 100 entry, 8 10, and 1, 1.
<guilhembi> I ran "bzr pack" in a 6.0 branch, took 5 mins, and now I am down to 40 packs.
<jam> In my mysql-repo, I see 61266 => 21
<guilhembi> I should run this in shared repo directly, maybe
<jam> guilhembi: can you do
<jam> guilhembi: shouldn't matter, lets check something else
<jam> grep -a "len" .bzr/repository/pack-names
<jam> That is the "official" count
<guilhembi> len=1
<jam> there *can* be files present which aren't referenced
<guilhembi> ok, so official count is 1, I start annotate
<jam> guilhembi: so there are some "cruft" files that won't be used, if you want you could get rid of them
<jam> I'm a bit surprised it is that high
<guilhembi> bah, if they won't be used, they just take up space... no time...
<jam> guilhembi: sure, it is just easier to remember the "ls" rather than the grep command :)
<guilhembi> jam: to get rid of them, what shall I do (won't do it right now) ?
<jam> cat .bzr/repository/pack-names
<jam> At the end is the list of files that are being referenced
<jam> rm the others
<jam> you may also want to clean them out of .bzr/repository/indices
<jam> Note that they are called "<name>.pack" on disk, and just <name> in that file.
<guilhembi> mmm so somebody could write a plugin which does "bzr pack" + the procedure which you suggest...
<jam> and there are NULLs in the file, but I don't expect that to cause you problems
<jam> guilhembi: sure
<jam> and if you did that, it would probably also want to delete the files in .bzr/repository/obsolete-packs so they are truly gone
<jam> probably after doing "sync"
<guilhembi> jam: Noted. Does it matter to "bzr pack" in one branch of the repo, or in the repo directly?
<jam> to make sure you don't delete the last copy before the OS has a chance to write it out
<jam> guilhembi: in a branch will pack the repo
<jam> no difference
<guilhembi> jam: not sure I get the relevance of "sync" here, but no big deal
<jam> guilhembi: you want to tell the OS to write out the new .pack file to disk, before you delete the old pack files
<jam> that is why we move them to 'obsolete-packs' rather than deleting them right away
<jam> in case you lose power inbetween claiming the new .pack and getting rid of the old one
<jam> OS don't always serialize actions the way we would prefer
<jam> even sync isn't a 100% guarantee, but it is *better* than not doing it
<guilhembi> jam: now I understand (interestingly, I have coded log recovery in a storage engine of MySQL, so this rings a bell now :)
<jam> guilhembi: right, you write out the "next" stuff, write out  what you are going to , sync, and then start doing it.
<guilhembi> So, first annotate finished, real 3m13
<jam> guilhembi: I'm a bit surprised... is that with '--show-ids', with 'annotate' or 'gannotate' and bzr.dev or my bzr
<guilhembi>  show-ids, annotate, your bzr; running with bzr.dev now
<guilhembi> real    0m20.485s
<guilhembi> wow
<guilhembi> this 20s was show-ids, annotate, bzr.dev.
<jam> guilhembi: try again with my bzr
<jam> oh, you know what
<jam> You didn't run "make" in my code, did you?
<jam> You don't have the compiled "diff" extension
<lifeless> moin
<jam> moin lifeless, go back to sleep :)
<guilhembi> jam: man, no; I branched your branch, and bent the symlink I use, and off I go
<jam> guilhembi: right, so go into that dir and run "make"
<jam> It should make annotate quite a bit faster
<NfNitLoop> what's that compile to?  .pyc? or is it C/C++?
<NfNitLoop> (sorry, eavesdropping)  : )
<jam> NfNitLoop: there is some Pyrex code which compiles to C => .obj
<NfNitLoop> Ah.
<jam> Pyrex being an intermediate between Python and C, (such that it has types, and can be "compiled" to raw C code to be compiled)
<NfNitLoop> Cool.
<guilhembi> grmbl it's not mentioned in the INSTALL file, neither in "Run from source directory" in http://bazaar-vcs.org/InstallationFaq which is what I followed
<NfNitLoop> See, I just hang out in here and learn through osmosis.  : )
<jam> Though technically, the "diff" code is just plain C formatted to become a python extension. There are *other* things we do in pyrex extensions
<jam> guilhembi: well, they aren't *needed* just recommended, but I'll update that page
<guilhembi> jam: thanks; is "make" automatically done for people who use "python setup.py blah" ?
<jam> guilhembi: The "Run from source directory" has a "% make" step
<jam> guilhembi: yes
<guilhembi> I'm trying to see how many colleagues would benefit from that...
<guilhembi> jam: indeed, I'm really blind
<guilhembi> jam: and now it's 20 secs for your bzr too.
<guilhembi> So, the annotate outputs have 266 different lines...
<jam> good to hear
<jam> guilhembi: well, "bzr annotate foo" doesn't actually annotate the working copy either ... :(, unlike gannotate
<mwhudson> morning
<guilhembi> jam: you wanted me to annotate the working copy? I used the clean 6.0-ndb file.
<jam> guilhembi: well, we are trying to figure out why we are seeing this conflict, right?
<lifeless> jam: physio appointment
<jam> if you want to take me through how *you* do it
<lifeless> jam: though I'd love to go back to sleep, I can't
<jam> that may be enlightening
<jam> sorry to hear that lifeless, sleep afterwards then :)
<jam> speaking of which, what are you doing up guilhem?
<guilhembi> jam: it's only 22:14 here and I'm talking with a bzr dev to try to find out what's going on in a damn file merge
<jam> silly man
<guilhembi> yes
<guilhembi> sure, I'll need to sleep, or waking up for kids' breakfast will be tough
<guilhembi> jam: so, I have now gannotate ha_ndbcluster.cc, with your bzr, under the eyes.
<guilhembi> let's look at a conflict which I prententiously claimed to be false...
<guilhembi> line 9836
<guilhembi> jam: I look and look again, but all lines in MERGE-SOURCE in conflict starting from line 9836,
<guilhembi> are from revs <= sp1r-frazer@forth.ndb.mysql.com-20080320110539-62618
<guilhembi> which is in 6.0-ndb already.
<guilhembi> As MERGE-SOURCE is supposed to be what comes from 5.1-telco-6.2-merge and conflicts with 6.0-ndb text,
<guilhembi> this is weird: all revs which form MERGE-SOURCE text have already been merged into 6.0-ndb.
<jam> yeah, but if you are merging from different bases, it is still possible. I'll still try to look at it closer, I understand your confusion
<guilhembi> jam: Ok. I verified again: I copy-pasted all revision ids from gannotate for this MERGE-SOURCE text, and ran "bzr log -r" for each of them in 6.0-ndb: they are all there.
<jam> guilhembi: bzr log -r revid: will always display the revision
<jam> whether it is merged or not
<jam> It just has to exist in the repository, not in the branch
<guilhembi> uh
<jam> Though if it has a revno, then it would exist in the branch
<guilhembi> jam: this behaviour of "bzr log -r" is probably confusing; "bzr help log" says
<guilhembi> "  By default show the log of the branch containing the working directory."
<jam> and in my check, the one you listed is in the ancestry
<jam> the frazer@forth revision
<guilhembi> I looked again, and it printed revnos for all revids.
<jam> I'm a bit curious, though, why it would give that merge revision as the last modified, are you using my bzr or bzr.dev?
<jam> my bzr shouldn't give the merge revision, unless it actually modified it
<guilhembi> jam: actually (I just tested), asking for a revid which is in another branch than 6.0-ndb, when I am cd into 6.0-ndb, results in bzr: ERROR: exceptions.ValueError: list.index(x): x not in list
<guilhembi> so it does not tell me about revs out of 6.0-ndb.
<guilhembi> jam: I'm using your bzr
<beuno> jam, specifying a revid that is not in the branch but is in the repo gived back a traceback. See bug #241998
<guilhembi> and I'm using gannotate.
<ubottu> Launchpad bug 241998 in bzr "bzr log -r revid:nonexistentrevid throws traceback" [Medium,Confirmed] https://launchpad.net/bugs/241998
<beuno> s/gived/gives
<beuno> exactly  :)
<beuno> I tested it on bzr.dev
<jam> guilhembi: one other interesting thing to try, is to use "-Dmerge" with "bzr remerge"
<jam> It should output a "filename.ext.plan" file
<jam> Which should hint as to how it arrived at its decision
<guilhembi> jam: bzr remerge -Dmerge?
<jam> guilhembi: bzr remerge --weave -Dmerge sql/ha_ndbcluster.cc
<jam> is what I would use
<guilhembi> jam: that would be interesting... but what if I left it to you? You may read the plan more easily than me, maybe spot a weirdness?
<jam> guilhembi: well, what I'm seeing is some lines in "killed base" and then them showing back up again as "new-b".
<jam> Which means that in one of the common ancestors, the lines were changed
<jam> and presumably in the others they are still there
<jam> I'll try to draw a quick graph of what I think happened
<guilhembi> jam: I think this may be a rabbit hole; I still have trouble understanding how the principle that: "if it has been merged already, it should not be a conflict", can fall short. You might be able to convince me that it's false, but for the entire Engineering group of MySQL, there would be work...
<jam> guilhembi: I'm guessing it is a discrepancy between the merge algorithm's annotations and how 'annotate' might do it.
<jam> As near as I can tell, the lines in question are considered "obsolete" by the time we get to the common ancestors
<jam> but then 5.1-merge introduces them again anyway
<jam> guilhembi: do you have these in BK that you could do the merge and compare, or is the current stuff only bzr?
<guilhembi> jam: the chance that people messed lines around, committed, put them bacl, committed, is low.
<pygi> folks, postgresql migrated to bzr, right?
<pygi> or was it mysql?
<Pieter> 'mysql
<Pieter> postregsql is in git afaik
<Pieter> or not
<mwhudson> i think it might still be in cvs or something crazy...
<jam> last I checked postgres was still in cvs, and it is mysql that moved to bzr
<beuno> mornin' mwhudson
<mwhudson> beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/files <- paste, zpt-templating, etc :)
<mwhudson> (not streaming though)
<beuno> mwhudson, very cool!  how's the server load?
<mwhudson> ok so far i think
<mwhudson> LH is also now running on a different machine from all the other codehosting stuff
<beuno> ah, so it's harder to compare
<beuno> yay!  nicer urls!
<mwhudson> oh yeah!
<mwhudson> that too
<jam> mwhudson: well, right now it is taking a while to load :)
<mwhudson> jam: which page?
<jam> mwhudson: the one you linked
<jam> once it came up, then it was reasonable the next access
<mwhudson> hmm
<jam> it could be dns on my end, I don't really know
<jam> anyway /away for about an hour
<pygi> jam, saw the mail from Packt about bzr book? :P
<pygi> ups, you went away xD
<beuno> mwhudson, you cerry-picked from trunk, right?  The order for dirs is still off
<mwhudson> beuno: no, it's just trunk @ some rev
<mwhudson> a few off tip
<beuno> mwhudson, I get timeout at: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3510
<mwhudson> beuno: just after the wsgi merge
<mwhudson> beuno: hmm
<mwhudson> beuno: that's a big old diff i expect
<beuno> I think it's like 20 big diffs  :p
 * thumper pats lifeless on the back
<thumper> I like looms
<thumper> more and more
<beuno> mwhudson, this revno makes a good case for my ajax branch  :)
<beuno> it will load the page
<beuno> and let you see each diff individually
<mwhudson> it also makes the case for my streaming branch i expect :)
<beuno> heh, yeah, that would be neat to see in production
<LarstiQ> beuno: can I see that ajax branch in action somewhere?
<beuno> LarstiQ, yeap, let me load it up on my machine
 * LarstiQ wants to show it to someone
<beuno> LarstiQ, http://intranet.pentacorp.net:8080/bazaar/bzr_garbage/revision/3469
<bkor> elmo: was the ldif enough for now?
<elmo> bkor: I think so, yeah, lamont should have set up/be setting up accounts
<bkor> elmo: good, as I think the port opening will take a while
<LarstiQ> beuno: thanks
<elmo> bkor: ok
<LarstiQ> beuno: I can't collapse the diffs?
<beuno> LarstiQ, the UI needs some serious love, yes
<beuno> I also need to merge that with trunk, since it's using old code
<beuno> and, well, there's a shiny new theme on the way
<beuno> so that will change everything. Again.
<Pieter> it'd be nice if bzr diff had an option to ignore whitespace differences
<beuno> Pieter, file a bug  :)
<Pieter> yeah I guess, but I hate bugtrackers
<mwhudson> diff --using 'diff -b'
<mwhudson> ?
<Pieter> yeah, but who's going to type that?
<mwhudson> bzr alias diffws='diff --using "diff -b"'
<mwhudson> ?
<mwhudson> if that's too much, then there's no hope for you :)
<Pieter> I don't like having to create aliases and installing plugins to get basic functionality :)
<fullermd> Heck with whitespace, I just wish it said something sensible about binary files   :p
<vila> Pieter: 'bzr help alias' no plugin needed
<Pieter> that's not what I meant
<LarstiQ> Pieter: but obviously it's not basic functionality ;P
<LarstiQ> Pieter: I'm interested though, when do you find it useful?
<LarstiQ> Pieter: and offtopic, are you going to Parkpop?
<vila> You asked for an option, mwhudson gave you an option, you didn't want to type the option, he offered the alias, you said no plugin nor alias, I said no plugin. But, ok, bzr can't do what you want.
<vila> g'night all
<LarstiQ> vila: night!
<Pieter> LarstiQ: if you have a python script that you changed to a class, so everything gets indented
<beuno> mwhudson, btw, do you know why this would be happening: http://bzr-mirror.gnome.org:8080/alleyoop/trunk/changes ?
<beuno> night vila
<LarstiQ> Pieter: aaah, good point
<Pieter> if you then want to diff it against eg the same file on another branch, you need something that ignores whitespace
<LarstiQ> Pieter: wouldn't you want to ignore just uniform indent changes?
<LarstiQ> for that specific case
<mwhudson> beuno: looks like url generation is fuxored :(
<Pieter> sure, anything that works :)
<Pieter> LarstiQ: and I'm not going to parkpop :)
<LarstiQ> Pieter: awww
<LarstiQ> Pieter: ok, I agree that ignoring something there certainly has merit
<beuno> mwhudson, yeah, I don't understand why. It's trunk + search, but he tried trunk alone, and same thing happened. I can't reproduce it locally
<LarstiQ> Pieter: I'm not sure if python specific should be in core, but ignoring all whitespace could be
<mwhudson> beuno: do you know if he's using a vanilla serve-branches.py ?
<mwhudson> Jc2k: still awake?
<beuno> mwhudson, yeap, untouched
<Jc2k> hi guys
<Jc2k> i considered patching serve-branches, but yeah, its a bit different to twisted.web2 :)
<Jc2k> i'm around if you want me to do stuff, i just have to hit the pro Git guy on pgo over the head
<mwhudson> Jc2k: hmm?
<Jc2k> mwhudson: i was hoping i could add something to serve-branches to serve /static/ of the root to get things going until there was a proper fix, but its not twisted.web2 so i dont know where to poke so i left it :P
<beuno> it should be serving /static/ from root
<beuno> that's the default behaviour
<mwhudson> the links to static things are all //staic
<mwhudson> which i guess is the problem?
<beuno> mwhudson, what's more interesting is that /static is served from: http://bzr-mirror.gnome.org:8080/epiphany/trunk/static/javascript/collapse.js
<beuno> so it's not at the root
<mwhudson> beuno: it's served from both places
<mwhudson> or at least, it should be
<beuno> mwhudson, doesn't seem to: http://bzr-mirror.gnome.org:8080/static/javascript/collapse.js
<jam> beuno: there is that bzr_garbage again... you make me :'(
<mwhudson> Jc2k: what versions of paste and paste-deploy do you have?
<Jc2k> mwhudson: 1s
<Jc2k> mwhudson: 1.0.1
<mwhudson> Jc2k: oh er ah
<mwhudson> Jc2k: that's paste-deploy, right?
<Jc2k> oh
<mwhudson> if it's paste, i'm amazed anything works at all :)
<mwhudson> Jc2k: can you try commenting out the stuff to do with PrefixMiddleware in serve-branches.py ?
<Jc2k> from dpkg -l
<Jc2k> ii  python-paste               1.0.1-1                                  Tools for using a Web Server Gateway Interfa
<Jc2k> ii  python-pastedeploy         1.0-1                                    Load, configure, and compose WSGI applicatio
<mwhudson> holy crap
<mwhudson> what os are you running?  etch?
<Jc2k> etch :)
<mwhudson> well, try commenting out the PrefixMiddleware stuff
<beuno> jam, hahaha, it's an old branch  :p
<beuno> there, killed the branch
<Jc2k> mwhudson: http://bzr-mirror.gnome.org:8080/conduit/trunk/changes :)
<jam> beuno: thanks :)
<jam> beuno: you could call it "bzr_no_more_tears" if you prefer
<beuno> Jc2k, cool. Search even works!
<mwhudson> Jc2k: that looks better
<mwhudson> dependencies suck donkey balls
<beuno> jam, muahahaha, I'll grep my LH and do it!
<cj> hurm...  '$ bzr branch lp:mysql-server' failed halfway through and now I can't 'bzr up' from the directory, and trying to re-run the branch command tells me:
<cj> bzr: ERROR: Target directory "mysql-server" already exists.
<jam> also, my fingers keep wanting to type bueno, what's up with your name? :)
<cj> I'm new here... can someone LART me?
<LarstiQ> jam: be-uno? :)
<beuno> jam, why would you want to type a full nickname?
<LarstiQ> not kinderbueno
<beuno> lol
<mwhudson> cj: can you cd into the branch and 'bzr pull' ?
<jam> beuno: because I start typing "bu^T" and it never works
<beuno> LarstiQ, I see you've been present in one of the conversations of me trying to explain my nickname
<LarstiQ> beuno: I haven't actually
<jam> but.. that is mixed languages :)
<jam> At least if you just said it is a fixed typo of bueno, *that* I could understand
<beuno> LarstiQ, then that's a pretty good observation
<LarstiQ> beuno: I did ask you in London wether 'be-uno' was a correct way to pronounce it.
<beuno> jam, the explanation is pretty stupid, so I'm going to defer that until the next time I see you and there is enough beer  :)
<LarstiQ> so that helped in my confidence :)
<jam> beuno: Well I'm as close to seeing you as I can now, and there is a reasonable amount of beers in the fridge, and the grocery store is 2 blocks away. I can't do much better than that :)
<beuno> lifeless, http://bzr-mirror.gnome.org:8080/conduit/trunk/changes    LH + search + Gnome theme in action!
<beuno> hmm, beer...
<beuno> I should really have a fridge in the office
<jam> beuno: well, following the "svn" link looks pretty bad: http://svn.gnome.org/
<jam> And the font sizes keep changing
<jam> but otherwise sexy
<jam> beuno: of course, if you do something like search on conversion_exists, i would sort of expect the revisions to come back in more of a sorted order: http://bzr-mirror.gnome.org:8080/conduit/trunk/changes?q=conversion_exists
<beuno> jam, yeah. New theme is 90% complete, so I should be able to wedge that in before Guadec
<jam> 717, 87, 79, 111, 160, ...
<beuno> jam, blame lifeless  :)
<jam> I've blamed him for too much already
<jam> he reached his quota for this week
<beuno> well, I suppose we can blame Jc2k, since it's on his server
<beuno> damn, font sizes do vary a lot
<Jc2k> beuno: O: ) i think the list of repos/branches being unskinned is the only thing stopping me doing a "OMG Bazaar/Loggerhead FTW" post
<beuno> Jc2k, that puts quite some pressure on me...  :p
<Jc2k> :D
<beuno> I'll get to that after I wrap up what I'm supposed to be doing now then
<Jc2k> :D
<Peng> jelmer: bzr-svn is currently tracebacking with bzr.dev because it can't import bzrlib.knit.make_file_knit.
<mwhudson> prettier directory listings really shouldn't be hard
<beuno> mwhudson, nah, I'll get that done today for sure
<beuno> I also what to see if I can improve the font weirdness
<beuno> seems both CSS files are clashing
<mwhudson> beuno: cool
<blueyed> I have a mainline dev branch.. a derived main.local branch with changes needed for local development and now a feature branch derived from main.local - how do I get only the feature into the main dev branch?
#bzr 2008-06-26
<mwhudson> blueyed: you'll probably need to cherry pick
<blueyed> mwhudson: thought so.. too bad.. should I adjust my workflow?
<blueyed> ..since merging is a lot nicer than cherrypicking.
<blueyed> I've thought about reverse-cherrypicking to reverse the local changes in the main dev branch..?!
<beuno> blueyed, feature branches are great if you need to move around features
<jam> blueyed: if you know you'll never want main.local in the real mainline, you can do
<jam> cd main
<jam> bzr merge ../main.local
<jam> bzr revert .
<jam> bzr commit -m "null merge main.local"
<jam> That will explicitly revert the changes in main.local into main
<blueyed> jam: "cd main"? do you mean the feature branch?
<blueyed> would this be necessary for each future feature branch?
<jam> blueyed: just a sec, phone
<blueyed> jam: np, take your time. I'm drunken already anyway :D
<jam> blueyed: no, you are rejecting the changes in your .local branch, by 'null merging' them into your mainline branch
<jam> so that when you merge your feature branch, it is built on something that has already been "merged"
<jam> even though those changes have been rejected
<Jc2k> mwhudson: http://blogs.gnome.org/johncarr/2008/06/26/the-mirror-man-says/
<Jc2k> how does that read?
<blueyed> jam: I have main.local (where the feature branches are derived from). You mean I should "null merge" the changes into the feature branch then merging this into the main dev branch?
<jam> blueyed: you said you were trying to get the features into the main dev branch, right?
<jam> so if you null merge what it is based on
<blueyed> jam: yes
<mwhudson> Jc2k: "which is handing after setting" ?
<jam> then the next merge will just grab the feature
<jam> blueyed: I probably left off the last steps
<jam> bzr merge ../main.local
<jam> bzr revert .
<jam> bzr commit -m "rejecting the local changes"
<jam> bzr merge ../feature
<jam> bzr commit -m "bringing in feature which was base on local"
 * Jc2k looks
<mwhudson> Jc2k: otherwise fine
<blueyed> jam: in what directory?
<Jc2k> mwhudson: "which is handy after setting"
<Jc2k> after-midnight-fail
<mwhudson> Jc2k: thought so :)
<jam> blueyed: in what you consider your official mainline, versus main.local
<blueyed> jam: yes, I see. I'm in the process of trying it already.
<blueyed> jam: well, too bad I had merged the feature already into the main.local branch.. :D
<jam> blueyed: bzr merge -r -2 ../main.local
<blueyed> jam: "Nothing to do." now.
<jam> blueyed: well *now* that you've already done the other merges
<blueyed> jam: I'm going the "bzr uncommit" route already, yes.
<blueyed> jam: well, "bzr merge ../feature/" said "Nothing to do."  now still.
<blueyed> jam: worked it out. thanks!
<jam> blueyed: great
<blueyed> ..seems like I've done the revert wrong before (answering "n" or something alike)
<cj> mwhudson: let me try that
<cj> $ bzr pull
<cj> bzr: ERROR: Not a branch: "/opt/src/bzr/mysql-server/.bzr/branch/".
<mwhudson> cj: :/
<mwhudson> maybe you'll have to restart the pull then
<cj> that's dumb.
<cj> :)
<cj> $ bzr branch lp:mysql-server
<cj> bzr: ERROR: exceptions.KeyError: 'getpwuid(): uid not found: 10069'
<cj> that was the original exception
<cj> we've got our users in ldap, not /etc/passwd
<cj> password
<mwhudson> er
<mwhudson> that's extremely strange
<mwhudson> can you test with a smaller branch
<james_w> cj: have you ever run "bzr whoami" ?
<james_w> or indeed "bzr launchpad-login" ?
<james_w> KeyError is weird though, that's a bug no matter what's going on. A bug report with the relevant section of your ~/.bzr.log would be appreciated.
<jam> cj, usually you have pam consult ldap
<jam> but I'm guessing you haven't done anything yet for it to find users
<jam> your username
<cj> jam: yeah :)
<cj> I don't have a launchpad user id configured for bzr
<cj> how do I do that? :)
<cj> maybe I should man bzr
<jam> cj: 'bzr whoami "Joe Foo <joe@foo.com>"
<jam> bzr launchpad-login username
<cj> cool.  done.
<cj> ooh, look.  SSH authentication and everthin.
<jml> lifeless: where does your extended test result whitepaper hang out?
<jml> mwhudson: I thought pydoctor also provided a link to source code?
<mwhudson> jml: only really works with svn & trac currently
<jml> mwhudson: ahh ok.
<mwhudson> i think there may even be a bug open about this...
<beuno> ok, I'm definetly not going to get anywhere today. Closing all vim's
<beuno> Jc2k, I'll have to pospone the dir-templating bit til tomorrow, when my brain decides to wake up again
 * jml pimps bzrlib.tests to python-dev
 * igc out for a few hours
<lifeless> jml: I don't have an extended test result paper AFAIK
<jml> lifeless: I ended up linking to the spec on the wiki
<lifeless> Peng: yes, massive API break landed last night
<poolie> hello lifeless, etc
<Peng> lifeless: Yeah, VersionedFiles, right?
 * spiv -> lunch
<lifeless> Peng: yes
<lifeless> Jc2k: cool
<lifeless> beuno: cool
<Peng> Has 1.6's development cycle been longer than usual?
<Verterok> moin
<lifeless> Peng: yes, as discussed on the list :P
<RAOF> Hm.  bzr-svn in intrepid seems to be broken with a svn_ra_get_log2 error.  Also, the initial branch of bzr & bzr-svn isn't exactly snappy :(.
<Peng> Does intrepid have svn 1.5?
<RAOF> Yes.
<Peng> Yeah, I don't think bzr-svn is entirely compatible with it yet.
<Peng> At least, 0.4.10.
<RAOF> Right :(
<Peng> The current development version of bzr-svn has some major changes (using custom Python bindings for svn), and I dunno if it works.
<mwhudson> i think there is a 1.5 branch
<Peng> that too
<lifeless> RAOF: welcome to intrepid
<lifeless> RAOF: going where no code has gone before
<RAOF> :)
<mwhudson> https://code.edge.launchpad.net/~jelmer/bzr-svn/svn-1.5 <- here
<RAOF> Why git cloning so much faster than bzr branching?
<lifeless> because
<RAOF> Beacause git does more server-side?
<lifeless> several things
<lifeless> git is optimised for one project one repo; so it has a full list of heads (hg does this too).compare with the test repo I've got with 13K heads.
<lifeless> git uses a bidirectional streaming protocol AFAIK, which can't tunnel through http
<lifeless> (our smart server protocol tunnels through http fine)
<lifeless> because we haven't fixed some of our bugs
<lifeless> bzr is not as fast as the bzr design permits it to be
<RAOF> And because lp is in England, and round-trips kill .au performance? :)
<lifeless> round trips are a significant factor
<lifeless> doing a branch over bzr+ssh should stream [mostly], and not with bzr.dev which just had some blunt trauma inflicted on it to sort out infrastructural problems
 * mwhudson finds himself looking at another savaging of the insides of loggerhead
<Peng> Poor Loggerhead.
<mwhudson> after this one, there really will be hardly any of it left
<Peng> How large is LH, compared to, like, hgwebdir?
<Peng> mwhudson: What are you going to savage?
<mwhudson> um, it's about 5000 lines i think
<mwhudson> a lot of that is templates though
<mwhudson> Peng: i don't want loggerhead to keep all the branches it has ever seen open
<Peng> ./mercurial/hgweb/*.py is 2253 lines.
<Peng> mwhudson: Oh. That sounds good. That'll help memory usage?
<mwhudson> Peng: maybe
<mwhudson> Peng: but file descriptor usage is the pressing issue ...
<Peng> Oh.
<mwhudson> (we want loggerhead to access branches over http, it seems having a branch open over http keeps the socket around)
<Peng> How many descriptors does it keep open per branch?
<mwhudson> Peng: only 1 it seems
<mwhudson> alternatively, i can try to rig things to share transports, but i think the threading implications of that scare me off
<Peng> Ah! Googlebot finally started poking around my Loggerhead instance. :)
<spiv> Hooray, my net connection came back.
<spiv> (Although bizarrely the odd spam email still snuck through when nothing else could...)
<lifeless> markh: how is tbzr installer coming along?
<lifeless> markh: been chatting with zou_ in #gnash, and he's a windows developer that would love a gui ...
<zou_> markh: hi, how is the status of TortoiseBzr now?
<lifeless> Jc2k: ping
<lifeless> jam: re sort order in search, relevance >> revno's in my opinion
<lifeless> jam: (not that relevance is really cooked today, but in principle)
<RAOF> So, I'm trying to branch bzr.dev.  This is proving surprisingly difficult.  bzr branch lp:bzr seemed to hang about a 1/4 of a progress bar into "Transferring 0/4", and branching over http from bazaar-vcs.org hung in the same place, ending up with http://pastebin.com/d69baea29
<RAOF> bzr 1.5 from Intrepid.
<lifeless> RAOF: you would appear to have unreliable DNS
<RAOF> I haven't noticed with anything else, but it's possible.
<lifeless> Couldn't resolve host 'bazaar-vcs.org' (-2, 'Name or service not known')
<lifeless> thats coming from below bzr
 * RAOF goes to find opendns howtos before trying again.
<lifeless> RAOF: do you have a local dns server?
<lifeless> RAOF: if not, its a failed request to your ISP's; just installing a local cache-only server would do
<RAOF> Hm.  Not deliberately.
<RAOF> Is that hard?
<lifeless> not at all
<lifeless> apt-get install bind + edit /etc/resolv.conf :P
<RAOF> Oh, no.  It seems that my router acts as a dns server.  So I do have a local dns server.
<RAOF> It's possible my router is crap, though.
<matkor> Is there any tool to find out during wich commit some string was deleted from given file ?
<lifeless> matkor: deleted is a tricky problem :P I want bzr-search to address this; but it doesn't yet. however bzr bisect + grep will do it in optimal iterations
<igc> back
<matkor> lifeless: OK. thanks readinf about bzr bisect :)
<Jc2k> lifeless: pong?
<lifeless> Jc2k: so, can you ask robtaylor today
<lifeless> exactly what options he'd give rebase -i
<lifeless> (give me an example to make work under bzr :P)
<Jc2k> will do
<lifeless> also, the gnome header on bzr-mirror.gnome.org - the viewvc page might want to go to loggerhead :)
<lifeless> ditto the loggerhead ones - why bounce to the svn vc page?
<Jc2k> lifeless: an example of how i used git rebase -i...
<Jc2k> i had 2 commits on libgitcore
<Jc2k> i did git rebase -i HEAD~2
<lifeless> while in your tree?
<Jc2k> yep
<Jc2k> then i did an "edit"
<Jc2k> and split those commits into multiple commits
<lifeless> so HEAD~2 is a revision spec right?
<Jc2k> yep
<Jc2k> last 2 revisions
<lifeless> ok
<lifeless> so that is 'edit my last two commits kthxbye' ?
<Jc2k> yep
<lifeless> ok
<Jc2k> you get an editor window that lets you chose to "squash", "edit" or "kill"
<lifeless> feed me defects to work out. I shall do stuff
<Jc2k> squash turns 2 or more commits into 1
<Jc2k> edit stops the replaying and lets you commit a bit at a time
<Jc2k> then you do git rebase --continue to carry on
<Jc2k> kill just drops a patch from the replay process
<lifeless> https://bugs.edge.launchpad.net/bzr-rebase/+bug/243150
<ubottu> Launchpad bug 243150 in bzr-rebase "support -i flag as per git" [Undecided,New]
<Jc2k> oh wait, i made kill up :)
<Jc2k> thats something bzr can do that git cant then :p
<lifeless> btw
<lifeless> ewww at the details
<lifeless> I'm going to make this nice, not nasty
<Jc2k> http://pastebin.com/mb8ed0fa
<Jc2k> is the view that you get in $EDITOR
<Jc2k> have to go now
<lifeless> k, thanks and bye
<vila> can anyone tell me why I can't install several ftp servers under Ubuntu (most of them seems to be conflicting with a ftp-server package which appears to be virtual or something) ?
<vila> Or may be the question should be: how can work-around that since I understand the rationale but want several ftp servers anyway for tests purpose
<bob2> have to use dpkg's --force-depends or rebuild the package without the Conflict, I guess
<lifeless> vila: file bugs; there are valid use cases for concurrent installs of any server that can run on an alternate port
<vila> lifeless: bugs against packages or against the distro ?
<vila> bob2: what are the risks of my dpkg getting fubared in the long run ?
<lifeless> vila: packages I think
<vila> lifeless: k
<lifeless> vila: they probably all install /usr/sbin/ftpd or similar
<lifeless> vila: so highly likely that they genuinely can't coexist
<vila> lifeless: good point, I'll investigate
<lifeless> vila: you could run up N VM's though, with one server each
<vila> lifeless: that's an idea but it doesn't fit my needs... or may be it will but will require to much admin. The aim is to inject these servers into bzr test suite without requiring too much admin privileges.
<bob2> aside from root to install the packages ;)
<vila> bob2: a couple of clicks away with synaptic, should fit :)
<vila> I'm trying to find the right balance here, the aim is to help testing not becoming an expert in ftp server admin :-/
<vila> I nearly got it for vsftpd but that beast is too secured :) I can't get chmod authorized for anonymous users :)
<lifeless> jelmer: bzr selftest rebase fails 7 tests
<lifeless> mm, one is bogus
 * lifeless fixes local edit
<lifeless> jelmer: 2 failures
<vila> hmm, vsftpd and wu-ftpd conflicts on /etc/ftpusers, nice diagnostic lifeless
<jelmer> lifeless: Oh, I only get 2 failures
<jelmer> lifeless: Can you pastebin the output?
<lifeless> jelmer: its bzrlib.plugins.rebase.test_rebase.TestReplayWorkingtree.test_multiple and
<lifeless> bzrlib.plugins.rebase.test_blackbox.TestRebaseSimple.test_pending_merges
<jelmer> lifeless: Yep, those are the ones
<jelmer> lifeless: That's only two :-)
<lifeless> dang, pysizer and heapy are not packaged :(
<lifeless> 17:28  * lifeless fixes local edit
<lifeless> 17:30 < lifeless> jelmer: 2 failures
<jelmer> ah, never mind me
<lifeless> :)
<lifeless> I'm implementing -i support
<lifeless> any tips or requests about how its done? or just do it and send you a patch ?
<lifeless> jelmer: what is replace_map too - is the idea that you precalculate what things are being done?
<lifeless> jelmer: (rather than e.g. recording what has been done then using the result when you need a merge etc?)
<jelmer> lifeless: Yes
<jelmer> lifeless: This shows a bit of rebase' background, since it was written as svn-upgrade backend
<lifeless> so what I appear to need is:
<lifeless> for combining, to just skip a revision
<lifeless> and output a different one
<lifeless> this will propogate; I guess I can write tests to update a map thusly
<lifeless> to split, I need to insert one, this should be kindof easy
<lifeless> also, the user needs the ability to edit stuff
<lifeless> as in to choose operations
<lifeless> I kind of like the shelve interactive operaiton
<lifeless> but there is the git style open-an-editor option too
<lifeless> jelmer: ^
<jelmer> re
<lifeless> spiv: have you used heapy/guppy?
<jelmer> lifeless: Yeah, updating a map makes sense
<jelmer> lifeless: Something else that would make sense is creating a new class
<lifeless> jelmer: for editing, we could make the plan have an editable area, or use a separate file to list what is pending (and thus what can be controlled)
<jelmer> and using that rather a dictionary
<jelmer> lifeless: gmta
<jelmer> lifeless: I think we're both saying the same thing but you're talking about the file format and I'm talking about the data type it's read into
<lifeless> jelmer: well I'm thinking UI largely; rebasing including merges clearly needs to rebase the side branches as well and so on
<jelmer> "side branches" ?
<lifeless> if I rebase three commits in this branch
<lifeless> and that includes a merge from another branch that is also not in the target i'm rebasing onto
<lifeless> surely I need to rebase them too ?
<jelmer> ahh, ok
<jelmer> true
<lifeless> but I'm not trying to fix any flaws in rebase :)
<lifeless> just to teach it -i
<jelmer> heh
<lifeless> so it sounds like my plan is:
<lifeless> -i should generate the plan and not execure
<lifeless> there should be some sort of edit-plan call
<lifeless> after which the plan is adjusted as needed to accomodate
<lifeless> refactor stuff so there is an 'execute_plan' method
<lifeless> which will know how to drop commits, and return to the shell to edit commits that are selected to edit
<lifeless> does that sound complete/sufficient?
<jelmer> yeah
<jelmer> Sorry for the slow responses, I'm not entirely here
 * lifeless pictures partial-jelmer
<LarstiQ> is that a derivative?
<LarstiQ> or have I been doing too much calculus lately
<LarstiQ> lifeless, jelmer: moin, btw :)
<lifeless> moin :)
<lifeless> poolie: I'm done for the day, rebase -i is doable tomorrow I think
<zou_> lifeless: there?
<zou_> http://rafb.net/p/qfCzZn85.html
<lifeless> zou_: was there a previous operation you interrupted/had an error of?
<zou_> yes, I did a "bzr commit --local" and there was too much prints, then I used "ctrl + c" stopped the process.
<lifeless> bzr break-lock
<matkor> and better leave commit to finish ... you can always revert/uncommit it ...
<lifeless> ctrl-c _should_ be safe but its possible you got it just the wrong point
<zou_> thanks, it's fine now.
<zou_> bzr commit --local;
<zou_> Now there are too much modifed files than I expect. what could be the problem?
<zou_> some are binary files
<matkor> zou_: so check what is different in files you expect being utouched
<lifeless> zou_: bzr st/bzr diff can show you the changes
<zou_> bzr commit --local >> output.txt
<zou_> got message: "Saving data locally - Stage 2/5Vim:  Warning: Output is not to a termianl"
<zou_> then bzr seems stops after that message.
<james_w> you've got a vim process open waiting to receive your commit message. You can use "-m <message>" to stop it from opening an editor.
<zou_> then I need to interrupt bzr again with "ctrl + c"
<zou_> sorry, "ctrl + z"
<lifeless> zou_: do you have a vim window popped up somewhere?
<lifeless> zou_: exporting EDITOR="vim -X" might help (or whatever the similar thing is in windows)
<zou_> I am using cygwin on windows.
<zou_> message: "=== modifed file 'xxxxxx/tests.png' (properties changed: +x to -x)"
<zou_> what does "+x to -x" mean?
<matkor> zou_: executable bit ?
<matkor> zou_: are  you under linux ?
<zou_> I am using Cygwin(a linux emulator) under windows.
<matkor> ah cygwin .. so I do not know how it works with executable bit
<zou_> what is " executable bit"?
<zou_> "===modefied file 'backend/render_handler_agg.h' (properties changed : +x to -x)"
<zou_> render_handler_agg.h is a text file.
<zou_> bzr -m "my message" commit --local
<luks> did you checkout the branch with native bzr and committing using cygwin bzr?
<zou_> got: bzr: ERROR: unknow command "-m"
<matkor> bzr commit -m "my mes" --local
<luks> you want bzr commit -m "..."
<eMBee> he looks german enough
<eMBee> ooops
<eMBee> wrong channel
<zou_> bzr commit -m "my message"   --local  <---- this works, thanks.
<zou_> luks: I checked out the branch with cygwin bzr.
<zou_> Now I'v finished "bzr commit --local".
<zou_> How do I check the difference between my local source and the source on the other server?
<matkor> bzr diff <remote_branch>
<matkor> or bzr missing
<zou_> If I don't want to type the " <remote_branch>", do I have a way to show the diff between my local source and the source from the branch I checked out?
<zou_> sorry, I am still thinking bzr in a cvs way.
<mlh> zou_: ctrl-Z doesn't stop a program, it merely suspends it
<zou_> mlh: thanks.
<mlh> you're welcome
<mlh> weird things could happen if you have multiple bzr's suspended
<zou_> btw, I really need a GUI-based bzr on windows.
<zou_> I am not used to command lines.
<matkor> zou_: so bzr diff/missing <local_path>
<zou_> matkor: there are two type of diffs after a local change IIRC: (1)difference within local source; (2)difference between local source and remote source.  right?
<matkor> let's name them branch
<matkor> so there are differences between branches and branches vs working trees
<matkor> so  yours (1) is diff working tree vs branch (of same woriking tree)
<matkor> and (2) is diff between branches
<zou_> ok, clear.
<zou_> then command "bzr diff" gives (1)?
<zou_> and command "bzr diff remote_branch" gives (2)?
<matkor> ad (1) - yes
<matkor> ad (2) - not sure - I am not using diff with uncommited working trees ... I suspect it shows working tree vs remote branch but not sure
<matkor> oh seems one can't diff to other place than  local
<zou_> Are my local branch and the remote branch always two different branches in concept, or they can be the same one?
<luks> you can
<luks> see bzr help diff
<luks> especially the --old option
<awilkins_> jelmer: Does the bzz-gtk bundle buggy supercede patches automatically? If so which criteria does it use?
<awilkins_> zou_: Olive works on windows, but isn't mature yet
<awilkins_> zou_: And you can bind your local branch to a remote one ; they are still distinct branches, but they are much closer
<zou_> I used TortoiseCVS a lot, so I would probably choose TortoiseBzr.
<awilkins_> zou_: Or you can ``bzr checkout --lightweight`` which makes no local branch, just a working copy.
<awilkins_> zou_: AFAIK TortoiseBZR is Olive with some shell extensions and I'm not sure how mature that is either.
<awilkins_> zou_: I'm a longtime user of TSVN and I'd like to see the bzr GUI on Windows that mature, but I find that CLI with some of the commands from bzr-gtk is pretty ok.
<zou_> awilkins_: right, I haven't install either of them. Both of them require you to download and install lots of other things.
<zou_> I just need a binary executable file.
<awilkins_> zou_: There's a prepacked installer for bzr-gtk that has most of the deps in it.
<awilkins_> http://d5190871.u44.websitesource.net/bzr-gtk/
<luks> I don't think it will work with cygwin python though
<awilkins_> Ah, I didn't catch that zou_ was running cygwin python
<zou_> if it works on my window, I don't need the cygwin version:)
<zou_> window/Windows
<awilkins_> zou_: I've been running it on windows since ...ooo , at least all the way back to 1.2 (last tuesday :-p  )
<zou_> thanks, downloading now.
<zou_>  <awilkins_> zou_: Or you can ``bzr checkout --lightweight`` which makes no local branch, just a working copy.
<zou_> so "bzr commit --local" doesn't make sense with this working copy?
<awilkins_> zou_: --local is for use when you have a bound branch but don't want to push your commit to the master branch immediately
<zou_> yes, I think I understand that.
<zou_> ah, a new name "bound branch".
<awilkins_> "attached to a remote branch to which it pushes all commits"
<zou_> that's exactly what I need. At the first stage, I just want to my local bzr rep. works exactly like my old cvs rep.
<zou_> awilkins: how do I use the bzr-gtk? I'v installed it.
<zou_> where could I expect the GUI?
<awilkins_> zou_: It adds some commands to your bzr command line ; for the GUI thing, ``bzr olive``
<awilkins_> zou_: I tend to just use the command line with some of the sub-commands
<awilkins_> like ``bzr gconflicts`` ``bzr viz`` ``bzr gdiff``
<zou_> I see some *.py files are installed to ..../bazaar/2.0/plugins/gtk dir under my Windows.
<zou_> Do I expect to compile these *.py file to produce a executable file?
<jelmer> awilkins_, hi
<AfC> Hm. If one does `bzr merge -r X..Y` (or uses `bzr rebase`, which I am slowly gathering is the same thing), one "loses history" right? Which can lead to conflicts later, which is, as I understand it, why we don't encourage people to rebase. Is that right?
<AfC> (this should probably be an email to the list, but feel free to poke at me now)
<jelmer> awilkins_, No, should only be if it was merged
<AfC> If so, then would the following clean matters up? 1) Create the nice orthogonal patch with one or more ï»¿`bzr merge -r X..Y --force` and or ï»¿`bzr merge --force ../path/to/file/in/other/branch`
<jelmer> AfC: rebae isn't the same as "bzr merge -r X..Y"
<AfC> then 2) bzr commit to create a new revision, then 3) immediately merge that new orthogonal half ass cherry pick revision _back_ into the branch that sourced it.
<zou_> hmmm, "bzr olive" got a runtime error.  I'll try tomorrow. Thanks awilkins.
<AfC> ï»¿Would that not remove the problem of (some time later) having the cherry pick / orthogonal / rebase / whatever come back to visit you causing problems?
<AfC> jelmer: [I have been given to understand here that bzr rebase is, under the hood, nothing more than a sequence of bzr merge -r N..N+1 and copying the commit message and forcing you to resolve conflicts]
<jelmer> AfC: yeah, that's how it's implemented at the moment - as a series of cherrypicks
<jelmer> AfC: merge -rX..Y does a single cherrypick
<AfC> jelmer: [but I'm not saying I know what I'm talking about. More to the point, Robert long ago advised me to use the `bzr merge -r X..Y [--force]` form to cherry pick orthogonal patches off of feature branches.
<AfC> jelmer: since then I have largely been trying to understand what the benefits/costs/implications of doing so are]
<AfC> jelmer: (right)
<AfC> ok, so back to my suggestion:
<AfC> if, having just done this nasty operation (be it X..Y or {N..N+1}*)
<AfC> would immediately (ie, while you still have control of the tip of the original branch and nothing else has yet happened to it)
<luks> so you just want to merge some branch, and not include the original revisions?
<AfC> merging that new branch with the evil nastiness on it back into the feature branch allow you to dismiss any conflicts and get back to work without fear?
<AfC> luks: the scenario I have is a lot of people working on long long LONG feature branches. After a while, they want to start contributing bits of it.
<AfC> luks: *yes* I can teach them how to make orthogonal patches (I've blogged extensively about this, in fact)
<luks> well, the answer for that is they are doing it wrong :)
<AfC> luks: but the problem comes when they continue on ... of course they don't want the very act of making a contribution upstream to screw them up when they later pull their own work back
<AfC> luks: [I hope you're trolling, in which case I return your :) with a good hearted {grin}. But otherwise, I really have to tell you that the scenario I am describing is *very* common. Not all languages, environments, and projects are suited to micro branches where each little feature is worked on in complete isolation and you have no dependence on a branch containing all of your work]
<luks> no, I'm not trolling
<AfC> {sigh}
<AfC> Then what I said is honest, and from the bottom of my heart.
<luks> if you have a feature branch, with more than one feature, it's no longer a feature branch
<AfC> People really do work on long feature branches.
<AfC> Ok, call it whatever you want then.
<luks> yes, but there is a big difference
<luks> if you have small feature branches, and you merge them to your "fork" branch it's fine
<luks> because the upstream can easily merge the feature branches separately
<AfC> Ok. Whatever you want to call the opposite of small isolated pieces of work
<AfC> "long line of development"
<luks> there is really no way to completely avoid conflicts if you start duplicating revisions via cherry picking
<james_w> AfC: as I understand it conflicts should be minimal if the act of cherrypicking doesn't change the code much from what's in the long-lived branch.
<AfC> james_w: that's sort what I'm figuring
<james_w> obviously if mainline makes big changes in the same areas as the long-lived branch then you get conflicts.
<AfC> james_w: I never thought of this before because one doesn't normally "no-op" (sic) merge into oneself (sic)
<AfC> james_w: sure
<james_w> though I guess you are asking if there is anyway bzr could be smarter when merging back as some of the conflict resolution has presumably been done.
<AfC> james_w: which would probably arise anyway
<AfC> james_w: well, really, I'm still bashing my way down workaround wobble
<AfC> james_w: as is anyone who is a Darcs refugee still struggling to cope with the fact that revisions aren't the diffs they look like.
<AfC> james_w: a specific technical question is "how much information is preserved if I cherry pick" to which there seem to be varying opinions. I tired to figure it out from the sources, but I'm not smart enough I'm afraid.
<james_w> not a lot I believe, I think the operation is currently equivalent to diff + patch
<james_w> so all the merging that is done is done purely on the text level.
<AfC> james_w: we discussed it a bit in London; Robert was talking about storing origins (file or rev) in revision properties as a possible first-hack approach. But it was all in the future tense, which seemed a bit discouraging.
<james_w> you can store cherrypick meta-data, but it's not exactly clear what to do with that, or at least how to do it in a way that doesn't cripple performance.
<AfC> james_w: yeah. Shame, though.
<james_w> yeah, you could stick it in revision properties, but the problem then is using the information. Let me find you a post on the subject.
<AfC> james_w: [it just seems really counter intuitive that I can create a revision that, to all outside appearances, looks exactly like one (or a small set of) revisions from a branch,
<AfC> ï»¿only to have those new revisions come back some other day to not merge cleanly because they aren't the same. I understand the technology now, but socially I still struggle with it. Or, more to the point, I struggle to explain it to people, which is always a good marker that you don't really know what you're talking about.]
<AfC> Anyway, I'll give the "immediate merge back" thing a try in some of my work
<james_w> yeah, there's a few issues that make it difficult to do, but not doing it also makes it difficult
<AfC> (me being one of these evil people with long running branches)
<james_w> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/33962/
<AfC> That looks familiar :)
<Pilky> wow, what did the dev team do in 1.6? Just ran 1.6b2 through my unit test suite for BazaarX and it ran 40% faster than 1.5
<lifeless> Pilky: is that good?
<Pilky> well the average run times of the test suite was 22.19s for bzr 1.3, 23.55 for 1.4, 22.92 for 1.5 and now 16.43 for 1.6b2
<lifeless> Pilky: this is something that uses bzrlib ?
<Pilky> no
<lifeless> oh, bzr's test suite itself ?
<Pilky> no, it's for my GUI client for OS X
<lifeless> ah, to me thats something that uses bzrlib: P
<Pilky> heh, well I'm using an NSTask to call via the command line, I believe you need to know python to use bzrlib, right?
<lifeless> directly sure
<lifeless> you're using it indirectly, not a big distinction I thnk
<Pilky> here's the graphs for the tests if you're interested: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Test_Graphs_1.6b2-20080626-121643.png
<lifeless> Pilky: I'd be interested in seeing what bzr.dev as of today does
<Pilky> has there been a lot more optimisation since b2?
<lifeless> massive api change yesterday
<lifeless> 6 weeks of work or so
<Pilky> well I'll branch it, install it and run the tests
<lifeless> thanks
<Pilky> lifeless: completes in 17.08s
<Pilky> here's the graphs: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png
<guilhembi> jam: hello! I posted comments in the issue.
<lifeless> Pilky: thanks!
<Pilky> still a huge improvement over 1.5 but some things are a bit slower than b2
<Pilky> want me to write up a brief description of each test, so you know what each one means?
<jelmer> Pilky: how did you generate those fancy graphs?
<Pilky> Numbers (iWork 08)
<Pilky> I'm just running my tests through 3 times and putting them in a spreadsheet, then graphing the average
<Pilky> jelmer, lifeless: Here's a quick description of what each test does: http://dropbox.mcubedsw.com/bazaarxtests.txt
<\sh> moins
<\sh> guys, how do I "branch" from launchpad.net via eclipse-bzr plugin? neither http://bazaar.launchpad.net/<branch loc> nor bzr+ssh://... works
<james_w> hi \sh
<james_w> I'm not familiar with eclipse-bzr, do you get some sort of error?
<\sh> james_w: yes :)
<\sh> Command.executing
<\sh>     Command.error
<\sh>     bzr: ERROR: Invalid url supplied to transport: "Host empty in: http:///bazaar.launchpad.net/~shermann/leonov/leonov-kde-mdi-style/"
<\sh>     bzr: ERROR: Invalid url supplied to transport: "Host empty in: http:///bazaar.launchpad.net/~shermann/leonov/leonov-kde-mdi-style/"
<\sh> something like this comes into the console of eclipse
<james_w> http:/// looks wrong
<\sh> yepp :)=
<james_w> urlsplit will make that ('http:', '', ...)
<james_w> I assume that you are not entering that.
<james_w> can you try "lp:~shermann/leonov/leonov-kde-mdi-style", it may work, it may not.
<\sh> it doesn't work :)
<\sh> I tried that already...the eclipse-bzr plugin url check doesn't like that style :)
<\sh> and you are right: http:/// I didn't enter that
<james_w> worth a go.
<james_w> it smells like a bug to me, but I'm a bit stuck about how to track it down.
<\sh> I'll file a bug :)
<lifeless> Pilky: that would be nice
<Peng> Haha, LH is using 125 MB of RAM now.
<Peng> Go Googlebot!
 * Jc2k is getting googlebotted too
<Pilky> lifeless: the link is above
<Peng> If my Loggerhead instance ever gets hit by an abusive bot that downloads pages as fast as it can, my VPS will be swapping to death in 10 minutes. :\
<Peng> (Actually, its RAM usage is hardly growing now. Googlebot probably already has every branch open, and has already downloaded several large pages.)
<Peng> I never configured Loggerhead to store its logs.
<Peng> I should probably RTFM, but how do you do that with serve-branches.py?
<ToyKeeper> BTW, after branch stacking is on launchpad, will that reduce the amount of data users need to upload to publish a branch?
<Peng> That's the idea.
<Peng> I have LP mirror my branches from my own server, so I'm not sure it'll help me though.
<Pilky> do any other VCSs have anything like stacked branches
<ToyKeeper> 'k.  So, they download a thousand revisions, make a change, and when they publish they only need to upload their new revisions?
<Peng> Something like that.
<ToyKeeper> I'm looking forward to it.  :)
<lifeless> Pilky: I'll peek tomorrow. its waay bedtime now
<Pilky> heh, ok
<LarstiQ> jelmer: is/should it be supported to push completely unrelated revisions into a new branch in svn? init, hack, hack, push svnrepo/newpath/foo
<LarstiQ> night lifeless
<Peng> Whee, Googlebot found its way to a LH URL that tracebacks with a NoSuchRevision in tree None. :) URL: http://snurl.com/2p8ye Log: http://paste.pocoo.org/show/77818/
<Peng> (LH trunk, bzr.dev.)
 * Peng disappears.
<ToyKeeper> Heh, at least googlebot didn't click all the "delete" buttons.  :)
<Peng> Ooooh.
<Peng> LH is using my system bzr, not bzr.dev. Go sys.path.
<Peng> Probably for the best, since VersionedFiles would probably break it anyway.
<Peng> ToyKeeper: Heh.
<Peng> God, there are probably a couple hundred thousand pages.
<Peng> This is the first time I've ever had enough "interesting" content for Googlebot to make more than 4 requests per day. :>
<spiv> lifeless: I have used heapy/guppy a little bit.  The remember the documentation wasn't particularly good.
<spiv> It seem to recall it working ok.
<VSpike> I can't quit seem to get the syntax - how do I find out where and how two branches diverge?
<lamalex> Hey guys, bzr is telling me I cant branch because of my public key, shouldn't I be able to branch anywhere?
<awilkins_> lamalex: Are you trying to branch into launchpad ?
<lamalex> branch from
<awilkins_> lamalex: You've set a launchpad login?
<james_w> VSpike: "bzr missing" is useful for this.
<lamalex> might have
<awilkins> lamalex: Have you uploaded a public key?
<james_w> VSpike: or do you want to know the last revision that both share?
<lamalex> yeah
<lamalex> but not from this box
<lamalex> is there a way to logout?
<awilkins> Do you have the private key available to you now?
<lamalex> no
<VSpike> james_w: yes, that would be excellent
<james_w> VSpike: "bzr find-merge-base" I think
<VSpike> james_w: ah yeah, missing is good too
<VSpike> thanks
<awilkins> lamalex: Go to your bazaar.conf file and remove the "launchpad_username" setting
<james_w> lamalex: use a http:// url, rather than an lp: one, or delete the launchpad line from ~/.bazaar/bazaar.conf
<lamalex> thanks
<jam> spiv: I used heapy/guppy, except it didn't work on 64-bit or Mac OS X, which were the 2 platforms I was using the most at the time :)
<jam> Pilky: glad to hear about the performance improvements
<jam> and at least commit is faster yet in bzr.dev
<Pilky> yeah
<jam> I'm not sure what the other speedups are. Given the raw values (0.88 => 0.52s for create repo) I'm tempted to say it is an import thing
<jam> but in general, we seem faster at finding and opening branches
<jam> I've done a few performance improvements, but I wouldn't have expected to see it effect this many places.
<jam> Pilky: out of curiosity, are you running with plugins in your 1.3/1.4/1.5 branches but without plugins for 1.6?
<jam> Just something to think about
<Pilky> nope, no plugins afaik, though I installed 1.3/1.4/1.5 with the OS X installer but 1.6 from source
<Pilky> and I don't think I've changed anything on my laptop which is where I ran all the other tests
<Pilky> I mean, there's always the possibility it could be something in the setup that's different that I've missed
<jam> Pilky: well, you could run the old benchmarks again :)
<james_w> perhaps the pyrex helpers.
<Pilky> yeah, I'll try them again... it could be something stupid and I'm using numbers from this desktop or something
<jam> james_w:  that *shouldn't* effect the "open an existing repository" tests
<Pilky> I'll try doing them all from source
<jam> I'd like to think we really are improving :)
<jam> Pilky: just make sure to run 'make' first
<Pilky> hmm, I've just been doing sudo pythong setup.py install
<Pilky> *python
<jam> Pilky: that will build the extensions
<jam> If you are going to be running from source, 'make' will run the right stuff for you
<jam> or you can do
<jam> python setup.py build_ext -i
<jam> yourself
<jam> (build extensions --in-place)
 * Pilky sighs
<Pilky> this is why I dislike the command line, everything seems to be way too complicated :P
<Pilky> I'll just run the OS X installer for the previous versions, much easier
<Pilky> ah... seems I may have run my previous tests on my iMac...
<Pilky> should really have checked that before hand
<Pilky> well that buggers everything up then...
<Pilky> I was sure I ran everything on my MacBook, because I was already on 1.5 on my iMac...
<Pilky> jam: guess there isn't a 40% speed increase then
<jam> :(
<markh> lazy question: what is the best way to see what remains to be pushed (somewhat similar to the mercurial 'outgoing' command)?
<guilhembi> jam: hello! I don't know if you saw that: I posted comments in the issue.
<Pilky> I could've sworn I ran them on my MacBook though, because I took it back to 1.3
<guilhembi> markh: "bzr missing" maybe?
<markh> guilhembi: thanks - that looks right1
<jam> guilhembi: I replied, but I don't know if you replied to my reply :)
<guilhembi> markh: note, "bzr missing" shows merge revisions, but not what they merged. There's a bug report for that.
<guilhembi> So, when you see a revision in the output, it may actually contain many revisions.
 * markh had one upset pidgin!
<guilhembi> jam: ok, now I read it. When you write:
<guilhembi> "2) Simple sorting of the parents wasn't enough" etc, are you talking about the "bzr --weave" breakage?
<jam> guilhembi: just referencing what I thought would fix it a post or 2 ago
<jam> the --weave breakage is probably something else
<jam> since you don't have my sorting-parents fix yet (3519)
<guilhembi> jam: mmm the sorting-parents seems to be a fix for a problem which I don't really know. I see your older post saying "My current guess is that I need to look a bit closer about left-versus-right parents";
<guilhembi> jam: is it that you're trying to fix --weave so that --full-weave isn't needed?
<jam> guilhembi: yes
<guilhembi> jam: ahah. But "merge --weave; remerge --full-weave" was sexy enough for me, I'd say.
<guilhembi> Hi jaypipes
<jaypipes> guilhembi: hi!
<guilhembi> jaypipes: every time I see your name, I think about its French translation (pipes->tuyaux), which could be interpreted as Jay-the-tips (in the sense of a guy who has good tips to share).
<jam> guilhembi: I'd rather '--weave' Just Worked (tm), there is no conceptual reason it shouldn't
<AfC> james_w, luks: thanks for chatting earlier. Good night.
<jaypipes> guilhembi: hehe.  Funnily, with our onboarding at Sun, many people thought JPipes was a Java project... ;)
<guilhembi> jam: ok. I worry a bit of the time it'll take to get --weave to just work, vs time to fix path conflicts, .OTHER etc. Maybe I'm too worried.
<guilhembi> Java Pipes...
<jam> guilhembi: can you quickly describe how "--weave" was broken? If only giving me a single file example so I can track it down
<jam> I can do it myself, but if you have it available ...
<guilhembi> digging
<guilhembi> ah, if only Konsole showed the last million lines and not a thousand or so...
<guilhembi> jam: not available; you'd need to run "bzr --weave" on your two branches
<guilhembi> and see the 208 conflicts.
<guilhembi> should take ~4 minutes
<fjw> hello?
<james_w> hi fjw
<fjw> Hello, I had a specific prolem with bazaar earlier and was wondering where I could get info
<fjw> The problem I had was that a commit failed due to running out of disk space.  It failed at: "Saving data locally [stage 2/5]".  It took me a couple of attempts before I figured out the problem.
<fjw> Afterwards I checked the repository and it looked like the repository was undamaged, and the commit just didn't complete.  I cleared up some disk space and also ran a "bzr pack"
<fjw> However, after trying another commit the repository grew by a large amount.  It was around 112MB, was multiplying in size.  After a while it was over 500MB.  The commit had only included a couple of small text files.
<fjw> After investigating I found that there were large files in .bzr/repository/upload  and .bzr/repository/pack-obsolete
<Peng> fjw: Packing saves a copy of any packs it removes in obsolete_packs. So you doubled your disk space to save a couple KB. :P
<fjw> I figure that some of these may be related to failed checkins and could be deleted.  Is there a proper way to do this?
<fjw> Ah I see.  So it is safe to delete the contents of pack-obsolete?  And is there an appropriate command to purge this or is it a case of just wiping that dir?
<Peng> fjw: upload is where stuff that's being committed or uploaded is put. Since the commit exited, you can just nuke the files in it.
<fjw> ok thanks for your help
<Peng> fjw: Well, the reason obsolete_packs exists is in case your new packs get corrupted in some way, like an NFS error causes them not to be written out. But yeah, you can nuke 'em.
<fjw> I figured it might be the case.  I am wondering why the contents of upload could be so large when it was involving small commits, though I don't really understand how that works
<Peng> When you're repacking, I'm sure the new packs are put in upload.
<Peng> Make sure everything is okay before nuking obsolete_packs.
<fjw> Ah interesting
<jam> guilhembi: I'm not sure what you saw, I'm curious if you didn't do a "bzr revert" first, but at revno 3519, when I do "wbzr merge --weave" I get 42 conflicts
<jam> I'll try with 3518
<guilhembi> jam: I used clean branches
<fjw> I figure that when I ran out of disk space, it started leaving failed packs in upload and then the packing also gobbled up even more disk space as I tried saving it.  Nice to know I can safely delete these files - thaks
<jam> guilhembi: I'm trying with 3518, just in case 3519 fixed something
<jam> guilhembi: we probably should also assert that we are using the same 6.0-ndb and 5.1-telco-6.2-merge revisions, just in case you are using a slightly newer tip than I (I haven't updated them since I started working on this, just to make sure you didn't resolve the problems manually.)
<guilhembi> jam: ok, here's the last revids I have:
<jam> guilhembi: ok... now that is weird
<jam> 3519 does fix it
<jam> but for reasons....
<guilhembi> 6.0-ndb tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j
<jam> guilhembi: so... update to 3519
<guilhembi> 5.1-telco-6.2-merge frazer@mysql.com-20080604171340-hesp1emb6dqpstkz
<Peng> Haha, Loggerhead just got swapped to hell. :)
<guilhembi> jam: ok
<jam> 2629 tomas.ulin@sun.com-20080619071842-gav9h5zkks8406rh => 2654 tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j
<guilhembi> weird
<jam> guilhembi: so we are using different versions, though I'm not sure *how* different yet
<guilhembi> jam: among what you pasted, what is 6.0-ndb?
<jam> 5.1 => ndb
<jam> guilhembi: you can use "bzr revision-info -r -1" in each branch
<jam> to give the revno and the revision id
<jam> With the revno, I'll know whether *I* need to update, or *you* do :)
<jam> though judging by the dates, I do
<guilhembi> jam: well:
<guilhembi> in 5.1-telco-6.2-merge I don't have any of your two revids
<guilhembi> and in 6.0-ndb I have revid:tomas.ulin@sun.com-20080619094326-n15bh5klhd3yt83j but not the other.
<jam> guilhembi: oh, just a sec, this is mysql-5.1-telco-6.2 not the -merge branch
<jam> guilhembi: 5.1-telco-6.2-merge is 2662 frazer@mysql.com-20080604171340-hesp1emb6dqpstkz
<jam> same as yours
<jam> *why* are your branches named so similarly :)
<jam> I've been doing the right merge, I just switched to the wrong dir when I went to check the revision
<guilhembi> jam: we have exact same branches.
<jam> ok, good
<jam> guilhembi: and I did see 208 conflicts with 3518, and only 42 with 3519... though looking at the actual change makes me wonder why
<jam> 3519 should be "more correct" than 3518, but I don't know why 3518 suddenly decided to puke on everything, as it should be the same basic stuff as previous ones
<jam> guilhembi: ok, I think I have an idea now. Probably 3518 was using a set() which could not be properly indexed by toposort. And since 3519 changes it to a list, everything works again.
<jam> set()[0] has no meaning, you have to use list(set())[0]
<guilhembi> jam: right, set() is the prominent change I saw when diffing 3517 and 3518
<jam> anyway, 3519 will give you "bzr merge --weave; bzr remerge --full-weave"
<guilhembi> jam: and full-weave won't:
<guilhembi> print: bzr: ERROR: Revisions have no common ancestor
<guilhembi> ?
<guilhembi> "bzr merge full-weave", I meant?
<jam> guilhembi: oh, it will still do that, but that is a quick fix :)
<guilhembi> ok, looking forward to 3520 then :)
<jam> guilhembi: done, though somewhat untested
<jam> should be available on my website
<jam> and in a bit when LP mirrors it
<guilhembi> jam: thanks
<jam> guilhembi: you might need http://paste.ubuntu.com/23130/
<jam> If you try it and need that patch, let me know
<jam> I'm trying to focus on some other things first, but I'll merge that if it is necessary
<guilhembi> jam: ok
<guilhembi> thanks
<VSpike> Is it a bad idea in a shared repository to delete a branch by just "rm -rf branch"?
<VSpike> Should I use a bzr command instead
<LeoNerd> It won't break anything, you'll just end up with unreachable revisions that nothing uses
<VSpike> thanks LeoNerd
<VSpike> what is the correct way to do it?
<LeoNerd> I'm not personally sure there is... it's a safe enough thing to do, as long as you don't care about recovering that extra bit of disk space...
<LeoNerd> Maybe there is better way, but I don't know it
<guilhembi> jam: support phoned me, and I recap-ed the status of the merge, in the support issue.
<guilhembi> time for a pause now.
<jam> nap time ? :)
<VSpike> LeoNerd: it's unclear if bzr rm on the top level branch dir will do it
<LeoNerd> bzr rm is for removing a single file from a branch
<jam> LeoNerd: or multiple files, but no "rm -rf branch" is the recommended way
<VSpike> OK thanks guys
<LeoNerd> jam: How's  bzr vacuum  coming on? :)
<fjw> If you are particularly concerned about that lost disk space, what would be a way to remedy this?  At this point I can only imagine setting up a new repository and doing bzr branch from the old repository into it for each branch.  then once confident everything is preserved deleting the old repository.
<jam> LeoNerd: I've never worked on vacuum. :) I think jelmer has something like that, which creates a new repo, copies all referenced revisions into it, and replaces your current one. Might be "vacuum" I'm not sure.
<james_w> fjw: that's the current recommended way.
<jam> fjw: Essentially there is a plugin that does that for you
<LeoNerd> jam: Well, for B in `bzr branches`; do push $B newrepo/$B; done   would do that..
<LeoNerd> A bit expensive though
<jam> LeoNerd: it also doesn't do it "in place" which means all the branches get new parents, etc
<jam> and it doesn't re-use the working trees you have
<jam> etc
<LeoNerd> jam: Indeedily
<awilkins> Is there a way to make log emit status changes for a single file (renamed, in particular)
<jam> jelmer: ping... what is the name of your plugin to GC a repository. I can't find it on BzrPlugins or searching in launchpad
<LeoNerd> bzr log path/to/file
<awilkins> Yes, but it doesn't tell you if the file was renamed, just emits the log messages (by default)
<awilkins> Got it, bzr status <path> -r 2..
<jam> awilkins: does --verbose not do that for you?
<jam> status gives you the snapshot between 2 to now
<jam> which may or may not be what you need
<awilkins> jam: --verbose in this case, is waaay to long for comfort
<awilkins> The tree has over 3400 files in it
<awilkins> And verbose has no meaningful way of filtering the lines (via grep, for example) because the statuses are on a different line to the paths
<awilkins> I got the information I wanted, which was "has the file been renamed between these two revisions"
<awilkins> I think 1.6b is noticeably snappier on these log-heavy things by the way
<awilkins> And on bzr status : is it supposed to be, or am I imgaining it?
<awilkins> And on the subject : there are no win32 installers for 1.6b2 ; I built my own but I'm sure there are others who might like to try it out who don't have the Taurean stubborness required to build it on Windows.
 * Peng waits.
<baco> hi, i don't really get which are all the different ways in which I can set a bazaar server, I realize one is an ssh+ftp server but I wish something that does not require an user account on my server, something that could authenticate against PAM-file for example
<awilkins> baco: You can use the smart HTTP server and make Apache do the auth
<awilkins> baco: Alternatively, you could create one user for the server, and make people who want access send you a public key, and just add them all to that users authorized_keys file
<baco> awilkins: but the commits will all be done by that user, and I don't want to give access to my server except for committing
<awilkins> baco: If users are using bzr+ssh rather than sftp their commits should be in their user name
<awilkins> And you can restrict the rights of that single user a lot.
<awilkins> baco:  In fact, if they are using sftp, their commits should be in their name too.
<baco> awilkins: really? It doesn't happen that when using the smart server only
<awilkins> baco: Don't all commits get logged under the name of the client user that commits them?
<baco> ï»¿awilkins: that smart http server you mention, works for writing commits?
<awilkins> baco: Allegedly ; I've never used it though
<awilkins> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id76
<baco> awilkins: ok, perhaps I can identify who does the commits with the smart server, but I can not restrict who can and who can not
<awilkins> baco: Nothing stops you serving it over plain http at the same time
<awilkins> read-only users only get plain http access
<baco> awilkins: how would the scheme end? could I have read-only access to anybody with http, and write access to selected users via smart http server for users I want? is that possible?
<fullermd> One way is that you use http for the readonly, and https for the write side, and just enable auth on the https side.
<baco> that is not documented, is it?
<Peng> Huh, Googlebot just requested "/loggerhead/my/branchrevision/138" <-- Bad link?
<awilkins> I have to say, whever I look for these things, I get frustrated. Would other people agree that the documentation could benefit from having this stuff broken out into a dedicated "Bazaar Server Guide" ?
<baco> awilkins: I agree
<Peng> Uh-oh, it's doing it again.
<Peng> Well, at least the bzr+http docs could be moved out of an appendix.
<awilkins> It's a major factor in deciding the feasibility of Bazaar use in an organisation ; how it can be fitted within existing infrastructure
<awilkins> A nice service matrix would go a long way to convincing managers to like it, for example :-)
 * Peng wanders off.
<LarstiQ> awilkins: I think that would be beneficial.
<fullermd> Well, a AAA-capable smart server would be too   :p
<awilkins> AAA? Anti Aircraft Attack?
 * baco LOL
<fullermd> Man, I would totally switch to SVN if it supported that...
<fullermd> ...   well, OK, maybe not.
<fullermd> Authentication/Authorization/Accounting
<awilkins> Aha. Yes, it could do with those things
<fullermd> As it is, authentication is pawned off to Apache (or whatever server), authorization is limited to "everyone can {do nothing,read,write}", and accounting is nonexistent.
<awilkins> 3 is suppliable by requiring sign-my-commits
<fullermd> Well, 3 isn't suppliable period as long as there are VFS methods.
<baco> fullermd: YES! that's what I was actually looking for, but I don't find it yet
<fullermd> I mean, I can use the VFS methods to delete every pack in the repository.
 * awilkins is definitely glad he's going for public-key auth
<fullermd> sign-my-commits gives you 3 if you always trust the client side.
 * fullermd points at Raph Koster.
<awilkins> Nah, sign-my-commits is pretty trustworthy, regardless of client integrity
<abentley> I wonder whether bzr+http can support openid?
<fullermd> Not at all.  I can connect up and do *ANYTHING* via the VFS methods.  Delete all the packs.  Replace the existing revisions with totally bogus data.  Add commits with no signatures.  ANYTHING.
<fullermd> I think there's an auth_openid apache module...
<fullermd> I'm not sure I see how it would work, but...
<awilkins> Hmm. Ok, I was coming at it from the point of view that you can always be sure that a signed commit was signed by the owner of the key
 * fullermd hasn't thought much about it.
<abentley> fullermd: There is.  It's the client side I wonder about.
<awilkins> You can't fake other peoples signed revisions with the VFS methods
<awilkins> But the other actions are obviously rather insecure
<fullermd> No, I can't do that.  But unless everybody's validating signatures of every revision they grab...
<awilkins> I presume then there isn't a reciprocal "verify commit signatures" plugin?
<fullermd> I think there is.
<awilkins> But you can't ensure that everyone is using it... it's the Visual Sourcesafe family of problems
<fullermd> I recall jam having/writing something some years ago.
<awilkins> VSS is also a fat client which accesses a filesystem backend and does what it will.
<awilkins> Of course, VSS fubared things a lot more because it wasn't as careful
<fullermd> Yeah.  If you solved that problem, VSS would still be [unprintable]   :)
<awilkins> There was a third-party thing that created a VSS "server" by wrapping a client up in a server process.
<awilkins> So you could use it across the wider internet without exposing win32 SMB shares to the world
<awilkins> It also dealt with some other howlers like timezone support
<awilkins> But didn't fix things like being able to set your clock to the future, in order to be able to commit revisions there.
<awilkins> THe revisions wouldn't show up until the future date, so you could commit a nasty delayed logic bomb that wouldn't even show in the code until someone did a build in the furture.
 * awilkins is a VSS survivor and converts it to SVN on sight these days.
 * fullermd makes a note to maintain a safe distance.
<fullermd> The problem with the signing commits is 3-fold.  First, you have to sign them.  Second, the other side has to verify them.
<fullermd> And third, you have to KNOW they're signed.  If you have a bunch of signed revs, they're trustworthy even if I get access to fiddle files in the repository.
<fullermd> But if I replace your revs with bogus revs of mine, and don't put up any signatures, you have to KNOW there were SUPPOSED to be signatures to be able to tell it's spurious.
<awilkins> True ; this is somewhere Monotone and git score.
<fullermd> Yah.  In a lot of ways, signing revs gives all the same assurances as the checksum being the rev name, but it doesn't quite cover it.
<fullermd> (it gives more in other ways of course; assuming the web-of-trust does its job right, you have assurance of WHO did it, which the checksums can't directly give you)
<awilkins> Signed digests 4tw
<awilkins> (as intrisic parts of the revision that can't be replaced)
<fullermd> mtn is great on that sort of assurance.  It's too bad it's so unpleasant to use [for me anyway].
<awilkins> I suppose there is nothing stopping Bazaar adopting it in newer repo formats
<awilkins> Unless it would hopelessly break revids?
<fullermd> Well, the revid would have to become the hash, and the client would have to know to validate it.
<fullermd> Of course, since our revids are always opaque, we have a leg up in that we could use multiple hashes.  The revid could be 12f57a2[...]a3:SHA1  or ab41d[...]85:SHA256 or what have you; easier to switch in the future.
<awilkins> I'd just stick to one ; hash function breaks or not I can't imagine people expending the effort
<fullermd> git or mtn would have a little more trouble, since they're build considering the id's as meaningful much deeper down.  Though, to use them as such, we may have to duplicate that much depth of knowledge, so it may not be any better   :|
<awilkins> I mean, you'd have to construct hash collision data for each revision ; together with the delta-i-ness of VCS systems, you'd rapidly have a huge pile of crap in your tree that everyone would spot as a hash attack.
<fullermd> I don't like to guess other than very conservatively the consequences of breaking assumed uniqueness...
 * lamont wonders idly if there is already a bug in the system that bzr status spits out filenames that are only useful if you happen to be in the root of the source tree
<lamont> rather than making them relative to the current working directory
<fullermd> I'm sorry, it's still 3 days until that debate is scheduled to come up again...
<abentley> fullermd: :-)
<LarstiQ> lamont: yes, there is
<abentley> lamont: I don't think anyone disagrees that status should be able to use cwd-relative paths.
<lamont> abentley: it accepts and uses them.  it's the output that's the issue...
<LarstiQ> lamont: https://bugs.launchpad.net/bzr/+bug/30159
<ubottu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed]
<abentley> lamont: The contention has mainly been about whether parent directories and their children should be displayed)
<abentley> lamont: For output, I meant.
<lamont> abentley: not that it helps the arguement, but git does. :-)
<abentley> lamont: In UI terms, Git occupies a similar space to CVS: Git does it that way?  Okay, what would the right way be?
<lamont> abentley: lol
<lamont> like I said, I rather expected it doesn't help the arguement...
<lamont> I rather expect that a naked "bzr status" should show the entire tree, with relative paths, while "bzr status $LIST" should show only the status of the listed files and directories (and children)
<lamont> git always does the full dump, with relative paths
<jelmer> jam: bzr-remove-revisions
<jelmer> LarstiQ: yeah, that should work - you still ahve to use svn-push though
<jelmer> jam: it's pretty specific to knits though, I haven't used it in quite some time
<LarstiQ> jelmer: ok, then it's time to file some bugs I guess.
<jelmer> LarstiQ: please do :-)
<jprieur> Hi guys, any clue about this problem? http://rafb.net/p/TE4SMk67.html
<jelmer> jprieur: hmm, looks like bzr-search relies on bzr-svn being there
<jelmer> I think that's a bug and that the intention was to have an optional dependency on bzr-svn
<kiko-afk> did lifeless' massive VF work land?
<kiko-afk> I'm curious about that one
<jelmer> kiko-afk: yes
<jelmer> at least a very major part of it
<kiko-afk> wooo, that's worth a drink and fireworks
 * jelmer doesn't have time for that sort of thing, I need to fix bzr-svn now that the API is all broken again :-P
<jelmer> (by the vf changes...)
<LarstiQ> jelmer: you're welcome to come hack here, and I'll supply the drink (no fireworks though)
<jam> jprieur: Looking at this http://mail.python.org/pipermail/python-dev/2006-August/068078.html
<jam> It seems that maybe 'bzr search' is trying to import the python files before it actually imports their containing dirs
<jam> so maybe it should do
<jam> import bzrlib.plugins
<jam> import bzrlib.plugins.svn
<jam> import bzrlib.plugins.svn.branch
<jam> But I can't really say for sure
<jam> beuno: do you have your links for the fancy loggerhead with integration to bzr-search?
<beuno> jam, well, gnome is running it: http://bzr-mirror.gnome.org:8080/banshee/trunk/changes
 * Jc2k grins
<LarstiQ> sweet!
<Pieter> hmm, too bad there aren't a lot ofpeople making the right points for git on pgo
<dato> I just read the post from they guy that went, "why not let each project use what they prefer"
<jam> beuno: well, you're making it into 'this week' so all the world will know :)
<LaserJock> anybody here happen to know about the Gnome bzr mirror?
<LaserJock> specifically, is http the only protocol for it?
<Peng> beuno! Just the person I wanted to harass!
<LarstiQ> ok, that's one for the quotes page
<Jc2k> Pieter: i'd love it if they were, then i'd file bugs against the right bits of bazaar
<jam> beuno: anything you would want us to mention?
<jam> We're showcasing your work today
<beuno> jam, one sec, phone, and yes  :)
<Pieter> Jc2k: how about real branch support? :)
<jam> beuno: when you get back, do you have skype? We can bring you in on our call
<Jc2k> Pieter: theres already a bug filed for that as its one the Git GNOME people seem unlikely to let go of
<Jc2k> Pieter: i imagine it will be useful for jhbuild, too
<LarstiQ> Pieter: what is 'real branch' support?
<Jc2k> (whilst looking at your blog) though it will be implemented as a plugin ;)
<Jc2k> LarstiQ: hide everything in one directory and make people switch branches with bzr switch
<LarstiQ> Jc2k: ah, figures, git style branch handling
<beuno> jam, I'll be off the phone in 5', and yes, I have skype
<Pieter> you also currently have to do a "bzr branch http://..." yourself every time someone creates a branch, right?
<Jc2k> or put another way, i only have branches that i care about
<Jc2k> some of the GNOME modules have *lots* of branches
<Pieter> yeah, that's why you use namespaces :)
<Jc2k> (to be honest, i've nearly finished a plugin that pulls *all* branches)
<Pieter> Jc2k: and you can also add git-like conflict resolution
<Jc2k> whats that? isnt there something like that already, with bzr merge --pull ?
<Pieter> with git, files that aren't in conflict are added to the index
<Pieter> so "git diff" will only show you files in conflict
<LaserJock> is there anything faster than bzr branch for creating local branches?
<Pieter> and when you resolved one, and do a "git add file", that one will disappear from the diff too, allowing you to kee ptrack of what cnoflicts there still are
<LarstiQ> Pieter: what part of that are you after?
<Jc2k> Pieter: so basically, you want the index?
<LarstiQ> Pieter: `bzr conflicts` will tell you what conflicts.
<Pieter> Jc2k: yeah, it's great
<LarstiQ> Pieter: I have been using hacked up version of bzr vimdiff that has an option to only diff conflicting files
<jelmer> LarstiQ, heh, some other time
 * jelmer is in Germany
<beuno> back
<LaserJock> oh man, locally branching gtk+ takes almost as long as branching it remotely, that doesn't make much sense :/
<jam> beuno: what' is your user id
<beuno> Peng, your new-style-class-patch went into trunk, so thanks for that
<beuno> jam: pentacorp
<beuno> I should probably open it though
<jam> beuno: I just asked to be your friend
<Pieter> LaserJock: bzr branch is pretty slow, especially if you don't have a rich root
<LaserJock> it's rich-root
<LaserJock> anything that would be faster?
<LarstiQ> LaserJock: are you branching within a repository?
<LaserJock> we're looking at almost 3.5 min
<LaserJock> no
<LarstiQ> LaserJock: or is it the working tree creation that takes tht long?
<LaserJock> the working tree doesn't take too long
<LarstiQ> LaserJock: if you branch within a repository, branch won't need to copy revisions across.
<LaserJock> it's mostly copying history it seems
<LaserJock> LarstiQ: well sure, but I don't have a repository
<LarstiQ> LaserJock: ok, could you confirm it's that?
<beuno> jam, just heard background noise, try again  :/
<LaserJock> LarstiQ: how can I confirm other than watching the progress bar?
<LarstiQ> LaserJock: trying to branch within a repository would do the trick.
<LarstiQ> LaserJock: --hardlink is only for working tree it seems, otherwise I would have suggested that
<Pieter> Jc2k: and also add something to modify history
<Jc2k> Pieter: they are already working on rebase -i
<Pieter> good, and then you also need something like the reflog :)
<Jc2k> eh
<Jc2k> whats the reflog :)
<Jc2k> i know i won't need it for libgitcore, but thats about all :)
<Pieter> it records what your HEAD pointed to in time
<Pieter> so if you switch branches, or use something like rebase -i, you can always get back to a previous point
<Pieter> just in case you didn't want to do the rebase -i anyway :)
<LarstiQ> something likes looms?
<Jc2k> LarstiQ: i think its more like the backwards and forwards in your web browser
<Pieter> yeah, what jc2k says
<Pieter> it means you can always get back to your repository state, however you fucked up
<LarstiQ> hmm
<LarstiQ> Pieter: ah, so git people _don't_ insist on destroying history! ;p
<LaserJock> LarstiQ: ok yeah, without shared repo 3m25s, within shared repo 5s ;-)
<LarstiQ> LaserJock: ok, so the workingtree building really isn't the bottleneck :)
<Pieter> LarstiQ: nothing is ever destroyed in git, just changed :))
<LarstiQ> Pieter: heh :)
<jam> Pieter: unless you run "git gc"
<LarstiQ> Pieter: so when does the reflog record what your head is at?
<LaserJock> LarstiQ: but git takes only ~2s for a git clone :/
<Pieter> LarstiQ: every time it changes
<LarstiQ> Pieter: and how do you navigate it? That would cause a lot of points you're not interested in I'd think?
<Pieter> LarstiQ: merge, switch branch, pull, revert, rebase
<Pieter> LarstiQ: if you do "git reflog", it gives you a pointer to a commit and a time you were there, together with the action that caused your head to be there
<LarstiQ> Pieter: the most recent one? All of them?
<Pieter> jam: yes, but that's after it's gone from your reflog, which stays for 30 days by default
<Pieter> LarstiQ: yes, for the last 30 days
<LarstiQ> Pieter: 'git reflog' gives you a list of all head changes for the last 30 days?
<Pieter> yes
<LarstiQ> Pieter: ok
<LarstiQ> shouldn't be hard to do
<Pieter> :) and proper cherry picking would also be nice
<LarstiQ> hook post_change_branch_tip to record changes, and a command to print them out
<LarstiQ> Pieter: 'proper cherry picking' is a rather ambiguous statement. Does anything but darcs do that?
<Pieter> well, something that keeps commit messages would be nice
<Pieter> and "git cherry" allows you to see which of your commits have been applied upstream
<LarstiQ> Pieter: recodring that a cherry pick happened is something that needed to be done last I looked at it, that is certainly true
<LarstiQ> Pieter: how does 'git cherry' differ from 'bzr missing'?
<Pieter> bzr missing looks at commit id, right?
<LarstiQ> assuming we record the cherry pick
<Peng> beuno: Anyway, I wanted to mention something. My Loggerhead instance finally got hit by Googlebot, so it's been very busy (and almost ran my VPS out of RAM). Anyway, certain annotation pages cause it to traceback with NoSuchId in the tree None.
<Peng> Ew, I said "Anyway" twice.
<Pieter> git cherry also works when you apply patches, for example
<beuno> Peng, ah, can I take a look at the traceback?
<LarstiQ> Pieter: ah, so it's more of a text content comparison?
<Peng> beuno: Hold on.
<Pieter> LarstiQ: yes, it calculates a diff id
<Peng> beuno: URL where it happens: http://snurl.com/2p8ye Log: http://paste.pocoo.org/show/77818/
<Pieter> so upstream doesn't even have to use git for it to work
<LarstiQ> Pieter: what does git cherry identify then?
<LarstiQ> Pieter: when upstream only applies some hunks of your patch for instance
<LarstiQ> Pieter: does it say something like 'incomplete merge of revision foo'?
<Pieter> I think it's all or nothing
<Peng> beuno: (Loggerhead trunk, but bzr 1.5 or so.)
<LarstiQ> Pieter: ok
<LarstiQ> Pieter: is there some document describing all these different missing features you would like to see?
<LarstiQ> Pieter: or do we have to edit the irc log
<Peng> beuno: Also, there's a small inconsistency in the logs: The "built revision graph" message basename()s the branch's name, but most others don't.
<Pieter> LarstiQ: I never wrote it down :)
<Peng> beuno: (Both of which just use self.log.info(), but one of them must be configured differently.)
<beuno> Peng, it seems to be tracebacking in bzr. Do you have that file in the branch?
<Peng> beuno: I have nooo idea. I'd assume I do, since Googlebot found a link to it...
<Peng> Also, this is an obscure one, but you know how LH links to "/MYBRANCH/revision/123"? Googlebot somehow managed to find some links to "/MYBRANCHrevision/123".
<beuno> Peng, right, makes sense. I'll look inyo reproducing it, thanks.
<LarstiQ> Peng: missing slash?
<Peng> LarstiQ: Yes, exactly.
<beuno> hrm
<jam> beuno: posted, thanks for your help
<guilhembi> jam: I posted a comment in the support issue
<beuno> I'll run a spider through my local LH and see how it could get generated
<jam> http://jam-bazaar.blogspot.com/2008/06/this-week-in-bazaar_26.html
<beuno> jam, my pleasure
<Peng> beuno: Thank you for the help. :)
<beuno> Peng, thanks for the feedback  :)
<Peng> beuno: No problem. I'm always happy to break software and whine about it. ;D
<LarstiQ> and you do it so well :)
<LarstiQ> ok, cutting power to replace the electra, bbl
<Peng> LarstiQ: It's a gift. :)
<Peng> Wow, Googlebot tried the bad revision links 300 times. :\
<lifeless> :P
<lifeless> not the smartest bot in the shed I guess
<Peng> It usually requested a page every 1-3 seconds, but after each 500 error, it stopped for a minute or two. :)
<beuno> lifeless, good morning
<beuno> you broke bzr search!
<beuno> (may of not been you)
<lifeless> beuno: oh noes
<beuno> I pulled bzr.dev a while ago, and it blew up: http://paste.ubuntu.com/23183/
<beuno> I assume one of your billion line patches passed PQM  :)
<Peng> beuno: I've got it! The /atom pages are generating the bad links.
<Peng> beuno: Can I fix it? :>
<beuno> Peng, pretty please  :)
<Peng> beuno: http://bzr.mattnordhoff.com/bzr/loggerhead/fix-atom-links should do it, but I didn't test it.
<Peng> beuno: Yeah, it fixes it.
<beuno> Peng, was that related to fileids in any way?
<beuno> (branching)
<Peng> beuno: This bug? No, just missing / in the template.
<lifeless> beuno: oh yes
<lifeless> beuno: hmm, I should do a 1.5/1.6b2 branch of search I guess
<beuno> Peng, alright, I'll try and find out what the fileid issue is then
<beuno> lifeless, bad timing, huh  :)
<lifeless> beuno: not at all; I did warn about massive api breakage for this patch
<lifeless> beuno: it should be trivial to fix; I'm just ensuring I have the latest .dev to test with
<beuno> lifeless, ah, good then. You have your talk today, don't you?
<lifeless> yes
<lifeless> haven't heard from verterok about eclipse shiny :(
<lifeless> but loggerhead is plenty shiny
<beuno> I think he got side-tracked by the BB-to-pg thing
<beuno> lifeless, I'm also going to push the last bit of javascript needed to fix it as soon as I get a few minutes off. It's been a crazy work day today
<lifeless> beuno: oh awesoem
<lifeless> beuno: is it merged to trunk yet ? :P (btw I'm surprised loggerhead is working with bzr.dev :))
<beuno> lifeless, I wish. It will be next week, although it depends on how many things mwhudson can review at once  :)
<lifeless> well, in about 6 minutes he should be online
<beuno> loggerhead works with bzr.div, mainly because I'm using bzr.dev, and fixing anything that breaks as I pull
<lifeless> :P
<lifeless> beuno: but does it work with 1.5 still ? :P
<beuno> lifeless, yeap. Peng is living proof of it
<walkeraj> Hello, the company I work for is evaluating revision control systems, and I've decided to use and then present on Bazaar.  Currently, we maintain a CVS repository, and I was wondering what the best way to work with CVS would be as a single user attempting to evaluate Bazaar.  I've read the docs, and Tailor is suggested as well as the rather awkward sounding (cvs to svn | svn to bzr) method.  What's a good way to evaluate it and still work with the ex
<Peng> (Only because I forgot to set sys.path.0
<Peng> )
<lifeless> walkeraj: your text cut off at:
<lifeless> What's a good way to evaluate it and still work with the ex
<walkeraj> ...existing repository?
<lifeless> I don't think I'm qualified to offer marital advice :)
<Peng> Dammit!
<lifeless> Peng: ?
<Peng> It cuts off at "with the e" for me. My IRC client still has that off-by-one bug.
<Peng> I thought it had been fixed.
<lifeless> walkeraj: I would say tailor, because although its PITA to set up, you need ongoing incremental and that is one of the use cases its designed to do an ok job at
<lifeless> walkeraj: when you actually go to migrate, I'd suggest doing a full fresh conversion with bzr-cvsps-import
<walkeraj> lifeless: sure, but in the meantime, I want to evaluate it as closely as I can to how it would be working in a purely bazaar environment.  What's the difference between using tailor and just creating a new bazaar repository with my CVS-controlled directory (periodically doing checkins on a task-by-task basis)
<lifeless> walkeraj: tailor tries to preserve individual cvs commits
<lifeless> walkeraj: other than that, not much difference
<walkeraj> so, basically, I could do something similar simply by making my CVS-controlled directory a shared repository that I could then make branches from on a task-by-task basis?
<walkeraj> and basically do a bzr merge followed by a cvs merge as each task was completed?  Maybe?  Am I close?
<lifeless> walkeraj: you could keep both in one tree yes
<walkeraj> Hmm.  My terminology is still a little fuzzy then.  So, I have directory under CVS control.  I want that directory to house all of the files and then be able to make "branches" on a task-by-task basis without copying the entire directory each time.  What's the organizational tree for that in bazaar terms?
<lifeless> walkeraj: we have three key objects on disk
<lifeless> walkeraj: 'repository' - stores history details, file texts etc.
<lifeless> 'branch' - stores a pointer into the repository for the latest commit on the branch (the tip), and pointers for each tag, as well as configuration options
<lifeless> 'working tree' - has a copy of editable texts representing the current tree which you can then do things to like: merge, commit, rename, edit etc
<lifeless> walkeraj: you can use a repository created with 'no-trees' containing N branches, and then a single tree (created by bzr checkout --lightweight), which you can 'bzr switch' between branches
<lifeless> jelmer: is there a bzr.dev branch of bzr-svn yet ?
<jelmer> lifeless, yes, the 0.4 branch
<jelmer> there is no non-bzr.dev branch :-)
<lifeless> is 0.4 trunk?
<jelmer> no, trunk is different
<lifeless> jelmer: so I've been running trunk
<lifeless> jelmer: what should I run
<jelmer> 0.4
<thekorn> hi, is it a known bug that bzr sometimes shows a files as (M)odified after a merge although the file did not change, although the file obviously did not change (according to 'bzr status' and 'bzr diff')?
<lifeless> thekorn: no
<lifeless> thekorn: is the tree public ?
<thekorn> http://paste.ubuntu.com/23202/
<thekorn> yes,
<lifeless> thekorn: url?
<thekorn> trying to get the url from launchpad, but its slow
<thekorn> lifeless, merging latest changes from lp:python-launchpad-bugs
<thekorn> into lp:~bughelper-dev/python-launchpad-bugs/intrepid.merge
<walkeraj> I see now (mostly).  So, let's say I create a branch for a particular bug.  That branch is basically just an aggregate of diffs, then?  And bzr switch will then un-apply and apply diffs to change the configuration of files from one branch to another?
<lifeless> thekorn: let me try
<bkor> Pieter: I'd love to get real arguments that are pro Git
<lifeless> walkeraj: bzr is not patch based; the branch is a pointer to a tree - an exact copy of the code a point in time
<lifeless> walkeraj: switch does a transform between two trees, both of which are historical, and preserves any local edits you had
<walkeraj> Okay, so just replace applying diffs then with shuffling files about?
<Pieter> bkor: read above log
<lifeless> walkeraj: sure, handwaving :P
<thekorn> lifeless, ok, thanks, I can reproduce it here with fresh copies of both branches
<lifeless> Pieter: could you paste it somewhere, my router was offline
<Pieter> hmm
<Pieter> that's not very easy in irssi+screen
<lifeless> ctrl-A [, select, enter to copy
<lifeless> switch to console
<lifeless> cat - | xsel
<lifeless> ctrl-A ]
<Pieter> it spans a lot of pages
<lifeless> ctrl-D
<lifeless> Pieter: fair enough
<walkeraj> So, in this use-case scenerio, my CVS directory becomes a working tree with branches, and the repository can just basically reside in that directory?
<lifeless> Pieter: uhm, are there some key points?
<lifeless> walkeraj: yes
<Pieter> http://frim.frim.nl/bzr.log
<lifeless> walkeraj: I suggest having a bit of a play with the tutorial before trying to do this
<walkeraj> Oh for certain
<walkeraj> this is all about getting my terminology straight.
<lifeless> Pieter: you're a gitter aren't ?
<walkeraj> Excellent.  Thanks for the help.
<Pieter> lifeless: http://frim.frim.nl/goodlog.txt
<lifeless> Pieter: I want to get someone who likes git to give bzr-loom a spin, not as a patch assembler, but as a 'all my branches in one spot' workflow
<Pieter> lifeless: I'm actually evaluating git, bazaar and mercurial personally, but I've used igt mostly
<lifeless> Pieter: and tell me what they are missing
<Pieter> *git
<lifeless> not in terms of features(git) - features(bzr-loom), but in terms of (features_used_by_me_in_git - features(bzr-loom)
<pickscrape> Is there an easy way to get bzr to gracefully exit from within a plugin (i.e. without a stacktrace)
<Pieter> I can take a look at it, but I don't think bzr-loom does anything that's by default in Git.. it looks more like something like StGit
<lifeless> pickscrape: you are writing a plugin, and for some command you want to say 'ok all finished now' ?
<lifeless> Pieter: well it offers a single branch object that can contain multiple editable refs
<pickscrape> It's more a case if "Erm, you need to set this up before this will work", but yet.
<Pieter> yes, but they're all dependent or each other, right?
<lifeless> no
<pickscrape>  * s/yet/yes/
<lifeless> pickscrape: if you want to do that, create a BzrError subclass
<Pieter> I thought everything under a current thread gets merged in
<lifeless> pickscrape: give it the message and so on, and raise it
<lifeless> pickscrape: it will show as 'bzr: ERROR: <message>'
<pickscrape> lifeless: Do I need a subclass, or can I just use BzrError directly?
<lifeless> Pieter: there are layers involved
<jelmer> lifeless: looms need a simpler ui to be usable as multiple-branches-in-a-dir thing imo
<lifeless> pickscrape: subclass
<pickscrape> lifeless: ok, thanks.
<lifeless> jelmer: well, I think there is too much tension to use looms directly yes. But I'm trying to evaluate the gap
<lifeless> Pieter: if you do:
<lifeless> bzr branch THING test
<lifeless> cd test
<lifeless> bzr nick test
<lifeless> bzr loomify
<lifeless> that will set you up to play
<lifeless> ui wise, bzr show-loom will list the 'branches'
<lifeless> bzr switch NAME will switch within them
<lifeless> bzr pull/merge/push etc work as normal only affecting the current one you are on (except when you interoperate with another loom, which is one of the reasons that loom-as-loom is not a good answer for multiple-branches-in-a-dir
<Pieter> lifeless: well, then it's kinda worthless, if you can't merge?
<lifeless> what I plan to do is to improve loom for this use case as far as it can without sacrificing the things that make it loom
<lifeless> Pieter: it totally can merge; but doing a merge against another loom object merges the list of branches
<lifeless> Pieter: because it is indeed a collaborative stit
<lifeless> *stgit*
<lifeless> Pieter: anyhow, the idea is to find what things you first cry out for, and what things get in the way (some I know about, see above)
<Pieter> lifeless: ok, but still take a look at that log, there are other things on there too
<lifeless> Pieter: and then reuse some of the code to do a plugin that offers this for people want it
<lifeless> Pieter: doing so
<lifeless> Pieter: so this is how long making a branch of bzr itself takes:
<lifeless> Pieter: cold cache
<lifeless> robertc@lifeless-64:~/source/baz$ time bzr branch bzr.dev sample-Pieter
<lifeless> Branched 3512 revision(s).
<lifeless> real    0m0.957s
<lifeless> user    0m0.672s
<lifeless> sys     0m0.124s
<lifeless> Pieter: I'm really not sure why you say it takes a long time
<thekorn> lifeless, I filed bug 243359 about my 'bzr merge' issue
<ubottu> Launchpad bug 243359 in bzr "bzr merge shows file as modified although they did not change" [Undecided,New] https://launchpad.net/bugs/243359
<Pieter> Vienna:bzr pieter$ time bzr branch 5.0 test2
<Pieter> Branched 2635 revision(s).
<Pieter> real	0m23.254s
<lifeless> Pieter: do you have a shared repo ?
<Pieter> I tried it on the mysql one
<lifeless> Pieter: and was that creating a working tree?
<Pieter> yes
<lifeless> to both ?
<Pieter> to both what?
<lifeless> there were two questions :P
<Pieter> ah
<Pieter> shared repo == rich root?
<Pieter> then, yes
<lifeless> no, shared repo == 'storage area for texts which multiple branches can use'
<lifeless> Pieter: can you pastebin 'bzr info' for me
<jelmer> Pieter, there is nothing particularly faster about rich roots
<lifeless> jelmer: I'm suspecting a terminology clash
<Pieter> I meant I did a git init-repo in the top dir
<Pieter> what's the name for that?
<Pieter> *bzr
<lifeless> shared repo
<Pieter> ah, sorry
<Pieter> then, yes
<jelmer> ah, ok
<lifeless> as opposed to the private repo created by bzr init/bzr branch if there is no shared repo to use
<Pieter> yes, I did that first, but that's unbearably slow :)
<lifeless> Pieter: so, jamesh is working on a plugin to provide better defaults for C projects - a shared repo, etc, with no fuss
<lifeless> Pieter: but thats about better-ui
<lifeless> Pieter: do you have a few minutes for me to show you our existing equivalent to the 'git switch' workflow ?
<Pieter> sure
<lifeless> ok
<lifeless> first, do you have a no-working-trees file in .bzr/repository/
<lifeless> (thats under your shared repo dir itself)
<Pieter> no
<lifeless> touch that file
<lifeless> now, make another new branch
<Pieter> right
<Pieter> that's faster
<lifeless> it should be a little faster :)
<Pieter> because it doesn't create a working tree :)
<lifeless> I think it still checks the whole graph depth
<lifeless> so we can make it faster still
<lifeless> but yes, its doing less work -> faster
<lifeless> now
<lifeless> you need a place to have your source files that you edit
<awilkins> Who's doing the Windows builds?
<walkeraj> I realized I forgot to ask one important question.  Let's take a scenerio where I have a branch, then I do a cvs checkout on the tree, then commit the branch using bazaar. Would that then overwrite the CVS changes leading to a destructive CVS commit?
<lifeless> awilkins: I believe markh will be
<lifeless> Pieter: this place will be a tree, but have no branch itself. and you'll switch it between branches
<awilkins> lifeless: Hmm, I'm building my own at present because the betas don't get packages
<awilkins> lifeless: Do the C extensions change much between versions?
<lifeless> Pieter: anywhere you like - can be outside this repository, or inside - it does not matter
<lifeless> Pieter: do 'bzr checkout --lightweight PATH_TO_ONE_OF_THESE_BRANCHES'
<lifeless> awilkins: they can but we try not to
<awilkins> lifeless: I don't know what it is, but 1.6b2 seems MUCH faster than 1.5, and I'm wondering if it's because I built it myself and perhaps my build has some differences to the officail ones
<lifeless> awilkins: no, its faster
<lifeless> awilkins: http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png
<awilkins> lifeless: Is it mostly import times, or are dirstate ops faster too?
<awilkins> lifeless: I presume those are *nix benches?
<lifeless> awilkins: I don't know exactly where we won
<lifeless> awilkins: mac os X
<lifeless> Pieter: once you've done the checkout
<lifeless> Pieter: you can cd to it
<awilkins> lifeless: It's especially pronounced on the branches I'm working with ; they are not deep in history but they do have a lot of files
<lifeless> Pieter: if you do 'bzr switch BRANCHNAME' where BRANCHNAME is the basename of a sibling of the branch you checkedout (actually, is reachable by ../BRANCHNAME) then bzr will switch without you needing to supply full paths or anything
<Pieter> lifeless: that's nice, but awfully slow
<lifeless> Pieter: well; speed we can improve
<pickscrape> lifeless: those graphs are tres impressive...
<lifeless> pickscrape: thanks
<lifeless> Pieter: how slow is slow? seconds? 10's of seconds? and how different were the branches you were switching between?
<Pieter> it's still running
<lifeless> Pieter: !
<lifeless> Pieter: the checkout, or the switch ?
<Pieter> the switch
<Pieter> pieter$ time bzr switch ../5.0
<Pieter> Updated to revision 2635.
<Pieter> Switched to branch: /Users/pieter/m/bzr/5.0/
<Pieter> real	2m18.943s
<lifeless> Pieter: so should be able to do 'time bzr switch 6.0'
<lifeless> Pieter: without the ..
<lifeless> Pieter: if 6..0 and 5.0 are in the same dir
<Pieter> ah, that's nice :)
<Pieter> I actually did ../ to do tab completion :)
<Verterok> mornin' lifeless
<lifeless> Pieter: thats what I was trying to say above. its a bit awkward to say 'it will just work' :)
<walkeraj> or, in that case, would bazaar see the changes CVS had made to the tree and merge properly?
<lifeless> walkeraj:
<Pieter> lifeless: yeah, I understood, but when I read that, I'd already done the command :)
<lifeless> walkeraj: I don't understand the question
<lifeless> walkeraj: I think this is a case of 'give it a whirl'
<lifeless> Pieter: if you were switching from 6.0 to 5.0 there are huge differences involved. I can say that we know some performance problems int hat area and are working on them now
<walkeraj> did you see the earlier line?  I was talking about, like you said, having a CVS directory acting as a tree.  What I asked was: if I created a branch, then made changes to it, but before committnig those changes with bazaar, did a CVS up on the tree.
<Peng> jam: Quibble: Re http://jam-bazaar.blogspot.com/2008/06/this-week-in-bazaar_26.html, it's "serve-branches.py", with a hyphen, not an underscore.
<lifeless> Pieter: if it was between two 5.x branches then I would suspect a bug
<Pieter> it was 6.0 to 5.0
<walkeraj> would committing the branch then destropy the changes downloaded by CVS to the tree, or would bazaar detect that the tree had changed and merge the branch commit?
<lifeless> walkeraj: bzr will try to preserve your local edits
<lifeless> walkeraj: e.g. a cvs change that you haven't committed into bzr
<lifeless> Pieter: right, try something that isn't three years work or whatever it was :)
<lifeless> Pieter: (that 2m is fixable, but its also not the common case)
<Verterok> g'afternoon beuno :)
<lifeless> Verterok: hey!
<lifeless> Verterok: I'm doing my talk tonight, can I ask for a more recent bzr-eclipse-search screen shot ?
<Verterok> lifeless: I made some small progress (project/workspace scoping) but it's far from what I wanted. how much hours I have untill deadline? :)
<walkeraj> Right, but what I'm saying is: since CVS is date-based, what if someone else committed something in CVS to a file I was editing in a branch, and then I did CVS up on the Tree.  Would committing my changes in the branch (which itself was based off of an earlier version) then overwrite their changes and commit only my branched version to CVS?
<lifeless> Verterok: 5 or so ?
<Pieter> lifeless: it's just that, everything I try something with bzr, I have to wait.. merging is slow, "bzr log" is slow, branching is slow, switching is slow, it's kinda frustrating
<lifeless> Verterok: I guess I need to get bzr-eclipse going too
<lifeless> Pieter: are you primarily working with mysql in bzr ?
<Verterok> lifeless: sure, I can upload some new screens
<beuno> Verterok, I didn't have time to warn you so you could hide   :p
<Pieter> lifeless: I'm testing mysql because the repository I'd convert is about the same size
<lifeless> Pieter: in history, or filecount, or both ?
<Pieter> history primarily
<lifeless> Pieter: ok. so, uhm, can I make some forward looking statements ? ;)
<lifeless> Pieter: also, try 'log --line'
<Pieter> sure
<Pieter> (log --line doesn't show full history, right? only on the 'mainline')
<Verterok> beuno: I read the backlog, so no problem :)
<lifeless> Pieter: yah
<Verterok> lifeless: I'll be glad to help in any means to get bzr-eclipse going
<walkeraj> in other words, if I directly edited a file in the tree with a text-editor (which is basically what a CVS up would do), would a branch merge destroy that change?
<lifeless> Pieter: merging is slow - it can be slow for a couple of reasons; one is having a lot to do; the other is defects in bzr - either code or current disk layout
<lifeless> Pieter: I don't find merging slow for instance:
<lifeless> well, when eclipse isn't starting up I don't find it slow :P
<Pieter> :) I was merging the 5.1 branch to 6.0 in mysql, it takes 12 seconds here, for something that differs only 6 commits or so
 * lifeless waits to get his disk back
<awilkins> Verterok: setupBestAvailableBackend, according to my IDE, is never called.
<lifeless> so this is about 60 commits
<lifeless> 3 conflicts encountered.
<lifeless> real    0m5.464s
<lifeless> user    0m5.092s
<Verterok> awilkins: hi, do you mean in bzr-eclipse?
<lifeless> sys     0m0.256s
<awilkins> Verterok: Unless I need to grab branches for the eclipse plugins as well as the library
<awilkins> Verterok: That could be it...
<lifeless> Pieter: but if I do:
<lifeless> bzr --lsprof-file foo.callgrind merge ../shallow-branch/
<lifeless> I can then pop it open in kcachegrind and fix its speed some more :P
<awilkins> Verterok: I don't see any XMLRPC specific Eclipse plugin branches in LP though
<lifeless> hmm I'm not meaning to say 'fix it for yourself'. I'm meaning to say -
<lifeless> please filea  bug saying its slow with such a callgrind file
<Verterok> awilkins: you 're right, I didn't merge it in trunk yet
<lifeless> and I'll see if there is a low hanging fruit we've missed, or if some of the stuff I know folk are working on will help in the short term
<Verterok> awilkins: I assumed that you need the xmlrpc for your in house project :P
<walkeraj> lifeless: in other words, if I directly edited a file in the tree with a text-editor (which is basically what a CVS up would do), would a branch merge destroy that change?
<awilkins> Verterok: My in-house project is using both the Eclipse UI plugins and the client code
<lifeless> walkeraj: it would not
<lifeless> walkeraj: it might conflict, but it won't destroy
<awilkins> Verterok: Actually, I don't really care about XMLRPC for my client-only code ; it's a couple of status calls and some other bits
<Verterok> awilkins: oh, nice! I didn't know :)
<awilkins> Verterok: But the Eclipse projects have over 3400 files in them and really need a speed boost on the VCS plugin
<lifeless> Verterok: so where are the bzr-eclipse install instructions
<walkeraj> lifeless: so once I start doing this (after the tutorial of course ;), I needn't worry about making destructive cvs commits?
<Verterok> awilkins: I can push my dev branch to lp, so you can use that
<awilkins> That would be much appreciated
<Verterok> lifeless: http://bazaar-vcs.org/BzrEclipse ;-)
<walkeraj> I suppose it would be smart to get updates to my branches before committing them, thus ensuring that they were up-to-snuff with the CVS-controlled tree...
<awilkins> It's not a fast Eclipse RCP anyway ; it's Borland Together and it really doesn't like 3400 class models either :-)
<Pieter> hmm
<Verterok> awilkins: I also have a merge (work in progress) with your eclipse.dev and plugin.dev branches if you are interested
<lifeless> walkeraj: as a design principle, bzr tries to be very obvious about what is going on, and to never ever discard user data
<Pieter> lifeless: I think I found a bug?
<Verterok> lifeless: I can build it as a single plugin/bundle with the search feature, so it's easier to setup (and with the xmlrpc client, so it's a *bit* snapier)
<lifeless> Pieter: cool
<lifeless> Pieter: I love bug reports
<Pieter> lifeless: http://pastie.textmate.org/private/juncspdiusl6alpqjzuxg
<lifeless> Verterok: please!
<Verterok> lifeless: eclipse-3.3, right?
<lifeless> I'm just going for breakfast
<walkeraj> lifeless: I don't mean to be asking fringe use-case scenerio questions here, but I just wanted to make sure I could be reasonably safe testing out baz by basically using an existing CVS directory as a tree.
<lifeless> Verterok: hardy : 3.2.2
<walkeraj> And it seems I can.
<lifeless> walkeraj: well, I would always say test on a clean checkout
<lifeless> walkeraj: because while bzr may be as safe as houses you could still get confused :)
<Verterok> lifeless: mmm....that's old, I'll check what I can do :(
<walkeraj> lifeless: sure.  All I really want to avoid is making destructive cvs commits.  In such a scenerio, would there be any reason to run an update on my branches after each CVS up on the tree?
<awilkins> Verterok: If you have an ongoing merge, that's fine, but I'll probably try to merge my branches with your dev ones locally anyway
<walkeraj> lifeless: or would conflicts still be conflicts either way?
<lifeless> walkeraj: oh, well 'cvs diff' before any cvs commit - standard good practice:)
<walkeraj> hah.  True indeed.
<walkeraj> ok.  Thanks.
<awilkins> Although I have done no work on that log cache, I still think some of the structural changes and API refactoring is worthwhile
<Verterok> awilkins: ok, I have it almost in place, I'll publish those branches if you need them, just ping me
<awilkins> Verterok: I've merged my changes for BazaarClient already, but I'm not sure how well they fit with the new "xml<command>" structure
<Verterok> awilkins: I some of that in a bracnh that is a merge with your java-client-lib code
<jam> Peng: fixed
<Peng> jam: Thanks. :)
<Peng> I just wanted to get this off my chest: Loggerhead is great! Squee!
<awmcclain_> Ug. How do I get bzr to create new branches with group +w?
<LarstiQ> lifeless: hmm, could the axes in http://dropbox.mcubedsw.com/skitchpics/BazaarX_Unit_Tests_1.6b3-20080626-123057.png start at the origin?
<LarstiQ> lifeless: (well, the time one anyway ;)
<LarstiQ> Pieter: thanks for goodlog.txt btw
<LarstiQ> lifeless: where are you at that you're giving a talk?
<Verterok> awilkins: I pushed my dev branch and xmlrpc-integration (which is a merge with your client-dev branch, so it use enum, etc)
<LarstiQ> heya Verterok
<Verterok> hi LarstiQ :)
<Verterok> awilkins: I must warn, all that code is quite bleeding edge :)
<Verterok> awilkins: now pushing my bzr-eclipse integration (that match xmlrpc-integration)
<rick_h_> anyone give me a hand getting the avahi plugin going for bzr?
<rick_h_> when I installed the plugin it went into my plugins dir
<rick_h_> using advertise I get an error that Unable to load plugin 'avahi' from '/home/rharding/.bazaar/plugins'
<rick_h_> and if I try to run setup on the plugin I get ImportError: No module named dbus.server_mainloop
<rick_h_> but I have python-dbus installed as well as python-avahi
<LarstiQ> rick_h_: hmm, only thing I can think of right now is if you installed the dbus service file
<rick_h_> LarstiQ: any hint on where I'm looking for that?
<LarstiQ> rick_h_: yeah, the bzr-dbus README lists all steps involved
<LarstiQ> rick_h_: (and the org.bazaarvcs.plugins.dbus.Broadcast.service is right next to it)
#bzr 2008-06-27
<rick_h_> is htat a differnet plugin?
<LarstiQ> rick_h_: no, that's in bzr-dbus
<igc> morning
<lifeless> LarstiQ: sydney
<lifeless> LarstiQ: http://www.slug.org.au/node/102
<lifeless> LarstiQ: not my graphs. ask Pilky
<lifeless> awmcclain_: uhm, jam: ^ awmcclain_ wants g+w branches ? I don't remember the voodoo
<lifeless> Pieter: hi, interesting
<Pilky> lifeless: did you see what I said earlier to jam, turns out that the 1.3-1.5 results must've been done on my iMac not my MacBook (which really confuses me)
<lifeless> Pilky: no, I didn't
<lifeless> my adsl went offline overnight
<Pilky> ah
<rick_h_> LarstiQ: where are you getting a bzr-dbus README?
<rick_h_> the only files I have are here:http://bazaar.launchpad.net/~jamesh/bzr-avahi/devel/files
<lifeless> rick_h_: thats bzr-avahi :)
<Pilky> I thought I'd done all the benchmarks on my MacBook as I remember taking it back to 1.3 to test the speed, but the results I did from 1.3 today don't match up
<lifeless> Pieter: can you ls . and .. and also do bzr info?
<rick_h_> right, what I'm saying. The error seems dbus related which is why I asked if that was a seperate plugin
<Pieter> lifeless: http://pastie.org/223007
<LarstiQ> lifeless: cool
<rick_h_> ok, checked out the bzr dbus plugin, but now I have two plugins that don't load
<lifeless> rick_h_: :X
<lifeless> rick_h_: can you pastebin the error from ~/.bzr.log please
<LarstiQ> rick_h_: ah sorry, I read 'python-dbus' as 'bzr-dbus', sorry :/
<rick_h_> lifeless: http://paste2.org/p/42752
<rick_h_> I'm tring to use this to get bzr avahi http://blogs.gnome.org/jamesh/2008/02/19/bzr-avahi/
<rick_h_> it looks like it's saying no module named dbus, but "python-dbus is already the newest version."
<lifeless> Pieter: ah
<lifeless> Pieter: what is pwd?
<LarstiQ> rick_h_: ok, now that you have bzr-dbus, did you follow the instructions in the bzr-dbus README?
<Pieter> lifeless: /Users/pieter/m/bzr/working
<lifeless> LarstiQ: this:
<lifeless> File "/home/rharding/.bazaar/plugins/bzr_dbus/activity.py", line 31, in <module>
<lifeless> LarstiQ: should give you an answer
<rick_h_> ah, ok...working on it. This seems like a pita
<lifeless> rick_h_: you should name the bzr_dbus dirctory 'dbus' in ~/.bazaar/plugins
<LarstiQ> lifeless: doh
 * LarstiQ hangs his head in shame.
<lifeless> LarstiQ: ah you see it now?
<LarstiQ> lifeless: the non python symbol naming of the plugin? yeah
 * LarstiQ was too focused on the org.thingy
<rick_h_> crap, that broke everything now
<rick_h_> ok, now I'm getting AttributeError: 'BranchHooks' object has no attribute 'install_named_hook'
<LarstiQ> I think, some code may have bitrotted a bit.
<beuno> mwhudson, got a minute?   I'm can't decide on how to approach something in the new theme
<mwhudson> beuno: not really, but let's hear it
<lifeless> Pieter: some lag here sorry; on the phone
<lifeless> rick_h_: thats a version issue; what bzr version do you have ?
<rick_h_> 1.3.1-1ubuntu0.1
<beuno> mwhudson, heh, well, here goes.  For the diffs, now, as opposed to the current theme, it fits the screen and wraps lines. So we don't have a horizontal scrollbar pushing everything away. This is a problem when long lines of codes don't have spaces to wrap over, because the texts gets hidden under the next div.
<beuno> that leaves me two roads
<beuno> a) add an html tag that will allow me to wrap on some characters like /
<mwhudson> oh, because the diffs have spaces replaced with &nbsp; right?
<beuno> b) don't do this anymore, and push everythign off-screen
<mwhudson> is there a concept of "space that doesn't collapse but still wraps" ?
<beuno> mwhudson, no, no &nbsp; anymore. They make files too big. I'm using <pre>
<mwhudson> i think in the spirit of "not trying to fix everything at once", i favour (b)
<mwhudson> beuno: oh
<beuno> the problem is with lines like: &lt;p class="expand"&gt;&lt;a href="#"&gt;&lt;img tal:attributes="src python:branch.static_url('/static/images/treeCollapsed.png')"
<beuno> no spaces
<mwhudson> mm
<beuno> I can force wraping by adding a tag after each /
<beuno> which would solve it
<mwhudson> <wbr/> or whatever?
<beuno> less work, should look better then off-screen pusing
<beuno> exactly
<mwhudson> well, but that's a total hack though
<mwhudson> what if the long text was long_package_name.long_module_name.long_function_name?
<beuno> right. CSS3 has a fix for this, but we can't use that for few years  :)
<lifeless> mwhudson: so, whats needed to merge bzr-search-integration to lh trunk?
<mwhudson> lifeless: me not having two critical issues to fix today
<beuno> mwhudson, well, we can pick a few characters,  / \ _ .
<lifeless> mwhudson: what issues?
<beuno> lifeless, and, I need to make it less invasive if search isn't installed  (ie, not show the div if no results)
<mwhudson> lifeless: codebrowse using too many file descriptors and the ssh server performance problem
<lifeless> beuno: I don't think the div is such a big issue :P but you're the dev
<lifeless> mwhudson: ooh, fd leakage?
<mwhudson> lifeless: well, not strictly leakage
<beuno> mwhudson, b) takes longer because I have to re-structure everything
<beuno> a) makes the file a bit bigger, which is a but sucky
<mwhudson> lifeless: loggerhead currently keeps a branch object around for every branch it has ever seen
<beuno> but I did remove all those &nbsp;, so we still win
<mwhudson> lifeless: when you're accessing branches over http, this keeps a connection open
<mwhudson> lifeless: so, once enough branches have been browsed, you bump into limits
<mwhudson> beuno: it sounds like you're arguing for (a)
<beuno> mwhudson, I can also add <wbr/> after X characters, which would probably take up less space. On the other hand, it may wrap in less-then-optimal places
<beuno> mwhudson, yes, I like a) right now
<mwhudson> beuno: the general assumption is that it's source code
<mwhudson> beuno: so the whole idea of wrapping it is a bit goofy anyway
<mwhudson> beuno: so i really wouldn't worry about trying to be too perfect here
<beuno> right, I agree from that point of view. On the other hand, a side-by-side view that goes off-screen isn't useful at all
<beuno> ok, so after X characters it is  :)
<Verterok> lifeless: is there any chance that you can install eclipse-3.3?
<awilkins> Verterok: Darn, SaveableCompareEditorInput is 3.3 specific
<lifeless> Verterok: are there packages?
<lifeless> Verterok: hardy is the most recent release...
<Verterok> lifeless: I don't think so :(
<beuno> mwhudson, that's the last big item on my list, so it should be reviewable on monday. Along with search branch, once lifeless makes it work with bzr.dev
<awilkins> There's no hardy package newer than 3.2 (not in official package repos anyway)
<Verterok> awilkins: yes, do you depends on 3.2?
<awilkins> Verterok: Is there an older choice for SaveableCompareEditorInput?
<Verterok> awilkins: write it by hand :(
<awilkins> Verterok: Alas, yes, the release of the UML modeller we use is 3.2 specific.
 * mwhudson has to go away for a bit
<beuno> mwhudson, thanks for the input
<awilkins> Verterok: I may just clip it out, I've been using Beyond Compare for merge editing
<Verterok> awilkins: I can make a ugly but temporal solution of copy/paste the implementation
<lifeless> beuno: search with bzr.dev is orthogonal to merging to loggerhead
<lifeless> beuno: because most folk will have 1.5 or 1.6b2 of bzr
<beuno> lifeless, not if I'm trying to find ways to buy time
<lifeless> beuno: pfft
<beuno> :)
<beuno> and it breaks everything I have indexed
 * awilkins opens Eurpoa
<awilkins> *Europa
<Verterok> awilkins: Ok, if you need the compare feature, I can try to make it a separate plugin
<beuno> but I suppose I can revert...
<Verterok> awilkins: s/need/not need/
<Verterok> lifeless: "installing" eclipse-3.3 it's just unzip it in some place
<awilkins> Verterok: Our comparing is nasty because all the documentation is smunged onto a single line by the tool ; I have an external converter than unpacks it to an HtmlTidy-ed CDATA span and then repacks it after editing
<awilkins> Verterok: Plus the modeller drops dead on files with conflict markers because they aren't valid XML ; so I'm making my users edit conflicts outside the IDE at the moment
<lifeless> Verterok: really? ok I'll look for it then
<lifeless> Verterok: why doesn't http://bazaar-vcs.org/BzrEclipse say 3.3 and where to get it ?
<Verterok> lifeless: the current published plugin is 3.2 compatibly
<Verterok> compatible
<Verterok> but the trunk isn't any more
<Verterok> as awilkins said, it's caused by the compare editor
<Verterok> lifeless: so if you download the "official" plugin, it still works with 3.2
<Verterok> lifeless: http://mirror.calvin.edu/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php
<Verterok> it's a mirror of the 3.3 download page
<Verterok> yesterday, the eclipse folks released 3.4
<Verterok> so, 3.3 download page is gone :P
<awilkins> Verterok: Ouch, if you start dropping it it cascades at least as far as the commit dialog... which I obviously can't do without.
<Verterok> awilkins: the commit dialog too? mmm...that's odd. what is the dependency?
<awilkins> It sets up a diff action
<awilkins> Line 400 : DiffOperation.openDialog
<awilkins> DiffOperation uses SaveableBazaarCompareEditorInput
<Verterok> awilkins: I think we can put that in an interface, and create a extension point for it, toughts?.
<awilkins> That seems fair ; what does it use for 3.2?
<awilkins> I don't think it's a saveable one, but I remember a diff view
<Verterok> awilkins: SyncInfoCompareEditor
<Verterok> awilkins: it's hack and a bit ugly compare editor, but it works :P
<lifeless> argh
<lifeless> http://mirror.calvin.edu/eclipse/downloads/drops/R-3.3.1.1-200710231652/download.php?dropFile=eclipse-SDK-3.3.1.1-linux-gtk-x86_64.tar.gz is not the download
<lifeless> its actually a page about the download. garh garh
<lifeless> Verterok: how do I find out if I have a 64 bit vm ?
<Verterok> lifeless: give me a min. I'll come back with the direct link :)
<lifeless> Verterok: I've found it
<lifeless> Verterok: but I need to know if I have a 32bit for 64 bit vm
<Verterok> ok
<Verterok> lifeless: output of 'java -version' ?
<lifeless> rick_h_: sorry for going silent
<lifeless> rick_h_: bzr 1.4 has that function
<lifeless> Verterok: thanks
<rick_h_> lifeless: ah, ok. So is there some method I should use to pull plugins for the hardy versoin?
<rick_h_> or am I fubar'd unless I update bzr to 1.4?
<lifeless> rick_h_: 'apt-get install' is the usual one :)
<lifeless> rick_h_: some plugins have version specific branches; I don't know if bzr-avahi does
<lifeless> jamesh: ^
<rick_h_> ok, is there a ppa for bzr I can pull 1.4 with?
<lifeless> markh: did you end up chatting to zou_ about installer builds?
<lifeless> rick_h_: http://bazaar-vcs.org/Download
<markh> hi lifeless - not sure who zou_ is :)  I've chatted with Alexander who made the last oens
<markh> I've got a nice new binary build here too, that include the little of tortoise that works
<lifeless> markh: zou_ is a gnash developer, they just switched to bzr
<lifeless> markh: release it!
<markh> yeah, I'm literally finishing it now :)
<markh> so - dumb user question: I've a branch of dvr.dev with a few changes that I'd like to public (ie, not quite ready to propose for merging).  What is the best way to do that?  What would happen if I tried to publish the branch to Launchpad - would it try and upload the *entire* branch?
<markh> bzr.dev obviously :)
<lifeless> markh: well, stacking hasn't landed yet, so yes, yes it will
<markh> so just put a bundle up on some server for people to grab?
<lifeless> normally we'd just upload the branch
<markh> oh - fair enough then - I'll do that!
<awilkins> Verterok: Should the diff use the merge viewer attached to the org.eclipse.compare.contentMergeViewers extension point?
<Verterok> lifeless: another thing, you need the xmlrpc branch of xmloutput plugin
<Verterok> awilkins: I don't fully understand the question, as I remember bzr-eclipse don't  use rg.eclipse.compare.contentMergeViewers extension point
 * Verterok checks
<lifeless> Verterok: eclipse is nearly downloaded
<lifeless> Verterok: what next
<Verterok> lifeless: install xmloutput plugin, but not the trunk, the xmlrpc branch
<awilkins> It doesn't use it, but my question is, should it be just getting the merge viewer from the platform which knows which viewer goes with which kind of file, rather than using the same one all the time.
<Verterok> lifeless: https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
<awilkins> Since there is an extension point for defining which viewer is used (and it's in 3.2 --- 3.4 at least), this may resolve the version-compatibility issue and also make it more flexible (since it should use the best available viewer for a given filetype)
<Verterok> awilkins: ahh, now I get it, thanks :). yes the comapre editor don't do the content comaprsion/merge, they delegate to the platform
<lifeless> Verterok: should it be called xmloutput or xmlrpc in ~/.bazar/plugins?
<Verterok> lifeless: gooood question :D xmloutput
<Verterok> lifeless: once eclipse is up and running, follow the steps in http://bazaar-vcs.org/BzrEclipse/Installation until step 6
<Verterok> lifeless: the url of the update-site should be replaced with: http://guille.beuno.com.ar/bzr-eclipse/bzr-search-site/
<Verterok> awilkins: do you have a link to that extension point?
<awilkins> http://help.eclipse.org/stable/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_compare_contentMergeViewers.html
<Verterok> thanks
<lifeless> wow, the plugin has lots of history/content :P
<Verterok> lifeless: xmloutput or bzr-eclipse?
<lifeless> xmloutput
<lifeless> took ages to branch
<lifeless> 380K
<lifeless> something freaky going on here
<Verterok> that's a lot
<lifeless> Verterok: oh
<lifeless> Verterok: upgrade your branch dammit
 * Verterok check his xmloutput branch
<lifeless> bzr info https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
<lifeless> Standalone branch (format: dirstate or knit)
<lifeless> you want 'bzr upgrade sftp://bazaar.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc'
<Verterok> indeed, doing it ATM. thanks!
<lifeless> Verterok: so, the tarball I downloaded
<lifeless> has an eclipse dir
<lifeless> oh, it fails, its good now
<Verterok> lifeless: it should have a eclipse executable inside
<lifeless> europa
<StyXman> hi all
<Verterok> lifeless: hardy comes with the java vm from sun or the gcj?
<Verterok> StyXman: hi
<StyXman> how can I do a bzr diff while editing the message for bzr ci? it tells me it can't lock...
<lifeless> Verterok: typo: 'Remainin portions'
<beuno> StyXman, bzr ci --show-diff?
<lifeless> StyXman: currently you can't, but as beuno says
<StyXman> beuno: wonderful
 * beuno curses simpletal
<Verterok> lifeless: in the install guide?
<lifeless> in the licence
<Verterok> thanks, fixed
<lifeless> unterminated entity ref ...StringReader@6c618821)
<lifeless> ^ what does that mean
<Verterok> ups, xmloutput not working?
<lifeless> when I click ok after setting the bzr executale to use
<Verterok> when you choose ok, it tries to execute 'bzr xmlplugins'
<Verterok> I missed to check if the output is actually xml
<lifeless>  just ran that in concole
<lifeless> it did not error
<lifeless> however
<lifeless> I have plugins that include " in their strings
<Verterok> I'm using the same version here, let me check
<lifeless> and it doesn't seem to be using CDATA
<lifeless> bzr xmlplugins | xmllint -
<lifeless> -:127: parser error : xmlParseEntityRef: no name
<lifeless>    lan-notify &``. ``lan-notify`` is very useful in local LAN collaboration to
<lifeless>                ^
<lifeless> back in a little, moar caffeine needed
<Verterok> mm...so I should use CDATA for the description
<lifeless> Pieter: ping, when you can, I'm interested in 'pwd' from the checkout please
<lifeless> Verterok: well
<StyXman> moar coffee indeed :)
<Pieter> lifeless: I already pasted that :)
<Pieter> lifeless: /Users/pieter/m/bzr/working
<lifeless> Verterok: its not escaping everything properly; either escape or CDATA
<lifeless> Pieter: sorry, ETHREADLIMIT :)
<lifeless> Pieter: oh! I know
<lifeless> Pieter: 'merge URL' and 'switch BRANCH' dont, unfortunately, share a lookup function
<lifeless> Pieter: I did the switch logic too see how people would like it; they seem to :)
<Pieter> ah.. this is a bit unexpected behaviour though ;)
<StyXman> ktxbye
<lifeless> Pieter: so 'merge 5.1' found '.' as the branch to merge from
<lifeless> Pieter: Totally, I'm filing a bug
<Verterok> lifeless: y'r absolutely right...
<Verterok> applying bzrlib.xml_serializer._escape_cdata
<lifeless> Verterok: I know I am :)
<Verterok> :)
<Verterok> lifeless: pushed to lp (and the branch is upgraded)
<lifeless> I'll repull for kicks
<lifeless> igc: something you might find fun to do; write a 'bitch about knits' patch, like the current 'bitch about weaves' one.
<lifeless> Verterok: 25 seconds
<lifeless> Verterok: vs minutes
<Verterok> lifeless: nice! :D
<lifeless> Verterok: now I get
<lifeless> XMLRPC based client is not available
<awilkins> moar caffeine : Mother Of All Roasts
<lifeless> Verterok: its lint clean now though which is better :)
<lifeless> oh caffeine. be right back
<lifeless> Pieter: and please, get a callgrind file on _anything_ that is slow (after checking here that its not just a case of asking bzr to do lots)
<igc> lifeless: as in grumble if people aren't running with packs?
<Verterok> lifeless: let me think but in the meantime just for the sake of try, restart eclipse :P
<lifeless> Pieter: your slow switch or merge _should_ be faster, its definitely worth gathering data on
<lifeless> igc: yes, packs or something better
<lifeless> igc: which is why just grumble on knits:)
<igc> :-)
 * fullermd looks at all his knit branches...
<lifeless> Verterok: I restarted
<lifeless> XMLRPC based client is not available
<lifeless> back soon
<lifeless> back
 * Verterok just found a bug...in the xmlrpc java client
<Verterok> lifeless: a new build in tic
<lifeless> :P
<lifeless> cool
<lifeless> don't you love new users
 * Verterok have a headless build...so sit and relax
<lifeless> Pieter: bug 243386
<ubottu> Launchpad bug 243386 in bzr "url lookups should be able to use the same heuristic switch does" [Undecided,New] https://launchpad.net/bugs/243386
<Verterok> lifeless: absolutely :D
<thumper> hey guys
<thumper> how many windows users do we have here?
<thumper> just raise hands
 * markh ducks
<thumper> feel free to point at windows users
<lifeless> jam
<lifeless> markh
<lifeless> zou_ who is in #gnash
 * Verterok thinks that bzr-eclipse need more users....and bug reports
<Verterok> lifeless: new build uploaded to the update site
<Verterok> lifeless: Help --> software updates --> find and install --> search for new features to install
<Verterok> similar to the install, and avoid the check for updates of all plugins
<lifeless> still says
<lifeless> "Remainin portions "
<Verterok> lifeless: yes, I fixed that in trunk :P
<lifeless> Verterok: ok
<lifeless> now its been 5 years since I used eclipse in anger :)
<lifeless> I want to point it at bzr.dev, which I have indexed
<lifeless> and try it out
<Verterok> lifeless: works?
<lifeless> doesn't complain in the setup box now
<Verterok> great
<lifeless> search window has 'file, java, plug-in' tabs
<Verterok> lower left --> customize
<lifeless> how do I tell it which breanch to search
<Verterok> you must have it in eclipse, as a project
<Verterok> if you don't want to branch,  it can be imported
<Verterok> create a new empty project
<lifeless> bzr is python :)
<lifeless> does that matter?
<Verterok> nope :)
<Verterok> eclipse treat .py as text files (in case PyDev isn't installed)
<lifeless> so branch as new project
<lifeless> use existing
<lifeless> empty list
<Verterok> there is no previous branch location used from eclipse (no integration with locations.conf yet )
<Verterok> lifeless: you can branch or you can take a shorcut :)
<lifeless> Verterok: k, well - take the things I try as user feedback to consier :P
<lifeless> (it doesn't say 'used from eclipse' :)
<lifeless> Verterok: what should I do?, I can't seem to edit the list ..
 * Verterok fires up a text editor...and start taking notes
<Verterok> lifeless: there should be two options
<beuno> mwhudson, so...  it turns simpletal converts < and > to html, no matter how much I yell at it
<mwhudson> beuno: even CDATA ?
<mwhudson> beuno: that sucks :/
<lifeless> beuno: monkeypatch?
<Verterok> check "initialize a new branch location"
<Verterok> lifeless: wait, you want to use the already indexed bzr.dev?
<beuno> lifeless, I'm trying to avoid that. Though mwhudson would know a magic way around it, that neither me or google did
<beuno> s/Though/Thought
<zou_> bzr commit file1.h file2.cpp
<Verterok> lifeless: to avoid re-indexing the branch, you can go to: File --> new --> Project --> General --> Project and specify a location
<zou_> got message: "bzr: ERROR: Selected-file commit of merges is not supported yet: file1.h file2.cpp"
<zou_> what should I do then?
<lifeless> Verterok: sweet thanks
<lifeless> zou_: you've done a merge from somewhere
<lifeless> zou_: you should just 'commit'
<zou_> lifeless: you mean just "bzr commit"?
<lifeless> yes
<zou_> hmm, but I want to control what I am going to commit.
<lifeless> you've done a merge though
<lifeless> so you already have some other work going in
<lifeless> bzr will link to say that that work was merged
<zou_> yes. here is what I did:
<lifeless> but we don't [yet] allow you to merge just some files from that merge, because the graph of merges is done at the revision level, not per-file.
<zou_> (1)I made some local changes on Gnash yestoday (2)I did a "bzr update" today.
<zou_> Now I want to commit my local changes with "bzr commit file1.h file2.cpp"
<lifeless> had you committed those changes locally?
<zou_> yes. I'v done "bzr commit --local"
<lifeless> so, can I ask why you don't want to commit some of your changes?
<lifeless> oh, markh meet zou_
<zou_> some changes are important. others are just trivial work, eg. indent the sources and add some debugging lines.
<lifeless> zou_: ok. why does that matter though ?
<zou_> I just want to commit the "important changes".
<lifeless> zou_: is it for review? or because some aren't ready? or ... ?
<markh> zou_: hi!  Please don't get your expectations up too far for a first tortoise release ;)
<lifeless> zou_: because all your work is /already/ committed locally
<markh> but its looking quite nice and I hope to have a binary up in a day or so...
<zou_> I don't want to make a new revision for a file without any meaningful change.
<lifeless> zou_: ok. so I would merge all the things in because you have committed them
<lifeless> zou_: but I can help you untangle things if its real important
<zou_> markh:  file marks + update + diff + commit should be enough at the moment.
<lifeless> zou_: and I think you probably want to start using a separate branch to do your own work, because 'commit --local' on trunk is for *things you want on trunk*
<lifeless> zou_: but what you are saying to me is 'I have committed things I didn't want on trunk yet' - and thats an ideal situation to be using a branch
<zou_> markh: and make the installation easier for me, hopefull a single TortoiseBzr.exe would work:)
<zou_> lifeless: I just thought "commit --local" was safe, eg. doesn't interrupt the work of the others.
<zou_> So I "commit --local" a lot without carefull consideration.
<lifeless> zou_: its for offline work on a shared branch, the intent is that what you did becomes part of trunk at the earliest possible opportunity - which is now
<markh> zou_: first cut will have icon overlays but no functinging context menus - so checkins etc are still from the cmdline
<lifeless> zou_: for doing stuff without care, use a branch. Branches are easy to make and work with
<zou_> But before a real commit(commit to remote branch), I have to think for the others.
<markh> it shouldn't take too long to wire that up,m be we decided an earlier release without out it was better
<lifeless> zou_: exactly. you want a branch for this, not commit --local
<markh> One task will be to wrap up the pygtk "worker" applications in a py2exe environment
<zou_> lifeless: OK, step1: bzr branch bzr+ssh://myname@bzr.savannah.gnu.org/gnash
<zou_> step2: local changes.
<lifeless> zou_: or even bzr branch . ../localwork
<zou_> then what should do after that? what are the commands?
<lifeless> zou_: in the new branch, commit to do a commit
<lifeless> merge $TRUNKURL + commit, to get updates from trunk
<lifeless> cd $TRUNK; bzr update; bzr merge $LOCALBRANCH; bzr commit
<lifeless> to take something you did locally and put it in the trunk
<lifeless> you probably want to have your localbranch be the one that your build trees point at
<lifeless> zou_: we can get more sophisticated, but $learning curve
<zou_> what is the URL of my local branch?
<lifeless> zou_: well, if you ran 'bzr branch bzr+ssh://myname@bzr.savannah.gnu.org/gnash' then it would have made a new branch at ./gnash
<lifeless> if you ran 'bzr branch . ../localwork' it would have made it at ../localwork
<zou_> This is what I did:  bzr co bzr+ssh://myname@bzr.savannah.gnu.org/gnash/trunk.  so it's not a branch?
<lifeless> zou_: that does a checkout
<lifeless> zou_: checkouts operate like cvs - when you commit it goes to the thing you checked out
<lifeless> zou_: for clarity - are you talking about the *existing place you were doing commit --local*, or a new one made during this conversation ?
<zou_> yes, but for a cvs rep., I can always use "cvs commit file1.h file2.h" and leave "modifiedy file3" alone.
<lifeless> zou_: yes, and you can in bzr too; but you *already committed* this stuff with --local
<lifeless> zou_: so lets make you a new branch and get you hacking again
<lifeless> zou_: cd to the checkout
<zou_> lifeless: I am taking about the "existing place"
<lifeless> cd to the existing place
<zou_> done
<zou_> and then?
<lifeless> run this command:
<lifeless> bzr branch . ../local-branch
<lifeless> that should be very fast; if its not we can make it faster in future but don't worry about that right now
<zou_> doing now, wait it to be fininshed.
<zou_> finished.
<lifeless> (when I say we can make it faster, I mean that its local configuration, not code-writing, to make it faster)
<lifeless> ok
<lifeless> this new place - local-branch - is where you should do changes and write code
<zou_> cd local-branch
<zou_> so I can do "bzr commit file1 file2" and leave modifidy file3 alone now?
<lifeless> yes, we need to recover the work you don't want to commit first
<lifeless> this needs  alittle python, because I just found a bug in the command that would normally make it real easy
<lifeless> you're on windows aren't you ?
<zou_> yes. Cygwin + windows.
<lifeless> well, lets see if we can use python, otherwise we'll peek at a file quickly on disk
<lifeless> python
<lifeless> >>> import bzrlib.workingtree
<lifeless> if that errors, we'll need to peek on disk
<lifeless> let me know if it worked or errored
<lifeless> (no output is worked)
<zou_> lifeless: I'v typed import bzrlib.workingtree
<lifeless> ok
<lifeless> now
<lifeless> tree = bzrlib.workingtree.WorkingTree.open('../trunk')
<zou_> still after ">>>" ?
<lifeless> (replace ../trunk with the path to your checkout - I am guessing at the relative path)
<lifeless> zou_: yes, the >>> is the python prompt
<zou_> done
<lifeless> tree.lock_read()
<lifeless> print tree.get_parent_ids()[1]
<lifeless> tree.unlock()
<zou_> done
<lifeless> the print statement will have printed out a GUID
<lifeless> exit python now
<lifeless> you should be in local-branch still
<lifeless> run bzr pull -r revid:$GUID ../trunk
<lifeless> this will restore your local work so we can pick and choose bits of it for trunk
<zou_> it prints "zoulunkai@gmail.com-2008xxxxxxxxxxxxx"
<zou_> should I write down the GUID before exit python?
<lifeless> zou_: yah, put that in the bzr pull commit - so 'bzr pull -r revid:zoulunkai@gmail.com-2008xxxxxxxxxxxxx ../trunk' (or whatever it printed)
<lifeless> zou_: if your window will go away yes - or just copy and paste
<zou_> bzr pull -r  revid:zoulunkai@gmail.com-2008xxxxx   ../trunk
<zou_> got message:
<zou_> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<lifeless> zou_: are directory are you in ?
<zou_> I am under the local-branch dir.
<lifeless> cool
<lifeless> add --overwrite to the command line
<zou_> ok, finished. got message: " ....  All changes applied successfully, Now on revision 9425"
<lifeless> cool
<lifeless> now, local-branch has what you were working on before you updated
<lifeless> one last thing to do -
<lifeless> cd to trunk
<lifeless> and run bzr revert
<zou_> I am still under "local-branch" dir. you mean "cd ../trunk"?
<lifeless> yes
<zou_> done "bzr revert"
<lifeless> right
<lifeless> now, to get some changes from local-branch into trunk
<lifeless> you can get them all by doing a merge
<lifeless> but you only want some
<lifeless> so I'm going to teach you how to do a 'cherrypick'
<lifeless> (this is all in the manual btw)
<zou_>  <lifeless> now, to get some changes from local-branch into trunk
<zou_> how to do that?
<lifeless> cd to the trunk
<lifeless> and do 'bzr missing ../local-branch'
<lifeless> this command tells you about commits that can be merged
<lifeless> (it tells you in both directions)
<zou_> got message:  "you have 13 extra revision(s): ....   you are missing 1 revision(s)"
<zou_> I want to commit some of my local changes. Can I use the local-branch dir to do that?
<zou_> commit to the remote branch.
<lifeless> yes
<lifeless> so, from the look of it you've only done one local commit, but you commited several things
<lifeless> so the we have to merge the files you want across:
<lifeless> 'bzr merge ../local-branch/file1.h'
<lifeless> 'bzr merge ../local-branch/file2.cpp --force'
<lifeless> 'bzr merge ../local-branch/file3.cpp --force'
<lifeless> etc
<lifeless> when you are happy, bzr commit
<zou_> bzr update
<zou_> then haven't the changes from remote branch already be merged to my local branch?
<zou_> the merge command is confusing.
<lifeless> zou_: could you rephrase the question, I'm not sure what you mean
<zou_> by using cvs, "cvs update" merges changes from remote rep. to my local rep. automatically.
<zou_> I am not sure when I need a "bzr merge" command.
<zou_> after "bzr update remote_branch"?
<lifeless> zou_: you need merge to move changes between your local 'trunk' directory and your 'local-branch' directory
<lifeless> zou_: the way merge works, is it moves some changes, and then you use 'commit' to record them permanently
<zou_> ok.
<lifeless> zou_: so you need merge in 2 places: after you do 'bzr update' in the trunk directory, you should cd to the local-branch directory and run 'bzr merge ../trunk ; bzr commit -m "merge trunk"' to move changes to the local branch
<lifeless> zou_: and when you have finished some work in local branch and want to put it in the trunk you should do:
<lifeless> cd trunk; bzr update ; bzr merge ../local-branch; bzr commit -m 'details of what you are committing to trunk'
<zou_> very clean, thanks:)
<zou_> clear
<lifeless> happy to help
<lifeless> you guys are taking a big step from CVS to distributed in one step
<lifeless> features like offline commits involve most of the complexity of full distribution, which is why you ran into the wall today
<zou_> another question:
<zou_>  'bzr merge ../local-branch/file1.h'  'bzr merge ../local-branch/file2.cpp --force'
<zou_> why I need the '--force' option?
<lifeless> so the first merge merges one file
<lifeless> and leaves you with pending changes
<lifeless> merge will stop and refuse to operate by default when you have pending changes, because its easy to get conflicts-on-conflicts and other such confusion
<lifeless> so the --force says 'allow me to merge the other file please'
<zou_> I have a 'trunk' dir and a 'local-branch' dir. what is the pending change?
<lifeless> well you are in trunk
<lifeless> and you merge one file - file1.h - from local-branch
<lifeless> that becomes a pending change in trunk
<zou_> yes
<lifeless> because you haven't yet run 'commit' to record it permanently
<lifeless> file1.h is the pending change :)
<lifeless> why don't you try it and see what happenes
<zou_> so, I select the files I want to commit at the "merge" stage instead of "commit" stage, right?
<lifeless> zou_: yes, when you are picking individual changes
<lifeless> zou_: _normally_ most people merge the entire directory - e.g. 'bzr merge ../local-branch', because thats what you usually want
<zou_> No, for Gnash, I do selective "cvs commit" everyday. (cvs commit all_files is dangerous)
<zou_> I touched lots of files during debugging, but many of them are not worthy for committing at all.
<zou_> It's difficult to track back if there are too much revision numbers.
<beuno> mwhudson, ignore my previous comment, you can print html, although it complicates everything for me. It's going to be a few python lines just to print out <wbr/>...
<zou_> lifeless: thanks a lot for you time!
<lifeless> zou_: ah, there are plenty of tools we have to help you here though
<lifeless> zou_: firstly, I didn't say that people _commit_ everything all the time - but that they _merge_ everything
<lifeless> zou_: another thing that you may like is the 'shelve' plugin
<lifeless> this lets you put some changes aside that are not ready to commit (or imappropriate, like debugging stuff)
<zou_> I think windows users need a TortoiseBzr which behaves like the TortoiseCVS, GUI helps me think better:)
<lifeless> zou_: to some degree we will have that soon
<lifeless> zou_: but there are _substantial_ differences in a full-tree system, which is what git/bzr/hg/monotone all are
<lifeless> ok, I'm heading lunch and poolies I think
<lifeless> poolie: see you 3ish ok ?
<zou_> I think I could expect that "selective merge", "selective update", "selective diff" would be very intuitive within the windows file explorer
<lifeless> zou_: well, selective update doesn't exist as a concept in the system; selective merge does but with some caveats; selective diff does
<lifeless> gotta run
<zou_> select the file with your mouse and right click it to choose a context menu to do your action:)
 * igc lunch
<zou_> are all files share the same revision number of a bzr branch?
<poolie> lifeless: 3ish is fine
<zou_> eg. for a cvs-head branch, we can have revsion 1000 for file1, 800 for file2, 2000 for file3.
<zou_> do we have a similar concept for a bzr-head branch? Or all files for a bzr-head branch share the same revision number?
<mwhudson> zou_: a revision in bazaar is a snapshot of the entire tree
<zou_> got it. so we don't have "revision for a single file"
<mwhudson> so, more the second of your two options, but the answer is more "neither"
<mwhudson> zou_: right
<zou_> thanks. Then I understand why I cann't do "selective commit" better.
<Peng> Eek, LH's traceback didn't go in the log.
<mwhudson> Peng: hmm
<mwhudson> sounds like a bug
<Peng> Huh.
<Peng> Want me to file a bug against LH?
<mwhudson> Peng: well, probably
<mwhudson> Peng: what was the traceback?
<Peng> mwhudson: That's another matter. Googlebot has been having lots of fun going through my LH instance today, and certain annotation pages traceback with a NoSuchId in tree None.
<mwhudson> man wtf, _that_ sort of traceback should be in the log i'd have thought
<mwhudson> Peng: interesting
 * Peng shrugs.
<Peng> I'll file a bug.
<mwhudson> Peng: are they reproducible, in that when you visit the urls do they traceback?
<Peng> mwhudson: Yes.
<mwhudson> ok, good (probably)
<mwhudson> Peng: is this public code?
<Peng> mwhudson: URL where it happens: http://snurl.com/2p8ye Traceback: http://paste.pocoo.org/show/77818/
<beuno> ah, that reminds me, I have Peng's patch for broken atom links.  Off to trunk...
<Peng> There are at least 2 pages that cause it to happen.
<Peng> beuno: :)
<mwhudson> i wish googlebot sent referer headers :/
<Peng> Heh.
<beuno> mwhudson, I've been meaning to run a custom spider script I have on LH with a bigg-ish branch, just haven't found the time
<mwhudson> Peng: so i guess the question is: is this a url that should render and explodes, or a link we shouldn't have generated?
<Peng> And I don't have an answer.
<beuno> from the traceback, it seems it blows up in bzrlib, LH seems to pass on an incorrect fileid
<beuno> Peng, how many branches are you serving from LH?
<mwhudson> index.txt-20071121073725-0corxykv5irjal00-1
<beuno> it would be good if we could know which one had index.txt
<Peng> beuno: Um. Maybe a little over 30.
<beuno> and what it's real fileif is
<beuno> *fileid
<Peng> It's in the URL.
<Peng> Hm.
<beuno> Peng, can you run bzr ls --show-ids in that branch?
<beuno> ah, wait a minute...
<beuno> is not present in the tree None
<beuno> the tree should probably no be None...
<mwhudson> there's no file with that file id in bzr.dev it seems
<mwhudson> i don't know how you can tell if there ever was such a file id
<mwhudson> convert the branch back to knits? :)
<Peng> That revid is r3231 of my branch, and probably bzr.dev.
 * mwhudson types the fileid into google
<Peng> yeah
<Peng> There wasn't such a fileid in that revision.
<mwhudson> the file id was fora  file called index.txt in the root afaict
<beuno> maybe bzr-search can help in that area?
<Peng> Heh.
<Peng> Want me to file a bug about the logging thing?
<beuno> please  :)
<mwhudson> and it was removed in r3067 it seems
<mwhudson> ah hah
<mwhudson> ok, this is quite a good one
<mwhudson> in the changelog view
<mwhudson> when a file is removed
<mwhudson> we link the filename to ...
<beuno> aaaaaaah
<beuno> lol
<beuno> interesting  :)\
<poolie> hello beuno
<beuno> hey poolie
<pickscrape> I'm trying to debug bug 56680 (diffstat), but I'm struggling to get bzr to even add the file given in the zip attached to the bug
<ubottu> Launchpad bug 56680 in bzr-diffstat "uncaught exception: bzr: ERROR: exceptions.UnicodeDecodeError:" [Low,New] https://launchpad.net/bugs/56680
<pickscrape> It is complaining thus: BzrError: Parameter ''Lekt\xfcre'' is unsupported by the current encoding.
<pickscrape> Any idea how I get my encoding right to allow bzr to add it? I'm not too familiar with locales etc.
<Verterok> pickscrape: your terminal encoding don't support Â¿utf-8 maybe?
<mwhudson> beuno: should be easy to fix i hope
<beuno> mwhudson, so we should either remove the link, or point to the previous revision
<Verterok> pickscrape: linux + bash?
<pickscrape> LANG is en_US.UTF-8
<pickscrape> Verterok: Yes, Ubuntu Hardy.
<Verterok> pickscrape: try this: python -c "import sys; print sys.getdefaultencoding()"
<pickscrape> Verterok: ascii
<Verterok> pickscrape: and sys.getfilesystemencoding()?
<pickscrape> UTF-8
<Verterok> I get ascii and utf-8 for each one
<Verterok> it "should" work (I recently fixed a similar bug in xmloutput)
<pickscrape> I'm not even at the point of fixing diffstat yet :)
<pickscrape> It's getting it added by bzr that is currently falling over.
<Peng> mwhudson: So..you figured out where the tracebacks were coming from?
<mwhudson> Peng: yes
<mwhudson> Peng: look at http://bzr.mattnordhoff.com/loggerhead/bzr/configobj-4.5.2/changes/3067
<Verterok> pickscrape: the diffstat command class should have a encoding_type attribute
<mwhudson> Peng: expand the first revision, click the link to index.txt
<beuno> mwhudson, linking to the previous revision is probably what the user expects (actually being able to see the file)
<Peng> mwhudson: Okay. That was quick. :)
<pickscrape> Verterok: I don't want to start trying to fix diffstat until I can reproduce the problem, and I can't do that without having a file with unicode characters in its filename already recognised by bzr
<mwhudson> beuno: or just have it not be a link
<beuno> mwhudson, well, that's easier, just would be interesting to know what the user expects
<beuno> Peng?  :)
<Verterok> pickscrape: I understand, but I think you are hitting a new bug :)
<pickscrape> Yay :)
<Peng> beuno: ?
<pickscrape> Verterok: Bug in bzr itself?
<beuno> Peng, what would you want/expect LH to do when a file is removed?
<Peng> beuno: I think linking to the previous revision would be most useful.
<Peng> But having no link at all would be easiest code-wise, obviously.
<Verterok> pickscrape: I hit a similar problem with the 'annotate --xml' command in xmloutput plugin and it was related to the encoding_type attribute
<beuno> of course, moving the user to a previous revision will be very confusing if they want to navigate from that page...
<beuno> how about both?  no link, link beside it, "See index.txt in revision X"
<pickscrape> encoding_type in diffstat is currently
<pickscrape> 'replace', but I'm having this problem with bzr add
<Peng> beuno: That sounds good to me.
<beuno> I'll file a bug for it
<Verterok> pickscrape: do you have a traceback?
<pickscrape> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<Peng> beuno / mwhudson: Thanks for you help. :)
 * Peng points out that tracebacking on bad input is also bad.
<pickscrape> Verterok: http://paste.ubuntu.com/23238/
<mwhudson> Peng: oh yes, there should be a bug for that too
<mwhudson> loggerhead is very bad at validating its input
 * beuno files a bug for that too
<Verterok> pickscrape: indeed it looks like a bzr or env. problem
<pickscrape> Verterok: thanks, I'll raise a bug. Either way it will be either fixed or the solution documented :)
<beuno> I wonder how this removed bug hasn't surfaced through LP
<beuno> anyway, Peng, thanks for all the bugs, and, especially, patches  :)
<Peng> LP has a very restrictive robots.txt, so it won't get triggered by them.
<Peng> beuno: :)
<mwhudson> hm, so i'm little surprised that paste doesn't send uncaught exceptions to _some_ logger
<pickscrape> Verterok: thanks for your help. I need to go to bed now. :)
<Verterok> pickscrape: np, sorry I can't give you more pointer on where to look
<mwhudson> should be easy enough to write some middleware for that though
<beuno> Peng, commit 179 removes the link  :)
<Peng> beuno: Cool. :)
<beuno> but of course, mwhudson deserves the credit for being so smart
<Peng> I'm sure this will make Googlebot happy.
 * beuno goes off to tweak loggerhead-serach a bit better before lifeless's presentation
<mwhudson> Peng: it will keep on requesting those urls for a few years i guess
<mwhudson> :)
<Peng> Heh, true.
<Peng> Well, then, I'm gonna go to bed. Good night, and thanks again. :)
<beuno> g'night Peng
<beuno> lifeless, pushed my loggerhead search changes, UI is a bit better, so I may even try and put it for review tomorrow
<beuno> anyway, that's it for me today. Good night folks
<lifeless> night beuno
<lifeless> beuno: coolness
<beuno> lifeless, good luck with your presentation, and blog about it so we know how it went  :)
<mwhudson> bye beuno
<beuno> mwhudson, good luck with those file descriptors. I'm interested to see what you come up with
<mwhudson> i'm not going to get to it today :(
<lifeless> mwhudson: how have you gone with the ssh server?
<mwhudson> lifeless: we think we have it beat
<lifeless> excellent
<ToyKeeper> Maybe this is crazy, but is there any way to branch a remote repo to a local one, without the complete history?  (perhaps only the past 50 revisions or somesuch)
<ToyKeeper> I keep seeing people complain that they don't want to download a project's entire history before making changes.
<spiv> Not crazy at all.
<spiv> lifeless is working on smoothing off the rough edges of a feature to do exactly that.
 * mwhudson gets ready to stop for the week
<lifeless> mwhudson.suspend()
<AfC> Are we still calling that "shallow branches", or has that become a feature of "stacked branches", or ... ?
 * ToyKeeper tells the users to be patient, since the feature is in progress  :)
<lifeless> AfC: its being touted as stacked
<lifeless> which makes me think entirely non appropriate thoughts.
<AfC> lifeless: that seems ... a less than ideal choice, given that "shallow" creates the impression of minimalism, whereas "stacked" means, well, nothing to do with thin. I can imagine you are thinking inappropriate thoughts :)
<lifeless> AfC: :)
<lifeless> Jc2k: is it git-svn that makes http://bzr-mirror.gnome.org:8080/gtk+/trunk/changes show just a list of names and dates?
<AfC> lifeless: replying on Jc2k's behalf: I don't think so. Contrast revno 16032
<AfC> lifeless: most of the people who hack on GTK whack their ChangeLog entry into the commit message, and so the first line thereof is, well, the usual. The translators seem to not do that, but then there are also GTK hackers who don't either.
<AfC> (whether any one group is or isn't using git-svn to facilitate this behaviour I can't tell you)
<markh> should the bzr binaries for windows set the PyOptimize (sp?) flag, or should I stick with __debug__ mode?
<markh> iirc, most assert statements are gone
<markh> I should see if the test suite completes any faster with binaries built with that flag...
<vila> markh: *all* assert statements should be gone by now, there is even a test for that to ensure they don't come back
<lifeless> AfC: ok
<markh> so there's no good reason to not set that flag?
<lifeless> markh: indeed
<markh> lifeless: thanks
<ToyKeeper> Hmm, I wonder how best to handle svn->bzr conversion.  The tags/ dir has 90% of the files.
<ToyKeeper> I suppose I could just convert trunk/, and manually tag based on when people copied trunk to tags/.
<AfC> ToyKeeper: that would probably work
<ToyKeeper> Yeah, except there's some stuff in branches/ too, and I'd lose that if I only did trunk/.
<ToyKeeper> It's probably better than pulling in tags/ and then having to delete it all though.  :)
<markh> so, finally worked out my ssh problem!  I'm guessing support for plink is new, as that is the problem.  If I disable plink and let it fall back to paramiko, it all works.
<mark1> so it seems we do prefer plink over paramiko even when paramiko exists.
<mark1> (did my last message about my ssh problem make it before I was disconnected?)
<sabdfl> no revisions to pull!
<RAOF> Is there a tarball of a bzr.dev repository somewhere?  My connection just refuses to branch bzr, either from launchpad or bazaar-vcs.org.
<Kinnison> IIRC you can rsync it from bazaar-vcs.org
<Kinnison> Otherwise, get a tarball of a recent bzr and then branch bzr.dev with that
<Jc2k> lifeless: thats just one of the braindead ChangeLog things we have to deal with
<Jc2k> some people put a copy of the changelog entry in the commit
<Jc2k> translators don't, hence the rev AfC pointed out
<james_w> RAOF: is there a bug in bzr you are hitting, or is it just your connection?
<RAOF> james_w: I'm not entirely sure.
<RAOF> When I try to branch bzr I end up getting unknown host errors, so it's probably my connection.  On the other hand, these errors always appear to occur at abount the same point in the branch process.
<RAOF> Kinnison: You'd rsync http://bazaar-vcs.org/bzr/bzr.dev, right?
<RAOF> Of course you wouldn't.  That's not how rsync works :/
<bob2> no, that's http :)
<bob2> rsync -r bazaar-vcs.org::bazaar-ng/bzr/bzr.dev .
<RAOF> Thanks.
 * RAOF was stocastically converging on that.
<Kinnison> :-)
<whs> https://bugs.edge.launchpad.net/bzr.webdav/+bug/243491
<ubottu> Launchpad bug 243491 in bzr.webdav "bzr push ask my password multiple times" [Undecided,New]
<aa_> hi, any doc for using the revision of a branch in a python application as the "version" ?
<james_w> aa_: there is the "version-info" command
<james_w> "bzr version-info --python > _version.py"
<james_w> from _version import version_info
<james_w> version = version_info['revno']
<james_w> or some variation on that.
<aa_> yeah, looks great, thanks
<gour> aa_: hello. how is pida doing?
<jelmer> luks: you rock
<aa_> gour: ! hello, pida is doing fine, thanks
<gour> aa_: cool. i moved to emacs...
<aa_> gour: pida does emacs too :)
<gour> aa_: are the patches applied upstream?
<gour> aa_: i use cvs version
<gour> aa_: ..and moved to bzr
<luks> jelmer: umm, I do? :)
<jelmer> luks, automv
<luks> oh
<james_w> oh yeah, I agree with jelmer, you do.
<awilkins> How do you merge two folders that have been added independantly in different branches under tha same name
<jelmer> I don't think you can since they would have different file ids
<awilkins> When you merge, one gets moved, you want to move files from the usurper into the .moved folder and ditch the usurpoer
<awilkins> I'm finding it a little tricksy
<awilkins> Ok, sorted
<awilkins> Moved the files from the usurper, trashed it, move dhte old one back, resolved
<fdv> Hi. "bzr: ERROR: exceptions.KeyError: 'pop(): dictionary is empty'" on a 'bzr st' is a known error, right?
<james_w> fdv: sounds familiar
<james_w> in tsort.py?
<fdv> yep
<james_w> yeah, would you like me to find the bug?
<fdv> james_w: that's ok, I think I've seen it
<fdv> then I'll just scrap that repo and create a new one
<fdv> but thanks :)
<jelmer> jam: ping
<jelmer> lifeless: ping
<jam> jelmer: ??
<jelmer> jam: Hi!
<jam> does everyone know the moment I log in ?
<jelmer> Lucky guess (-:
<jelmer> jam: I was going to ask you about something but already forgot what it was
<jam> jelmer: well, I'm merging your setup.py change if that was it
<jelmer> I should've asked you about that as well, but that wasn't it
<jam> though you are missing the Copyright and other headers
 * jelmer tries to revive his short-term memory with some coffee
<jam> also, do we want to force "python2.4" what if they have 2.5 installed?
<jam> I realize it is avoiding 2.3...
<jelmer> In my defense it was copied from bzr-email so it's all Roberts fault :-P
<jelmer> Yeah, just using python makes sense now
<jelmer> There's very few systems around anymore with python2.3 as default python
<jam> jelmer: though honestly, I always run with "python setup.py" rather than "./setup.py"
<jam> but I suppose some people do it the other way
<jelmer> Yeah, most people seem to do that
<jelmer> I always get annoyed by setup.py's that aren't executable
<Kinnison> If you're worried about 2.3, do the sys.version hack at the top?
<jam> *I'm* not worried
<jam> some people might be
<jam> but they can just do "python2.4 setup.py"
<Kinnison> kay
<jam> of course, I didn't even have a setup.py script
<jam> I don't believe in needing more than "bzr branch" :)
<asabil> a small question some git fanboys have been asking, and I don't really have an answer
<asabil> why does bzr not use the same repository format as git ?
<james_w> because it doesn't used hash based naming for stuff
<jam> "it" being bzr
<jam> We could use it as a layer, but we would still need a layer on top of it
<jam> It also doesn't store anything like "per-file graphs" etc.
<jam> It just stores "content blobs"
<james_w> the indexes for git packs are better than what we have, mainly because they have fixed length names.
<asabil> hmm oki, thanks :)
<awilkins> How does git reassemble hunks into files, anyone know?
<awilkins> Does it just have "make me a file" hunks?
<james_w> awilkins: it doesn't split files
<awilkins> james_w: Yes, but it has to be able to write files to disk
<james_w> it's "blobs" are full texts.
<james_w> I'm not sure I understand the question then, sorry.
<awilkins> I think it's good that it can do things like track content that was split out of one file into multiple, but what I was wondering is how it knows which file to write the content into
<james_w> oh, it doesn't track that
<james_w> it just guesses after the fact.
<awilkins> If you view the content as one great big stream, are there hunks in the stream that correspond to "swtich context to this file" for exapmple
<awilkins> It can't just guess, or the kernal source would come out as a big blob when you checked out.
<james_w> so if you annotate a file it will also search in other files for the hunks when they disappear (moving backwards through history) and then link them up.
<awilkins> Hmpph, I shall just have to look at the docs if I ever get the time
<awilkins> Or start using it
<jam> awilkins: everything maps sha1sum => content object
<jam> some of these will be xdelta
<jam> with a marker that "I'm based on *this* sha1sum"
<jam> at the top level you have "inventory" blobs
<jam> (I think the git term is "tree")
<jam> And then you have "commit" blobs which reference tree blobs, which reference raw file content blobs
<awilkins> Knew it had to be in there somewhere
<awilkins> So it's hierarchical and not stream based
<jam> awilkins: that is my understanding
<jam> and the reason git repack --as-hard-as-you-can actually works pretty well
<awilkins> I'll trust that more than the back of a cereal packet :-)
<jam> because it just does an xdelta against 50-or-so likely-to-be-close sha1sums
<jam> and grabs the smallest.
<jam> smallest delta
<jam> I don't specifically know how that effects performance on *extracting*
<jam> as it could lead to arbitrarily long chains (unless that is also capped somehow)
<lifeless> jearl: pong
<lifeless> jearl: sorry
<awilkins> jam: It's the kind of realm where speculation is useless and test implementations are everything
<lifeless> jearl: I wanted jelmer how has loged out
<wingo-tp> greetings.
<wingo-tp> i have more traceback nasties.
<wingo-tp> https://bugs.launchpad.net/bzr/+bug/243536
<ubottu> Launchpad bug 243536 in bzr "bzr log fails" [Undecided,New]
<mw> are any bzr developers planning to attend http://guadec.expectnation.com/guadec08/public/schedule/detail/81?
<wingo-tp> i will be there but i am not a bzr dev.
<mw> the feeling i get is that git will be railroaded through, which would be unfortunate
<wingo-tp> the topic seems a bit out of date: there already are git and bzr mirrors.
<Jc2k> mw: there will be 4 at least bzr/canonical guys there, and mark afaik
<mw> jc2k: ah, excellent
<wingo-tp> either one would be fine imo...
<Jc2k> im just amazed at the kinds of arguments the pro-Git people are making
<Jc2k> and they even admit they havent tried anything else
<capiscuas1982> 1 question, one member of my team is trying to push in my bzr branch, is that possible? or it must be a team branch
<capiscuas1982> $  bzr push lp:subdownloader
<capiscuas1982> Enter passphrase for key '/home/leggewie/.ssh/id_dsa':
<capiscuas1982> bzr: ERROR: Cannot lock LockDir(lp-146781388:///~capiscuas/subdownloader/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<capiscuas1982> i don't know how to give him write access to ~capiscuas branch
<Jc2k> wingo-tp: i would be happy to keep subversion, as bzr-svn does a wonderful job
<radix> capiscuas1982: yeah, you'll need to create a team
<radix> capiscuas1982: if you want multiple people to be able to push to the same exact branch
<radix> capiscuas1982: alternatively he can push to his own branch location and you can merge it into your branch
<james_w> Jc2k: it may be that svn would be better that git, as I doubt bzr-git could do as good a job as bzr-svn.
<capiscuas1982> team is already created at ~subdownloader-developers
<capiscuas1982> how can I copy from my branch ~capiscuas into a new branch ~subdownloader-developers ??
<radix> capiscuas1982: bzr push lp:~subdownloader-developers/subdownloader/trunk
<capiscuas1982> radix: i got this bzr: ERROR: Transport operation not possible: http does not support mkdir()
<Jc2k> james_w: my day job is (sadly) to make "libgitcore", (http://git.codethink.co.uk/?p=git;a=shortlog;h=libgitcore). im hoping that might help bzr-git, but im not going to take that route until after GNOME has picked a DVCS
<radix> capiscuas1982: run "bzr lp-login <your username>"
<radix> first
<radix> you should only need to run that once
<capiscuas1982> radix: thks
<james_w> Jc2k: yep, it probably would help, but the friction between the two models might make it difficult anyway. Or perhaps it just needs someone smarter than me to work on it.
<capiscuas1982> radix: it worked, but i'm surprised it didn't ask for my password in launchpad
<radix> capiscuas1982: authentication works with your ssh key
<capiscuas1982> oh yeah
<capiscuas1982> right
<wingo-tp> so
<wingo-tp> anyone have an idea about #243536?
<mw> Jc2k: yeah, they mostly started using git because somebody famous wrote it, suffered hugely for months, finally came to grips with it, and now claim to have no time for anything else
<mw> and now say "oh, but it makes perfect sense once you read 'Git for Computer Scientists'
<wingo-tp> could it be the same as 239499 ?
<wingo-tp> different repos, but both arch-imported...
<wingo-tp> in this case i can't even do a bzr log, which sucks.
<wingo-tp> (jam? :)
<wingo-tp> this is becoming urgent
<jam> wingo-tp: I think it is fixed in 1.6b2 if not there in b3, abentley had the fix
<wingo-tp> jam: it's not
<jam> wingo-tp: I'm checking quickly about it
<jam> hopefully it isn't a huge repo
<wingo-tp> not huge, no; a few hundred revisions
<wingo-tp> thanks for taking a look
<walkeraj> Some clarification.  If I don't use init-repo --no-trees, then each time a branch is created it gets its own copy of the entire working tree, correct?
<jam> wingo-tp: sorry about the delay... "bzr log --short -r -10..-1" works fine :)
<wingo-tp> heh ;)
<wingo-tp> tx jam :)
<wingo-tp> but... hm. we still have a problem :)
<jam> wingo-tp: actually, 'bzr log --short -r 1..-1' also works fine
<jam> Yeah, I see the problebm
<jam> just slowing working out the "outer boundary" of it
<wingo-tp> interesting
<wingo-tp> cool
<jam> the problem is pretty much *just* that the first revision claims to have a parent, but it is a ghost
<jam> so "revision_history" tries to walk off and hits that
<wingo-tp> ah.
<jam> so... oddly enough, we have this "trap" for it:
<jam> self._extend_partial_history(stop_index=last_revno-1)
<jam> which is what abentley did
<jam> ah, ok, so it is now breaking in a different location
<jam> weird, I could have sworn it was breaking there
<jam> anyway, now it is breaking in "tsort" for log --long
<jam> so "bzr log --long -r 2..-1" works, because it doesn't try to include that problematic 1st revision
<guilhembi> jam: hi! I posted on the support issue. Need to run
<guilhembi> bbl
<walkeraj> Hmm, did my last message come through?  This is my first attempt using pidgin for IRC, and I am leery.
<bpeterson> does anybody offer free Bazaar hosting (ie github.com or freehg.org) aside from Launchpad?
<Peng> I'm not sure.
<Peng> On the upside, bzr can work with dump HTTP and SFTP, so you can host it basically anywhere, but that doesn't get you a slick interface.
<awilkins> bpeterson: Cheap hosting by anyone who provides a web host with sftp or ftp uploads :-)   ?
<bpeterson> true. So I could I setup it up easily using the SF webspace?
<Peng> yes
<Peng> The only setup required is "mkdir bzr", then just push over sftp.
<bpeterson> nice although I might just bite the bullet and use launchpad
<Peng> Launchpad is pretty nice.
<bpeterson> It's a pity it doesn't have a wiki, though.
<jam> wingo-tp: well, the quick fix is to edit your ".bzr/branch/last-revision" file and tell it that you only have 138 revisions instead of 139, but I don't know how that will work long term.
<jam> testing
<wingo-tp> interesting
<wingo-tp> i guess i should fix the history at some point, no?
<jam> well, we should support this sort of thing as well
<jam> for example "bzr reconcile" has some code to fix incorrect last revision info, but it fails because of the ghost in your history.
<jam> also, after my "fix" doing "bzr log -r 1" seems to return the first revision as revno 2
<jam> which is just weird
 * vila cries
<vila> ftp... I hate you
<vila> the protocol is messy, the servers interpret it with a crystal ball, trying to run then without being root is a dream, TDD nightmare :-(
<vila> s/then/them/ even
<jam> vila: then don't use ftp :)
<Kinnison> vila: ftp sucks
<vila> jam: Ooooh, *I* don't use it :-) I wanted to add chmod support in bzrlib so that bzr-upload users can enjoy it...
<vila> Kinnison: I know why now :)
<jam> as you wish vila, as you wish.... I've jumped ship a while ago :)
<jam> I honestly appreciate that you are willing to work on it
<vila> jam: I can see that :-/ But well, I have a patch nearly correct, a single test is still failing because it's damn hard to recognize errors....
<jam> vila: both ftp and sftp have *awful* error handling
<jam> you basically can't trust that you'll get anything better than "Failed"
<vila> yeah, that's a shame, I'm now to the point where I wonder if the best solution will not be to issue *more* commands to get better diagnostics which is kind of weird when trying to avoid LBYL...
<jam> well, you could LAYL
<jam> (look after you lept)
<vila> yeah, my point
<jam> though failed is generally failed, even if users want more
<jam> tell them to use something that doesn't suck if they want that
<vila> that could help raising NoSuchFile or DirNotEmpty instead of PathError
<Peng> Nice, Googlebot has used 360 MB of bandwidth spidering Loggerhead, and LP has used 78 MB.
<jam> next you'll be telling me that you will be supporting servers that don't have APPE
<vila> the other problem I have is that the test suite covers more than is strictly needed... so it's a bit hard to decide when a failed test is really relevant :-/
<vila> jam: not worth the effort
<vila> I was hoping that adding ftp servers to the local_test_server plugin will be as easy as http, but... root access required sucks
<vila> I think I will leave that percolate a bit, I'm too much in anger against that mess right now :-)
<vila> I sepdn the whole week on it (part time of course, but yet, several couples of hours) and the conclusion is that, anyway, there are so much requests sent that the performances will always suck
<vila> and all of that to finally implementing chmod in our own test server in a couple of minutes...
<vila> jam: do we really have users for ftp ?
<jam> vila: yeah, we do
<jam> :(
<vila> Well, at least that means our implementation is correct...
<vila> ...correct for our needs :)
<vila> jam: anyway, sorry for the rant, I needed to tell it to someone :-)
<jam> the only bit I've been seeing is the APPE stuff
<jam> rant away
<jam> I didn't like *my* time in the ftp code either
<jam> I'm happier being an ear to rant towards than being the one doing the work :)
<vila> jam: hehe
<vila> I'll get back to preparing my submission :)
<mkanat> What branch format should I be using for new branches that only I am going to be using?
<jelmer> mkanat: rich-root-pack may be a good choice, that's going to be the default in the near future
<mkanat> jelmer: Okay.
<jelmer> otherwise, the default (pack-0.92) should work fine as well
<Peng> If you use pack-0.92, you can upgrade to rich-root-pack later..
<Peng> How does upgrading to a rich-root format work? Does it pick a random file ID for the root? If two people upgrade the same branch, will they use the same ID?
<jam> Peng:  I think it standardizes on "TREE_ROOT" as the file id for the root
<jam> so all trees share the same root at that point.
<Peng> Oh.
<Peng> Okay.
<abentley> jam: it uses whatever root id was already the root id, but 99.9% of the time, that's TREE_ROOT
<Peng> There's a root ID when you're not using a rich root format?
<jelmer> Peng: only that implicit one
<Peng> Ah.
<vila> jam: regarding _can_roundtrip_unix_modebits, did your review implies that we will use it only for our tests and never as part of bzrlib ?
<vila> jam: the underlying question being: can I put it into the test classes instead so that I can query the server too ?
<vila> to be able to test against server with and server without chmod support ?
<vila> hmm, not there anymore, no urgency, since you voted tweak, I can do that in a later patch
<jam> vila: I only "_can_roundtrip" be used in the test suite
<jam> I only *see* ...
<jam> And for example in chroot we do:
<jam> def _can_roundtrip_unix_modebits(self):
<jam>     return self.server.backing_transport._can_roundtrip_unix_modeb
<jam> so you could conceptually do 2 returns based on whether the server can/can't support it
<jam> But logically, it just enables the tests for that action
<jam> if you say "False" then we skip all the related tests
<vila> yeah, I can't imagine using it in bzr anyway, what if it returns False ? :)
<jam> So I don't think there is an advantage to testing across that
<jam> vila: it is just for the test suite, so we can assert that it really does what we want when we pass a mode bit
<jam> If the transport can't support it, it just gets ignored.
<vila> hmmm, I see. So the tests are structured to test the mode bits last so that all other features are already tested.
<jam> vila: right
<jam> if they were *good* tests they would have separated them out
<vila> But, if the server doesn't implement it the tests will fail anyway if we say can_roundtrip
<jam> I wrote them, though, so you are stuck with what you get :)
<vila> jam: good point, now that you said it, I thought about separating them at one point :)
<jam> vila: be my guest
<jam> I think I wrote that code 2-3 *years* ago
<vila> ok, so no problem in putting can_roundtrip into the tests classes instead of the transport classes ?
<vila> so that the server can be queried too if needed
<jam>        john@arbash-meinel.com-20060116213637-2f4cc1c55769f464 |     def test_unicode_paths(self):
<jam> So it seems I wrote it in Jan, 2006
<jam> about 2.5 years ago
<jam> my TDD was not as good then :)
<vila> Ha ! Of course I'll have to write a true ftp.stat() first :-/
<vila> Which demonstrate that you're better TDD hacker now :)
<vila> s/better/a better/
<vila> jam: Do you think that patch can still find its way into bzr-1.6 or is it too late ?
<jam> vila: At this point, I have very little idea of when 1.6 will land
<jam> so if you merge it *today* I think it will get in :)
<vila> hmm, same here :-/
<jam> I can't say much outside of that
<jam> VersionedFiles and stacking is almost done
<jam> the bulk of it has landed.
<vila> Ok, last thing before I go to sleep then...
<jelmer> lifeless, ping
<krow> Hi!  So I just pushed a new tree to Launchpad. I then go and do a bzr branch lp:name from it.
<krow> Then I do a bzr merge /tmp/patch
<krow> That merge pukes on this:
<krow> [brian@piggy drizzle]$ bzr merge /tmp/\[MERGE\]\ bzero\ to\ memset.txt
<krow> bzr: ERROR: Revision {('brian@localhost.localdomain-20080625052913-\xc2\xa06upwo0jsrl4lnapl',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x7f89830956d0>".
<krow> So...
<krow> I know the patch was generated from the recently created tree.
<krow> What am I, and I suspect it is me, screwing up?
<lifeless> jelmer: pong
<lifeless> krow: hi
<jelmer> lifeless: So, I've got --stacked working with your shallow-branch branch
<jelmer> except...
<jelmer> it fetches all revisions
<jelmer> s/working/passing tests/
<lifeless> krow: you created a cherry pick patch, but the reference branch, the one that is expected to be common to anyone applying the patch, has more history than the one you are applying the patch too
<lifeless> jelmer: ok
<lifeless> jelmer: uhm, merge in aarons stuff too
<jelmer> lifeless, where's that?
 * jelmer looks on bb
<jelmer> Re: [MERGE] Stacking policy   ?
<lifeless> krow: so, what (exact) command did you use to make the patch?
<lifeless> jelmer: yes
<jelmer> ah, that includes two of the fixes I had already made locally
<jelmer> lifeless, nope, that doesn't appear to help (though it doesn't break the tests either)
<jelmer> I suspect a bug in one of my FakeVersionedFiles implementations..
#bzr 2008-06-28
<lifeless> jelmer: or possibly an ordering bug in branch --stacked etc
<lifeless> jelmer: uhm find the call point that does the fetch
<jelmer> lifeless: Svn's fetcher is being called before any data has been fetched
<lifeless> btw, if they allow data access, they aren't Fake objects :P
<lifeless> virtual
<lifeless> or svnbacked
<lifeless> but not fake
<lifeless> whats calling the svn fetcher?
<jelmer> heh, true
<jelmer> bzrdir.sprout() iirc
<krow> lifeless: No idea, someone else made it/sent it via email.
<jelmer> uhm, is self._pack_collection.revision_index.combined_index supposed to be accessing fallback repositories?
<krow> lifeless: Thanks... I am going to send back the results to the user to figure out.
<lifeless> krow: so
<lifeless> krow: let me give you a little info
<lifeless> krow: say you have three branches
<lifeless> TRUNK
<lifeless> my-branch
<lifeless> your-branch
<lifeless> 'bzr send' is used to create a patch, which contains a _bundle_ of data
<lifeless> for me to send some commits from my-branch to you
<lifeless> bzr could either give you a full copy of my-branch (bad, lots of data), or we can send the data since some common point of reference that we both share
<krow> ok
<lifeless> so the send command wants a branch that it can use to determine that common point of reference
<lifeless> now, if someone cherrypicks - if they say -r x..y
<lifeless> this *still applies* - because bzr needs enough data in the patch to verify that noone edited it in transit
<lifeless> so it actually includes common_rev..y, but knows that when you merge from it you only want x..y in the merge
<lifeless> I bet that your user did something like this:
<lifeless> 'bzr send . -r x..y'
<lifeless> (where . says 'the SUBMIT_BRANCH is my current branch'
<lifeless> this caused the problem, because bzr said 'oh, *everyone* has all the data, I just need to include the instruction
<lifeless> (rather than finding the common point between 'my-branch and TRUNK' it was the common point between 'my-branch and my-branch'
<lifeless> so the solution is to do 'bzr send -r x..y TRUNK'
<lifeless> and it will all be good
<lifeless> I hope that made sense and will help
<jelmer> lifeless: Is Repository.has_revisions() supposed to be querying fallback repositories?
<lifeless> jelmer: of course, if they are absent locally
<krow> lifeless: It does... I assume there is no way to recover this patch?
<lifeless> krow: not and maintain the commit metadata/revision id etc
<lifeless> krow: if you really just want the textual patch you see at the top 'bzr patch /tmp/patch'
<jelmer> hmm, something funny is happening here
<lifeless> jelmer: here is the stacking expectation:
<lifeless> jelmer: data available locally is used before data available remotely
<lifeless> jelmer: queries are only made for remote data when it is needed
<lifeless> jelmer: few complex queries are preferred over many small ones
<lifeless> jelmer: so whats triggering the fetcher
<lifeless> ?
<jelmer> lifeless: Trying to figure that out atm
<lifeless> 'bt' ?
<lifeless> back in 15-20
<jelmer> you mean, what's starting the fetcher?
<jelmer> or what's causing it to fetch non-tip revisions?
<jelmer> bzrdir.sprout() is starting the fetcher
<lifeless> jelmer: and is the repository stacked at that point?
<jelmer> lifeless: Yes
<jelmer> lifeless, has_revisions() doesn't appear to go to the fallback repository
<lifeless> jelmer: oh
<lifeless> delete pack_repo.py's has_revisions
<jelmer> woot
<jelmer> lifeless, that did it
<jelmer> not that it works, but I get a different error now
<lifeless> jelmer: :P
<jelmer> NotImplementedError: <bound method SvnTexts.get_parent_map of <bzrlib.plugins.svn.versionedfiles.SvnTexts object at 0x8d830cc>>
<jelmer> lifeless: in self.texts.get_parent_map(), is it required to return more than the lhs parent?
<lifeless> yes
<lifeless> if you don't per-file log will be fucked
<lifeless> and check will fail
<lifeless> bbiab
<jelmer> hmm, that sucks
<jelmer> lifeless: It would be nice if there was some way to override build_tree() to just call revision_tree()
<jelmer> rather than using iter_file_bytes(), etc
<lifeless> jelmer: if you need that; patch it :)
<jelmer> heh
<lifeless> jelmer: but really, you should be able to do iter_file_bytes efficiently for merge and other operations as well
<lifeless> going to a movie - laters
<jelmer> lifeless: Merge from svn you mean?
<lifeless> merge from bzr
<lifeless> when the base of any text is in svn
<jelmer> That's always going to be significantly slower
<jelmer> svn's protocol is very tree-oriented
<jelmer> For now, I'll just return None for parents
<jelmer> enjoy your movie!
<jelmer> which one are you going to?
<lifeless> get smart
<markh> jam: you here?
<bob2> hm, the smart server isn't working for me at all at head
<markh> when connecting via ssh to launchpad, I'm seeing 'Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)', then the connection is (successfully) retried.  Is that "expected" (ie, is there any reason to believe the binaries I'm putting together are incorrect because of this?)
<Peng> markh: It's correct. Protocol v3 is very new.
<Peng> markh: (That is, I think it might be even newer than 1.6b2. I'm not sure.)
<markh> Peng: thanks.  I wonder if the binaries I'm making should be from 1.6b2 rather than what is on the head when I happen to flick the switch...
 * Peng shrugs.
<Peng> I use bzr.dev all the time.
<markh> me too :)  Thats something I can decide later though :)
<markh> ssh issues on windows are still driving me nuts too, so I better get back to that...
<Peng> It might be good to package the revision before VersionedFiles, though, since that's a big API change and breaks many plugins.
<markh> these are binaries for windows, where a good plug story remains to be written anyway :)
<markh> by the time we would out to package them reasonably, hopefully they will all then be working again!
<markh> s/would/work/
<markh> does bzr cache passwords used for the "lp:" protocol?
<jelmer> lifeless: W00T
<jelmer> ganieda:/data/tmp/stackable% BZR_PDB=1 ~/bzr/shallow-branch/bzr -Dfakevf branch --stacked svn://svn.gnome.org/svn/gnome-specimen/trunk tr-sp
<jelmer> Initialising Subversion metadata cache in /home/jelmer/.bazaar/svn-cache-exp/203ae883-c723-44c9-aabd-cb56e4f81c9a
<jelmer> using experimental bzr-svn mappings; output may change between revisions
<jelmer> Created new stacked branch referring to svn://svn.gnome.org/svn/gnome-specimen/trunk.
<jelmer> and bzr info actually shows there are 0 revisions in the local repository
 * markh thinks maybe it caches a certificate...
<spiv> jelmer: sweet
<baco> which is the difference between sftp and bzr+ssh schemes?
<spiv> baco: bzr+ssh is a protocol native to bzr.  It runs bzr on the remote end.
<spiv> sftp is just standard sftp, so while it tends to be a little bit slower, it also works with every SSH server, even if bzr isn't installed on the server.
<baco> spiv: like the commits being made locally in bzr+ssh?
<spiv> I'm not sure what you mean.
<spiv> The behaviour is the same, just bzr+ssh tends to be faster.
<spiv> The downside is that it needs bzr installed on the server.
<baco> sftp uses ssh an then ftp on the remote end
<Peng> SFTP is not FTP.
<Peng> It's similar, but it doesn't just SSH in and run FTP.
<spiv> SFTP also doesn't have the weird control channel/data channel split that FTP has.
<baco> let figure it out, with sftp you *put* your files on the remote server, and with bzr+ssh you make an ssh connection, you send a stream which is captured an then piped to bzr to make the commit real on the remote end?
<Peng> It's not that simple, but basically yeah.
<baco> then, on server side, the auth via ssh is the same, but in bzr+ssh you also need the command line client installed
<Peng> Yes.
<baco> the only options now working for auth on the server side are the provided by apache via http or ssh via ssh ones?
<Peng> Yes.
<baco> tnx
<baco> I've been trying thins on launchpad, does the setting of the main branch affect the repo in any way? I mean, you really set that on the repo, or is just launchpad magic?
<Peng> If I understand you correctly, it's just Launchpad stuff.
<baco> So, there's no way you set a branch as the default or main one so when you branch the repo url you get only this branch in a normal setting
<spiv> baco: you don't branch repos, you branch branches :)
<baco> ok, I usually, but not on lp, I mean you have the option not to
<Peng> What?
<baco> that in launchpad you have the option of branching a project, which is a repo, and it gives you one branch, the one has been declared as the main one
<lifeless> hi spiv
<lifeless> jelmer: congrats!
<jelmer> spiv, lifeless: thanks
<jelmer> lifeless: There's no rich-root-stackable format yet, right? I'm using devleopment-rich-root for now
<lifeless> jelmer: thats stackable yes
<jelmer> argh, it's getting late
<lifeless> jelmer: there is no non-development stackable if thats what you are asking
<jelmer> I meant development-subtree
<lifeless> jelmer: hmm, we should add that
<lifeless> jelmer: patch it up :P
<jelmer> heh, some other day maybe :-P
<lifeless> jelmer: still, fantastic news
<baco> Peng: am I right?
<lifeless> jelmer: should be trivial yo add development-rich-root
<jelmer> Performance on operations like log in this branch is pretty terrible right now, though that was to be expected
<lifeless> jelmer: so we need to fix that; log --short shouldn't be terrible though
<jelmer> lifeless, it's worse than usual though
<jelmer> as it's accessing these objects as XML
<jelmer> rather than calling get_revisions() directly, avoiding a conversion back and forth
<lifeless> jelmer: yeah; so stacking in a semantic fashion is actually significantly more work, as every layer needs to be taught
<lifeless> jelmer: and every api needs to be stack-aware
<jelmer> yeah
<jelmer> lifeless, I also had to disable packrepo's get_parent_map implementation btw
<lifeless> jelmer: right, please turn those into patches
<lifeless> jelmer: they should not be needed with the thinner layers of VersionedFiles
<Peng> bac: No. You only branch branches, not repos.
<Peng> bac: Are you talking about "lp:" URLs?
<Peng> Augh, crap.
<baco> Peng: yes
<Peng> I'm sorry, bac. I meant baco.
<baco> understood :-)
<bac> Peng: np  :)
<Peng> Usually it's safe to tab-complete three characters. Whoops.
<baco> LOL
<Peng> baco: When you use "lp:myproject", the launchpad plugin (which comes with bzr) translates that to bzr+ssh://you@bazaar.launchpad.net/~you/myproject/trunk or whatever branch it refers to.
<Peng> baco: This has nothing to do with repos having default branches or anything.
<baco> Peng: ok, tnx
<jelmer> spiv: It looks like a python clone is significantly faster now, btw
<spiv> jelmer: sweet
<jelmer> spiv: about 1500 revisions in the first 5 minutes (not involving stacked branches)
<spiv> Not bad!
<lifeless> jelmer: if you support texts properly now
<lifeless> jelmer: try bzr-search, and disable 'revisions_only' for svn
<pfharlock> if I wanted to remove a change that happend awhile back (say the repo is on version 11) and I wanted to undo whatever happened in rev 3, in svn I would do something like svn merge -r 3:2 followed by any tweaking and then commit.  What would be the best way to do this in bazaar?
<lifeless> pfharlock: exactly that
<lifeless> but with .. instead of :
<pfharlock> yeah, but when I try bzr merge -r 3..2 it doesn't do what I would expect
<lifeless> pfharlock: what does it do ?
<lifeless> pfharlock: oh, you probably want 'bzr merge -r 3..2 .'
<pfharlock> well the revision in question I added a file, I would expect the file to be marked for removal
<pfharlock> oh, what does the . do
<lifeless> its merges from the current branch
<lifeless> rather than from the parent branch
<pfharlock> duh
<pfharlock> thanks
<pfharlock> let me try that
<lifeless> jelmer: oh, just remembered, I haven't dont VersionedFiles for bzr-search yet.
<lifeless> jelmer: I will today probably
<pfharlock> yes, that worked like I expected, thanks a bunch
<lifeless> cool
<pfharlock> if I wanted to pull the history/log or an entire repository, not just a branch, is there a way to do that, either builtin or through plugin?
<pfharlock> s/or/of
<pfharlock> I've been contemplating writing a script to do it if one doesn't already exist
<lifeless> there are plugins
<lifeless> the underlying api can do it of course, but unreferenced revisions are just garbage pending gc
<markh> jam: ping
<pfharlock> you'll have to forgive me, I'm not familiar with bzr's internals, but that's interesting, if you delete a branch with a bunch of revisions, they'll be removed from the shared repo automatically after awhile through garbage collection?
<lifeless> pfharlock: yes, we don't guarantee preservation or timely gc, what we do guarantee is that referenced data is preserved, and unreferenced data is not cloned
<lifeless> on my TODO is to write an efficient gc to give people direct control over this in case they need it
<pfharlock> wow, that's pretty cool, other than deleting a branch, what could cause a revision to become unreferenced?
<pfharlock> I would guess that uncommit might do it
<Odd_Bloke> pfharlock: Rebasing, I think.
<pfharlock> ok, that makes sense (not knowing how the rebasing plugin does it's magic :)
<Odd_Bloke> pfharlock: Yeah, I only have vague recollections, but it's the sort of operation that might. :)
<lifeless> uncommit
<lifeless> and rebasing
<pfharlock> as to repo-wide log, one of my common use cases is not remembering where something is I know I worked on months ago and searching the logs looking for whatever it is.  I realized the other day that if I wanted to duplicate this workflow that I use from subversion to bazaar I would need to get history from the whole shared repo.
<pfharlock> I'm not sure what the best way to order the logs would be, my thought is that organizing it chronologically would probably be best.
<lifeless> pfharlock: hmm, I would say 'bzr search' :)
<pfharlock> cool, thanks, I'll give that one a try :)
<lifeless> pfharlock: its a plugin, it currently searches per-branch
<lifeless> pfharlock: but once indexed the searches are subsecond
<pfharlock> yeah, I'm looking for repo-wide, but if it's close to what I need, maybe I can modify it to be repo wide
<lifeless> yup
<lifeless> the index is agnostic as to where content comes from
<pfharlock> would be a good primer on how to start programming for bzrlib
<lifeless> so you should be able to quite easily tweak it; and I'd be happy to accept any patch (though I might ask for tweaks to fit in with $plans)
<pfharlock> very cool :)
<pfharlock> if I get anywhere with that I'll get in touch, are you the author of the search plugin?
<lifeless> sure am
<pfharlock> cool, well thanks for all the help, it's greatly appreciated
<Odd_Bloke> For anyone who's around, I'm going to be sending an email tomorrow asking for input on what I should be working on for PQM this summer.  Already on my list are XMLRPC submissions and getting rid of the crufty VCS abstraction.  Existing ideas (from the London sprint) are at http://bazaar-vcs.org/SprintLondonMarch08/Brainstorms#head-f2678f1f3acd54a5199c577538301a91be6f7915-2 but I'm looking for some idea of which of those are most important.
<Odd_Bloke> And with that wall of text, I shall head to bed.
<lifeless> Odd_Bloke: pqm's bugs are a good place to look too
<dbmoodb__> hi i'm new to bzr i ran bzr branch lp:bzr-search .... so i now have what-- i'm trying to use what i just got
<dbmoodb__> yes i am an idiot
<dbmoodb__> don't worry i am an idiot
<dbmoodb__> fixed
<AfC> dbmoodb__: no need to beat up on yourself. Everyone has to learn things the first time at some point.
<lifeless> dbmoodb__: hi
<dbmoodb__> oh hi
<dbmoodb__> ah to use your nice little thing what do i need to do. i'm new to bzr and wanted to have a play. i can't use python2.5.
<lifeless> thats fine, 2.4 should be enough
<dbmoodb__> what are the packages required for bzr search ?
<lifeless> have you got bzr installed ?
<dbmoodb__> yes
<lifeless> what version?
<dbmoodb__> but i have python2.5 installed prior to this and hardy is trying to use python 2.5 even tho your setup says 2.4 i think
<lifeless> oh
<lifeless> ignore the setup.py for the plugin, thats for distro's that want to install it system
<dbmoodb__> Bazaar (bzr) 1.3.1 Python interpreter: /usr/bin/python 2.5.2.final.0 Python standard library: /usr/lib/python2.5 bzrlib: /usr/lib/python2.5/site-packages/bzrlib
<lifeless> wide
<dbmoodb__> k sure i couldn't get that to work either :)
<lifeless> dbmoodb__: it will work with 1.3.1 but print an error on every bzr command; if you can upgrade to 1.4 or newer that would be a good idea
<lifeless> dbmoodb__: are you using ubuntu?
<dbmoodb__> this is ubuntu hardy yes
<lifeless> ok
<lifeless> if you add
<dbmoodb__> launchpad repo yah ?
<lifeless> deb http://ppa.launchpad.net/bzr/ubuntu hardy main
<lifeless> so your /etc/apt/sources.list
<lifeless> it will give you the current release of bzr
<lifeless> which is 1.5
<dbmoodb__> lifeless: ok sure..... it would be nice to use it with what i currently have tho
<lifeless> dbmoodb__: unfortunately I haven't written the backwards compatability stuff needed - 1.5 is disk and network compatible with 1.3 though. Is there some reason to stay on 1.3 ?
<dbmoodb__> lifeless: so it will work with what i have just produce an error ?
<AfC> dbmoodb__:  you're going to use Bazaar you might as well use the latest release. The version you will find published there will be significantly better than whatever was around when Ubuntu last froze its package set.
<lifeless> dbmoodb__: yes
<lifeless> dbmoodb__: it will also not auto-update the index when you commit/push/pull
<lifeless> dbmoodb__: but if you're happy with those caveats then its ok by me :)(
<dbmoodb__> lifeless: because thats in my release. sigh its still dev so ok !
<dbmoodb__> i will add packages that have no gpg auth :)
<lifeless> dbmoodb__: ah I see. we're going to get a backport done
<dbmoodb__> lifeless: its still dev don't worry. but what you were saying was that it previously was using cron jobs and things.
<lifeless> dbmoodb__: still; you don't have to upgrade to 1.4/1.5, its only a recommendation
<dbmoodb__> that was because of the old bzr ?
<dbmoodb__> lifeless: i have done it.
<lifeless> dbmoodb__: *loggerhead* used to need all sorts of nastiness
<lifeless> dbmoodb__: ok.
<lifeless> https://edge.launchpad.net/bzr-search
<lifeless> has install instructions for bzr-search
<lifeless> (mkdir -p ~/.bazaar/plugins
<lifeless> bzr branch lp:bzr-search ~/.bazaar/plugins/search
<lifeless> )
<dbmoodb__> do i have to be in the directory of the folder i am searching ? i see no option to search within an index that i have made
<dbmoodb__> lifeless: yes but that page is hard to come by actually perhaps put an install / info in the read me (i know its dev just suggesting)
<lifeless> dbmoodb__: yes, for the command line, cd to the branch you want to search -
<lifeless> I'll add those to the README
<dbmoodb__> lifeless: ok i wish to request a database of the indexes / file that says which indexes you have so one can autocomplete / use dirs / blah to search using your tool.
<dbmoodb__> again -- i know its dev
<lifeless> dbmoodb__: let me see if I understand
<lifeless> you want a global list of the branches that you have indexed ?
<dbmoodb__> that would be nice. given you intend for this to be networkable no ?
<lifeless> well, it is networkable already using the same model bzr has
<dbmoodb__> well autocompletion would be nice (of the ones you have done and perhaps a few suggested projects
<lifeless> so, what would the global list help you do ?
<dbmoodb__> lifeless: tab complete ?
<lifeless> dbmoodb__: so, you're saying you could 'cd ~', 'bzr search -d <TAB>' - and it would list places you could search?
<dbmoodb__> perhaps.
<lifeless> I'm just trying to understand the use case
<lifeless> I mean
<lifeless> imagine you hack on openoffice, binutils and gcc
<lifeless> you'll have branches of them that you edit code in
<dbmoodb__> lifeless: it was a suggestion that is all. if you use firefox you can see how useful it is. however in this case there probably aren't that many things
<dbmoodb__>     data, consumed = self.encode(object, self.errors)
<dbmoodb__> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 21: ordinal not in range(128)
<lifeless> dbmoodb__: can you get the backtrace from ~/.bzr.log ?
<dbmoodb__> sure thing
<Peng> (and don't paste it all in the channel!)
<lifeless> dbmoodb__: I think what I'm saying is that the issue with finding previously used branches is much broader than bzr search
<dbmoodb__> Peng: i only pasted that small amount and i was afriad of being kicked. sorry i will just query to paste this time
<lifeless> dbmoodb__: http://rafb.net/paste/
<Peng> dbmoodb__: Sure, pasting 2 lines is no problem. I was just making sure.
<dbmoodb__> http://rafb.net/p/UEdy7J89.html
<lifeless> dbmoodb__: ah ok
<lifeless> dbmoodb__: your console is ascii
<lifeless> dbmoodb__: but the search result was unicode, and it can't show it to you
<lifeless> dbmoodb__: I'll file a bug for this; have you considered using a UTF8 locale ? (or perhaps I'm not analysing the error right).
<dbmoodb__> http://rafb.net/p/o7XV9H92.html -- full thing. lifeless well my locale is the one setup for me by ubuntu isn't that utf8 ?
<lifeless> ah yes, you do have UTF8 local
<lifeless> ok, something different, one sec
<lifeless> can you edit home/X/.bazaar/plugins/search/commands.py
<dbmoodb__> yes. how so ?
<lifeless> on the line before self.outf.write(" Summary: '%s'\n" % result.summary())
<lifeless> insert
<lifeless> print type(result.summary())
<lifeless> print result.summary.decode('utf8')
<lifeless> run it and pastebin the output
<spiv> lifeless: the repr might be useful too
<spiv> (And is usually ascii-clean)
<lifeless> spiv: I'm betting I have utf8 data I'm tossing at outf
<lifeless> but its doing implicit decode(ascii(
<dbmoodb__> lifeless: it doesn't like my indentation :(
<lifeless> dbmoodb__: use spaces and not tabs, and line it up with the 'self.outf' line
<dbmoodb__> http://rafb.net/p/9scZU348.html
<dbmoodb__> i hate spaces
<lifeless> oh, result.summary().decode('utf-8')
<dbmoodb__> add the ()'s that all ?
<lifeless> yes
<dbmoodb__> sorry that doesn't work either
<lifeless> ok, I'll do it and make a patch
<dbmoodb__> good because i don't want to learn a language where space is used over a tab :) (just kidding)
<spiv> dbmoodb__: python lets you use tabs or spaces for indentation, it just doesn't like you to mix them... bzr's code chooses to use spaces.
<lifeless> dbmoodb__: ok, cd to the ~/.bazaar/plugins/search, and do 'bzr pull lp:~lifeless/bzr-search/debugging'
<dbmoodb__> hum i think i'm going to look up a c++ project. run "bzr launchpad-login YOUR_ID" lifeless another time
<dbmoodb__> wait i don't have to login do i ?
<lifeless> dbmoodb__: no
<lifeless> dbmoodb__: its just spam
<lifeless> that branch will print debug output
<dbmoodb__> ko
<lifeless> oh, you'll want to do 'bzr revert' after the pull
<lifeless> because your edits will conflict
<dbmoodb__> still get an error.
<lifeless> thats to be expected
<lifeless> the output should help me determine the cause and fix it for you
<dbmoodb__> if i was to guess. it is because you are using weird characters that cannot be printed on my screen.
<dbmoodb__> rofl ah dude it think you need utf_8 ?
<lifeless> dbmoodb__: could you paste the output please?
<dbmoodb__> will do
<dbmoodb__> http://rafb.net/p/LTcKpa44.html
<dbmoodb__> wait are you using a null character some where ?
<lifeless> its not what I'm using
<lifeless> its whats been indexed
<lifeless> what you searched for found a hit in a .png file
<dbmoodb__> lovelly :)
<dbmoodb__> but i'm in squid3 i got that too. that is what i'm indexing and searching
<lifeless> so, what I need to do is to upcast the byte sequence of the summary
<lifeless> or something similar.
<dbmoodb__> perhaps you should check the magic numbers of files and get only the relevant ones ?
<lifeless> dbmoodb__: perhaps
<lifeless> though images can be relevant :)
<dbmoodb__> yes if you like to hide stuff
<lifeless> - they can have comments in headers and so on
<dbmoodb__> sure sure. but ah there isn't going to be a bug in the image header. lest the end is nigh
<lifeless> sure there can be
<dbmoodb__> "can"
<dbmoodb__> i can fly.
<lifeless> all it takes is a header style that is not printable cleanly
<lifeless> squid includes images in its source too
<spiv> Definitely there can.  Metadata in images can include things like attributions for the author(s), and that sort of data can be wrong and get corrected.
<spiv> I can imagine less trivial examples too.
<dbmoodb__> spiv: yes and no. my point is at least identify the file and not try to get stuff from image files / not print it if it can't do that
<lifeless> dbmoodb__: I'm writing the code now to print it safely
<lifeless> dbmoodb__: code takes a little time
<dbmoodb__> i know
<Odd_Bloke> lifeless: You should consider a dependency on libaa, to display image search results. ^_^
<dbmoodb__> i use debian etch lifeless as my primary os :)
<dbmoodb__> have fun fixing it up lifeless.
<bob2> woo, the smart server thing got fixed already
<gour> igc: hello, any questions on reading?
<igc> gour: not yet - I'll read them this weekend but I'm yet to do so
<gour> igc: good. keep up the good spirit ;)
<Edulix> hi
<Edulix> why bzr doesn't let me commit if I'm not exactly in the last revision of the repository ?
<Edulix> I mean, I was committing to a file that had not even changed in the new revisions......
<Edulix> it doesn't make sense to me
<matkor> commiting to old revision of checkout would have to make branch , right ?
<matkor> so if you want stay as checkout , update checkout and than commit your changes
<Edulix> I want to commit it to trunk no to an old revision
<Edulix> whatever, subversion would have allowed me to commit it for example :P
<Edulix> without branching
<matkor> or if  you want to make branch, unbind checkout , and commit to yours created branch
<matkor> svn is different than bzr
 * gour is glad that it is
<gour> *err, i'm glad taht bzr is different than svn :-D
<matkor> let's agree to: bzr and svn are different ;)
<Edulix> well yes they're different xD
<bjacques> So I have a mirror checkout and I created a branch from the checkout. Now I made various commits to the branch, and I'm merging them into the checkout. Now, if I merge my changes, will the commits (including commit messages) from the branch also be imported into my local checkout?
<matkor> bjacques: in checkout you see all messeges from branch
<matkor> so if you merged to branch you will have full history
<bjacques> great, thanks
<bjacques> matkor, so how does this work? I merged my changes to my mirror checkout and then committed the result to the 'main' repository. My commit shows up as a single commit with only the brief summary I gave in the final commit stage.
<radix> bjacques: if you 'bzr log', you'll see all your revisions indented underneath the merge revision
<radix> bjacques: all the revisions are there
<matkor> bjacques: you can use also bzr-gtk to see graph of revisions ...
<bjacques> ah, I see, I guess it's just the web interface that doesn't show them
<bjacques> explicitly, anyway
<bjacques> thanks for your help guys
 * LarstiQ frowns at libapr
<enobrev> having a bit of trouble getting trac-bzr working on win32.  i can import tracbzr fine in the python console.  i've added the [components] section to the ini with "tracbzr.* = enabled"  I've set my repo type to "bzr", but I'm still getting 'Unsupported version control system "bzr"'.  Anyone familiar?
<LarstiQ> enobrev: I've never tried trac-bzr on win32 I'm afraid
<enobrev> hmmm... anyone? thanks LarstiQ
<LarstiQ> enobrev: are trac and the normal python console using the same sys.path?
<enobrev> good question
<enobrev> LarstiQ any easy way to figure that out?
<LarstiQ> enobrev: for starters, is it the same interpreter?
<enobrev> only have py2.5 on my system.. single install
<enobrev> (2.5.1)
<LarstiQ> ok
 * LarstiQ has a gander
<LarstiQ> enobrev: have you tried increasing the logging level?
<enobrev> LarstiQ doing that now
<enobrev> this could be it.. though im not quite sure how to resolve
<enobrev> 2008-06-28 10:46:01,030 Trac[loader] ERROR: Skipping "bzr = tracbzr.backend": (can't import "bad local file header in C:\Program Files\Python25\lib\site-packages\tracbzr-0.2-py2.5.egg")
<bob2> perhaps the zip header is messed up
<LarstiQ> enobrev: remove it and try a fresh build?
<enobrev> LarstiQ exactly what I'm doing now... actually going to grab a couple builds from LP to see if any of them work... if not, time to get my hands dirty
<LarstiQ> cool :)
<enobrev> thanks LarstiQ, bob2
<enobrev> LarstiQ, bob2, fixed.  wish i could say i know what the problem was, but I just installed bzr from source (instead of bzr win32 installer) and now it's workin... thanks again
<enobrev> oddly, bzr's been working great all this time.  just had to reinstall for the tracbzr plugin to work
<LarstiQ> enobrev: doh
<qense> I'd like to create a copy of a branch in Launchpad to my own profile so I can implement something and propose it for a merge later
<qense> but how do you create the copy? I can't find it
<dato> I think you just have to push it to ~youruser/productname/yournameforthebranch
<qense> ok
<pfharlock> does anyone in here maintain the bzr-upload plugin?  I have a small patch.
<jelmer> pfharlock: vila and beuno are the people to talk to
<pfharlock> cool, thanks, I've not used launchpad before, so I'm signing up for an account now.  it's just a small syntax error in the setup script
<bobesponja> hi
<bobesponja> how do I create a bare (empty) repository to push to? if there is such a thing
<pfharlock> bzr init
<pfharlock> bzr init .
<pfharlock> creates a branch
<pfharlock> actually if you just push to an ssh location and there isn't a repo there, I think it just creates it for you, if I'm wrong about this somebody please let me know.
<bobesponja> pfharlock: I mean, in git for hosted repositories( where people push) there is no working tree with files, only a .git
<dato> bobesponja: there is no such thing as "bare" in bzr (as in, having the .bzr/* stuff at the top level), but there are branches without trees
<Pilky> bobesponja: bzr init-repo --notrees
<dato> bobesponja: and, you need not (as in git) logging into the remote server to create the repo first; you can just push directly, and bzr will create it if it does not exist, making it without a tree by default
<Pilky> oops, that should be --no-trees
<bobesponja> ok thanks
<bobesponja> Pilky: so bare would be --no-trees
<Pilky> if you want one with no working tree and just the .bzr folder
<bobesponja> yep, that's what I want
<bobesponja> Pilky: isn't that what is always used on hosted repositories?
<Pilky> I believe it's what is usually used on (and recommended for) hosted repositories, you still have to specify --no-trees though
<bobesponja> what if my local repo has trees, if I push to a repo that doesn't exist yet, will it create automatically with or withour the trees?
<dato> bobesponja: do you have clear the disticntion between repo and branch in bzr?
<Pilky> I dunno, I believe it will just push the branch if a repo doesn't exist
<dato> Pilky: uh, sure it will
<bobesponja> dato: a repo has many branches?
<fbond> Would `bzr multi-pull' be useful for updating all of the threads in a loom from another loom?
<dato> bobesponja: yes, but branches can exist outside repos
<Pilky> dato: I mean, I have a repo on my desktop, I've pushed a branch from it to my server and pull the branch to my laptop (with no repo)
<bobesponja> basically, my use case is people have local repositories with working trees they work on and when they push it creates (if the repo doesn't exist yet) a remote repository with --no-trees
<bobesponja> branch without repo? that's weird I guess I need to do some reading
<Pilky> bobesponja: I think you have to create the repo manually, otherwise it will push the branches as being self contained
<Pilky> branches are just directories
<Pilky> bobesponja: this may be of help: http://bazaar-vcs.org/BzrVsGit#head-8d6788e5fb366d04efa536c4c41d4b36e67233fb
<bobesponja> ok thanks
<bobesponja> so branches are kind of like svn I guess
<Pilky> yeah, sort of
<baco> question, you branch branches, not repos, which are re-branchable, but then no one except the original server can have the same structure of repo and branches, but a bunch of branches which could eventually be grouped in a repo, but there's no way to clone the entire repo from the server
<bob2> there's repo-push and multi-pull to do bunches together
<baco> bob2: I don't have repo-push in my command-line client, and multi-pull pull all branches, but does not says anything about the configuration of the repo, you'll have to do a bzr init-repo in the directory pulled after that
<bob2> repo-push is a seperate plugin
<bob2> as for the rest, you've lost me
<bob2> what is "configuration of the repo"?  and multi=pull pulls into a repository (so no need for a init-repo after - it has to be before or it won't work)
<baco> bob2: the .bzr directory in the repo directory that is created after a bzr- init-repo is what I say for configuration, and ï»¿multi=pull was a typo of ï»¿multi-pull
<bob2> for configuration, do you mean branch.conf?
<baco> when you do bzr init-repo a .bzr directory is created with lots of files
<baco> brb
<baco> back
<\sh> guys, which version of bzr supports lp: formed uris? regarding bzr+ssh usage? :)
<jelmer> \sh: All recent versions do
<\sh> jelmer: hardy can't use lp: to push branches to launchpad :)
<\sh> jelmer: so I think more the intrepid one can?
<jelmer> hmm, not sure then
<jelmer> sorry
<jelmer> it's probably just that push in that version is unaware of directory lookups (such as lp)
<pygi> \sh, afaik thats a plugin
<pygi> \sh, 1.3.1-1 from Hardy I think, and all works =)
<\sh> pygi: I always have problems doing a "bzr push lp:~<team|user>/<branchname>" because this starts to use http[s]:// and not bzr+ssh :)
<dato> did you do `bzr launchpad-login`?
<pygi> \sh, do what dato said :)
<\sh> dato: something like this exist? ;)
<\sh> dato: so no :)
<\sh> dato: but I'll try :)
<libwilliam> I have a question about commit --show-diff...
<libwilliam> In the guide it said you could use that instead of using --message
<libwilliam> but when I do bzr commit --show-diff it still asks for a message and fails if I don't give one
<LarstiQ> It's not a replacement, but --show-diff isn't useful if you supply --message on the cli.
<LarstiQ> libwilliam: where in the guide should I look?
<libwilliam> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#commit
<libwilliam> the --show-diff option
<libwilliam> "When no message is supplied, show the diff along with the status summary in the message editor."
<LarstiQ> Right.
<libwilliam> to me it means if I don't supply a message but use the --show-diff option it should ask for a message after, then fail if I leave it blank
<libwilliam> should not*
<libwilliam> I typed that confusing
<LarstiQ> ah, to me it means what you said without the correction :)
<libwilliam> ok let me try again :)
<LarstiQ> Ie, it will fire up the message editor and show the diff for your review. You still have to write a commit message.
<libwilliam> oh
<libwilliam> i get what it means... I read it as instead of showing the diff for review. it just takes the diff and uses it as the message
<LarstiQ> *shudder*
<LarstiQ> libwilliam: That doesn't make sense to me, at all.
<libwilliam> it does make sense now that I reread it
<LarstiQ> libwilliam: you actively want to use the diff as a commit message?
<libwilliam> no... I am just writing the Anjuta IDE plugin and I am making sure the user can't execute a command that will fail... so I am handling all of the scenerios
<LarstiQ> libwilliam: ah ok, cool
<LarstiQ> libwilliam: the reason I ask is I've come across some projects where that is done, and I never understood why.
<libwilliam> I essentially read it as  "When no message is supplied, show the diff along with the status summary in the message editor." without the last word "editor"
<LarstiQ> I mean, the diff is available in the tool anyway, and it only obfuscates what the commit was about.
<LarstiQ> libwilliam: ah, I see.
<libwilliam> its just me reading it wrong
<libwilliam> well thanks for your help
<LarstiQ> libwilliam: would a different wording have helped?
<libwilliam> LarstiQ, well it is currently worded correctly, I just wasn't paying very good attention. It might be worded a little better.
<libwilliam> I'm not very goods with words though, I'll try and think of something that sticks out more though.
<ChristopheT> How am I supposed to use bzr-svn-1.5 with bzr.dev?  If I just make a link from ~/.bazaar/plugins/svn to the svn-1.5 branch, I get the message "Unable to load bzr-svn extensions - did you build it?"
<Peng> ChristopheT: Run make.
<libwilliam> LarstiQ, "When no message is supplied, show the diff along with the status summary to help the user decide on a message."
<ChristopheT> Peng: thanks.  Why isn't "make" run by "setup.py build"?
<LaserJock> I was just trying to revert some changes. After doing bzr revert I seem to have several .~1~ files. Are those from bzr?
<LaserJock> hmm, maybe I should've read bzr help revert first ;-)
<Peng> ChristopheT: I dunno. Maybe jelmer forgot to update setup.py.
<Peng> ChristopheT: Maybe setup.py builds them in build/, while make builds them in-place.
 * Peng shrugs.
<LarstiQ> ChristopheT: I expect things to be the other way around usually, the README is certainly out of date though.
<LarstiQ> (ie, make doing a superset of setup.py, the latter not being 'complete')
<LarstiQ> libwilliam: hmm, I'm not entirely happy with that, but I haven't found something better :/
<libwilliam> LarstiQ: I am the wrong guy to ask. Words are far from my strong suit.
<LarstiQ> libwilliam: I do get the gist of what you tried to express though.
<libwilliam> LarstiQ: Really it doesn't necessarily need to be rewritten. I just never use the message editor so when I was reading it I skimmed right over that word.
 * LarstiQ nods at libwilliam 
<LarstiQ> libwilliam: still, if we can improve it, that wouldn't be bad
<LarstiQ> but I'll stop breaaking my head for noow :)
<libwilliam> Also one more question why I am in here. Is there a way to know if a bug pattern will work or fail with the --fixes option in bzr commit.
<libwilliam> I am trying to throw a warning if the user inputs an invalid bug bug I have currently have no way of knowing what is the wrong form.
<LarstiQ> libwilliam: hmm, I don't think the cli exposes that
<libwilliam> I can use the Python code from the C/Python interface if it isn't too confusing for me :) I will check it out there
<LarstiQ> libwilliam: look at commit 2446 then
<LarstiQ> libwilliam: bzrlib/bugtracker.py and bzrlib/builtins.py:_get_bug_fix_properties() are of intereste
<LarstiQ> libwilliam: and the MalformedBugIdentifier error
<libwilliam> LarstiQ, thanks, I am looking them up now
<LarstiQ> libwilliam: I think it's basically <tracker_identifier>:<bug_identifier>
<LarstiQ> libwilliam: where the first exists due to configuration, and the second is tracker instance specific
<libwilliam> LarstiQ: I will need to use the Bazaar Methods though because I can't just test for that format because a:1 won't work
<LarstiQ> libwilliam: it could work
<LarstiQ> libwilliam: but yeah, using bzrlib beats parsing bazaar.conf yourself and potentially querying the tracker for existance of the bug
<LarstiQ> (or even verifying that the commit actually fixes _that_ bug, but that's a lot further than checking if the syntax is ok)
<libwilliam> LarstiQ: ya I believe so, definatly going the  bzrlib route
<libwilliam> LarstiQ: I didn't even know it had that ability
<LarstiQ> libwilliam: the ability to configure bugtrackers/
<libwilliam> LarstiQ: the ability to have it actually check if the bug was fixed
<LarstiQ> ah, it can't :)
<LarstiQ> and it would be a difficult problem. If you require a unit test that demonstrates the bug, it would be easier to do.
<libwilliam> LarstiQ: I'm kinda glad it can't because my head was going to explode trying to figure out how
<libwilliam> LarstiQ: ya
<LarstiQ> :)
<LarstiQ> that might actually be a useful workflow bit, ala aegis
<libwilliam> LarstiQ: I need to take off, thanks for helping me out with everything. I am definitely going the bzrlib route.
<libwilliam> see ya
<LarstiQ> libwilliam: np, take care!
<libwilliam> you too, have a good one
#bzr 2008-06-29
<jelmer> ChristopheT, You need to run ./setup.py build_ext --inplace
<Peng> (Which is exactly what make runs.)
<Peng> jelmer: Why doesn't setup.py do it automatically?
<jelmer> peng: it does
<jelmer> peng: Well, if you have some way to make that the default
<jelmer> that's deep inside distutils though
<Peng> Ah.
<jelmer> patches are welcome :-)
<LarstiQ> you can replace the default build command object with one that does that?
<Peng> I've heard rumours about distutils. I'm afraid to go anywhere near it. :)
<jelmer> LarstiQ: It's the build_ext command unfortunately
<LarstiQ> jelmer: yes, but I mean making './setup.py build' do an inplace extension build (too)
<baco> wait a moment, imagine you restrict the log in via ssh or http, whichever you want, to a server, both are the same fake for the repo, right, your server is secure, but as bzr not having an auth method, anybody can personify another developer just setting his email variable in his bazaar.conf, and commit mistakes to blame someone else, that's a security error
<Peng> That is true.
<Peng> You could have developers always PGP-sign their commits.
<jelmer> LarstiQ: Rather just recommend everybody to use make :-)
<LarstiQ> jelmer: what a copout! ;)
<LarstiQ> baco: supposedly you merge from people you trust, not random strangers
<baco> Peng: I think I misted that doc, but wouldn't be easier to have an auth method in the server? that would require to run a server each time, the smart-server for example, mmm... nasty
<baco> LarstiQ: then I wouldn't merge anybody, neither myself
<LarstiQ> baco: I'm not sure what you mean with it being easier to have an auth method in the server.
<baco> LarstiQ: I was imaging the svn model, which forces you to give a correct user and password
<baco> but this requieres to have a server running somewhere
<Peng> bac: The thing is, with a DVCS, people will often be pushing each others' commits around.
<baco> Peng: they do need at least an ssh server running, there is no difference in having another server that forces them to auth correctly, using that for setting the commit-er field
<Peng> bac: Say you're working on a feature in a branch, committing frequently. I notice a bug and fix it. You merge my fix. Now when you finally merge your feature branch into the trunk and push it, you'll be pushing both your revisions and one from me.
<LarstiQ> baco: not really, there are many ways you can exchange revisions
<santagada> the signing of the revisions could be an useful feature
<baco> Peng: I don't get your point
<LarstiQ> baco: your method works in a centralized setup, not in a decentralized one.
<Peng> Augh, dammit. I'm sorry again, bac.
<Peng> Dammit. I keep doing that.
 * LarstiQ hands Peng the second part of cola
<Peng> LarstiQo: :)
<LarstiQ> haha :)
<LarstiQ> baco: perhaps it helps to get clear what exactly it is you are after. As santagada said, bzr supports signing commits with gpg, that (and verifying them) can take care of trusting who authored a commit.
<baco> LarstiQ: I understand, that could be also done by faking persons in local commits an then merging you lose  the control, but again, you fix at least the centralized model
<LarstiQ> pardon me?
<santagada> baco: it is already fixed with signing
<LarstiQ> baco: I didn't follow you
<baco> LarstiQ: I was referring to ï»¿(21:12:51) LarstiQ: baco: your method works in a centralized setup, not in a decentralized one.
<santagada> baco: read about signing, then tell us why this doesn't fix your problem
<LarstiQ> baco: mja, I don't see a lot of merit in doing it for a centralized workflow when the tool supports decentralization.
<LarstiQ> baco: and in my experience, it's a non-issue.
<baco> santagada: no anybody I work with knows about the private-public key scheme, but they know that when they see 'Password:' they have to enter one
<baco> *not anybody...
<santagada> baco: this is mostly a tool issue... it has to be fixed, but it is not a problem with bzr
<santagada> baco: why not use svn then?
<santagada> baco: I worked with a team of people that couldn't understand keys or distributed scm at all... the easiest thing was just using subversion then.
<LarstiQ> baco: aha, I think I understand your situation now.
<baco> santagada: I like the best of both worlds, decentralization, works for me working at home
<LarstiQ> baco: do you think things will go wrong if you just trust your peers to set their committer id correctly?
<santagada> baco: bzr-svn
<santagada> should solve your problem of working at home
<baco> LarstiQ: I am really paranoid, I don't allow any ssh connection to my station, I just don't trust
<baco> santagada: yeah, that's a solution, I just wanted to promote bazaar because I like it, but I can not without solving those problems. I think is a good solution for working in many situations, but is strongly based on trust, or experienced users (like the ones who know about public-private keys) :-(
<LarstiQ> baco: to me shell access to your machine is a bit different than trusting people's claim that it's their work
<santagada> baco: I'm not from the bazaar project so I can't express what they want, but maybe they can be everything to everyone. fixing your problem is just going to bring one completely unuseful and dangerous feature to the project
<santagada> s/can/can't
<LarstiQ> santagada: we do try to be :)
<LarstiQ> well, to some extent
<santagada> LarstiQ: I can't access bzr with my svn client... try to fix this :D
<LarstiQ> in the context of a versioning control system mainly for source code, the idea is to support different workflow styles
<LarstiQ> santagada: there is a project for that, though I think long dormant
<LarstiQ> baco: so, if someone would mail you a bundle, would you be willing to merge that?
<santagada> LarstiQ: did you see the linuxhater blog post about bzr?
<santagada> http://linuxhaters.blogspot.com/2008/06/do-you-guys-remember-that-whole-betamax.html
<LarstiQ> baco: or, if each coworker pushes their work to their own home directory on a central server where only they have access, would you be willing to merge from one of those?
<LarstiQ> santagada: looking at it now
<baco> LarstiQ: is almost the same situation, but in a workgroup in which someone wants to harm a coworker an scheme like svn solves my problem
<LarstiQ> santagada: that seems to be a general lament about the amount of different dvcsen, that's an old concern
<baco> LarstiQ: I know it's a really wried situation, but could happen
<LarstiQ> baco: if they really want to hurt you they'll crack the password, or worse, break your fingers.
<lifeless> baco: you can use bzr just like svn in this regard if you so desire:
<santagada> LarstiQ: I still wish that mercurial and bzr would just merge... both projects that have almost the same goals using almost the same tools
<lifeless> baco: setup a server, have everyone push and pull against a central branch there
<lifeless> baco: via webdav, or bzr+http, or bzr+ssh
<LarstiQ> baco: trust will have to enter the picture somehow
<santagada> baco: why not have each user have its own accound on the main server
<santagada> if someone tamper with commits you can discover who did it
<baco> LarstiQ: I preferred the conspiring plot instead of physical aggression :-P
<lifeless> well, they can't tamper with history without bzr alerting everyone else anyway
<lifeless> back later folk
<baco> lifeless: with bzr+http or bzr+ssh they auth against the server, but the commit in the repo could be made by sancho <sancho@panza> or don <don@quijote> for the same log in account at separate times
<santagada> baco: but you can track wich user did what
<baco> santagada: no if you branch the trunk to another server losing the log-ins history
<santagada> ?
<LarstiQ> baco: you could conceivably set the committer id server side
<LarstiQ> baco: but if you want to go to all these lengths, I'd really try to invest my effort in educating my coworkers about signing and verifying commits.
<LarstiQ> baco: but frankly, I trust my coworkers.
<baco> LarstiQ: I do insist when I say I am a paranoid bastard
<baco> LarstiQ: how could you set the id server side? not only with bzr, I guess
<LarstiQ> baco: I've not verified this all works, but something along the lines of using the smartserver and generating new revisions to actually commit with the commiter id changed to server side approved ids.
<LarstiQ> baco: note that that is very nasty to do, because then you will have to throw away your local revisions and pull from central again.
<LarstiQ> baco: and I don't think it actually buys you anything
<LarstiQ> baco: as soon as you outside that central server, people have control over their committer id again.
<LarstiQ> baco: really, the committer id is not meant to give a secure way of identifying who is responsible for said commit.
<baco> then blame is not a secure command to say who introduced a bug
<LarstiQ> baco: before going back to my girlfriend I'll suggeset two avenues of attack for you: 1) educate on gpg signing (bzr supports this in the tool) 2) trust people
<LarstiQ> baco: no, 'secure' doesn't enter the equation
<LarstiQ> neither is svn blame
<baco> imagine you dismiss the wrong person for that
<LarstiQ> baco: if your assumption is that people are out to harm you and hide their tracks, I wouldn't stop at assuming they can't do with the server whatever they want. Including doing and svn dump and restore.
<LarstiQ> baco: using the wrong tool for the job.
<LarstiQ> baco: the only thing that can ever work is signed statements. Digitally, that would mean gpg.
<LarstiQ> (for that sceneario)
<bpeterson> is there a Bazaar equivalent to svn:keywords?
<bpeterson> ie can I replace a keyword with the current revision?
<bob2> no, I think people generally use "bzr version-info" in a build script
<lifeless> LarstiQ: I would have suggested 'peer review' actually.
<lifeless> LarstiQ: as in - noone commits to trunk unless there is someone else with them, etc.
<lifeless> LarstiQ: because of his concept of firing people that introduce bugs :)
<enobrev> is there a way to link files from other branches / repositories when pushing to another branch?
<enobrev> or even directories?
<bob2> ala svn-externals?
<enobrev> yes!
<enobrev> been so long since svn that i'd forgotten the name
<enobrev> (bob2)
<ToyKeeper> D'oh.  bzr.dev and bzr-svn trunk started out better, but its memory use exploded after it finished grabbing revisions.
<Jc2k> i hear the worst leak is in sqlite now :)
 * ToyKeeper wonders how to get swap usage data per process
<ToyKeeper> The versions in hardy used about 600MiB RAM to branch this repo, but the dev versions are up to about 2 GiB if I count swap.
<ToyKeeper> anyhoo, the current head revisions are both better and worse.  :)  http://launchpadlibrarian.net/15674458/bzr-svn-memuse.png
<weigon_> does someone have an idea on: https://bugs.launchpad.net/svn2bzr/+bug/230341 ?
<ubottu> Launchpad bug 230341 in svn2bzr "ValueError: need more than 1 value to unpack" [Undecided,New]
<weigon_> I run into the same problem
<jelmer> ToyKeeper, Wow, I wonder what that sudden memory increase comes from
<jelmer> at least part of the memory usage is caused by memory leaks in the python sqlite3 bindings
<ToyKeeper> jelmer: Yeah, I was pretty surprised.
<lifeless> jelmer: could be versionedfiles copying
<lifeless> jelmer: did you implement streams memory-efficiently ?
<weigon_> is gustavo niemeyer here from time to time ?
<lifeless> yes
<weigon_> what's his nick ?
<lifeless> niemeyer
<jelmer> lifeless: he's not using stacked stuff at all
<lifeless> jelmer: oh
<jelmer> lifeless, there's no versionedfiles involved in that case
<lifeless> ToyKeeper: was it building a tree ? or just a branch fetch ?
<ToyKeeper> lifeless: https://bugs.launchpad.net/bzr-svn/+bug/243939
<ubottu> Launchpad bug 243939 in bzr-svn "'bzr branch' over svn uses a lot of RAM" [Undecided,New]
<jelmer> lifeless, it's memory leaks in the python bindings and sqlite3 bindings
<jelmer> lifeless: I can reproduce them here, but debugging them is pretty hard
<lifeless> jelmer: after its grabbed the revisions though, it builds a tree; that could be local KnitVFs issue
<jelmer> lifeless: hmm, that would be convenient :-P
<jelmer> lifeless: I'm sure there's bzr-svn- or svn-specific memory leaks as well still though
<lifeless> jelmer: right, I'm just noting that it needs more analysis :)
<lifeless> jelmer: and my question to ToyKeeper will help
<lifeless> ToyKeeper: if you could answer it that would be great
<bob2> apropos #75700, how ghetto is extracting the version from the deprecation symbol's string
<ToyKeeper> lifeless: The spike happened just after it finished fetching all the revisions, and started on the next step.
<lifeless> 22:34 < lifeless> ToyKeeper: was it building a tree ? or just a branch fetch ?
<ToyKeeper> I only know what it printed onscreen, which didn't include that much detail.
<lifeless> ToyKeeper: well, did you end up with a working tree?
<ToyKeeper> Yes, the result seems to work fine.
<jelmer> ToyKeeper: You'd want http://svn.gnome.org/svn/sawfish/trunk rather than http://svn.gnome.org/svn/sawfish
<jelmer> ToyKeeper: Or perhaps bzr svn-import http://svn.gnome.org/svn/sawfish
<lifeless> ToyKeeper: so 'yes it was building a working tree'
<lifeless> next thing would be to try fethcing into a treless branch
<ToyKeeper> lifeless: Oh, sorry, I parsed that as "functional result".  Yes, it included a working tree.  :)
<ToyKeeper> jelmer: Yes, I plan to fetch only the trunk for a real conversion.  90% of the files are in tags/, and that's wasteful.  I used the repo root just as a test case.
<jelmer> ToyKeeper: That's an unfair comparison with git-svn then though
<ToyKeeper> I fetched the repo root with git, too.
<jelmer> Ah, ok. Sorry
<jelmer> I wasn't aware it could do that
<ToyKeeper> The behavior of git is mostly irrelevant.  I just wanted a vague idea what people might expect after using other tools.
 * jelmer tries to reproduce
<ToyKeeper> I hope the gnome server admins don't mind me sending hundreds of thousands of http requests as I poke at this.
<Jc2k> poke what :o
<Jc2k> hmm
<Jc2k> ToyKeeper: why are you poking sawfish via svn
<Jc2k> bzr branch http://bzr-mirror.gnome.org/bzr/sawfish/trunk ??
<ToyKeeper> Jc2k: The sawfish project is considering moving to git or bzr, so I'm looking into the migration details.
<Jc2k> well its already kinda migrated to both :)
<lifeless> gnight
<Jc2k> you can get an rsync of the sawfish module svn stuff if you want to keep running conversions though
<Jc2k> either ask bkor or i can throw up a .tar.gz on my webspace for you
<jelmer> conversion of sawfish trunk here took 20 minutes
<jelmer> unfortunately I was away for a bit while it was building the working tree :-/
 * LarstiQ chains jelmer to his chair
<ToyKeeper> Jc2k: Any chance of getting tag data in those mirrors?  :)
<Jc2k> ToyKeeper: git-mirror has tags, bzr-mirror.. i don't know how to, but the tags exist as branches
<Jc2k> http://bzr-mirror.gnome.org/bzr/sawfish/tags/
<ToyKeeper> In any case, whether or not grabbing from root makes sense, it does help expose a memory issue.
<jelmer> hmm, this appears to be related to the number of write groups I use in bzr-svn
<nandersson> Is there a faster way to push/pull to central repository than using the prefix sftp:// ? I've got a shared key solution today but I've heard something you could still use SSH without having to use sftp?
<LarstiQ> nandersson: bzr+ssh://, the drawback is that that requires having bzr on the remote side. If that is no problem, it will be faster than sftp://
<LarstiQ> nandersson: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id60
<nandersson> LarstiQ, Thanks for that!
<LarstiQ> nandersson: np :)
 * LarstiQ heads off to Parkpop
<jelmer> LarstiQ, enjoy!
<nandersson> I'm a first time Launchpad user and I've created a new empty branch, factoryx-java, that I try to push to with: bzr push lp:~niklas-andersson/+junk/factoryx-java
<nandersson> but I get this error: bzr: ERROR: Transport operation not possible: http does not support mkdir()
<dato> nandersson: try running `bzr lp-login` first
<nandersson> aha, thanks!
<nandersson> dato, Thanks a lot! Now I'm up'n running
<dato> nandersson, great
<nandersson> How do I get Eclipse 3.4 into Ubuntu 8.04 without breaking the repository?
<nandersson> ...or Eclipse 3.3 even..
<bpeterson> is there something like svn:keywords in Bazaar?
<Kinnison> bpeterson: I believe someone has written a plugin to do them
<Kinnison> nasty things though they are
<Kinnison> </prejudiced>
<jelmer> beuno, ping
<jelmer> ToyKeeper, still there?
<jelmer> whatever happened to your diff panel patch ?
<beuno> emgent, pong
<beuno> er
<beuno> jelmer, pong
<beuno> emgent, ignore me :)
<jelmer> beuno: was just wondering if you had time to do some patch reviewing for bzr-gtk
<beuno> jelmer, sure, I can spare an hour or so after I eat something   :)
<beuno> es BB up?
<beuno> it is, cool
<beuno> I'll get to it in a while
<beuno> is there a release date for 0.95?
<jelmer> not yet
<jelmer> I would like to get daniels signature checking fixed
<beuno> sounds like a good idea
<beuno> I've been toying with the idea of getting bzr-search integrated on there
<beuno> it should't be too much work
<beuno> I've just been crazy busy
<jelmer> Yeah, that would be a really neat thing
<beuno> most of the backend stuff can be re-used from Loggerhead, so it's more about the interface
<beuno> anyway, off to get food. I'll try and go through the whole batch when I get back
<beuno> and, btw, I just re-poked the DD about bzr-upload
<jelmer> ah, thanks
<beuno> but I suppose it may be time to find someone else...  :(
<jelmer> oh, ok
<beuno> I can keep on poking, just don't want to keep on delaying it
<jelmer> k
<beuno> thanks for packaging that, btw  :)
<enquest> I keep getting this error when updating. But I don't get on wich file bzr: ERROR: [Errno 13] Permission denied
<enquest> Can I force or see some log to know where the error is?
<jelmer> ~/.bzr.log may be able to tell you
<jelmer> beuno: Is there a loggerhead example up somewhere that does search?
<Jc2k> jelmer: http://bzr-mirror.gnome.org:8080/$MODULE/trunk
<Jc2k> :)
<jelmer> Jc2k, ah, thanks :-)
<jelmer> beuno, J2ck: coming up with the right UI would be the hardest bit I guess
<Jc2k> aye
<jelmer> I just sent a patch that allows indexing branches from "bzr viz"
<Jc2k> nice
<baco> If I rename a repo, and one of it's branches, manually, the only thing affected would be the Working trees generated as checkouts of this branch?
<jelmer> beuno: Just saw a bzr-upload upload, thanks!
<enquest> jelmer, there is no .bzr/log
<enquest> or .bzr.log
<jelmer> enquest: .bzr.log in your home directory
<enquest> jelmer no there is not much more info in there
<enquest> it crashes when always when updating a file
<enquest> jelmer, here the traceback http://dpaste.com/59818/
<jelmer> enquest, no idea what's going wrong, sorry
<jelmer> wb LarstiQ
<LarstiQ> jelmer: thanks, firewall problems ftl
<davidstrauss> Is there a good tool for browsing bzr repositories on the Web?
<LarstiQ> davidstrauss: do you mean something like loggerhead?
<LarstiQ> davidstrauss: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3513
<davidstrauss> LarstiQ: yes, but i couldn't find good info on it
<LarstiQ> davidstrauss: what kind of info are you looking for?
<davidstrauss> LarstiQ: Documentation for it
<davidstrauss> LarstiQ: many of the related sites seem to be down or devoid of information
<davidstrauss> LarstiQ: for example, http://www.lag.net/bzr.dev/changes
<lifeless> moin
<Jc2k> moin
<Jc2k> http://icanhascheezburger.files.wordpress.com/2008/06/funny-pictures-never-trust-a-feline-technician.jpg
<lifeless> davidstrauss: hi, what sort of info do you want? https://launchpad.net/loggerhead/ is the home for loggerhead these days
<davidstrauss> lifeless: thanks
<thumper> lifeless: morning
<lifeless> hi thumper
<thumper> lifeless: do you have a date for the move across the ditch?
<lifeless> enquest: for some reason the rename is failing
<lifeless> enquest: renames on window et permission denied when a file is open - is it possible that you have a file in your tree open in an editor ?
<enquest> lifeless, I found it ther was a directory not in the right permission but bzr didn't tel me wich one
<lifeless> thumper: not yet, currently getting budget size from bank
<lifeless> enquest: cool; could you file a bug please?
<thumper> lifeless: fun, fun
<lifeless> how much is the house you want? I don't know, how much can I ask for? well it depends on the house ...
<beuno> jelmer, seems the poking finally payed off!
<beuno> lifeless, hey!
<lifeless> hi beuno
<beuno> how did the search talk go?
<lifeless> good
<lifeless> http://www.robertcollins.net/talks/bzr/200806-slug
 * beuno branches
<lifeless> it was taped as well
<beuno> anything interesting come out of it?
<lifeless> nothing major
<jelmer> lifeless, Search seems to depend on weave_store existing, is that right?
<jelmer> lifeless, I've got a pending merge request that adds an Index button to bzr viz
<beuno> not pending anymore  :)
<lifeless> jelmer: I was going to update it for bzr.dev in the weekend
<lifeless> jelmer: but I had some stomach updaset and spent most of it in bed taking drugs :(
<jelmer> lifeless: ah, ouch :-/
<lifeless> yah not fun
<lifeless> still hurts a bit now, but fingers cross I'll get some code written
<ferringb> curious, anyone seen issues w/ create_signatures (gpg) for bzr 1.5 on gentoo?
<ferringb> ...specifics being the signing generally just hanging
<lifeless> I wouls strace -ff and see whats happening
 * ferringb mutters, was expecting that suggestion
<ferringb> was hoping someone had a solution that didn't involve me debugging it myself ;)
<lifeless> ferringb: (no I haven't heard anyone else complain)
<lifeless> ferringb: I expect its the gpg command doing something you don't expect
<ferringb> yep
<ferringb> gpg-agent specifically seems to be implicated
<bjwebb_> hello
<bjwebb_> why should i choose bzr over git?
<ferringb> lifeless: reminds me, noticed your nick a couple of times in trac-bzr discussions- any comments on that pkg?
<ferringb> lifeless: specifically, areas of improvement, if it's still actively maintained, etc
<lifeless> jelmer: uhm -
<lifeless>   File "/home/robertc/.bazaar/plugins/svn/fileids.py", line 20, in <module>
<lifeless>     from bzrlib.knit import make_file_knit
<lifeless> jelmer: which url should I pull from to fix that ?
<lifeless> bjwebb_: because its better overall ?
<lifeless> bjwebb_: (sorry if that sounds flippant)
<bjwebb_> lol
<bjwebb_> for example?
<lifeless> less tightly coupled to ext3 internals, less portability issues, more hackable (written in python), more approachable UI
<lifeless> tracks renames
<lifeless> uhm
<lifeless> what I hear from git refugees who start using bzr is that bzr is 'nicer' and 'more pleasant' and 'not in their way'
<bjwebb_> oooh, tracks renames
<bjwebb_> nice
<jelmer> lifeless: 0.4 branch
<bjwebb_> any good bzr hosts than propreitarypad?
<uws> bjwebb_: any web host will do
<lifeless> bjwebb_: http://kubasik.net/blog/tag/bzr/
<lifeless> bjwebb_: point 9
<lifeless> bjwebb_: really sums up what we are trying to achieve - and I think we _are_ achieving it
<lifeless> bjwebb_: alioth, savannah (though their support is in beta and not yet polished)
<lifeless> bjwebb_: oh, if it matters - bzr is a GNU project
<bjwebb_> it is now, nah, doesn't really matter to me
<bjwebb_> all that matters on the ethical side is that it is free software
<bjwebb_> so bzr does branches as directories in the way that cvs and svn do
<lifeless> I read that as 'can you checkout arbitrary subdirectories of a branch'? (Is that a fair translation?)
<lifeless> jelmer: whats the url
<jelmer> lifeless, http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<jelmer> It's also registered in launchpad, I believe as lp:~jelmer/bzr-svn/0.4
<lifeless> jelmer: its rich-root, or subtrees
<jelmer> lifeless: rrp
<uws> are those repo formats documented somewhere?
<uws> I often have no clue what to use
<uws> (and why I should choose)
<berto-> i'm having trouble using bzr-svn.  when I try to branch an svn repo I get the message "Unable to load bzr-svn extensions - did you build it?"  After downloading the svn plugin I ran "make" in the svn dir.  anything else I need to do?
<jelmer> http://bazaar-vcs.org/BazaarFormats, although it doesn't appear to be up to date
<RAOF> Are reports about the svn-1.5 branch of bzr-svn wanted?
<jelmer> RAOF: the 0.4 branch should work fine with subversion 1.5
<RAOF> berto-: Right.  That's something I'm meaning to report; the modules seem to be installed a directory or two too low.
<lifeless> uws: yes
<RAOF> jelmer: I take that to be a "no", then. :)
<lifeless> uws: in the doc/developers/repository-formats.txt i think
<jelmer> RAOF: Well, reports are always welcome :-)
<uws> bzr help init   has some info as well it seems
<berto-> RAOF: what can i do to make it work?
<jelmer> RAOF: I just wouldn't recommend using that branch if you're just looking to try out bzr-svn as opposed to working with it
<jelmer> berto-: You installed bzr-svn in ~/.bazaar/plugins/svn ?
<berto-> jelmer: yes, sir.
<RAOF> jelmer: I was just kinda interested.  Depending on how the mood takes me, I may actually hack on it, too.
<RAOF> Well, the reports are: the modules are installed in the wrong place, and they generate a bus error in ra.c on x86-64 :).
<jelmer> berto-: Any errors in ~/.bzr.log ?
<lifeless> bjwebb_: I read your lasst question as 'can you checkout arbitrary subdirectories of a branch'? (Is that a fair translation?)
<bjwebb_> not quite
<jelmer> RAOF: The bus error was fixed about a week ago - are you using a recent revision?
<berto-> jelmer: 1 sec, i'm going to clean out my log and repro the error
<bjwebb_> i get the impression that in svn adn cvs branches are just directories
<bjwebb_> wheras in git they are kindof abstracted
<RAOF> jelmer: Yes.  Pulled as of yesterday.
<jelmer> RAOF, and rebuilt?
<RAOF> Yes, but I'll check again.
<lifeless> bjwebb_: ah; so in cvs a branch is orthogonal to directories, they are identified by tags
<lifeless> bjwebb_: in svn a branch is just a directory
<bjwebb_> right
<bjwebb_> whats it like in bzr?
<lifeless> in git and bzr and hg etc branches are first class objects
<berto-> jelmer: the last interesting bit looks to be: UnboundLocalError: local variable 'version' referenced before assignment
<berto-> jelmer: i can send you the entire traceback if you wish.
<lifeless> bjwebb_: that said, I strongly believe that we have gone too far
<jelmer> berto-: Any chance you can pastebin it?
<lifeless> and need to restore some of the flexibility that cvs/svn displayed in this area
<pygi> in any DVCS branches are first class
<pygi> :)
<berto-> jelmer: http://paste.pocoo.org/show/78162/
 * pygi hides
<lifeless> pygi: :)
<jelmer> berto-: That's odd - what revno of bzr-svn are you using?
 * pygi is practicing for the book xD
<berto-> jelmer: revno: 1368, just downloaded it last night.
<RAOF> jelmer: Gah.  Apparently I _hadn't_ rebuilt.  Sorry for the noise.
<berto-> jelmer: i'm working on cleaning out some other stuff.
<jelmer> berto-: Did "make" create a ra.so file in your plugin directory?
<berto-> jelmer: yes it did.
<berto-> jelmer: ra.so client.so wc.so and repos.so
<berto-> jelmer: i see pycurl errors in my .bzr.log; is that from bzr-svn?  i should install pycurl, working on that ...
<lifeless> berto-: you don't need pycurl
<berto-> lifeless: ok, thanks.  wonder what the pycurl error is all about then ...
<lifeless> berto-: its probing for it is all
<jelmer> berto-: What is the error exactly?
<lifeless> berto-: it possibly needs to be toned down :)
<berto-> lifeless: jelmer: here's the entire log: http://paste.pocoo.org/show/78163/
<jelmer> RAOF: I've add some code to make bzr-svn warn when the extensions are out of date
 * LarstiQ thought that was some sort of acronym at first
<jelmer> *warning
<jelmer> berto-: please update your version of bzr-svn and try again
<lifeless> jelmer:  http://rafb.net/p/uWYMxK12.html
<jelmer> lifeless, you need to have libsvn-dev installed
<lifeless> jelmer: then the exception could note that :)
<berto-> jelmer: i'd go about doing that by running "bzr pull" ?
<jelmer> berto-: yep, followed by 'make'
<berto-> jelmer: i really messed something up: bzr: ERROR: Cannot lock LockDir(http://people.samba.org/bzr/jelmer/bzr-svn/stable/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<lifeless> berto-: if you have a checkout, use 'bzr update'
<jelmer> lifeless: It certainly could :-)
<lifeless> berto-: pull always affects the branch, and a checkout (or bound branch) will try to affect the master
<jelmer> lifeless: I'll see if I can add that at some point
<lifeless> jelmer: it already tries to be helpful ...
<lifeless> cc1: warnings being treated as errors
<lifeless> ra.c:979: warning: Ã¢ defined but not used
<lifeless> ra.c:998: warning: Ã¢ defined but not used
<berto-> jelmer after running "bzr update" i'm still on revno 1368.
<jelmer> berto-: Looks like I accidently replaced that symlink with a copy
<berto-> looks like i checked out the stable branch; should i have checked ot a dev branch?
<jelmer> berto-: Should be fixed now, please try again
<lifeless> jelmer: you have mixed tabs/spaces in these files; bit of an eyesore with 4-wide tab setting
<berto-> jelmer: merging ...
<lifeless> jelmer: I've unset my CFLAGS to build
<jelmer> lifeless: Fixed, will push later
<jelmer> lifeless: There are no unused variables - you are probably compiling with heavy optimization?
<berto-> jelmer: looks better, but still getting an error: ImportError: dlopen(/Users/berto/.bazaar/plugins/svn/client.so, 2): Symbol not found: _apr_array_make
<berto-> jelmer: i think i need to rebuild my svn's python bindinds now.
<lifeless> jelmer:
<lifeless>  echo $CFLAGS
<lifeless> -g -O2 -Wall -Werror -fno-strict-aliasing
<jelmer> berto-: No, this is probably a bug in bzr-svn
<jelmer> berto-: It no longer uses the standard Python subversion bindings
<jelmer> berto-: what platform are you on?
<berto-> jelmer: oh, i see.  os x
<berto-> jelmer: so, these instructions are obsolete?  http://bazaar-vcs.org/BzrForeignBranches/Subversion#mac-os-x
<jelmer> berto-: yes, for the development branch of bzr-svn
<berto-> jelmer: and i spent forever figuring out building subversion properly last night, *sigh*.  ;)
<LarstiQ> berto-: always a useful skill :)
<berto-> LarstiQ: not reallly complaining, just that one thing leads to another, to another.  kinda reminds me of when i used to use redhat and rpm didn't have any sort of auto-dependency bits.
<berto-> jelmer: if there's anything you'd like me to test on OS X, let me know.
<jelmer> berto-: Sorry :-/ It'd be nice if somebody with Mac OS X can update those instructions at some point
<jelmer> berto-: I'm pushing a fix that should take care of that unresolved symbol
<berto-> jelmer: once i get this working, i'll do it.
<berto-> jelmer: the instructions are going to be much easier if the python svn bindings aren't even needed anymore.
<jelmer> ooh, somebody improved the message displayed when a lock is active
<jelmer> berto-: Thanks
<jelmer> berto-, pushed
<jelmer> please try again with r1387
<jelmer> you may need to run "make clean; make" after updating
<berto-> kind of a tangent, but anyone know how i can tell "make" not to build -arch ppc?
<jelmer> beuno: Thanks for the reviews
<jelmer> berto-: instead of make you can also run "./setup.py build_ext --inplace" - perhaps it's easier to override for that
<jelmer> ?
<beuno> jelmer, np. One to go, the progress bar one. Left the largest for last
<jelmer> beuno: Ok, I'll start merging
<berto-> jelmer: ImportError: dlopen(/Users/berto/.bazaar/plugins/svn/client.so, 2): Symbol not found: _svn_auth_first_credentials
<berto-> jelmer: Referenced from: /Users/berto/.bazaar/plugins/svn/client.so
<LarstiQ> jelmer: aaah, I think I might know where my svn-push problem lies
<jelmer> Hmm, it's probably going to take a long time if I keep pushing changes for each of these
<LarstiQ> (a missing prefix, lp:bzr-svn/0.4 warns about it, 0.4.10 didn't)
<berto-> jelmer: do you want me to get patches some other way?
<berto-> rsync or something?
<jelmer> berto-: in setup.py, line 106, can you add "svn_subr-1" to libraries ?
 * LarstiQ growls at having to enter authentication endlessly
<LarstiQ> as in, at least every revision :(
<jelmer> LarstiQ, what sort of prefix?
<LarstiQ> jelmer: repo path, pushing to /misc/plagg while /misc didn't exist
<LarstiQ> jelmer: it's a known problem that I have to authenticate more than once?
<jelmer> LarstiQ: Yeah, but that's all in bzr itself
<berto-> jelmer: line 106 in setup.py lands me in the middle of setup's packages param's list
<LarstiQ> jelmer: right. I'll just enter it the 102 times now.
<berto-> jelmer: setup.py is revno: 1387, timestamp: Mon 2008-06-30 00:09:57 +0200
<jelmer> berto-: That should be the line with
<jelmer>           SvnExtension("client", ["client.c", "editor.c", "util.c", "ra.c", "wc.c"], libraries=["svn_client-1", "svn_auth-1"]),
<jelmer> s/auth/subr
<beuno> hrm, jelmer, I get this when trying to see the diff from a revision in bzr viz:  http://paste.ubuntu.com/23812/
<beuno> is that a known issue?
<berto-> jelmer: that's line 109 for me.
<jelmer> beuno: Not until now :-)
<jelmer> berto-: ah, ok
<jelmer> berto-: s/106/109 then :-)
<berto-> i need to figure out a problem where -lapr-1 doesn't work with leopard's linker.
<berto-> if i swap -lapr-1 with /usr/lib/libapr-1.dylib it works fine, but doing that 7 times for each gcc command that fails is a pain.
<jelmer> does "apr-config --link-libtool" return that perhaps?
<berto-> jelmer: [berto@bolt][1422]$ apr-1-config --link-libtool
<berto->  -L/usr/lib -R/usr/lib -lapr-1
<berto-> leopard was released with a new linker and i've run into this ever since.  i finally need to just figure out the solution.
<lifeless> jelmer: 1.6b3 suppport pushing now
<jelmer> lifeless: Hmm?
<beuno> jelmer, ironically, you removed that from bzrlib: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/pqm%40pqm.ubuntu.com-20080529152850-mdjpxxj9futs06vu?start_revid=pqm%40pqm.ubuntu.com-20080627225315-j2xpbsvjyya1s97y
<jelmer> beuno: yes, but only because it was broken anyway there
<beuno> right, we let a patch in from Javier which introduced it
<beuno> let me see what I can do
<lifeless> jelmer: pushed
<beuno> lifeless, for bzr-search?
<lifeless> jelmer: you wanted bzr-search for VersionedFiles
<beuno> yay!   :)
<jelmer> ahh
<jelmer> lifeless: awesome, thanks
<lifeless> jelmer: trying bzr index now via the .texts and .inventories stores
<LarstiQ> jelmer: check, bzr.dev + 0.4 succeeds in pushing the tree
<jelmer> LarstiQ: Ah, you're finally done entering your passwords ? ;-)
<lifeless> jelmer: (by which I mean, svn co foo foo; cd foo; bzr index)
<LarstiQ> jelmer: 110 times..
<LarstiQ> some setup at the start, and then once for every of the 102 revisions
<lifeless> ?!
<LarstiQ> jelmer: but bzr1.5 + 0.4.10 tracebacked
<jelmer> lifeless: I hope there's enough of them implemented
<jelmer> LarstiQ: What was the traceback exactly?
<lifeless> jelmer: it hasn't failed yet; but I think its going to be _slow_
<lifeless> jelmer: if it doesn't fail, I'll file a bug
 * jelmer already sees the lp bug mail coming in: "[NEW] bzr plugins work too well together"
<LarstiQ> jelmer: tried with 1.5/0.4.10 again, prefix didn't help
<jelmer> LarstiQ: what was the exact backtrace?
<LarstiQ> jelmer: http://rafb.net/p/23kX4935.html
<jelmer> LarstiQ, thanks
<LarstiQ> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/242979 perhaps?
<ubottu> Launchpad bug 242979 in bzr-svn ""PROPFIND request failed on '/svn/!svn/bln/7739'" [Undecided,New]
<jelmer> LarstiQ, that's a different error code
<LarstiQ> doh
<jelmer> berto-, any luck?
 * LarstiQ meant https://bugs.launchpad.net/bzr-svn/+bug/240954
<ubottu> Launchpad bug 240954 in bzr-svn "SubversionException: ("PROPFIND request failed on '/svn/gazpacho/!svn/bc/2621/tags/branches'", 175007) " [Undecided,Fix committed]
<LarstiQ> but that looks different
<jelmer> LarstiQ: Yeah, that could indeed be related
<berto-> jelmer: i compiled the long way and still get the same error i sent you earlier.  i'm trying to figure out if it's something i did wrong.
<jelmer> berto-: Did you add "svn_subr-1" to the libraries list for "client"?
<berto-> jelmer: 1 sec ...
#bzr 2009-06-22
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> when you were working on the missing keys stuff
<lifeless> did you happen to also have methods to get 'all the new revision ids' or something like that?
<lifeless> I'm making StreamSink do a pack()
<lifeless> but providing only the revision ids to pack
<lifeless> alternatively, I could make it pack with some opaque hint about the pack names to use, which commit_write_group could be modified to return
<lifeless> I'm still undecided.
<spiv> I did, I can't remember if that method ended up landing or ditched, though...
<lifeless> telling you about this I've realised a race with my current approach
<lifeless> so I am now decided, the hint has to be opaque and list the pack names.
<spiv> I either didn't have that method, or I had it and abandoned it in favour or something else (_KnitGraphIndex's track_external_parent_refs flag, maybe?)
<lifeless> spiv: well, I don't want refs, I want something to id the packs themselves
<spiv> Yeah, I prefer the sound of that approach anyway.
<spiv> Right, it doesn't help for this.
<SamB> jelmer: is there a bzr-svn equivalent for "svnversion"?
<AfC> SamB: http://blogs.operationaldynamics.com/andrew/software/version-control/subversion-revision.html
<poolie> hello all
<poolie> jml: https://edge.launchpad.net/bzr/+milestone/2.0
<poolie> it still shows a few bugs
<poolie> how many are actually critical i don't know
<lifeless> FWIW I haven't attempted to categorise all the critical bugs as blockers/not blockers at this point
<jml> lifeless, as in, there are some bugs on 2.0 marked 'critical' that might not be blockers?
<lifeless> no
<lifeless> as in there are bugs marked critical that might be blockers for 2.0, but not set against the milestone
 * SamB wonders how many GHC releases are going to go by with that critical bug in the typesystem ...
<lifeless> using milestones to plan releases is a new experiment for us
<jml> ahh ok.
<jml> https://bugs.edge.launchpad.net/bzr/+bug/389272 ; https://bugs.edge.launchpad.net/bzr/+bug/376243 and https://bugs.edge.launchpad.net/bzr/+bug/365615 are the only ones I could find like that.
<ubottu> Launchpad bug 389272 in bzr "upgrade and root data for cached inventories in trees" [Critical,Triaged]
<lifeless> for regular releases I think we shouldn't ever really have bugs open against the milestone
<lifeless> 2.0 is special
<jml> lifeless, aiui, 2.0 is special because we need some way of deciding when to change the naming convention of one of our regular releases.
<lifeless> its special because people percieve .0 releases differently
<lifeless> ugh spellink
<SamB> 2.0 is special because it comes after 1.n
<lifeless> SamB: so does 1.n+1 :)
<SamB> well, I mean, you don't even have to know what "n" is before you start planning for 2.0
<lifeless> sure :P
<SamB> or alternatively, you have to pick an n
<lifeless> what I mean though, is that people will make more of an effort to upgrade; that we are likely to be changing the default for 2.0, that rich roots will get much more exposure.
<lifeless> we're going to _drive_ exposure of all the little issues in the system that are currently an optional experience
<igc> morning all
<lifeless> so 2.0 is more a readiness test than 'another month has passed'
<jml> igc, good morning
<fullermd> Speaking of 2.0, which we weren't, I'd like to suggest we remove the 'clone' alias for it...
<fullermd> That would give it time to get out of circulation and cut down on surprise when we re-used it in 3.0 for cloning multi-branch repos...
<lifeless> fullermd: put a patch up
<lifeless> fullermd: I'm ambivalent; I think you're prematurely judging what the ui changes will be. OTOH clone is the source of some confusion today.
<fullermd> Well, I am.  OTOH, it's an excellent word for it, matches 'git clone', and probably should be de-made a copy of 'branch' ASAP if it's ever going to come into usage meaning something rather different, so...
<fullermd> I'll try banging something together for the list later; wouldn't want to bother if I could just hop on IRC and get told "WTF, no".
<lifeless> I mean; specifically, we have multibranch repos today
<lifeless> theres no real need to have the deep problems fixed to make the change you want today
<lifeless> clone URL could just clone the entire structure today
<lifeless> the things I'm interested in for 3.0 are removing the sand grains
<fullermd> Would you prefer I said "git style branches"?   :p
<lifeless> if you said that, I'd feel even more like you're prejudging
<fullermd> Anyway, my rush wasn't so much the changes, as that moving clone instantly from being an alias for 'branch' to being a totally different command is unpleasant, and it'd be better to give it a while of being nothing in the middle, to get people away from it.
<lifeless> I think we'll have to change much more than simply clone to do 3.0 :) If you want to do this work on clone, its fine with me.
 * fullermd thinks you're reading a LOT more into this...
<lifeless> could be ;)
<fullermd> All I'm saying is "Hey, I think this is a command we'll want to use for XYZ in the future, we should stop making it mean ABC ASAP"
<fullermd> That was we have all 2.x for people to start using 'bzr branch' instead of 'bzr clone', so they're not unpleasantly surprised out of the blue when it changes.
<lifeless> All I'm saying is 'using it for XYZ isn't clear to me, and perhaps using it for ABC will still be appropriate. But hey, it causes confusing on ABC at the moment so changing it might be good anyway'
<lifeless> fullermd: w.r.t. avoiding confusion, I'm fairly sure 'bzr branch' will change *too*, so I'm not buying the avoiding-of-surprise.
<fullermd> Well, but I expect branch will always pretty much mean 'make a new branch based on X', give or take.  So it wouldn't be a conceptual shift, just syntax and details.
<fullermd> Oh well.  I'll try starting a bikesh^Wthread on it later.
<SamB> fullermd: that'll still screw scripts
<SamB> you know the one nice thing about that concept?
<SamB> ... at least those nuclear power plants only give you trouble in *making* them
<fullermd> I was hoping it would lead to wealth and women, actually.  Oh well, back to the drawing board.
<poolie> lifeless: so, how about upgrading bzr on launchpad?
<poolie> good morning spiv, igc
<lifeless> poolie: the LOSAs are all in the UK this week
<lifeless> poolie: I don't think we should do anything risky until spm is at hand again
<poolie> next monday?
<lifeless> also, as we have a wide variety of users, we should really plan it carefully and socialise dates etc
<poolie> do you know what they're doing? some kind of sprint?
<poolie> sure
<poolie> i'm not proposing to just run the command
<poolie> i'm proposing to start that process though
<lifeless> by bzr on launchpad, do you mean 'change format to 2a' ?
<igc> hi poolie
<poolie> yes
<poolie> hello igc
<igc> after a busy weekend hacking from bialix and igc, BzrExplorer hits the streets
 * igc lunch and medical appointment - bbl
<tedg> Uhm, bad stuff just happened.  I did a commit on a repository that had about 1900 revisions and it now said "commiting rev 1" which is scary.
<tedg> But doing a "bzr log" I can see that all the old revisions are there, but now my log has negative revisions in it.
<bialix> run `bzr reconcile`
<tedg> bialix: Thanks, running now.
<lifeless> reconcile won't fix that
<lifeless> there is a bug open about doing 'bzr init + bzr merge + bzr commit' doing this
<lifeless> but we've not seen anything else cause it.
<lifeless> tedg: please file a bug about how you made this happen. use your bash history and ~/.bzr.log as data for what you did to make it happen
<tedg> lifeless: I think it's because I had a commit waiting on another operation using a lock file.
<tedg> I'm not sure if that'll show up in the log or not.
<lifeless> if so its a huge bug
<lifeless> gather as much data as you can
<lifeless> file a bug
<lifeless> try to reproduce
 * tedg is still waiting on reconcile...
<bialix> igc: I've made tar.gz and installer and upload them
<bialix> igc1: hi
<igc1> hi bialix!
<bialix> hi!
<bialix> I've upload release tarball and installer
<igc1> I'm just looking for them now
<bialix> do you want to provide the links for these files at wiki?
<bialix> https://launchpad.net/bzr-explorer/trunk/0.3
<igc1> yes please
<bialix> https://launchpad.net/bzr-explorer/+download
<igc1> I'll update the main overview page on lp too
<bialix> igc1: there: http://bazaar-vcs.org/BzrExplorer ?
<bialix> or made additiona page http://bazaar-vcs.org/BzrExplorer/Download
<igc1> bialix: just updating the main page is good enough for now I think
<tedg> Wow, reconcile is taking forever.  Do I want to know what it's doing?  30m of CPU time for bazaar at this point.
<bialix> added link to https://launchpad.net/bzr-explorer/+download
<bialix> igc1: btw, I've tried to hook in double click event handler for wt view, and failed. I'm not sure why
<bialix> I'm not expert in Qt :-/
<igc1> bialix: thanks for trying. My naive attempt at it failed as well, hence my email to garyvdm
<bialix> I suspect it's related to QDirModel
<bialix> igc1: I don't see the way to edit hats
<lifeless> tedg: reconcile won't help you
<lifeless> tedg: you don't need to run it for the problem you had
<bialix> thanks for your sample with bookmarks/tags, it looks interesting
<tedg> lifeless: Yes, but canceling in the middle seems like a bad idea, eh?
<lifeless> ctrl-C
<bialix> lifeless: IIRC spiv added code to fix wrong revno
<tedg> lifeless: s/life/fear/
 * tedg is more scared of bazaar than that :)
<lifeless> bialix: I don't see anything to do that in log
<lifeless> tedg: bzr is designed to be as robust as possible
<lifeless> ctrl-C shouldn't ever be more risky than using it over the internet.
 * tedg is going to have to stop using bazaar over the Internet.
<tedg> :)
<poolie> lifeless, mwh, jml, thumper, i filed bug 390502 re upgrading to 2a
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed] https://launchpad.net/bugs/390502
<lifeless> poolie: ah, so that was what you meant :)
<mwhudson> cool
<tedg> lifeless: Hah, well, whether I'm crazy or not.  Even running reconcile for that amount of time fixed my revno
<poolie> addition/comments/etc welcome
<lifeless> tedg: very odd :P
<mwhudson> let us know if we can help, but doing it without losas around will be a pain i expect
<thumper> :)
<lifeless> bialix: jam did change reconcile, but didn't put it in a commit message.
<poolie> are they have a sprint or something?
<lifeless> bialix: thanks for letting me know of that
<poolie> apparently yes
<lifeless> yes, LOSA sprint
<poolie> i see the mail now
<bialix> lifeless: I remember discussion on it
<tedg> Okay, I've documented everything in bug 390490 -- I'm not sure what the status should be now.  Thanks lifeless and bialix!
<ubottu> Launchpad bug 390490 in bzr "Revno reset to 1, others now negative" [Undecided,New] https://launchpad.net/bugs/390490
<Peng_> Should other related projects upgrade to 2a too? Several (bzr-svn, bzrtools, Loggerhead) already use rich roots, making it a lot easier.
<lifeless> their devs should be dogfooding locally already
<lifeless> moving mainline forces all devs to be using 1.16
<lifeless> thats somewhat more reasonable for bzr itself
<Peng_> FWIW, I have a copy of Loggerhead in 2a -- https://code.edge.launchpad.net/~mnordhoff/+junk/trunk.2a
<Peng_> Heh, I'm not dogfooding 2a locally. :D
<Peng_> Converting between packs/btrees and 2a on every push and pull would be slow, no?
<fullermd> I've got a 2a branch, that I don't use of code that's maintained in CVS  ;)
<Peng_> Heh.
<Peng_> Does stacking, say, a 1.9-rich-root branch on a 2a branch work?
<jml> I haven't tried :)
<Peng_> I think I've heard bad things about stacking and differing serializer formats.
<Peng_> I don't use stacking at all (well, except for LP's mirrors of my branches), but...
<fullermd> Well, bzr.dev still has the nested trees issue keeping it from upgrade'ing on that route.
<fullermd> I was GONNA say 1.16 will do it, but so far it's burned about a minute and a half of CPU trying to upgrade a repo with no revisions...
<lifeless> poolie: no
<lifeless> you can't stack across formats
<Peng_> What about minor format changes, like 1.6 to 1.9?
<lifeless> I'd need to check. We don't support it even if it happens to work
<lifeless> :)
<fullermd> Whoah, that's wacked out...
 * fullermd files a bug.
<lifeless> jml: I have had a merge proposal I sent it get ignored, or something
<lifeless> jml: what should I do
<Peng_> Back to my other question, does converting between rich-root-pack or 1.9-rich-root and 2a on every push and pull cause significant performance problems?
<Peng_> I suppose I should just test it myself.
<lifeless> its probably terrible at the moment
<lifeless> there are two bugs open
<Peng_> That would make dogfooding 2a on one's own a bad idea, then.
<jml> lifeless, is it this bug? https://bugs.edge.launchpad.net/launchpad-code/+bug/387683
<ubottu> Launchpad bug 387683 in launchpad-code "Cover letter for emailed merge proposal silently discarded" [High,In progress]
<lifeless> no
<lifeless> I've just sent a bug mail for it in fact
<lifeless> well, I say no, but what I mean is, the summary makes me think no.
<lifeless> jml: no, its nt
<lifeless> jml: I had a branch created, absent the correct metadata, absent the merge proposals revisions
<lifeless> poolie: I think we should wait to move bzr for launchpad to be able to upgrade our branches
<lifeless> poolie: [even if 'upgrade our branches means a LOSA for-script']
<jml> lifeless, I'm reminded that there is a known bug such that errors during merge proposal creation are not reported.
<lifeless> jml: once you've gathered any data you need, I'll push and manually submit for merge
<jml> lifeless, I'm not going to do any data gathering on that today, sorry.
<lifeless> jml: tomorrow morning?
<lifeless> poolie: so you object to the class name in my branch?
<jml> lifeless, I'd just push it and manually submit it if I were you.
<jml> lifeless, https://bugs.edge.launchpad.net/launchpad-code/+bug/376204
<ubottu> Launchpad bug 376204 in launchpad-code "Create merge proposal job doesn't send failure email" [High,Triaged]
<jml> lifeless, that's probably the bug you are seeing. I'll be able to do more when I get the oops report tomorrow
<jml> assuming I am at leisure to look at the bug.
<poolie> lifeless: i do object to the class name
<poolie> i think you should fix it
<poolie> lifeless: you mean wait for launchpad rather than, for argument's sake, doing the upgrades over sftp?
<poolie> fair enough
<poolie> now to escape from bug mail
<lifeless> poolie: ok, I'll change it. FWIW I chose it deliberately for more clarity in the class
<lifeless> but I'm not deeply attached
<poolie> the thing is it doesn't *mean* apha
<poolie> alpha*
<poolie> therefore it's not more clear
<lifeless> well
<lifeless> I'm confused by what it means then
<poolie> it is the first 2-series format
<poolie> i know i owe bzr a doc patch on this
<poolie> but there was a thread about it
<lifeless> will the next be 2b rather than e,g. 2.3?
<poolie> yes
 * lifeless is apparently totally confused
<poolie> the point is:
<poolie> it's hard to tell whether a format will change on disk between alpha testing and final release
<poolie> and it's hard to tell precisely which release it will land in
<poolie> and it's hard to tell which will be "the" format for 2.0
<poolie> therefore, let's not put them into the symbol that names the on disk format
<lifeless> if we get into this, I'll be wasting your time I think. So lets not. I'll re-read the thread and see if I can understand this time around. Because we put them into the on disk format to solve other issues
<lifeless> and we didn't have any difficulty with the first two points for the last 3 or so formats before 2a
<poolie> i'll try to finish things currently in train and then do a doc patch
<poolie> and we can discuss it there
<lifeless> I think not putting it into the disk format is a mistake, and if I failed to make that clear earlier, I'm really sorry.
<poolie> putting what in?
<lifeless> lets pause the conversation. I'll dig up the thread; it may be totally convincing.
<abentley> lifeless: Any idea how long it takes to reconcile a launchpad repository in 0.2a?  I started on Friday, and it's still going...
<fullermd> poolie: I don't understand "what does dev do specifically?"
<lifeless> abentley: uhm, a while.
<lifeless> abentley: is it thrashing?
<lifeless> poolie: what was the thread name?
<abentley> lifeless: load average is ~1.4, 1 CPU core is maxed.
<lifeless> abentley: thats longer than I would have expected
<abentley> Yeah, me too.
<abentley> lifeless: It also has some old bzrs in it, but still...
<abentley> It's spinning the spinner, fwiw.
<abentley> But it's been in "Reconciling repository:repacking texts:Finding text refe" since Friday.
<vila> hi all
 * fullermd waves at vila.
 * vila waves back 
<AfC> abentley: Maybe `bzr reconcile` is subject to a Red Giant Bug :)
<lifeless> igc1: I can work on iter_changes tomorrow
<igc1> lifeless: cool
<igc1> hi vila!
<vila> igc1: hi Ian !
<lifeless> hi vila
<vila> lifeless: hi Rob ;-D
 * lifeless EOD's
<bialix> igc1: we have broken release
<igc1> bialix: I'm just about to pack it in for the day
<igc1> bialix : is it osmething you need me for?
<igc1> or it is installer packaging, say?
<bialix> no, I'm fixing it right now and will release 0.3.1
<igc1> cool
<bialix> no, this is broken sources
<bialix> delete all pyc/pyo files from your sources and try to run bzr explorer
<bialix> https://bugs.launchpad.net/bzr-explorer/+bug/390539
<ubottu> Launchpad bug 390539 in bzr-explorer "Installation fails on Windows [bzr 1.16, bzre 0.3/0.4]" [Critical,In progress]
<bialix> option --app-suite broken
<igc1> oops - sorry
<igc1> the registry is in app_suite now iirc
<bialix> yes, I've chenged it
<igc1> bialix: btw, I fixed that hat selection bug and applied a fix for bookmark editing on osx
<bialix> yes, I saw
<bialix> so, 0.3.1?
<igc1> bialix: yep. Please do it ASAP - rev 100 (including your profile fix)
<bialix> ok
<igc1> bialix: I need to go
<bialix> bye
 * igc1 heads off to celebrate a good news day with the family - cancer all gone it seems. Hooray!
<igc1> night all
<bialix> !!!
<guilhembi> Hello! my colleagues asks this:
<guilhembi> "Anyone knows whether it is possible to copy a file or parts of its contents to another file and still preserve the history of the copied lines?
<guilhembi> The problem is that i need to copy some large code over to a new file and i would like to preserve the history of those lines. "
<guilhembi> and I believe the answer is "no".
<mwhudson> you're right
<vila> guilhembi: your're right, the answer is no. It's a planned feature, long term though.
<guilhembi> vila: thanks
<fullermd> Heck, you don't need to preserve the history, you can just guess at it later.  Ask any git person.
<vila> fullermd: joke aside, that's the reason why I often comments in commit messages about such transitions ('start implementing X based on Y')
<vila> s/comments/put comments/
<vila> I started doing that back in sccs days, less so now (most of my use cases were renames which are now tracked ;-)
<fullermd> That would take up precious space in the commit logs I could be using to mock and belittle the client, other developers, or myself...
<vila> think about it as mocking the tools instead :-D
<fullermd> Oh, heck no.  I'm far too animistic to dare mocking the tools I'm currently using.  They would TOTALLY find a way to get back at me for it.
 * vila lol (sometimes that acronym can be used in its true original meaning :)
<fullermd> vila: Can you take a look over the patch I just posted to the list?  It's kinda in your line.
<poolie> hello vila
<vila> hi poolie
<poolie> vila thanks for the emacs comment on the ui branch
<vila> poolie: np, thanks for working on that, I really like the design and I thought you could use some feedback from contexts you don't use on a regular basis
<Peng_> fullermd: Oh, thanks for the patch. I ran into the bug once, but it didn't annoy me enough to track it down. :P
<vila> fullermd: I can't believe it, I was so sure to have used '_unused' myself, looks like some modifications forgotten on my laptop when switching back to my desktop :-/
<fullermd> poolie: I don't understand your comment on bug 390512...
<ubottu> Launchpad bug 390512 in bzr "Downgrade spins on working tree" [Medium,Incomplete] https://launchpad.net/bugs/390512
<poolie> yeah it madde me think of some more tests to add
<poolie> about your point of allowing the user to turn off guessing?
<poolie> fullermd: iirc you said "it fails in bzr'dev"
<poolie> so does it fail with a traceback?
<fullermd> Oh.  No, bzr.dev still has bug 388727 around, so it doesn't even try to do anything.
<ubottu> Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] https://launchpad.net/bugs/388727
<fullermd> It was a note that you have to use 1.16 to reproduce the bug.
 * fullermd adds a comment.
<vila> fullermd: by the way, can you use --parallel now ? I've lost track on that.
<fullermd> vila: --parallel wants the testtools module, which I don't have an available package for   :|
<poolie> fullermd: but i thought bug 388727 was now merged?
<ubottu> Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] https://launchpad.net/bugs/388727
<vila> fullermd: ha yes, thanks for the reminding, sorry about that again :-/ I think it's a python-only module, I know zilch about packaging but it shouldn't be hard :-/
<fullermd> A fix was merged for 1.16.  AIUI, it's a somewhat hacky fix and lacks tests, which is why it wasn't put into bzr.dev.
<vila> wow, 1.16 hasn't been merged back to bzr.dev ?
<fullermd> vila: Yeah, but, see, if I made a package for it, some yutz would decide to stick me with maintaining it from now on   :p
<vila> fullermd: yup, I think it's kinda part of deal for using a faster selftest, the time you gain from the faster executions can be used more productively now, see ?
<Peng_> Packages are no fun! bzr branch lp:testtools /usr/local/lib/python2.5/site-packages/ :D
<Peng_> Or co --lightweight, I guess.
<fullermd> Having maintained installations with lifespans over a decade, I feel I can authoritatively say that fiddling around in /usr/local/ behind the package manager's back is *REALLY* no fun  ;p
<jml> Peng_: I think someone's going to package testtools rsn.
<vila> fullermd: whereas maintaining local version in ~/lib is quite usable :-)
<fullermd> Anyway, longer single-thread selftest just means I have more time for reading web com^W^W^Wimportant research.
<Peng_> Running parallel selftest on my VPS is fun. Swaps a bit, but it's fast.
<Peng_> 'Course, The EC2 thing would be even faster. :D
<vila> Peng: swaps ! Urgh, I'm surprised it's still faster then...
<fullermd> Ah, swapping isn't slow if you arrange it right.  Gotta put swap on its own disk so it doesn't interfere with anything else, see.  I've got this 5 meg drive in the closet I can dedicate to things like that...
<Peng_> vila: It's not that bad. Puts me maybe 20-100 MB over my total amount of RAM.
<lifeless> also you don't have ext3 to contend with
<lifeless> or do you?
 * Peng_ 's VPS is on ext3, with swap on the same hard drives. :D
<vila> Peng: How much RAM does the running system have and how many concurrent selftest are spawned ?
<Peng_> vila: How much total RAM?
<lifeless> Peng_: are the drives real?
<Peng_> lifeless: They exist only in my dreams. No, uh, it goes through Xen, and LVM, depending on how that works, and they're in a RAID 1 (or maybe 10) array.
<Peng_> vila: 360 MB total, about 140 MB actively used (more if Loggerhead is feeling hungry), and 4 processes.
<Peng_> Hardware RAID, though.
<lifeless> Peng_: so, they are vg's in LVM? or xen disk files?
<vila> Peng: wow, that's tiny
<Peng_> lifeless: Noo clue.
<lifeless> :)
<Peng_> lifeless: Heck, I don't even know what that question means. :D
<Peng_> vila: Yeah, I'm cheap. :P
<Peng_> Hmm, if they were just Xen disk files, using LVM would be pointless, no?
<fullermd> Oh, I can't `missing` a merge directive?   :(
<Peng_> vila: Could be tinier. 6 years ago, it would've been 64 MB. :D
<fullermd> Yeah, but 6 years ago bzr used WAY less memory  :>
<Peng_> Yes, things that don't exist don't tend to be RAM-heavy.
<Peng_> 6 years ago the test suite was REALLY fast, too. :D
<fullermd> Yeah, it didn't have any failures either.
<Peng_> "bash: bzr: command not found" doesn't exactly sound like a success.
<poolie> vila/mwh: do you have any opinion what SilentUIFactory should do if asked for input?
<poolie> fail? or read random stuff from stdin?
<poolie> the second doesn't seem really helpful
<fullermd> Peng_: It's not bzr's fault bash has errors   :p
<Peng_> If bzr+http uses SilentUIFactory, reading random crap from stdin sounds dangerous.
<vila> from memory, SIlentUIFactory returns None which leaves upper levels decide right ?
<Peng_> Err, wait, bzr+http uses stdin anyway. So it'd just break stuff, or do nothing.
<poolie> run as a cgi i guess it does
<LarstiQ> does anybody know where johnf hangs out?
<poolie> i think it did previously read stdin which suggests that path was never hit
<poolie> LarstiQ: on irc but not here? not really
<poolie> he lives in Sydeny
<poolie> Sydney
<LarstiQ> poolie: he pinged me over the weekend
<vila> poolie: yeah, looking at the code, I don't see how it can be used if input is needed... on the other hand making it *fail* can be useful for scripts that want to ensure no input is required
<poolie> Sydney
<poolie> blah
<poolie> i mean, "yes"
<vila> poolie: it's a bit strange it doesn't define get_boolean though
<poolie> it inherits from CLIUIFactory
<vila> poolie: hmm, get_boolean doesn't seem to be able to return None as currently coded
<poolie> i'm deleting that layer too
<poolie> i don't think it's useful anymore to make a static distinction between smart and dumb terminals
<poolie> because it's actually more than one dimension:
<poolie> does the user want progress, is there a tty for input, is there a tty for output, etc
<vila> agreed
<vila> poolie: quick question: do you know why _btree_serializer_c.pyx is not called _btree_serializer_pyx.pyx ?
<poolie> vila, i was just wondering the same thing myself!
<poolie> afaik it's an accident
<poolie> vila, could you merge 1.16 to trunk sometime?
<vila> poolie: sure
<Peng_> bzrlib/_dirstate_helpers_c.pyx and bzrlib/_knit_load_data_c.pyx too.
<vila> Peng: right
<mwhudson> poolie: fail
<Peng_> fail?
<poolie> mwhudson: win! thanks
<Peng_> lifeless: LVM.
<awilkins> jelmer: Just ran into something interesting : I did `bzr version` and got prompted for auth on an SVN repo
<awilkins> jelmer: bzr 1.14.1 bzr-svn 0.5.4
<awilkins> It's not even a URI I recognize it's prompting for
<mbnoimi> what the different between Bazaar and Subversion ?
<awilkins> mbnoimi: Subversion uses a single central repository ; Bazaar permits you to use distributed repositories
<awilkins> That's the most significant difference
<mbnoimi> what about the pull/push speed ?
<jpds> mbnoimi: http://bazaar-vcs.org/BzrVsSvn
<mbnoimi> is bzr faster than svn?
<awilkins> mbnoimi: For many use-cases, yes
<awilkins> mbnoimi: And I'd say the critical one is merging easse
<awilkins> mbnoimi: It makes certain ways of working cost much less than using subversion so they become more viable, like per-feature or per-bugfix branches
<LenzGr> mbnoimi: The good thing is that switching from svn to bzr is painless and the commandline interface is very svn-like.
<mbnoimi> awilkins: I got
<mbnoimi> I got it
<awilkins> You make a disk-space saving on many trees, and commands like status commands are in my experience a lot faster, as are checkouts
<awilkins> (as long as the revision data is already downloaded or present on a LAN)
<mbnoimi> but I couldn't find any shell integration for bzr on ubuntu where there are many shell integrations for svn
<awilkins> mbnoimi: On win32 there is TortoiseBZR, which is not by any meaasure as mature as TortoiseSVN
<mbnoimi> awilkins: I know it, I need one for ubuntu/Linux
<awilkins> On Ubuntu.. I think there is a nautilus plugin but I think it's quite slow because of the way GVFS works
<LenzGr> mbnoimi: Try qbzr or the bzr-gtk plugin, if you need a GUI
<awilkins> mbnoimi: And if you are an eclipse user, there are a couple of plugins for that
<fullermd> Don't forget the Explorer thing that was just released...
<mbnoimi> LenzGr: they are not shell integrations !
<jpds> mbnoimi: What do you mean by 'shell integration'?
 * awilkins has not treid that thing yet
<LenzGr> mbnoimi: On my zsh, bzr commands expand nicely.
<LenzGr> (If that's what you are referring to)
<awilkins> He means GUI file manager integration
<mbnoimi> jpds: just like TortoiseSVN (right click)
<mbnoimi> awilkins: could you give me a link?
<mbnoimi> awilkins: I googled about it but I couldn't find anything
<awilkins> mbnoimi: nautilus-bzr is part of bzr-gtk
<awilkins> Apparently
<awilkins> http://bazaar-vcs.org/bzr-gtk
<awilkins> The "Bazaar Explorer" thing sounds nice too
<mbnoimi> awilkins: I've installed bzr-gtk but I didn't notice any thing in nautilus
<mbnoimi> awilkins: even I looked in apt and I found nothing !
<awilkins> mbnoimi: Do you have the GNOME Python bindings installed?
<mbnoimi> awilkins: I didn't see it in Synaptic ?
<mbnoimi> awilkins: so I'm not sure if it's installed
<awilkins> You want python-gnome2-desktop
<mbnoimi> awilkins: yes, I got it. It installed
<mbnoimi> awilkins: how I can be sure that nautilus-bzr is working correctly ? From my side I didn't see any action in right menu in nautilus
<awilkins> Neither do I ; I'm not sure how you configure it
<mbnoimi> awilkins: I just installed bzr-gtk from Synaptic nothing else
<awilkins> I'm afraid I don't know then ; I'm usually content to use the CLI and spawn qbzr windows from the command line when I need some GUI lovin'
<mbnoimi> awilkins: anyway thanks for help, I'll migrate my repos from SVN to bzr today
<awilkins> mbnoimi: I use it in parallel with the SVN repos at work successfully
<awilkins> mbnoimi: It's hard to change peoples habits with version control ; even when you're the guy who migrated them to SVN in the first place..../
<fullermd> awilkins: Well, once they've seen you push svn on them, why _would_ they ever listen to you again?   ;>
<awilkins> fullermd: In fairness, this was before Bazaar was in version numbers mod 1
<awilkins> fullermd: And they'd spent 2 years deliberating on whether to use CVS or Visual SourceSafe
<mbnoimi> before leaving, in SVN I can specify access rules of svn repos by editing passwd & authz files. In bzr I couldn't find any document talking about access rules, could you tell me how I can specifying that rules?
<awilkins> fullermd: :-p
<awilkins> mbnoimi: There are no access rules except access to full tree
<awilkins> mbnoimi: Bazaar itself has no access rules, you configure access to the transports you use
<awilkins> mbnoimi: It's a bit silly to try and restrict access to subtrees in a VCS where everyone has a copy of the whole repository
<mbnoimi> hummm, but I want to make some folders just for read only and the others forbidden
<awilkins> mbnoimi: Aside from breaking those folders into seperate branches, can't be done
<fullermd> Oh, you could probably do something with a pre_commit hook on the "central" branch to prevent undesirables from being responsible for changes to given areas.
<mbnoimi> awilkins: we're programing team in a commercial company so there are many access rules needed
<fullermd> But there's nothing you could do about what they do in their own local branches.  They're root there, after all.
<mbnoimi> fullermd: that's mean bzr not suitable for commercial usage !
<fullermd> Not necessarily, it just means you have to think about things differently than you do in svn.
<mbnoimi> fullermd: access rules are very important in our case
<fullermd> Don't think about the access rules you have now; think about what you're trying to _accomplish_ with those access rules.
<fullermd> For instance, you have sections of the tree that are read-only [for certain users].
<fullermd> Now, how are you preventing them from changing those files locally in their svn checkout (but not committing the changes)?
<fullermd> The answer almost certainly is "you're not, you can't, that's ridiculous".  What you're actually trying to do is not prevent them _changing_ the files, but prevent them _checking in_ changes to the files.
<mbnoimi> fullermd: I can preventing them from committing , that's it
<fullermd> So a hook on the "central" server saying "only these people can check in/merge/etc revisions that change these files" accomplishes the same thing.
<fullermd> You can't assuredly  do anything about them committing changes there in their local branches, but that's equivalent to them making local changes in their svn checkouts; it doesn't affect anybody but them.
 * fullermd sprinkles a few more pronouns into that sentence, just to make his English teachers twitch.
<fullermd> (I'm somewhat sure pre_commit hooks could currently do that.  If they can't, it's probably a bug, and they should be able to.)
<jelmer_> awilkins: you need a newer version of bzr-svn
<jelmer_> SamB: 'bzr version-info'
<awilkins> jelmer_: Thanks, just updating server :-) ; was a weird link though, never touched it. It's recognizably something to do with the server it's on but not something I would touch
<LarstiQ> moin jelmer_
<awilkins> jelmer_: Still doing it with bzr 1.16 / bzr-svn 0.6.2 / subvertpy 0.6.8
<awilkins> jelmer_: Although the link it's trying to auth with has changed
<johnf1> LarstiQ: I see I don't have to bug you abut bzr-svn :)
<LarstiQ> johnf1: you already did over the weekend, and today I saw those pings ;)
<jelmer_> awilkins: what's the sort of URL its prompting for?
<LarstiQ> johnf1: thanks for doing so btw
<jelmer_> mbnoimi: there is nautilusbzr, included with bzr-gtk
<LarstiQ> johnf1: all left now is to give the packages some test spins, and then they can be copied over
<jelmer_> mbnoimi: it's experimental though
<awilkins> jelmer_: https://cubit.extranet.collab.net/svn/cubit
<awilkins> jelmer_: This is on a Collabnet CuBIT server
<awilkins> jelmer_: Before it was https://cubit.extranet.collab.net/svn/cubit/branches/hilarity/ui/extauth/cubit-skel
<jelmer_> awilkins: that requires authentication here, even with svn
<awilkins> jelmer_: But I've no plausible reason why it would try accessing it from a "bzr version"
<LarstiQ> jelmer_: are you still using https://edge.launchpad.net/subvertpy/+download ?
<jelmer_> awilkins: no idea
<jelmer_> LarstiQ: no, http://samba.org/~jelmer/subvertpy/
<awilkins> jelmer_: pull seems to work fine (seems a bit quicker too)
<awilkins> When you run from your local folder, do you have to copy the extensions to the bzrlib folder to use them?
<LarstiQ> jelmer_: can you point launchpad's download page at that?
<jelmer_> LarstiQ: It's set up to, but that feature seems to've broken recently
<awilkins> jelmer_: That's odd, doesn't seem to do it if you've installed instead of running from build folder
<LarstiQ> johnf1: I think I'm happy. Shall I copy over bzr-svn now?
<johnf1> LarstiQ: ye please and bzr and bzrtools as well
<LarstiQ> johnf1: will do
<johnf1> thanks
<LarstiQ> johnf: aand they're published
<poolie> night all
<LarstiQ> night poolie
<LarstiQ> jelmer_: can you approve me for ~subvertpy?
<LenzGr> So I wanted to test the Bzr Explorer, but it fails with the following message:
<LenzGr> $  bzr explorer
<LenzGr> bzr: ERROR: No module named lib.util
<LenzGr> You may need to install this Python library separately.
<LenzGr> Has anyone seen this?
<LenzGr> I can't find said python lib...
<LarstiQ> LenzGr: how did you install Bzr Explorer?
<LenzGr> LarstiQ: I branched the lp project into my plugin dir, as stated in the instructions
<LarstiQ> LenzGr: k
 * LarstiQ tries the same
 * LenzGr uses openSUSE 11.0, FWIW...
<LarstiQ> LenzGr: works for me, on Debian Lenny
<LenzGr> LarstiQ: OK, I guess I will submit a bug report then :)
<LenzGr> Oh wait...
<LenzGr> I guess my version bzr-qt is too old.
<LenzGr> 0.8...
<LenzGr> Never mind...
 * LenzGr tries to update
<vila> LenzGr: if updating solve your problem, file a bug anyway, bzr explorer should checks its dependencies
<LenzGr> vila: Can do. Agreed, the error message could be a bit more helpful
<AfC> $ bzr help revisionspec
<AfC> bzr: ERROR: No module named subvertpy
<AfC> You may need to install this Python library separately.
<AfC> huh?
<verterok> AfC: bzr-svn requires subvertpy
<verterok> hi! :)
<AfC> verterok: which is what? [any idea why this would have broken now whereas it was working silently for ages]
<verterok> AfC: did you updated bzr-svn?
<AfC> verterok: [and, hi! back Guillermo :)]
<AfC> verterok: yea
<verterok> AfC: installing the dependency should fix it :)
 * AfC wonders what the dependency is. There's no *subvert* package on my system
<johnf> Afc: you using the ppa?
<AfC> johnf: no
<verterok> AfC: https://edge.launchpad.net/subvertpy
<AfC> "Alternative Python bindings for Subversion"? Never heard of it
<verterok> AfC: and if you'r using Ubuntu adding the ~bzr ppa should be enough: https://edge.launchpad.net/~bzr/+archive/ppa
<AfC> verterok: no, not using Ubuntu. Stopped using Debian 7 years ago. Never looked back.
<verterok> AfC: don't know if it's packaged for your distro :/
<verterok> AfC: bzr branch lp:subverty; and install it from source ;)
<AfC> Does anyone know if there's a way to tell bzr-svn to use whatever it used to use?
<AfC> verterok: ok. Is it a bzr plugin, or am I going to have to jump through hoops to try and install it somewhere?
<verterok> AfC: I think subvertpy was part of bzr-svn
<AfC> Oh shit
<verterok> AfC: what distro are you using?
<AfC> verterok: Gentoo on systems I control, RHEL on systems I don't.
<AfC> verterok: (and some Solaris, unfortunately)
<verterok> AfC: for  Gentoo it should be quite easy to create an ebuild....for the RHEL and Solaris...I don't know :(
<AfC> verterok: of course
<AfC> Just the usual "oh, joy, another dependency that doesn't already exist"
<AfC> we went through this already once with Subversion needing to be build by hand. :|
<verterok> AfC: subvertpy avoid requiring a patched subversion :)
<AfC> "great"
<verterok> but you need subvertpy :)
<AfC> "great"
<monkey_d_luffy> I accidentily deleted (through a bad makefile) a directory in my project. I would like to restore it from bzr. But from what I can see, I can only "export" a whole branch.  How can I do this?
<AfC> monkey_d_luffy: does
<AfC> $ bzr status
<AfC> monkey_d_luffy: show it as removed?
<AfC> verterok: [Any idea how to tell bzr-svn to use the subverty checkout I just built?]
<monkey_d_luffy> AfC: yes, the whole dir contents is shown as removed.  How can I restore this specific directory (and files and subdirs)?
<AfC> monkey_d_luffy: then
<verterok> AfC: move the build into the bzr-svn checkout? :)
<AfC> $ bzr revert path/to/directory
<verterok> AfC: or include it in the PYTHONPATH of bzr
<AfC> monkey_d_luffy: should restore it
<AfC> move it into... um
<monkey_d_luffy> AfC: thanks
<AfC> monkey_d_luffy: (if you ever *really* get backed into a corner, you can always just branch another branch
<AfC> (hm)
<AfC> with say
<AfC> $ cd ..
<AfC> $ bzr branch bad/ good/
<AfC> $ mv good/missing/ bad/
<AfC> (sic)
<AfC> or something to that effect)
<AfC> monkey_d_luffy: you've got full history, so you can always get back
<monkey_d_luffy> AfC: full history as long as I have commited :p          I did loose a bit of information, but not much I think.   This scared me.  If the remove was a dir up... I would have lost everything... also ".bzr"
<monkey_d_luffy> I think it's time to backup to read-only media
<AfC> monkey_d_luffy: nothing so drastic needed ... but this is why it's a good idea to push your work elsewhere from time to time
<AfC> [even internal work-in-progress branches we tend to push up to our public server; not so much for anyone else to see, but it is another defence against what you describe - and tends to be fresher (since easier) that proper backups (which we also do!)]
<Sheepherd> you here lifeless?
<tedg> lifeless: Added a script to bug 390490 to recreate it.  I now know how to make the revno's backwards :)
<ubottu> Launchpad bug 390490 in bzr "Revno reset to 1, others now negative" [Undecided,New] https://launchpad.net/bugs/390490
<vadi2> For a patch made with bzr diff, how can it be applied?
<Tak> patch < blah.diff
<Sheepherd> just reading "bazaar in five minutes" and im about to "publishing your branch with launchpad"
<vadi2> And for windows? the said contributor has an odd setup of a gprs modem in a vm because it doesn't work on linux
<Tak> cygwin + patch < blah.diff? ;-P
<vadi2> heh
<Sheepherd> set up my account properly and now the tutorial says: "$ bzr push bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/myproject" replacing john.doe with you own launchpad username
<Tak> I dunno, tortoise might have some util for applying a patch
<Sheepherd> i put Sheepherd @ both places but it doesnt work
<Sheepherd> returns the errow: "Unable to loop up default port for ssh
<Sheepherd> error*
<Sheepherd> someone knows why this happens to me? win xp 32bit sp3
<vadi2> Firewall?
<Sheepherd> i allowed the app
<Sheepherd> but wait a mom... gonna check if thats the prob
<Sheepherd> nope... doesnt work without firewall
<Tak> specify the port in the url?
<Sheepherd> how?
<Tak> bazaar.launchpad.net:22
<Sheepherd> k thx gonna try after a reboot
<AshtonKem> Hey, quick question. I have my own branch on launchpad. But after I did a merge from trunk, it turns out that trunk is broken. How would I revert one revision back from trunk, but not my branch?
<vila> jam: ping
<jam> hi vila
<vila> jam: I just wanted to clarify the naming rules for pyrex/python modules as there seem to be several right now
<vila> _py.py for python _pyx.py for pyrex right
<jam> vila: it changed over time
<jam> _pyx.pyx actually
<jam> :)
<vila> yes :)
<jam> but yeah, Robert said he prefers that
<jam> and I don't really care
<vila> Ok, so it allows to use the same method names in both implementations
<vila> I'm updating _dirstate_helpers to that scheme and aligning all other module names (the final aim is to be able so safely predict the generated C file name when pyrex is not available)
<vila> I also like to call them pyrex methods/modules instead of C methods/modules to make it clearer if one day we have a third pure-C implementation for one module
<vila> In fact, that already works for patience diff
<vila> jam: no objections ^ ?
<vadi2> Is it planned to fix bzr-gtk anytime soon?
<jam> vila: no objections
 * SamB wonders why his completions for "bzr" are so lame right now -- it doesn't complete directories in "bzr co --lightweight", for instance!
 * SamB is using zsh
<Sheepherd> when i try to publish my branch with launchpad i get this error: http://pastebin.com/da8a7a5b
<Sheepherd> why is that so?
<Tak> Sheepherd: are you using the keyset that you set up with launchpad?
<Sheepherd> Tak: whats that?
<Sheepherd> nvm found the issue
<Sheepherd> forgot one slash somewhere in the command :/
<LCIDFire> Hi. Could someone give me a hint how to get a bzr branch imported into git
<awilkins> LCIDFire: Bidirectionally or once?
<LCIDFire> awilkins: Every once in a while - but just pulling
<awilkins> LCIDFire: Well, I'm not sure if bzr-fast-import works incrementally
<awilkins> LCIDFire: But that's maybe a good place to start. And there's a bzr-git plugin too.
<LCIDFire> awilkins: But it seems to me that they are the other way around
<awilkins> LCIDFire: bzr-fast-import is based on git-fast-import, so the output of the frontend for bzr should be compatible with git (?)
<awilkins> LCIDFire: I've not used bzr-git but if it's like bzr-svn it should support push
<LCIDFire> awilkins: I'd just submit patches instead of pushing
<lamalex> I ran bzr shelve --all and got this 'bzr: ERROR: Tree transform is malformed [('missing parent', 'new-16'), ('missing parent', 'new-1')]'
<lamalex> anyone know why?
<dash> woah
<dash> no, but I sure would like to
<lamalex> heh me too
<LCIDFire> awilkins: do you know whether piping works?
<awilkins> LCIDFire: piping from what to what?
<awilkins> LCIDFire: fast-export | fast-import  ?
<LCIDFire> awilkins: from bzr fe to git fi
<awilkins> LCIDFire: It should work, if it's going to work
<LCIDFire> awilkins: at least it does not complain too much - we'll see what it does
<LCIDFire> awilkins: what is a checkpoint in bzr language?
<awilkins> tag?
<awilkins> I'm not sure what a checkpoint in git is though
<LCIDFire> it's over 1000 commits
<awilkins> LCIDFire: Ah, that would be a pack boundary, I suppose
<awilkins> LCIDFire: It auto-repacks at intervals
<LCIDFire> awilkins: could be
<awilkins> lamalex: shelve was changed to use the same operations as the VCS does, but I'm not sure for the specific reason for your error, but it might be that you have a file in a folder that hasn't been added??
<awilkins> lamalex: Looks like a bug anyway
<LCIDFire> at 2000 commits
<lamalex> awilkins: i have many files in my folder that haven't been added
<lamalex> that shouldnt matter though.. if it does- definitely a bug
<LCIDFire> awilkins: it's done - and seems pretty good - thanks a lot
<awilkins> LCIDFire: Excellent.. does it seem to have an "incremental" feature?
<LCIDFire> awilkins: it does not "seem" - but it might be smart enough (hopefully)
<LCIDFire> awilkins: even if it is - it will probably still need a complete export of the branch - which is not a nice thing to do :(
<awilkins> http://www.fthieme.net/drupal6/node/77
<awilkins> Apparentlt it does support it
<awilkins> Right, hometime
<LCIDFire> awilkins: I seem to overlook the phrase where it states it...
<jelmer_> LarstiQ: yeah, one sec
<SamB> hmm ... is it possible for bzr diff to show context information like git diff does?
<SamB> I mean, after the @@ .. @@ line?
<SamB> (well, at the end, actually)
<SamB> for example:
<SamB> --- a/arch/x86/kernel/signal.c
<SamB> +++ b/arch/x86/kernel/signal.c
<SamB> @@ -340,6 +340,8 @@ __setup_frame(int sig, struct k_sigaction *ka, sigset_t *set,
<shane_fagan> Hey im trying to push to launchpad but bzr keeps telling me no revisions to pull
<shane_fagan> Or push ha
<garyvdm> shane_fagan: what makes you think that there are revisions that have not been pushed?
<shane_fagan> It isnt showing up on launchpad
<shane_fagan> and I pushed it about 20 minutes ago
<garyvdm> try running bzr log -l 1 lp:{your branch]
<garyvdm> That will confirm if you have pushed, and the launchpad ui has not updated it's cache
<garyvdm> Which is what I suspect.
<shane_fagan> no output
<shane_fagan> strange
<garyvdm> Please pastebin terminal.
<garyvdm> brb
<shane_fagan> there is nothing to pastebin
<garyvdm> Ok - what is you branch on launchpad?
<shane_fagan> Ill try again just give me a sec
<shane_fagan> Hmm still didnt work lp:~shanepatrickfagan/+junk/zeitgeist_empathy
<garyvdm> and if you do "bzr log -l 1" in the directory that you are pushing from?
<shane_fagan> shane@shane-laptop:~/zeitgeist_empathy
<garyvdm> lp:~shanepatrickfagan/+junk/zeitgeist_empathy is empty
<garyvdm> No revisions
<shane_fagan> yep thats the problem I tried pushing to it but it says no revisions to push
<garyvdm> What happens if you do just bzr log -l 1"
<garyvdm> bzr log -l 1
<shane_fagan> nothing
<garyvdm> So your local branch is the same as the launchpad branch - so push is working fine.
<garyvdm> Both your branches are empty.
<garyvdm> Have you done bzr commit?
<shane_fagan> I have 1 file in the one on my computer
<shane_fagan> Yes but I havent on this branch
<garyvdm> You need to do bzr add
<garyvdm> then bzr commit
<garyvdm> then bzr push
<shane_fagan> Ok that must be my problem
<shane_fagan> bzr: ERROR: Path(s) are not versioned: "lp:~shanepatrickfagan/+junk/zeitgeist_empathy"
<garyvdm> What did you try?
<shane_fagan> bzr commit lp:~shanepatrickfagan/+junk/zeitgeist_empathy
<garyvdm> No - you first need to commit locally, and then push to launchpad.
<garyvdm> So just bzr commit -m "your message"
<shane_fagan> Ah there I feel really stupid
<garyvdm> Don't worry.
<shane_fagan> Thanks for the help
<abentley> SamB: To do that, supply --diff-options="-p"
<SamB> abentley: is there a configuration option for that?
<ddaa> I have a very strange problem here that seems to be related to bzr in a weird and indirect way.
<ddaa> I run an apache server, with Trac and ReviewBoard on mod_python.
<ddaa> Both of them interfacing with bzr.
<abentley> SamB: All commands can be configured with aliases, e.g. bzr alias "diff=diff diff --diff-options=-p"
<ddaa> And if I run them both in different subinterpreters, then the ElementTree monkeypatching fails the second time it runs.
<ddaa> With AttributError, no ElementTree in module.
<ddaa> If I run them both in the same subinterpreter, it works.
<ddaa> (actually, the test was with one in main_interpreter, and one in a sub-interpr, but I doubt it makes any difference).
<ddaa> Does it makes sense to anyone here?
<SamB> abentley: ah
<abentley> ddaa: No, not something I've heard of.
<beuno> jam, hi
<beuno> are around?
<jam> hi beuno
<beuno> jam, got a sec to help me figure out a bbc bug?
<beuno> (or what I think is a bbc bug)
<beuno> https://pastebin.canonical.com/18839/
<beuno> this is a new 2a branch created today
<beuno> I suspect stacking bugs: the return of the undead
<jam> stacked or not?
<beuno> stacked
<beuno> with 1.16
<beuno> 1.16rc1 on the other end (LP)
<jam> beuno: do you get the same error if you just try to do "bzr branch lp:..." ?
 * beuno tries
<beuno> jam, not into a shared repo with all the revisions already present
<beuno> not sure how to test it without the revisions present
<beuno> (as it's my branch, etc)
<beuno> but someone else tried it, and it did fail
<jam> so does merge still fail "in a shared repo with all the revisions present"?
<beuno> cprov, ping?
<cprov> beuno: yo
<cprov> beuno: I don't know anything about bzr :)
<beuno> cprov, did you get the error with my branch on merge, or on branch?
<cprov> beuno: ah, yes, one merge or pull, it seems to be a problem in the smartserver.
<beuno> jam, seems so, but this is new to 2a, because we've been error-less since ~1.14rc1 or so
<jam> beuno, cprov: to test this out locally, you can "bzr branch myrepo/devel testrepo"
<cprov> beuno: https://pastebin.canonical.com/18844/
<beuno> ah
<beuno> jam, so on pull it breaks as well
<jam> and then cprov oddly enough that is a different traceback than https://pastebin.canonical.com/18839/
<jam> not that it really matters
<jam> I have some thoughts
<jam> but I'll try to check it here
<beuno> thanks
<beuno> it's release week
<beuno> and I need to get that branch landed somehow  :)
<jam> have to wait for it to download
<jam> beuno: I'm not sure if I'll have access to your branch
<beuno> jam, I think you should, but I'll subscribe you anyway
<jam> beuno, cprov: just to be sure, can you access it via sftp?
<jam> (you should be able to, and that is the current workaround)
<cprov> jam: I can try, one sec
<beuno> jam, even if we could, EC2 can't
<cprov> jam: it seems to work over sftp
<cprov> jam what's the 'nosmart' trick for bzr+ssh ?
<lifeless> moin
<beuno> cprov, lp+nosmart://...
<beuno> hiya lifeless
<lifeless> jam: before you go, reviewing the patch I copied you on is really important to me ;)
<cprov> jam: after the successful merge with sftp, bzr+ssh works as well
<lifeless> jam: ah, found the review from you - thanks.
<beuno> cprov, jam, it seems that once the revisions are in the shared repo, all is fine
<beuno> smells exactly like the 1.13 stacking bug
<lifeless> I think it is
<lifeless> which is, that the delta being created on the server is too big
<beuno> lifeless, and why did it come back in 2a?
<lifeless> don't know yet
<lifeless> there are two possibilities
<lifeless> a) the code that chooses what to push/request, to ensure that good deltas can be made, is broken.
<lifeless> b) the code that makes good deltas, is broken
<lifeless> c) Something I haven't thought of.
<beuno> ok, progress
<beuno> now
<beuno> 1) do you want me to file a bug?
<lifeless> no
<lifeless> its already filed
<beuno> 2) how can I get passed this, and land my branch, as it's the last day to land fixes on Launchpad?
<lifeless> use sftp
<beuno> I can't
<lifeless> or nosmart+
<beuno> it needs to go through EC2
<beuno> and EC2 uses lp:
<lifeless> teach EC2 to use sftp or nosmart
<beuno> re-building the EC2 image will take...  4 or 5 hours
<lifeless> Downgrade your branch to 1.9-rich-root
<lifeless> which will take longer :P
<beuno> I have about 2 hours to land this
<lifeless> land it by hand
<beuno> how?  it needs to be in LP, and whenever it's pushed to LP it breaks
<lifeless> that last bit didn't parse
<beuno> how can I land this branch, if it breaks when it's pushed to Launchpad?
<cprov> beuno: it doesn't help if you reapply the diff in a fresh branch ?
<cprov> probably not, ignore me.
<beuno> cprov, maybe, I don't know what will fix it at this point
<beuno> maybe not stacking it
<beuno> but it will take hours to push it as well
<cprov> beuno: branch lp:~cprov/launchpad/beuno
<beuno> cprov, thanks. I'll get someone who doesn't have the revs to branch it
<cprov> beuno: I didn't merge you branch successfully in my local repo, it was in dogfood. I've reapplied your diff in a fresh branch in my machine.
<beuno> cprov, the problem is that you will have stacked the branch, so it may contain the same error
<lifeless> beuno: get a LOSA to push your branches revisions to whatever branch you stack on
<cprov> beuno: right
<beuno> lifeless, of course, all LOSAs are sprinting in London and sleeping by now  :)
<beuno> fantastic day, as you can see
<lifeless> yes
<beuno> lifeless, I'll try and figure this out, maybe using chinstrap for speed. But, can you please make sure this is treated as critical?  it will bring the Launchpad team to a stop
<lifeless> beuno: it is
<beuno> lifeless, thank you
<lifeless> beuno: however you will /need/ to fix EC2 in the short term
<beuno> lifeless, yes, I will make sure everyone is aware
<lifeless> because that can be done without blocking on server side changes which this needs
<beuno> yeah, we can tackle it on all fronts
<lifeless> jam: ping? or are you gone already?
<abentley> beuno: You don't *need* to run the test on EC2.  You can run them locally.
<beuno> abentley, yes, I can stop working for 5 hours while tests run
<beuno> also, PQM will fall over as well
<abentley> beuno: Sorry, I thought that that this was a critically-important branch.
<beuno> abentley, it is. But tests locally take longer than EC2 (5hs vs 2.5)
<abentley> lifeless: couldn't this be that issue where stacking is too aggressive, so it doesn't with the smart server, just dumb clients?
<lifeless> abentley: I think its the same cause, but the details will be different for CHK
<lifeless> 07:16 < lifeless> a) the code that chooses what to push/request, to ensure that good deltas can be made, is broken.
<lifeless> 07:16 < lifeless> b) the code that makes good deltas, is broken
<lifeless> 07:16 < lifeless> c) Something I haven't thought of.
<jam> beuno: btw, I can't see your branch
<jam> I assume you never got me subscribed
<jam> lifeless: I'm here, but I'm just about to head out the door
<lifeless> jam: do you agree with my analysis - have you done more analysis on this yourself?
<jam> lifeless: I just managed to download launchpad itself
<jam> I was going to poke at it, but haven't got there
<lifeless> jam: you don't need lp; there are bzr branches suffering
<jam> and yes, it is either a, b, or c :)
<lifeless> do you have a hunch, given you touched this area for chk most recently?
<jam> lifeless: so unfortunately this is happening on the *server* and we don't get the server traceback
<jam> so I'm not sure where it is happening
<jam> it certainly looks like the "iter_interesting_nodes" is thinking different things locally than it does on the server
<jam> otherwise, it should have found that text to be missing, and have requested it be filled in
<lifeless> bug 390563
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when merging or branching" [Critical,Confirmed] https://launchpad.net/bugs/390563
<lifeless> jam: ^
<lifeless> bzr branch lp:~mbp/bzr/progress progress
<lifeless> is suffering apparently
<jam> lifeless: so that would indicate it isn't a bbc thing
<beuno> jam, re-pushed
<lifeless> oh right yes
<lifeless> man, my thinking cap was not working at all :)
<jam> Are we sure Martin's 'progress' branch wasn't originally pushed with a "broken client" ?
<lifeless> jam: not entirely
<lifeless> I'll get him to run the fixer
<jam> So... we can be quite sure of it for the LP branches, since they wouldn't have pushed up a --2a without it :)
<lifeless> indeed
<jam> but i'll play around with it a few different ways
<jam> Unless you take care of it tonight
<jam> I need to go pick up my son
<jam> I might check back in later tonight
<lifeless> kk
<jam> beuno: I still get "bzr: ERROR: Not a branch: "bzr+ssh:/...~beuno/launchpad/sprites-more-fixes/"
<jam> I'm not on the Launchpad team
<jam> I can only see the trunk because jml subscribed me
<beuno> jam, you are subscribed
<beuno> can you go to: https://code.edge.launchpad.net/~beuno/launchpad/sprites-more-fixes
<jam> beuno: nope
<jam> :(
<beuno> really?
<beuno> argh
<beuno> you show up on the subscribers list...
<beuno> jml, can you help?
<beuno> jam, are you logged in?
<beuno> on edge
<jam> beuno: yep
<jam> yep
<jml> beuno, what's the problem?
<beuno> ~jameinel is subscribed
<beuno> jml, jam's subscribed to a branch
<beuno> and he still can't access it
<jam> lifeless: my simple direct tests with a --2a conversion of bzr.dev and about 500 extra revisions in a stacked location does *not* reproduce this
<jam> so we'll need to try something else
<jam> lifeless: I'll be back later
<beuno> lifeless, FYI, branching trunk locally, and merging the sprites branch into it, and pushing, doesn't trigger this problem
<beuno> no idea why
<beuno> but it doesn't
<jml> beuno, jam needs to be subscribed to db-devel also.
<beuno> jml, smells like a UI bug
<beuno> (thanks(
<jml> beuno, it's a very complicated one that I'd be glad to discuss with you & fix when we both have the time to do so :)
<beuno> jam, try again when you're back
<beuno> jml, :)
<jml> after packing, can I delete obsolete packs?
<jml> safely, that is.
<beuno> jml, make sure the branch still works (bzr log?) and yes
<beuno> I do that routinely on the office branches
<lifeless> jml:  you can remove the contents of obsolete_packs/, not the dir itself
<lifeless> jml: but you should 'sync' first
#bzr 2009-06-23
<jfroy> jelmer: there a way to list ghost revisions or try to figure out where to grab missing revisions? Loggerhead is dying on a new revision in which I've branched a few svn remote branches because it's missing revisions
<lifeless> poolie: ping
<thumper> poolie: ping too
<poolie> hello thumper, lifeless
<poolie> was a late night
<lifeless> poolie: on your progress branch, can you please run the fixer script from the other bug
<lifeless> bug 305964 or some such
<ubottu> Launchpad bug 305964 in nautilus ""Preferred Applications -> Multimedia" should have "Do Nothing" as selection" [Undecided,Invalid] https://launchpad.net/bugs/305964
<lifeless> well, not that #. but something :P - documented in the mail I sent to announce last week about networking bugs
<lifeless> jml: could the branh6/7 thing with LP be the bug I filed about the puller not noticing format changes?
<poolie> lifeless: yes that's the next thing i was going to do
<poolie> thumper, what's up?
<poolie> jam: still around at all?
<thumper> poolie: was wanting to talk
<thumper> poolie: although now is probably not a good time
<lifeless> poolie: jam headed out to pickup his son; he says he may drop in later
<lifeless> poolie: when you've done that, if your progress branch is fixed, it means that the bug you commented on is probably CHK specific; if your progress branch isn't fixed it could be generic.
<poolie> lifeless: ok, so that branch is diverged from my local copy of it
<poolie> it may be the same as the one on my laptop
<poolie> i'll look into it
<poolie> thumper just ping me later
<thumper> ok
<lifeless> poolie: ok; if you need help/assistance let me know. One thing I'll mention is that the fixer script doesn't accept lp: urls.
<lifeless> poolie: other than that it should be trivial to use.
<poolie> so
<poolie> there's not much content in that branch that i actually want
<poolie> i can just delete it, unless it's useful debugging information to see whether the script works
<lifeless> please fix it
<lifeless> it will tell us whether or not you were seeing the known bug, or something new affecting all formats
<lifeless> the fixer is pretty quick
<poolie> ok
<poolie> so the affected branch is on launcphad
<poolie> do i run it across sftp?
<lifeless> bzr+ssh
<gcpeters> hey everone.. i'm a fairly new user of Bzr and I had a question about the .bzr folder and vs2003 web applications.
<lifeless> python fixer.py bzr+ssh://bazaar.launchpad.net/~mbp/bzr/progress
<lifeless> gcpeters: shoot
<gcpeters> unfortunately we have some legacy projs under vs2003.  It appears that folders starting with a period throws off vs for web projects
<gcpeters> I noted that svn usrs had the same issue but they resolved it with a .net hack by going to _svn
<gcpeters> is there an option for bzr to use a different root folder for the branch information?
<lifeless> not at the moment, no.
<gcpeters> ok
<lifeless> (sorry)
<gcpeters> no worries..it'll be an incentive to convince my manager to switch to vs2005 faster. :)
<gcpeters> thx though.
<LaserJock> is it possible to do equivalent to svn-copy with bzr-svn?
<SamB> jelmer: grr, why does a bzr svn-import have to do so many reads of the bzr repository?
<SamB> or, noo, wait, those are swap-ins aren't they ...
 * SamB should have looked closer at gkrellm
 * SamB wonders what the percentages in the SWAPIN column even mean
<poolie> isn't maritza nice :)
<SamB> poolie: who/what?
<SamB> what ubuntu release is currently comparable with testings/unstable?
<dash> do you mean "which one is the newest"? karmic
<lifeless> SamB: karmic is probably closest at the moment; its usually, as dash implies, whatever ubuntu version is newest.
<SamB> dash: I mean which one should I have in my /etc/apt/sources.list for bzr-related PPAs, given that I'm actually using testing/unstable
<lifeless> SamB: karmic
<SamB> lifeless: how come they don't have a name for that ?
<lifeless> SamB: its done differently to debian
<lifeless> unlike debian, after a release ubuntu has a period of anarchy where noone can safely run it
<lifeless> while the mass merges from debian happen, the toolchain gets rebuilt - everything built again
<SamB> lifeless: say WHAT?
<mwhudson> poolie: yes, hang on to that one
<SamB> oh
<SamB> oh, btw, how come you always release right before GHC?
<lifeless> coincidence
<lifeless> we release right after gnome ;)
<garyvdm> Whats GHC?
<mwhudson> glasgow haskell compiler usually...
<lifeless> haskell
<jml> lifeless, I don't think so. I've specifically told the puller to mirror those branches each time I've upgraded them.
<lifeless> jml: is that done by setting the 'next pull time' ?
<jml> lifeless, yes.
<lifeless> then it would still fit my bug
<jml> lifeless, you've lost me.
<poolie> mwhudson: on to maritza?
<lifeless> jml: I filed a bug that when the puller runs on a branch with no new revs but a format change, it doesn't remirror the branch
<lifeless> you're saying yo don't think that fits your scenario, because you've told the puller to run, but I don't see that that stops it fitting the situation I described
 * SamB never dreamed that darcs' use of _darcs had any advantages
<jml> lifeless, the scanner is the thing that updates the format on the branch page, the puller works entirely from the next pull time and notices format changes.
<jml> lifeless, bug 376276 wouldn't explain end-users branching from a branch and getting an old format. It would explain discrepancies between the website's display of format and what I might expect the format to be, however.
<ubottu> Launchpad bug 376276 in launchpad-code "mirror doesn't notice format changes without a rev change" [Low,Triaged] https://launchpad.net/bugs/376276
<SamB> jml: so what do you think is going wrong?
<SamB> the puller is just pulling into the same branch without running --upgrade?
<SamB> er. without running "bzr upgrade"
<lifeless> SamB: the puller shouldn't upgrade; it zaps and remirrors
<SamB> lifeless: oh
<SamB> lifeless: you're sure about that?
<SamB> have you *seen* it do this?
<lifeless> SamB: I wrote the original code
<SamB> and you're sure nobody changed it?
<jml> and since then we've fixed it. but it still does zap & remirror.
<lifeless> SamB: I'm sure its been changed, but I'm also sure ^
<lifeless> SamB: because upgrade is very expensive
<lifeless> SamB: compared to zap and pull
<SamB> really ?
<SamB> that's wierd
<SamB> why is that?
<lifeless> copying is cheaper than calculating
<SamB> what if the other end is slow?
<lifeless> then it takes a while, but launchpad isn't wasting CPU cycles
<SamB> true
<SamB> I hope you actually keep a backup while this goes on?
<lifeless> SamB: no, why would we?
<SamB> in case the other end goes down half-way through or something
<lifeless> this is a mirror we're maintaining
<lifeless> most of the lp branches are hosted anyway, so the other end is on the same LAN [FSVO LAN]
<SamB> oh
<lifeless> jml: bug https://bugs.edge.launchpad.net/bzr/+bug/390563 - any chance of getting the server traceback that is written to .bzr.log?
<ubottu> Ubuntu bug 390563 in bzr "absent factory exception from smart server when merging or branching" [Critical,Confirmed]
<SamB> you mean you aren't talking about what happens if I mirror a repository from some random URL?
<lifeless> nothing to do with the command line bzr behaviour
<lifeless> or qbzr/bzr-gtk etc either
<SamB> it sounded like you were discussing launchpad
<lifeless> we are
<lifeless> the internals of launchpad
<jml> lifeless, perhaps. we don't have a facility for it, but we could probably grab a LOSA sometime this evening.
<lifeless> jml: it would be of great assistance to debug the cause quickly
<SamB> so, are you talking about the code that maintains a branch I set up to mirror a URL?
<jml> lifeless, ok. then your best bet is to contact a LOSA directly, I think.
<lifeless> SamB: and that maintains the http mirrors for hosted branches
<lifeless> jml: Are there plans to tie this into oops?
<lifeless> [this == bzr serve exceptions]
<SamB> lifeless: in the case of a non-hosted branch, does it zap before re-mirroring on format changes?
<jml> lifeless, no immediate ones. we'd love to, of course
<mwhudson> poolie: yeah
<lifeless> jml: I'll file a bug then
<jml> lifeless, but these days, mwhudson & I's days are basically made entirely out of interruptions.
<thumper> poolie: ping
<poolie> mwhudson: you might look at bug 390542
<ubottu> Launchpad bug 390542 in loggerhead "Installation fails on Windows [bzr 1.16]" [Undecided,New] https://launchpad.net/bugs/390542
<poolie> thumper: hi
<thumper> poolie: call?
<mwhudson> poolie: yes, a catch up of loggerhead bugs is on my list of things to do today
<mwhudson> after lunch though
<poolie> thumper: sure
<lifeless> jelmer_: ping. please explain why you reopen tasks on bugs that people move to bzr-svn with reasons - it means we won't get into back-and-forth
<poolie> i should read your check-1 branch i guess?
<lifeless> if its not reviewed yet, please. stacking-policy is actually more urgent though
<lifeless> as it makes upgrading a series branch impossible
<poolie> lifeless: thumper asks: brisbane-core pack can take a long time, recompressing things
<poolie> does this mean that finishing a stream to a smart server might sometimes take a very long time?
<lifeless> 'why are you running bzr pack'
<jelmer_> lifeless: there's some duplication in bzr-svn that can be fixed, but even when that's done the main problem is that bzr deals with full file texts
<poolie> well, forget about me running bzr pack
<jelmer_> lifeless: I don't see how commit builder fits into all of this
<lifeless> jelmer_: with jams next commit to bzr.dev, commit will hold one copy of the file in memory
<poolie> is it possible that finishing a stream could take a very long time if it causes repacking?
<jelmer_> lifeless: I don't see what commit has to do with this
<jelmer_> lifeless: this bug is about fetch
<lifeless> jelmer_: its the API you're using
<lifeless> add_lines is part of commit
<lifeless> jelmer_: anyway, bzr _has_ lower memory API's. bzr-svn should use them.
<jelmer_> lifeless: bzr-svn doesn't use commit
<lifeless> jelmer_: this won't get you below 160MB to commit a 160MB file, but it will get you below 1GB
<lifeless> jelmer_: which is what the guy is complaining about. I Agree we need to fragment-or-something, but thats a different issue.
<lifeless> jelmer_: I know you don't use commit builder
<lifeless> poolie: potentially yes. FSVO of 'very long time'
<lifeless> poolie: a few minutes perhaps
<lifeless> may 10 or 15 on the mysql trunk or openoffice. And in those cases, it will do that once every few years.
<jelmer_> lifeless: It's not just that, it's also that I can
<jelmer_> 't afaik iterate over a large file without loading it into memory
<poolie> lifeless: ok, but not hours? apparently a full 'bzr pack' of launchpad can take over an hour
<lifeless> poolie: that seems slow to me
<lifeless> poolie: and we can look at reusing compression groups in the future
<poolie> ok
<lifeless> poolie: a normal push only autopacks, which is logarthimic backoff
<poolie> yes, i thought this was something we can potentially tune later
<poolie> right, that too
<lifeless> so trunks will only do the equivalent of a full pack when they hit the next power of 10 revisions over their current count
<poolie> another question: tim says the launchpad branches need to be reconciled because they have inconsistent head pointers
<lifeless> reconciling stacked branches should be very fast
<poolie> however, this takes a long time, and might block out people from writing to those branches for days
<lifeless> reconcile them on the server in batch, and upgrade for the users.
<lifeless> there is a bug open about having a button to request upgrades
<thumper> lifeless: reconcile on LP 2a format takes over 4 days
<lifeless> thumper: /stacked/ branches should be very fast to reconcile
<thumper> these are the trunk, unstacked ones
<lifeless> thumper: you've already reconciled them as part of the upgrade
<lifeless> haven't you?
<thumper> I reconciled the original branch, and upgraded, but when I pulled in the updates, there were inconcistent heads in those
<thumper> we didn't stop commits for 4 days to do this
<lifeless> thumper: thats why you needed to reconcile the others before pulling in
<lifeless> we're working on making check and reconcile be able to look at just a few revisions
<thumper> there was no partial reconcile
<jelmer_> lifeless: what other codepaths could bzr-svn use that use less memory? Doesn't insert_record_stream() require a fulltext or a chunked text?
<lifeless> thumper: when thats done you can fix things up, if you're not experiencing errors at the moment. There is no ETA for it at the moment.
<thumper> well
<thumper> actually we are
<thumper> well, some people are
<lifeless> jelmer_: we're talking past each other. You're talking about 'use < file size memory'. I'm talking about 'use 2xfile size memory at most'
<thumper> those that reconciled thier local repos after I had fixed some of the issues in the later revisions
<thumper> and they can't merge their pack 0.92 branches into 2a
<thumper> without reconciling their 2a repo
<thumper> which takes ages
<lifeless> jelmer_: insert_record_stream or _add_text can both use less memory than add_lines, for 2a repos.
<lifeless> thumper:  then they'll need to reconcile their repositories. This is /why/ reconcile was such a big feature in the 'how to upgrade' docs.
<igc1> hi all
<jelmer_> lifeless: this bug report was unrelated to 2a (it's from march)
<garyvdm> Hi Ian
<lifeless> jelmer_: thats true; how does bzr-svn go for 2a formats?
<jelmer_> lifeless: also, how can add_lines() be using more memory than VF.insert_record_stream(ChunkedContentFactory) ?
<jelmer_> lifeless: It works fine, but I don't know about memory usage
<lifeless> jelmer_: I think we should either close with 'try with 2a', or you should actually measure how it does. AFAICT you should be able to use no more than 320MB with bzr for a 160MB file coming from svn
<lifeless> jelmer_: because add_lines requires buffer splitting and joining. Its terrible.
<jelmer_> lifeless: isn't that required for chunked data as well?
<lifeless> no
<lifeless> for starters, you don't need to use CCF if you have the full contents you can just use a FCF
<lifeless> and I encourage you to focus on 2a memory performance ;)
<jelmer_> CCF?
<lifeless> chunked content factory
<jelmer_> but isn't a list of lines just chunked data as well?
<lifeless> thumper: can you please make sure that there is a bug or something documenting the error some people are having ?
 * jelmer_ fears he's missing something obvious here
<thumper> lifeless: I'm about to
<lifeless> I want to make reconcile faster, but I can't remove checks that prevent fetching working etc.
<lifeless> jelmer_: lines have to be split exactly on \n
<lifeless> jelmer_: svn uses binary deltas
<RenatoSilva> is there a way to show a diff between branches?
<lifeless> RenatoSilva: diff -r branch:oldbranch
<lifeless> RenatoSilva: or diff --old oldbranch --new newbranch
<RenatoSilva> the latter makes more sense to me.
<RenatoSilva> you mean bzr diff right?
<lifeless> RenatoSilva: yes
<jelmer_> lifeless: sure, but eventually the result of that would be chunked data, not a fulltext
<lifeless> RenatoSilva: if you're in the new branch, the former is easier to type :)
<RenatoSilva> ok, -r is for revision?
<RenatoSilva> let me try...
<lifeless> jelmer_: sure, but the output of svn is chunked, *not* lines. To make it into lines then requires str copying, which gives you two copies.
<spiv> RenatoSilva: yes.  see "bzr help revisionspec" or http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#specifying-revisions
<lifeless> jelmer_: so by using add_lines you're doubling the memory usage, unless you're very careful to get rid of the svn output before calling into add_lines
<RenatoSilva> oh, branch: is literal
<jelmer_> lifeless: Sure; I'm just trying to understand why the current add_lines() code that John added, which uses some parent data caching, would be worse than my original code which used FCF
<lifeless> jelmer_: well, if its using the parent map stuff, thats a dict of old texts, so it will be huge in memory
<lifeless> not get_parent_map, but the cache of serialised forms
<lifeless> jelmer_: knits are problematic anyway, because of design defects we were not allergic enough to
<jelmer_> lifeless: ahh
<lifeless> jelmer_: Lastly, I want to delete add_lines
<jelmer_> lifeless: so in other words, the current code is optimal for knits but for bbc it would make more sense to use insert_record_stream() ?
<lifeless> I want VF to have /just/ insert_record_stream
<jelmer_> lifeless: optimal for knits in terms of speed I mean
<lifeless> jelmer_: possibly yes, I mean, I haven't looked at what the bzr-svn code is doing
<lifeless> knits should be very fast via insert_record_stream too.
<jelmer_> lifeless: it's basically caching two things; the texts (via LRUSizeCache) since they need to be available as base texts to delta against later, and some opaque structure returned by add_lines and passed into add_lines againg for parents
<jelmer_> lifeless: since insert_record_stream() doesn't receive the serialized parent texts in any form, how much will this impact performance against knits?
<lifeless> -> poolies
<lifeless> jelmer_: I will chat in a bit
<jelmer_> lifeless: thanks for being so patient explaining this :-)
<jelmer_> lifeless: I'll probably be gone by the time you get back, time for some sleep
<SamB> jelmer: current code is very slow here ...
<SamB> swaps a LOT
<jelmer_> SamB: which current code?
<jelmer_> SamB: I think I'm missing context, or are you referring to the conversation above?
<SamB> someone mentioned something about "parent caching" and "full texts"
<jelmer_> SamB: in bzr-svn yes, but that'll only really impact you if you have files that are tens of megabytes in size
<SamB> jelmer: just how many parents does it cache?
<jelmer_> SamB: 50 at most
<SamB> jelmer: that sounds like a lot
<SamB> does that get multiplied if there are many branches?
<jelmer_> SamB: no
<SamB> how would I know if bzr-svn is encountering files of that magnitude ?
<jelmer_> SamB: it's the files in your branch
<SamB> it's not MY branch ...
<jelmer_> SamB: well, after you've imported the branch
<jelmer_> SamB: this would only really be a problem if you're importing from a repository that *only* contains iso's
<SamB> oh.
<jelmer_> SamB: I mean, that sort of magnitude
 * igc lunch
<SamB> well, any idea why else bzr-svn would end up using more RAM than firefox?
<jelmer_> SamB: what are you importing?
<SamB> well, first valgrind ... then vex
<SamB> hmm, they do have a 1.5 MB Makefile.in and a 1.3 MB Makefile
<dash> impressive
<SamB> well, I guess the Makefile is local
<SamB> not in the branch
<SamB> oh, Makefile.in is from automake too ...
<jelmer_> SamB: even if you end up with 50 copies of the makefile that cache won't be a problem (1.5Mb * 50)
<SamB> jelmer: is there some kind of retainer profiling I can do to diagnose the problem ?
<mwhudson> heh, amusing
<mwhudson> repo.iter_inventories([revid, revid]) expodes
<jelmer_> SamB: Yeah, I think John posted something to the list about memory profiling a month or two ago
 * SamB finds the emacs frame where hee has Wanderlust open
<jelmer_> SamB: also, are you using the 2a format yet?
<SamB> jelmer: how do I do that?
<SamB> I've been using bzr from apt lately, mostly from PPAs but they seem to have dried up or something ...
<jelmer_> SamB: When you create a repository or branch you can specify the format
<jelmer_> SamB: 2a is still in beta, but I was curious as it has different codepaths (and memory usage) as knit packs
<SamB> jelmer: what is the minimum version of bzr that supports 2a?
<jelmer_> SamB: 1.16 I think
<SamB> jelmer: and how would I pass a format to bzr svn-import ?
<jelmer_> SamB: you need to create the repository first
<SamB> jelmer: oh
<SamB> and what flag do I use to do that?
<SamB> I didn't see any "2a" in current-formats
<jelmer_> I think it's not listed there because it's still in beta
<SamB> couldn't they just warn about it ?
<SamB> or maybe have a future-formats topic?
<jelmer_> SamB: bzr help other-formats
<SamB> jelmer: I thought that was for obsolete formats
<jelmer_> SamB: "bzr help formats" mentions it
<SamB> so will converting a repository convert all the branches?
<jelmer_> SamB: "bzr upgrade" won't touch anything but the current directory afaik
<SamB> do the branches even need converting?
<jam> poolie: ping
<jam> beuno: I was able to finally connect to your branch, and it failed over bzr+ssh, and looks like it is working via sftp
<beuno> jam, cool, so you're up to speed now
<beuno> we now just have to find a fix  :)
<beuno> note that I re-pushed it with some black magic
<beuno> and it didn't fail afterwards
<thumper> poolie, lifeless: bug 390951 filed
<ubottu> Launchpad bug 390951 in bzr "Revision not present errors in Launchpad's scanner" [Undecided,New] https://launchpad.net/bugs/390951
<jam> beuno: pushed to the same location?
<jam> or to a new one
<mwhudson> no New bugs in loggerhead \o/
<Peng_> Just lots of old bugs :D
<Peng_> :P
<mwhudson> Peng_: how do you trigger https://bugs.edge.launchpad.net/loggerhead/+bug/382765 ?
<ubottu> Ubuntu bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged]
<Peng_> mwhudson: Honestly, I've got no idea.
<Peng_> mwhudson: When I was testing Loggerhead once recently, I realized that it should probably be failing, but it wasn't.
<Peng_> mwhudson: So...I have no idea what's going on. :D
<mwhudson> hooray
<mwhudson> serve-branches http://... seems to be broken too?
<Peng_> It is?
<mwhudson> maybe
<mwhudson> oh wow
<Peng_> mwhudson: It is, but I think it's bzr-svn's fault.
<Peng_> mwhudson: bzr+http works. http does a PROPFIND but nothing else.
<Peng_> mwhudson: Wow what?
<mwhudson> Peng_: serve-branches http://localhost/.../loggerhead/trunk
<mwhudson> go to some revision page
<mwhudson> expand all
<mwhudson> and boooooooom
<mwhudson> like this: http://pastebin.ubuntu.com/201853/
<mwhudson> something somewhere is very not threadsafe
<Peng_> Wow, 300 lines of tracebacks.
<mwhudson> i wonder why this isn't happening on launchpad
<mwhudson> i'm going to file a bug and see if this goes away/makes more sense in the morning
<mwhudson> i guess there's massively inappropriate connection sharing going on
<mwhudson> aaaa
<mwhudson> today's lesson: don't share transports between threads
<mwhudson> and also, t2 = t1.clone(path); <use t1 and t2 in separate threads> --> utter fail for ConnectedTransports
<Peng_> Ah.
<mwhudson> Peng_: does https://bugs.edge.launchpad.net/loggerhead/+bug/390972 make sense to you?
<ubottu> Ubuntu bug 390972 in loggerhead "need to be more aggressive about transport thread safety" [Critical,Triaged]
<poolie> mwhudson: urgh, don't do that
<mwhudson> poolie: nmf!
<mwhudson> there are disadvantages to letting other people commit to trunk, it turns out :)
<Peng_> Don't do what? threading.local?
<lifeless> Peng_: create a transport in thread a, use in thread b
<lifeless> Peng_: when thread a may still use it
<poolie> spiv, igc, do either of you want a brief call?
<igc> poolie: would tomorrow morning be ok?
<igc> 10-ish say?
<poolie> fine with me
<poolie> just go ahead and call if you like
<vila> hi all
<mthaddon> erm, any idea why the main links for downloads, etc for bzr1.16 are for the edge version of launchpad?
<poolie> hello mthaddon
<mthaddon> hi poolie
<poolie> and hello vila!
<poolie> where?
<poolie> i mean which links?_
<mthaddon> http://bazaar-vcs.org/Download
<mthaddon> first links next to "Source of the stable release for any platform"
<poolie> i guess jml or somebody just copied the links
<jml> yeah, I copied them from the commented out lines in the wiki source
<jml> I guess they should be production links.
<poolie> is fixed
<jml> thanks.
 * davidstrauss is about to complain.
<davidstrauss> When are we getting fresh OS X .dmg files?
<davidstrauss> I'm happy to build 10.5 ones if I can get instructions.
<poolie> davidstrauss: there were instructions in the thread about this the other day from jfroy
<poolie> want to give it a try? you'd win acclaim throughout the land
<davidstrauss> poolie: Have a link?
<davidstrauss> poolie: just found it
<mneptok> you would win acclaim throughout the land, but from Mac users. who will turn on you like a pack of rabid, starving, insane wolves if your icon doesn't scale well.
<davidstrauss> mneptok: :-P
<mneptok> *muah* :)
<poolie> well, there is that
<poolie> don't even think about fixing openbsd selftest :)
<mneptok> poolie: i owe the list an e-mail, which will be sent when i return from .fi
<mneptok> "Your test suite violates about EVERY law of proper security practice this project relies upon. You are obviously a mental inferior, and why your parents let you live is beyond my comprehension. BTW, I have attached some patches you might try. When you're not drunk. Love, Theo de Raadt."
<davidstrauss> poolie: Will anyone care if I drop rebase, qbzr, and looms from the OS X build?
<poolie> i think some people will
<poolie> it might still be useful though at least as an intermediate step
<bialix> qbzr require PyQt4 and there are many questions from mac users about installing this GUI toolkit.
<bialix> so, bundling qbzr without PyQt is problem for the users
<bialix> that said: I think if you drop it, not so many people will complain
<davidstrauss> poolie: The package is building now, including all the same plugins.
<lifeless> davidstrauss: have you update to loom trunk?
<davidstrauss> lifeless: yes
<lifeless> davidstrauss: cool
<davidstrauss> lifeless: I saw the commit about 1.16 compat
<lifeless> :)
 * lifeless goes to organise dinner
<stewart_> does anybody have a suggestion on how to solve: Unable to load plugin 'gtk'. It requested API version (1, 15, 0) of module <module 'bzrlib' from '/home/stewart/lib/python/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)
<stewart_> latest gtk and latest bzr
<Peng_> stewart_: Which latest gtk?
<Peng_> stewart_: If it's a package, it may be out-of-date.
<stewart_> Peng_: bzr+ssh://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
<Peng_> Oh. :D
<stewart_> latest from bzr :)
<Peng_> stewart_: Well, I'd probably just edit __init__.py, adidng (1, 17, 0) to COMPATIBLE_BZR_VERSIONS, but that's kind of wrong. :D
<stewart_> does seem to work :)
<Peng_> stewart_: You should poke the bzr-gtk developers too.
<davidstrauss> Anyone want to try out my Bazaar 1.16 installer for OS X 10.5?
<Peng_> FWIW, using Loggerhead's repo, pushing the whole thing from 2a to 1.9-rich-root locally takes 1m11s, but pushing a couple revisions is close enough to instant that dogfooding it would be doable.
<Peng_> ("close enough to instant" == 2 seconds, FYI)
 * igc dinner
<Peng_> Remote pushes might be different, of course...
<lifeless> there is a critical bug open about IDS being used for bzr+ssh
<lifeless> till thats closed remote pushes will be rather different
<Peng_> I'm assuming it's not "good" different... :P
<lifeless> stewart_: file a bug on bzr-gtk
<vxnick> davidstrauss: I will
<davidstrauss> vxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip
<vxnick> thanks
<vxnick> davidstrauss: doesn't look like it's overwritten my previous bzr - where does it install bzr to?
<davidstrauss> vxnick: should be /usr/local/bin
<vxnick> that's showing me as 1.14.1
<davidstrauss> oh, that's cute
<davidstrauss> it installed everything to /
<vxnick> haha
<vxnick> got an uninstaller for it/
<davidstrauss> vxnick: just look in / by date
<vxnick> alrighty
<davidstrauss> i'll fix the installer
<davidstrauss> vxnick: Rebuilding the installer now
<vxnick> davidstrauss: nudge me when ready
<davidstrauss> vxnick: http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip
<vxnick> davidstrauss: thanks
<davidstrauss> vxnick: I've verified that it installs the right places now
<vxnick> davidstrauss: seems to work fine :)
<davidstrauss> vxnick: cool
<vxnick> davidstrauss: are you the maintainer for the mac images?
<davidstrauss> vxnick: Installing to / is such an amazingly dumb default
<vxnick> :P
<davidstrauss> vxnick: No, just someone frustrated with the slow updates and probably taking over
<davidstrauss> vxnick: But I am not a Mac developer, just a user. So this is my first OS X installer build.
<vxnick> sounds good
<vxnick> you did good
<davidstrauss> :-)
<vxnick> I was looking for a 1.16 build
<davidstrauss> vxnick: I do maintain RPMs
<davidstrauss> vxnick: And have for a while
<vxnick> cool
<davidstrauss> vxnick: Making my first Mac installer is enough for one night I think. Bedtime for me.
<vxnick> :)
<davidstrauss> vxnick: I've made some minor tweaks to the installer to fix man paths, but I haven't uploaded an update yet
<vxnick> oh, nudge me as usual then
<davidstrauss> vxnick: Contact me on IRC if you run into any issues
<vxnick> will do
<davidstrauss> vxnick: I won't update any more tonight
<vxnick> no worries
<davidstrauss> vxnick: Do you work for Canonical?
<vxnick> davidstrauss: nope
<davidstrauss> vxnick: Just a bzr+launchpad user?
<vxnick> davidstrauss: that's right :)
<davidstrauss> me too
<Hamaryns> ping gmb
<Hamaryns> hÃ© jelmer, is het gelukt om Trac naar Launchpad te migreren?
<LarstiQ> Hamaryns: in what sense?
<Hamaryns> Um, ok, back to English: Jelmer seems to be the guy that asked https://answers.edge.launchpad.net/malone/+question/73758 and I wanted to ask wether it worked since I am astruggling with the same problem
<LarstiQ> Hamaryns: ah, jelmer doesn't seem to be done with that yet
<Hamaryns> Iâm onto it with Graham right now, actually
<Hamaryns> keep an eye on https://answers.edge.launchpad.net/malone/+question/69864
<lifeless> gnight
<awilkins> jelmer: Is there any reason why --2a isn't compatible with bzr-svn?
<jelmer_> awilkins: 2a is compatible with bzr-svn
<jelmer_> Hamaryns: the actual import hasn't happened yet
<jelmer_> Hamaryns: but obtaining the xml did
<awilkins> jelmer: Specifically ; as a test I upgraded a --1.14-rich-root repo to 2a.. I think it make have halted silently though
<Hamaryns> right, I am in the same phase now, I mailed the xml file to graham binns, waiting for him now.
<awilkins> jelmer: I'll try it again
<jelmer_> awilkins: during "bzr upgrade --2a" you mean?
<awilkins> jelmer_: Yes, I think it may have halted there
<awilkins> jelmer_: The next thing to try is to pull it from the SVN repo into a fresh 2a repo
<awilkins> jelmer_: After I'm getting a "NoSuchRevision" error for what I presume is the tip revision of the branch concverned
<jelmer_> awilkins: and into a 1.9-rr repo works?
<awilkins> awilkins: This was a 1.9-rr upgraded to 1.14-rr
<awilkins> I'm trying upgrading again
<awilkins> jelmer_: This repo has some very large revisions in it
<awilkins> jelmer_: I think it halted during a repack
<jelmer_> awilkins: that's all inside of bzr itself; the NoSuchRevision error would be a bzr-svn bug though
<jelmer_> awilkins: are you running 0.6 ?
<awilkins> jelmer_: This is the lastest windows drop 1.16.1 with (AFAIK 0.6.1 bzr-svn)
<jelmer_> awilkins: in that case, this might be a known fixed bug
<awilkins> I'll try it again, I deleted the repo and I'm converting again from the backup
<awilkins> (taken immediately before conversion)
<awilkins> As long as it's not a bug related to subvertpy I can try updating my bzr-svn
<awilkins> subvertpy is a PITA to build on win32
<jelmer_> you shouldn't need a newer subvertpy
<awilkins> jelmer_: Aha, it halted during repacking inventories
<awilkins> jelmer_: No stacktrace either
<awilkins> So not a bzr-svn bug
 * awilkins tries pull-from-scratch
<zarq> hm, gcc on rhel 4.8/itanium is taking forever (over 12 minutes now) to compile _dirstate_helpers_c.c when i do easy_install bzr
<awilkins> zarq: It should take a few secnds
<awilkins> zarq: And that's exaggerating
<zarq> i'll try to install 1.15
<zarq> 1.13 installs fine, 1.14 1.15.1 and 1.16 take "forever" to build
<awilkins> It might be some quirk of Itanium I suppose
<vila> jam: ping
<bialix> igc: ping
<igc> hi bialix
<bialix> what is your timezone?
<bialix> re your latest change in bzre (revno 108): IIUC std_profile xmls always should be installed with sources?
<bialix> igc: if std_profile is must have then we have to add them to setup.py and windows installer
<igc> bialix: ah ok, I wasn't sure seeing it's not a 'package', just a directory
<igc> bialix: I'll do it now ...
<igc> bialix: do I update the packages list in setup.py?
<bialix> in setup.py you need to use package_data
<igc> ok
<igc> bialix: and in the installer, what there?
<bialix> section [Files], but installer I can update myself
<bialix> igc: I think Nick Allen should have separate team for qbzr-eclipse
<bialix> May be we want in the future to create big umbrella team for all qbzr-related things... I dunno
<igc> bialix: I'd like a bzr-desktop team myself, including qbzr, bzr-gtk and bzr-ide-integration
<igc> bialix: we need to get more consistency across UIs I think
<igc> bialix: and many topics are about design, not the technology
<bialix> yes
<bialix> igc: good news: translation template is imported! https://translations.launchpad.net/bzr-explorer
<bialix> igc: new bzr explorer icon in LP is funny :-)
<igc> bialix: the feet were just too fuzzy :-)
<igc> bialix: and my daughter, who put both together, preferred the new one
<bialix> yeah, this one has more positive energy
<bialix>  I really like it
<bialix> it's funny and positive
<bialix> but your slogan: "is for human beings" ;-)
<bialix> perhaps now you would add: and for extra terrestials too!
<bialix> :-)
<ddaa> Who said aliens are not human beings?
<ddaa> Xenist!
<bialix> Well, I never saw them
<jimmy_dean> Is it possible with bzr to do the following scenario: Have one master branch with one or more sub-branches, each having been independently initialized with "bzr init". Then be able to commit to any of the subbranches, but also have the ability to pull the master branch and get all of the subbranches.
<bialix> how can I know about them?
<bialix> jimmy_dean: yes and no
<ddaa> jimmy_dean: you appear to be requesting what we call "nested tree" tracking.
<jimmy_dean> yes :)
<ddaa> Which is not (yet) in core.
<jimmy_dean> does a master branch know about sub branches
<bialix> there is poor man emulation available in plugin
<jimmy_dean> is it in the works?
<ddaa> It's been in the works for years.
<jimmy_dean> oh really, what's the name of that plugin?
<bialix> scmproj
<ddaa> jimmy_dean: the person you need to harass about it is abentley.
<jimmy_dean> lol, ok
<bialix> harass about nested trees
<jimmy_dean> this would prove extremely useful for how we use bzr at the company I work for
 * ddaa nods enthusiasticly
<jimmy_dean> I'm surprised that it's not requested more often
<bialix> every day or so?
<jimmy_dean> oh really, wow
<bialix> every week -- for sure
<jimmy_dean> so is abentley the only one working on this functionality?
<jimmy_dean> does he need some help?
<abentley> jimmy_dean: I'm not currently working on this functionality.
<jimmy_dean> ok, so this functionality is currently abandoned?
<bialix> I don't think so
<ddaa> I guess it's "dormant".
<ddaa> Anyway, scmproj should be as good as what you can get from any other DVCS.
<abentley> jimmy_dean: It's on hold while I work on some other things.
<jimmy_dean> ok
<igc> night all
<jimmy_dean> abentley: thanks for letting me know
<bialix> igc: bye
<jimmy_dean> so how many active core developers are there on bzr, is it a project that needs some help?
<bialix> I think so
<jam> vila: pong
<bialix> hello jam
<jam> morning bialix
<bialix> :-)
<ddaa> There are bunch of core devs on bzr (several on them on payroll at Canonical), but the only software project that does not need help is a dead one.
<bialix> it's closer to evening there
<bialix> jimmy_dean: there is a lot places where one can help
<ddaa> jimmy_dean: nested trees could use some help, if only as a way of demonstrating active community interest. It's problably something very complex and reaching deep in the guts of bzrlib. So not a week-end project.
<abentley> ddaa: We are stuck at the design stage.  Coding help is not useful.
<ddaa> Then I think coding help would be most useful. I have deep respect for the bzr folks, but you have an unhealthy propension to analysis paralysis on some subjects.
<abentley> ddaa: I have written plenty of code, and it has not yet been merged.  Code help is not useful.
<ddaa> Ok.
<LenzGr> jelmer: Around?
<jimmy_dean> ok, maybe I could start looking at some bugs
<jimmy_dean> since I'm an experienced coder, but am relatively new to Python
<jimmy_dean> I'm a C/C++ guy mainly
 * LenzGr tries to compile subvertpy for bzr-svn, but gets compile errors
<jelmer_> LenzGr: hi
<LenzGr> jelmer_: Sorry to bother you, but could you look at this compile failure in subertpy? I wonder if it's my setup or a bug...
<jelmer_> LenzGr: sure
<LenzGr> ok, one sec...
<LenzGr> jelmer_: http://paste2.org/p/279813
<LenzGr> jelmer_: This is subvertpy-0.6.0, subversion-1.6.2 and python-2.5.2
<jelmer_> LenzGr: does /usr/include/subversion-1/svn_props.h contain a definition for SVN_PROP_REVISION_LOG ?
<LenzGr> jelmer_: Yes:
<LenzGr> 446:#define SVN_PROP_REVISION_LOG  SVN_PROP_PREFIX "log"
<jelmer_> LenzGr: subvertpy 0.6 is a bit old, it was the initial subvertpy release
<jelmer_> LenzGr: any chance you can try 0.6.8 ?
<LenzGr> jelmer_: Oh, sure! Weird, I wonder where I got that one from...
<ddaa> jelmer_: why "0.6"? Because you thought "Hm, I guess it's a bit more than halfway there", or something else?
<LenzGr> jelmer_: Will try and get back to you...
<jelmer_> ddaa: it's split out from bzr-svn, so I kept the bzr-svn version numbering up until I split it out
<jelmer_> ddaa: bzr-svn 0.6.0 was the first to use an external subvertpy
<ddaa> Ok.
<LenzGr> jelmer_: Please disregard, now it compiles fine. I should have taken a closer look at which version was the latest :)
 * LenzGr simply clicked on the topmost file at http://samba.org/~jelmer/subvertpy/
<jelmer_> LenzGr: ah
<jelmer_> LenzGr: perhaps I should reverse the ordering
<LenzGr> jelmer_: I think that would make sense :)
<LenzGr> jelmer_: In any case, I'll work on getting a package of it into the openSUSE build service (to support bzr-svn)
<jelmer_> LenzGr: cool
<abentley> jam: is there something I can do to help you diagnose this inconsistency?
<abentley> jam: When I got that error, bzr was transferring 190 revisions.  But the branch itself had less than 10 lefthand revisions.  Is the inconsistency being detected because bzr is doing too much work?
<jam> abentley: regardless too much work or not... we have a per-file graph where one side says a revision has 2 parents, and the other side says only 1
<jam> and you should certainly realize that 190 revs is easy to hit with 10 mainline :)
<jam> we *could* be hitting too much, but that would still be a bug in the per-file code
<abentley> jam: I recognize that there is a real inconsistency here.  I just think earlier formats weren't so sensitive to this kind of inconsistency.
<jam> abentley: can you link the bug report again
<abentley> jam: which bug report?
<jam> abentley: whatever the traceback was
<jam> sorry, email
<jam> brb
<jam> abentley: so it is possible that it is the new streaming fetch code
<jam> which tries to fill in things when it thinks other things are missing, etc.
<jam> certainly we might be looking at more than before
<jam> because the CHK pages give us more neighbors
<jam> than the minimal inventory XML delta
<abentley> jam: https://pastebin.canonical.com/18881/
<abentley> jam: It's also possible that the faulty revisions were because PQM was running an old bzr.
<jam> so the error is saying that the local repo is claiming 1 parent, but the merge source is claiming 2
<abentley> jam: I was pulling lp:~launchpad-pqm/launchpad/devel into my local, reconciled, repo.
<jam> abentley: well one thing we could try
<jam> r = bzrlib.repository.Repository.open('local')
<jam> r.lock_read()
<jam> t = r.texts
<jam> keys = t.keys()
<jam> parent_map = t.get_parent_map(keys)
<jam> remote_r = ...
<jam> repeate
<jam> and then compare remote_parent_map with parent_map
<jam> see how bad things are
<jam> there should be some keys missing on both sides
<jam> present entries should have the same value
<jam> it *sounds* like ghost issues
<jam> though you shouldn't have ghosts with bzr revisions
<jam> (versus Arch)
<jam> ahh....
<jam> and the new code notices that the inventories are different
<jam> because they have different per-file info... perhaps
<pygi> vila: poke
<abentley> jam: Working on it..
<jam> abentley: if you have 2 repositories with different per-file graph, that might cause the inventories to have different last-modified settings
<jam> if that was true
<jam> then "derived" inventories would have a different entry in the inventory
<jam> and that would show up during the inventory-diff stage
<jam> and tell us to fetch that record
<jam> which then gives different content, and boom
<jam> (versus XML formats, that assumed the XML line-delta held all the information about what was needed to be fetched)
<jam> though... the last modified revision should be known, since that is the text key we are using for insertion...
<jam> so maybe I'm off
<abentley> jam: So if I've done this right, there are 2918 inconsistent texts between the two repos.
<jam> ouch. that seems like a lot
<abentley> https://pastebin.canonical.com/18883/
<vila> pygi: Hi mario
<abentley> jam: It's a lot, but it's ~1% of the total texts.
<jam> abentley: it looks like you did it correctly
<pygi> vila: are you busy? I want to discuss bzr-gtk :)
<jam> by my read
<vila> pygi: yeah pretty busy :-/ Let's try anyway
<pygi> vila: basically, bzr-gtk is in problems IMHO
<vila> pygi: define problems :)
<pygi> Szi doesn't have time, Jelmer either, and I didn't have time even to fix that path issue and/or look at that dbus stuff
<jam> and at least all the ones I've seen so far say that your local repo claims more revs than the remote
<pygi> vila: no release for a year? :p
<jam> well, more parents
<abentley> jam: I don't think so.  My repo is claiming (('bugsemailaffectspath-20070306155409-3k9ueivfh05v4v3b-1', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),)
<jam> abentley: sorry, I read it backwards
<jam> parent_map is the local one
<abentley> jam: right.  But I did the list comprehension using remote_parent_map, since it would have the subset that's common to the repos.
<vila> pygi: ha, right, let's look at the active devs list to find a new RM then... abentley (oops), beuno (oops), garry (oops),
<vila> pygi: :-/
<pygi> vila: I'll have more time starting mid-next month so I'll at least fix windows problems
<jam> abentley: do you have the XML versions of these repos?
<beuno> vila, I'll be happy to work out a relaese for bzr-gtk after I manage to get loggerhead out the door  :)
<vila> beuno: err, we want it for yesterday, not next year :-D
<abentley> vila: I'd take over as the *leader* of pygtk.  I wouldn't want to RM without that much authority.  Too much strangeness in that codebase.
<abentley> vila: I mean bzr-gtk
<vila> abentley, beuno : I was *joking* I didn't think any of the ones I mentioned *can* actully become RM
<abentley> jam: I don't have an XML version of the remote one, and the local one has had revisions added since the conversion.
<beuno> :)
<vila> jelmer: you should know better than me if phanatik intend to do a bzr-gtk release shortly
 * vila kicks NFS a..^W head for working in all configurations except the one needed right *now*
<abentley> jam: Ah, fun!  All these bad texts contain 'abel' in their revision-id.
<abentley> jam: This suggests abel was using an old bzr, and it's not likely that current bzrs are broken.
<abentley> jam: abel thinks he was using 1.6 (not 1.16).  Could it have had such a bug?
<abentley> jam: so why does fetch care that the remote repository has wrong data about a revision that is already present in the local repository?
<jam> abentley: my guess is that his *derived* inventories are showing different content
<abentley> jam: it would be nice if we could somehow fetch the revisions without this affecting us.  Otherwise, it's hard to see how we can get properly reconciled across the team.
<abentley> jam: Could we indirect through an xml-based repo?  Or use a more generic fetch codepath?
<jam> hmm...
<jam> you could comment out the GCCHK stream source
<jam> in repofmt/groupcompress_repo.py
<jam> well, comment out returning it from _get_source
<jam> that would at least be something to try
<jam> it would go back to the "generic" path
<jam> though I can't swear by it
<jam> the other possibility is to force the InterDifferingSerializer
<jam> which I think would be the most likely to work
<abentley> jam: Cool, I'll try it.
<abentley> jam: No joy the first approach: https://pastebin.canonical.com/18887/
<abentley> jam: How do I force the InterDifferingSerializer?
<jam> === modified file 'bzrlib/repository.py'
<jam> --- bzrlib/repository.py        2009-06-22 21:55:37 +0000
<jam> +++ bzrlib/repository.py        2009-06-23 16:16:28 +0000
<jam> @@ -3489,6 +3489,7 @@
<jam>      @staticmethod
<jam>      def is_compatible(source, target):
<jam>          """Be compatible with Knit2 source and Knit3 target"""
<jam> +        return True
<jam>          # This is redundant with format.check_conversion_target(), however that
<jam>          # raises an exception, and we just want to say "False" as in we won't
<jam>          # support converting between these formats.
<jam> sorry for the spam
<abentley> jam: No joy: https://pastebin.canonical.com/18891/
<abentley> jam: So it seems this error is being triggered because we're adding records to a GraphIndex which are already present in that GraphIndex.
<abentley> jam: does that seem like a good thing to you?
<SamB> is there a way to ask bzr what file defines a given command?
<jam> abentley: so... not really, but we are doing so because there is a discrepancy, which *does* seem like a good thing to check
<SamB> jelmer: is there a nice way to find out the closest SVN parent of a working tree's commit, and how far away it was ?
<abentley> jam: It seems to me like we are checking something we shouldn't check, and getting an irrelevant error as a result.  The revisions I want to pull don't have inconsistent parents, AFAIK.
<abentley> jam: or at least, they don't *introduce* inconsistent parents.
<jam> so is any of this actually available?
<abentley> jam: The launchpad branches are not publically available.  Is that what you mean?
<jam> abentley: right, so *I* don't have the easy ability to look at these and see what it thinks needs to be transferred
<jam> my guess is that these revs say something different than the parent revs
<abentley> jam: One is lp:~launchpad-pqm/launchpad/devel.  I don't know whether you have access to that.  I can push my local repo to devpad, or whatever machine we both have access to.
<jam> I do have access to devel
<jam> abentley: if you want you can push the other to devpad
<abentley> jam: pushing...
<kirkland> jelmer: hey, vcs-imports question again
<kirkland> jelmer: i'm still not having much success at all with the launchpad auto vcs imports git->bzr for qemu
<kirkland> jelmer: however, i do have fast-export and fast-import working pretty reliably
<kirkland> jelmer: i'm wondering if it would make sense at this point just to cronjob something on my end
<kirkland> jelmer: that would do a fast-export, fast-import, and push periodically
<kirkland> jelmer: at least until LP gets its vcs importing sorted out
<abentley> jam: The faulty revisions were committed with whatever preceeded 1.16rc1 in the bzr beta PPA.
<jam> abentley: where is it pushed to?
<abentley> jam: /home/abentley/branches, but the rsync hasn't completed yet.
<kirkland> jelmer: also, i think you can delete lp:~jelmer/qemu/kvm-git-import-HEAD and lp:~jelmer/qemu/git-import-HEAD
<mxpxpod> jelmer: ping?
<abeaumont> hmmm, bzr is taking quite a bunch of resources here: 21683 alfredo   20   0 2936m 1.6g 1816 R   95 40.8   1037:31 bzr
<abeaumont>  
<abeaumont> is there any way to improve bzr-svn's performance?
<dash> Hmm
<dash> i'm trying to envision a workflow for loom
<dash> i have a big huge branch with changes all jumbled together in it. I want to stratify this into a set of patches for submitting to trunk (which is an svn repo and doesn't care about my local history)
<dash> so i guess one way to do it is to create a new branch from trunk, loomify it, merge my existing branch, and use shelve to selectively commit things to different threads?
<Isaiah> Is there a way to have bzr ignore everything except one file in a directory? Can I just do !filename like in git?
<Tak> ? ls | grep -v filename | xargs bzr ignore
<beuno> Isaiah, just don't add the other files?
<abentley> jam: This fixes the problem for me.  I know it's inefficient, but is it sane? https://pastebin.canonical.com/18904/
<Peng_> Isaiah: Use a * ignore rule, and then "bzr add" that one file.
<Isaiah> Ah cool, that works! Thanks Peng_ and beuno :)
<jam> abentley: I think you can do that sort of thing differently, but the check you are trying to do is there
<jam> namely, if we have it, skip it
<abentley> jam: What's a better way of doing it?
<lamalex> Can anyone help me with bzr bisect
<lamalex> the --help is ambiguous
<jam> abentley: if self.get_parent_map(key): continue
<jam> well
<jam> if self.get_parent_map([key]): continue
<jam> though that may do something based on fallbacks
<lamalex> If I'm looking for what revision a bug was introduced at, and the current revision has the bug would I want to do bzr bisect yes or no
<lamalex> bzr bisect yes [-r rev] The specified revision (or the current revision, if not given) has the characteristic we're looking for,
<lamalex> Is the characteristic im looking for the bug, or not the bug
<dash> you're looking for where a bug was introduced
<dash> so 'yes'
<lamalex> thanks
<abentley> jam: It would be nice to be able to predict the text keys before drinking the stream.
<jam> abentley: sinks aren't supposed to
<jam> as it sort of violates the "streaming" principle
<jam> as would having the source peak at the target
<jam> at least, that's what I've been told
<abentley> jam: I know that it does, but you can see why it would be useful.
<jam> abentley: sure
<abentley> jam: Still pushing the repo, by the way.
<jam> big repo, it would seem
<lamalex> wow, bzr bisect fails
<abentley> jam: .3 G, and twice that with obsolete_packs.
<lifeless> oioioi
<beuno> good morning lifeless
<lifeless> jam:
<lifeless> jam: https://devpad.canonical.com/~spm/bzr-logs.tgz
<mtaylor> lifeless: morning!
<mtaylor> lifeless: I'd just like to point out: /usr/lib/python2.6/dist-packages/bzrlib/util/bencode.py:22: DeprecationWarning: bzrlib.util.bencode was deprecated in version 1.16.
<Peng_> Somebody forgot a stacklevel=2.
<mtaylor> I mean, it's obviously not breaking anything - but it is annoying to see _every_ time I do anything
<Peng_> mtaylor: That error message is useless. It doesn't say *what*'s importing bzrlib.util.bencode. Is there a traceback in .bzr.log or something?
<mtaylor> Peng_: nope
<Peng_> Argh. I knew I should've sent a patch for that.
<mtaylor> heh
 * mtaylor _really_ hates stack traces that swallow incoming stack
<Peng_> mtaylor: I think bzr-svn or bzr-git imported bencode, and a development version fixes the deprecation warning.
<Peng_> fwiw
<mtaylor> Peng_: cool
<mtaylor> Peng_: I don't have bzr-git - but I do have bzr-svn
<mtaylor> not that I really need it atm...
<Peng_> Anyway, it's only a guess at what's causing it.
<garyvdm> Hi all
<lifeless> mtaylor: edit that file
<Peng_> That part of bzr-svn probably shouldn't get imported unless you're actively using bzr-svn.
<lifeless> mtaylor: on that line is a function call
<lifeless> add stack_level=2 to the call
<Peng_> stacklevel=2
<mtaylor> lifeless: symbol_versioning.warn(dep_warning, DeprecationWarning, stack_level=2)
<mtaylor> ah
<Peng_> No underscore.
<mtaylor> HAHA
<mtaylor> it's a local plugin
<mtaylor> thanks guys!
<lifeless> mtaylor: :)
<mtaylor> lifeless: /home/mordred/.bazaar/plugins/mysql/emailer.py
 * Peng_ sends a trivial patch.
<Peng_> mtaylor: Change it to use bzrlib.bencode.
<Peng_> mtaylor: (Or do a try...except ImportError for bzrlib.bencode, falling back to bzrlib.util.bencode.)
<mtaylor> actually... since I don't hack on mysql internals anymore - I might just uninstall the plugin...
<Peng_> Or that.
<lifeless> drizzle isn't mysql?
<mtaylor> god no
<lifeless> YHBT HAND HTH
<lifeless> ah, the sweet smell of trolling in the morning
<mtaylor> mmm
<lifeless> where are those bindings in your stack now?
<mtaylor> ooh. actually, that might be something I can whip up while sitting here in this conference...
<mtaylor> I'm certainly not actually getting anything out of the talks
<lifeless> what conf?
<mtaylor> lifeless: velocity
<mtaylor> lifeless: I'm speaking tomorrow, so I'm here today
<lifeless> its a LEAN conf or something?
<mtaylor> lifeless: does mainline bzr have default hooks for not commit conflict markers yet?
<mtaylor> that's the main reason I was keeping the mysql plugin around
<mtaylor> lifeless: it's an O'Reilly conference about Scaling
<lifeless> expand on ' default hooks for not commit conflict markers'
<mtaylor> lifeless: if you ran bzr resolve on a merge conflict, but you actually didn't catch all of the conflicts
<lifeless> 'bzr resolve foo' ignores the file content.
<mtaylor> lifeless: so somewhere in your code something is broken and has a <<< MERGE-SOURCE (or whatever the marker is)
<mtaylor> right
<lifeless> 'bzr resolve' scans all conflicted files and resolves those that look clean
<mtaylor> ok.
<lifeless> moral of the story, use 'bzr resolve'
<mtaylor> well, yeah. I like doing that
<mtaylor> you know when that doesn't work?
<mtaylor> when I pull changes into a branch, and one of the changes was adding a file that already existed in the branch I'm pulling in to
<mtaylor> I have to resolve each of those individually :(
<lifeless> yes
<mtaylor> but I can get over that
<lifeless> its a weak point
<mtaylor> while I'm whinging ...
<mtaylor> unshelve           Restore shelved changes.
<mtaylor> unshelve1          Restore shelved changes. [bzrtools]
#bzr 2009-06-24
<lifeless> mtaylor: its the older form of shelve
<lifeless> mtaylor: for folk with old shelves they need to get ack
<Peng_> Or for people on Windows, right?
<garyvdm> Hi - I'm getting an error trying to commit which is quite weird.
<garyvdm> http://paste.ubuntu.com/202463/
<garyvdm> Could not acquire lock "/home/garyvdm/qbzr/wd/qbzr/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable')
<garyvdm> There is nothing that I am aware of that could be holding a lock.
<garyvdm> Nothing running that is.
<garyvdm> Ah - never mind - I had a bzr runinng in my ide that was stoped in pdb that was holding the lock.
<poolie> hello
<poolie> jam, thanks for the analysis of 390745
<poolie> jml/thumper/mwh: I'm thinking about doing "reconfigure --stacked-on" or --unstacked soon
<poolie> robert questions whether this is a good use of time or not
<poolie> any opinions?
<mwhudson> poolie: YES PLEASE
<poolie> k
<thumper> poolie: how would that interact with LP?
<igc> morning
<poolie> hello igc
<poolie> thumper: um
<igc> hi poolie, thumper
<thumper> poolie: as in, reconfiguring a stacked LP branch
<thumper> hi igc
<poolie> it would work over hpss to let you configure branches to be either stacked or unstacked
<poolie> not sure what you're asking
<thumper> poolie:would it pull the necessary revisions from the stacked branch?
<thumper> poolie: how about the ability to override the suggested stacking branch?
<poolie> yes, it would potentially copy a lot of data when making the branch standalone
<thumper> poolie: is incremental reconcile very hard?
<poolie> lifeless estimates several days
<lifeless> thumper: its tricky; gotta copy some data exclude others while simultaneously altering it
<thumper> I'd say that is more important than playing with stacking right now
<thumper> IMHO
<thumper> or
<thumper> some optimisations for reconcile on 2a formats
<thumper> we're wanting to move more internal teams to the 2a format
<thumper> and james_w's ubuntu branches
<poolie> ok, that's useful feedback
<poolie> though it's not necessarily either/or
<thumper> heh
<thumper> no
<thumper> we want everything, and a pony
<poolie> in that i'd need to page in a lot of robert's state to do renconcile
<jml> delicious ponies.
<poolie> but i can do the stacking thing fairly quickly
<thumper> reduced swapping is always a win
<thumper> I'd still like the ability to tell the bzr client not to stack no matter what LP suggests
<thumper> which we can't do right now
<lifeless> the streaming fetch bug is highest IMO
<lifeless> reconcile is a pain, can't merge for lp developers is a blocker
<lifeless> other teams have /way/ fewer devs per branch, which makes transition much easier. Also smaller history.
<thumper> yeah
<thumper> +1 on streaming fetch
<spiv> lifeless: as in inventory deltas, or do you mean something else?
<mwhudson> i was assuming reconfigure --unstacked/--stacked-on wouldn't be especially hard
<poolie> me either
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/390563
<ubottu> Ubuntu bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged]
<poolie> so easy a manager could do it
<thumper> poolie: :)
<thumper> poolie: also a definitive "don't stack" flag should be easy too right?
<lifeless> mwhudson: the library call to change already takes care of fetch; more problematic is making a new repo when making a shared repo branch into a stacked branch
<lifeless> thumper: don't stack may require smart server verb changes. FWIW
<lifeless> thumper: but is a don't stack flag needed ?
<thumper> lifeless: I thought we decided a while ago that stacking was determined entirely client side
<poolie> so, seriously
<poolie> i have to make some calls today
<lifeless> thumper: I know the lp-code team have occasion to use it for testing, but outside that group?
<poolie> i was hoping i could do one or the other of them in the time i do have today
<thumper> lifeless: for unrelated branches, it is useful
<thumper> although, perhaps limited use
<thumper> poolie: pick one an do it!
<thumper> :)
<lifeless> thumper: /may/ require verb changes  ;)
<lifeless> thumper: we have more verbs doing more things, now.
<thumper> lifeless: is one "JFDI" ?
<lifeless> for a small hack, I'd most like to see network activity not overwriting stuff when there is no progress bar. Or something like that. Its a very visible ugliness
<poolie> lifeless: it's high on my list too
<lifeless> mwhudson: the bzr log from codehosting
<lifeless> mwhudson: is it safe to attach to the bug, or do you think there are things we'll want kept secret in them ?
<mwhudson> lifeless: i think it's pretty unlikely there's anything sensitive in there
<igc> poolie: ready for a call soon?
<Peng_> Yep, pushing 2a -> 1.9rr over hpss isn't very fun. 22 seconds, while 2a -> 2a is 6.
<Peng_> (For 11 revisions of loggerhead.)
<poolie> igc, yes, let me get a couple of things closed here
<poolie> will call you in 5?
<Peng_> Still usable, of course, but it doesn't make dogfooding very fun.
<igc> sure
<lifeless> Peng_: indeed
<Peng_> Well, I could upgrade lp:loggerhead to 2a when nobody's looking, and it would take them a while to figure it out... :D
<lifeless> I wouldn't
<lifeless> not till we fix the current set of critical bugs
<Peng_> What is the current set of critical bugs?
<Peng_> Absent factory, IDS being used for push, ?
<lifeless> lp knows :P
<Peng_> Yeah, that's mostly it, aside from some rich-root upgrade issues.
<Peng_> The other one is cross-format inventory delta streaming.
<lifeless> thats needed for cross format pushing to be pleasant
<poolie> igc https://edge.launchpad.net/bzr/+milestone/2.0
<poolie> Peng_: that url for you too
<lifeless> spiv: what are you up to today? Could I request https://bugs.edge.launchpad.net/bzr/+bug/338561 ?
<ubottu> Ubuntu bug 338561 in bzr "calling an unknown method logs noise (do_end, and a backtrace)" [High,Confirmed]
<poolie> lifeless, spiv, can you tell me about bug 390563 too?
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563
<lifeless> poolie: I'm investigating it at the moment
<lifeless> poolie: all I know for sure is in the bug
<lifeless> I think
<Peng_> poolie: Oh, thanks.
<spiv> lifeless: hmm, I could have sworn I fixed that a couple of months back.  Sure, I'll look at that.
<lifeless> spiv: lots of them in ~/.bzr.log on lp codehosting ;)
<SamB> spiv: could be that someone unfixed them
<SamB> or that the fix somehow got lost before being merged...
<lifeless> SamB: thats what we have tests for; and lp/bb both track merge status by revids
<lifeless> SamB: e.g. 'no' ;)
<lifeless> poolie: is there more you want to know about 390563?
<SamB> lifeless: depending on how forgetful you are
<SamB> and/or whether you actually manage to write said tests
<spiv> SamB: it's possible that I actually just fixed something similar but not quite the same, too :)
<spiv> SamB: my memory of things I did a few months ago tends to be pretty hazy.
<SamB> spiv: yeah, there's also that
<lifeless> spiv: a few months ago, at my place, we looked at it and said 'lets file a bug and keep going on streaming'
<spiv> lifeless: ah
<spiv> Also, I think before that I fixed a similar issue to do with streaming bodies, perhaps.
<lifeless> yes, that rings a bell
<mwhudson> er
<mwhudson> pqm seems to be getting absentcontentfactory errors with two non-stacked branches
<lifeless> mwhudson: details?
<lifeless> mwhudson: push or pull
<lifeless> could be bug 365615
<ubottu> Launchpad bug 365615 in bzr "Random 'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository" [Critical,Fix released] https://launchpad.net/bugs/365615
<mwhudson> lifeless: merge, i expect, i don't really know details
<lifeless> mwhudson: who does
<mwhudson> dunno
<mwhudson> lifeless: all i'm going in is failure mails to the launchpad list
<mwhudson> it could be 365615 i guess
<mwhudson> a traceback would be nice...
<fullermd> igc: Nice timing results...
<igc> fullermd: indeed. jam rocks!
<fullermd> 's almost enough to make me wanna see how long importing ports would take...
<fullermd> Though I don't think I'd want my system murdering me in my sleep for doing so.
<igc> (I'm guessing his chk-map tweaks made a huge difference, together with his faster-commit stuff)
<igc> fullermd: for *really* huge imports, there's still plenty of tuning to do I think
<igc> fullermd: but probably in fast-import itself, more than the core
<igc> fullermd: and I'm unlikely to get to tuning fast-import till after 2.0 reaches RC
<fullermd> Yeah.  It'd be pretty huge.  Say around 200k revisions of 200k files.
<fullermd> (well, files and dirs)
<lifeless> fullermd: doit
<lifeless> fullermd: generate a stream and save to disk ; then you can import incrementally or some such
<fullermd> Yeah, the first step would be seeing if I have enough disk space to hold the fast-import stream...
<fullermd> Certainly no time for it this weekend though; it's Field Day.
<fullermd> (and the following few days will be "desperately catch up on sleep", as usual  ;)
<lifeless> whats a field day?
<fullermd> http://www.arrl.org/contests/announcements/fd/
<thumper> lifeless: does the nightly ppa contain the autopack fix yet?
<fullermd> (For some of us, hanging around an IRC channel about a version control tool just ain't nerdy enough, see...)
<lifeless> thumper: I don't know
<thumper> ok
<thumper> lifeless: a pack of an already mostly packed 2a repo is taking quite a while
<thumper> is that expected
<thumper> ?
<thumper> like 10 minutes
<lifeless> thumper: do you have the C extensions?
<thumper> lifeless: it is from the PPA so I think so
<lifeless> thumper: and 'pack' has to recompress all history, so its a slow command to run (which is why you shouldn't ever run it unless you have specific reasons to do so)
<lifeless> thumper: so why were you packing?
<thumper> testing mainly, making my repo smaller, considering how to handle this on a large scale for LP
<lifeless> thumper: bzr will pack as needed
<lifeless> manual packing is generally a bad idea
<Peng_> mwhudson or beuno: ping
<jfroy_> jelmer: I just tried to diff two local branches which are both branches of remote svn branches
<jfroy_> And bzr died with a missing revision / no such revision error
<jfroy_> Is there any way to figure out, perhaps, where that revision is?
<jfroy_> if anywhere
<jfroy_> this is kind of an open question too, I suppose
<jfroy_> wondering if there's a way to search a repository or a branch for a specific revision ID
<lifeless> log -r revid:REVID
<jam> igc: did you change fast-import to use _add_text instead of add_lines at least?
<jfroy_> lifeless: ok I think I am screwed :/
<jfroy_> well maybe
<jfroy_> it's odd
<lifeless> or cat-revision
<jfroy_> that revision shows up in a branch in another repository
<jfroy_> but does not show up in the same branch in another reposityr
<jfroy_> *repository
<jfroy_> it's clearly a bzr-svn bug
<jfroy_> :(
<jfroy_> actually, it looks like that revision was in a local branch I did not push to subversion
<jfroy_> and have since deleted in the local repository
<Peng_> mwhudson & beuno: unping. :)
<mwhudson> Peng_: not-hi
<Peng_> mwhudson: Heh, nice timing.
<igc> jam: not yet - my figures are still with code calling add_lines()
<lifeless> jam: hi
<lifeless> jam: did you get anywhere with the stacking bug overnight?
<jam> lifeless: I did not, other than to not be able to reproduce it locally, but to have the lp branch fail :(
<lifeless> jam: lftp seems to be working again with lpp
<Peng_> mwhudson: FWIW, I unpinged you because I decided to send a merge request.
<lifeless> lp's sftp server, so you can just mirror down the branch
<lifeless> you don't need all of lp
<mwhudson> Peng_: oh ok
<mwhudson> Peng_: ah, cool in principle at least, haven't read the diff yet :)
<Peng_> mwhudson: The diff is the part I'm worried about. :P
<jelmer_> jfroy_: hi
<jelmer_> jfroy_: there's been another report of that as well
<jelmer_> jfroy_: I suspect there's a regression since one of the 0.6 releases
<jfroy_> is there anything at al to be done to salvage that revision?
<jfroy_> I suspect push_merged_revision will help
<jfroy_> since it will push merged revisions, even those of otherwise purely local branches I would not otherwise push myself
<jfroy_> (which I do a lot, scratch branch, private feature branch, merge branches)
<jelmer_> jfroy_: until we've figured out what the bug is about, no idea if push merged revisions will help
<jfroy_> I think it will
<jfroy_> the branch nick on that missing revision if from a branch that was purely local
<jfroy_> I suspect that specific revision never got pushed to svn
<jfroy_> so other people, starting from scratch, will have that revision as a ghost
<jfroy_> push merged revision should avoid that situation
<jfroy_> (purely local and since then deleted)
<jelmer_> if you can confirm that is the case, please let me know
<jelmer_> are you using "bzr branch" or "bzr svn-import" to fetch?
<jfroy_> branch
<RenatoSilva> Is there any documented problems with Novell filesystems?
<lifeless> no
<jelmer_> jfroy_: I need to get some sleep, again, if you find more info please let me know
<jfroy_> will do
<jelmer_> jfroy_: I hope to put some time into bzr-svn again at the end of the week
<jfroy_> np
<jfroy_> it's not a show stopper
<RenatoSilva> I get an error about .bzr/branch/lock/[...].tmp/lock, something like that. I think it may be related to big dir names or so. Stupid Novell anyway.
<mtaylor> lifeless:
<mtaylor> >>> import cpuinfo
<mtaylor> >>> cpuinfo.cpuinfo_processor_count(True)
<mtaylor> 2
<lifeless> mtaylor: cpuinfo.processor_count(True) would be nicer
<lifeless> mtaylor: and for nonstrict mode (which scripts will want,
<lifeless> cpuinfo.processor_count()
<mtaylor> lifeless: indeed
<lifeless> if you can :)
<mtaylor> lifeless: totally
<lifeless> mtaylor: don't you need perl first ?
<mtaylor> lifeless: ew
<lifeless> mtaylor: to be able to use this, I mean?
<lifeless> isn't your test thingy that checks cpu counts perl?
<mtaylor> lifeless: so - do you have any philosophical or other arguments about various ways to build python extension modules in the context of a larger autotools-run project
<mtaylor> lifeless: yeah. I'll add perl in just a sec
<lifeless> mtaylor: personally, I hate setup.py being mixed in with autotools
<thumper> spiv: ping
<lifeless> no point taking one half assed build system and mixing *another* half assed one in with it
<spiv> thumper: pong
<lifeless> mtaylor: but, working >> purity
<thumper> spiv: I have a local lightweight checkout of a 2a branch
<mtaylor> lifeless: k. I go back and forth on that... because I hate mixing the two - but I also hate telling automake all about python :)
<mtaylor> lifeless: working bitshift purity?
<thumper> spiv: bzr info -v tells me it is Branch format 7
 * mtaylor is confused 
<lifeless> mtaylor: working is more important than purity
<thumper> spiv: pushing to LP says: Source branch format does not support stacking, using format:
<thumper>   Branch format 7
<mtaylor> lifeless: yes yes. trolling
<thumper> spiv: what can I do to help diagnose
<spiv> thumper: known bug, lemme get you the number
<spiv> thumper: https://bugs.edge.launchpad.net/bzr/+bug/388908
<lifeless> thumper: its filed as a bug already
<ubottu> Ubuntu bug 388908 in bzr "unnecessary stacking upgrade warning with bzr.dev" [High,Triaged]
<thumper> ok, thanks
<abentley> jam: branch push is complete.
<thumper> spiv: I was wondering if it had something to do with the format 6 remote branch format problems
<lifeless> thumper: what format 6 remote branch problems?
<spiv> thumper: no
 * igc lunch (and afk for a few hours)
<mtaylor> lifeless: it would be great if ruby and perl had something like AM_PATH_PYTHON...
<lifeless> wouldn't it just
<jfroy_> hey, this may be a stupid question, but is there a difference between bzr shelve and looms?
<lifeless> huge
<Peng_> mwhudson: loggerhead/main.py should lose the exec bit, right?
<mwhudson> Peng_: i thought i did that, so yes
<Peng_> mwhudson: Mind if I do it?
<Peng_> mwhudson: Err, yeah, you did do it. I misread the diff. Sorry!
<mwhudson> Peng_: i just did
<mwhudson> gar, didn't mean to commit that :(
 * mwhudson uncommits
<Peng_> Oh yay, one of my 2a branches just committed suicide.
<Peng_> Oh, it was just bzr-search.
<Peng_> ...Which doesn't really make a difference, because I usually bug lifeless about these sorts of things anyway. :P
<Peng_> mwhudson: Hey hey, your revision makes bzr-search explode on 2a. :)
<mwhudson> Peng_: hooray
<mtaylor> lifeless: python. ruby. done.
<mtaylor> lifeless: perl next
<Peng_> Buggy bug filed, FYI -- https://bugs.edge.launchpad.net/bzr-search/+bug/391459
<ubottu> Ubuntu bug 391459 in bzr-search "KeyError in _terms_for_file_terms lambda indexing 2a copy of Loggerhead" [Undecided,New]
<Peng_> "Ubuntu bug"?
<Peng_> mwhudson: I like 'hi', 'ho', 'ha'. :) Today I used 'Hello' but it felt kind of silly and verbose.
<lifeless> Peng_: thanks for the bug; will check later
<Peng_> lifeless: :)
<poolie> spiv, around? want a quick call in a bit?
<bignose> bzr-loom crashes, no matter what I do (Debian bug #532947).
<ubottu> Debian bug 532947 in bzr-loom "bzr-loom: =?utf-8?Q?=E2=80=98loomify?=" [Important,Open] http://bugs.debian.org/532947
<bignose> how can I un-loomify a branch so I can keep working on it?
<poolie> bignose: can you branch individual threads out into separate branches?
<bignose> poolie: using what command? whatever I do it crashes with the message as recorded in that bug report.
<lifeless> bignose: I think its all fixed upstream
<lifeless> bignose: I'm not sure the branch is corrupted; is it possible that you simply have a broken combination of loom + bzr?
<bignose> anything's possible.
<bignose> so how can I get back to a working state for that branch?
<bignose> or, more relevant to today: a branch that has already been working fine with a loom, but is now unreadable as per that bug report?
<lifeless> if it *is* a damaged loom, you might be able to get the thread tip ids out using hexdump on .bzr/branch/current-loom, and use the python api to fetch content from the repo
<bignose> urk.
<wgrant> I'd just try upgrading bzr-loom first, though...
<lifeless> if, as I suspect, you just  have an incompatible loom, get your loom version matching your bzr version, and it should be fine
<bignose> I'll wait for the Debian package to update, then.
<lifeless> jelmer was asking for help on it
<bignose> the "Debian Bazaar maintainers" (listed as the maintainer) have yet to give any response to that bug report, though :-(
<poolie> igc, could you post your "IDE Integration..." message on the project blog?
<bignose> is this related to the discussion on the Bazaar mailing list, about the systemic problem of plug-ins that *need* to be at the same version, but never *say* that in the corresponding OS packages?
<lifeless> bignose: loom tries very hard not to be tied to specific versions
<lifeless> but there have been a few API skews that affected it recently.
<vila> hi all
<lifeless> hai
<igc> hi vila
<vila> hi Ian !
<Peng_> Does bug #390563 waste disk space in non-stacked branches or just bandwidth?
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563
<Peng_> ...S'pose I could check it myself.
<vila> Peng: and tell us if you can reproduce it and how
<Peng_> Oh, right, I forgot that that bug only affects certain branches.
<Peng_> effects? eh
<fullermd> Affects.
<fullermd> Well, the bug may effect certain branches too, but that would be a really weird bug   :p
<Peng_> Someday, I should learn the difference between those two words.
<Peng_> Then I should verify "then" and "than". :P
<fullermd> Generally, affect is a verb and effect is a noun.
<Peng_> (OK, I just said that one for the punny thing.)
 * Peng_ is obviously a linguistic master. :P
<fullermd> Oh, you can sort them out.  Their knot that hard.
<mwhudson> fullermd: you're a bad man
<Peng_> mwhudson: Shouldn't that be "your a bad man"?
<fullermd> Hey, the proof is in the pudding, just take a different tact.
<Lo-lan-do> Hi all
<Lo-lan-do> What's the status of the HistoryHorizon feature currently?
<Lo-lan-do> (The use case I'm looking for is the "Old huge project" mentioned on http://bazaar-vcs.org/HistoryHorizon)
<Lo-lan-do> Is it fulfilled by stacked branches?
<Peng_> Lo-lan-do: They're not the same thing, but stacked branches let you store the repository on the server, similar to a lightweight checkout, only you've got a real branch.
<lifeless> Lo-lan-do: we have decent performance and excellent compression even for huge old projects, in the 2a format.
<Peng_> Users will just move the goalposts by making even huger projects. :P
<Lo-lan-do> lifeless: Huge as in?
<Lo-lan-do> I'm talking about a 16G CVS repo here.
<Peng_> lifeless: Do you sleep?
<Lo-lan-do> We need to do some cleanup in there, and it'll be smaller with bzr, but still, if the main repo could be limited in history that would certainly help.
<Lo-lan-do> Could the main repo be stacked on a historical one, thus making day-to-day operations fast while keeping history?
<Peng_> Lo-lan-do: What do you mean? Like, have a stacked branch pointing to another one on the same machine?
<Lo-lan-do> I'm very glad to hear about 2a, too.  Do you think it'll be stable before the end of the year?
<Lo-lan-do> Peng_: Yes.  So daily commits only add to the smaller "current" repo.
<Lo-lan-do> But maybe 2a entirely removes the benefits of such an approach, in which case I'll happily recommend that.
<asabil> hi all
<asabil> is there a way to setup a configuration (bugtracker settings) that will be propagated during a bzr branch to all users ?
<Peng_> Lo-lan-do: Having a larger repo isn't a problem. Stacking that would be pointless.
<lifeless> Peng_: theory has that I do
<Lo-lan-do> Having to replicate a large repo with file transfers could cause problems.
<lifeless> Lo-lan-do: that could be massively smaller - perhaps even 1GB total, in 2a
<Peng_> Lo-lan-do: Actually...a smaller repo would probably save a few ms here and there, but stacking would also cost a few ms here and there. :D
<Peng_> Lo-lan-do: If the users do "bzr branch --stacked", they won't have to replace the entire thing.
<Lo-lan-do> I fear that smart repo formats wouldn't be very good at rsyncing (but maybe I'm completely wrong)
<lifeless> Peng_: but its only EOD, not time-to-sleep now
<Peng_> Err, replicate*
<Peng_> lifeless: Ah.
<lifeless> Lo-lan-do: all our formats since pack-0.92 rsync very well
<Peng_> lifeless: Except when they get packed...
<lifeless> Lo-lan-do: old data is rarely moved on disk, so it rarely shows up
<lifeless> Lo-lan-do: as long as noone runs 'bzr pack', which they shouldn't.
<Lo-lan-do> Good to know.
<Lo-lan-do> I guess bzr pack could be run monthly or so, if it's useful at all.
<lifeless> I wouldn't even do that
<lifeless> bzr incrementally packs as commits and pushes occur.
<Lo-lan-do> More and more excellent.
<lifeless> every power of 10 commits it does a full pack automatically
<lifeless> so if you have 1M commits today, you'd need another 9 million to need another full pack ;)
<Peng_> Running "bzr pack" occasionally *would* buy you a teensy bit of performance, but it's not enough to matter. Autopacking keeps things from getting out of hand.
<lifeless> Peng_: actually, full packing when its not needed, with pack ordering, can decrease performance :)
<lifeless> Peng_: (for a central repo thats only push/pulled with)
<Peng_> lifeless: Oh? Why? I don't get it.
<Peng_> Also, Firefox crashed. Arrgh.
<Lo-lan-do> How do the new repo formats cope with thousands of branches?
<lifeless> Peng_: by creating a single large btree that has to be read rather than a smaller one with the most recent data and a larger one that isn't read at all
<Peng_> lifeless: Ahh.
<lifeless> you'd need fairly extreme repos for this to show up
<lifeless> as we get a 200:1 fanout in our indices today
<lifeless> Lo-lan-do: should be fine; there isn't a single file listing all the branches or anything, so its much of a muchness
<Lo-lan-do> Good.
<Lo-lan-do> Last two questions: timeframe for format 2a being officially stable?  And possibility for repo-side hooks?
<Peng_> Repositories don't really know about branches. They're just big bags of revisions.
<Lo-lan-do> (The hooks can be done without, they use incron for now)
<Lo-lan-do> (they=my current client)
<Peng_> Well, I guess it could matter if you had a complicated history and bzr was bad at choosing compression parents, but it's not.
<lifeless> Lo-lan-do: 2a is supported now; however you need https://bugs.edge.launchpad.net/bzr/1.16/+bug/365615 - we're still polishing the code around the format.
<ubottu> Ubuntu bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed]
<lifeless> Lo-lan-do: we'll be doing a 1.16.1 with that hotfix and possibly a couple of others (to do with stacking on 2a formats)
<Lo-lan-do> I'm not in much of a hurry, they'll need time to think about it anyway.
<Lo-lan-do> My current job is to find quickfixes to make the CVS repo a bit more usable than it currently is.
<Lo-lan-do> ...and to provide recommendations for the longer term.
<Lo-lan-do> I'm pretty sure bzr will be in that part :-)
<lifeless> awesome
<Peng_> Stupid question: how large is MySQL's repo?
<Lo-lan-do> A bzr branch uses 600 MB (with working-tree)
<mwhudson> Peng_: ~600 megs or so
<Lo-lan-do> The .bzr is 467MB here
<lifeless> Lo-lan-do: of mysql?
<lifeless> Lo-lan-do: it shrinks by about 2/3rds going to 2a
<Lo-lan-do> (Branched from lp:mysql-server sometime this week)
<Lo-lan-do> format: unnamed, bzr 1.11
<lifeless> info -v will show you the actual repo format
<Peng_> In 1.11, it'll probably also spend a long time churning through the history, but you can Ctrl+C it.
<Lo-lan-do> packs 6
<Lo-lan-do> This 2/3 number is awesomely impressive.
<Lo-lan-do> Sorry, crashed.  You were saying?
<lifeless> nothing ;)
<lifeless> 19:42 < Lo-lan-do> packs 6
<lifeless> 19:43 < Lo-lan-do> This 2/3 number is awesomely impressive.
<lifeless> 19:46 -!- Lo-lan-do [n=roland@193.252.149.222] has quit [Read error: 104 (Connection reset by peer)]
<lifeless> 19:48 -!- Lo-lan-do [n=roland@193.252.149.222] has joined #bzr
<Lo-lan-do> Cool.
<Lo-lan-do> Anyway, will you be available for a beer at Debconf? :-)
<Lo-lan-do> I think I owe a couple to jelmer too.
<lifeless> I won't be at debconf
<lifeless> sorry :(
<Kinnison> You won't? Boo hiss :-(
<Lo-lan-do> RMLL in Nantes maybe?
<lifeless> Kinnison: where is it this year ?
<Lo-lan-do> Western Spain
<Kinnison> CacÃ©res, Spain
<lifeless> yah. Wrong side of the world
<Kinnison> About four hours west of Madrid
<lifeless> when things line up, its awesome to get to such things
<lifeless> but as it stands, its awfully hard to get there, and I've used all my conference leave this year already.
<Kinnison> fair enough
<Lo-lan-do> My plan is to develop the bzr plugin for fusionforge during debcamp/debconf
<Kinnison> Lo-lan-do: coo. sounds amusing.
<Lo-lan-do> (And git, and hg, and whatever VCS out there if there's a guru around to tell me what needs to be done for his preferred one)
<Lo-lan-do> I'll probably implement a cpold plugin too, if only as a proof of concept after my refactoring.
<Kinnison> lifeless: any plans for a UDS in the UK any time soon?
<Peng_> cpold?
<lifeless> next is US I think; beyond that no idea
<Lo-lan-do> Peng: The oldest VCS of them all.
<Lo-lan-do> Peng: "cp foo.c foo.c.old"
<Peng_> Lo-lan-do: Oh. I use that one a lot!
<Lo-lan-do> There you are :-)
<Lo-lan-do> I'm wondering if I'll have the nerve to actually upload a gforge-plugin-scmcpold to Debian :-)
<Lo-lan-do> Anyway, food calls.  Thanks for your answers!
<Peng_> Lo-lan-do: See you later! :)
<Peng_> Hmm, food. Good idea.
<awilkins_> Is bzr 2 getting copy of files in inventories?
<gioele> hello
<lifeless> awilkins: no
<awilkins> I suppose it would be yet another awkward format hump to drive over
<awilkins> It's nice to see that not-rich-root is deprecated for 2a
<gioele> do stacked branches require the master branch to support the staking in some way? Or this feature can be used with any published branch, regardless of its format?
<lifeless> the formats must match
<lifeless> and bzr won't honour default-stacking requests with very old branches because that would potentially leave the trunk unable to merge from feature branches
<gioele> lifeless: anyway, is it possible to use stacking with lp:bzr?
<lifeless> yes, and bzr should do that by default
<gioele> lifeless: that = stacking? if I do a bzr clone lp:bzr I end up with a stacked branch?
<lifeless> no
<lifeless> and doing that isn't very useful or sensible anyway
<lifeless> (stacking your local copy on the network version
<lifeless> )
<lifeless> if you do a bzr push lp:~gioele/bzr/foo, it will stack on lp;bzr automatically
<gioele> lifeless: but then the remote branch is stacked, not the branch on my PC, if I understood that correctly
<lifeless> right, but its not useful to stack branches on your pc
<lifeless> a stacked branch doesn't have enough data in it to even create a working tree
<gioele> I see
<gioele> thank you for the explaination
<ddaa> Hello.
<ddaa> I have a collaborator, who is using Windows to write to some files in a linux-based bzr tree over the network (presumably SMB)
<ddaa> This appears to cause the executable bit to turn on on every file he edits from the network. Which is kind of annoying to me.
<ddaa> Is there a way to edit files in a linux bzr tree from windows over SMB that will not cause those files to be recorded as executable when committing from linux.
<ddaa> Note that I do not really care about whether the becomes executable on the linux filesystem. I just do not want bzr to record a permission change.
<matkor> Hi ! what is easiest way to apply changes (uncommited) from given branch to current one ?
<Lo-lan-do> bzr merge --uncommitted $given
<ddaa> bialix: Can I make my collaborator use the bzr-x-bit plugin on linux to solve this problem?
<bialix> ddaa: no
<matkor> Lo-lan-do: Looks great, thank you very much !
<Lo-lan-do> matkor: Then you'll probably do "cd $given ; bzr revert" or so
<bialix> x-bit plugin does reverse thing
<Lo-lan-do> (Be sure to only do that afterwards)
<ddaa> bialix: doh, any idea?
<bialix> SMB settings maybe? I'm not Linux expert
<ddaa> I know, but you're the expert of all things windowish around.
<bialix> IIUC this is always problem: try to open USB flash disk on Linux and all files have x-bit set
<bialix> ddaa: IIUC your situation: your collaborator working directly with files over the network?
<bialix> so why he does not have separate tree on his local disk?
<bialix> e.g. lightweight checkout
<ddaa> Yup. As I said, I do not care much what the filesystem says, I just do not want this nonsense to contaminate my carefuly tended bzr branch.
<bialix> lightweight checkout will help you
<ddaa> bialix: out of convenience, he's editing, over SMB, files that are used by a live web server on linux.
 * bialix out of ideas
<bialix> I'm usually working via ssh in those cases
<ddaa> I do not want to worry about running the web server on windows, but I would like him to be able to retain the convenience of editing files on his big-screen windows system while he's testing IE compatibility.
 * ddaa contemplates how all evil in computing those days can be ultimately traced to Internet Explorer.
<bialix> and Bill G. of course!
<ddaa> I do not like to take things personally. It's fine to hate pieces of technologies, but not people.
<matkor> Lo-lan-do: Sure, I will even commit first on current :)
<bialix> as you wish, I've tried to make joke
<ddaa> bialix: sorry :) I'm just annoyed about how it became fashionable to hate B. Gates and Microsoft over the past few years.
<ddaa> I mean, they actually invented a few good things.
<ddaa> Like the scroll wheel.
<ddaa> Thinking of it... Microsoft is actually pretty good at making mice, keyboards and joysticks...
<LeoNerd> MS mice are quite nice, yeah..
<LeoNerd> Probably because Logitec make them?
<garyvdm> When Bug 1 gets fixed people will be replace those with Mark S. and Canonical :-P
<ddaa> LeoNerd: that might have something to do with it :)
 * garyvdm ducks and runs
<ddaa> garyvdm: a few people already have.
<garyvdm> Is ubottu asleep/
<garyvdm> bug 00001
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<ddaa> Not ubottu, but most of the time this page times out.
<ddaa> something to do with insanely large amount of comments, dups, subscribers and so on and so forth.
<fbond> Hi.  In the old bzr shelve, I could `bzr shelf show FOO`, I think, to see a diff representing that particular change on the shelf.  Can I do that with the new shelve/unshelve commands?
<fbond> `bzr unshelve --dry-run` shows me a stat-like representation of the change, but not a diff.
<garyvdm> bug 391471
<garyvdm> bug #391471
<ubottu> Launchpad bug 391471 in tortoisebzr "Inconsistent Diff behavior" [Undecided,New] https://launchpad.net/bugs/391471
<garyvdm> https://bugs.launchpad.net/ubuntu/+bug/1
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/1/+text)
<fbond> garyvdm: That bug has a lot of comments.
<garyvdm> lol
<garyvdm> oops - I've now cause to to try 3 times...
<garyvdm> *caused it
<ddaa> Okay it turns out there should be two ways of fixing it.
<ddaa> 1. setting the "create mask" in smb.conf to something like "644", so files are not create executable
<ddaa> 2. configuring the windows-side editor to save files in place (instead of doing the copy-rename thing).
<asabil> jelmer: ping ?
<jelmer> asabil: pong
<asabil> jelmer: did you receive my filter-branch merge request for bzr-rebase ?
<jelmer> asabil: no, I didn't see anything
<asabil> jelmer: I did send it a while ago, maybe I should resend it ?
<jelmer> asabil: please do
<Lo-lan-do> Are pack files often modified?
<Lo-lan-do> Or are they only generated once by a commit or a repack and not changed afterwards?
<Lo-lan-do> I'm pondering about risks of filesystem fragmentation.
<jelmer> Lo-lan-do: pack files are not modified themselves, but new pack files will be created regularly
<jelmer> (e.g. by commit, repack, push/pull etc)
<Lo-lan-do> Okay, so little risk for fragmentation increasing over time.  Good, good.
<mxpxpod> jelmer: ping?
<jelmer> mxpxpod: pong
<mxpxpod> jelmer: I'm trying to mirror dojotoolkit.org's svn repository using bzr-svn's svn-import, but we have a strange branching and tagging method
<mxpxpod> basically, each project (dojo, dijit, dojox) has it's own sub-repository (src/dojox/{branches,tags,trunk})
<mxpxpod> but then when we release, we create a structure in src/branches/{release_version} that copies current trunk of each project into that directory
<mxpxpod> same with tagging with the tags directory
<mxpxpod> jelmer: if you want to take a look, it's at http://svn.dojotoolkit.org/src
<abentley> jam: In case you missed it earlier, the push to /home/abentley/branches is complete
<mxpxpod> jelmer: src/trunk is our old code-base
<mxpxpod> jelmer: the problem is that when I did the svn-import, I specified branches=branches/*;*/branches/*;*/trunk and tags=tags/*;*/tags/*, but no tags showed up
<mxpxpod> jelmer: am I going to have to tag things manually?
<jelmer> mxpxpod: sorry, phone, back in a few minutes
<asabil> jelmer: just sent it, you should receive it on your samba mailbox
<jam> abentley: thanks
<jam> robert says you can lftp the broken branch
<jam> which works well, too
<abentley> jam: was the lftp message for me?
<jam> yes
<jam> not that *you* need to
<jam> just that it is another branch I can use
<abentley> jam: I don't understand.  by "broken branch", you mean db-devel?
<jam> cinnamon-and-spice, IIRC
<jam> abentley: sorry, crimson-and-clover
<abentley> jam: Oh, you'd like a copy of lp:~sinzui/launchpad/crimson-and-clover ?
<abentley> jam: I've mirrored crimson-and-clover for you at /home/abentley/crimson-and-clover
<mxpxpod> is there a way to register a directory service and have it create a shared repo for multiple branches for certain urls?
<asabil> jelmer: did you get it this time ?
<jelmer> asabil: yep, thanks
<asabil> cool
<jelmer> mxpxpod: re
<jelmer> mxpxpod: that should've worked
<jelmer> mxpxpod: did svn-import say anything about the layout being used?
<mxpxpod> jelmer: Using repository layout: WildcardLayout(['branches/*', '*/branches/*', '*/trunk'],['tags/*', '*/tags/*'])
 * awilkins thinks bzr-svn should have a layout option for "total freakin' mess"
<mxpxpod> awilkins: :)
<mxpxpod> jelmer: I think the problem is that we have src/tags/release-1.3.1/dojo
<kirkland> jelmer: hi there
<mxpxpod> and dojo resides in src/dojo/{trunk,branches}
<kirkland> jelmer: i'm still getting a vcs import update failure for qemu's git
<kirkland> jelmer: i was under the impression that LP's rollout this morning had your latest fixes?
<kirkland> jelmer: http://launchpadlibrarian.net/28287607/qemu-git-log.txt
<kirkland> jelmer: https://code.edge.launchpad.net/~vcs-imports/qemu/git
<jelmer> kirkland: I'm not sure what version of bzr-git launchpad is using
<kirkland> jelmer: is there any way that I can run this script/process locally, on my hardware
<kirkland> jelmer: and push to a bzr branch in LP?
<kirkland> jelmer: i'm happy to cut vcs-imports out of the loop, until they get that fixed
<kirkland> jelmer: i need a bzr/git mirror up ASAP
<jelmer> kirkland: yeah, just install bzr-git and run something like this from a cronjob:
<kirkland> jelmer: what's bzr-git?  a bzr pluggin?
<Jc2k> yes
<jelmer> kirkland: "bzr svn-import git://git.savannah.nongnu.org/qemu.git qemu; bzr push -d qemu lp:~kirkland/qemu/git-import"
<jelmer> sorry, git-import rather than svn-import obviously
<kirkland> jelmer: s/svn-import/git-import/
<kirkland> k
<kirkland> jelmer: thanks
<jelmer> kirkland: alternatively if you just need the main branch you can just use "bzr branch" / "bzr pull" with git URLs
<mxpxpod> jelmer: I'm figuring for this strange layout that we have that I'll have to do some sort of custom import for this repo
<kirkland> jelmer: and getting git-import ....
<kirkland> jelmer: cd .bazaar/plugins; bzr branch lp:bzr-git ?
<jelmer> kirkland: yep
<jelmer> kirkland: you'll also need dulwich, which is a dependency of bzr-git
<jelmer> mxpxpod: there don't seem to be any actual tags for dojo that bzr-svn could import
<jelmer> mxpxpod: http://svn.dojotoolkit.org/src/dojo/tags/ is empty
<kirkland> Unable to load plugin 'git'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 13, 0), and the maximum is (1, 13, 1)
<mxpxpod> jelmer: yeah, we tag dojo, dijit, dojox, and util at src/tags/{release_name}/{project_name}
<jelmer> kirkland: the version of bzr you have locally is too old, you need at least 1.14 for bzr-git
<kirkland> jelmer: best way of getting a newer bzr onto a jaunty machine?  a ppa, perhaps?
<jelmer> kirkland: yeah, there's a bzr ppa (~bzr on lp)
<kirkland> jelmer: cheers, thanks for your help, dude
<mxpxpod> kirkland: https://launchpad.net/~bzr/+archive/ppa
<jelmer> mxpxpod: so in that case it seems your tags setting is incomplete
<mxpxpod> jelmer: right, but how do I tell svn-import that the tag is at tags/release-1.3.1/dojo rather than dojo/tags/release-1.3.1 ?
<mxpxpod> and then how do I get it to translate the former to the latter for the conversion?
<jelmer> mxpxpod: try tags/*/dojo
<mxpxpod> jelmer: what if I'm importing the whole repo at one time?
<jelmer> mxpxpod: shouldn't be any different
<mxpxpod> jelmer: so, just put tags/*/{project_name} for each project?
<jelmer> mxpxpod: yeah, that's how it's intended to work at least
<mxpxpod> jelmer: same with branches?
<jelmer> mxpxpod: yeah
<mxpxpod> jelmer: welp, here goes nothing ;)
<marianom> hi guys, can anyone tell me why I'm hitting this error? bzr: ERROR: Reserved revision-id {null:}
<marianom> First time I see it
<mxpxpod> jelmer: that didn't work :(
<mxpxpod> jelmer: I did this: bzr init-repo --1.14-rich-root test; cd test; bzr svn-import http://svn.dojotoolkit.org/src .
<kirkland> jelmer: http://pastebin.ubuntu.com/203025/
<kirkland> jelmer: dulwich is installed
<kirkland> never mind
<kirkland> bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required
<kirkland> i installed dulwich from the ppa
<jelmer> kirkland: I don't think there's a current dulwich packaged in the ppa
<kirkland> jelmer: okay, thanks.
<jh> hi, I'm trying to get to the newest revsion of a branch on launchpad. I had already a local copy of the repository and changed some things (and committed it locally). how can I change to the current remote revision? ignoring all my local changes
<dash> you want to remove your local changes?
<dash> or merge the remote ones into your local branch
<jh> I want to ignore my local changes
<dash> bzr pull --overwrite <remote url>
<dash> if by 'ignore' you mean 'remove'
<jh> y
<jh> thx!
<ddaa> There's something annoying about shelve storing a pack in the shelf instead of a diff.
<dash> yes
<ddaa> Previously, I could go into the shelf, and modify the shelved diff.
<dash> also the shelve plugin has more features than the builtin
<ddaa> In this instance, I want to split a diff hunk.
<dash> me too
 * ddaa shakes dash's hand
<ddaa> dash: so what is it you do you to satisfy you obsessive-compulsive need for clean commits?
<dash> (I am trying to split up a very large diff into multiple unrelated ones via loom+shelve)
<dash> ddaa: Nothing easy.
<ddaa> that kind of sucks
<dash> yes
<dash> i think i am going to switch back to shelve1
<ddaa> you mentioned a different between a plugin and a builtin
<dash> yes, the 'shelve' in bzrtools is different
<ddaa> I did not realize shelve was now a builtin
<dash> so yeah, try 'bzr shelve1'
<ddaa> Yay, happiness.
<ddaa> bzr shelve1, manual diff editing, bzr unshelve1
<ddaa> dash: thanks pal
<dash> <3
<mwhudson> jelmer_: hello, https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne still seems to be failing with bzr 0.4.0, i can't remember if i asked you about this one already :)
<mwhudson> bzr-git, obv
<poolie> hello
 * beuno waves at poolie 
<poolie> good morning beuno
<beuno> how are you poolie?
<poolie> good thanks
<poolie> woke up a bit too early though
<poolie> how are you?
<beuno> pretty good
<beuno> slow day for me today
<poolie> how is 2a dogfooding going for you?
<poolie> i realize bug 390563 is a big deal
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563
<beuno> poolie, that's really making things chaotic
<beuno> but, apart from that, things seem much faster
<beuno> I've upgraded about 30 branches at the office to 2a
<beuno> and it's gone well
<beuno> no problemas at all
<beuno> something to note is that at least half the branches didn't go down in size from 1.9
<poolie> ok, interestig
<poolie> how about if you repack them?
<beuno> I do, all of them
<beuno> initially the branches are larger
<beuno> and then they go down to about the same size after a pack
<beuno> they are branches with heavy binary usage
<lifeless> oh wow
<lifeless> did all codeimports die overnight?
<lifeless> mwhudson: ^
<mwhudson> lifeless: no
<thumper> lifeless: no, we've just now automatically failing imports that have failed lots
<mwhudson> oh yes, that's a lot of spam in my codeimport folder...
<lifeless> vila: still around?
<poolie> hello mwhudson, lifeless
<mwhudson> hi poolie
<lifeless> mwhudson: you're going to cherrypick bug 365615 today, yes?
<ubottu> Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615
<mwhudson> yeah, we should
<mwhudson> lifeless: it won't hit prod until uk versions of 'today' of course
<mwhudson> lifeless: is there any sense in waiting for a fix to the other absentcontentfactory bug to maybe appear?
<mwhudson> lifeless: also, is the fix for that bug in the 1.16 branch?
<mwhudson> seems no
<mwhudson> i guess i should talk to the 1.16 release manager
<mwhudson> who should be waking up around about now...
<lifeless> mwhudson: its not in the 1.16 branch yet
<lifeless> mwhudson: just cherry pick
<lifeless> and no, no sense waiting
<poolie> lifeless: did you talk to jam today (au time)?
<poolie> i was just going to call him and say hello
<lifeless> poolie: no; I'd like to to pickup the state on the bug
<lifeless> he commented about 7 hours ago on the bug, but hasn't mailed a status note, nor has vila
<lifeless> so AFAICT it hasn't advanced any
<lifeless> which may just mean that a lot of work hasn't ruled anything out nor proven anything
<lifeless> poolie: I'll be on m mobile; just grabbing a hot brekkie
<poolie> lifeless: john's sending an update now
<FibeRichio> Hi, I wanted to exclude a directory called 'webstats' from the revision, so I did 'bzr ignore ./webstats'. It told me that there already existed a directory in the revision and that I should use the remove command, but after I did 'bzr remove webstats', the entire directory dissappeared from my filesystem?
<lifeless> back
<lifeless> poolie: thanks
<lifeless> FibeRichio: right, it did that because it was versioned
<lifeless> FibeRichio: do this:
<lifeless> bzr revert webstats
<lifeless> bzr remove --keep webstats
<FibeRichio> thanks, that looks bettter :)
<lifeless> np
<rocky> jelmer_: hey, does deleting tags not work with bzr-svn ?
<poolie> jam, lifeless,  i filed bug 391851
<ubottu> Launchpad bug 391851 in bzr "groupcompress holds a compressed full text for each file in each group" [Medium,Confirmed] https://launchpad.net/bugs/391851
<poolie> jml that's what you mentioned last night
<lifeless> oh that reminds me
<poolie> i don't think there was a bug for it previously
<lifeless> I'll file one on skinny networkin
<lifeless> g
<poolie> ok, refer back to this one
<poolie> i mean put in a see also
<lifeless> Actually
<lifeless> I think yours really should just be turned into 'skinny on the network please'
<lifeless> as the other aspects were all considered and balanced during design.
<lifeless> single commit having a full text isn't a drawback, as it makes commit fast; and group size is dynamically tuned based on file size
<lifeless> poolie: ok if I repurpose it? or should I close it and file a targeted one for networking?
<poolie> either is ok
<poolie> i'd like the other one perhaps open at least at low priority
<poolie> so it has a handle
<lifeless> poolie: I'm not clear what it is meant to be though - I don't see anything in 391851 as a bug or defect, other than networking not being skinny
<lifeless> poolie: quick call?
#bzr 2009-06-25
<thumper> james_w: ping
<james_w> hi hi
<lifeless> meep
<lifeless> something very odd:
<jam> lifeless: I just set you an update about iter_interesting... did it make sense?
<lifeless> g$ bzr info lp:~mordred/libcpuinfo/add-bindings
<lifeless> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "lp-49592784:///~mordred/libcpuinfo/add-bindings"')
<lifeless> but merging from http://b.l.n. works
<lifeless> if someone could reproduce that would be great
<jam> lifeless: 'bzr info lp:...' works here
<jam> I do see:
<jam>   public branch: http://bazaar.launchpad.net/%7Emordred/libcpuinfo/add-bindings
<jam>   parent branch: lp-hosted:///%7Elibcpuinfo-developers/libcpuinfo/trunk/
<jam>      stacked on: /~libcpuinfo-developers/libcpuinfo/trunk
<jam> the 'lp-hosted' specifically looks weird
<lifeless> jam: its plausible
<lifeless> jam: the parent branch won't be followed though
<lifeless> jam: are you lp-login'd?
<jam> lifeless: yes
<lifeless> [its plausible] - the iter_interesting
<jam> lifeless: I figured
<Peng_> I just tried "bzr info" over lp: (logged in). I mostly concur with jam, except I saw a shared repo line, not a public branch line.
<lifeless> yes, interesting things cannot be in *any* uninsteresting page
<jam> lifeless: "bzr info http://b.l.n" works, too
<lifeless> http:// works for me
<mwhudson> i see the same as lifeless
<lifeless> mwhudson: great.
<mwhudson> i bet the difference here is that lifeless and i have branch super powers
<mwhudson> and are seeing the hosted area
<lifeless> https://code.edge.launchpad.net/~mordred/libcpuinfo/add-bindings
<lifeless> it looks like it is a hosted branch
<mwhudson> and well
<mwhudson> there's no repository there
<mwhudson> lifeless: https://pastebin.canonical.com/18971/
<lifeless> ?!
<lifeless> I'll ask monty when he returns
<jam> mwhudson: so you're saying that it didn't mirror the broken repo to the public side
<jam> and thus non-super people like me and Peng see everything as ok
<mwhudson> jam: i am not intepreting anything!
<mwhudson> jam: but yes, that seems likely
<mwhudson> there's probably an oops from the puller somewhere
<jam> lifeless: could be in the middle of an upgrade?
<lifeless> he asked me to look at it; I don't think he'd have done that just before starting an upgrade
<jam> lifeless: unless he was asking you why it was broken :)
<poolie> jam, want to resume?
<jam> poolie: yes, though my wife is away, so I'm watching my son
<lifeless> jam: no, he asked me to review it
<jam> phone would probably work better
<igc> morning
<lifeless> jam: so, let me know when you're stopping working on the bug and I'll pick up from there
<jam> lifeless: I'm done
<lifeless> kk
<jelmer> rocky: that's not specific to bzr-svn, deleting tags doesn't propagate inside of bzr in general
<rocky> jelmer: so there's no way to delete a tag?
<jelmer> rocky: push --overwrite might delete a tag
<jelmer> IIRC
<Peng_> Yeah, I think so.
<mwhudson> damn loggerhead's way of making you fix a bunch of bugs at once!
<lifeless> because it has so many?
<mwhudson> yes
<mwhudson> still, it's only 250 lines
<mwhudson> Peng_: want to review a branch? :)
<Peng_> mwhudson: Sure.
<Peng_> mwhudson: I'll probably wind up saying "it seems ok to me, but you should really ask beuno", though. :P
<mwhudson> yeah
<Peng_> mwhudson: no-transport-sharing?
<Peng_> mwhudson: I think you have the logic backwards in check_serveable.
<mwhudson> Peng_: yeah
<mwhudson> oh yes
<mwhudson> writing up a merge proposal now
<Peng_> If a thread exits, will its threading.local stuff automatically get cleaned up?
<mwhudson> not sure
<mwhudson> probably not
<Peng_> Leaking a transport every 100 requests (by default) wouldn't be very nice/
<lifeless> uhm
<lifeless> I'd expect threading.local to get dereferenced
<lifeless> otherwise its a huge bug in python :)
<Peng_> Haha.
<lifeless> check the module source if you need to
<Peng_> I did once. I wasn't curious enough at the time to try to understand it. :P
<Peng_> And I only checked the Python version, not the C version that actually gets used on most platforms.
<lifeless> so there is a wrapper around each thread
<lifeless> I'd expect the wrapper to have a list of threading.local instances, and tell them all at thread exit
<Peng_> _threading_local.py uses attributes on threading.current_thread() to store the thread-local data, so it'd probably be okay?
<mwhudson> the data is stored in the threadstate it seems
<mwhudson> so it will die with the thread
<mwhudson> (in the c implementation)
<Peng_> Wait, what broke HTTP serving was the stupid readonly+ decorator? Ouch.
<mwhudson> Peng_: yes
<mwhudson> Peng_: hey, you know what are really really great?
<Peng_> Cupcakes!
<mwhudson> i was going to say tests, but you're also right
<mwhudson> i guess docstrings are nice too
<Peng_> What's even better are interns to get you cupcakes, docstrings and unit tests.
<jml> I would like a cupcake.
<lifeless> Peng_: I did suggest not doing readonly+ :P
<Peng_> lifeless: :(
<lifeless> Peng_: actually no. I suggested not requiring it :)
<mwhudson> Peng_: LocationConfig doesn't open a transport afaict
<mwhudson> it looks up locations by url in the ~/.bazaar/locations.conf file
<Peng_> mwhudson: Oh, OK.
<Peng_> mwhudson: ...If locations.conf is broken, will it explode, and do we care?
<mwhudson> Peng_: so will everything else though?
<mwhudson> i'm not sure i care very much
<Peng_> Heh, probably. I'm OK with that, then. :)
<mwhudson> uh
<mwhudson> the date on this launchpad bugmail is highly unbelievable
<mwhudson> (i.e. it's in the future)
<Peng_> Oh? Which one?
<mwhudson> Peng_: when you assigned the 'serve over http is broken' to me
<Peng_> I got "Date: Thu, 25 Jun 2009 01:36:37 -0000", which is correct.
<mwhudson> Date: Thu, 25 Jun 2009 02:36:38 -0000
<Peng_> Wow.
<RenatoSilva> Is BzrEclipse compatible with Eclipse Galileo?
<Peng_> Hello, Daylight Saving Time. Meet Launchpad.
<mwhudson> Peng_: i'm a little bit scared as to how this is possible :)
<mwhudson> Peng_: which machine was yours sent from?
<Peng_> mwhudson: If you're receiving bugmail from the future, you could file bugs before people get the chance to and steal the credit!
<mwhudson> mine was 'potassium' it seems
<Peng_> From what, the Recieved headers?
<Peng_> loganberry -> adelie (IIRC) -> my mail server.
<Peng_> Notably, both were BST (GMT+1)
<mwhudson> ok, mine was a very different path
<mwhudson> which is good, i guess
<Peng_> Might've been Adelaide or something. I can't remember, and my mail client is swapping.
<Peng_> Oh, adelie.
<Peng_> mwhudson: Oh, the message-id is indeed potassium.
<mwhudson> <20090625013638.19816.53674.launchpad@potassium.ubuntu.com> ?
<mwhudson> i guess the launchpad user's TZ is set wrong on that machine or something
<Peng_> Message-Id: <20090625013638.19816.85527.launchpad@potassium.ubuntu.com>
<mwhudson> huh
<mwhudson> i have no idea how this code works :)
 * mwhudson emails the sysadmins
 * Peng_ brushes his teeth.
<Peng_> brb
<lifeless> abentley: is there a bug open for the fetch errors you're experiencing?
<abentley> lifeless: I don't know.
<abentley> lifeless: You know that this was discussed in the canonical-bazaar thread "Ongoing problems with inconsistent revisions in Launchpad trunk", right?
<Peng_> "canonical-bazaar"?
<abentley> Peng: The canonical employees' list for discussions related to bazaar.
 * Peng_ feels left out. :P
<abentley> Peng_: It doesn't get a lot of traffic.
<fullermd> Peng_: Why?  Obviously being on the list makes you have problems   ;)
<Peng_> Heh.
<abentley> fullermd: No, only people with problems are allowed on the list :-)
 * fullermd quickly hides his invitation.
<lifeless> abentley: I've re-read the thread; it didn't seem to talk about the proposed solution
<lifeless> abentley: I agree that this is an important thing to correct
<abentley> lifeless: Yeah, it mostly covers the investigation of the situation.  I thought that was what you were looking for.
<lifeless> abentley: I want a backtrace I think; I want to make reconcile faster, but I need to make sure it will still catch these bits of data
<lifeless> the new KnownGraph thing may be an easy-grasp item to make reconcile _much_ faster.
<abentley> lifeless: backtrace is in the first message.
<lifeless> abentley: ah cool.
<lifeless> I'll turn it into a bug
<abentley> lifeless: My problem repository is at devpad:/home/abentley/branches
<poolie> lifeless: see you soon
<lifeless> yeehaw
<jml> spiv, I want to hook into the smart server so that I logged an OOPS on unexpected errors
<jml> spiv, where's the best place to hook in?
<jml> at the moment, I'm considering monkeypatching log_exception_quitely
<jml> quietly.
<ree> hi All! I pushed a branch to a different location (on launchpad) and it became stacked for some reason. Is there any way to make it non-stacked? I would not like it to depend on the old location
<ree> I find no --nostacked option.... how is stacking prohibited?
<lifeless> ree: there isn't a command line way to do it at the moment
<lifeless> ree: I don't understand the issue though?
<ree> ok, so is it a problem if it's stacked? The launchpad ui says it's stacked on the old location. What if the old location is removed? I would like to keep the new branch location independent from the old one
<ree> lifeless, ^
<lifeless> ree: well, lp won't let you remove the series branch
<lifeless> ree: as its used by other branches to stack on - not just branches of your own; anyone pushing to that project
<ree> the trunk was under my own username, and I want to move it to under a group, so I can share access
<ree> I thought in bzr the full branch history is stored in every repo... now this seems to be not like this with stacking. I also would like to find the way in general, to make a repo unstacked
<ree> is there a way to "flatten out" a repo? Remove all stacking and get all history be local?
<ree> lifeless, ^
<spiv> jml: yes, that's probably the best option at the moment.
<spiv> jml: In the background I've recently started thinking about how to do that better, but for now hooking into where log_exception_quietly goes is the simplest route I can think of.
<jml> spiv, thanks.
<jml> spiv, why doesn't bzr use log.exception for that?
<jml> (I'm guessing performance, but it's worth asking)
<spiv> jml: you mean logging.exception?  Not sure for this particular case.
<spiv> I personally wouldn't expect log_exception_quietly to be performance-sensitive... if you're calling it, something has gone wrong, so speed isn't a massive concern.
<jml> spiv, trace._bzr_logger.exception is what I mean in particular.
<jml> hmm. I guess that's a simple patch to try out.
<lifeless> ree: local branches on your pc will be not be stacked
<lifeless> ree: for server side branches, stacking is a *huge* space saver
<lifeless> ree: and you should be able to move the branch to a shared branch without problems; if you have any we can recover via the python API
<lifeless> ree: (just ask a question on answers.launchpad.net/launchpad-code, if noone here or in #launchpad is around/able to help immediately)
<lifeless> jml: do you mean logging.exception ?
<lifeless> jml: because logging was a huge performance suck for us, IIRC
<ree> lifeless, thanks! I have to go now, I'll experiment around.
<jml> lifeless, logging is being used for note & error, just not log_exception_quietly
<lifeless> jml: hmm, not sure then.
<lifeless> jml: I do recall us having performance issues tied into using logging for multiple levels of output
<jml> lifeless, I can easily believe that. :)
<jml> lifeless, but as spiv says, I wouldn't expect log_exception_quietly to be particularly performance-sensitive.
<jml> what'd be the best way of evaluating the performance impact?
<lifeless> test? :P
<lifeless> I'm struggling to think of a scenario where we'd be logging high volumes of exceptions though
<spiv> Yeah, me too.
<lifeless> as we stop what we're doing when we choose to log exceptions
<spiv> I'd think any case where we're logging high volumes of exceptions that the right answer would be "stop doing that" rather than make it fast.
<spiv> I'd expect the highest-volume producer of bzrlib exceptions is probably Launchpad :)
<jml> :D
<poolie> spiv, hi, still around? how did you go on network deltas?
<jml> lifeless, just double checking: bug 365615 is fixed in trunk, should be CPd to Launchpad and should (not 'must') go into 1.16.1...
<ubottu> Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615
<jml> bug 390563 still needs to be fixed (there's a cheap-but-slow fix and an expensive-but-performant fix), it has to go into 1.16.1 and be CPd to Launchpad
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,Triaged] https://launchpad.net/bugs/390563
<lifeless> jml: 365615 yes
<lifeless> 390563 is in progress
<lifeless> no fixes completed yet; have code for a candidate in front of me now
<jml> lifeless, sweet.
<jml> any other bugs that I need to be watching, either as RM or as LP/Bazaar person?
 * jml looks over the Critical bug  list
<jml> I obviously don't know how to use "Target to release"
<lifeless> jml: yes, but let me get this done first
<jml> lifeless, no worries.
<kfogel> poolie: you explained to me once why Bazaar trunk itself is not on 1.16, but I can't remember the answer.  What was it?
<kfogel> poolie: (a mere hint might be enough :-) )
<asabil> bialix: ping ?
<lifeless> kfogel: because wee've moved on?
<lifeless> kfogel: we don't release from trunk
<kfogel> lifeless: not sure I understand.  IIRC, if I branch Bazaar's bleeding-edge development trunk, the branch will not be in 2a, but in something older.  Is that still right?
<lifeless> kfogel: oh, that isn't what you asked
<kfogel> lifeless: sorry
<lifeless> kfogel: two reasons; one we know its broken at the moment.
<kfogel> *nod*
<lifeless> we're trying to fix it
<lifeless> secondly, we knew it was broken, and were trying to fix it
<kfogel> lifeless: :-)
<lifeless> the check and reconcile steps make the upgrade process very traumatic
<lifeless> and at the moment, without LOSA's to help, migrating would be fraught with risk
<kfogel> lifeless: thanks
<kfogel> lifeless: I do think dogfooding is important at some point, but obviously not when there are known problems.
<lifeless> there is another aspect which is that its hard for distros to track trunk until there is a version out there that they can use to pull trunk
<lifeless> so I'm not at all convinced that dogfooding *trunk* in canididate formats makes sense
<kfogel> lifeless: why would we want distros to track trunk?
<lifeless> kfogel: daily builds
<lifeless> or even release builds
<lifeless> what I want is bzr to get to a rich root format ASAP
<kfogel> lifeless: (2a is rich-root, right?)
<lifeless> then we can dogfood 2a as developers without trunk changing to 2a
<kfogel> ah
<lifeless> and once we've got a clean bill of health as developers, then its much lower risk to change trunk
<kfogel> sure
<kfogel> okay, bedtime for me.  Thanks for the explanation, lifeless.
<lifeless> the rich root transition is really painful, as most trapdoors are
<lifeless> hey, how is the mysql test going?
<kfogel> lifeless: still going.  ~/.bzr.log last touched 8 min ago
<lifeless> cpu burning up?
<kfogel> lifeless: yes, it looks like my process eats all available cpu
<lifeless> good
<lifeless> its busy
<bialix> asabil: pong
<asabil> bialix: I just checked bzr explorer, and it looks great ! thanks
<bialix> asabil: kudos for igc!
<bialix> it looks easy, but I agree -- it's great GUI
<asabil> bialix: yes, but you are also the guy implementing it, am I wrong ?
<bialix> I'm padavan here, and igc is master
<bialix> I'm mostly working on qbzr
<asabil> bialix: I see :)
<bialix> it's so cool to see how fast bzr explorer growing into usable tool. mostly because we already have mature enough pieces in bzr-gtk and qbzr
<asabil> bialix: I would like to suggest you take a look at the accurev ui
<asabil> I have never used it myself, but it got some really awesome drag and drop features
<asabil> you can basically drag and drop revisions between branches to merge/cherry pick
<bialix> oh, I see
<asabil> and that's something I would love to see integrated in qbzr's qlog and bzr explorer
<bialix> it's related to qlog (from qbzr then)
<bialix> you also need to ping garyvdm with this idea
<asabil> http://www.accurev.com/virtualbooth/2min-demo/2min-demo.html
 * bialix looks
<asabil> :)
<asabil> it does more than version control, but there are some good ideas that could be used in the bzr gui world I think
<bialix> hmmmmmm
<bialix> why they're dragging offshore team back and forth?
<bialix> what's the point?
<bialix> looks interesting, but I don't understand something
<bialix> anyway thanks, I'll send the link in qbzr ml so other people (garyvdm) can see it too
<asabil> bialix: to allocate resources
<bialix> allocate resources?
<asabil> bialix: from what I understood, accurev does version control + bug tracking + resources management
<bialix> and it supposed to be distributed?
<asabil> bialix: I am not sure, never used it myself as I said earlier
<bialix> ok
<asabil> but basically they are dragging a Team on top of a Stream (branch) to say that "this is the team now working on this branch"
<bialix> hm
<bialix> I see the point
<bialix> asabil, btw here is our ideas qbout qbzr gui http://groups.google.com/group/qbzr/browse_thread/thread/68987a67f323e287#
<bialix> feel free to comment
<bialix> the main problem with bzr is main bzr idea: one branch = one dir
<asabil> will check it out, thanks
<asabil> yep, I agree :/
<bialix> so you have to either work inside shared repo to get all branches
<bialix> or create virtual project structure
<bialix> though I think defining projects (including remote branches like in git) could be very powerful
<bialix> I'm not sure how such project could be shared between several devs though
<bialix> future colocated branches won't fix all rough edges
<bialix> I think idea of registering remote branches in git is the right idea
<bialix> although it's mostly local thing IIUC
<asabil> yep
<asabil> but I think each model has its flaws
<bialix> as usual :-)
<bialix> igc: ping
<igc> hi bialix
<bialix> hi, is there possible to pass current branch as argument to some commands?
<bialix> in explorer
<igc> bialix: yes
<igc> bialix: see lib/app-suite-qbzr.ini in rev 113
<bialix>     "add":      "bzr qadd --ui-mode %(selected)s",
<bialix> that is?
<igc> bialix: we haven't populated the context with "current selection" information yet, but the command definitions support it when we do
<igc> bialix: %(root)s is the current branch
<igc> that bit is working now
<igc> bialix: got to go, sorry
<bialix> ok
<igc> very hungry and dinner is ready :-)
 * igc dinner
<bialix> bon appetit
<poolie> night
<lifeless> EOD()
<mzz> I was wondering if putting unrelated projects into the same shared repository is good, bad or neutral?
<mzz> I currently have most stuff in a single ~/bzr shared repo and am doing some belated digital spring cleaning, was wondering if I should change that
<lifeless> neutral
<vxnick_afk> mzz: I only ever put related projects within the same shared repo
<vxnick> related branches, even
<ddaa> lifeless: If I understood correctly, at some point it was bad, if one project was large (e.g. launchpad) because the index bloat impacted performance with the branches of small projects.
<mzz> also it makes it a bit hard to rm -rf a project
<mzz> so I think I'm changing away from it
<ddaa> But 1. maybe I misunderstood, or 2. maybe it's fixed now with some newer non-default repo format.
<lifeless> ddaa: bzr runs out of steam with 16K projects
<lifeless> (all of ubuntu)
<lifeless> but other than that its really just total things to index, not project count; the steam issue on 16K projects is simply the total file-version count
<lifeless> and B+Tree indices are much more robust than the flat file indices were
<ddaa> I do not understand what you mean by the "16k projects" limit. I take your other reply as meaning "yes, index bloat can be an issue with the default repo format, but it's fixed with repo format >= 1.9".
<lifeless> I put all of ubuntu into a single repo
<lifeless> as 16K 1-commit long branches
<lifeless> it uses a lot of memory to work with everything at once
<lifeless> but you can commit to individual branches very quickly and successfully
<ddaa> lifeless: with which repo format?
<lifeless> 1.9+
<lifeless> I think
<lifeless> pack-0.92 was worse
<ddaa> Thanks. Sorry about being this insistent, but I think it's important to be very clear about what performance benefits from non-default repo formats.
<lifeless> 1.9 memory caps the cache for indices
<lifeless> speeds up locating data by 100x factor (200:1 rather than 2:1 fan out)
<lifeless> 2a delivers similar changes to the inventory layer
<ddaa> So, how are you going to market 2.0? Came with something better than "bzr, it's not slow anymore!"?
<lifeless> no idea :)
<ddaa> My 2Â¢, postpone 2.0 until you have a marketing angle.
<ddaa> 2.0 is largely (not only, but largely) a marketing op, so better to fire that particular bullet when you have a good target.
<lifeless> its mainly about fixing the rich root problem once and for all
<lifeless> marketing is a small component
<lifeless> 2.0's default format will be rich root; there will be no new formats added in 2.0 that are not rich root
<ddaa> Oh. I thought it was more important to make the public reconsider its perception that "git and hg are so much faster than bzr".
<lifeless> the way to do that is to be fast
<ddaa> Which has proven disastrous for adoption.
<lifeless> have you tried 2a out?
<ddaa> Nope. Not interested in testing it before release. Bzr has been mostly fast enough for me since knitpacks.
<lifeless> 2a is supported - its a released format
<lifeless> it becomes default in 2.0
<lifeless> I encourage you to migrate to rich roots as soon as you can; it will mean you can test 2a more easily if you want to
<ddaa> Oh right, it must have been just released.
<lifeless> 18th June :)
<ddaa> I set up repos for my current project just a couple of weeks ago. It was not out yet.
<ddaa> BTW, I did have a performance problem.
<lifeless> 1.16.1 will fix a key bug with 2a btw
<lifeless> thats due out in the next dayish
<ddaa> Specifically, initial push to as unpopulated repo through bzr+shh was MUCH slower than it should have been (with 1.9 repos).
<lifeless> not a dataloss bug, just annoying
<lifeless> big history?
<lifeless> and what bzr version ?
<ddaa> History ~1000 revs. Bzr from ppa as of one month ago.
<ddaa> Import from hg using fast-import.
<lifeless> ok
<lifeless> its odd that that would be slow
<ddaa> It was not as much slow as stalling.
<lifeless> if you care to a) try with bzr 1.16 at both ends and b) if it is still slow, run with 'bzr -Dhpss' and file a bug with the .bzr.log contents for it
<ddaa> At minutes at a time.
<ddaa> Sure. I'll do that today.
<lifeless> lan or internet?
<ddaa> internet, but should be fast
<lifeless> we had a hard-to-diagnose problem with the python trials
<ddaa> i.e. remote host is a hosted server on the same ISP as my workstation.
<lifeless> similar sounding symptoms
<ddaa> I'd be happy to provide diagnostic.
<lifeless> cool
<lifeless> thanks
<asabil> is it normal that bzr status takes 26sec to complete with a clean working tree ?
<lifeless> asabil: it has to sha1sum the files the first time
<lifeless> asabil: it should be near instant after that
<asabil> lifeless: what is the 1st time ?
<lifeless> asabil: after checkout, after manually copying the tree (destroys the stat cache)
<asabil> right, it gets down to 1.1 seconds after that
<lifeless> asabil: the other possibility is that your tree was cold and you're actually measuring the time to page in the dentries and inodes for the tree (and if its really cold, bzr is likely not in cache as well - thats a good 15-20 seconds there, because python *sucks* at loading many modules)
<ddaa> also, if the tree has many files, it can take a while for the system to read directory entries into the cache. Cold-cache perf occurs e.g. after reboots or long periods not working on those files.
<ddaa> (lifeless just said the same thing with more jargon)
<asabil> lifeless: also I had a really weird issue with bzr-svn and the --development-6-rich-root format
<vxnick> davidstrauss: ping
<davidstrauss> vxnick: pong
<asabil> I checked webkit over http, and it did result in an 11GB repository
<vxnick> davidstrauss: did you package the fixed 1.16 installer?
 * ddaa goes afk for an hour
<asabil> it went down to 800MB after running bzr pack
<davidstrauss> vxnick: I haven't done anything since that venerable night
<lifeless> asabil: hmm, shoulda gone smaller.
<vxnick> davidstrauss: fair enough :)
<davidstrauss> vxnick: It wasn't clear from the mailing list who was doing what
<vxnick> davidstrauss: ah, ok
<asabil> lifeless: the 11GB is not good in the 1st place I think
<lifeless> anyhow, its bug https://bugs.edge.launchpad.net/bzr/+bug/376748
<ubottu> Ubuntu bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released]
<lifeless> bzr-svn needs to change as well
<asabil> lifeless: it wasn't a conversion
<asabil> it was a fresh checkout
<lifeless> asabil: svn->bzr - thats a conversion
<asabil> ah oki
<asabil> thanks
<lifeless> so what happens is
<lifeless> bzr-svn copies some data
<asabil> yes ?
<lifeless> because of a couple of things, its not compressed beyond zlib
<lifeless> then, when it hits a threshold (5000 commits I think), it commits the transaction, and repeats
<lifeless> bzr's core causes an autopack when a certain number of transactions have occured
<lifeless> probably bzr-svn needs some tuning to work better with 2a
<lifeless> and it definitely needs to start doing the incremental autopack at the end of the fetch process as well
<asabil> I see
<lifeless> `night all
<asabil> night, and thanks for the explanation
<Peng_> You mean the pack_hint stuff? bzr-svn and bzr-git do that now.
<jrwren> I'm getting very strange behavior, bzr 1.16 on win32 installed via the setup program. nslookup resolves my host, an internal dns name, but bzr says "failed to lookup <hostname>:4155: getaddrinfo failed"
<james_w> it shouldn't be adding the port to the lookup should it?
<james_w> how many colons do you have in the host/user/password part of the URI?
<jrwren> none.
<jrwren> its connecting to a bzr://host/path
<jrwren> an instance of bzr --serve running
<jrwren> it appears to be python getaddrinfo is different from windows nslookup.
<jrwren> ah!  maybe a python bug.
<jrwren> my win7 network interfaces were in bridge mode.
<jrwren> I had both interfaces up and connected to the same network.
<jrwren> when I took down an interface, it worked again.
<jam>  morning vila
<jam> morning #bzr
<james_w> morning jam
 * vila waves and wonders how jam manage to pop up at the precise second I was clicking on ja1 to check :-)
<jam> vila:  magic
<vila> jam: Aren't you scared that my magic allows me to summon you with my mouse ?
<vila> :D
<jam> meh, such is life
<jam> Being summoned at the whim of a Frenchman is just part of the mystery of the world
<awilkins> Ca va
<awilkins> And C'est la vie
 * vila should stop magic, too much of it today anyway
<awilkins> Speaking of mouse magic, I've discovered Synergy and I' love it
<vila> awilkins: you forgot: 'Et pour la ptite dame ce sera quoi ?'
<vila> awilkins: yup, synergy rocks, despite some incompatibilities with virtualbox
<awilkins> Ma Francais est tres merde
<vila> awilkins: You certainly meant: "Mon francais n'est pas tres bon" :-D
<awilkins> Ah, yes, I just called myself a girl
<awilkins> No wonder they're obsessed with sex, it suffuses their language (ok, ok, that's gender)
<vila> awilkins: nope, I'm a boy, yet, I can say: "Ma voiture est en panne" (my car is broken)
<vila> awilkins: German is even worse, there is also neutral ;-)
<awilkins> So "french" is mle
<awilkins> I thought it was that way round
<awilkins> I only studied it until I was 15
<Tak> yeah, I wonder why so many of the romance languages dropped the neuter gender from latin
<awilkins> Wasn't romantic enough   <ducks>
 * Tak cry
<awilkins> verterok: I hate Eclipse sometimes
<awilkins> "No repository found containing ...."   WHY IS THE SOFTWARE IN THE LIST IF YOU CAN'T SEE ITT!!!!1
<awilkins> Ahem.
 * awilkins calms down a bit
<verterok> awilkins: you'r not alone
<jrwren> is there a way to spec a revno saying "last time this file changed"?
<jrwren> i want to bzr diff MyFile, I know it changed recently, but I don't know if its -2, -3, -4...
<jrwren> is there a way to say "-1 for this file" ?
<vila> jrwren: no, but annotate will show you all revisions the modify you file
<jrwren> ah!  right!
<jrwren> ty.
<vila> jrwren: no, but annotate will show you all revisions the modified your file
<vila> gee, typos all over the place
<vila> s/the/that/ even or something
<awilkins> You can log a file
<awilkins> bzr qlog <file> and bzr log <file> work just fine
<jrwren> annotate doesn't work in this case because I'm looking for a deleted line.
<jrwren> yes, I was trying to avoid log then diff
<vila> jrwren: try qannotate
<vila> one more typo "-(
<jrwren> i'm on win32 :(
<awilkins> qannotate works on win32
<vila> qannotate from the qbzr plugin
<jrwren> whoa!  awesome!
<awilkins> If you installed the .exe it's arleady instlled
<jrwren> thanks, that helps a lot
<james_w> chk seems to have changed the rules about the revprops you can supply
<james_w> I have to supply unicode values now, and I thought I had to supply non-unicode with old formats
<james_w> was I wrong before?
<awilkins> Oh, I found a circumstance in 1.16 on windows where it just drops dead, something happening inside groupcompress_pyx.pyd
<awilkins> Alas, no stack track, because it just drops a minidump
<awilkins> Would that actually be any use to any bzr developers?
<rockstar> jam, who designed the plugin model for bazaar?
<vila> awilkins: did you check you .bzr.log ?
<vila> awilkins: did you check your .bzr.log ?
<awilkins> vila: yes
<jam> rockstar: I wrote the original code
<jam> james_w: Revision property *values* were *always* Unicode
<jam> we may have not asserted that in the past
<jam> but they were meant to be
<jam> and the decoder would always turn them into Unicode
<awilkins> vila: It doesn't write a stack dump to the log. I suppose a debug-on log would be ok
<james_w> jam: ok, thanks
<jam> awilkins: a copy of the *data* you were using would be helpful
<jam> if that is possible
<jam> awilkins: and you can rm groupcompress_pyx.pyd and you should then get a stacktrace
<rockstar> jam, so, if I wanted to, say, steal the plugin loading code, where would I need to look?
<jam> Though I recommend *moving* it away
<jam> rockstar: bzrlib/plugin.py
<vila> rockstar: groupcompress is not a plugin anymore
<jam> mv groupcompress_pyx.pyd groupcompress_pyx.old.pyd
<rockstar> jam, okay.
<jam> rockstar: different threads :)
<jam> awilkins: We have a pure-python fallback that will be in library.zip
<rockstar> vila, ?
<jam> So we should recover just fine from the .pyd going missing
<awilkins> jam: Alas, the data is rather large
<jam> awilkins: my guess is an out-of-memory error or something weird like that
<jam> awilkins: but again, the pure-python is more "segfault" tolerant
<awilkins> jam: That was my guess too ; it's also a bzr-svn branch
<jam> so try that and see if it gives anything interesting
<vila> rockstar: err, sorry, misread your first message, forget me
<awilkins> jam: Ok, I'll have to tinker with library.zip
<jam> awilkins: you shouldn't have to tinker with library.zip
<awilkins> jam: Can you just unpack it and delete the zip
<jam> I was just saying where the python code is
<awilkins> Ah, yes
<awilkins> so just rename it to pyd_off ?
<jam> awilkins: yep
<rockstar> vila, c'est bon
<jam> vila: any chance you could look at https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889
<jam> It should unblock the launchpad devs
<jam> so I'd like to get it merged in
<jam> and probably end up cherrypicking it to 1.16.1
<jam> Then I need to look at a more complete fix
<jam> abentley: https://code.edge.launchpad.net/~jameinel/bzr/bug-390563/+merge/7889
<jam> That is the branch Robert & I put together
<jam> which probably fixes your issue about texts getting fetched that have already been fetched.
<abentley> jam: That approach isn't as robust as simply skipping duplicates when inserting records.  For example, the target repository may have text versions that cannot be predicted from its inventory data.
<jam> abentley: I think erroring is the right approach if you have data that is inconsistent with what we want to insert that "cannot be predicted from the inventory data"
 * vila can't parse robust == ignoring errors
<abentley> jam: I disagree.
<jam> abentley: if you have something that isn't referenecd
<jam> which then *disagrees* with data that *is* referenced
<jam> then you have something very strange going on
<jam> and it would be better to error than to warn
<jam> warning == do nothing
<jam> (most people ignore warnings)
<abentley> jam: Erroring makes it harder to fix such situations.  It also requires the code that determines what to send to be bug-free.
<jam> abentley: having different content be "acceptible" means that broken repositories are never "found"
<abentley> jam: Since you acknowledge that your code isn't bug-free, I'm not happy with such a solution.
<jam> abentley: code is never bug free
<jam> I would rather have it fail
<jam> than silently propagate corruption
<vila> corrupted data are harder to fix and diagnose than corrupted code
<abentley> jam: I didn't say we should do it silently.
<jam> abentley: a warning won't generate a bug report
<jam> nor push us to fix the code
<abentley> jam: It's not silent.  Users who care about corruption will notice and do something about it.  Users who don't care won't bother.  Everyone wins.
<jam> cprov: I think the "crimson-and-clover" branch was yours, right? I've confirmed that lp:~jameinel/bzr/bug-390563 on the server side allows me to branch your stacked branch.
<jam> beuno: ^^
<jam> abentley: I honestly doubt it.
<jam> Simple warnings get ignored
<abentley> jam: Also, your patch means that a bzr 1.16 server will break a newer client.
<jam> abentley: nope
<abentley> jam: Doesn't the server decide what to send?
<jam> abentley: so an older server will send more data than necessary to a client
<jam> no breakage
<jam> an older server will *break* just as it is breaking today
<jam> when you push minimal data
<jam> but then fetch more data than that
<jam> client determines what data to push
<jam> server determines what data to pull
<abentley> jam: Right.  I don't want it to break the way it breaks today.
<jam> aka, source determines data
<jam> abentley: and upgrading the *server* to this patch will fix it
<abentley> jam: I encountered this bug when pulling, not when pushing.
<jam> abentley: to give details
<jam> when pushing up 1 rev
<jam> we pushed up the minimal data
<jam> when fetching 10 revs
<jam> we suddenly started fetching more data than the minimal set
<jam> so doing "bzr push; bzr commit; bzr push" would send a minimal amount of data to the server
<jam> and then doing "bzr pull" would break
<jam> (for someone that didn't have the data)
<jam> if you did "bzr commit; bzr commit; bzr push"
<jam> everyone would be happy
<jam> the server would have "more data than necessary"
<jam> but that doesn't *break* things
<abentley> jam: As I said earlier, this approach is not robust.  I'm not happy with it.
<jam> abentley: having the same text twice in a repository with identical details does not harm anything
<jam> attempting to insert it with *different* details does
<jam> I'm against not aborting under that circumstance
<abentley> jam: It does no harm if you don't insert it.
<jam> abentley: Except if *you're* the one that is wrong
<jam> and the only way to find that out
<jam> is to fetch someone else who is actually right
<abentley> But you're damaging the case where I'm the one who is actually right.
<jam> unlike the justice system, I'd rather presume guilty than innocent
<jam> I realize this has blocked LP devs for a couple of days
<jam> and that is certainly annoying
<jam> I'd rather block some people and get a fix
<jam> than not block, and have the problem spread
<abentley> jam: It is not reasonable to prevent people from pulling good data from a server, just because the server also happens to have bad data.
<abentley> It makes it much harder for us to fix the data.
<abentley> And this won't detect most forms of bad data.  It will only detect it in edge cases.
<abentley> In fact, it won't even detect bad that we are inserting.  It will only detect potentially bad data that we *aren't* inserting.
<abentley> I'm all for improving consistency, but this is not contributing to that cause significantly.
<vila> jam: I was looking at Robert's branch already,  I approved yours
<mxpxpod> is there a way to register a directory type with the directory service and have certain urls initialize a shared repository with multiple branches in it?
<abentley> jam: I also don't understand why you think my fix would cause the corruption to spread.  Your fix would cause us to silently ignore the bad data, while my fix makes us warn about it.
<jam> abentley: my fix is not specifically proposed for your work, though I think it will get you to where you want to be
<jam> the problem is cases where we should be fetching things  and they turn out to be inconsistent
<jam> yours will still only warn
<abentley> The problem is that I don't trust bzr to figure out what things we should be fetching.  Especially if I don't have control over the copy of bzr determining what to fetch.  That code is complex and you've already said it still needs work.
<vxnick> is it best to use 'bzr bundle' or 'bzr send' for saving patches?
<vxnick> creating*
<dash> i think the main difference is that 'send' mails it
<vxnick> I can't get either to output the patch info in the output file - I don't know what I'm missing
 * Tak always use bzr diff
<vxnick> I've tried "bzr bundle -o changes.diff" and "bzr bundle -r-1 -o changes.diff"
<vxnick> so something like "bzr diff -r-1 > changes.diff" ?
<LarstiQ> vxnick: bzr send
<fullermd> You want 'send -o$FILE'
<fullermd> bundle is deprecated since about 2 weeks after dirt was invented.
<dash> why doesn't it say anything about that then
<vxnick> ah I didn't know that
<LarstiQ> vxnick: and you might want to supply the submit branch
<LarstiQ> dash: bundle is a hidden command
<fullermd> It maybe should.  It's been taken out of the 'commands' list since...  I don't even know.
<fullermd> 0.11 maybe, something in that era.
<vxnick> LarstiQ: there isn't a public branch
<LarstiQ> vxnick: send needs to know which revisions to include
<vxnick> LarstiQ: I'm using "-r -1" for that
<vxnick> assuming that'll do the last rev
<LarstiQ> vxnick: not exactly
<vxnick> "bzr send -r -2.. -o changes.diff" works
<fullermd> And note 'submit branch' != 'public branch'.
<vxnick> fullermd: yeah I'm aware of that bit
<LarstiQ> vxnick: say you have a branch that is 2 revisions behind, if you made a merge directive with just the last revision, it wouldn't be able to apply that in the 2-behind branch
<fullermd> And if that works, it probably means it already has a submit branch, so you don't need the -r at all (unless you're intending a cherrypick).
<vxnick> ok, so assume I've branched someone's code - if I want to create a patch with my changes in it since their last update, what would I use for the revision argument?
<LarstiQ> vxnick: nothing
<LarstiQ> vxnick: just `bzr send`
<fullermd> You wouldn't need any.  send checks the submit branch (which default to what you branched from), and includes everything that isn't in it already.
<vxnick> ah, thanks :)
<LarstiQ> vxnick: now, if your last couple of revisions were bogus, but you wanted to send the rest, you would do `bzr send -r -4`
<LarstiQ> which means, everything up to -4 that the submit branch doesn't have
<vxnick> gotcha
 * LarstiQ goes for dinner
<vxnick> thanks for your help guys
<LarstiQ> vxnick: np
<glyph> "DoS attack"?
<glyph> whoops
<glyph> I was responding to something twenty hours ago on a different channel :)
<alf> Hello, I was wondering if there is a preferred way to handle feature branches in very large (disk-space wise) trees. Creating lots of feature branches creates lots of large trees which can be a problem. Any thoughts?
<FibeRichio> Is it possible to integrate the "bzr-push-and-update"-plugin to Turtoise Bazaar on Windows? Or do I have to use the commandline for that?
<beuno> alf, because of the working tree, or the revision information?
<alf> beuno: the working tree
<beuno> alf, you can use bzr switch\
<alf> beuno: thanks, I am reading about it now in the user guide
<jskulski> is this possible: bzr branching from a checkout of svn?
<LarstiQ> jskulski: if you have bzr-svn installed, yes
<jskulski> LarstiQ:: so when you bzr push you modify the files in teh checkout (which will sit and wait to be committed manually?)
<kirkland> i'm in a local bzr branch, and i want to change the location it pushes to when i just type "bzr push"
<kirkland> how do i change the stuff cached and reported in 'bzr info' ?
<vxnick> kirkland: bzr push --remember <new location>
<kirkland> vxnick: rocking, thanks.
<LarstiQ> jskulski: no, it will push to the svn server then
<LarstiQ> jskulski: (and update the checkout)
<LarstiQ> jskulski: you need not touch the svn checkout anymore after you branch from it though
<jskulski> LarstiQ:: ok, so for bzr-svn, the workflow requiires svn commit access
<LarstiQ> jskulski: how so? (and what workflow?)
<jskulski> is that correct?
<LarstiQ> jskulski: you don't need to have svn commit access to use bzr-svn, no
<LarstiQ> jskulski: you need it to write back to the svn repo though
<jskulski> LarstiQ:: yeah
<jskulski> LarstiQ:: ok thanks for your help
<LarstiQ> jskulski: and pushing to a checkout implies pushing to it's master, both in bzr and svn
<jskulski> right on
<jskulski> seriously this channel is rocking, consistently helpful and friendly advice to a newb.
<jskulski> thanks!
<LarstiQ> jskulski: but it's fine to just branch from svn, develop, publish, and let someone else bother with pushing back into svn. It's what I do ;)
<LarstiQ> jskulski: thanks :)
<jskulski> LarstiQ:: oo that is what i'm waiting for
<jskulski> err looking for
<jskulski> hey again, I am trying to bzr branch file:///var/www/project where /var/www/project is a svn checkout of an external repository and I keep getting a segementation fault.
<jskulski> i have bzr-svn installed
<jskulski> and i've done this process berfore with local svn repositories
<LarstiQ> jskulski: which version of bzr, bzr-svn (and possibly subvertpy) does this happen with?
<jskulski> bzr 1.5
<jskulski> 1.5.1
<jskulski> 0.4.10-2
<jskulski> sorry 0.4.10-2 is bzr-svn
<schmoonior> so I was doing a bzr add when my Mac had the equivalent of a BSOD (not related to bzr) and now when I run bzr status I get: bzr: ERROR: The dirstate file (DirState(u'/Users/drew/Documents/working/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '\n'
<schmoonior> any suggestions?
<jskulski> subversion is also 1.5, but not sure what the external reposiotry version is
<Peng_> schmoonior: If you don't mind losing some of the working tree's uncommitted meta data (e.g. bzr adds), and aren't using a lightweight checkout, getting rid of .bzr/checkout and running "bzr co" is probably easiest.
<Peng_> schmoonior: Note: if it opens a black hole and destroys the planet, it's not my fault. :)
<schmoonior> fortunately I'm not at LHC ;)
<schmoonior> if I do the bzr co, it won't mess with any of the uncommitted changes in files?
<Peng_> schmoonior: I don't know. I'd be surprised if it *destroyed* anything, but it might rename stuff to backup files or generate conflicts or something.
<Peng_> schmoonior: Again, black holes, not my fault, etc.
<schmoonior> ok, I might just make a simple copy of my tree before I do anything
<SamB> schmoonior: was just about to suggest that myself ;-)
<Peng_> Yeah, backups are good. :)
<schmoonior> thanks guys, I will let you know how it goes
<LarstiQ> jskulski: sorry, I didn't get highlighted so didn't get drwan back here
<LarstiQ> jskulski: bzr-svn 0.4 is a dead end, preferably use 0.6.x or if not that then at least 0.5.x
<kfogel> anyone: if you had to point people to just one page to say what brisbane-core is all about, what page would it be?  http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ?
<LarstiQ> jskulski: I can't promise all bugs will be fixed in newer versions, but many have
<LarstiQ> kfogel: if one page, then yes that one
<kfogel> LarstiQ: thanks
<LarstiQ> jskulski: are you on suse by chance?
<jskulski> LarstiQ:: sorry stepped out, i will look into updating. We are debian 5
<schmoonior> Peng_ and SamB: it appears to work.  I'll have to readd everything like you suggested and I had to fix a bunch of conflicts.  Thanks again
<LarstiQ> jskulski: ah good, I run Lenny myself too
<SamB> jelmer: if I do a "bzr svn-import" with a destination repository that contains a branch of my own in addition to the branches imported from SVN, is my branch in any danger?
<synic> is there an easy way to serve bzr via http with access control?
<dash> sure
<dash> use any http server with access control :)
<synic> I see.  Just the regular Auth in apache would work?  What about limiting writes to some users and read to others?
<SamB> bazaar supports commit-by-PUT now?
<synic> anyone?
<dash> synic: i don't remember if you can push to a bzr branch via http
<LarstiQ> SamB: with smartserver enabled, or with webdav
<dash> but yes, just regular auth will work.
<synic> I'm trying to find the best way to serve a bzr repo to windows users with access control
<synic> ssh doesn't really work because lol windows
<LarstiQ> windows can do ssh
<LarstiQ> synic: bzr has support for putty/pageant
<synic> oh, pageant?  Sweet, this will work then
<synic> LarstiQ: is there a doc on that?  I'd like to use ssh keys
<LarstiQ> synic: userguide perhaps, but if pageant is in your PATH, it should just work?
<LarstiQ> synic: and yes, with keys :)
<synic> LarstiQ: do you have to tell bzr to use pageant?
<lifeless> jelmer: bug 376748, just checking - you call the partial pack function?
<ubottu> Launchpad bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released] https://launchpad.net/bugs/376748
<LarstiQ> synic: should not be needed. But in case you also have openssh on windows (which it will prefer) you can use BZR_SSH=plink
<synic> mk
<LarstiQ> synic: but afaik all you should need is to have PATH set up
<synic> yeah, it's working now.  Thanks :)
<LarstiQ> cool :)
<synic> one more question, is there a way to "bzr push" in tortoise bzr?
<synic> it's got pull, update, commit, add, delete.  No push?
<LarstiQ> synic: called 'publish' maybe?
 * LarstiQ is not well versed in windows/Tortoise :/
<synic> yeah, no publish
<synic> I'm not very good with windows either
<synic> I'm probably missing something obvious
<jam> lifeless: ping
<lifeless> hi
<lifeless> timing :P I wass just about to go grab food
<jam> Sorry I was away, my wireless on my laptop dies every now and then
<jam> so I just hacked hidden without it for a while
<jam> lifeless: so you may want to look at lp:~jameinel/bzr/1.17-chk-multilevel
<lifeless> thats cool
<lifeless> so
<jam> I'm pushing it now
<jam> anyway, it is an attempt at using the same heapq strategy
<jam> for iter_interesting_nodes
<lifeless> I was wondering why you remove any uninteresting nodes
<jam> any?
<jam> so that you don't have to walk the entire uninteresting set
<jam> the way the code was structured
<jam> it made sure to get the 'largest possible uninteresting' set
<jam> and then filtered the interesting nodes as it read the rest in
<lifeless> well
<lifeless> let me rephrase
<lifeless> 'I wasn't awake'
<lifeless> clearly an interesting tree may have uninteresting nodes, so you have to trim from both sides
<lifeless> so, all good
<lifeless> let me know when its pushed, and I'll give it a review
<lifeless> I wanted to ask you about abentley's skip-dupes; reading scrollback it looks to me like you have similar concerns to what I expressed about the first version of the patch
<jam> lifeless: the basic fix I wrote, and you managed to write tests for has been landed in bzr.dev
<jam> as it at least fixes the common cases we are running into
<jam> lp:~jameinel/bzr/1.17-chk-multilevel is a pretty major rewrite
<jam> and it is going to be a while before I'm specifically ready to land it
<jam> It currently reads nodes 1-at-a-time
<jam> which isn't appropriate for what we are doing
<jam> (especiallly yielding *keys* one-at-a-time)
<lifeless> heh yes
<lifeless> I think the crisis is over, I'm helping[nagging?] mwhudson to land the common case fix
<jam> lifeless: generally, I think the check we have is better than a simple warning. I could be convinced that it isn't the perfect time to be doing the check, and that we should have better ways of handling it.
<jam> like having a "reconcile my repo with this repo over here"
<jam> and "I know you don't like it, but stop getting in my way" flag.
<lifeless> jam: Could you do me a favour, and review aarons new version; I don't like being the only bad guy :)
<abentley> lifeless: Dude, I did what you asked.
<lifeless> abentley: you did, but the basic concern I expressed is still there
<lifeless> which is fundamental
<lifeless> the trace version has no performance issues - and thats great
<lifeless> if its conceptually ok to do this, then it passes muster
<abentley> lifeless: You expressed concern about it being silent.  It's not silent.
<lifeless> abentley: your revised version is massively better than the first one. I'm ecstatic on that basis.
<lifeless> I think one of the concerns I have that I haven't adequately expressed so far is this:
<lifeless> for revisions is really serious to have this wrong
<lifeless> for texts it affects annotate and log
<lifeless> so I'm going to ask you to do one smallish further change, which is to note whether we care in a particular GCVF  object, and then I'll be happy
<SamB> have what wrong?
<abentley> lifeless: for revisions, it would be a pretty big bug to miscalculate what revisions to send.
<jam> abentley: it would be an even bigger bug to have different ancestries
<abentley> jam: I'm not sure that's even true.
<SamB> sending the wrong revisions doesn't sound like it ought to do any permanent damage to *me*
<jam> for the same revision to have different parents...
<jam> SamB: sending revisions you don't need, or duplicates with what you already have doesn't seem like a problem, as long as they are identical
<SamB> corrupting the revisions sent is indeed *bad*
<lifeless> abentley: it would; and this was an inarticulated concern, which is why you couldn't fix it ;)
<SamB> jam: exactly
<lifeless> abentley: now I've figured it out, its possible to fix it.
<lifeless> abentley: I've proposed one way in the merge
<SamB> jam: not sending what you do need is a problem but presumably the other end will catch it
<lifeless> abentley: other ways are likely possible, and if you have one please propose it. Though what I'm proposing is pretty lightweight.
<jam> and at least in our "theoretical" prototypes, we have discussed sending extra data in exchange for not having to query to determine what you do/don't have
<abentley> lifeless: I will update my branch as you requested.  I think my fix is appropriate for CPing into Launchpad, because it lets us reconcile trunk.
<SamB> jam: like the way git defaults to behaving?
<lifeless> abentley: as long as we deploy the full version rapidly thereafter I'm fine with that
<lifeless> abentley: I would be concerned about running with trace-for-revisions for extended periods
<lifeless> SamB: that isn't what git does
<lifeless> abentley: sorry for giving your a runaround here; it wasn't intentional.
<lifeless> s/your/you/
<abentley> lifeless: Okay.
<SamB> lifeless: well, it doesn't involve going down the list and asking the recieving end "do you have this? do you have this?"
<abentley> lifeless: I will try to set up a cron job to run "bzr check" on trunk.
<lifeless> SamB: it does
<lifeless> abentley: I think thats a good precaution.
<SamB> lifeless: git-to-git? no...
<lifeless> SamB: yes
<lifeless> SamB: it has a bidirectional stream where both sides say 'I have X\nI have Y\n'...
<lifeless> SamB: and that goes on until the sender knows precisely what the reciever doesn't have, when it stops sending 'I have' messages, goes and creates a pack on the fly and transmits it.
<SamB> well, it doesn't go and then ask you what blobs you have ...
<lifeless> SamB: neither does bzr
<lifeless> SamB: it walks the commits and tree content to determine what blobs to send; bzr does similar.
<SamB> ... which can be annoying if you're rewriting ancestry ;-P
<lifeless> so yes, the same blob will be sent if you rebased or similar the only refs that had it
<lifeless> and bzr will do the same in the same situation
<lifeless> what jam is talking about is quite different
<SamB> so, what approximation do you mean ?
<lifeless> its about *deliberately* cutting the calculation for 'what the receiver has' short (either at the revision level, or doing less work analysing the commits), and just sending what we have on disk
<lifeless> e.g. send the entire compression group, rather than the 3 texts from within it that the receiver needs
<SamB> oh, you mean the sender deciding "screw this, I'm just sending the pack"?
<lifeless> for instance, yes.
<lifeless> jam: I really must eat now, bbs
<jam> lifeless: eat hearty
<lifeless> 87.1kg today
<lifeless> slowly slowly
<jam> that is a lot of food to eat
<jam> and it isn't even 8am there
<jam> lifeless: you should slow down indeed :)
<lifeless> jam: !
<lifeless> bbs
<thewrath> hey all i have linux commands i need to run
<thewrath> can i run bzr diff commands
<lifeless> what do you mean?
<thewrath> is there a such thing as bzr diff
<thewrath> want to run something liek this svn diff -r 36:69 URLgoesHere | grep "^+" | grep -v "^+++" | wc -l
<thewrath> but im using bzr
<lifeless> yes there is
<thewrath> pefecto
<thewrath> i need the url like this  hold on
<thewrath> https://code.launchpad.net/~mikesats-coders/mikesats/stableversion
<thewrath> what would the url be for that
<thewrath> would it be bzr diff -r 4:5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l  ?
<lifeless> bzr diff -r 4..5 lp:mikesats
<lamalex> does anyone know the name of the project for code hosting on lp?
<lamalex> whooops
<lamalex> meant to join #launchpad
<lifeless> lamalex: launchpad-code
<thewrath> lifeless but i want the number of added lines
<thewrath> that is where the greps come in handy
<lamalex> lifeless: thanks
<lifeless> thewrath: sure, so use them
<thewrath> is that supposed to be 4.5 or 4:5 lifeliess
<lifeless> 4..5
<thewrath> that is how bzr does it?
<lifeless> yes
<thewrath> bzr diff -r 4..5 lp:mikesats | grep "^+" | grep -v "^+++" | wc -l  ?
<lifeless> yes
<thewrath> lifeless: u still around
<lifeless> thewrath: sure
<thewrath> i get  a dont know how to handle ssh connection
<thewrath> please set bzr_ssh enviroemnt variable
<lifeless> thewrath: are you on windows?
<thewrath> yes sir
<thewrath> i have pageant key list running with my key
<lifeless> ok
<thewrath> how do i correct the error
<lifeless> uhm, I'm not really fluent about using bzr on windows
<lifeless> how did you install bzr?
<thewrath> normal windows install
<lifeless> we have a couple of different installers; can you be more precise? was it a .exe? or the python installer or?
<lifeless> jam: are you still around? ^
<thewrath> exe
<thewrath> i think its sometihng to dow ith cygwin but not sure
<lifeless> thewrath: its meant to detect pageant automatically I thought
<thewrath> yea
<thewrath> it is
<thewrath> damn it
<lifeless> so you could try
<lifeless> set BZR_SSH=paramiko
<lifeless> then run your bzr commands
#bzr 2009-06-26
<lifeless> thewrath: did you install bzr using cygwin's setup.exe?
<jml> lifeless, yesterday, you suggested that there were bugs for 1.16.1 other than bug 365615 and bug 390563
<ubottu> Launchpad bug 365615 in bzr/1.16 "'AbsentContentFactory' object has no attribute 'get_bytes_as' errors with CHK repository on write operations" [Critical,Fix committed] https://launchpad.net/bugs/365615
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<jml> lifeless, can you please point me to them?
<lifeless> jml: did I? I thought I said I was flat out :P
<lifeless> jml: and I recall talking about 2.0 in terms of what bugs there were
<lifeless> anyhow, I'm not aware of other 1.16 worthy cherrypicks
<lifeless> once abentley's skip-dupes patch lands in trunk that might be worth putting in 1.16 too; though I thought lp devs ran off nightlies
<jml> lifeless, we do run off nightlies.
<lifeless> in which case there are no other patches for 1.16 that I know of
<jml> ok.
<jml> what about things to cherrypick to Launchpad?
<lifeless> mwhudson has them in hand
<jml> sweet.
<jml> thanks.
<igc> morning
<lifeless> hai
<igc> hi lifeless
<poolie> jml, re your "branches that fix bugs"
<poolie> there are some more cases like that in devnotes 3.0-ui document
<poolie> http://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html
<jml> poolie, ahh thanks.
<jml> poolie, I'd been meaning to refresh myself on the devnotes branch but let it slip my mind.
<poolie> np
<poolie> i don't necessarily want that document to become a laundry list of every possible thing you could want to do with bzr
<poolie> but these are at least a bit related
<poolie> also airing them on the list may atract more thoughts
<jml> well this has a specific focus I guess
<poolie> jml, could you send a short metronome mail re 1.17?
<jml> poolie: yep, it's already on my list for today
<poolie> oh cool
<poolie> maybe i should send one about 1.17 vs 2.0
<jml> that's probably a good idea
<jml> my list for today is perhaps slightly too long, but I know only one way of making it shorter.
<jml> poolie: I'm also going to cut 1.16.1 today, if I can.
<poolie> delete things? or do things?
<poolie> i was planning to do both :)
<jml> do things.
<lifeless> igc: I'm working on iter-changes today
<lifeless> igc: now that the crisis with fetch is fixed
<igc> lifeless: cool
<lifeless> igc: I'd appreciate your holding off your other landing ;)
<igc> lifeless: I'm doing reviews and clearing the desks to work on bug 374735
<ubottu> Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Triaged] https://launchpad.net/bugs/374735
<igc> sure
<poolie> hello igc, lifeless
<lifeless> hi poolie
<poolie> i'm planning today to: send a coscup abstract, (re)send a blog acct to igc, write up a patch explaining the 2a format, do the minimal activity-tied-to-pb fix, order a new disk
<igc> hi poolie
<poolie> talk to spiv
<poolie> and hopefully get other uifactory fixes done
<poolie> they have a tangle-of-string quality - fixing each test makes for larger changes
<poolie> all good, but it's not converging
<poolie> so sometimes i take a step back and try something smaller
<poolie> but still
<poolie> thanks for the review igc
<jml> another unusual error from our systems: https://devpad.canonical.com/~matsubara/oops.cgi/2009-06-25/SMPM01
<jml> http://paste.ubuntu.com/203878/
<lifeless> it would be nice if that was openid
<jml> when mirroring http://bzr.malept.com/avant-window-navigator
<jml> yes.
<lifeless> didn't you file a bug on that 3 weeks ago?
<jml> I don't think so.
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/377453 ?
<ubottu> Ubuntu bug 377453 in bzr "Error from smart server: ScopeReplacer object '_KnitGraphIndex' was used incorrectly" [High,Confirmed]
<jml> oh good.
<lifeless> hmm, different but similar
<lifeless> add it to the same one I think
<jml> done.
<lifeless> so, iter_changes tests existing now
<lifeless> time to fix implementations
<lifeless> can anyone confirm: setup.py build_ext -i is putting the so files in bzrlib/bzrlib/ ?
 * fullermd hasn't seen it...
 * igc school visit & lunch - bbl
<lifeless> bug 392355
<ubottu> Launchpad bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged] https://launchpad.net/bugs/392355
<mwhudson> lifeless: no
<lifeless> mwhudson: python version? bzrlib version?
<lifeless> mwhudson: are you on karmic?
<mwhudson> lifeless: no
<mwhudson> python2.6 jaunty 4477
<lifeless> jml: you're on karmic aren't you... could you check for this (in 1.16 and-or bzr.dev)
<mwhudson> 4479 sorry
<fullermd> I just did a fresh branch of lp:bzr and they're all in bzrlib/ where they belong.
<lifeless> fullermd: when you run setup.py build_ext -i ?
<fullermd> Yah.
<fullermd> Well, ./setup.py [...]
<lifeless> fullermd: so bzrlib/*.so, not bzrlib/bzrlib/*.so
<fullermd> Right.
<lifeless> ok
<lifeless> thats good data
<lifeless> It could well be setuptools
<fullermd> (py 2.6)
<lifeless> sorry distutils or something
<thewrath> (9:17:33 PM) thewrath: hey guys with bzr or svn any way to find the number of modified lines
<thewrath> (9:17:50 PM) thewrath:  svn diff | grep "^+" | grep -v "^+++" | wc -l  gives you added lines
<thewrath> (9:18:00 PM) thewrath:  svn diff | grep "^-" | grep -v "^---" | wc -l is removed
<thewrath> (9:18:13 PM) thewrath: but i need modified lines and unmodified lines
<lifeless> what are you trying to calculate
<jml> lifeless, the bug refers to 'make build' -- I don't even have a build target in my copy of bzr.
<lifeless> jml: I fabricated. just 'make', or setup.py directly
<thewrath> i need to find the total number of added, removed, modified and unmodified lines from revision a to revision b
<lifeless> the first three are easy
<lifeless> the last one is much harder
<fullermd> 'modified' can be pretty tough to quantify...
<lifeless> I'm not aware of any simple way to do it
<thewrath> lifeless: how u calculate the modififed
<lifeless> thewrath: I'd use some of the existing python libraries to parse the diff and turn added and removed into modifications when they are adjacent
<lifeless> thewrath: be a couple of hours work top, at most.
<lifeless> thewrath: anyway, why do you want this?
<poolie> igc, re the revert patch
<thewrath> lifeless: its for work
<poolie> can you try to add a blackbox test?
<fullermd> I actually thought diff(1) had an arg to show the whole files, which would help with the last, but it doesn't seem to.
<poolie> there's a slim nonzero chance it'll break
<fullermd> You could fake it by asking for 99999 lines of context, I guess.  Would work on all those sub-100kLOC files.
<jml> lifeless, https://bugs.edge.launchpad.net/bzr/+bug/392355/comments/1
<ubottu> Ubuntu bug 392355 in bzr "C extensions placed in wrong directory" [Critical,Triaged]
<lifeless> fullermd: we don'tsupport that argument, I don't think
<fullermd> Well, but we could use the external diff, instead of the internal one.
<lifeless> jml: so its broken for you too
<jml> yep.
<thewrath> lifeless: can i sent you a pm
<lifeless> thewrath: I guess
<jml> lifeless, does this critical bug mean I should use a chroot to rollout 1.16.1?
<jml> I guess I could always experiment.
<lifeless> jml: the so's don't go in the tarball
<lifeless> jml: so no special actions required there
<lifeless> however johnf probably needs to know to build debs properly
<jml> and all the C files go to the correct place, I see.
<lifeless> just popping out to the chemist
<lifeless> brb
 * spiv pops out for food
<lifeless> deep hack time
<lifeless> SMS or ring if you need me
<poolie> lifeless: (realize you're away) fix for progress bar droppings pushed
<poolie> yay hacks
<lifeless> poolie: yay
<lifeless> poolie: do you need a review?
<poolie> yes
<poolie> is easy
<poolie> i also need a lunch
<lifeless> is it 'if count < 1: return' ? or something like that?
<poolie> close
 * jml sends a metronome email
<fullermd> Oh, good, the RC is on my mother's birthday.  Now I'll remember to call her.  Just don't slip the date!
<lifeless> igc: may have found other latent commit bugs with this work :)
<igc> lifeless: I recall raising one or two when I was last looking in there
<poolie> thanks lifeless
<jml> ok. time to cut 1.16.1.
<jml> it's going to look a _lot_ like the current launchpad branch of bzr :)
<glyph> jml: yay releases!
<jml> lousy internet :(
<jml> glyph, Twisted should do time-based releases!
<glyph> jml: you know what else
<glyph> jml: Twisted should have a release manager
<glyph> jml: and a hundred billion dollars.
<jml> glyph, and a pony
<jml> maybe I'll steal the RM job from radix
<jml> if only I were less of a bum.
<glyph> jml: well, relatively speaking
<jml> :)
<jml> has skip-dupes landed in bzr.dev?
<jml> hmm. computer says no.
<jml> there's no bug associated with it either
<lifeless> its not needed for 1.16.1 anyhow
<lifeless> because 2a is not popular, and you're landing a separate fix that means skip-dupes isn't needed anyway.
<lifeless> (needed in terms of 1.16.1 as a server, or locally)
<jml> ok.
<jml> still love merge --uncommitted.
<jml> when doing a point release...
<lifeless> ?
<jml> should I change the introductory paragraphs?
<fullermd> I make use of it in nasty and evil ways on many occasions.
<jml> in the NEWS file, that is.
<lifeless> the whichwhat?
<lifeless> its a new release
<lifeless> it should get its own intro
<jml> OK. That's not how 1.14 & 1.15 were done, but it is how 1.13 was done.
<jml> can someone please look over the release announcement?
<jml> http://paste.ubuntu.com/203968/
<jml> poolie, lifeless: ^
<lifeless> new codename needed I think
<lifeless> and the top line should say 1.16.1
<lifeless> this is a new release; 1.16 is the series
<lifeless> personally, I don't htink you should be moving the bug block
<lifeless> big block*
<lifeless> that was the 1.16 release
 * jml tries to find prior art to copy from
<lifeless> use case for you
<lifeless> 'I am a debian user and I have 1.16 already'
<lifeless> they should see the new changes they are getting.
<vila> hi all
<lifeless> hai
 * vila stares at the restart button (triggered by the ssl update) :-/ What the hell these days !
<vila> back in a restart
<vila> re-hi
<vila> poolie: ping
<jml> I'm off. Back later to finish the bzr 1.16.1 release.
<vila> jml: excellent metronome mail !
<jml> vila, thanks.
<vila> lifeless: still around for a quick chat ?
<lifeless> vila: sure
<lifeless> whats up?
<lifeless> jml: when you return, testresoureces has branches that need your personal touch
<igc> night all
<poolie> hello vila!
<poolie> jml, yes, really nice mail there
<poolie> i mean the metronome one
<poolie> jml, if you're still here, the release mail draft confuses me
<poolie> it almost looks you you're marking all of the trunk changes as being in 1.16, which would either be inaccurate or a mistake
<Adys> I got a centralized repo to which I was the only committer. someone has an --unchanged commit on it since a few hours. I try to push my work but I keep getting "branches have diverged"
<Adys> bzr merge tells "nothing to do". bzr pull tells "no revisions to pull". bzr up tells "Tree is up to date"
<Adys> what am I supposed to do?
<vila> Adys: You can either 'push --overwrite' or 'merge; commit; push'
<Adys> merge doesnt work =/
<Adys> I dont know if its a bug
<Adys> ill try push --overwrite
<vila> Adys: wait
<Adys> Ok
<vila> 'push --overwrite' will ignore the --unchanged commit and make it hard to get back to, while 'merge; commit;push' will take into account
<vila> Adys: what do you want to do ?
<Adys> vila, merge doesnt work
<Adys> it tells "nothing to do"
<vila> Adys: It works then, doing nothing is sometimes the Right Thing :)
<Adys> hm
<Adys> hold on i screwed something up ...
<vila> Adys: What does 'bzr info' says ? Are you working with a standalone branch, a checkout ?
<Adys> standalone
<Adys> uh, is there some way to undo a pull? =P
<vila> Adys: 'pull --overwrite'
<Adys> Yeah I just did that, it had an old location saved
<Adys> think I lost some code.. not a big deal
<vila> Adys: committed or not ?
<Adys> yes
<Adys> committed but not pushed
<vila> then it's not lost
<Adys> How do I get it back?
<vila> you have to find the revid you're interested in and pull it somewhere safe first (aka, not in your current branch)
<Adys> okay
<Adys> vila: I need to grab rev 525, but when I branch it it updates to rev 524
<vila> use 'bzr heads --all' and see if you can find it back
<Adys> found it, what do I do now?
<Adys> HEAD: revision-id: adys@azura-20090626072855-ze3ykij2nuraihhe (dead)
<vila> Adys: bzr branch <orig> -rrevid:adys@azura-20090626072855-ze3ykij2nuraihhe <recover>
<vila> Adys: replace <orig> and <recover> by valid and appropriate values
<Adys> Ah great stuff, thanks. :)
<jml> hello hello
<jml> poolie, had a chance to sanity check?
<Adys> vila: got it all sorted, thanks a lot!
<vila> Adys: Always happy to help (TM)
<Adys> â¢
<jml> gasp
<jml> unicode
<Adys> gasp, customized keyboard layouts :D
<jml> bazaar-vcs.org appears to be down :(
<poolie> jml, i don't think it is present...
<poolie> still checking
<poolie> jml, srsl?
<poolie> srsly*
<jml> poolie, yes, srsly.
<Peng_> Indeed. Cool! Can't connect.
<jml> fixed
<jml> (thanks elmo)
<Peng_> That was quick. What was wrong?
<jml> buggered if I know :)
<poolie> jml, it certainly looks like it's not in there
<poolie> i wonder how the text got into news?
<poolie> jml i guess launchpad got fixed?
<jml> which bit of launchpad?
<elmo> apache upgrade didn't restart cleanly; sorry about that
<elmo> peng: ^--
<Peng_> Oh.
<poolie> jml, the appserver outage?
<jml> poolie, yes. that got fixed
<jml> poolie, what's the number of the bug that appears in NEWS that isn't fixed?
<poolie> bug 376478
<ubottu> Launchpad bug 376478 in percona-xtrabackup "Specify Target Directory Name with innobackupex" [Undecided,New] https://launchpad.net/bugs/376478
<poolie> you cherrypicked trunk r4470
<poolie> which claims to fix that
<poolie> ah
<jml> https://bugs.edge.launchpad.net/bzr/+bug/376748
<ubottu> Ubuntu bug 376748 in bzr "after conversion chk formats are badly packed" [Critical,Fix released]
<poolie> it might just be lack of cherrypick tracking...
<poolie> normally people tend to merge the bugfix branch into the release branch rather than cherrypicking
<poolie> but it's a reasonable enough thing to do
<soren> Can I fake the timestamp on a bzr commit?
<jml> yes.
<soren> (without changing my system clock)
<poolie> of course in this case you couldn't because it was based off too late a version of trunk
<poolie> soren, yes
<soren> Cool. How?
<jml> Python!
<jml> (looking up the api)
<soren> I was afraid you'd say that.
<soren> Oh, well.
<soren> Hm... Doesn't look to hard at all.
<soren> (famous last words)
<jml> soren, yeah... I think I'd just hack something up based on cmd_commit().
<jml> possibly even add an option to cmd_commit for the timestamp.
<jml> poolie, so where were we?
<poolie> i'd be ok with an option to cmd_commit
<poolie> jml, it's in, and it seems like a reasonable thing to put in
<poolie> so i think we're good to go
<jml> rock'n'roll.
<poolie> spiv, still around? how did you go today?
<Wyvern> I have a question: I do bzr status and I get a lot of modified files, even though they haven't been touched. But they have an * at the end. What does that mean?
<bialix> help form bzr hackers needed
<bialix> see http://pastebin.com/m40991c66
<bialix> why I've got error?
<soren> jml: Oh. I was thinking of just calling bzrlib.commit.Commit.commit() from python with the right arguments. This is (hopefully) just a one-off thing.
<soren> jml: Oh, that is what you're suggesting as well.
<jml> soren, basically, yes.
 * soren has not had sufficient coffee today.
<jml> soren, although tweaking the commit command is probably even less work, as long as you don't bother with user-friendly parsing & data validation.
<jml> which you won't, because it's a one off thing :)
<soren> True, true :)
<Peng_> Wyvern: The executable bit probably changed.
<Wyvern> Indeed! Thanks.
<Peng_> jam: FYI, mail2.domainpeople.com yelled at me when I tried to send an email to you. (Nothing important, I just used Reply All on a mailing list post.)
<jelmer> is CommitBuilder.record_entry_contents() going to be removed before 2.0 ?
* jml changed the topic of #bzr to: Bazaar version control system | 1.16.1 released 26th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jml> *mutter mutter*
<jml> conflicts are teh suck
<soren> How do I specify a base revision during a merge?
<soren> I'm trying to merge two trees that have no common ancestry (bzr-wise, but in the real world, they do), and "bzr merge" suggests that I can somehow do it anyway if I specify a base revision for the merge, but I don't see how to do that.
<spiv> soren: "bzr merge -r0..-1" will allow you to merge unrelated (bzr-wise) trees
<spiv> soren: because 0 is common to histories, in a sense.
<soren> Yeah, I was hoping that would be the case (0 being everyone's grandparent).
<soren> haha..
<soren> spiv: YEs, that seems to do the trick. Lovely. Thanks!
<awilkins> abentley:
<abentley> awilkins:
<awilkins> abentley: How easy would "parallel" support be in bzr-pipeline?
<abentley> awilkins: Not terribly hard, but if the parallels ever met, that would cause criss-cross merges.
<awilkins> abentley: I posted to the list about supporting something similar in loom ; the idea of having a web of patch branches that all converge on a single "work" branch, with UI assistance for committing the correct hunks to the appropriate branch
<awilkins> Like Mercurial pbranches (only they don't have that UI support)
<abentley> awilkins: If by converge, you mean A -> B -> C, A ->D -> C, that would be very, very bad.
<awilkins> abentley: Because each branch would be receiving the same merges from the base branch?
<abentley> awilkins: Well, let me think about this.
<awilkins> For reference : http://arrenbrecht.ch/mercurial/pbranch/
<abentley> awilkins: You get criss-cross when you merge in an inconsistent order, and thereby repeat the merge of revision X with revision Y in two places.
<abentley> awilkins: It may be that a pipeline can prevent that, but I'd have to think about it.
<awilkins> abentley: I have this mental picture of a commit dialog in qbzr where the patch is on the left and there is a radiobutton column on the right for each patch branch and you select which hunk goes where.
<abentley> awilkins: I've never been a fan of selective commit, but I can envision adding it to the uncommitted changes of that pipe.
<awilkins> abentley: Does each pipe have a working tree?
<abentley> awilkins: No, each pipe has a shelf.
<awilkins> abentley: That sounds like the implementation I had in mind ; shelve the changes and switch-unshelve-commit for each branch
<awilkins> abentley: I just don't have the time to actually write it though
<abentley> awilkins: I'm suggesting that the user would still commit the changes, rather than having it happen automagically.
<awilkins> abentley: I can see that working as long as you're not allowed to commit to a branch that depends on branches with shelved changes
<abentley> awilkins: I think that restriction would not be workable.
<awilkins> abentley: How do you cope with the scenario when you want to commit C, and B has changes in it's shelf ; the changes are presumably in the working tree of C also, and you've just committed them?
<kfogel> abentley: how can I tell if a given installation of bzr is built with the C extensions?
<awilkins> kfogel: Presence of .pyd files
<abentley> awilkins: It would be unusual for the changes to be in the working tree of C also.
<kfogel> awilkins: thank you.  where would they be?   (some python path on my system?)
<awilkins> abentley: I thought A -> B -> C ... doesn't that imply that the changes from B are in C and C may even be dependant on them
<awilkins> kfogel: They should be in the bzrlib folder
<kfogel> awilkins: thanks
<awilkins> kfogel: "lib" on Win32 bzr.exe, %PYTHON%/lib/site-packages/bzrlib for win32/python
<abentley> awilkins: No, it doesn't imply that.  When you want that to be true, you run the "pump" command.  That merges from A->B->C, but it doesn't do anything with uncommitted changes.
<awilkins> abentley: I'll have a play with bzr-pipeline for a bit and think some more
<awilkins> abentley: It sounds like I'm not totally grokking the way it work
<awilkins> abentley: Is there a good source of documentation besides the help? I've only found the launchpad page (after seeing it mentioned o the mailing list)
<abentley> awilkins: The way it works is, you're hacking on something in A, then you realize you need to fix B.  You switch-pipe B, which automatically stores the uncommitted changes in A.  You fix B and commit.  You switch-pipe back to A, which restores your changes.  You finish hacking in A.  You pump, which applies the changes in A to B, and the changes in B to C.
<abentley> awilkins: "bzr help pipelines" is the main documentation.  There's also a comparison with looms in pipeline-and-loom.txt in the source tree.
<kfogel> awilkins or abentley: if I have done a long-running 'bzr upgrade --2a' to get a tree to 2a format, and I *think* it completed (but for various reasons am not sure), is there some command I can run to verify, other than 'bzr info -v' ?
<awilkins> abentley: That help topic doesn't seem to be in the lp:bzr-pipeline trunk
<abentley> awilkins: Sorry, "bzr help pipeline"
<awilkins> kfogel: On the same topic, I've been running --2a conversions and getting segfaults on windows where it just fails silently, so I'm no help here
<kfogel> awilkins: ugh.  no useful trace?
<jam> Peng: I believe my mail host no longer allows direct emails from people, you have to go through official ISPs
<abentley> kfogel: bzr info -v won't tell you whether it's well-formed.  You would need to run "bzr check" for that.  (Which takes a verry long time)
<awilkins> kfogel: Just a minidump and an offset in the groupcompress extension
<kfogel> abentley: 'bzr check' time comparable to the original 'bzr upgrade' time?
<awilkins> kfogel: I'd make a trivial branch and upgrade it to 2a to see what the successful log output looks like
<kfogel> (because that was almost 4 days)
<abentley> kfogel: worse.
<kfogel> abentley: holy cow
<awilkins> abentley: Ok, it still sounds compatible with my intentions as long as the criss-cross merge is dealt with
<awilkins> abentley: Because you would actually be working in C, you know how the merged output should look because it's what you actually wrote, so does that make it easier?
<abentley> awilkins: I don't know what you mean by "you would actually be working in C".
<awilkins> abentley: You have pipes   A > B | D > C
<awilkins> So when you pump, changes in A are merged to B and D and then C
<awilkins> So you end up with two merge revisions being merged to C and they are a crisscross merge
<awilkins> If you are editing in C and your "chunk selective commit" has directed some changes to go to A, some to B and D (and none to C because it's just a convenient tip to amalgamate patches)
<abentley> A > B, D > C does not lead to a criss-cross merge.
<abentley> awilkins: Why would changes from B be merged into D?
<awilkins> abentley: Not from B to D
<abentley> That would be a linear pipeline of A > B > D > C
<awilkins> A to B and D
<awilkins> B to C, D, to C
<abentley> awilkins: So you really men A > B,  A > D > C?
<awilkins> abentley: And B > C also
<awilkins> Including an additional revision of changes to B and/or D
<abentley> awilkins: As long as the parallel lines don't merge from one another, I'm not sure that leads to a criss-cross.  But I still need to think about that.
<abentley> awilkins: In any case, if you pump from A, you're not necessarily "working in C".  That would only happy if conflicts were encountered merging into C.
<awilkins> abentley: I'm thinking ; edit with the lightweight checkout aimed at "C" ; commit chunks to A, pump
<awilkins> abentley: Because you're editing in a checkout of C, you know how the end state of the tree should look, so you either don't have conflicts or you know exactly how to resolve them before you start the merge
<awilkins> I'm not sure you don;t have conflicts 100% of the time
<abentley> awilkins: If you're in C and you pump, that will do nothing, because you pump from the current pipe to the following pipes.
<abentley> awilkins: If you're in C, you can't commit chunks to A.
<awilkins> abentley: Edit in C : special-multi-pipe-commit to A (shelve ; switch A ; commit ; pump)
<abentley> awilkins: You're now in A.
<abentley> Not working in C.
<awilkins> abentley: Automating this is what I'm driving at ; all the dancing up and down pipes handled in software
<awilkins> So after, switich to C (which got your changes merged upward by the pump)
<awilkins> So the intent is "I always want to work in a tree that looks like it would with all my patches applied, but I want to be able to commit to each of my patches separately"
<abentley> awilkins: I'm not in favour of committing changes to A without even having looked at A with those changes.
<awilkins> I agree that there is potential hairiness there
<awilkins> I think the add-to-shelf approach has merits too
<awilkins> It makes things a little less quick, but I agree it adds safety
<awilkins> My concern with it was that if you have a bunch of changes hanging around in a shelf, they are not committed in the branch you intend them for, they are in it's shelf. You may commit the changes to descendants of that branch ; not entirely a disaster because if you merge them from beneath later they are just a no-action merge.
<abentley> awilkins: I don't think it's likely that you would commit the changes to descendants of that branch.
<awilkins> abentley: Have you removed them from the tree when you shelved them to that branch?
<abentley> awilkins: yes.
<dash> hmm, i have not heard of bzr-pipeline before. is it a thing like loom?
<awilkins> abentley: So now your work cannot continue until you visit A and commit/pump yes?
<abentley> awilkins: Your work would only be unable to continue if all the changes you wanted to make depended on the shelved changes.
<abentley> dash: yes.
<dash> i've been using loom a lot this week
<dash> i've been wondering if something better was possible. :)
<awilkins> dash: Looks like you walked into the right discussion ; I'm likeing pipeline so far in that I have the impression that it implements the features of looms by manipulating standard branches (?)
<abentley> dash: As a contributor to loom and heavy user, I think something better is possible, and pipeline is my attempt to achieve it.
<abentley> awilkins: It does manipulate standard branches.  The feature parity is not exact, and that's deliberate.
<lifeless> pipeline is interesting; If I read the code right it has strong parallels to topgit
 * awilkins adds another mental bookmark to review
<lifeless> dash: have you been liking loom?
<dash> lifeless: Mostly.
<awilkins> lifeless: I've shied away from using it because of the stacked branches design
<dash> My use case lately has been dealing with code at work where a snapshot of a public SVN repository was taken, checked into a company-internal SVN repo, and both were modified independently for about three months
<dash> and now I am trying to reconcile the changes
<lifeless> awilkins: sit in top tree, commit to arbitrary 'patch' - thats a goal I have too, for both generic bzr and looms; but requries care because it is conceptually bad (committing untested code). Howver some folk really do want it
<dash> and, in particular, stratify them into independent patches
<awilkins> My use case is a software project in an SVN repo which I sync periodically
<awilkins> I tidy the code and document it and also write patches
<lifeless> dash: I find shelve very useful there
<dash> lifeless: yes. using shelve a lot too.
<lifeless> dash: commit -i and a split-commit command would be nice
<dash> yeah
<awilkins> But I don't want things to be dependant on each other (in terms of DAG)
<lifeless> anyhoo, its past midnight
<dash> shelve is a little awkward when dealing with 200+ diff hunks :)
<lifeless> -> sleep
<dash> I find myself alternating between diff-based and pack-based shelve
<awilkins> "conceptually bad (committing untested code)" ; I don't think committing untested code is bad, as long as it's plain you're not committing to a branch that will be shipped untested ; AFAIK the Bazaar development process handles this by testing merged revisions before it commits them and that's the place to be
<awilkins> EAch time I try pack-based shelve on win32 it's failed so far
<awilkins> The merges I've submitted to Bazaar have included revisions that definitely didn't pass testing because I separated the commits into one revision for the tests that exposed a broken feature, and one that fixed it.
<awilkins> But the merge revision is the one that counts for testing purposes
<dash> awilkins: yeah, that's the workflow i'm familiar with from svn
<awilkins> Anyway ; so, I want to be able to submit patches to my foreign SVN repo without cherrypicking out changes from branches lower in the loom
<dash> hm.
<dash> i'm not familiar with doing that
<dash> so far i've just used 'bzr diff -rthread:' to create patches to send in
<awilkins> dash: I created a branch from HEAD of trunk, cherrypicked the patch into it, and pushed it to trunk using bzr-svn
<awilkins> dash: Does each thread only list the changes it introduces when you do that or do you get the threads beneath it?#
<dash> it's the diff between the thread and the one below
<awilkins> I suppose that works, in a pinch
<awilkins> Doesn't account for diffs to things that were changed by the thread below with respect to trunk though
<dash> well right
<dash> but i've always envisioned a loom as a stack of patches
<awilkins> The topgit README also makes it sound like the feature I seek!
<awilkins> Yes, that's the thing that puts me off using it - I have no idea what order I want to put patches in
<dash> a diff against the bottom thread would include all the changes of the intervening thread
<dash> well, they have to go in some order :)
<awilkins> Yes, but I don't want to have to decide what order before I merge them, before I've even started writing them
<awilkins> TopGit readme is very dry and needs more pretty ASCII art like Mercurial pbranches
<abentley> awilkins: changing the order of pipes would not be easy, but it's theoretically possible.
<awilkins> abentley: Would that involve a lot of rebasing?
<abentley> awilkins: No.
<awilkins> abentley: I can't think of a way to do it without rebasing ... but now I have to go and pick my wife up from the station, so I'll think about it on the way.
<abentley> awilkins: Merging.
<awilkins_train> INcluding reverse merging?  (now I'm really gone)
<infinity> So... At the risk of looking like an idiot, has anyone else noticed bzr 1.16 spamming "unsupported locale" warnings when running under any locale other than en_GB.UTF-8 or C?
<infinity> (And yes, I have several other locales generated and usable by everything else)
<mneptok> infinity: WFM in Klingon. but then, i always challenge such error messages to personal combat with bat'leth.
<infinity> Reproduced here on an up-to-date karmic (times two), and a jaunty with the PPA 1.16 installed.
<infinity> To be fair, didn't test EVERY locale, but en_US and en_CA are both grumpy and both quite obviously working in other apps.
<radix> is there a way to apply shelved changes without removing them from the shelf?
<radix> I guess not, since there's no parameter that indicates that possibility.
<Tak> hmm, a `bzr branch` from an svn repo seems to have gotten me some ancient files
<radix> Tak: which don't show up in "svn ls <svn-branch>"?
<Tak> no, I mean they're not current
<radix> oh, I see
<Peng_> jam: Oh, OK. It was an ISP, though. A stupid cheapo shared host, but they still count. :D
<jam> Peng_: I don't really know the answer, but I've gotten similar messages emailing vila from my home machine
<jam> I had to proxy through my ISP to get it to work
<jam> I don't know why they would reject you
<Peng_> jam: Well, okay. Anyway, I just wanted to alert you if necessary. :)
<jam> I didn't want your email anyway :)
<jam> I'm just hiding behind my mail host
<Peng_> Heh.
<jam> LarstiQ: I don't see jelmer around, but I had a question about what I should be bundling in the win32 installer
<jam> jelmer mentioned something about changing bzr-rebase => bzr-rewrite
<jam> and I don't really know what the latest versions of
<jam> rebase/rewrite, svn, subvertpy etc are
<jam> any ideas?
 * Peng_ runs them all from source. :P
<Peng_> s/source/bzr/
<jam> *arg***
<jam> It seems the project is now called "bzr-rewrite"
<jam> but the *tag* is "bzr-rebase-0.5.1"
<jam> bad jelmer, no biscuit
<jam> ah well, I can cheat easily enough
<kirkland> when using bzr export ../foo.orig.tar.gz ... is there any way to --exclude a file from being exported?
<jam> hmm... seems "cd bzr-rewrite; py setup.py install" still installs itself as 'rebase' as well.
<jam> weird
<Peng_> jam: FWIW, I still call it "bzrlib.plugins.rebase" and it doesn't mind, so maybe you should stick with rebase for now.
<Peng_> jam: Obviously it would be best to ask jelmer. :D
<jam> yeah, I'm sticking it where it wants to be
<jam> just seemed wrong
<jam> probably just an incomplete conversion at this point
<Peng_> Stupid question: Have enough 2a bugs been fixed that it's reasonably to dogfood it, and interact with different formats over the network?
<bpierre> hi
<rellis__> Anyone know what the right path is to obtain loggerhead 1.2.1?
<Peng_> ...1.2.1? Isn't that from the 1990s?
<rellis__> yeah im thinking the same
<Peng_> Why?
<rellis__> my boss asked me to do this so im sort of flying blind
<rellis__> disregard my question
<Peng_> Wouldn't you want something...modern?
<rellis__> yeah indeed i do
<rellis__> i want absolute current
<Peng_> rellis__: bzr branch lp:loggerhead :D
<rellis__> hehe alright
<rellis__> thanks
<Peng_> Guaranteed to partially work at least 14% of the time!
<rellis__> what more could i ask for?
<flvr8> does 1.16 work more than 14% of the time :) ? we're seeing a couple bugs with 1.10
<Tak> upgrading to 1.16 seems to have fixed my issue with the svn branching
<rellis__> Tak: Do you know the path to checkout 1.16 specifically?
<rellis__> or is it just trunk?
<Tak> eh, I used the release download
<rellis__> huh i missed that on the site i guess
<Peng_> OK, are we talking about Loggerhead or Bazaar now?
<rellis__> loggerhead
<rellis__> yeah that's exceptionally confusing =p
<Peng_> rellis__: 1.16 hasn't been released yet. It's just the trunk.
<rellis__> okay nifty
<Tak> oh, yeah, I'm talking about bzr, sorry
<Peng_> flvr8: Are you talking about Loggerhead or Bazaar? If LH, which bugs? Have you filed reports?
<rellis__> np :)
<Peng_> The trunk has a tendency to randomly break sometimes (cough test suite cough), but it fixes lots of things.
<flvr8> peng - loggerhead as well. (i work with rellis). haven't yet filed a bug, but when we browse to one of the repositories we get an error (for which i haven't yet filed a bug):
<flvr8> An unexpected error occurred whileproccesing the request: KeyError: ....
<Peng_> flvr8: I think some KeyErrors have been fixed, but my memory is fuzzy.
<flvr8> ok, we'll check out trunk and see
<Peng_> I know an *IndexError* was fixed a while back, but that bug was introduced in the trunk. :P
<rellis__> So  bzr branch lp:loggerhead should give me current 1.16 development work right?
<rellis__> The readme says 1.10 so it's a little confusing..
<Peng_> rellis__: Yeah. Seems nobody updated the version number
<rellis__> fair enough :)
<rellis__> Peng: I'm seeing ImportError: No module named main trying to fire up the new serve-branches from trunk... do i need to install some prereq's?
<Peng_> rellis__: Yeah. See the README. Uh, Paste, SimpleTAL and simplejson (on Python <2.6) are the necessary ones.
<rellis__> hmmm thought i had those
<rellis__> i'll reverify
<Peng_> rellis__: Oh, crap. I didn't see the "main" bit.
<rellis__> yeah that threw me
<rellis__> made me think it was something internal
<Peng_> rellis__: It is. ISTM serve-branches is finding an old copy of the "loggerhead" package.
<rellis__> ahh gotcha
<rellis__> hmmm
<sanjays> Hi
<sanjays> looking for a seeming python dependency issue at Loggerhead / Bzr
<rellis__> When I try to use loggerhead against one of my projects I get this error.. KeyError: 'someguy@somebox-20090314122230-5ds8oco7g27p9ukx'
<rellis__> any idea what causes this?
<rellis__> This is the full error from the loggerhead log file.. http://www.pastebin.ca/1475807
<Peng_> sanjays: Aye?
<sanjays> ya
<Peng_> sanjays: What's the issue?
<sanjays> had a particular problem with loggerhead as frontend  of BZr repository
<sanjays> after import by developers it cannt show the trunk
<sanjays> i will tell u the exact error if that helps
<Peng_> rellis__: That error isn't familiar to me. Upgrading is all I can suggest.
<rellis__> fair enough peng
<rellis__> it's the same erro sanjay's refering to
<Peng_> Oh.
<rellis__> Peng would you expect the python module for loggerhead to still register as 1.10 like the readme file?
<rellis__> We did a trunk checkout then installed and we see 1.10 listed everywhere..
<Peng_> rellis__: Yeah, it still thinks it's 1.10.
<rellis__> cool
<jh> hi, I did a 'bzr pull --overwrite' and get a text conflict... how is that possible?
<beuno> jam, hi
<beuno> still around?
<beuno> I've got an interesting traceback where check blows up, and reconcile finds nothing
<beuno> https://pastebin.canonical.com/19049/
<beuno> lifeless, maybe you're around and bored on a saturday ^
<beuno> I'm probably going to file a bug, but I'd like to see what's interesting to add to the bug info
<jam> beuno: yeah
<jam> was afk for a bit, though :)
<beuno> jam, filed as 392698
<jam> bug #392698
<ubottu> Launchpad bug 392698 in bzr "bzr 1.16 blows up on upgrade or check" [Undecided,New] https://launchpad.net/bugs/392698
<jam> beuno: and it dies on upgrade as well?
<jam> at least it looks like you have a missing text in your repository
<jam> the inventory wants "(file_id, revision_id)"
<jam> but the repository says "I don't have that"
<jam> AFAIK, there isn't much reconcile can do
<jam> as it can't *create* the file for you
<jam> now, if we have the sha1 sum, we could probably fake it
<beuno> jam, it dies on both upgrade and check
<beuno> it's odd that *this* branch is broken, since there hasn't been anything fancy done to it
<beuno> I'm less interested in fixing it, and more in debugging why it happened
<beuno> it's history isn't terribly important to me
 * beuno is in the process of upgrading the remaing ~60 branches at the office to 2a
<beuno> only that branch failed up to now
<beuno> and it has to be something that happened from 1.9 to now, which I upgraded a few months ago
<beuno> so it's a bug in bzr 1.13+
<jam> beuno: see my comment
<jam> It was probably a bug in a really old version
<jam> that generated a slightly bogus inventroy
<jam> and bzr 1.12 or so wouldn't have fetched the data properly
<jam> to handle the really old problem
<jam> 1.13+ should handle it more correctly now
<jam> I'm not 100% sure when the fix landed, but the fix was written by lifeless at rev: robertc@robertcollins.net-20090310065003-a57qlol97z6ohczi
<beuno> jam, so is there anything I can do to provide useful information here?  or just delete, init, and move in with life?
<beuno> *on
<jam> beuno: I have a theory about what happened, but it is pretty difficult to prove or disprove...
<jam> beuno: is this a branch with a separate repository?
<jam> It might be interesting to see what "bzr log -r revid:'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo'" says
<jam> or even "bzr log -v"
<jam> or bzr log -v --show-ids
<jam> to see if 'wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75' was modified in that rev
<beuno> jam, it's a standalone branch
<beuno> let me try that...
<jam> beuno: do you have more branches of this project?
<jam> Note that the dates are ~ the same
<beuno> jam, probably not anymore, no. It hasn't been touched in a while, so developers likely deleted them locally
<jam> and that -75 means this was the 75th file to be added in this commit
<jam> which means it sounds a lot like something that was approximately the initial commits
<jam> Amazing what info you can glean from non-random revision ids :)
<beuno> bzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')
<jam> beuno: interesting, sounds like a ghost rev then
<jam> wonder how that happened
<jam> beuno: there is something weird about 200705250025002205
<jam> are you sure that was cut & pasted correctly?
<beuno> yeap
<jam> 2007-05-25 00:25:00: 2205
<beuno> KeyError: ('wiki_icon.gif-20070525002152-lu3yrapgr7a4d8dp-75', 'martin@pentacorp.net-200705250025002205-ybn9m9tqnxu122qo')
<jam> still too many digits
<beuno> bzr log doesn't blow up
<jam> 2009-06-26 18:03:31
<beuno> bzr revision is from 2007-07-11
<jam> 20090626180331
<jam> 20070525002152 => 20070525002152
<jam> 2007-05-25 00:21:52
<beuno> neither does bzr log -v -n0
<jam> looks like we generally used date to seconds
<jam> which would be:
<jam> 2007-05-25 00:25:00
<jam> or
<jam> martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo
<jam> beuno: can you try "bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo" ?
<beuno> jam, I can upload the repo for you, it's private-ish, but not critical, so it's ok for you to look at it
<jam> beuno: devpad would be fine
<beuno> malbisetti@pentaserv:/var/www/ellatinoamericano$ bzr log -v --show-ids -r revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo
<beuno> bzr: ERROR: Requested revision: u'revid:martin@pentacorp.net-20070525002500-ybn9m9tqnxu122qo' does not exist in branch: BzrBranch7('file:///var/www/ellatinoamericano/')
<jam> beuno: alternatively "bzr log --long --show-ids | less" and search for 22qo
<jam> but I can do that
<jam> I want to know who this latin american is... so yes, please upload :)
<beuno> heh
<jam> alternatively, create a tarball, gpg sign it to my pub key
<jam> and upload it wherever you want
<beuno> it's about 14mb
<beuno> uploading...
<beuno> it should be about 6 minutes
<beuno> jam, https://devpad.canonical.com/~beuno/ellat.tgz
<beuno> jam, I'm also curious as to why it failed now, and not when I upgraded it to 1.9
<jam> beuno: upgrade to 1.9 doesn't do much but change the indexes, IIRC
<jam> as in, it doesn't have to check every text, etc
<jam> it just rewrites what is there to be a btree rather than a KnitIndex
<jam> beuno: *especially* if you used the fast-path writer that I had written
<beuno> ah
<beuno> I didn't
<beuno> but I see what you mean
<jam> beuno: it is also possible that the upgrade itself is the part that broke things
<jam> it just didn't care that the text was missing
<jam> beuno: I get "not in gzip format"
<jam> is it encrypted?
<jam> or is it bzip2 ?
<beuno> uhm, no, should be tar.gz
<beuno> argh
<beuno> seems broken
<jam> it is just tar
<jam> no gz
<beuno> did you manage to unpack it?
<jam> beuno: "tar xvf ellat.tgz" worked
<beuno> cool
<beuno> I missed a flag then  :)
<mzz> I think I've had firefox automagically decompress things for me when downloading from some servers. I tend to just always use "tar xf" to extract, modern versions of gnu tar don't need the j or z flag, they autodetect if you omit
<jam> beuno: something very weird
<jam> ah just a sec
<jam> missed a flag
<jam> forgot you now need -n0
<beuno> yeah  :)
<jam> beuno: so something very strange after all
<jam> according to 'bzr log' the first revision is
<jam> 2007-07-11
<jam> but your error is on a file with
<jam> 20070525
<beuno> ha
<jam> and a commit around
<jam> 20070525
<jam> so somehow your branch has a revision that existed... 1+ months before the branch
<beuno> well, FWIW, that branch was re-inited at some point due to breackage
<beuno> but the bzr dir was probably killed, and init + added everything
<beuno> maybe someone merged it in that had the old branch?
<jam> I do see a revision present:
<jam>  ('martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo',),
<beuno> it wouldn't of let them I guess, since there's no common ancestors
<jam> which probably isn't in the ancestry of the branch
<jam> but is present in the repo
<beuno> this is getting stranger as we go  :)
<jam> beuno: so I can do "bzr branch -r revid:'martin@pentacorp.net-20070525002205-ybn9m9tqnxu122qo' . ../ellat2"
<jam> and then I see
<jam> $ bzr log ../ellat2/
<jam>     1 Martin Albisetti  2007-05-24
<jam>       inicio
<jam> so *my* guess is that *you* are responsible :)
<jam> beuno: and if I look at "bzr log -v --show-ids" for that revision
<jam> I also see what I expected
<jam> namely, the file
<jam> the file-id matches
<jam> only notice that the revision id is different than what you gave as an error
<jam> 2007 05 25 00 22 05
<jam> where you had 2007 05 25 00 22 00 ...
<beuno> heh, it was 2007, I was doing all kinds of crazy things (?)
<jam> beuno: I see the same error
<beuno> wooo, finished upgrading all branches, that was the only one that exploded
<beuno> pretty impressive considering we've been using bzr since 0.12
<jam> beuno: so my guess is that the original commit was bogus
<jam> which is why you started over
<jam> if you do "bzr branch ellat ellat2"
<jam> you should probably be able to upgrade ellat2
<jam> as it will have pruned out the bogus revision
<beuno> cool, easy peasy
<beuno> is there anyway reconcile could tackle this in the future?
<beuno> jam, you're right
<beuno> oddly enough
<jam> beuno: so... something still strange. In that I get the same failure
<beuno> check finds 81 revisions on the borked one
<jam> but I don't see any way yet for it to occur.
<beuno> and 57 on the branched one
<jam> so maybe it is a different rev which is broken
<beuno> jam, upgrading went fine on the newly branched one as well
<beuno> the 81 vs 57 revs is intriguing
<jam> beuno: anyway, I'm off for now
<jam> but I find the bogus text in the inventories of 20 revisions
<jam> beuno: https://pastebin.canonical.com/19053/
<beuno> jam, cool. Hope it helps at all, and thanks for the workaround
<beuno> have a nice weekend
<jam> which is probably the 20 or so that aren't in the branch anymore :)
<abeaumont> vila: ping
<lifeless> beuno: ?
#bzr 2009-06-27
 * SamB wishes bzr-gtk packages could depend on bzr in a way that reflected the API version they require from it
<SamB> ... I think they could do a bit better than "bzr (>= 1.12~)", though
<Peng_> beuno: Upgrading your branches of Loggerhead to 2a, or just other stuff?
<glyph> jml: erm
<glyph> jml: I think maybe there's a problem with the latest release
<glyph> http://codepad.org/lxIt1U1g
<glyph> oh
<glyph> whoops, is this exactly what SamB is talking about?
<SamB> glyph: say ... what ?
 * SamB looks
<SamB> glyph: oh, not exactly
<SamB> I did get that one a few days back though, I think
<SamB> so I guess it's probably just that my bzr knows it doesn't provide that version of the API and yours doesn't know?
 * SamB wonders why python-dulwich wants to reinstall Python 2.4 for him :-(
<rellis__> Is there a convenient way to have bzr execute an arbitrary shell command after a commit to a given project/branch?
<SamB> rellis__: there's some shell-hook plugin
<SamB> see the plugins page on the wiki
<SamB> should be listed there
<rellis__> nice
<rellis__> thanks much sir
<SamB> you're welcome
<SamB> I don't have a clue why that's not integrated with bzr ...
<Peng_> Propose it for merging in bzr 2.0! :D
<rellis__> So bzr plugins i.e. shell-hooks run on developer machines not my bzr server right?
<rellis__> i should say they run wherever the bzr command itseld is executed
<SamB> rellis__: well, unless you install the plugin on the server and the plugin provides hooks of a kind that would get run as part of the smart-commit process
<rellis__> hmmm
<rellis__> im trying to integrat hudson with bzr
<rellis__> and the hudson bazaar plugin doesnt work with hudson slaves
<SamB> hmm ?
<rellis__> so i need a different mechanism to launch builds after commit
 * SamB wishes jelmer were about so he could complain about this python2.4 dependancy on the python-dulwich package
<resolve> hi folks. i'm new to bzr, and I just pushed a branch to lp, commited a change, and pushed again, and I end up with a "stacking branch"
<resolve> which appears as a separate entry in launchpad. I just wanted to push my latest changes. is push the wrong command?
 * SamB remembers he can file debbugs even if he knows where the maintainer hangs out on IRC ...
<SamB> resolve: did you push to a different name the second time ?
<resolve> ah. what happened is my first push was to name x, but I made a typo so deleted and specified name y
<resolve> i thought it would remember name y but it remembers name x
<SamB> resolve: bzr push --remember y
<resolve> thanks. all good now.
<beuno> lifeless, Peng_, other stuff. Branches from the office
<beuno> all cleared by jam now
<Peng_> I kind of want to upgrade my Loggerhead repo to 2a, just for "fun", but I can't since I have a corrupt revision. :D
<beuno> I think we should upgrade to 2a
<beuno> it should be easy since we're in rich-root already
<Peng_> LH itself is still compatible with bzr 1.13. The 2a format isn't. :D
<Peng_> Eh. I'm just reluctant to upgrade because I'd have to move to a new repo.
<lifeless> beuno: you should be able to locally
<lifeless> beuno: just init a new 2a repo and branch in any lh branches you want
<bignose> I'm attempting to migrate a CVS repository to Bazaar
<bignose> (a particular branch in that repository, anyway)
<bignose> I've used cvs2git (from the cvs2svn project) to create two separate files
<bignose> a dump file and a blob file
<bignose> what do I need to use to import those into a Bazaar branch?
<lifeless> bzr-fast-import
<lifeless> thought IIRC it wants inline format
<bignose> âbzr fast-import foo.fi-blobâ succeeds but says there are no revisions
<bignose> âbzr fast-import foo.fi-dumpâ crashes with a traceback
<bignose> neither of them seems to create any branch
<beuno> lifeless, right. Maybe I should just do that.
<beuno> now, if only bzr moved to 2a as well
<beuno> I could have a shared repo again in the bzr-devel dir  :)
<wgrant> How's the Launchpad 2a trial going?
<bignose> ah! on the cvs2git web page it suggests the two can simply be catted together and fed to git as a stream. should that work too for bzr fast-import ?
<beuno> wgrant, much better than expected, although there are some stacking bugs that still need ironing out
<beuno> it's amazing how much faster it is
<lifeless> bignose: I guess :)
<bignose> cat foo.fi-{blob,dump} | bzr fast-import -
<bignose> that worked fine
<wgrant> beuno: I guess you have many tens of thousands of revisions?
<bignose> maybe someone could look at <URL:http://cvs2svn.tigris.org/cvs2git.html> and update <URL:http://bazaar-vcs.org/BzrFastImport> to connect the two
<bignose> (someone with an accounton the wiki, that is.)
<beuno> wgrant, I think it's around 60k
<bignose> the help for merge says:
<bignose>   By default, bzr will try to merge in all new work from the other
<bignose>   branch, automatically determining an appropriate base.  If this
<bignose>   fails, you may need to give an explicit base.
<bignose> but doesn't say how to "give an explicit base"
<bignose> any clues?
<james_w> -r
<james_w> "-r 7" will merge in just up to revision 7, "-r 7.." will use 7 as a base, "-r 4..7" will cherry-pick
<bignose> okay. and those revision numbers are for the other branch, yes?
<james_w> correct
<bignose> hmm. okay, it seems I need to hack a bit.
<bignose> I originally grabbed a source tarball, imported those files into a new branch, and committed revision data from that point on
<bignose> subsequently, I have gained access to the upstream CVS repository, and have imported that history to a different branch.
<bignose> but of course as far as Bazaar is concerned, the two branches share no ancestor.
<bignose> how can I best tell Bazaar that the head of the CVS-imported branch represents the origin of the from-scratch Bazaar branch?
<bignose> so the history is intact and consistent
<bignose> james_w: thanks for the assistance
<bignose> probably what I want to do (convince Bazaar that one file imported separately in two different histories are actually the same file) can't be done
<lifeless> what you need is a form of history editing
<lifeless> the fast-import could in principle be done to match the file identities of your tarball branch
<lifeless> two ways to do that: have an option to fast import 'get-ids-from-<branch>'
<lifeless> -or-
<lifeless> do a transform on the result of the fast-import branch
<bignose> interesting
<lifeless> a longer term solution is for us to support file copies
<bignose> well, I encounter this use case not infrequently, so I suspect others would as well
<lifeless> because the symmetry there gives file joins as well, and then you can just tell bzr after the fact 'oh, this became that'
<bignose> yes.
<bignose> that's exactly the place my mind was at after merging with a specified base
<lifeless> yah. its important to me
<lifeless> but not top of the stack yet, sadly.
<bignose> all the files got moved out of the way, and I wanted to say "no, each one of these became one of those"
<bignose> okay, that's good enough for me
<bignose> thanks for the insight into upcoming features :-)
<poolie> hello all
 * bignose checks the weather in Sydney
<poolie> are you in sydney bignose?
<poolie> it's kind of grey
<bignose> Melbourne
<bignose> you two (poolie and lifeless) visited my workplace a while back
<bignose> Cybersource
<bignose> now home to a raving mob of Darcs pushers :-/
<dash> man, darcs.
<bignose> man: No manual page for darcs.
<dash> yes exactly
<bignose> speaking of which, does anyone have any good *canonical* references for
<poolie> jam, i'm trying to work out kerguelen for you
<bignose> speaking of which, does anyone have any good canonical references for manpage *roff markup?
<poolie> i can't recall where it is but there's some documentation in the man library for groff/troff
<poolie> man 5 something
<bignose> but is that specific to Linux only? I'm curresponding with someone who wants to know more Unix-wide conventional practice.
<poolie> well, the location of the manual is gnu-specific
<poolie> i think the syntax is fairly standard
<poolie> jam, kerguelen works for me
<lifeless> poolie: look at the calendar :)
<lifeless> in other news, why does evolution hate me
<poolie> lifeless: give me another clue?
<poolie> are you saying it's too late for john? i'm not counting on him talking back :)
<lifeless> poolie: no, just that its saturday:)
<lifeless> sunshine; people; loife!
<lifeless> or liff
<lifeless> my laptop fan has died
<lifeless> :(
<lifeless> poolie: I'm trying to encourage you to stop working, to shore up my failing willpower to also stop workingish
<poolie> ah ok
<poolie> just trying to keep him unblocked
<poolie> though, since it's now friday night it's moot
<cyberixae> What does --fixes do?
<Peng_> cyberixae: Adds a little meta data saying "this revision fixes bug X".
<cyberixae> How can I see that metadata?
<cyberixae> I mean I'd like to verify that it succeeded
<Peng_> cyberixae: Well, you could use "bzr cat-revision". Recent (trunk) versions of Loggerhead also show 'em.
<cyberixae> thanks
<jam> poolie: kerguelen worked ok, I got the packages built
<jam> It just took a while
<jam> didn't work in the morning
<jam> worked by the afternoon
<bignose> I'm vaguely aware of discussion about tags not surviving some operations
<bignose> what's the status of that?
<bignose> and what should I read to know which operations do or don't preserve tags?
<SamB> bignose: apparently, patch queue managers tend to eat them
<Peng_> bignose: It's not like they get eaten; PQM just doesn't/didn't propagate them to the target branch.
<bignose> so if I branch, or checkout, or merge; do the tags come across with the revision data from the other branch?
<bignose> (obviously checkout, forget that one)
<Peng_> bignose: Yes.
<bignose> thanks.
<bignose> according to âbzr tag --helpâ:
<bignose>   Tags are stored in the branch.  Tags are copied from one branch to another
<bignose>   along when you branch, push, pull or merge.
<Peng_> bignose: There isn't some huge tag problem. It was one bug in PQM that (according to someone in that thread) was fixed.
<bignose> good enough for me.
<bignose> Peng_: okay, that puts it in context.
<bignose> thanks again.
<Peng_> bignose: The discussion was also about how PQM makes tagging difficult. You can only tag a revision after it's created. In PQM's case, you usually want to tag the revision created by PQM. If you don't have direct write access to the branch, this means you have to put the tag in some other branch that PQM merges in the future. Kind of a pain, no?
<Peng_> Hmm, pqm-submit could tag some --tag argument.
<AfC> Any of the bzr viz hackers here?
<abosamoor> Hi, do you know website that offer hosting for code with bzr for proprietary code ?
<lifeless> abosamoor: launchpad can do that
<abosamoor> lifeless: your code must be an open source to host it on lp, is not it ?
<lifeless> for free hosting, yes
<abosamoor> lifeless: I want free hosting using bzr for closed source project
 * garyvdm is at a package jam updating qbzr in karmic!
<LarstiQ> jam: I don't know about rebase, but for bzr-svn and subvertpy 0.6.2 and 0.6.8 afaik
<mathrick> hiya
<mathrick> is it possible to ignore a versioned file?
<mathrick> ie. there's an editor's project file, and while it's useful to keep its contents, it's completely boring for the purpose of bzr diff
<ddaa> AFAIK, it's not possible.
<ddaa> You can approximate it with a plugin.
<ddaa> If
<mathrick> aha, is there one that already provides that?
<ddaa> I guess, if you go as far as writing your own custom branch format, you might even get transparent support in third party tools, such as "bzr vis".
<ddaa> mathrick: not as far as I know.
<mathrick> hmm, that's kinda extreme though
<mathrick> ok
<ddaa> The alternative is to make it a simple add-on, but then you need to modify bzr vis etc. to support it.
<mathrick> right, but just making diff shut up is enough to cover the 90% case
<ddaa> That should be a pretty straightforward plugin. Maybe a hundred lines of code.
<ddaa> (upper bound)
<mathrick> yah, I expect it to be simple to do
<mathrick> and a different question, albeit plugin-related
<mathrick> who wants to help me implementing git's rebase --interactive functionality (ie. retroactive history shaping)?
<mathrick> I'm not exactly sure where to begine
<mathrick> *begin
<LarstiQ> mathrick: I'm happy to us the template solution for that usecase
<mathrick> what template solution?
<LarstiQ> mathrick: versio foo.template, for local use copy foo.template to foo, and ignore foo
<mathrick> but it's useful to keep the changes that happen to the file
<mathrick> it's just not interesting to see that in diff by default
<LarstiQ> right, but to me this is a good way of handling it with what's there
<LarstiQ> mathrick: alternative is to symlink it to something else
<LarstiQ> mathrick: and then version it in a different branch
<mathrick> that loses the connection between changes then
<mathrick> the template is good when you have files that rarely change and are edited by hand mostly
<mathrick> not so much for automatically generated and managed foo
 * LarstiQ nods
<flvr8> hi...both loggerhead and trac-bzr fail on the same repository (which we migrated from svn). however, the repository branches check out just fine. the error that both loggerhead and trac-bzr give is KeyError: ...
<flvr8> is there a way to fix that in the branch?
<LarstiQ> flvr8: you could try `bzr reconcile` (as rather general advice)
<flvr8> heh, yeah that crapped out with a KeyError too
<flvr8> i'm trying an svn -> git -> bzr run on the module. that fixed my problems with one of the others
<cyberixae> Btw
<cyberixae> my actual use case
<cyberixae> I needed to find out whether some one already did --fixes
<cyberixae> in the end I had to ask him
<luks> you could have used bzr qlog
<cyberixae> glÃ¸g?
<cyberixae> bzr: ERROR: unknown command "glog"
<luks> well, I said qlog, not glog
<luks> but you would need to have qbzr installed
<cyberixae> oh
<luks> it has an option to search by bug number
<cyberixae> ah
<cyberixae> thanks
<cyberixae> doesn't seem to have that feature
<cyberixae> maybe Ubuntu has an old version
<thewrath> wats going on with this bzr stats plugin
<jelmer> thewrath: what about it?
<thewrath> trying to get this done for bzr
<thewrath> http://www.statsvn.org/
<thewrath> i have bzr here at work we have svn
<thewrath> ?
<thewrath> jelmer: you still around
<thewrath> i have a questiona bout creating my own bzr server
<flvr8> yep, svn -> git -> bzr fixed my KeyError problem
<flvr8> it seems to be a safer migration path
#bzr 2009-06-28
<Raim> hi
<Raim> what should I do if bzr instructs me to run 'bzr upgrade' but then it tells me that it is already at the latest format version?
<Raim> see http://pbot.rmdir.de/c09c1e95ebc98ddbc7148e2c3a228cc8
<Peng_> Raim: It's telling you to upgrade http://code.bitlbee.org/bitlbee/
<Peng_> Damn LF.
<Peng_> Raim: , not your local repo.
<Raim> Peng_: ah!
<Peng_> Actually, it's telling you to upgrade http://code.bitlbee.org/.
<Raim> yeah, I understand
<Raim> and by reading the message again it even said exactly that
<Peng_> Unless you actually run code.bitlbee.org, you can't fix it, but it does encourage you to send them an email, and it helps explain why you'll have awful performance pulling from that repo. :"D
<Peng_> s/"//
<itistoday> hi there, i'm new to bazaar and DVCS in general, was wondering if someone could help explain to me what the difference between 'pull' and 'merge' is?
<mzz> that had better be in the manual, it's kinda important
 * mzz checks
<mzz> itistoday: "pull" either turns the branch you're running it in into a copy of the branch you're pulling from (while keeping any uncomitted changes) or complains if it can't do so because you have committed changes that aren't in the branch you're pulling
<flvr8> it isn't explained well in the user guide, but the man page has a good concise summary (i.e. man bzr)
<mzz> itistoday: "merge" should only be done on a branch with no uncommitted changes and combines anything you've committed with anything in the branch you merge that you don't have yet, after which you get to review the result and commit it if it makes sense
<mzz> weird that this isn't explained properly in the manual, imho it's kinda important to understand the difference
<itistoday> thanks, although sorry, i'm still a little confused... so first, for both 'pull' and 'merge' you need to have an existing branch to run the command from?
<mzz> itistoday: it is important to realise that merge is normally done in a clean working dir, and you need to commit the result if it makes sense. "merge" always creates a brand new revision nobody else has yet, even if the resulting text is identical to some revision that already exists. pull fast-forwards, you don't add any revisions other than what you're pulling in.
<mzz> yes, both pull and merge need two branches
<itistoday> so... I'm assuming the answer to this is 'no', but is then 'pulling' simply merging and then committing? if no, then what's the difference?
<mzz> itistoday: if in doubt pulling if you can and merging if pull complains will often work, but in some workflows you may want to explicitly commit a merge even though a pull would be possible.
<mzz> itistoday: pull does not create any new revisions that aren't already in the branch you're pulling. after merge you always have to commit the result (even if there are no conflicts)
<mzz> itistoday: (this also means that you can merge and then revert if you did not like the result. With pull you'd have to remember the previous revision yourself to be able to do that)
<itistoday> mzz:  thanks, kinda getting it, still have more questions tough, so then is 'pull' as if you were to remove your entire local branch and use the 'branch' command?
<mzz> itistoday: yep
<itistoday> ok... that makes a whole lot more sense
<mzz> itistoday: but only if you don't have any revisions locally that aren't in what you pull. If you do it'll complain that the branches have diverged.
<mzz> itistoday: so other than that you can't easily undo it if you don't quite remember what the previous revision was, and assuming no *uncommitted* local changes, "pull" is quite safe
<itistoday> mzz: does that mean: local branch must have a revision number less than the one from where you're pulling?
<mzz> itistoday: revision numbers in bzr confuse me. You'll have to read the manual for that one.
<itistoday> i guess that was a bad question, but essentially does that mean that you cannot have made any changes to the branch you have that are not in the one you're pulling from?
<mzz> itistoday: (what if you committed one extra revision and you're pulling from a branch that has two (unrelated) new revisions?)
<mzz> itistoday: no *committed* changes, yes.
<mzz> itistoday: "pull" will attempt to keep uncommitted changes (just like "up" does in things like svn and cvs)
<itistoday> ok, cool :-) i think i get pull now
<itistoday> thanks!
<mzz> itistoday: actually so will merge, but using that is usually a bad idea, since it means it's hard to tell which changes are part of the merge and which are yours!
<itistoday> that was going to be my next question
<itistoday> so you can merge when you have uncommitted changes?
<Peng_> By default, merge yells at you if you have uncommitted changes. You have to pass --force to do it.
<mzz> ah, I didn't know that.
<itistoday> Peng_: thanks! What does the --uncommitted option mean?
<mzz> (because I'm pretty good at making sure I have no uncommitted changes before merging myself)
<itistoday> --uncommitted: "Apply uncommitted changes from a working copy, instead of branch changes."
<itistoday> does that mean only grab the uncommitted files from the place you're merging from?
<Peng_> itistoday: Yeah.
<Peng_> itistoday: That merges the uncommitted changes in the source branch's working tree into yours, instead of merging the new revisions and ignoring the working tree.
<itistoday> that's really weird
<Peng_> It's really useful.
<mzz> I don't think I've used that, but that's my fault.
<itistoday> i'm sure, i'm just new to this entire thing, it's all fascinating to me
<Peng_> Say you're making some changes in a branch, but then decide they should be in a new branch. Do "bzr branch", "bzr merge --uncommitted", and then "bzr revert" in the source branch. Bang!
<mzz> I think I'd usually end up just committing those uncommitted changes to the other branch, then merging regularly.
<mzz> ah, that's actually useful.
<itistoday> Peng_: great example! thanks
<mzz> although unsurprisingly there are other ways to do that :)
<itistoday> so, one other thing regarding pull.. in the user's guide part 6.2.3:
<itistoday> 6.2.3   Refreshing a mirror branch
<itistoday> "Use the pull command to do this:"
<itistoday> cd trunk; bzr pull
<itistoday> that seems to be similar to 'update'
<itistoday> what's the difference?
<Peng_> itistoday: Pull is about branches, while update is about working trees.
<itistoday> ok, the terminology still hasn't stuck quite yet, is this right: pull is more granular than update? i.e. update does it for all the branches..?
<mzz> "up" becomes important if you have working trees and their corresponding branch in different locations.
<Peng_> itistoday: Pull is "copy new revisions from branch X to Y". The pull command also implicitly runs "bzr update". Update is "update my working tree with new changes in branch X".
<itistoday> Peng_: does 'new revisions' there mean the 'history' from branch X to Y?
<mzz> sounds right to me
<itistoday> and then 'update' takes the latest history and makes it visible to the file system for you to work?
<Peng_> itistoday: Yeah.
<mzz> yep
<itistoday> awesome! thank you both very much for helping explain this :-)
<mzz> itistoday: if this is just the result of "bzr branch" (aka "get") you'll end up with working tree and branch in the same spot, and won't have much use for "update"
<mzz> itistoday: but there are ways to get the branch revision updated that don't automatically update the working tree afterwards, in which case you'll need "update". It'll probably be obvious once it happens.
<mzz> err, branch history, not revision
<mzz> "bzr help working-trees" mentions a few, I think
<itistoday> mzz: thanks, i'll keep that in mind
<itistoday> i looked over a quick git tutorial, it seems to take a different approach with where branches are stored, i.e. it seems like the entire folder contains the repository
<mzz> does someone know if there's a plugin I overlooked that automates creating a new branch for a lightweight checkout and switching to it?
<mzz> itistoday: I haven't used git much, but see 10.2.5 in the manual
<mzz> I use a variation of that setup: my lightweight checkout isn't below the repository.
<itistoday> mzz: k, reading...
<mzz> I'm looking for a more convenient way to do the "bzr branch ...", "bzr switch ..." mentioned there.
<mzz> perhaps I should just write a plugin.
 * mzz throws together a "relswitch" plugin
<flvr8> is there a generalized way to create server aliases, a la "lp"?
<mzz> flvr8: I just came across the "bookmark" plugin, which may do what you want
<flvr8> thanks, will take a look
<Peng_> flvr8: Better than writing Python code, you mean?
<flvr8> Peng_: heh, i take it "lp" is hardcoded somewhere? are there other "presets"?
<mzz> oh, huh. ":this" partially fixes what was annoying me.
<mzz> flvr8: "lp:" is a bit fancier than it looks (deals with logins and some transformations of the path too iirc, it's not just a fixed prefix)
<itistoday> mzz: that seems a bit different from how git does it, i think. i think git sortof hides the branches from you, whereas with bzr you have to have the directory structure already laid out (repo/branches), i think git does (folder <- invisible branches)
<flvr8> mzz: ah, of course
<mzz> itistoday: git does have a directory structure, but it's below .git, iirc.
<mzz> itistoday: I suck at git, but afaict it's considered acceptable to peek inside .git. That's *much* less common with .bzr.
<itistoday> mzz: ah ok, then it should be possible to do something similar with 'bzr'?
<mzz> itistoday: well, I do think the two are pretty similar, but I haven't compared them in any amount of depth :)
<mzz> itistoday: I just found out about the magical ":this" location which points at the current branch. I think that can make them more similar
<mzz> let's see
<itistoday> the idea would be to have a branch with a .bzr folder in it, and to be able to change the working directory of that to another branch, without changing the folder's location
<mzz> I don't think you can have a .bzr folder, but you can have a .hidden-repo folder. Give me a minute, experimenting.
<itistoday> k
<itistoday> the .hidden-repo folder would have to reside within the branch itself... i'm not sure if that's possible with bazaar, which i think expects the repo to be the parent folder
<mzz> yay lightweight checkouts
<mzz> itistoday: haven't thought this through, but http://paste.pocoo.org/show/125465/
<mzz> itistoday: note that putting the checkout inside the repo works just fine (that's how that example in the manual I mentioned does it)
<mzz> itistoday: I'm interested in doing it this way because I have my repo on a network mount while I want my checkout to be local.
<itistoday> mzz: so initially in that example :this points to .hidden-repo/trunk ?
<mzz> itistoday: yeah, because that's what we checked out
<itistoday> with the checkout, do you still have access to all the revisions?
<mzz> itistoday: as long as the repository is reachable
<mzz> err, as long as the branch is reachable is better
<mzz> it's a lightweight checkout, which means it has just a working tree. For anything involving history it needs the branch and its repository
<itistoday> which it transparently accesses?
<mzz> itistoday: might actually want to peek at what ends up in .bzr to understand what's going on here, imho.
<mzz> itistoday: the checkout remembers the location of its branch
<itistoday> mzz: so the lightweight checkout acts as an alias to the branch?
<mzz> see "bzr help checkouts"
<itistoday> thanks, yeah, it seems like an alias
<mzz> oh, I forgot --no-trees on the init-repo
<itistoday> what does that do?
<itistoday> er... i'll have a look at the manual
<mzz> stop it from putting working directories in .hidden-repo, which is kinda silly here
<itistoday> cool, that makes sense, thanks for the example :-)
<mzz> notice there's very little to a branch without a working tree: just a revision id, tags, and branch.conf
<itistoday> neat
<itistoday> but yeah, i think the main difference here between git is that with bzr the repo must be in a different directory than the working tree
<mzz> and bzr gives you quite a bit of flexibility in where you put the repo, the branch, and the working tree (in the same place is simplest, but you can spread them out a bit too)
<mzz> you might even be able to put the repo inside the checkout and .bzrignore it
<itistoday> now that would be cool
<mzz> well, I think it'd be confusing.
<mzz> if you mess up the .bzrignore you could end up committing the repo to itself, or something equally daft.
<mzz> let's see though.
<Peng_> flvr8: lp: is provided by the built-in Launchpad plugin (bzrlib.plugins.launchpad), using bzrlib's directory service API. You could totally write a plugin to provide something similar, but you can't just add "foo: = http://bzr.foo.org/" to some config file.
<mzz> the bookmark plugin mostly does just that, iiuc
<mzz> itistoday: http://paste.pocoo.org/show/125470/ does seem to work, although I still think it's confusing.
<flvr8> Peng_: thanks
<mzz> itistoday: to improve this setup further you'd want a :repo alias so you don't have to specify those paths relative to the branch
<itistoday> mzz: thanks! is there any easy way to set that alias?
<flvr8> does anybody have experience with the bzr-emailer-notifier script? it's sending emails ok for two of the repositories, but not the third. (and there are a bunch of 'No handlers could be found for logger "bzr" errors' in the log, which makes me wonder if it's hung up on a lock per #141172 or #172392 -- any way to tell?)
<mzz> itistoday: and adding that to bzr is pretty trivial, although it is arguably a misfeature because branches are normally just an optimization, you're not supposed to care about their location
<mzz> itistoday: I'm tempted to just write it anyway though.
<mzz> lemme grab a snack and do that.
<itistoday> mzz: :-)
<itistoday> wow this is neat
<itistoday> so, i did something very similar to what you did, mzz
<itistoday> except i had a branch to start with already
<itistoday> so after creating the repo in the branch (.bzr-repo)
<itistoday> i branched to it like this: bzr branch . .bzr-repo/trunk
<itistoday> then I deleted everything inside the folder *except* for the .bzr-repo folder
<itistoday> and did a lightweight checkout from the .bzr-repo/trunk
<itistoday> and now it appears i have the same setup
<mzz> yep (remember to make that a --no-trees repo, bit faster that way)
<itistoday> yeah i did :-)
<itistoday> is there a bzr command though to do what i did via rm -rf  and bzr checkout --lightweight?
<itistoday> i.e. turning the current branch into a checkout from someplace else?
<itistoday> it seems like a dangerous thing to do though so there might not be
<itistoday> just want to know if what i did would be the standard way of doing that
<mzz> lemme see
<mzz> itistoday: bzr reconfigure --lightweight-checkout --bind-to .bzr-repo/trunk .
<itistoday> wowww
<itistoday> let me see if that works...
<itistoday> incredible
<itistoday> bazaar is awesome :-)
<itistoday> i might write a blog post on this if that's OK? i'll of course be sure to credit you and your examples
<mzz> mmm, drat. "lookups" is not an instance variable, so I can't just hack up the existing AliasDirectory so you get the same style of alias. Oh well.
<itistoday> i think people would be interesting for the git people to know that this can be done in bazaar
<itistoday> *think people = think it
<itistoday> how does the autocompletion work in bzr shell?
<itistoday> i type 'br[tab]' and it just puts a tab
<mzz> itistoday: meh. Try http://paste.pocoo.org/show/125474/ (put in ~/.bazaar/plugins, then turn the ":this/.." in earlier examples into "repo:")
 * mzz found various fun locations differing from the one he wanted
<mzz> itistoday: tab-completion works for me
<itistoday> i'm on OS X
<itistoday> oh well, not a big deal
<itistoday> re plugin: neat!
<itistoday> ill try it right now :-D
<mzz> (I was ending up with locations at various spots below .bzr, which wasn't what I wanted)
<mzz> (took me a while to realise I had to go through .bzrdir)
<itistoday> it might be useful for me to learn python at this point, if only to be able to customize bzr to my liking :-)
<itistoday> not sure what what you mean ..?
<mzz> can be quite useful to do ad hoc scripts or plugins
<mzz> just that I was getting the code wrong initially
<itistoday> how do i setup the plugin folder properly with this paste?
<itistoday> i've always seen plugins as directories, and they usually have some sort of specific setup with an __init__.py file in it
<itistoday> mzz: ping
<mzz> itistoday: http://paste.pocoo.org/show/125477/ is slightly cleaner
<itistoday> mzz: how do I setup the plugin though?
<mzz> itistoday: just store as ~/.bazaar/plugins/repoalias.py, or ~/.bazaar/plugins/repoalias/__init__.py if you prefer
<itistoday> doesn't seem to work via the second method...
<itistoday> Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins'
<itistoday> Unable to load plugin 'repoalias' from '/Users/gslepak/.bazaar/plugins'
<itistoday> err, sorry for the dup
<mzz> no? urgh, now what did I do wrong
<itistoday> mzz: have you tried it?
<mzz> there should be a message above the failure
<mzz> yes, I have
<mzz> well, I've tried way one, and I can't think of a reason for way 2 to fail
<mzz> (don't do both at the same time though)
<itistoday> i tried method 1 too
<itistoday> same message
<itistoday> wonder if there's any way to get what the reason is?
<mzz> no further output? Also check ~/.bzr.log
<itistoday> yeah, there is
<itistoday> 1 sec
<itistoday> http://paste.pocoo.org/show/125478/
<itistoday> doesn't seem to like RepositoryDirectory
<mzz> that traceback makes no sense to me
<mzz> oh wait
<mzz> itistoday: how did you paste this code over? Did you accidentally end up with the call to directory_service.directories.register indented?
<itistoday> let me check
<itistoday> yes
<itistoday> sorry, i don't know python
<mzz> itistoday: indentation is syntax in python. Using the "download" button of the pastebin is strongly recommended.
<mzz> (under "paste details")
<mzz> or I guess I could just stuff this thing on launchpad
<itistoday> k, will remember that from now on for python code
<itistoday> ok that seemed to work :-)
<itistoday> although i'm probalby using it incorrectly: bzr branch . :repo/expirmental
<itistoday> bzr: ERROR: ":repo/expirmental" is not a valid location alias.
<mzz> itistoday: repo:, not :repo. Sorry about that.
<itistoday> :-D
<itistoday> mzz: thanks! sorry about that
<itistoday> i like that syntax a lot actually
<mzz> I actually think I like repo: better, so I think I'll keep it
<itistoday> yeah
<itistoday> definitely
<mzz> hmm, what to call the plugin
<itistoday> mzz: you might want to consider making this a real plugin?
<itistoday> i think lots of people would find this useful
<mzz> hardest part: think of a name
<itistoday> repoalias is pretty good i think...
<mzz> repoalias it is
<itistoday> :-)
<itistoday> yup, seems like it
<mzz> itistoday: just give me a minute, pushing etc
<itistoday> mzz: sure :-)
 * mzz is figuring out whether lp can host branches without having a whole project for them
<wgrant> mzz: Use +junk in place of the project name.
<mzz> "bzr push lp:+junk/repoalias" fails
<wgrant> mzz: You need your username in there too.
<wgrant> bzr push lp:~username/+junk/branch
<mzz> yeah, got it. Thanks!
<mzz> itistoday: bzr get lp:~marienz/+junk/repoalias
<itistoday> mzz: awesome, thanks!
<itistoday> if I get time i'll write a blog entry on this plugin and using bazaar like git here: http://taoeffect.com/blog
<mzz> notice this is just a hack so far, I don't know if there are any gotchas if you actually use this
<itistoday> mzz: k, will be sure to mention that if i post it
<mzz> added it to the list on the wiki too
<mzz> I guess I'll turn it into a proper lp project if people use it
<itistoday> just used it with merge, seems to be working fine :-)
<itistoday> mzz: if i find any bugs in it, what would be the best way to report them to you?
 * mzz wonders if launchpad has a way to file bugs on a person instead of a project
<mzz> itistoday: I'm actually more reachable through irc than through email, I'm weird like that. Just poke me in here.
<itistoday> mzz: k, sure thing, yeah, and it would be neat if launchpad could do that, although if you decide to turn it into a project that would solve it
<itistoday> already, i'm heading out, thanks again mzz for all your help, and the awesome plugin!
<kfogel> If I see this:
<kfogel> working tree: Working tree format 4
<kfogel>         branch: Branch format 6
<kfogel>     repository: Development repository format - rich roots, group compression and chk inventories
<kfogel> ... from 'bzr info -v', does that mean I'm using brisbane core?
<wgrant> 'chk inventories' == brisbane core
<wgrant> Not sure if that's 2a, though.
<mwhudson> 2a has branch7 too
<mwhudson> kfogel: run bzr upgrade --2a in the *branch* directory
<wgrant> Right, my 2a has that repository type but branch7
<mwhudson> (it will be very quick)
<mwhudson> although
<mwhudson> you should probably recreate the working tree too
<kfogel> mwhudson: this is the mysql-server branch that I created, using the script you've seen by email.  I ran 'bzr upgrade --2a mysql-server' to get this!
<mwhudson> kfogel: it's a standalone branch?
<kfogel> mwhudson: yes
<wgrant> I though branch7 was only needed for stacking. Does 2a force it just because it's a good opportunity?
<kfogel> mwhudson: it is not in a repo other than itself
<mwhudson> kfogel: strange!
<mwhudson> wgrant: yes, i think so
<mwhudson> wgrant: any client that can understand a chk repo can certainly understand branch7
<wgrant> mwhudson: That is true.
<kfogel> mwhudson: this appears to be bzr 1.16, not 1.16.1, fwiw (it's on devpad).
<mwhudson> kfogel: i don't think any of the fixes will have made a difference here
<mwhudson> kfogel: you did run reconcile before updgrade, right?
<kfogel> mwhudson: yup.  I just ran that script, as per my email.
<mwhudson> good
<wgrant> What benefit does the reconcile bring?
<mwhudson> well, you could try running bzr upgrade --2a again...
<wgrant> (apart from making a nice heater)
<mwhudson> wgrant: inconsistent revision information in the revision graphs can mess the conversion up
<mwhudson> (i don't really know the details tbh)
 * mwhudson goes to cook dinner
<wgrant> mwhudson: Ah, right.
<kfogel> mwhudson: bzr upgrade --2a will take another four days?
<mwhudson> kfogel: it really shouldn't
<mwhudson> changing the branch format is easier
<mwhudson> maybe tar it up first though...
<kfogel> time bzr upgrade --2a
<kfogel> starting upgrade of file:///home/kfogel/lp-testing/mysql-server/
<kfogel> making backup of file:///home/kfogel/lp-testing/mysql-server/.bzr
<kfogel>   to file:///home/kfogel/lp-testing/mysql-server/backup.bzr
<kfogel> bzr: ERROR: File exists: u'/home/kfogel/lp-testing/mysql-server/backup.bzr/': [\
<kfogel> Errno 17] File exists: '/home/kfogel/lp-testing/mysql-server/backup.bzr/'
<mwhudson> rm -rf backup.bzr
<kfogel> mwhudson: done (well, moved it elsewhere).  now re-running
<kfogel> mwhudson: thanks for taking time out from cooking dinner
<kfogel> mwhudson: upgrade completed :-)
<kfogel> 22 milliseconds
<kfogel> bzr info -v now says branch format 7
<mwhudson> kfogel: yay
<Lo-lan-do> G'day allâ¦
<Lo-lan-do> I'm reading http://bazaar-vcs.org/Roadmap/BrisbaneCore/PlusOne and the last feature listed there appeals to me for a client.
<Lo-lan-do> Any hint whether we're talking months or years here?
<Glenjamin> is there a mirror for bzr downloads somewhere? lp seems to be down
<james_w> Glenjamin: should be back up
<Glenjamin> mm, got it now
<Glenjamin> altho i'm having a problem installing bzrtools on linx
<Glenjamin> i;ve installed bzr and bzrtools via easy_install, but they both seem to be eggs, instead of bzrtools going into the plugins folder
<SamB> Glenjamin: but does "bzr plugins" list bzrtools?
<Glenjamin> SamB: cheers for replying, i figured our that easy_install did an egg, which didnt work - but setup.py install did it properly
<dobey> abentley: not around are you?
#bzr 2010-06-28
<spiv> Good morning.
<lifeless> allo allo
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<poolie> hi spiv
<lifeless> hi poolie
<lifeless> anyone know, can you do keyword lambdas in python 2.4?
<lifeless> by which I mean
<lifeless> lambda foo=bar:quux
<thumper> lifeless: I've never seen that before
<lifeless> thumper: :)
<lifeless> thumper: I'd never had cause to do it before today.
<thumper> lifeless: what are you trying to do?
<lifeless> it Just Worked in python 2.6
<lifeless> thumper: theres an interface which is (now) called with keyword parameters, that a test stubbed out with a lambda.
<thumper> ah
<parthm> lifeless: seems to work on 2.4 http://pastebin.com/k4X1x8pE
<lifeless> parthm: thanks!
<spiv> You've been able to do that with lambda since approximately forever.
<spiv> It was particularly useful back when Python didn't have nested scopes.
<lifeless> cool
<poolie> hi there spiv
<spiv> Hey poolie
<poolie> hi spiv
<poolie> do you have any particular thoughts on bug 582157?
<ubot5> Launchpad bug 582157 in Bazaar "pull from launchpad is slow (affected: 1, heat: 8)" [High,In progress] https://launchpad.net/bugs/582157
<lifeless> spiv: http://pastebin.com/fqiwpZ7S
<spiv> poolie: I like your remarks about the two parts of the problem
<poolie> :)
<poolie> i was hoping you'd say i was obviously wrong and there was an easy fix :)
<lifeless> everyone.move_to(ireland)
<spiv> Heh.
<lifeless> spiv: I'm not entirely sure why the is None check is needed; pqm failed two calls to stat() with it though
<lifeless> bah
<lifeless> 'bzr st'
<poolie> or the IoM, 10% tax and low ping time :)
<lifeless> spiv: or possibly I'm misreading the trace; trace shadowing a top level import is a bit annoying.
<lifeless> Hmm, maybe we should fix that
<spiv> poolie: so how close are we to finding that SSH is the limiting factor?
<poolie> good question
<poolie> we know that https from chinstrap is not much faster
<poolie> it would be nice to try plain tcp with no encryption
<spiv> And SSH with no encryption, perhaps.
<poolie> if it is something at the encryption level it might be either encryption cpu overhead or added latency or windowing effect
<poolie> mm that could be good
<poolie> spiv, what are you up to next?
<spiv> Firing off a merge request, then lunch ;)  Then https://bugs.edge.launchpad.net/bzr/+bug/551525, then maybe https://bugs.edge.launchpad.net/bzr/+bug/522637
<ubot5> Launchpad bug 551525 in Bazaar "reconfigure --unstacked doesn't quite work for lp branches (affected: 1, heat: 6)" [High,Confirmed]
<lifeless> spiv: no comment on my pastebin ?
<poolie> that would be nice
<poolie> bug oh especially the latter, but both would be great
<spiv> lifeless: the test change seems fine, there's an incomplete sentence in the docstring change, and I lack enough context to judge if that's sane and obviously correct, or nonsense ;)
<poolie> i'm going to try Maverick on my desktop to give feedback on some kernel bugs i hit on the new mb
<spiv> Hmm, SSH with no encryption seems hard with modern versions of SSH.  Oh well.
<poolie> i may try ssh without encryption
<poolie> istm the next thing is plain tcp
<poolie> this might require sysadmin help
<lifeless> spiv: yes
<spiv> You could try SSH with a supposedly faster cipher at least, like blowfish.
<lifeless> spiv: the doctstring is winging its way up, I'll iterate on it sometime this week.
<lifeless> spiv: its only missing a single bracket.
<spiv> That's ok, the original sentence was arguably missing a comma ;)
<lifeless> I'd like --lsprof-file
<lifeless> to tell the smart server to lsprof the request (and lock out other threads yada yada)
<lifeless> and attach the callgrind format data as another part of the response.
<poolie> ! :)
<AfC1> Strangest thing just happened. Doing bzr push bzr+ssh:/// to a server where we don't have RSA keys and so have to type the password on console,
<AfC1> suddenly a GTK dialog popped up asking for the target user@host's password.
<AfC1> WTF?
<AfC> Was that Bazaar trying to be helpful, or something else $known trying to be helpful, or a "problem"?
<lifeless> something else probably
<lifeless> new ubuntu version ?
<AfC> lifeless: Lucid
<AfC> both sides
<AfC> It was reminiscent of the Subversion credential caching behaviour, but I wasn't expecting Bazaar to do that at all, and especially not for an SSH login password.
<AfC> And not I can't duplicate it. If I can't figure it out, I may have to judge that the box got owned
<lifeless> there is a gtk UI for ssh keychains
<lifeless> its part of the gnome stack
<AfC> Hm
<AfC> It was just really anonymous looking. Didn't look that authoritative.
<AfC> lifeless: (anyway, thanks)
<lifeless> look in your process list
<lifeless> for agent
<vila> hi all
<spm> hey vila!
<poolie> hi there vila
<vila> hey poolie
<poolie> vila, did i tell you i replaced my broken pc with a 6-core amd?
<poolie> it makes selftest --parallel pretty nice
<poolie> it gets easily disk bound though
<vila> wow, welcome to the club :-)
<vila> poolie: python -c 'from bzrlib import osutils ; print osutils.local_concurrency()' ?
<lifeless> 6
<vila> 6 or 12 ?
<vila> ok
<poolie> probably 6, no ht
<lifeless> AIUI amd have rather different ideas in that space
<vila> so running the full test suite is down to what ? 6mins 8 mins ?
<poolie> something like that
<lifeless> hmm
<lifeless> tomorrow
<lifeless> remind me to land my 'delete 1/3 of the registered repo formats' patch.
<poolie> :)
<lifeless> its intermingled with other stuff
<poolie> vila, is texinfo blocked, or still on your plate, or ..?
<lifeless> but I can pull it out and do it with a prod, and I think it will be quite noticable
<vila> still on my plate
<lifeless> hi jkakar
<jkakar> Hiya lifeless!
<lifeless> memo to self, put http://www.webperformancematters.com/journal/2007/7/24/latency-bandwidth-and-response-times.html in the bzr perf bug
<jam> vila: what's up with: https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28315
<jam> ?
<jam> though you may already be gone
<vila> jam: almost but not quite, I just need to look at it, I'm looking into .conf files needs to be locked and ran into yes-but-lock-info-use-config loop :-)
<jam> vila: sure, just trying to drive the queue, and that is a 'tweak' entry
<vila> jam: I'll look into them as soon as I submit this one
<parthm> jam: hi
<jam> hey parth
<jam> bbiab
<Stavros> hello
<Stavros> is there a way for a colocated branch switch to store uncommitted changes?
<Stavros> anyone?
<parthm> Stavros: i haven't used colocated branches but shelve command stores uncommitted changes. maybe you can check if they work together.
<Stavros> i can't find it anything in the docs, but it would be great if colocated branches could store changes a la shelve
<Stavros> i could have two branches in the same dir and work on them at the same time
<parthm> Stavros: yes. i understand the colocated concept in bzr but just haven't tried it :) ... so i don't know how well it works with shelve.
<Stavros> as far as i know, it doesn't work at all
<Stavros> i'll add a feature request, thanks
<parthm> Stavros: oh. yup. in that case its probably a good idea.
<jam> back
<jam> Stavros: I'll also note that 'bzr-pipeline' does something similar and stores a related group of 'shelved changes' on a given branch
<Stavros> Added: https://answers.launchpad.net/bzr-colo/+question/116044
<jam> I don't know the details, though
<Stavros> jam: oh, let me check that out, thanks
<jam> abentley might be able to give more details (author of bzr-pipeline)
<Stavros> pipeline looks great, i should be able to figure it out from the docs, thank you very much
<lifeless> jam: I think you perhaps got tricked by the new feed-pqm
<lifeless> jam: did you mean 'e' ?
<jam> morning lifeless
<jam> well, right now it is hard to test as it says "No remaining merge proposals matching status ['Approved']?"
<jam> however, if there is a single proposal marked approved ,then running 'n' will repeatedly give you back the same proposal
<jam> (go to next)
<jam> lifeless: also, I submitted martin's proposal, but pqm doesn't seem to be running, nor did I get an error message about it.
<jam> though it did go into the Queued state
<jam> and it didn't seem to write a 'sent to pqm message'
<lifeless> jam: run with --help
<lifeless> theres an option to access queued ones too
<lifeless> then use e to send it via email
<jam> lifeless: so is 's' useless now?
<jam> (until we get pqm reading queued messages again) ?
<lifeless> I sent email a while back - thumper asked us to stop using queued
<lifeless> yeah
<jam> k
<jam> it was certainly the obvious step
<lifeless> yeah
<lifeless> I would love to fix that
<jam> and Queued gives:
<jam>   File "c:\Python26\lib\site-packages\lazr.restfulclient-0.9.10-py2.6.egg\lazr\restfulclient\resourc
<jam> e.py", line 852, in __getitem__
<jam>     raise KeyError(key)
<jam> KeyError: '--queued'
<lifeless> dah wtf
<jam> apparently you need to put the project name before the arguments
<lifeless> *blink*
<jam> nope
<jam> that doesn't work either
<jam> it tells me that I need to only supply 1 argument
<jam> sigh
<lifeless> looking
<lifeless> the __name__ == __main__ section is borked
<lifeless> overlapping merges I think
<jam> yeah
<jam> checks length and then aborts
<jam> vs using OptionParser for it
<jam> I'll fix it up
<lifeless> overlapping merges
<jam> oh, and it still uses argv[1] after parsing into args :)
<jam> joy
<lifeless> http://pastebin.com/Zc6PrRhy is most of it
<lifeless> oh lol
<lifeless> that think is going to be me
<lifeless> the other bit I dunno what happened
<jam> lifeless: it also doesn't work particularly well if you initially gave hydrazine readonly credentials
<jam> :)
<lifeless> thats surprising
<lifeless> surely the queue command would have blown up, then ?
<jam> well, it read it ok, but it failed with big tracebacks when I tried to set something
<jam> sure
<jam> it just failed in hard-to-debug ways
<jam> lifeless: anyway, 's' is much more obvious for submit (IMO), but hey, as long as we get something working.
<JoshBrown> I've accidentally added my email to my name in all my commits, so I'm seeing something like: 'Josh Brown josh@host.com <josh@host.com>' - is there anything I can do about this this?
<rubbs> JoshBrown: you can try to reset your whoami by doing bzr whoami Josh Brown <josh@host.com>
<rubbs> alternatively you can edit the "email" line in your bazaar.conf file. On linux that is located at ~/.bazaar/bazaar.conf
<JoshBrown> rubbs: I've got it set fine now ('Josh Brown <josh@host.com>'), it's just that it looks messy in the logs.
<rubbs> oh, of that I'm not sure.
<rubbs> unfortunately I must go, I wish you luck in finding your answer
<JoshBrown> rubbs: Bye.
<rubbs> bye
<JoshBrown> :)
<jam> JoshBrown: you might look at using something like 'bzr rebase', but I think that tries to preserve the original author info
<JoshBrown> jam: Thanks, I'll look into it.
<JoshBrown> Actually it only seems to change the actual content, while preserving author info.
<jelmer__> heh, bzr transports ftw
 * jelmer__ runs bzr.dev pack sftp://charis.local/~/samba3.git
<jam> jelmer__: interesting
<jam> now does that end up doing a git pack  on the remote side?
<jam> seems like it would be pretty inefficient, but still interesting to have it work
<jelmer__> jam: Since it's all local it's not that inefficient
<jam> jelmer__: well, other than the sftp protocol overhead :)
<jelmer__> local as in LAN I mean
<jelmer__> jam: right
<lifeless> jelmer__: \o.
#bzr 2010-06-29
<lifeless> poolie: http://www.network-theory.co.uk/cgi-bin/ghm.cgi?
<thumper> lifeless: hey, perhaps you can help with something
<thumper> http://bazaar.launchpad.net/~agilence/+junk/tonomundo/changes shows last revision is 192
<thumper> http://bazaar.launchpad.net/~agilence/+junk/tonomundo/.bzr/branch/last-revision shows last revision is 13
<thumper> any idea what causes this?
<poolie> that's odd
<thumper> I've seen it happen before
<thumper> but I can't remember why, or what we did to fix it
<poolie> i think we had some bugs in the past where the cached last revno could be wrong
<poolie> it's possible that pushing using a buggy client could get it wrong
<poolie> is there a bug for this, or is it causing a crash?
<thumper> bug 599492
<ubot5> Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/599492
<poolie> lifeless, does that ring any bells with you?
<poolie> spiv^^
<nekohayo> hey there, what's up with nested trees/submodules support? I see https://blueprints.launchpad.net/bzr/+spec/nested-tree-support being dead for 4 years!
<poolie> nekohayo, hi, i would recommend you use scmproj
<poolie> http://doc.bazaar.canonical.com/plugins/en/scmproj-plugin.html
<thumper> poolie: is that the official answer now?
<nekohayo> poolie, actually I'm asking this because I'm dying having to use git to pull pitivi... I'd like to be able to use bzr-git
<thumper> poolie: what about submodule support for bzr-git?
<poolie> thumper, that's not on our plate at the moment
 * thumper nods
<spiv> poolie: no bells other than "this used to happen sometimes in the past"
<thumper> I've asked on the bug about the client bzr version
<spiv> 'bzr reconcile' ought to fix it.
<nekohayo> is it on some not-so-far roadmap or ETA, or should I not expect this within years?
<lifeless> thumper: hi, sorry
<nekohayo> (I can't provide a patch, sadly)
<thumper> nekohayo: I think decisions were made at a recent sprint to allow nested trees to work as a plugin initially
<lifeless> yes
<thumper> nekohayo: to clear the road for some development on it
<lifeless> thumper: so I think that that indicates a 'wrong' last-revision file in the branch.
<thumper> nekohayo: but I don't know if anyone is moving with it right now
<thumper> lifeless: yes...
<lifeless> thumper: if the user runs 'bzr reconcile' bzr will rewrite it.
<thumper> lifeless: and push again?
<thumper> lifeless: or we should reconcile the LP version?
<lifeless> push --overwrite (to force it to update)
<lifeless> or reconcile, and the next push that actually does stuff should fix it automatically.
<lifeless> you could reconcile the LP version too
<thumper> can you reconcile a remote branch?
<lifeless> yes but its a tad slow
<spiv> The user will probably need to reconcile their local copy too.
<thumper> thanks
<thumper> bug has been updated
<lifeless> thumper: nested trees - marius kruger is interested in running with it, but hes out of cycles
<poolie> spiv, in the 2.2.0 milestone page, how many bugs does it say under "assigned to you"
<poolie> the actual field, not adding it up yourself
<lifeless> https://edge.launchpad.net/bzr/+milestone/2.2.0 ? yes fail.
<lifeless> using caching is hard.
<poolie> it seems like in principle you could warn about that
<lifeless> Vary
<lifeless> In general we want Vary on everything that is cachable.
<lifeless> Because there are so many...variations :P
<poolie> mm
<lifeless> thumper: bzrlib/tests/blackbox/test_serve.py
<thumper> lifeless: ta
<lifeless> 12 tests
<lifeless> 336 lines; balance is ok but its a lot of complexity
<parthm> poolie: hi
<idnar> argh
<idnar> so I have a branch, which I've committed several revisions to
<idnar> and now I realise that in one of the earlier revisions, I accidentally removed a file and readded it elsewhere, instead of using bzr mv
<idnar> is there an easier way to fix the branch up besides creating a new branch and manually replaying the revisions on this one, one at a time?
<idnar> hmm, I'm going to try making a copy of the branch, uncommitting past the faulty revision, fixing it up, then rebasing the complete branch on top of that one
<thumper> lifeless: it seems that push --overwrite didn't update the last revision: https://bugs.edge.launchpad.net/launchpad-code/+bug/599492/comments/3
<ubot5> Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,Incomplete]
<idnar> argh, now I have a "contents conflict"
 * idnar continues hurtling down the rabbit hole
<idnar> okay, I think that worked
<lifeless> thumper: thanks
<lifeless> vila: ping
<vila> hi all !
<vila> lifeless: pong
<poolie> hi there vila
<vila> lifeless: do GlobalConfig and LocationConfig objects sound like good candidates for bzrlib.state ?
<poolie> how's it going?
<vila> poolie: fine, I encounter funny details while working on the config file locks, like: lock info trying to access the config while locking it and lock trying to create the config dir to access a non-existent config file but I'm almost finished
<lifeless> vila: hi, was looking for a 'ForceNeeded' error but couldn't see one
<lifeless> vila: uhm, *if* they are currently getting globally memoised, sure.
<lifeless> vila: but I wouldn't add anything to it that isn't already globally memoised.
<lifeless> vila: I think we should have smaller lifetime context objects for such things.
<vila> lifeless: the context here is that to fix the bug I need to lock write access but also read access which makes accessing the config more costly. On the other hand we actually almost always access the file for every config variable. The file is read/parsed and all (variable/value) tuples are indeed memoised... to be thrown away immediately
<lifeless> vila: why do you need to lock read access?
<lifeless> vila: that smells very wrong to me
<vila> lifeless: since there is a very high suspicion (I couldn't get a corrupted conf file yet), it means two writers have been able to write to the same file at the same time. I see no reason to believe that a reader can't get a partial file while a writer is producing it
<lifeless> vila: I think it would be a lot better to do the following:
<lifeless>  - ensure that the file is written with our atomic-write facilities
<vila> it is
<lifeless> e.g. transport.put_bytes()
<vila> well, no, it isn't
<lifeless> in which case readers cannot get partial files
<lifeless> and
<lifeless>  - ensure that changes to it do not do so from stale data - changes should be 'lock, read, write, unlock', never 'read, lock, write, unlock'
<vila> that's already done, with tests
<lifeless>  - do that by making configs gotten without locking be immutable.
<lifeless> so that we're not dependent on tests for correctness.
<vila> the third point is guaranteed from the second one
<lifeless> vila: no its not :)
<vila> well, at least from the config object point of view, extending this rule to callers....
<lifeless> vila: 1 word: plugins
<lifeless> OTOH you may have done 3 already - I haven't seen your code.
<lifeless> anyhow, if you have those three things, why do you need to lock when reading?
<lifeless> locking is /very/ expensive and there is no way we should consider for more than an msec doing that on every execution of bzr
<vila> I don't have the first yet
<lifeless> it would also cause all sorts of bugs on readonly filesystems.
<lifeless> vila: well, thats easy then :)
<vila> config dir on read-only FS.... missed that one, not sure it's easy to achieve but no reason to make it harder
<poolie> urk, yes, we should really not lock on read
<vila> yet, even if the write is atomic, do we rely on the FS to keep providing the file content as it was when opened even if the path is no longer valid ?
<lifeless> vila: there are a few cases. I think its ok. Its certainly no worse than today, right ?
<vila> lifeless: no worse yes, at least we cover the concurrent writers which the bug seems to be about
<lifeless> right.
<vila> lifeless: regarding point 3 above (immutable), if you keep your config objects around, even if immutable, they can be come out of date, sharing them is a way to address the problem hence my question about state
<vila> s/be come/become/
<lifeless> vila: different problem
<lifeless> vila: that can happen today.
<vila> lifeless: yes
<lifeless> vila: and I don't see any need to change any code beyond config.py for this patch; we want to fix 'concurrent writers', nothing less, nothing more.
<lifeless> The reason to focus on the use case here is because we are generally happy with configs I think
<vila> lifeless: I don't intend to fix more than needed, just discussing the problem while it's fresh
<lifeless> there aren't other issues to tackle, unless we make them ;)
<vila> lifeless: and also checking I understand how you intend bzrlib.state to be used ;)
<vila> s//to use/
<lifeless> vila: I want to delete it totally
<vila> s!s///!!
<mgz> Unsupported or unknown search engine!
<lifeless> vila: but its a tool to transition existing global state from all over the library into one place.
<lifeless> vila: which is better than the same state spread out.
<vila> config files are global state, outside of the code currently, but still a global state
<lifeless> vila: unless they are assigned to a global variable, they aren't for the purpose of this discussion.
<lifeless> import universe is cheating!
<vila> then I'm done :)
<lifeless> cool
<vila> using threads to test concurrent actors is yummy, I even just found away to avoid hangs (at least some) when the test fail...
<vila> gee, that's typo day ! s/away/a way/
<vila> freudian slip for get awat may be...
<vila> away of course, couldn't avoid the typo there, story of my life :)
<CaMason> Hi guys. I have a commit that introduced some good and bad changes on a file. What would be the best way to 'unpick' this file for a new commit?
<jpds> CaMason: bzr shelve - is your friend.
<CaMason> yes, I figured that would help
<CaMason> so, should I get the copy of the file before the bad commit?
<rubbs> CaMason: you may be able to uncommit and then shelve.
<rubbs> bzr uncommit takes off the last commit and restores to that state IIRC
<tsmith> bzr: ERROR: No module named _curses
<tsmith> i'm on CentOS and CANNOT find th epython curses module
<jelmer> vila: hey
<jelmer> vila: your  lp:~vila/bzr/525571-lock-bazaar-conf-files branch has conflicts
<maxb> tsmith: This should be provided by the Python installation itself, i.e. your Python installation is broken
<tsmith> well that's good to know!
<tsmith> i couldn't find source code for pycurses anywhere
<vila> jelmer: wow, I was about to tell you I submitted this :)
<jelmer> :-)
<vila> jelmer: as far as bzr-svn is concerned, it should just me a matter of requiring 2.2 and changing the base class for subversion.conf
<jelmer> ah, great
<jelmer> vila: I'll give it a try when I get a chance, thanks very much for working on this (and I'm sure you'll also make the losas very happy)
<vila> jelmer: that's only conflicts in NEWS, ignore them, news_merge is not configured on lp :-P
<vila> jelmer: I only quickly skimmed config.py in bzr-svn, there seem to some duplication that may need to be removed though
<vila> s/to some/to be some/
<vila> jelmer: Overall: my feeling is that we were *very* unlucky to encounter concurrent writers, my proposal use the transport API to make the config write atomic, so this fixes the bug,
<vila> s/,$/./
<vila> jam: what was your tweak for https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28306 ? osutils lazy imports ? Or was there more ?
<jelmer> vila: there are a lot of imports running on the import slaves I guess
<vila> jam: nevermind, I was looking at the wrong mp
<jam> vila: I think just the osutils stuff
<vila> jam: yes, sorry
<JoshBrown> I've accidentally added my email to my name in all my commits, so I'm seeing something like: 'Josh Brown josh@host.com <josh@host.com>' - is there any way I can edit the logs to remove the duplicated email address?
<maxb> I am confused. Why would I be getting a Contents conflict when I cherrypick a revision that adds a file?
<maxb> oh, because I don't understand what -r N.. does
<maxb> Eeek. This scares me.
<maxb> I have a bzr-svn branch, and did a merge, and got bogus merge results
<maxb> I ran the repository through fast-export|fast-import, and got saner merge results
<maxb> bzr-svn must be doing something evil
<vila> maxb: next time, try 'bzr st --show-ids'
<maxb> vila: ok, what am I looking for?
<vila> maxb: content conflicts are generally about conflicting *paths* with different file-ids
<maxb> ah, right, you are speaking regarding my first problem
<maxb> That turned out to be me misunderstanding the exclusiveness of the N in -r N..
<vila> ha, sry for the noise then
<maxb> np, you are right about the issue - I was merging a modify on a file-id which didn't have its addition merged
<maxb> the other issue is unfortunately rather scarier
<jam> vila:  I realize you are probably gone, but any thoughts on bug #530584
<ubot5> Launchpad bug 530584 in Ubuntu Distributed Development "File conflict when merge back packaging branch to upstream (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/530584
<jam> like, does your resolve stuff have a 'bzr resolve --mine" for deleted files?
<vila> jam: almost done but not quite, --mine should work for deleted files as well as long as they were deleted by the merge
<vila> AFAIR
<jam> vila: the point is to leave it deleted
<jam> supersede changes in favor of considering the file deleted
<jam> I don't fully understand what is flowing where yet, so i'm not 100% sure what is OTHER and what is THIS
<vila> ha, yes, just -rereading the bug report
<vila> that reminds me of some thoughts I had about making some --mine/--other "sticky" but I don't have the context anymore :-/
<vila> something like a merge plugin based on a list of (file-id, --mine) or something
<vila> or file path... anyway, some text file a user can still modify
<jam> vila: have you upgraded your VBox yet?
<vila> jam: no, given the changelog I see no urgency
<jam> vila: oh, and I was timing 'ping bazaar.lp.net' and found it at 120ms from babune, is that normal?
<jam> I thought you had 20ms ping time to lp
<vila> jam: ha, right, I forgot to comment on that, no 20ms is indeed the "normal" lag
<vila> at what time did you try ?
<jam> just tested again and seem 120ms
<jam> right now
<vila> wow, indeed, never saw that !
<jam> +20% packet loss
<jam> but maybe because I used ^C
<vila> 6% packet loss here ^C too
<jam> yeah, without ^C and just doing -c 10 no loss
<vila> after your mail I tested again and I got 20ms as expected
<jam> I think it is just 1/num succeeded
<vila> so it may depend on time of day ?
<jam> absolutely possible, but surprising nonetheless
<jam> that is a rather large swing
<jam> and you still get *way* better downloads from http://bazaar.lp.net than I do
<jam> at this instant, I have 110ms ping time (so lower than you)
<jam> and it 'bounces' trying to cap 3Mbs
<jam> although it does a better job than it did the other day
<jam> and it just dropped to 200kB/s for a second or to
<jam> 2
<vila> hmm, the osutils tweak is more tricky than I thought, both 'import tempfile' and 'from tempfile import mkdtemp' are *required*
<vila> of course I didn't ran the tests after such a small tweak :)
<jam> vila: that's why we have pqm. Because I've certainly done things similarly.
<vila> :-D
<jam> vila: for your config locking patch
<jam> should we be putting 'held' in the directory directly
<jam> or should we be using a 'lock' subdir
<jam> and what is the overhead time of locking/unlocking repeatedly? (how long are the locks maintained, etc)
<vila> the locks are maintained very briefly we just output the config file textual content
<jam> vila: sure, but I just did some timing and "lock_write() && unlock()" on Windows takes 10ms
<vila> I think people won't mess up with a directory named 'lock', I'm less sure of that with a 'held' file and/or 'info'
<jam> vila: also, what is the concurrency that we are trying to solve. Does it make sure to hold the lock open from the time the file is read until it is written?
<vila> jam: No ! Only around the file being written. How could I forgot to explain that :-(
<vila> could I have forgotten ?
<jam> vila: I thought the problem with svn concurrency was that the read got out of sync with the other one
<jam> was it actually having 2 writers on the same file?
<vila> AIUI yes, hmm, yeah, that was mentioned on IRC I think
<vila> and since the fix use an atomic write, the risk is really very low to mess up a reader
<vila> It would require interrupting a read() of an opened file
<jam> vila: if the problem is not using atomic write, then just doing that would 'fix' it, without the overhead of a lock dir
<jam> and needing stuff like break-lock
<vila> no
<vila> the sequence is: lock; read ; set new value ; write; unlock
<vila> no lock means races all over the place
<jam> vila: you just said "No ! Only around the file being written."
<vila> and even harder to diagnose bugs
<jam> you then said: (12:50:16 PM) vila: the sequence is: lock; read ; set new value ; write; unlock
<vila> eerk
<jam> so which is it?
<vila> dang it, I changed it after discussing it with lifeless this morning
<vila> s/read/re-read/ would be more appropriate, but I've changed the method where the @needs_write_lock is used
<vila> jam: fixed, I have to EOD, I'll try to provide a better explanation tomorrow
<vila> jam: just pushing for now
<vila> jam: and to answer your question: *it* is: lock ; re-read the config file ; set the new value ; write the config file ; unlock
<jam> vila: k
<jam> have a good night
<vila> and @needs_write_lock must be set on all methods that *calls* _write_config_file
<vila> and I have a bug in my test for catching this regression
<vila> s/for catching/for not catching/, typo's day until the end... :)
<dipnlik> hi, can I ask a bzr-svn question here?
<rubbs> yes, I probably can't answer, but ask away, someone can help.
<rubbs> dipnlik: ^^
<dipnlik> oh, nevermind, now it's working again
<rubbs> good to hear
<rubbs> for future reference all things bzr can be asked here.
<rubbs> some know more than others, but all questions get answered eventually
<rubbs> well, maybe not all. but just about all.
<dipnlik> i had a problem with tags, i created a tag with bzr but bzr-svn didn't auto-create the equivalent svn tag
<rubbs> ah
<rubbs> just curious how did you get it working? manually create the svn tag?
<rubbs> I ask because I'm eventually going to be lead person on migrating from svn to bzr
<dipnlik> after i created the first tag manually, the second one worked as expected
<dipnlik> "manually" == "using svn cp"
<dipnlik> and here we don't really intend to migrate the svn server, I just use bzr as a client because it's more user friendly and for some cheap local branches
<dipnlik> sad thing is that when I merge local branches to the trunk their log messages don't go the svn repo, so I don't use them as much as I wanted to :|
<rubbs> right, that's why we eventually will get rid of svn completely
<rubbs> my plan is to get them to use bzr as a client first
<rubbs> get used to the client, then switch out the server,
<dipnlik> oh, nice plan
<dipnlik> rubbs: didi you read http://www.szakmeister.net/blog/2010/may/30/bzr-svn-round-2/ (and the first one, linked on the 1st paragraph)?
<dipnlik> I didn't read it all but it looks interesting
<rubbs> no I haven't, but i will book mark it thanks!
<rubbs> bookmark*
<exarkun> If I have a bzr repository that I want to make public, but it contains some confidential information that I want to keep private, what should I do?
<jam> exarkun: you might want to look at 'filter-branch' from bzr-fastimport
<jam> it should allow you to rewrite the history into something similar, but with some bits removed
<exarkun> Cool, thanks
<lifeless> morning
<jam> morning lifeless
<lifeless> hiya
<lifeless> vila:
<lifeless> +    __doc__ = """\
<lifeless> +    Break a dead lock on a repository, branch, working directory or config file.
<lifeless> I'd prefer to see that spelt as
<lifeless> __doc__ = \
<lifeless> """Break...
<lifeless> because having to actually think about what you were escaping hurt my brain
<vila> lifeless: that's your brain telling you that you missed what is wrong (in both cases the newline is escaped), and what is wrong are the spaces I've added :-P
 * vila lower the volume and goes back to bed :)
<mgz> ...don't actually *need* to escape that docstring
<mgz> *newline
<mgz> it gets pulled off before anyone tries to print it
<lifeless> vila: in one, the \ is inside the docstring content
<lifeless> vila: so you
<lifeless> 're escaping ^M
<vila> mgz: no, lifeless got it right, there should be no spaces before "Break"
<lifeless> and then the formatter strips it
<mgz> the newline/spaces before 'Break' will always get stripped though, no?
<vila> and in the other I escape ^M too and the scanner strips it
<vila> mgz: no
<mgz> some people do print blah.__doc__ rather than help(blah), but they're silly.
 * vila off
<mgz> okay, night.
<mgz> I'm still confused as to what doesn't follow pep 257 stripping rules though.
<mgz> the whole point of them is so you don't need to do weird backslash or dedent things.
<TresEquis> why would you ever type '__doc__ = ...' instead of inlining the triple-quoted string?  That's just noise
<lifeless> TresEquis: -O0
<lifeless> TresEquis: there are two sorts of docstrings in bzrlib
<lifeless> TresEquis: programmer docs and command help
<lifeless> TresEquis: we don't want stripped binaries to lose the command help.
<lifeless> mgz: I know, thus my asking vila to change ;)
<TresEquis> scripts don't need stripping, anyway
<lifeless> TresEquis: commands are not scripts
<TresEquis> they don't even get compiled
<lifeless> TresEquis: you've added an untrue assumption to the discussion
<lifeless> pydoc bzrlib.builtins
<lifeless> 'bzr' is the script
<lifeless> and it has no functions or docstrings or anything
<mgz> yeah, it's not like git with lots of teeny shell scripts
<mgz> ...is git even like that any more?
<TresEquis> you don't need to use -OO ever
<lifeless> mgz: fsvo of
<lifeless> TresEquis: the windows packagers folk saved a MB or something doing it
<lifeless> TresEquis: so we happily acquiesced and helped them do it.
<mgz> it was me.
<mgz> easy change, was going for a slight startup speedup
<TresEquis> docstrings aren't the same as comments
<lifeless> mgz: thats right
<TresEquis> but whatever
<lifeless> TresEquis: I don't know why comments come into this
<mgz> and I think having special, user-visible docstrings marked differently in the source is a good thing
<TresEquis> sounds like you are using docstrings where you could use comments
<lifeless> TresEquis: the compiled python files *are* smaller without docstrings for the bulk of the library.
<mgz> even if it's not as significant a win as it might have been
<lifeless> TresEquis: not at all. The bzrlib API has docstrings describing how to use functions in it.
<TresEquis> if they need to be runtime-introspectable, then they shouldn't be stripped
<mgz> they don't.
<TresEquis> if they don't need to be runtime-introspecctible, then they could just be comments
<lifeless> TresEquis: that would make pydoc useless
<mgz> there are two different cases here
<lifeless> TresEquis: I really don't know what you're saying here.
<mgz> bzrlib being good to develop on
<mgz> and bzr being used as a tool
<mgz> we want decent docstrings for the first
<TresEquis> if they need to show up in pydoc, then they need to be runtime introspectible
<lifeless> TresEquis: not from a binary .exe
<mgz> but no one with a packaged bzr cares about the method descriptions
<lifeless> TresEquis: there are two separate sets of docstrings
<TresEquis> nolo contendere, I guess
<mgz> there's a thing about "never use -OO" in the python world, but this is one of the few sensible cases
 * exarkun disbelieves
<mgz> which bit? :)
<exarkun> docstrings are great
<exarkun> Python should try sucking less.  There's no particularly good reason for docstrings to make things bloated or slow.
<mgz> right, so there shouldn't be a disincentive to use them over comment when you're shipping pyo files only
<mgz> *comments
<mgz> it's not uncommon with py2exe I think.
<exarkun> py2exe is a different case, isn't it?
<mgz> it's what bzr uses for the windows package
<exarkun> It gives you an opaque blob you can ask Windows to execute.  Even if there are docstrings in there, you can't really find them, right?
<mgz> right, so, why not remove them, which is what the change is.
<exarkun> oh, I see
<exarkun> I missed the one comment above where someone said "windows" ;P
<mgz> as far as I can see, not an approach that works on nix, as users and developers will be working from the same package
<mgz> so they'll always be on pyc anyway
<lifeless> mgz: debian/ubuntu can build pyc's too - its an /etc config option
<lifeless> mgz: whats tricky is choosing which level of pyo to build
<lifeless> mgz: s/pyc/pyo/
<mgz> yeah, and that's not something barry's __pycache__ thing has done anything about I believe
<TresEquis> trading off the cost of this discussion vs. the bandwidth for the downloads ;)
<lifeless> TresEquis: :P
<mgz> the actual cost is likely to be in confused plugins devs. Need to do a post to list now there's a windows packaged 2.2b3 (there is, right?) saying what changed
<mgz> lifeless: you didn't push a testtools fix for u""?
<lifeless> mgz: let me check
<lifeless> pushing now
<lifeless> sorry
<mgz> 's okay, just needing it now.
<lifeless> ok, someone else pushed, pulling that in first
<mgz> hm, and no, no packaged 2.2b3 for windows yet it seems, I may as well draft the message now though
<mgz> I'm not seeing anything on launchpad testtools trunk after your rev
<mgz> did you uncommit locally?
<lifeless> mgz: actually no, I did push it.
<lifeless> mgz: I just have the edited version locally
<lifeless> rev 75
<lifeless> revno: 75
<lifeless> committer: Robert Collins <robertc@robertcollins.net>
<lifeless> branch nick: trunk
<lifeless> timestamp: Thu 2010-06-24 20:03:30 +1000
<lifeless> message:
<lifeless>   Do not generate str objects for StringException's internally.
<lifeless> its just not py3 happy
<mgz> yup, I see that.
<mgz> you were going to add _()
<lifeless> I did in fact
<lifeless> but I hadn't committed it
<lifeless> and then forgot and ...
<mgz> thanks!
<poolie> hello all
<poolie> hi jam
<jam> hi poolie
<jam> calling now
<poolie> hi there jam
<poolie> ok
#bzr 2010-06-30
<mtaylor> lifeless: around?
<lifeless> mtaylor: sure am
<lifeless> mtaylor: what can I do for you?
<mtaylor> lifeless: well... I'm going to get to have yet another launchpad/bzr vs. git/github discussion
 * mtaylor jumps up and down with excitement
<mtaylor> lifeless: and as part of prepping for it, it has been asked about the feasibility of us keeping things in launchpad but letting the devs continue to use git/github and syncing them
<mtaylor> lifeless: I think this is a terrible idea, mind you
<mtaylor> as the bug/blueprint/merge request integration is one of the main things we're gaining from launchpad and I believe we'd lose that that way ...
<mtaylor> lifeless: but - I was wondering if you had any advice/pointers on where I should start looking/poking to be able to give real and specific feedback about that (would be easier if I used github for any reason I imagine)
<lifeless> uhm
<lifeless> is it a valid summary to say
<lifeless> 'some people want to keep working on github using git'
<mtaylor> yes
<lifeless> 'team leads want the work tracking / planning features launchpad offer'
<mtaylor> yes
<lifeless> is there more to it than that ?
<mtaylor> nope
<lifeless> ok
<lifeless> one way
<lifeless> trunk on lp
<lifeless> feature branchces on lp
<lifeless> merge proposals on lp
<lifeless> have your well known branches - trunk, releases - mirrored to git
<lifeless> and hell, sourceforge and the hg site too
<lifeless> using bzr-* plugins and cron
<mtaylor> (there's an hg site?)
<mtaylor> k
<lifeless> then say in your project docs
<lifeless> 'launchpad is official, launchpad is great. But if you have muscle memory of $other vcs, see x, y, z and you can work on that site for *code management only*'
<lifeless> make the $other site pages point to launchpad with ambiguity
<mtaylor> ok. that all seems sensible...
<lifeless> and document how the dev in question can generate a branch on launchpad (again, push with the bzr-* plugin to launchpad)
<lifeless> for merges etc
<lifeless> I suggest doing multiple sites because your center of gravity will be less a battle of two things and more a common-reference point - its a social angle on it
<mtaylor> given the way git arranges branches - does bzr-git pushing to a branch on launchpad do what I expect?
<mtaylor> mmm. very good point
<lifeless> mtaylor: bitbucket.org is the hg one
<lifeless> mtaylor: now, the git folk may say 'we don't care about hg/svn we wanna bikket gnar gnar gnar'
<lifeless> mtaylor: I would then ask - so if its not about acessability for non bzr users, what is it about ? :)
<mtaylor> lifeless: I, in fact, assure you they will say exactly that
<mkanat> There's another hg one, too.
<mtaylor> jelmer: bzr: ERROR: exceptions.KeyError: 'No such TDB entry'
<jelmer> mtaylor: When?
<mtaylor> jelmer: I was trying to bzr dpush a bzr branch to an empty git repo on github
<mtaylor> jelmer: I'm using head of lp:dulwich and head of lp:bzr-git
<mtaylor> jelmer: it seemed to be happening right after it finished updating the git map
<jelmer> mtaylor, does your repository perhaps contain ghosts?
<jelmer> mtaylor: it might also be a regression in the dpush code which is being refactored at the moment so we can support roundtripping. I would recommend sticking with the releases for the time being.
<mtaylor> jelmer: ah ok
<mtaylor> jelmer: the version in lucid broke in a different way so I just grabbed trunk
<mtaylor> jelmer: I'll try a recent release
<mtaylor> jelmer: well, that's certianly creating a different amount of things in the git map
<mtaylor> jelmer: trying 0.5.1
<jelmer> mtaylor, if you can still reproduce some issue with 0.5.1, please file a bug
<jelmer> I'm off to get some sleep, back in ~7h :-)
<mtaylor> jelmer: will do
<mtaylor> jelmer: thanks
<poolie> mkanat: hi, are you around?
<mkanat> poolie: I am!
<poolie> are you still working on loggerhead?
<poolie> if so, i think we should be more in touch
<mkanat> poolie: Yeah, I'm still doing stability stuff.
<mkanat> poolie: Yeah, I think that's a good idea. :-)
<poolie> are you working with anyone else on it?
<mkanat> poolie: Well, I get people to review my patches now and again.
<mkanat> poolie: Usually Peng or mwhudson.
<poolie> oh that's good
<poolie> but sometimes you just commit to trunk?
<mkanat> poolie: No, I don't have privs.
<mkanat> poolie: So all my merge proposals get reviewed.
<poolie> (i'm not trying to give you a hard time, just to understand)
<poolie> ah ok
<mkanat> poolie: Which is probably good, at this point.
<poolie> istm you probably should be a committer though?
<poolie> even if you still ask for reviews first
<mkanat> poolie: Possibly, yeah.
<mkanat> poolie: Sometimes it's not too clear when the proposal is "reviewed enough" to check in, though.
<poolie> yeah
<poolie> but you can just say "is this reviewed enough yet?" until people give a clear answer
<poolie> i had a couple of other ideas
<poolie> one would be to post an occasional short note to the bzr list about what you're doing
<mkanat> poolie: That'd be good. I should probably subscribe to that list. :-)
<poolie> :)
<poolie> even if you just skim it, it would be a good idea
<mkanat> poolie: FYI, right now what I'm doing is tracking down a memory leak, but meliae is breaking on my platform and jam and I haven't figured it out yet.
<poolie> of course you don't need to recapitulate every patch but just an idea of the general area might help
<poolie> yes he said so
<poolie> that might also be reasonable to post about
<mkanat> poolie: http://wiki.bazaar.canonical.com/BzrDevelopment mentions the word "mailing list" several times but has no link to it.
<poolie> jam knows the most about meliae but the build problems might ring a bell for someone else
<poolie> heh, really
<poolie> we can fix that
<poolie> that page is pretty old
<poolie> better now, mkanat?
<poolie> how did you get to that page?
<mkanat> poolie: Hahaha, better!
<poolie> we could adjust the links to it
<mkanat> poolie: google "bzr developers mailing list"
<lifeless> thumper: so this revno is wrong bug
<mkanat> poolie: Okay, I've subscribed to the mailing list.
<lifeless> thumper: is it on lp-code ?
<poolie> mkanat: so the final thing was, perhaps you should be more in touch with the LOSAs?
<mkanat> poolie: Yeah, that would be great.
 * spm waves hi to mkanat
<mkanat> Hey spm. :-)
<poolie> yay :)
<mkanat> poolie: Well, I'm in touch with spm.
<poolie> spm, mkanat is working on loggerhead
<mkanat> poolie: But he's not always around.
<poolie> oh ok
<poolie> mkanat: are you in the us? but you normally work evenings on this?
<mkanat> poolie: I am in the US. My schedule varies a fair amount.
<mkanat> poolie: I'm in California.
<poolie> ok
<poolie> there are a couple of people in the US
<poolie> mbarnett and . um
<mkanat> poolie: But I'd say generally I'm working between 9am and 11pm.
<spm> mkanat: have you been introduced to the other losas? mthaddon, Chex and mbarnett? Chex and mbarnett are roughly in your TZ.
<poolie> oh chex
<mkanat> spm: I haven't, no.
<mkanat> spm: I think what would be ideal is if you guys basically considered me the contact for loggerhead stability.
<poolie> so i think it would be nice if there was a conversation here about
<poolie> pain points, getting new versions rolled out
<poolie> getting you debug data from our deployment
<poolie> what else?
<spm> mkanat: scary: https://edge.launchpad.net/~canonical-losas/+mugshots
<mkanat> spm: Ah ha! :-)
<spm> poolie: we auto rollout lp-loggerhead, as distinct from 'loggerhead' every day if a new version is available? that's been in place for some time. ??
<mkanat> Hmm, I thought I had a picture on launchpad....
<mkanat> spm: I think at some point there's going to have to be a conversation about making a stabler branch of loggerhead that you guys can use, though.
<poolie> mb is particularly scary
<spm> mkanat: I can abuse my powa and give you an ... unsuitable one :-)
<mkanat> spm: lol.
<mkanat> spm: No, I have one, I'll go grab it and upload it.
<poolie> it's been years since i've seen the goatse guy
<spm> .....
<mkanat> Oh, I do have a mugshot.
<poolie> is there any suitable list where all these people could talk?
<mkanat> But I can't find the URL in the Wall Of Text.
<poolie> maybe it's enough to just have mail to losas@ plus max and me...
<mkanat> poolie: I imagine we're all on the bzr list, no?
<spm> would we need tim involved? or is this no longer in his baliwack?
<poolie> i don't know if the losas are
<spm> what poolie said
<poolie> probably it is
<mkanat> Maybe there should just be a loggerhead list.
<poolie> it's a bit between the cracks
<poolie> arguably lp-dev would be better
<spm> +1
<poolie> that's public, and fairly low traffic
<poolie> and the losas should be subscribed
<poolie> and i would like to see it have a bit more traffic
<spm> max, fwiw, lp-loggerhead is *vastly* more stable these days. the few occaisons I've been alerted in recent weeks, it's typically fixed itself before I could get much done beyond basic "is it really/still down?"
<poolie> spm, mkanat, what do you think?
<mkanat> spm: That's pretty good! :-)
<poolie> i'd like to see it give a better message when it does fail
<mtaylor> anybody know - if I'm doing a bzr-git dpush --- if I abort it after updating git map during generating git objects - will it have to do the git map all over again when I restart it?
<mkanat> poolie: Yeah, lp-dev would work.
<poolie> ideally with an oops-like identifier that can go into a bug report
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=like
 * poolie pets the bot
<spm> poolie: yah, lp-dev is fine by me
<poolie> spm the losas do all read it?
<spm> "no comment" ;-)
<spm> we are subscribed. reading implies... other things.
<poolie> i won't even bother asking about "understand" then :)
<spm> heh
<spm> I'd suggest it's a case of 'keep an eye on', vs read every thread. Most discussions therein are more at the code layer and only rarely touch on operational concerns. So that would tend to define the scheduling it gets in our attention span.
<poolie> that's fine
<poolie> so if the subject is clear, you'll read it
<poolie> that's what i though
<poolie> *thought
<poolie> so mkanat perhaps you would be kind enough to post a thread saying what you're up to and soliciting feedback from losas
<poolie> how do things get into lp-loggerhead?
<spm> not speaking for the others; but yes for me. Some persons who reply at top levels in a thread will also garner my attention. But that's a personal info filter.
<spm> poolie: thumper is probably best placed to answer that? or mwh if he's around.
<mkanat> poolie: Mostly by somebody asking, I think.
<mkanat> poolie: I think the trouble with loggerhead is that it has a great UI, but until recently it had massive, fundamental architectural problems.
<poolie> like you, if you think you've fixed something?
<poolie> mm
<mkanat> poolie: Yeah.
<poolie> also there is a project towards having an edge/beta loggerhead
<poolie> i'd like to know where that's up to
<mkanat> poolie: Well, that's basically what you're running in production.
<mkanat> poolie: Which is the problem.
<mkanat> poolie: Or at least, one of the problems.
<spm> production being edge, in this specific case? yes.
<poolie> i mean, a place by which new code can be exposed to realistic load
<poolie> and then something that updates more solwly
<mkanat> spm: Well, lp-loggerhead pretty much contains loggerhead trunk.
<mkanat> poolie: Oh, yes.
<spm> mkanat: kk, I'd assumed as much; but wasn't aware of the fine print - if any
<mkanat> poolie: That is definitely something we should have.
<spm> poolie: that's RT:38985 fwiw; apologies there - looks like it was languishing from not being correctly tagged (by us).
<poolie> oh ok i was wondering about that
<poolie> spm so you can look at that as making edge faster-moving, or lpnet slower-moving, or both
<poolie> at any rate getting a bit away from one-size fits all
<poolie> i guess to prioritize this it would be useful to know
<spm> when in doubt, raise it with tom/francis. we do try real hard to pay attention to the priorities, so please do actively manage those :-)
<spm> ha. snap. :-)
<poolie> - how often do rollouts cause problems?
<poolie> does mkanat or anyone else wish to roll out any faster?
<mkanat> No, definitely not.
<poolie> if we did roll out faster, would the feedback data get back to mkanat?
<poolie> "definitely not" want to go faster?
<lifeless> I'd like to be able to rollout every time that there is a fix :)
<mkanat> poolie: Right, definitely not want to go faster, at the moment, because it's trunk.
<spm> I'm not aware of any cases of a rollout causing problems - having said that, I don't we actually have too many either. so... :-/
<mkanat> lifeless: Right, but to do that, we need two branches.
<GradysGhost> Is this a bad time/room to ask for help?  Is there a better room for that?  It appears I'm interrupting something.
<mkanat> lifeless: We need an actually stable branch of loggerhead, preferably one with better test coverage on load issues.
<mtaylor> lifeless: generating git objects 2867/11230
<mtaylor> lifeless: perhaps I should have picked something other than drizzle to use as a test case :)
<mkanat> GradysGhost: This channel is fine.
<spm> given our current setup tho - if a rollout breaks; we can/do revert - I think automatically even for simple "it no responds correctly"
<spm> GradysGhost: go for it. we can always /ignore you ;-)
<GradysGhost> heh.  True.
<lifeless> mkanat: seems like you are well on the way to heaven
<mkanat> lifeless: lol
<GradysGhost> Okay, so I'm trying to set up bzr on my server so that only myself and a friend can commit changes to the working product.  Forgive me, but this is the first time I've ever worked with any kind of revision control system, so my terminology may not be correct.
<mkanat> GradysGhost: That's fine. :-) Is it a Unix system?
<mkanat> Or *nix, I guess I should say.
<GradysGhost> I've set up a Bazaar repository at /opt/bazaar/repository.  I've started bzr with `bzr serve --directory=/opt/bazaar/repository` and that appears to be working.  It is Linux Mint Helena.
<GradysGhost> I intentionally left off the --allow-write parameter since that appears to allow global writing.
<GradysGhost> The process is running as root.
<mkanat> GradysGhost: Okay. You just use basic *nix permissions to control who can write to the directory, and then you allow SSH access to your server from user accounts.
<GradysGhost> That's what I'm getting to.
<GradysGhost> It looks like everything should be in order, but it's still failing.
<GradysGhost> So I added a group and put my own user account into that group, then I recursively set the group ownership on the repo to that group.
<GradysGhost> Perms are 775 on all files, including the .bzr control directory.
<GradysGhost> So I do this: `bzr push --create-prefix bzr_ssh://ryan@localhost/path/to/branch`
<GradysGhost> And I get an error: bzr: ERROR: Permission denied: "earthcrash/client/": : [Errno 13] Permission denied: '/earthcrash'
<spm> poolie: as an aid to clarity. what is the .. governance (I guess) of loggerhead vs lp-loggerhead these days? aiui, lh is a stock oss project - that just happens to have large numbers of lp devs working on it, vs lp-lh which is the blessed version of same that we actually run with. ?
<lifeless> GradysGhost: you have to yse --allow-write, or the server won't permit *any writes*
<GradysGhost> Okay.  I'll try that.  That doesn't allow global write perms for anybody?
<lifeless> GradysGhost: it does
<GradysGhost> As long as world perms lack write?
<lifeless> GradysGhost: we recommend using the server with bzr+ssh or bzr+http if you wish to have people writing.
<GradysGhost> I have SSH installed.  What kind of config do I need to do to make it bzr+ssh only, disallowing write access to anyone without a valid account and auth?
<GradysGhost> SSH does work; I've been using it on this config for at least a year.
<GradysGhost> Well, at least 6 months.
<lifeless> GradysGhost: you are already setup then; just use bzr+ssh urls on your client machines.
<lifeless> GradysGhost: there is no need to have a continually running server
<lifeless> as the ssh server will start bzr when a bzr+ssh client connects.
<GradysGhost> Okay.  I gotcha.  I was under the understanding that I still needed to have bzr running in server mode.
<GradysGhost> That's very cool.  I was unclear on that.
<GradysGhost> I will try it out.  Thanks for the help, lifeless.
<poolie> hi spiv?
<mkanat> spm: lp-loggerhead has a bunch of modifications to loggerhead.
<mkanat> spm: Mostly about the environment that it runs in--Paste changes, and so on.
<mkanat> spm: It also represents the whole package that runs on launchpad, including any plugins, I believe.
<spm> mkanat: oki. so we do very much have a separate blessed version. I guess - who is the blessor in the usual case. ?
<mkanat> spm: It used to be mwhudson.
<mkanat> spm: The thing is, the loggerhead that's in lp-loggerhead is pretty much stock loggerhead.
<mkanat> spm: There are just a bunch of additional files.
<mkanat> spm: I suppose Peng also handles lp-loggerhead.
<mkanat> spm: It's probably a bit up in the air. Maybe thumper?
<mkanat> Anyhow, I'm out for the night. :-)
<mkanat> Later, folks!
<lifeless> it might be nice to factor those differences out
<spm> possibly. the question has come up in similar terms regarding lp as a whole. because we're dealing with prod code, and confidentiality of protected code (etc), we need a Canonical person to give the nod that X is ok to go into prod.
<lifeless> into a non-merged change so just config changes
<lifeless> then we could more easily experiment
<mkanat> lifeless: I agree completely.
<lifeless> mkanat: if you have time available in the contract, that would be good to do, then.
<mkanat> lifeless: Yeah, it's something I could talk to Francis about.
<thumper> lifeless, mkanat: hi, what's up
<thumper> ?
<lifeless> mkanat: please do :)
<mkanat> thumper: Oh, nothing. Was just wondering if you were in charge of the launchpad-loggerhead branch now.
<lifeless> thumper: just chewing over loggerhead - it came up on the bzr list
<thumper> the launchpad-loggerhead branch has been merged into launchpad proper
<mkanat> poolie, lifeless: Can you send me an email or something to remind me to do all the things we talked about just now?
<mkanat> I'd do it myself but I have to run.
<lifeless> thumper: nothing in particular on de agenda; see the backlog for nitty details
<thumper> as of a few months ago
<mkanat> thumper: Oh!
<mkanat> So that's done.
<lifeless> cool
<lifeless> thumper: you really should give Guido his time machine back.
<mkanat> Anyhow, I do have to go.
<lifeless> thumper: I hear he needs it to make Python3 nice.
<spm> night max!
<mkanat> Later!
<mkanat> lifeless: HAHAHAHAHAHA.
<lifeless> mkanat: ciao
<thumper> mkanat: ttfn
<mkanat> Later. :-)
<thumper> lifeless: perhaps just fixing up strings and WSGI
<thumper> lifeless: which I hear is a bit of poo
<lifeless> its a bit contentious
<lifeless> email too is in trouble
<thumper> really?
<thumper> damn
<lifeless> thread today about a use case where its - I think - 18 times slower. Or something, I skimmed it.
<thumper> I don't really follow py-dev
<thumper> lifeless: about the last revision bug, I really think it is a bzr bug
<thumper> lifeless: as it happened locally on the guys machine
<thumper> lifeless: his local reconcile fixed it, but push --overwrite didn't update LP
<poolie> spm: good question about governance
<poolie> i'll be the canonical manager and mkanat is the technical lead
<spm> ahh, excellent. good to know. ta.
<lifeless> thumper: ok let me look for a bug
<poolie> iow if you have bugs talk to mkanat, if he doesn't answer talk to me :)
<spm> ha, kk, will do.
<lifeless> thumper: ok, no open bugs I can see. Please change the product to bzr and gimme th enumber again.
<lifeless> thumper: or just gimme the number and I'll do it all
<thumper> lifeless: ok, let me look
<thumper> https://bugs.launchpad.net/bugs/599492
<ubot5> Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,Incomplete]
<lifeless> thumper: there are two bugs here but neither in lp-code.
<thumper> I thought so
<lifeless> As for the branhc in question
<lifeless> just reconcile it
<lifeless> on lp, if you could
<poolie> spiv bug 599670 is the one i alluded to on the phone
<ubot5> Launchpad bug 599670 in Bazaar "ValueError: absent factory in _stream_to_byte_stream during push (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/599670
 * spiv looks
<mtaylor> dude. this bzr-git dpush has been running for 3.5 hours
<lifeless> mtaylor: dpush will be rebasing your local history
<lifeless> mtaylor: you probably didn't want dpush.
<lifeless> mtaylor: I like to think the D stands for 'do not want'
<mtaylor> lifeless: well, it said that push wasn't supported
<lifeless> mtaylor: ><
<lifeless> mtaylor: I'm really serious, its going to be stripping all your local history down to zip, and rewriting it as a import from the git representation
<mtaylor> lifeless: so I should cntrl-c this
<lifeless> mtaylor: depends, do you value your life with other drizzle devs?
<mtaylor> lifeless: :)
<lifeless> I'd use bzr fast-export || git fast-import
<lifeless> for maintaining the git mirror
<mtaylor> lifeless: ah.
<lifeless> dpush is pretty bad, because you can't simultaneously do it to hg and svn
<lifeless> (the code quality is ok, its the concept that hurts)
<mtaylor> lifeless: ok... I guess I should learn about fast-export
<mtaylor> lifeless: sigh
<mtaylor> fatal: Path libmysql/libmysql.c not in branch
<mtaylor> lifeless: why do I get the feeling this is going to be fun
<lifeless> mtaylor: FSVO painful ?
<mtaylor> lifeless: yup
<mtaylor> lifeless: I'm guessing this has to do with bzr tracking renames and git not so much doing that
<lifeless> fast-export can include renames
<lifeless> FTW
<mtaylor> yup. so that doesn't work
<lifeless> file bugs
<lifeless> and tell your git fanboy devs to suck it up ?
<mtaylor> lifeless: should I file bugs against git or bzr?
<lifeless> mtaylor: which process blew up
<mtaylor> lifeless: I'm guessing git, since it's the one that crashed
<lifeless> check the stream did include the file creation and rename
<lifeless> but yes, I suspect so
<mtaylor> lifeless: M 644 inline libmysql/libmysql.c shows up in the stream
<lifeless> looks sensible to me
<lifeless> is the fail on a rename of that?
<mtaylor> yes
<lifeless> sounds like a boog to me
<mtaylor> well, it would be great if there was a report-a-bug link on the git website.
<mtaylor> lemme go ask in #git
<lifeless> ...
<lifeless> I need a hallway check
<lifeless> what would you expect 'before:thread:foo' to resolve to ?
<lifeless> [this is open to the floow]
<poolie> i don't know
<poolie> where would i find help about the meaning of 'before:'?
<lifeless> bzr help revspec
<mtaylor> lifeless: I'd expect it to resolve to the thread before foo?
<lifeless> sorry
<lifeless> revisionspec
<poolie> i thought that was it but it doesn't work
<mtaylor> lifeless: oh - hrm
<lifeless> mtaylor: great, thats what I was hoping someone would say.
<poolie> i would have thought the penultimate revision in foo
<lifeless> and thats the other answer
<poolie> however saying "the thread under foo" would be useful
<mtaylor> lifeless: before == parent of the revision - thread: is tip of a loom
<poolie> but i'd expect that to have a different name
<lifeless> ok
<lifeless> that was the tension being considered in a bug
<lifeless> I'll go with below
<mtaylor> lifeless: so - parent of the tip of the loom
<lifeless> below:tread:foo
<lifeless> so you can say
<lifeless> before:below:thread:foo
<spiv> lifeless: +1 for below:
 * poolie is putting 2.1.2 into the ppa
<lifeless> \o/
<poolie> me too
<poolie> :qa
<lifeless> ZZ?
<poolie> so what's the right way to bring in upstream changes from another branch, using builddeb?
<poolie> just plain merge?
<mtaylor> poolie: that's what I do
<poolie> ah http://jameswestby.net/bzr/builddeb/user_manual/normal.html answers pretty well
<poolie> merge-upstream with the tarball and the upstream branch
<lifeless> yes
<lifeless> poke me if it blows up - it may
<lifeless> you may need an import-upstream first, depending on the packaging state.
<lifeless> I've been improving this recently.
<poolie> is there a special Command attribute for example help?
<lifeless> vs the main prose?
<poolie> yes, and no, there isn't
<poolie> only a todo wishing for one :)
<lifeless> Not currently, that might be nice; probably wants to be a list or dict or something.
<poolie> spiv if you wanted you could post an rfc on how to clean up merge
<poolie> or talk to vila perhaps
<poolie> the strasbourgeouis teddybeaor
<spm> having a brain blank moment here. bzr push to remote server. now have a dir with .bzr in it - how do I expand that to have the various versioned files in that same dir? I thought bzr up would do that, but "bzr: ERROR: No WorkingTree exists for..." ?
<spiv> spm: 'bzr co .' in the server
<spm> argh. thanks spiv.
<spiv> Or perhaps 'bzr co SOME-OTHER-DIR' if you'd like to keep the history and the tree-on-disk separate :)
<spm> heh, not really. someones +junk that I've pulled locally. pushed to where it needs to be run. so... carefactor :-)
<spiv> Or perhaps just use the bzr-upload plugin in the first place.
<spm> pish tish :-)
<spiv> Having a working tree on a remote branch you 'bzr push' to is a bit of an attractive nuisance because the tree won't get updated automatically.
<spiv> So it's often an sign that you want to be doing something a bit different.
<spm> technically in this case? purty much. scp would have worked better. but bzr push is so *easy*.... ;-)
<lifeless> spm: have you tried bzr upload ?
<lifeless> spm: its the bomb
<spm> I have not. or ... perhaps not in quite a while at any rate.
<vila> hi all
<poolie> hi vila
<vila> lifeless: when a config file is saved for the first time, the config dir didn't exist so it needs to be created and the first point where this is required is when the lock is taken
<lifeless> vila: we used to have code that did that already, but I don't see it being deleted.
<lifeless> vila: if its not being deleted, we now have code duplication.
<vila> I removed some duplications laready, I may have missed some though
<vila> lifeless:
<vila> grrr
<vila> lifeless: "This seems like a case where two threads would be nice" as in loom threads ?
<lifeless> yes
<vila> I was very tempted :)
<vila> oh, wrong _write_config_file citation, when the IniConfig class is used (no lock there) then the point where ensure_config_dir_exists is required is when we want to *create* the config file in this dir
<vila> lifeless: this call has been added to *remove* code duplication in the various set_user_option() calls
<lifeless> vila: I'm concerned that this will make bzr worse than it was about creating/checking dirs.
<vila> lifeless: no worse than before since these calls were already there
<lifeless> ok
<poolie> which "this" makes it worse?
<vila> ensure_config_dir_exists()
<vila> lifeless: "Also see my ordering suggestion " the threads ?
<vila> lifeless: "may help you not to need this at all", what is 'this' ?
<lifeless> ordering of break lock checks
<lifeless> this is your exception
<lifeless> the subject of the paragraph
<vila> I can't break a lock if there is no lock dir
<lifeless> yes
<lifeless> I get that; I feel like you haven't really thought about the suggestions I've made. I'm sure thats just me though.
<lifeless> What can I do to help you understand my suggestions?
<vila> lifeless: hmm, tweak my code and run the tests ? -s bt.test_config -s bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home  -s bb.test_break_lock.TestConfigBreakLock are the ones I have in my history and should cover most of the edge cases I encountered
<vila> a point easy to miss is that the config dir doesn't exist in *many* cases (especially during the tests) and we have a surprising number of cases where we read or set one variable
<vila> I certainly need to better explain why and how I fixed the bug (I completely forgot to post the COVER file I had prepared...)
<poolie> bzr 2.1.2 for dapper just sent to the ppa
<poolie> i think
<lifeless> poolie: Cool
<poolie> i think
<poolie> there's a few minutes lag
<poolie> it's always a bit "did that happen or not?"
<lifeless> vila: I trust that the code and tests work. I'm talking about the design and structure of the patch, not the red/green tests passing component.
<lifeless> vila: meet me halfway :)
<lifeless> vila: As far as I can tell you've made 'bzr break-lock (remote url) much slower.
<vila> lifeless: As always, you know I'd love to do that, show me where ! :) I'm adding docstrings and a better cover letter, let's talk about the result or give me more precise indications
<lifeless> vila: Tell me more about the bits of the review that confuse you
<vila> much ? config files are always local (well the ones we're talking about here)
<lifeless> vila: but your code *looks* for the config file first.
<lifeless> vila: rather than looking for the bzrdir first.
<lifeless> vila: unless I misunderstand it, which is possible.
<vila> if I look at the bzrdir first I can't say if it succeeded or failed and whether I should try the config ones
<lifeless> vila: then lets solve the UI problem differently.
<vila> hehe, I punted on that after trying :)
<lifeless> How about '--config' as an option to break-lock
<lifeless> bzr break-lock --config
<lifeless> which will DTRT on windows, doesn't need people to know where the config is.
<vila> if that's the only remaining point of disagreement I can see why :)
<lifeless> vila: I don't recall the full review offhand.
<vila> it won't address the 'bzr break-lock' just do the right thing, thanks, I hate copy/pasting :)
<lifeless> vila: but if you think that with that you can complete the review changes easily, why thats great.
<vila> I *can* go further and change the way break_lock works for all cases but that's definitely more work that I thought was necessary
<lifeless> vila: I don't think that 'bzr break-lock' needs to be magic: its a recovery tool used when things are interrupted by flaky networks or crashes.
<lifeless> vila: I think a simple if config: config-path else: bzrdir-path will be easy, give a nice UI.
<vila> well, it *is* magic today, *I* *never* specify location (nor had to)
<lifeless> vila: most users have to most of the time they use it.
<lifeless> IME
<lifeless> I know this because we give out the wrong URL for lp branches today and they turn up here a lot :)
<vila> good enough then, the bug is pretty hard to encounter I think so recovering from it will remain exceptional
<vila> but that's exactly where using 'bzr break-lock' without arguments *does* the Right Thing ;)
<lifeless> vila: I'm really not convinced by this
<vila> and even when you give a location, there are a lot of magic (checkout, master branch, branch and repo from wt, you name it)
<lifeless> vila: Here is what I see:
<lifeless>  - you have an ambiguous exception (type doesn't match what the caller cares about all that well)
<vila> true
<vila> it's tailored for the specific need
<vila> that's not ideal
<lifeless>  - you add a VFS probe that isn't needed when the URL is a remote URL, and we want to *remove* those across the code base, VFS is deprecated.
<lifeless>  - Users are already following documentation to get to this command, so there is no particular need to have it be magic
<lifeless>  - Its possible for the magic to be very wrong. What if they have ~/.bazaar/ under bzr controll ?
<vila> meh for last point, --config is ok for the previous ones
<lifeless> vila: I don't know what you mean by that sentence.
<vila> what's the problem with having .bazaar versioned ?
<lifeless> bzr init ~/.bazaar
<lifeless> bzr commit ~/.bazaar -m "This cannot be break-locked"
<vila> lifeless: I think --config being required to break config locks is a good solution that addresses the points (minus the last one I don't understand)
<lifeless> vila: ok, thank you. I thought you were still arguing for magic.
<vila> no no
<vila> I *tried* to respect the magic, if I don't have to... I won't :)
<vila> but I still don't get why you can't break lock in ~/.bazaar if it's versioned ? Are you arguing that people will version control the lock files ?
<vila> huh ? Did anybody knows what the 'show' parameter to cmd_break_lock.run() has been supposed to mean ? It's not used...
<vila> show == dry-run ?
<lifeless> vila: it shows whether there is a held lock, or used to.
<lifeless> vila: say ~/.bazaar is versioned
<lifeless> vila: and magic is present
<lifeless> vila: now, say that the machine crashes while the working tree's lock is held.
<vila> it won't break the wt lock
<lifeless> vila: and to make it really obvious, say that the config dir lock is also held - e.g. bzr-svn had kicked in and was updating stuff.
<lifeless> vila: right.
<vila> lifeless: nice catch
<lifeless> vila: and there wouldn't be any way to make it break it either.
 * lifeless takes a bow
<lifeless> when designing magic
<lifeless> think *really really* paranoid.
<vila> there is a way: run break-lock twoce, hard to discover though
<vila> twice
<lifeless> I'm not sure that would work, would it ?
<lifeless> because it would find the config lock that isn't held, and stop
<vila> eeerk
<vila> err, no, there are tests covering that
<vila> damn, the tests are wrong
<lifeless> vila: anyway, --config avoids this, and is simpler to talk about I think.
<vila> +8000
<lifeless> so lets do that, and you can buy me a beer for finding your bug, at the epic :)
<vila> hehe
<poolie> Value "bzr+ssh://bazaar.launchpad.net/~bzr/bzr/packaging-dapper/" is masked by "lp:~mbp/bzr/packaging-dapper" from locations.conf
<poolie> were we going to change that?
<lifeless> yes
<lifeless> I hate that.
<lifeless> I was going to do a spike, I ran out of tuits.
<lifeless> bbiab, food n stuff time.
<poolie> GaryvdM: hi there
<poolie> GaryvdM: we do have a vm with the developer tools
<poolie> it's on ec2 and currently shut down
<poolie> i can start it back up for you
<poolie> vila, did we once have a copy of configobj and then later remove it?
<poolie> it seems like that breaks dapper support
<vila> poolie: this doesn't ring a bell, we updated it several times but I don't remember *replacing* it (aka changing the file-id)
<vila> IMBW
<poolie> i think it was deleted in the packaging branch
<poolie> incorrectly, if you want the branch to work on dapper
<GaryvdM> Hi poolie.
<GaryvdM> I can't do it now. I can do it this evening.
<jelmer> poolie: I removed it in the Debian packaging
<GaryvdM> And I merge the debian branch into all the packing-* branches. Opps
<GaryvdM> *merged
<CaMason> I've done a `bzr pull --overwrite` and there are text conflicts. How can I ask bazaar to just overwrite those conflicts with the versions in the repo?
<GaryvdM> poolie: I'll ask jam for access this evening.
<lathiat> CaMason: bzr revert <file>
<vila> CaMason: resolve --take-other should address that but if you encounter conflicts here it means you have uncommitted changes in which case you ought to check that you really want to get rid of them, so 'bzr revert' may be better suited
<CaMason> I effectively want to switch to a different branch, losing all changes / commits / working tree changes
<vila> bzr revert then
<spiv> I suppose there could be an argument for adding a 'bzr switch --revert' flag for that use-case.
<lifeless> ?
<spiv> lifeless: <CaMason> I effectively want to switch to a different branch, losing all changes / commits / working tree changes
<lifeless> related to 'I want to shelve them all'
<spiv> lifeless: (they did a pull --overwrite, and got conflicts.)
<lifeless> I think I'd like it if we added a shelve, and that gets close while covering more use cases
<spiv> Perhaps, this was just a quick idea before I disappear for dinner etc :)
 * spiv -> dinner etc
<lifeless> sure
<lifeless> same
<lifeless> well, have eaten, I mean it was also a quick idea
<CaMason> back
<CaMason> ok, so it's just a case of bzr revert, and deleting some of the *.moved files?
<CaMason> I know this is a broken workflow... it's a messy environment I've been having to work with
<lifeless> bzr revert
<lifeless> bzr resolve --take-other
<lifeless> or so
<CaMason> I do believe `bzr resolve --take-other` said that the argument didn't exist. Sec..
<CaMason> "ERROR: no such option: --take-other"
<lifeless> ah thats in a newer bzr
<lifeless> so:
<lifeless> bzr resolve
<lifeless> remove any .moved files
<lifeless> sorry
<lifeless> revert
<lifeless> then remove .moved files
<lifeless> then resolve --all
<CaMason> ok thank yoyu
<parthm> i am trying to use assertRaises in a really simple test case. but it seems the the exception is not being handled by assertRaises. Am i doing something wrong? http://pastebin.com/aATNseAC
<lifeless> I haven't looked at the pastebin
<lifeless> but the usual gotcha
<lifeless> is that you are calling your function
<lifeless> which means that assertRaises hasn't actually started running yet
<parthm> no. i checked that "self.assertRaises(errors.InvalidPattern, p.match, 'foo')"
<lifeless> you have to use assertRaises like addCleanup - you give it something to call.
<lifeless> ok
<lifeless> hmm, I will look - sec
<lifeless> see how it is in __getattr__
<lifeless> its the lazy thing tripping you up
<lifeless> define a lambda
<lifeless> assertRaises(InvalidPattern, lambda:p.match('foo'))
<lifeless> you'll want a comment noting why this is needed.
<parthm> yup. that worked. thanks :) ... i will add the comment.
<mkanat> thumper: So, are you managing loggerhead development now?
<mkanat> jam: ping
<jam> morning mkanat, haven't seen you around this early before :)
<mkanat> jam: Yeah, I'm up early. :-)
<jam> GaryvdM: are you around?
<jam> mkanat: what TZ are you in?
<mkanat> jam: America/Los_Angeles
<mkanat> jam: Do you have a few moments to help me figure out what's up with meliae on my system?
<GaryvdM> Hi jam
<jam> yeah, it will be maybe 10 min, but then I'll be able to work with both of you :)
<GaryvdM> jam: I'm done at work to :-)
<mkanat> jam: Okay. :-)
<GaryvdM> Cool
<jam> hi mkanat
<mkanat> Hey jam. Good timing. :-)
<jam> mkanat: so, first off, grab my meliae branch at lp:///~jameinel/meliae/skip_static_type_traverse_bug_586122
<jam> which I think you have
<jam> but I wanted to make sure
<mkanat> jam: Yeah, I do have it.
<mkanat> Tree is up to date at revision 143 of branch bzr+ssh://bazaar.launchpad.net/~jameinel/meliae/skip_static_type_traverse_bug_586122
<jam> k, run python setup.py build_ext -i && python run_tests.py
<jam> and see if it builds and then runs the tests successfully
<mkanat> Ah, I get a bunch of test failures.
<mkanat> I'll pastebin them.
<mkanat> Let me start with a fresh checkout first, though.
<mkanat> jam: http://pastie.org/1025109
<jam> so to start with the 'get_memory' not implemented is something I should probably implement, but shouldn't be an issue here.
<jam> The bigger one is the 'intset' failures
<jam>     self.assertEqual(10000, len(iset)) AssertionError: 10000 != 259
<jam> says that I added 10k items, but now we are only seeing 259 in the set
<mkanat> jam: If you need it, I can get you a shell on my machine.
<jam> mkanat: I might, this is probably specific to 64-bit or something
<mkanat> That seems likely. Or having something to do with my compiler flags.
<mkanat> (Which are just the default compiler flags that Python is built with on Fedora, FWIW.)
<mkanat> jam: If you need it, just email me your ssh key and whatever username you want.
<jam> well it is IDSet that is failing, which is especially suspect since you're on 64-bit
 * mkanat nods.
<jam> mkanat: sent
<GaryvdM> jam: I'm reading docs atm.
<jam> mkanat: any ideas why "long myint; myint = 0x08; myint <<= 60, wouldn't end up with 0x8000000000000000" ? would it be a signed issue?
<mkanat> jam: I really haven't done much C development in years, so it's hard to say.
<jam> mkanat: it was my formatting.
<mkanat> jam: Ah, okay.
<jam> I was printing using %x but needed %lx
<mkanat> Ah, okay. That's surprising, I'd expect that to Just Work on 64-bit architectures.
<maxb> %x is specified as taking an int quantity
<maxb> common 64-bit architectures are LP64, i.e. ints are still 32 bits
<jam> yeha
<jam> yeah
<mkanat> Yeah. Further proof that C is not really a high-level language.
 * mkanat shrugs.
<jam> mkanat: so no luck tracking it down yet, but still working on it, had some dead ends because of stuff like that
<mkanat> jam: Okay.
<Phoenixz> Question.. Someone really borked up a merge, committed those changes, made a push to a centralized repo, we did a pull from there.. Now we have quite a mess.. Can I somehow undo this commit he made and have it undone in all repositories?
<Phoenixz> I tried uncommit in my local repo, but when I do a pull from the central repo, I get that very same revision back again..
<GaryvdM> Phoenixz: You can do either:
<GaryvdM> bzr push --overwrite, but then everyone else needs to do bzr pull --overwrite
<GaryvdM> or
<GaryvdM> bzr revert -r -2 && bzr commit "Revert stuff up..."
<GaryvdM> and push
<Phoenixz> GaryvdM: ah, a brz revert -r will revert a specific commit, and then store those changes so with a pull / push everyone will recieve that revert?
<GaryvdM> The second option will show in the history.
<GaryvdM> Phoenixz: Yes , after you do a commit
<Phoenixz> GaryvdM: excelent. Thanks!
<GaryvdM> Phoenixz: Hmm - maybe that is not the best option
<Phoenixz> GaryvdM: what would be better?
<Phoenixz> GaryvdM: Im also considdering the push --overwrite.. that way, there is no garbage in the history..
<GaryvdM> Phoenixz: because then bzr will think that the branch he was trying to merge, is succussfully merged, which it is not.
<GaryvdM> Phoenixz: If you do uncommit & push --overwrite then it will not think that it is merged
<Phoenixz> ok
<GaryvdM> Phoenixz: just make sure to tell everyone that is gonig to pull about this.
<Phoenixz> GaryvdM: that won't be a problem, I'll go for the uncommit and push --overwrite
<GaryvdM> Ok
<mkanat> So, the best migrator for CVS right now is cscvs, yes?
<mkanat> I guess I should be asking jml or mwhudson, per the "top contributors"?
<jam> I would actually say cvs2svn (which has cvs2bzr in the suite)
<jam> mkanat: ^^
<jam> It is what I've been using
<jam> cscvs is probably the most robust in some senses, but requires much more effort to get working
<mkanat> Okay. Yeah, we just need to migrate a single branch, once.
<chaosaddict> when importing into bazaar, has anyone else run into problems with latin-1 encoded filenames or files?
<SpamapS> so I want to use bzr-builder with a tarball from an upstream, do I have to first import the tarball into a bzr branch, then run my recipe?
<james_w> hi SpamapS
<james_w> SpamapS: you would, yes, but bzr-builder isn't going to be particularly interesting with a single upstream tarball. What is it you wish to accomplish?
<SpamapS> james_w: just wanted to maintain the packaging in my own branch without all the upstream source
<james_w> SpamapS: well, you're wrong, but even so, that is supported in bzr-builddeb, see "merge mode" :-)
<SpamapS> wrong?
<SpamapS> or misguided?
<james_w> http://jameswestby.net/bzr/builddeb/user_manual/merge.html
<SpamapS> I don't think I actually suggested any sort of solution, just a desire.. so not sure how I can be wrong.
<james_w> SpamapS: yeah, sorry, misguided
<SpamapS> Well enlighten me
<james_w> SpamapS: I was only trying to be funny though, it's perfectly supported, just not my choice
<SpamapS> I'm totally new and have no preconceptions about large scale package maintenance, so now is the time to set me in the right direction.
<james_w> I just think it is more useful to have all the code to hand, and to be able to track their co-evolution, which helps as things start to get trickier.
<SpamapS> yeah I'm seeing that actually
<SpamapS> its actually quite annoying having the packaging in its own branch
<james_w> I agree that it's not so nice having the extra data carried around that is in some ways redundant, and for simple things having a more focused view of just the packaging can be useful
<SpamapS> but I got the idea that people were doing that on a regular basis
<james_w> yeah, if you are upstream then you can ship the packaging in your branch, but even then people will still tend to want to modify it, as packaging that works across all releases of all (.deb-based) distributions is going to be rare.
<SpamapS> vendors have been doing that for .spec files for a long time
<mtaylor> SpamapS: I was just telling you yesterday about keeping the branch and packaging in the same branch...
<mtaylor> SpamapS: you may find http://rbtcollins.wordpress.com/2009/12/19/debianising-with-bzr-builddeb/ interesting
<mtaylor> SpamapS: that's the process I use
<SpamapS> mtaylor: right I still hadn't chewed through that process yet
<SpamapS> no better time than now I guess
<mtaylor> SpamapS: I promise - once you do, you'll like it
<mneptok> mtaylor sounds like a drug dealer.
<mtaylor> mneptok: I _am_ a drug dealer
<mtaylor> mneptok: but sssssh
<mneptok> "Try it ince, you'll love it. Your first taste is free."
<mneptok> *once
<SpamapS> mtaylor: so I never bzr add debian, right?
<mtaylor> SpamapS: nope. doing the import-dsc step will do that for you
<mtaylor> SpamapS: also, be sure to look at the bzr mark-uploaded command once you upload packages to the repo
<mtaylor> SpamapS: that way you can get the fine folks over in #launchpad to make the UDD listings for your package actually use your packaging branch
<SpamapS> weird
<SpamapS> so I bzr added debian so I could use bzr-buildpackage .. and then it won't let me bzr revert debian
<SpamapS> oh wait no, it just won't delete it
<SpamapS> silly build artifacts
<mtaylor> SpamapS: oh - also, this is going to be weird with gearman-interface since the upstream tarball doesn't match the upstream bzr...
<mtaylor> SpamapS: I should perhaps come up with a better plan for how gearman-interface source works...
<ssylvan> Does bzr have a way to create a local branch in the same working tree (to avoid having to re-configure apps that make assumptions about paths etc.)?
<SpamapS> mtaylor: I think it works ok
<mtaylor> ssylvan: yes, but it's not particularly easy or exposed in the UI directly quite yet  ... co-located branches is the thing you're wanting here
<SpamapS> mtaylor: I'm settled on producing source packages for each language rather than trying to let the main one build them all
<ssylvan> mtaylor: thanks
<SpamapS> mtaylor: the complexity of the latter overrides its pure-correctness
<mtaylor> ssylvan: although I'd love to be an asshole for a moment and suggest that any app that makes assumptions about paths is broken in some way ;)
<mtaylor> SpamapS: indeed... I'm just saying that robert's process I pasted in above assumes that the tarball is some reflection of the branch
<mtaylor> ssylvan: the write up on the work to implement it is at http://doc.bazaar.canonical.com/developers/colocated-branches.html
<ssylvan> mtaylor: Well every IDE I've used will make assumptions about where to find various libraries, headers etc. It'll be based on environment variables, sure, but I'd rather not have to update all of them just to work on some separate feature in its own branch real quick...
<mtaylor> ssylvan: indeed.
<mtaylor> ssylvan: it's a flaw/bug in every IDE - but it is the case :)
<mtaylor> ssylvan: ah - this might be helpful at the moment:
<mtaylor> http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
<mtaylor> ssylvan: I have not used it myself, so I can't vouch for it
<SpamapS> mtaylor: ah .. true.. but I think it will be "ok" in this case, because I imported your pypi tarball
<SpamapS> ugh and now i just realized I pushed to ~me/gearman-interface instead of ~me/+junk ..
<mtaylor> SpamapS: right - but that's what I was saying, robert's workflow starts with a branch of upstream and imports the tarball on top of it (which means you can pull in changes from upstream really easily)
<mtaylor> SpamapS: but, of course, the way you are doing it will totally work
<SpamapS> mtaylor: yeah ... and I'm done maintaining packaging separate from upstream. all the debian tools want to work on ./debian not ./
<SpamapS> yay! "Start in 4 hours" ... yesterday it was 23
<ssylvan> mtaylor: well, not sure it's a flaw. It needs to know where to find stuff somehow, and not everything can be kept in the same repository, so relative paths are out.
<andresj> Hello, I want to use the push-and-update plugin on a project, but I don't want it to interfere with other projects. Is there a way I can install it somewhere else from ~/.bazaar, or to enable it on a per-repository basis?
<mtaylor> ssylvan: I strongly dislike that IDEs often skip the configure step in favor of 700 configuratoin dialogs, which leads to exactly your problem. if IDEs had better integration with existing build system instead of inventing their own, it wouldn't be nearly as much of an issue
<ssylvan> The build system still needs to know where to find each component, and if working on a feature for one of those components changes the path then I can't quickly switch without having to somehow reconfigure the build settings which is annoying.
<mtaylor> ssylvan: I'm a bit of a snob for build systems that know how to discover dependencies and do not require a dev to spend time setting up a tree to be sueful
<mtaylor> ssylvan: right. but that's why I'm saying it's a flaw in the IDE design. I do not have this problem in any of the build systems for any of the projects I work on... it is a totally solvable problem, it's just that the IDE designers choose to not care about it enough to fix it
<mtaylor> ssylvan: it's certainly not the fault of the users of the IDE
<mtaylor> and with that off-topic rant (apologies) ... I will now go get lunch. :)
<ssylvan> ssylvan: I don't think it's a flaw at all. When the compiler needs to find a header or the linker needs to find a lib it NEEDS to know where those are located, regardless of IDE. So the build system will have a depedecy on a path, or an environment variable. If I do a quick branch for a small feature, changing the path, I don't want to have to modify the build configuration... I *could* but it's just unecessary hassle which just leads to me not 
<ssylvan> that was for mtaylor, not myself obviously
<ssylvan> Anyway, the solution is to be able to easily create quick local branches that are located on the same path and you can switch between them quickly. That way any config files relying on that path will not need to be updated.
<mtaylor> ssylvan: totally... that is certain a solution ... but another solution is just running ./configure in the new branch - I think your solution of co-located branches is an important one to have...
<mtaylor> ssylvan: I just think that it is _also_ a deficiency in many IDEs that I cannot choose to take the other solution
<ssylvan> mtaylor: You'd still need to modify the configure script to tell it that you want branch B not A. Also, the problem is that ./configure may not be quite as fast as you'd hope... We have dozens and dozens of complicated dependencies and external applications and even though it really is automatic to switch my path around (I just need to change one file) it takes a long time to go through and verify all of that..
<GaryvdM> jelmer: I'm tryng to build windows installers. The build script is trying to download http://subversion.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip , which no longer exists. I am struggling to fine alternatives. Could you give me any pointers on where to look?
<GaryvdM> *find
<jam> GaryvdM: well, after some chasing I did find: http://www.collab.net/downloads/subversion/
<jam> but those look like runtime and not developer stuff
<jam> GaryvdM: and I just followed your link, and it gave me a download
<jam> looking here: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11129&expandFolder=11129&folderID=0
<jam> 1.6.6 is the latest uplead
<jam> upload
<jam> although subversion.apache.org says there is a 1.6.12
<GaryvdM> Thats odd I could not access it just now...
<GaryvdM> jam: they were maybe doing maintenance..
<GaryvdM> jam: we may need to look a building the latest in the future.
<jam> GaryvdM: I'd *really* like to avoid setting up a subversion build stack if we can avoid it
<jam> somehow saying: "if you want to build the windows installers, first set up a subversion development environment" really doesn't sound right
<GaryvdM> Yes
<GaryvdM> jam: http://pastebin.org/368612 - It seem that the server requires cookies.
<jam> I thought we had something a while back about passing the username + password (for anonymous access) in the url
<GaryvdM> If I clear my cookies, and got to http://www.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip, I get redirected to http://subversion.tigris.org/servlets/ProjectDocumentDownload?documentID=46880, and then back to ttp://www.tigris.org/files/documents/15/46880/svn-win32-1.6.6.zip, which does not happen if I don't clear my cookies.
<jam> For example: http://guest:password@tortoisesvn.tigris.org/svn/...
<jam> hmmm
<jam> I really don't know hexagonit well. Perhaps sidnei (da silva) will show up sometime and we can ask him
<awilkins> jam: Shouldn't you just be able to use the older windows dev pack for builds and bundle the latest libs? The API won't have changed?
<jam> he was the one who did a lot of the work
<jam> awilkins: well, who has the latest libs ? Extract it from the installers?
<jam> (this is supposed to be a mostly-automatic build process)
<awilkins> Humph
<jam> awilkins: http://subversion.apache.org/packages.html#windows talks about full builds and links to http://www.collab.net/downloads/subversion/
<awilkins> They had bundles which were just archives the last I looked but reading up you may be having trouble auto-downloading them
<jam> that has source code and executables
<jam> but I don't see any developer builds
<jam> and now requires a login to proceed
<awilkins> Darn, used to know where they were when they were on tigris.org
<GaryvdM> jam: Right now I don't have a good answer, so I think I should carry on without bzr-svn, and come back to it later
<jam> awilkins: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11129&expandFolder=11129&folderID=11129
<jam> which is where we are getting them from
<jam> which only has 1.6.6
<jam> and is causing problems for us to automate the download
<jam> seems to work fine in a browser
<jam> but not in hexagonit (buildout)
<jam> GaryvdM: sure, though we would be a bit hard pressed to have an official build without them
<awilkins> jam: wget seems to grab them OK
<jam> I think one option is to download them manually into build-win32/downloads
<lifeless> cache it on lp?
 * jelmer waves
<jam> awilkins: I think wget saves cookies, and python's httplib does not
<GaryvdM> jam: sure
<GaryvdM> Hi lifeless, jelmer
<jelmer> GaryvdM: you're having trouble getting a particular feature of bzr-svn to work?
<GaryvdM> jelmer: I'm trying to build windows installers
<jelmer> GaryvdM, ahh
<jam> lifeless: lp:python-six
<lifeless> yah
<lifeless> thanks for that ref
<jam> jelmer: I'd like to do a new release of meliae, I don't quite remember what the process was last time
<lifeless> I think we rather drained the topic dry for now at least though
<jam> sure
<jam> I sent it mostly for you
<jam> since you were poking at py3
<lifeless> thank you :)
<jelmer> jam: When you've got a tarball out let me know and I'll upload to Debian/Ubuntu.
<GaryvdM> jam: I'm getting this error: http://pastebin.org/368639
<GaryvdM> jam: I think we just need to install sphinx-builld
<GaryvdM> easy_install -U Sphinx
<jam> GaryvdM: 1.0b2 installed
<GaryvdM> jam: thanks
<jelmer> jml: hi
<mkanat> I'm guessing that bzr-fastimport trunk is stable enough for use?
<jelmer> mkanat, yeah, I think so
<mkanat> Okay.
<jam> jelmer: https://edge.launchpad.net/meliae/0.2/0.2.1rc1
<jam> 0.2.1rc1 tarball has been uploaded
<jelmer> \o/
<jml> jelmer, hello
<jelmer> jml: You had a nice introduction to getting started with the launchpad API somewhere, is available somewhere publicly?
<jml> jelmer, yeah, it's on my blog
<jml> jelmer, http://code.mumak.net/2010/03/launchpadlib-gotchas.html is the final part and links back to the first two parts
<jelmer> jml: Thanks!
<poolie> hi all
<poolie> hi jelmer, garyvdm
<poolie> mkanat, jam
<mkanat> Hey poolie. :-)
<jelmer> g'morning poolie
<GaryvdM> Hi poolie
<poolie> happy new australian financial year :)
<GaryvdM> jam: I'm going home now. Should I shutdown?
<poolie> GaryvdM: oh did john start up the ec2 vm for you?
<GaryvdM> poolie: Yes - and I've been working on building the installer
<GaryvdM> Using igc's scripts
<GaryvdM> jam: I've keep notes an pushed changes to lp, so it's ok if d is trashed.
<poolie> way to go
<GaryvdM> Night all
#bzr 2010-07-01
 * mattman_ is away: 
<poolie> mkanat: mwh says if you request access to ~loggerhead-team he will approve it
<mkanat> poolie: Okay, will do.
<mkanat> Done.
<poolie> hi spiv?
<mkanat> jam: Thanks for the cvs2bzr recommendation. Worked like a charm.
<spiv> Good morning :)
<lifeless> spm: are you familiar with the new bazaar website deployment?
<spm> lifeless: as in for http://bazaar.canonical.com/ ?
<lifeless> yes
<spm> heh, no. not familiar with.
<lifeless> poolie has asked me to look at why an rss feed cron job in it isn't.
<lifeless> and crontab -e as bzr-website on the machine -> empty file
<spm> is that the way rss feeds are generated for the site? as in some I've worked with previously (geeklog springs to mind) encode the generation of rss in every home page request (I deliberately disabled THAT gem).
<lifeless> :>
<lifeless> yeah
<lifeless> so I think I have it sorted - thanks
<lifeless> ftr, its running from poolies crontab
<poolie> thanks for all the reviews jam
<poolie> i should migrate them...
<spm> lifeless: coolio. possibly we should have a 'bzr' account to run those sorts of things, but that works.
<poolie> there is a bzr-web
<poolie> (or something like that) role account
<poolie> i should migrate the cron jobs to run in that
<spm> that works
<mtaylor> lifeless: is there a reason you have not merge in my pandora-build packaging updates? or have you just not gotten to it?
<lifeless> mtaylor: time, yeah.
<mtaylor> lifeless: ok. just wanted to make sure it wasn't blocking on me
<lifeless> I don't think so.
<lifeless> Was moving country etc.
<lifeless> the hits keep on coming ;>
<mtaylor> lifeless: you were moving country?
<mtaylor> lifeless: where do you live now?
<lifeless> NZ
<mtaylor> ah.
<mtaylor> so you're even closer to my timezone now :)
<lifeless> yes
<mtaylor> woot
<lifeless> except when I'm in .au (now), or europe (week after next)
<mtaylor> well right
<mtaylor> same goes for when I'm in other places - or when new zealand moves into the indian ocean
<lifeless> http://www.paulhammond.org/2010/06/trunk/
 * spiv hmms at a stacking test
<poolie> spiv :)
<poolie> so you're going to tackle those other bugs and then prod merge cleanups?
<poolie> (if so that's fine with me)
<spiv> poolie: yep, exactly
<spiv> Can I get an incremental review of just http://bazaar.launchpad.net/~spiv/bzr/reconfigure-unstacked-551525/revision/5331 ?  I had some minor test fallout.
<lifeless> +1
<spiv> lifeless: thanks
<lifeless> thanks for the direct link
<lifeless> I wish that page didn't need a click to see the diff
<lifeless> -> fud
<parthm> i am trying to deprecate osutils.re_compile_checked. adding @deprecated_function(deprecated_in((2, 2, 0))) produces 'no attribute _format_version_tuple' http://pastebin.com/EeEiLfbx
<parthm> should i be doing something differently?
<spiv> parthm: argh, imports :/
<spiv> parthm: the issue is that _format_version_tuple in bzrlib/__init__.py is defined after the import of bzrlib.lazy_regex
<spiv> The fix is probably to move the definition _format_version_tuple above that import.
<parthm> spiv: oh. ok. i can fix that and send it separately for merge if that works.
<spiv> Or do the deprecation without using the decorator, I suppose.
<spiv> (I don't have a strong opinion either way)
<parthm> spiv: i will go ahead and am a separate patch for that. its a trivial change anyway. its nicer to use the decorator.
<parthm> spiv: https://code.launchpad.net/~parthm/bzr/format_version_tuple_import_order/+merge/28953
<spiv> parthm: reviewed, thanks
<parthm> spiv: thanks. i fixed the comment. do you think its a small enough change to send to pqm or do we need another review?
<spiv> parthm: Fine to send, I think.
<parthm> cool. thanks. i will send it.
<lifeless> parthm: hi
<lifeless> parthm: I gave similar advice to john earlier in the review of your bad ignores branch
<lifeless> parthm: Perhaps you missed it? I'd like to help you land that branch.
<parthm> lifeless: hi. i might have missed it. what are you referring to?
<lifeless> the layering - passing in info about where patterns came from etc
<parthm> lifeless: ah. yes. thats probably a good way to go. i might have missed it earlier. the comments on the patches were really growing long :)
<parthm> lifeless: i plan to look at that once the current patch (part-1) lands
<spiv> Hmm, there are a few TODO comments in chk_map talking about improvements that weren't done because we didn't have a pure-python StaticTuple
<spiv> There might be some cheap wins to be found there
<lifeless> spiv: revision specs could use cleanups
<spiv> lifeless: very much, yes
<spiv> lifeless: the trick is doing it without disrupting 3rd party implementations & callers too much, I think
<spiv> But right now, lunch!
<lifeless> spiv: yes; I made the comment when working on loom.
<vila> hi all !
<mneptok> vila: salut
<lifeless> night all
 * poolie is trying to backport python-configobj to dapper in the ppa
<poolie> hi there parthm vila
<johnf> Say I have to releases trunk and release and I need to fix a bug in release but trunk has moved on. Am I better off fixing it in trunk and then cd release; bzr merge -r REVISION_ID ../trunk
<johnf> or fix it in release and merge back into trunk
<johnf> or it doesn't matter or some other better way? :)
<spiv> If you merge release branches back into trunk (which is how bzr manages its branches), then branch off release and fix it there is typically easiest.
<spiv> Because then your fix branch can be merged directly into both your trunk and release branch.
<johnf> spiv: ok that's what I thought. Thanks
<spiv> But fixing in trunk and then backporting via "bzr merge -c BLAH ../trunk" is not too painful either, although it leaves bzr with slightly less complete information in the revision history.
<echo-area> If I'm going to make a repository public for all users on a host, what's the recommended way?  Currently 'chmod -R 777 repo-dir' comes into my mind
<poolie> if you want to let them all commit to it?
<poolie> that would do
<echo-area> poolie: Okay, thank you.
<echo-area> And I suddenly find there are very large files (~3.7G) in my ~/.bazaar/svn-cache directory.  Can I delete it?
<spiv> You can.
<spiv> (But bzr-svn may need regenerate some or all of them later if you access a SVN repo with bzr.)
<echo-area> spiv: Fine.  Storage is a more critical factor than speed for me now :)
<lifeless> poolie: I was taking a bet with myself whether you'd have finished yet :)
<lifeless> mgz: hey, when you get here, it might be nice for us to put heads down and get a subunit + testtools release done
<swathanthran> http://pastebin.ca/1892599 what can be the problem?
<vila> swathanthran: s/lh/r/
<vila> swathanthran: try it with a web browser and you'll realize you're using the wrong url (use 'r' not 'lh')
<swathanthran> yeah i guessed that but didn't know what to use instead of lh
<swathanthran> and lh is disabled on savannah.
<vila> swathanthran: I walked up to the root to find it
<vila> swathanthran: I don't know what is going on with lh on savannah
<swathanthran> anyway to find out how much size it could be?
<vila> what ? savannah ? loggerhead ? the branch ?
<swathanthran> sorry, the branch..
<vila> swathanthran: 147.685  Transferred: 60985kB (413.9kB/s r:60931kB w:54kB)
<swathanthran> to find out how much size it could be to download, before downloading
<swathanthran> vila: ok thanks.
<vila> swathanthran: there is no easy way to find that without downloading :) It depends on what you want to download and that can be a part of the whole
<swathanthran> ah
<vila> the bulf of the data is the revisions, but you can branch from an older revision or the branch's repository can containg more revisions that you need to download
<vila> and you may already have some revisions locally and don't need to download them
<swathanthran> oh yeah, how to download the sources alone?
<swathanthran> bzr co --lightweight?
<vila> that's one way, another is: bzr export  builder.tgz http://bzr.savannah.gnu.org/r/gnewsense/builder
<vila> but the former will allow you to update at will
<swathanthran> oh thats great.. i actually wanted just the current version..
<vila> swathanthran: right, if it's a one-time only operation it's ok, but you'll pay the full price the next time you need it otherwise
<swathanthran> sure, at night, i don't have to pay for the net, to get along with work now, i have ot pay for the bandwidth;-)
<swathanthran> bzr export does it without having the branch on our system?
<vila> swathanthran: both export and co --lightweight won't store the downloaded revisions, you'll pay at each use :)
<vila> swathanthran: if you use a local branch, you'll only need to download the new revisions next time
<swathanthran> yeah got that.. i'll do a full branch at night when i have bandwidth..
<swathanthran> and cool, i just got builder.tgz and it was like 20mb or so i guess.
<spiv> G'night all.
<vila> spiv: g'night
<swathanthran> vila: thanks !:)
<swathanthran> without loggerhead, can i have an http link to just one file on the repo?
<Glenjamin> hi guys, i'm wondering if anyone can help me out; i'm getting this traceback http://pastebin.org/369909 whenever I try and checkout some branches from my SVN repo
<maxb> Glenjamin: It looks like you might be branching into an existing shared repository.... if so can you try without?
<Glenjamin> there's a whole bunch of inconsistent details in skipped record errors along the way - but the checkout appears to have worked.
<Glenjamin> does this mean my shared repo is corrupt in some way?
<maxb> Sounds like it
<maxb> Try 'bzr check' to get more info, and 'bzr reconcile' to try to fix it
<Glenjamin> i guess bzr check sitting there not spitting out any output for a while is probably just it working
<Glenjamin> seems to be munching cpu, so i'll trust it
<lifeless> check is not optimised -> by which I mean its pretty slow compared to many other commands
<Glenjamin> fair engouh really
<Glenjamin> http://pastebin.org/369954 was my output
<Glenjamin> do i just do reconcile on the repo now?
<lifeless> reconcile can't fix the ghosts
<lifeless> it can fix the parents.
<lifeless> that may fix your error
<lifeless> have you looked in the bzr-svn bug tracker ?
<Glenjamin> i have, the only similar errors are from 2008 and marked as fixed.
<lifeless> ok
<lifeless> take a backup
<lifeless> then give it a shot
<Glenjamin> bah, no luck :(
<Glenjamin> i guess i'd better post the bug
<Glenjamin> cheers for the help guys, fresh repo from SVN seems to be working :)
<jam> GaryvdM: are you currently working on desolation?
<jam> (no problem if you are, just checking)
<GaryvdM> Hi jam
<GaryvdM> I am, but am about to go to ice hockey.
<GaryvdM> Trying 1 last build
<jam> np
<GaryvdM> jam: do you normally work in cygwin bash, or window cmd?
<jam> GaryvdM: *I* work in cygwin bash
<jam> I believe Ian was working under cmd using gnumake for win32
<jam> rather than cygwin make
<jam> I just find setting up cygwin a whole lot easier
<jam> setup.exe is at least a cygwin package manager
<GaryvdM> yes
<GaryvdM> ok I'm off to ice hockey
<jam> GaryvdM: have fun
<vila> aaaaargh lp ! come back !
<jam> jelmer: when you get this, 'bzr-svn' doesn't seem to have a tag for 1.0.3
<jam> vila: hi
<jelmer> jam: that's correct, since 1.0.3 is not out yet
<jam> ah, I misread your lp page then
<vila> hi jam !
<jam> building the installer for 2.1.2 and hacking together the old scripts
<jam> I think igc's updates were a push in a good direction, but I don't fully understand them, and they aren't working *right now* so easier for me to start with a known place
<jam> jelmer: yeah, looking now I see 1.0.3 is an open circle. I missed that the first time
<jam> vila: lp seems to be back for me
<vila> jam: yup. me too now
<jam> anyone know why Launchpad now requires REFERER to be set to upload files?
<jam> It is a real pain for me to upload 5 installers using Firefox versus just a plain script
<jam> ah, here we go: https://answers.edge.launchpad.net/launchpad/+faq/1024
<jam> of course, *curl* has no referrer because I just uploaded it manually
<jam> sigh
<mwhudson> you can probably set the referrer on the command line for curl?
<jam> mwhudson: I assume so, but it feels stupid to fake a referrer
<jam> and requires time for me
<jam> :)
<exarkun> jam: sounds like a good referrer to use
<exarkun> 'this feels stupid and is a waste of my time'
<jam> exarkun: except since launchpad is trying to validate it, I imagine that won't work. But I'll give it a shot :)
<jam> the FAQ I linked claims they use it to avoid cross-site scripting
<mwhudson> no
<jam> so all POSTs to LP now have to have a Referrer
<mwhudson> cross site request forgery
<mwhudson> not quite the same
<mwhudson> in particular: no scripting
<jam> mwhudson: so what is the specific problem if my web page helps you to upload something or update a bug on lp?
<jam> is it more of a 'don't send your login credentials to 3rd party sites' ?
<maxb> The idea is that javascript on some other site can't trick you into making a POST to launchpad to do something evil, using your cookie
<mwhudson> maxb: again, not javascript, javascript already can't do that
<mwhudson> boring old html can though
<jam> mwhudson: so... will any edge.launchpad.net url work as the referrer?
<mwhudson> http://en.wikipedia.org/wiki/Cross-site_request_forgery
<exarkun> For that purpose, isn't a missing referrer as good as a correct launchpad.net referrer?
<mwhudson> jam: probably
<jam> exarkun: some people disable referrers in their web browser
<jam> and they want to protect you from yourself
<jam> it seem
<jam> seems
<mwhudson> a better fix is nonces in the form, but that would be considerably harder to trick with curl i guess :)
<jam> mwhudson: the best part is because of how http uploads work, you don't find out about the failure until *after* you've upload 4MB of content
<mwhudson> and the real real fix for uploads specifically is an api to do it
<exarkun> jam: 100 Continue !!!
<mwhudson> exarkun: ptth!
<exarkun> mwhudson: yea, I was gonna say
<exarkun> mwhudson: haha.
<jam> and, of course, all of this worked 3 months ago when I was doing it last
<jam> like 5+ things broke in the windows installers steps
<jam> mwhudson: so --referrer https://edge.launchpad.net worked just fine
<jam> vila: true story. Trying to download the svn binaries leads to URL recursion. It seems they redirect you to a second page, which then sets a cookie and redirects you back to the first page. If you don't carry your cookies along, then you get infinite recursion.
<jam> *sigh*
 * vila bangs head on desk
<jam> vila: building the windows installers is being a real joy
<jam> ...
<jam> I remember why I loved doing them so much in the past
 * jelmer sees his sarcasm-o-meter pan out
<jam> it seems that everything in the world decided to change in the last 3 months, just to thwart us
<jam> zlib has a new release without a similar dll build
<jam> lp now requries referrer to be set
<jam> ian did a lot of work to update the installer, but I don't quite follow how it should work yet
<jam> svn moved to apache
<jam> and doesn't have *new* dlls, and now the old dlls have crazy redirects
<jam> qbzr didn't tag 0.19b1 in their trunk
<jam> ah they did, but as '0.19beta1'
<jam> anyway... getting there
<jam> we shut down the old desolation instance, and it may have only been working because all the files were already cached in d:
<vila> jam: :-/
<vila> so before I EOD, you want me to confirm that as soon as the test suite is passing on windows I will set up babune for windows daily builds ? :-D
<jam> anybody knows how to fake a buildout signature so that we can manually do the download and work around buildout trying to be extra helpful
<vila> err, won't that make the next failure even more horrible to address ?
<jam> vila: I don't care, I want to get builds
<jam> stuff is der broken
<jam> I'm asking sidnei for help, hopefully he can help work out the buildout stuff
<jam> vila: right now I'm reverting back to my old code because it actually works
<jam> and I'd really like to switch to what Ian was working
<jam> on
<chaosaddict> it sounds like the fast-import format prefers ASCII with the exception of raw file data. Is it possible to have non-ascii filenames? I've been having a lot of trouble with latin-1 encoded filenames from Perforce importing into Bazaar.
<jam> chaosaddict: I believe the data stream is assumed to be in utf-8
<jam> any way you can get the perforce output to .decode('latin-1').encode('utf-8') ?
<eydaimon> hi. how is this even possible? http://pastie.org/pastes/1026887
<chaosaddict> jam: I believe I have that working, and the fast-export-from-p4 part works. However then the fast-import step crashes. I haven't figured out the root cause on that yet.
<jam> chaosaddict: tracebacks help
<chaosaddict> jam: unfortunately it spits out a parsing error, rather than a crash + traceback.
<jam> eydaimon: One side has: "pu = PaymentUser" and the other side only has "PaymentUser"
<jam> I don't know what .rvmrc is, but it appears to be something your vim dropped in the current working dir
<jam> eydaimon: otherwise I don't really understand your question
<eydaimon> jam: The point I'm making is that after modify the file, and I resolve it, there's nothing to check in
<eydaimon> jam: and if I merge again, I get exactly the same thing happening
<jam> eydaimon: I don't really know. I would think at the least the merge revision would be ready to be committed.
<eydaimon> exactly
<jam> Though maybe this is because of the "infinite merge request" issue
<eydaimon> sounds like
<jam> merging a => b creates a commit that can be merged b => a
<eydaimon> is that an open bug?
<jam> so we probably added code to prevent that
<jam> which is triggering here
<jam> I don't think this is an open bug
<jam> which is
<eydaimon> then how can I address it?
<jam> conflict resolution leading to know content change is preventing commit
<jam> or something along those lines
<jam> eydaimon: worse case you can make a trivial change somewhere
<eydaimon> I don't want merging with trunk forever more to cause conflicts
<jam> but I'm also surprised that 'bzr status' doesn't say anything
<jam> can you paste the output of "bzr merge ; bzr status" *before* you resolve the conflicts?
<eydaimon> yeah
<jam> you might want to use paste.ubuntu.com, your formatting came out a bit weird on pastie
<eydaimon> I already show the first merge
<jam> eydaimon: you showed the merge, but not 'bzr status' afterwards
<eydaimon> reload pastie to see changes
<jam> eydaimon: so something is odd about your merge, as it isn't recording a revision to be merged
<jam> ahhh
<jam> you are doing a single file merge
<jam> that doesn't get recorded
<jam> you have to do a full tree merge
<eydaimon> k
<eydaimon> I would do that but there's one of the files I didn't know how to handle
<eydaimon> so I was doing a whole directory
<eydaimon> ( was using one file as an example here )
<mkanat> 6) Important since these often outline the actual changes in a short form or
<mkanat> reason for why the commit were done in that specific branch.
<mkanat> Oops.
<mkanat> Sorry.
<mkanat> Drag-and-drop. :-|
<mkanat> jam: Do you still need the account on my machine?
<jam> mkanat: only if you tell me I do :)
<mkanat> jam: Okay, I'll test meliae first. :-)
<mgz> garyvdm, jam: thanks for working on packaging 2.2b3 for windows
<jam> mgz: well, my version is pretty hack-tastic, but let me know if it works for you
<mgz> <jam> zlib has a new release without a similar dll build <- you still needed to do this bit? Does svn or something also need the dll?
<jam> mgz: since you mention it, probably not. but the build code I was using still did
<mgz> I'm going to test it to see if my -OO change does anything bad to plugins, then send a message to list for plugin authors
<mgz> lifeless: after I do that, I have an hour out or so for squash, but am then free all evening for testtools/subunit things
<mgz> 'd file a bug on the referer thing jam, even though it's easy to work around, it's stupid
<mgz> uploading doesn't sign the binaries or anything, right?
<jam> mgz: It looks to be a purposeful design thing, so I can file it, but I think the powers-that-be have explicitly requested it
<jam> mgz: no, I manually sign them
<mgz> it's purposful for editing bugs and so on, but an upload isn't a db-state-changing thing
<mgz> it's just moving bits.
<mgz> okay, I get API version complaints from svn and rebase
<mgz> urk, and this one is my fault:
<mgz> ValueError: No help message set for <bzrlib.plugins.explorer.lib.commands.cmd_explorer object at 0x0114ABF0>
<jam> dang jelmer already left
<mgz> I *thought* I'd avoided that, and the thingy had been changed not to throw any more anyway
<jam> send a message to the list
<mgz> will do.
<jam> mgz: I think it has, but that will be in 2.2b4
<jam> which isn't released yet
<mgz> okay, so, this is a maximally borked version, that will probably be useful
<mgz> these plugins *are* seperate though, and should be compiled differently, I wonder what went wrong
<jam> mgz: well, I used some old build tools
<mgz> the setup.py is from the bzr you're shipping though, right?
<jam> should be
<jam> (i'm pretty darn sure it is)
<mgz> okay, so the bit that seems not to be working is the install_data_with_bytecompile class ~line 530
<mgz> or I misunderstood how it works
<mgz> the idea is that things in library.zip should get optimize=2 and things in the plugins dir should get optimize=1
<jam> mgz: sure I remember that part of the patch
<jam> I don't know what it takes to make it work or not work, though
<mgz> ah, urk, problem.
<mgz> it seems the pyo files there do contain the docstrings
<mgz> so, instead perhaps the problem is when bzr.exe runs, it does in such a way as they're not loaded?
<mgz> which would be I need to work out how to seperate the byte compiling of py files from the mode set for the base script
<mgz> I'll get something worked out.
<jam> mgz: my quick-and-dirty test says it shouldn't matter
<jam> if I compile a .py to .pyo and include the docstring
<jam> running python -OO main.py still loads the existing .pyo and still has a docstring
<mgz> hmpf, so that's what I originally assumed, something else must be going on
<jam> so I would guess something else is at fault
<jam> mgz: we need a way to get to a python interpreter from the bzr.exe :)
<mgz> that would indeed be useful ;)
<mgz> bzr interpreterplz
<mgz> wait, I already have the machinery for that, have a throwaway plugin to shove arbitrary stuff in
<jam> mgz: yeah, here is one option: http://writeonly.wordpress.com/2008/09/08/embedding-a-python-shell-in-a-python-script/
<jam> which uses ipython
<jam> but I think you could just have something that does "import pdb; pdb.set_trace()" and get something good-enough
<mgz> code.interpret is it indeed.
<mgz> dammit, we don't bundle that. pdb it is.
<mgz> okay, so explorer does have doc strings.
<mgz> is this going to be something daft like, that cmd really *doesn't* have one in the source?
<mgz> I should have checked that.
<mgz> nope, it seems it does.
<jam> mgz: it does in my copy
<jam> mgz: are you sure it isn't loading your *local* copy of the plugin rather than the bundled one
<jam> and because it is running -OO it is stripping them on-the-fly
<jam> oooh
<mgz> okay, and it really is missing from bzr.exe's perspective, though other bits keep it.
<jam> so your code breaks people from installing extra plugins (it would seem)
<mgz> it does, if they don't install them correctly
<jam> mgz: I mean, if you put something in BZR_PLUGIN_PATH it will get loaded with -OO
<mgz> I'll check on the location, but bzr.exe should really get the path right
<jam> which will break them
<mgz> right.
<jam> import bzrlib.plugins.explorer; print bzrlib.plugins.explorer
<jam> should tell you what you want to know
<mgz> they are all from the right place
<jam> mgz: define 'right place'
<jam> the bundled plugin
<jam> or a user-installed copy
<mgz> bundled
<mgz> what I don't get is that bzrlib.plugins.explorer isn't stripped, but bzrlib.plugins.explorer.lib.commands is
<mgz> and they are both from the installer
<mgz> so... one of two things
<jam> mgz: and what does bzrlib.plugins.explorer.lib.commands.cmd_explorer.__doc__ say ?
<mgz> (None)
<jam> mgz: ah, so the sub-dirs are getting stripped
<mgz> (as in, it says nothing, because it really is None)
<jam> I wonder if they aren't getting anything
<mgz> right, so one of two things
<jam> aren't-getting pre-compiled because it isn't doing something recursively
<mgz> either the installer is being generated with some plugin files stripped and some not
<mgz> or the installer isn't generating some plugin files, and it's happening at run time with -OO
 * mgz checks timestamps
<jam> mgz: I would guess the latter
<jam> mgz: I'm going to install here, and see what files end up
<mgz> yup, and on quick check, it's only commands.py that's 18:58 rather than 09:31
<jam> mgz: C:\Program Files\Bazaar\plugins\qbzr\lib\commands.pyo
<jam> exists at install time
<mgz> but I also had a problem with qbzr, so this suggests something slightly more systematic than one missing file in a list
<mgz> ^ack.
<jam> timestamp of commands.py is 9:30am, timestamp of commands.pyo is 9:34 am
<mgz> okay, nice little mystery then.
<jam> mgz: and the timestamp isn't updated when I run bzr.exe
<jam> but it still fails to run bzr explorer because of a missing help text
<jam> mgz: opening the commands.pyo in vim shows that the strings are present
<mgz> something is certainly causing them to be rewritten here.
<mgz> just did bzr lp-propose
<mgz> and the stamp on plugins\launchpad\lp_propose.pyo bumped to now
<jam> mgz: my user doesn't have rights
<jam> so probably they are being rebuilt in memory, but not getting written down
<jam> and just not getting used here
<mgz> ah, yup, that'd explain it
<mgz> so, the last remaining question is why it's not just loading them from disk...
<jam> mgz: how are you getting it to run your code? I don't seem to be able to set BZR_PLUGIN_PATH and have it respected
<mgz> 's under .\bazaar\2.0\plugins
<jam> ah, k
<mgz> in BZR_HOME
<jam> well, I got it to run, but then it imported -OO and stripped the docstring :)
<jam> mgz: also I wouldn't be surprised if the -O setting is stored in the compiled code
<jam> and it sees "oh, this is only -1, I'll do -2 and update it"
<mgz> I wouldn't be, but I tested previously and it didn't do that
<mgz> so, if it's started doing it I'd be suprised
<jam> mgz: python2.6 vs python2.5 maybe?
<mgz> also... this is interesting
<jam> mgz: so that fixed my problem
<jam> I was compiling -O in py2.6 and then running bzr.exe which uses py2.5
<jam> after doing that
<jam> it just loaded the .pyo without recompiling my plugin
<mgz> ah, so, that does explain it
<mgz> different magic bit, but from the python version not the flag
<jam> mgz: but why would we be building them in the installer with the wrong python version
<mgz> good news is that fixing that not only unborks me, but will make first run faster all round
<mgz> ...and all runs, in your case where you don't have write access
<jam> mgz: (Pdb) bzrlib.plugins.explorer.lib.commands
<jam> <module 'bzrlib.plugins.explorer.lib.commands' from 'C:/Users/jameinel/dev/bzr/plugins\explorer\lib\
<jam> commands.py'>
<jam> I'm pretty sure that confirms it is loading the .py directly, and not the extension
<mgz> yup.
<jam> however, we are shipping .pyo and I don't see any reason why they would be invalid
<mgz> okay, I need to leave... now-ish, but this is something worth fixing
<GaryvdM> Hi jam, mgz
<jam> hi GaryvdM
<jam> mgz: well, given the installer is thoroughly broken... I have to agree :)
<GaryvdM> jam: I see you also had zlib issues. Thats where I was stuck today.
<mgz> well, backing out my setup.py change will unbreak, but not fix the never-using-pyo thing
<jam> GaryvdM: yeah, but we should be able to just drop zlib completely now
<jam> I don't know when mgz's patch landed, but we shouldn't need it in the build steps for bzr >2.2?
<jam> I pushed the builds out by just reverting to old build scripts
<mgz> yup, zlib change landed for 2.2b3
<jam> which should be okay for 2.1, it looks like it shows a lot of brokenness in 2.2, but I think that is going to be there regardless
<mgz> so, deleting it from all remaining build scripts should work
<jam> because it is stuff like "bzr-svn 1.0.2 is incompatible with bzr2.2"
<jam> mgz: so there is still the concern that this fix will break anyone running custom plugins
<jam> though 2.2b4 won't raise an exception
<jam> it will still break "bzr help myplugin"
<mgz> right, provided they are running from a tree, not installing with setup.py
<jam> mgz: right
<mgz> hence message to list about this, and seeing how people use the installer with plugins
<jam> mgz: already sent
<mgz> it's not a big change to put in and back out, I just wanted some testing and feedback with it in
<GaryvdM> jam: So should I see if I can make the build script use wget?
<mgz> okay, I need to leave... five minutes ago, but will be back in an hour and a bit to help sort this out
<jam> GaryvdM: I'm uploading to launchpad
<jam> and have us just point there for now
<GaryvdM> ok
<GaryvdM> jam: If you happen to do another 2.2, please use qbzr trunk.
<jam> GaryvdM: bug #600746
<ubot5> Launchpad bug 600746 in Bazaar Windows Installers "unable to download svn dlls due to redirects (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/600746
<jam> GaryvdM: it is a bit tricky to do a "trunk" build without a tag
<jam> any chance you could take 0.19b2 ?
<GaryvdM> Ok - let me do that.
<jam> s/take/tag/
<GaryvdM> jam: I still have not worked out, where do you specify the plugin versions.
<jam> GaryvdM: have not worked out what?
<jam> If you are on the build host, I'm doing the work in "old-windows-installers"
<GaryvdM> jam: Where do you specify that it should use version 0.19b1 of qbzr
<jam> tools/win32/buildout.cfg
<jam> (yeah, ugly place, which is why igc was fixing it)
<GaryvdM> Ah - thanks
<GaryvdM> jam: can one not put any revision spec in [plugin]-release-tag?
<GaryvdM> (still going to to qbzr release
<jam> GaryvdM: probably could, but it is pretty set up to do it this way
<jam> I think at one point it supported grabbing the latest tip of everything for doing the build
<jam> but I've only really done releases
<jam> and I prefer to have tagged code in releases anyway
<GaryvdM> Ok
<GaryvdM> We can try use "-1" for daily builds.
<jam> GaryvdM: something like that
<jam> GaryvdM: have you tagged 0.19beta2 yet?
<GaryvdM> Not yet - Going through the whole release processes
<jam> k
<GaryvdM> jam: I normaly make sure I can build the installers before I tag and push
<jam> sure
<jam> as you wish
<jam> GaryvdM: so why were you using the ~igc branch rather than lp:bzr-windows-installers?
<GaryvdM> jam: I soon realised that lp:bzr-windows-installers was newer, and switched to that.
<jam> ah, k
<jam> good
<mkanat> Hahaha, the page that causes a memory leak in loggerhead also causes a memory leak in Chrome. :-)
<jam> mkanat: So it really is just generating too much stuff :)
<jam> its not leaking
<jam> just over allocating :)
<jam> or just showing too much stuff
<mkanat> jam: Well, no, it leaks, in loggerhead.
<mkanat> jam: Also, I just crashed meliae.
<jam> is this the one I commented on? That going to the 'files' page will leak memory if you reload it a few times until gc kicks in and memory drops again
<mkanat> jam: No, I don't think so.
<jam> k
<jam> mkanat: care for more details than "crashed" ?
<mkanat> jam: Yeah, getting them. I just want to be absolutely sure that I have 0.2.1rc installed.
<jam> mkanat: I don't doubt you've managed to do something, as your machine seems to work differently than all the other ones I've worked with :)
<mkanat> jam: lol
<mkanat> jam: Exact same bug; no change on my end. Does 0.2.1.candidate.1 have the fix from yesterday, or do I need trunk?
<mkanat> jam: Well, exact same original bug.
<mkanat> jam: It now does a fair bit of dumping, but it crashes with the same assertion and a core dump. Do you want the core, or do you just want me to give you steps to reproduce and have you log in?
<jam> candidate.1 should have the fix
<jam> I might have an idea of one more place to check
<mkanat> jam: Okay. Do you want a backtrace?
<mkanat> It will take about 20 minutes to get, because I have to install a lot of debug symbols.
<jam> either way
<mkanat> Okay, I'll start the process.
<jam> steps to reproduce would be helpful too
<jam> I was able to reproduce it before with "python -c "from meliae import scanner; scanner.dump_all_objects()"
<jam> but I fixed that
<jam> so it seems to depend on something else now
<mkanat> jam: Okay. It's: ./serve-branches /mnt/mkanat-hdd/mkanat/bzr/; SIGQUIT;  then the above.
<mkanat> jam: But the ability to SIGQUIT serve-branches is a tiny patch of my own.
<mkanat> jam: It just adds breakin to serve-branches.
<jam> mkanat: bzr serve --http can be SIGQUIT :)
<mkanat> jam: Ah, okay. :-)
<mkanat> jam: And yeah, it doesn't matter where I point serve-branches.
<mkanat> jam: If I install Cython, will it build with it instead?
<jam> yes
<mkanat> Hmm, maybe I should try that.
<jam> but I don't think that is the specific problem
<mkanat> Okay
<jam> the core-dump is fix #1, the pyrex is fix #2
<mkanat> Ahh.
<jam> is everything installed globally?
<jam> or are you running something from source?
<mkanat> Except meliae, now. Meliae was installed globally, but now I'm running it from a build dir.
<lifeless> hi jam
<mkanat> And I just installed Cython.
<lifeless> mkanat:
<mkanat> lifeless: ?
<jam> mkanat: well, I don't have your install of loggerhead, etc (at least not obviously)
<mkanat> jam: Oh, right. Yes, that's from source.
<jam> and I don't have perms for /mnt/mkanat-hdd/mkanat
<mkanat> jam: You don't need them.
<mkanat> jam: Just start: ./serve-branches
<lifeless> mkanat: saying hi
<jam> mkanat: well, I need loggerhead
<jam> hi lifeless
<jam> I was hoping to avoid re-downloading it for you
<mkanat> jam: Oh. I could branch it over to you.
<jam> loggerhead isn't terribly big
<mkanat> jam: Yeah, re-downloading it would be fine.
<mkanat> lifeless: Ah, okay. :-) Howdy. :-)
<jam> mkanat: k, I've reproduced in a slightly different way
<jam> mkanat: how would you get a stack trace from the core dump?
<mkanat> jam: Well, normally I'd use gdb, and it would ask me if I wanted to use yum to install stuff.
<mkanat> Or it would just tell me to.
<mkanat> Or there's some tool for analyzing cores.
<mkanat> It's too bad this isn't Fedora 13, though--they have something like pygdb built in.
<jam> well the last thing in the dump fil is _ctypes.PointerType which is probably a good hint
<jam> yep, got a core from: py -c "from meliae import scanner; import ctypes; scanner.dump_all_objects('test.dump')"
<mkanat> Okay. I'm installing the debug symbols.
<mkanat> Ah, debuginfo-install python.
<PDecker> After "bzr pull"-ing updates of my system-wide-plugins, how do I know which ones need me to "python setup.py install"?  Seems some do (like Dulwich) and most others don't.
<jelmer> PDecker, dulwich isn't a plugin but rather one of the dependencies
<PDecker> jelmer: It's installed in the system plugins directory, at least on this box I got.  How do we know the difference?
<jelmer> PDecker: It wouldn't do anything if it's in the system plugin directory - how did you get it there?
<PDecker> Took me awhile to figure out why things weren't working, and that I had to do the 'install' step.
<jelmer> PDecker, dulwich is used by bzr-git
<PDecker> Never used bzr before ...
<PDecker> jelmer: *I* didn't do anything.   I got this box -- new job -- with all this biz pre-installed.  Now I'm doing the usual "fix everything that's screwed up by the nitwits in corporate IT" phase
<mkanat> jam: Okay, I have a backtrace for you.
<jam> mkanat: can you paste it? or copy it into my home dir?
<mkanat> jam: I'll paste it.
<mkanat> jam: This is the only thread that isn't in sem_wait: http://pastie.org/1027210
<GaryvdM> jam: Is there any think I can help with related to win installers?
<jam> GaryvdM: any idea where we are supposed to set versions in the new igc code?
<jam> I see in 'bazaar_releases.py' that it references qbzr (for example) but nothing where it says "use version X.Y"
<mkanat> jam: I wonder if Fedora ships patches with python. I'll go see if they have any that would affect this.
<jam> mkanat: well certainly their assert is tripping in a release build which is strange
<jam> but I shouldn't be tripping that anyway
<GaryvdM> jam: Same as before:  tools/win32/buildout.cfg
<mkanat> jam: Okay.
<jam> GaryvdM: are you sure? All the other download urls, etc, are in bazaar_releases.py
<GaryvdM> jam: Maybe he meant to move it but did not get to it?
<jam> GaryvdM: I think he just never removed it
<jam> all the stuff in build-win32 seems to be auto-generated
<jam> afaict his code *only* builds the latest tip of each branch
<jam> look at build-win32/buildout-bzr-2.2.cfg
<jam> it doesn't have any versions in there
<jam> and just accesses the trunk brancehs
<jam> branches
<GaryvdM> jam: let me step through the code an see if i can confirm that.
<jam> GaryvdM: he seems to be using a jinja2 template
<jam> if you look in buildoutgen.py
<jam> and then templates/buildout/buildout.cfg
<jam> and nowhere in the template does he note a way to specify a version
<jam> (I'm getting a failure in qbzr because of a .po being changed, and I think that is because you haven't made a release so the code that generates the .po files from the .mo is actually producing a new update)
<jam> and buildout makes sure that trees are clean before building
<jam> and so tip of qbzr is not perfectly up-to-date
<jam> but regardless of all that
<jam> I need a way to force versions of plugins
<jam> especially for building the stable releases...
<mkanat> jam: There are patches to python, but I don't see any of them that would affect this.
<GaryvdM> jam: ok - let me work on that
<GaryvdM> jam: I think you tired to do a build in /cygdrive/d/bzr/bzr-windows-installers. Please could you rm /cygdrive/d/bzr/bzr-windows-installers/build-win32 -r
<jam> mkanat: so what is the quick way to get a stack trace from a dump?
<jam> I'm triggering it differently, but getting the same failure
<mkanat> gdb --core=core.12476 --exec=/usr/bin/python2.6 --batch -ex "thread apply all bt" > bt
<jam> it looks like it may be a case of a class having its own tp_traverse, but one that calls into the original one
<jam> mkanat: and where is the core dumped, because it isn't in '.'
<mkanat> jam: And you have to set "ulimit -c unlimited" to get the core, first.
<mkanat> jam: Before running bzr serve.
<jam> nice of it to say core dumped without actually dumping it :)
<GaryvdM> jam: I created the dir, so I was able to mv build-win32 build-win32-old
<mgz> am back.
<jam> mkanat: so I can certainly work around the obvious bug by just saying "don't dump anything that is considered a heap type"
<jam> sorry a 'non-heap' type
<jam> however, it means references will be left out
<jam> for platforms that don't have the assert tripping them up
<jam> anyway, I have to go now
<jam> I'll poke back at this later
<mkanat> Okay.
<jam> the diff is stuff like this: http://paste.ubuntu.com/458000/
<jam> in meliae/_scanner_core.c
<jam> GaryvdM: it looks like you reverted some of my changes in bzr-windows-installers
<jam> namely, pointing the code at the launchpadlibrarian branches
<mkanat> jam: I'm not quite sure I understand what leaving out references would entail. I mean, everything is a reference in python, on a high level, isn't it?
<jam> and having "strip_..." set to False for zlib
<GaryvdM> jam: ah - sorry
<GaryvdM> I restore from ~ files
<jam> mkanat: the point of meliae is that it walks references to find objects and dumps their info. Not walking references means that we won't find refs and won't dump them
<jam> GaryvdM: anyway, I'm done for now
<jam> good luck
<mkanat> jam: Yeah, that sounds problematic.
<jam> mkanat: tp_traverse was originally meant only for the garbage collector
<jam> and it doesn't make sense to garbage collect static objects
<jam> (non heap objs)
<mkanat> Ahh.
<jam> however, it is nice to find them
<jam> by for now, see you guys tomorrow
<jelmer> moin lifeless
<lifeless> hi jelmer
<lifeless> how are things
<mgz> blast, missed jam while catching up on log
<mgz> I need to file a bug against the installer, what project should that be?
<jelmer> lifeless: well, trying to fix the #1 bzr-svn bug!
<lifeless> which installer
<lifeless> windows/mac/ubuntu/???
<mgz> just checked 2.1.1 installer and it too overwrites pyo files at runtime rather than using the ones on disk
<lifeless> jelmer: cool
<mgz> win.
<lifeless> bzr-windows-installers
<GaryvdM> mgz: bzr-windows-installers
<lifeless> or something like that
<mgz> this is going to hurt perf, even if we avoid my added docstring problem
<lifeless> ugh faaail
<mgz> badly, for people like jam who install as admin and run with dropped privs
<lifeless> ah yes
<lifeless> the classic' but I waannnnnnna cache Mommy!'
<mgz> well, library.zip avoids this, but it hurts plugins
<lifeless> how so?
<mgz> well, it seems that (at least some of) the pyo files for plugins shipped in the installer are for python 2.6 but the python is 2.5
<mgz> so they need to be recompiled from the py at least once (and every load if you don't have write privs to the dir)
<lifeless> 06:46 < mgz> well, library.zip avoids this, but it hurts plugins
<lifeless> 06:46 < lifeless> how so?
<mgz> pasted what I said pre-ping in /query
<lifeless> ah
<lifeless> so that would be a bug, not a library.zip thing
<mgz> but if you mean the library.zip bit of that question... I presume it's a different path in the building of the installer
<mgz> nothing would work at all of the files in the zip had the wrong magic at the start
<mgz> (as there are no .py files in there)
<mgz> just finishing typing up the bug entry now
<mgz> I'm not certain it's down the python version, the shipped and recreated files appear to have the same magic
<mgz> and it's not timestamp related... what else can cause recompilation?
<lifeless> nothing I've heard of
<lifeless> oh
<lifeless> if you can't read the file
<mgz> oh, wait.
<mgz> the timestamp check is != rather than < isn't it?
<mgz> that'll be it.
<mgz> the pyo files shipped are all from a few seconds later
<mgz> wait, I'm wrong about that too. 's the timestamp in the bytecode that matters, not the file timestamp
<mkanat> jam: The python-meliae maintainer in Fedora has a patch! :-D
<mkanat> I didn't even know there was a python-meliae.
<lifeless> mgz: is the timestamp in the bytecode borked perhaps ?
<mgz> it is, seven hours out exactly
<lifeless> oh joy
<mgz> is jam in gmt+7?
<lifeless> windows not understanding GMT. again.
<mgz> (or whoever built 2.1.1)
<lifeless> well
<lifeless> I think they are built in a VM on ec2
<lifeless> but whatever
<mkanat> jam: Anyhow, I'm working it out with the Fedora python maintainer.
<mkanat> jam: Okay, problem is that Fedora is unintentionally shipping debug builds of python, somehow.
<GaryvdM> mgz: You are good with these things. Any idea how to fix this: http://pastebin.org/371858
<GaryvdM> If I run the command manually, then it works. I only fails when the build script runs it.
<mgz> hm, funky.
<mgz> well, the environment is messed up, I don't seem to have a devenv.com to check out though
<GaryvdM> mgz: ok thanks for looking.
<mgz> anything more in the buildlog html file?
<GaryvdM> mgz: no. Its just the same output nicely formated
#bzr 2010-07-02
<mgz> lifeless: if you kick up in te next few hours and want to look at some subunit things I'll be around
<lifeless> hi
<lifeless> I'm here
<lifeless> trunk subunit and testtools are, AFAICT, ready for releases
<lifeless> Damn, I wanted to grab tres
<mgz> we didn't explictly change subunit to use the unicode path though right? just relied on the __str__ behaviour now giving utf-8
<lifeless> subunit depends on unicide exceptions no
<lifeless> w
<lifeless> if someone has it fail, we can say 'your exception isn't serialisable safely, see testtools for helpers, or hey, use testtools
<johnjosephbachir> hey folks. a developer in my team has been using a branch bound to the server (IE, only using checkout, update, and commit), but also often uses the --local flag on commit and then commits to the server in a batch. she recently experienced a situation where she is missing some local commits, and can't find them in the repo OR her local code. she suspects that this is because she did a pull at some point in bettween local commits and server commits
<johnjosephbachir> how can we start investigating what happened? i suspect this code is hiding out in one of the "hidden" branches that bazaar keeps around... i can't remember the name of that concept
<johnjosephbachir> i suppose this is a mailing list -grade question
<johnjosephbachir> fwiw, seems like i had the same problem as this guy http://srtsolutions.net/blogs/chrismarinos/archive/2008/10/24/don-t-loose-your-head-with-bazaar.aspx
<spiv> johnjosephbachir: sounds strange
<spiv> johnjosephbachir: it would be good to have a bug report with as many details as possible
<johnjosephbachir> alas i probably don't have the time to do that
<lifeless> morn morn
<mgz> ah, lifeless back again
<mgz> see my name in lights on planet debian, thanks ;)
<johnjosephbachir> spiv: thanks-- code saved!
<lifeless> mgz: :)
<lifeless> mgz: and on planet.python.org
<spiv> johnjosephbachir: great!
<mgz> so, my subunit question boils down to if we want to something before release about:
<mgz> http://bazaar.launchpad.net/~subunit/subunit/trunk/revision/125/python/subunit/__init__.py
<mgz> your check-and-mention testtools suggestion sounds fine to me
<poolie> hello mgz, spiv, lifeless
<mgz> something like getattr(self, "_exc_info_to_unicode", None), then fall back to self._exc_info_to_string and complain if it's not ascii
<mgz> hey poolie
<lifeless> mgz: we could derive from testtools
<mgz> is a goal to avoid an explict testtools depedency though?
<lifeless> no
<lifeless> it has an explicit one already
<mgz> okay, in which case, just using the testtools class and maybe a version check would do
<lifeless> -garh
<lifeless> mgz: see my last commit to testtools :P
<mgz> ha!
<mgz> my fault too, didn't get as far as testing attempt 2 on py2k
<mgz> *3
<aaron01> I'm trying to use bzr import on a tarball, but I get a 'tree is malformed' error. Any ideas?
<mgz> maybe something like: http://paste.ubuntu.com/458088/
<lifeless> mgz: sorry I had already pushed :P
<mgz> ah! I'll pull.
<lifeless> aaron01: please file a bug? Not sure what is wrong there.
<aaron01> Seems like adding a top level dir (that will be stripped) fixes the problem
<aaron01> but now getting it trying to import that dir into another branch :(
<aaron01> s/it/the same error
<poolie> spiv does bug 600636
<ubot5> Launchpad bug 600636 in Bazaar "bzr ci crashes after a bzr break-lock (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/600636
<poolie> look to you like just another issue of a connection drop causing "too many concurrent requests"
<poolie> it does to me
<jam> lifeless, poolie: do you know why when submitting a bug with bzr, you get the option to set the priority, etc?
<jam> I don't see that for Meliae, or Loggerhead, or fastimport or any other project, and I miss it
<mgz> okay, yup, your rev is a less borked version of the same
<jam> anyway, back to family time, just curious if it was an option that needs setting somewhere
<poolie> jam it's something to do with permissions
<poolie> i'm not sure which thing controls
<poolie> it
<poolie> perhaps whether you're in the bug control team
<poolie> ask in #launcphad
<spiv> poolie: oh wow
<spiv> poolie: the commit code path was meant to be fixed ages ago.  Interesting!
<poolie> mm?
<spiv> It does seem plausible that a connection drop is involved.
<spiv> Hmm, likely even.
<poolie> there is a message about it
<spiv> Oh right.
<lifeless> jam: I think its driver permission
<lifeless> most things don't have driver set
<mkanat> poolie: Hey hey, do you have a second?
<poolie> hi, i do
<mkanat> poolie: Great, let me remember what I needed to chat with you about....
<mkanat> poolie: Oh, right. So, it sounds a bit from the discussion with Francis and the way things are gong on the list that I am in fact actually sort of going to end up owning loggerhead. Is that right?
<lifeless> \o/
<mkanat> poolie: I mean, with oversight from you and the bzr team.
<poolie> that sounds good to me if it's ok withy ou
<mkanat> poolie: Yeah, it's totally okay with me, but it will probably require an adjustment in the way that the contract works.
<mkanat> poolie: Should I discuss that with you first and then Francis, or should Jolie just discuss it with Francis?
<poolie> with me first
<poolie> it's up to you and jolie which of you wants to be involved from your side
<poolie> this is because it's expanding the scope of your work?
<poolie> let's talk in private
<mkanat> Okay.
<lifeless> poolie: I have a request; please document in doc/developers/testing.txt how to make bzr selftest run on a ramdisk.
<lifeless> poolie: I think many folk would benefit.
<lifeless> I can file that as a bug if you would like.
<poolie> no i'll just do it
<lifeless> thanks!
<lifeless> poolie: http://pastebin.com/rULLkF29
<lifeless> vila: --config please, not --conf
<lifeless> --conf is a strange abbreviation
<lifeless> c = config.LockableConfig(lambda : location)
<lifeless> reads really strangely
<lifeless> perhaps the LockableConfig constructor should be different
<lifeless> vila: I *really* wish you would not mix changes to imports with test changes
<lifeless> vila: it makes the patch about 4 times harder to review.
<vila> lifeless: I don't want to break the chain of constructors, I can add a def get_filename if you prefer
<lifeless> vila: its like a massive whitespace change *just because*
<lifeless> vila: and as far as I can tell no actual changes to many tests.
<lifeless> vila: so I'm going to push this back to you
<vila> lifeless: yeah, jam complains about that too, but we won't get the import problem addressed until 1) we all stop importing symbols, 2) we fix all remaining wrong imports
<lifeless> get me a diff that shows the *actual* test changes, and I'll happily review it.
<lifeless> vila: be tolerant of what you accept, and strict in what you output - wonderful IETF principle.
<lifeless> vila: it applies here - accept difference in files you are editing. Make what you write be up to scratch.
<vila> lifeless: this one goes both ways :) That was my reply to jam :-D
<lifeless> vila: I don't think you're considering the impact on the reviewer enough.
<lifeless> We're here to think about the change, about what it is meant to accomplish, and we're having to go line by line through noise.
<vila> I do, but the alternative is to postpone these fixes endlessly
<lifeless> +1
<lifeless> vila: 'the import problem' is approximately 0% of our bugs.
<lifeless> vila: a bad review can easily let a new bug in, or fail to see a structural issue.
<lifeless> vila: I really want you to think about the relative costs and merits here.
<poolie> vila i think lifeless has a point there
<vila> I really wish to feel less alone to realize that our actual tests serve as examples, get copy/pasted and decrease the overall quality which as an impact on our productivity because it makes them harder to modify :-(
<poolie> i think i agree with you on that too :)
<poolie> does importing the module make much difference in tests?
<poolie> presumably we don't care much about laziness?
<poolie> or is it just for the sake of consistency and examples?
<lifeless> vila: I really don't see that the changes you're making make stuff easier or harder to modify.
<lifeless> Just different.
<lifeless> not importing symbols has a specific benefit when we want to use lazy_import, but that does not apply to tests [perhaps it should, but the general import in tests is TestCase*, which can't be lazy imported anyway)
<vila> being consistent makes it easier to move code from one file to another or even inside the same file sometimes
<lifeless> I don't like doing 'from bzrlib import trace' in tests, because in tests you normally want a test object of the class, and that can't be called trace, so it has to be 'from bzrlib import trace as _mod_trace', and thats ugly.
<vila> not being consistent means you never know where a symbol is coming from and in this particular case prefixing with the module makes it 4 times easier to read
<vila> lifeless: <1% of the cases
<lifeless> Look, there are two things here.
<lifeless> a) when we do cleanups
<lifeless> b) whether they are better or worse.
<lifeless> Put (b) to the side; I'm tired, have a different opinion anyway, and *I was not complaining about b before*.
<lifeless> I, and John, are both complaining about mixing code changes with cleanups-to-code.
<lifeless> if everytime you touch a module, you want to put in a separate branch to clean it up, it would not take much more-or-less of your time
<lifeless> it could be reviewed totally separately to the *actual thing* you are working on.
<lifeless> and your colleagues wouldn't be feeling that reviewing your changes is hard
<Outlander> hi
<Outlander> what's the best way to convert cvs repo to bzr? appears to be a few different ways?
<vila> lifeless: 1) I got vaccines yesterday and that makes me grumpy  2) I've made separate branches in the past for cleanups and that raised discussions anyway so I grew tired of doing that on top of feeling alone cleaning this up 3) the import thing sounds like spurious spaces changes, yet, reviews are either a) not pushed back when they introduce them b) pushed back when they are VWS
<vila> the end result is that spaces are still there and the problem is not addressed
<maxb> Outlander: what are the ways? I only know of cvs2bzr
<vila> the imports are more important than spaces and there has been associated problems with them (I encounter one when trying to monkey-patch transport.get_transport, another one was people were importing symbols already imported from another module which broke when the symbol went to a different module or were fixed to not being imported as a symbol)
<lifeless> on whitespace - when it gets in the way of review, it gets pushback from me; when it doesn't, it doesn't.
<lifeless> the changes here are big fraction of the total patch.
<lifeless> its an 800 line patch, for a 200 line change, or something like that.
 * vila tells his vaccines that they don't have to make it grumpy and come in the way to progress
<vila> lifeless: that's unfair, please check
<lifeless> I did
<lifeless> 822 lines of diff
<vila> 1) s/file/infile/ trivial to filter on reading
<lifeless> 542->669 are the actual new tests (I think, my eyes are glazing over so I may be missing other semantic changes)
<vila> add 426-> 448
<lifeless> and 300 lines at the start; so 420/822
<lifeless> ok, 440/822
<lifeless> and thats exactly my point
<lifeless> in all the excess I couldn't see an important part of the change.
<vila> so, basically, you're saying that you should not cleanup, but you did so in many proposals and I supported that because it's part of keeping the code in good health, 324->333 for example is not required but the cleanup version make it easier to see what is happening here (and avoid useless calls)
<spiv> He's saying: consider the audience (which is good advice for any kind of writing)
<vila> So where is the limit on cleanups ?
<lifeless> There is a balance; I may have gotten it wrong in the past, and for that I'm sorry.
<vila> I'm sorry too but that doesn't address the problem :) Let's put emotions aside and focus on solutions
<spiv> If you make a diff that seems unnecessarily hard for a reviewer to review, expect them to be a bit grumpy about it.
<vila> yup, I was expecting that. I was hoping that people were rejoicing about cleanups progressing instead of staling though :)
<spiv> So either try to make easier-to-review diffs, or perhaps take other steps to ease the burden, e.g. point out the lines of the diff with the interesting changes.
<vila> I (and I think others) have been daunted in many occasions...
<lifeless> vila: There are two sorts of cleanups here: code clarity ones, and 'import style'. The former I rejoice at, the latter are entirely mechanical, and have caused bugs in the paste. I do not rejoice at those.
<spiv> There's no fixed limit, it really depends on the details of each patch.
<vila> which bugs ?
<lifeless> we've had import cleanups break due to shadowed names
<lifeless> they are not risk free.
<vila> true,
<lifeless> They are also not reviewer time free.
<spiv> (e.g. a 90% cleanups patch might be fine if the total patch is only 10 lines long :)
<vila> they are not time free for me either, but some tests are so unclear that I spend time deciphering them too
<lifeless> I'm saying that the cost and benefit need to be weighed; neither side is 0, and neither side is aleph-0
<lifeless> or aleph-1
<vila> on the overall, I consider that importing symbols is easier to *write* but harder to *read* and leads to more symbols staying around after they are not being used
<vila> and since code is more often read than written, the weight is more important too
<lifeless> vila: I don't see why symbols that aren't used is a maintenance problem; what does it make non-trivial that is trivial otherwise ?
<vila> review is *part* of the readers but not the only part
<lifeless> (I like a lean import list btw, don't get me wrong)
<vila> false positives when grepping or even thinking about the module
<lifeless> vila: something you can do in cases like this is filter the diff
<lifeless> and only show the bits that are relevant
<lifeless> andrew has done that in the past and its very nice
<vila> lifeless: ha, nice one
<lifeless> vila: but really, it all comes down to what has been said before
<lifeless> consider what the people you ask to review are going to be reading.
<lifeless> you know what a long repetitive patch is like to review.
<vila> the problem with that is that we tend to *never* address some problems
<vila> and we also said before that we are supposed to clean up things when we modify close enough parts
<lifeless> I've got nothing more to offer.
<lifeless> I'm sad.
<vila> so, hmm, looks like I will get back to the two branches approach but there was some concerns about polluting the active review queue with such cleanups too
<vila> and landing them without review was also frowned upon
<lifeless> I think that that concern is a reflection of this
<spiv> vila: so, my opinion is that opportunistic cleanups of nearby code is fine, but not at the cost of significantly worse diffs
<vila> lifeless: I don't want to make you sad because I
<vila> lifeless: I don't want to make you sad because I'm cleaning things up which should make you happy, that's counter-productive :)
<spiv> vila: If it e.g. makes a smallish diff large and repetitive I'd rather get two separate diffs.
<vila> so, how about a cleanup branch as a pre-requisite that gets automatically approved if not vetoed when the main branch is approved ?
<spiv> Um,
<vila> more work, but I'm ready to do it if it means we progress here
<spiv> Perhaps that's ok, although it seems like a solution to a problem we don't have yet?
<spiv> Is it really that hard to get approval for cleanup-only branches?
<vila> we have a problem: our code base is not consistent
<spiv> I haven't found that to be the case, but I also have not tried to land a large one recently.
<spiv> To be clear: a pre-req branch sounds fine to me
<spiv> It's the "automatically approved" part that I'm unsure about.
<spiv> Also, I think we still have the notion that an unreviewed branch can "time out" and just be landed, although we don't exercise it very often.
<spiv> Which would seem to cover that case (but I would hope we still do not exercise it very often).
<vila> spiv: I think that's the crux of the problem: do we want cleanups, do we want to review them ?
<spiv> Yes, and yes.
<spiv> In my opinion :)
<lifeless> I might let poolie have his office back.
<vila> then it boils down to not mixing them up with actual fixes
<spiv> The review will often be easy: read the explanation in the cover letter, and then eyeball the diff to feel secure that it is fine.
<spiv> Right.
<lifeless> vila: thats all I asked for
<vila> lifeless: good, I'll try harder then
<vila> lifeless: and sorry for starting grumpy on this subject
<mneptok> FINISH HIM!
<mneptok> (sorry. couldn't resist.)
<spm> we hadn't noticed :-)
<mneptok> i love you, too :)
<spm> mneptok: so how's the new job going since you abandoned us all?
<lifeless> mneptok: cavemen in mountain fortresses shouldn't throw spears.
<mneptok> spm: it goes well. busy as hell. long days. but quite rewarding.
<spm> excellent!
<mneptok> lifeless: i'm touched you noticed my brow-ridge.
<spm> touchÃ©!
<lifeless> mneptok: I've seen the photos
<lifeless> I went blind.
<lifeless> :)
<mneptok> lifeless: you know, i recently got another photo from the same day the "mnep the gigolo" photo was taken. this one onvolves a camisole, a top hat, and clown shoes.
<lifeless> _LOL_
<mneptok> oh, and grandma underwear
<lifeless> this is a family rated channel
<mneptok> grandma's part of the family.
<mneptok> and until i finish chewing through this leash, so am i. ;)
<mneptok> /m/m lifeless http://mneptok.com/kvf-clownshoes.jpg
<mneptok> gah
<mneptok> tab complete fail
<mneptok> ah well, don't click that if you're under 18 or value your sanity
<spm> I've menepolo'd before. how bad could this be.....
<spm> AAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaa
 * spm reaffirms the desire to NOT click on any menptok.com urls to images again
<mneptok> am i not hot?
<spm> um...
<mneptok> 01:45 < mneptok> i love you, too :)
<spm> hahahaha
 * mneptok rm's before Google decides to index that
<spm> Google. Knows. All. Google. Sees. All.
<poolie> that's exactly what stephenconroy needs to save us from
<poolie> apparently
<mneptok> Bing knows and sees all, but the Executive Oversight Committee For Strategic Use Of Internet Data And Applicability For Increased Market Penetration can't get the data on their Zunes.
<spm> EOCFSUOIDAAFIMP ?
<mneptok> gesundheit
<spm> thank you
<lifeless> poolie_: your _ is showing.
<poolie_> heh
<poolie_> as nethack says "you are being punished"
<poolie_> i think that's actually a _o
<lifeless> yah ball n chain
<jave> hello
<jave> I'm trying to set up an Hudson instance to build emacs from bzr
<jave> the Hudson bzr plugni tries to do this: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk /var/lib/hudson/jobs/emacs-trunk/workspace
<jave> but its really slow
<jelmer> jave, is there any reason it needs the full history
<lifeless> jave:  do 'bzr init-repo /var/lib/hudson/jobs
<jave> well, I want it to be compatible with the hudson-bzr plugin, will it work if I do it by hand?
<lifeless> yes
<jave> lifeless: stuff that has nothing to do with bzr lies in /var/lib/hudson/jobs
<lifeless> jave: you're right
<lifeless> add --no-trees to the command
<jave> hmm ok
<lifeless> thought that may cause it to not work
<jave> ok
<lifeless> I'd really just do what I initially suggested
<jave> ok, but what happens if I have different jobs with different bzr urls?
<jave> I think I will need special workspace configuration for hudson
<lifeless> no
<lifeless> honestly
<lifeless> just init-repo at the jobs level
<lifeless> its what everyone does.
<jave> ok
 * bialix waves at GaryvdM
<GaryvdM> Hi bialix
<bialix> Hey Gary!
<bialix> Thank you for doing release
<GaryvdM> Sure - Want it to get into the win installers
<bialix> yeah :-)
<bialix> how's footbal 'raound you?
<bialix> how's football around you?
<GaryvdM> Ah - cool. I don't watch it much
<GaryvdM> Do you watch it?
<bialix> GaryvdM: sometimes. last weeks was a crunch for me :-/
<bialix> GaryvdM: I'm planning to be on vacation in second half of July. And we need to release 0.19 final till August for Maverick. It means I have only 2 weeks for any QBzr development
<bialix> GaryvdM: do you have any specific things in mind that I should look at?
<GaryvdM> bialix: I'm also planing on taking a weeks leave soon.
<GaryvdM> bialix: It would be cool if they were in sync
<bialix> so maybe we should release 0.19 final till our vacations?
<GaryvdM> bialix: I want to try get at least qcat and qdiff to have a toolbar like qannotate
<GaryvdM> for 0.19
<bialix> hmmm
<bialix> yep, it would be cool
<bialix> I will try to look at qlog labels again
<bialix> we have one special case here: bzr qlog colo:
<GaryvdM> I've been chipping away at the threads branch.
<bialix> I want to see labels as colo:trunk, today it's shown as colo:/trunk
<bialix> chip away? what do you mean?
<GaryvdM> bialix: It's a saying - If you want to cut through a log, you chip away at it with a axe
<GaryvdM> bialix: work on it in small chunks..
<bialix> that means you have slow progress, correct?
<GaryvdM> bialix: slow, but steady
<jam>  morning GaryvdM, bialix, and vila
<vila> mornign jam
<GaryvdM> Hi jam
<bialix> heya jam! and bonjour vila!
<vila> bialix: privet :)
<bialix> :-D
<vila> bialix: brasil - netherlands should be a nice one ;-)
<GaryvdM> Hey vila
<bialix> vila: yep, I've heard comments and prognosis
<GaryvdM> jam: lp:~garyvdm/bzr-windows-installers/maybe
<GaryvdM> jam: I committed rev 119 with --author "John ... - I hope you don't mind
<GaryvdM> jam: Please could you do a quick review of rev 120
 * vila feel depressed, 2.1.0 and 2.1.1 have a test failure: bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures does that ring anyone bell ?
<vila> and 2.1.2 too
<GaryvdM> jam: I'm now stuck with a can't find zlib.h build error. Maybe I need to adjust so env var.
<jam> GaryvdM: well, for 2.2 we shouldn't need it at all
<jam> maybe setup.py needs updating?
<jam> or something is importing it that shouldn't be
<jam> I thought mgz tracked those down
<jam> vila: I haven't seen it before
<vila> jam: me neither 8-(
<vila> add 2.2
<GaryvdM> jam: building _chk_map_pyx.c
<jam> GaryvdM: other than not needing zlib.h, the original goal was that the build script would download zlib and put it in the path
<vila> jam: pass in trunk at least (which kind of rules out a weird setup here)
<jam> GaryvdM: so the issue
<jam> is again that igc's new code doesn't grab a tag
<jam> it grabs the latest in a branch
<jam> and lp:bzr/2.2 hasn't been updated
<GaryvdM> http://pastebin.org/375070
<jam> so it is still trying to build old code
<GaryvdM> jam: Ah - let me try build bzr.dev
<jam> GaryvdM: _chk_map_pyx.pyx has "cdef extern from 'zlib.h':"
<jam> which shouldn't be in 2.2b3
<jam> GaryvdM: it looks like we need to do more direct work on ian's code
<jam> and possibly get ahold of him to determine what he had in mind
<jam> vila: does it fail when tested in isolation (and succeed in bzr.dev in the same case)?
<vila> yup: ./bzr selftest -s bzrlib.tests.test_selftest.TestTestCaseWithMemoryTransport.test_dangling_locks_cause_failures --no-plugins
<vila> with extensions compiled in all cases (but that shouldn't be relevant)
<jam> fails here, too....
<jam> makes me think it is a test-tools issue
<vila> jam: forget it, sorry for raising it, unless pqm yelles at you , yeah, ne too
<jam> vila: len(result.failures) == 1
<jam> I have the feeling one testtools considered something a Fail
<jam> and one considered it an Error
<vila> definitely raises a bell now that you mention it
<jam> so I would say the test should become something like
<jam> assertEqual(1, len(result.errors) + len(result.failures))
<jam> with a big:
<jam> # Testtools sometimes considered this an Error, and sometimes a Failure
<jam> # so make sure to trap for bothe
<jam> vila: I seem to remember being worried that relying on a 3rd party tool for the test suite would cause spurious failures and lock-step versioning issues
<vila> I'm pretty sure lifeless did a patch very close to that
<jam> total_failures = result.errors + result.failures
<jam> if self._lock_check_thorough:
<jam>     self.assertLength(1, total_failures)
<jam> yep
<jam> in bzr.dev
<jam> albeit without the snarky comment against testtools
<vila> hmm, I think I asked for a comment, whatever the content was :) But fater the landing
<vila> after
<vila> anyway, we know how to fix it, back to regular schedule
<jam> vila: feedback on https://code.launchpad.net/~vila/bzr/525571-minimal-lock-bazaar-conf-files-2.1/+merge/29086
 * vila holds his breath...
<chaosaddict> anyone know what might cause this error message when doing a bzr fast-import?
<chaosaddict> "bzr: ERROR: The file id "TREE_ROOT" is not present in the tree <bzrlib.inventory.CHKInventory object at 0xa2a610c>."
<jam> vila: sent to the list
<jam> sorry, breathe again
<vila> deep shudder
<vila> jam: a = AtomicFile() ; a.write(data) ; a.commit() ; a.close() ?
<jam> vila: well, a = AtomicFile(filename); but yeah, something like that
<jam> IIRC LocalTransport uses AtomicFile for put()
<jam> GaryvdM: what else is in the environment that you need to copy? (It seems ok, I just wanted to check)
<jam> anyone know if the 2.1.2 installers are looking good? I'm thinking I should extract a nonadmin version
<GaryvdM> jam: It was failing like this. http://pastebin.org/371858
<GaryvdM> jam: I thought it would be easy to just copy the env rather than play wack-a-mole
<GaryvdM> *easier
<jam> GaryvdM: so the concern is accidentally having an env var like CFLAGS suddenly change your build (and it starts working/failing surprisingly)
<jam> however, I probably agree with you
<jam> I'm fine with just copying
<jam> given that everything else that builds just uses the existing env vars
<jam> we just want to *add* ones for tbzr
<GaryvdM> jam: ok
<GaryvdM> jam: I think we could maybe extend Project, Plugin, and Application in bazaar_releases.py to include revision specs.
<GaryvdM> jam How do we allow for differences in revision specs, with out duplicating all other details?
<GaryvdM> jam: Maybe copy and modify?
<jam> GaryvdM: what do you mean duplicating all the other details?
<jam> Are you thinking to have the same code base do multiple builds?
<GaryvdM> jam: Differences in plugin version between distributions
<jam> traditionally we just had separate branches for this
<jam> afaik that isn't planned
<jam> but I could be wrong
<jam> I also really don't know the plan for the distribution stuff
<jam> Certainly I don't really want to debug why Mac OS X has plugin version x, but windows has version y
<GaryvdM> jam: yes, you can currently do ./build.py bzr-dev or ./build.py bzr-2.2 or just ./build.py for both
<jam> or even worse, Vista has X, Win7 has Y, and XP has Z
<GaryvdM> jam in this context, distribution = bazaar major release series.
<GaryvdM> 2.1, 2.2, dev
<jam> bad name, then
<jam> IMO
<GaryvdM> jam: Agree  - lets look a renaming it once we have everything else figured out.
<jam> GaryvdM: so for that, I would even expect *what* plugins are bundled to be different
<GaryvdM> "Series" ftw
<GaryvdM> jam: yes
<jam> and I would expect the versions to be different at least 50/50.
<jam> since we have started working on stuff like stable qbzr releases, etc
<GaryvdM> jam: For me but pdb is unusable with cygwin. I don't see a prompt. The prompt only shows after I've pressed a key. (I see the same thing with bzr uncommit)
<GaryvdM> jam: Do you maybe know how to fix this?
<jam> GaryvdM: I don't really know, something is weird on that machine
<jam> I don't have problems at home
<GaryvdM> :-|
<vila> jam: fix with AtomicFile pushed
 * GaryvdM off to find food. bbl
<jam> vila: do you still need the intermediate StringIO, rather than just using AtomicFile as the thing you write to?
<vila> jam: no, fixed
<jam> vila: approve
<vila> jam: thanks
<vila> *now* I will have to take care of test failure :-/
<GaryvdM> Yhea - I don't get zlib err on bzr-dev.
<GaryvdM> I now get this error: http://pastebin.org/375504
<GaryvdM> jam: ^ Any ideas?
<chaosaddict> I'm new to Bazaar, but it seems like it might be useful to be able to use the Bazaar Explorer to get a file at an arbitrary revision number.
<GaryvdM> chosaddict: Like bzr revert foo -r x
<GaryvdM> chaosaddict: That was recently added to qlog.
<GaryvdM> (Bazaar Explorer uses qlog...)
<chaosaddict> oh cool, thanks.
<mgz> garyvdm: I think I remember a list message about having to remove the py3k port bits of pyqt
<GaryvdM> Hi mgz
<mgz> yeah, by jam, so he's probably the right person to ask.
 * jam hides
<jam> ugh. that terrible stuff
<jam> I ran into it, did something which seemed to fix it, it broke again, tried something else, etc, etc.
<jam> GaryvdM: we have this: excludes.append('PyQt4.uic.port_v3') in bzr.dev setup.py
<jam> which is the only thing that could approximately work
<GaryvdM> mgz: I can't find the mail. What is the subject?
<jam> but I ran in to all sorts of hell
<jam> leaving it out caused one failure, putting it in caused another
<GaryvdM> Err
<jam> Check the version of PyQt as well
<jam> PyQt4.QtCore.qVersion() says 4.6.1
<mgz> it's in the middle of Robert's "Python 3" thread, but what jam is saying now will probably help you more
<jam> QtCore.PYQT_VERSION_STR says 4.7
<jam> so it seems to be PyQt4  (4.7) which wraps Qt 4.6.1
<GaryvdM> I think that is the qt version. The pyqt version is 4.7
<GaryvdM> Er you faster than me
<jam> this was one-of-those-things that made me stick with python2.5
<jam> GaryvdM: the easier solution is to delete that directory from PyQt4
<jam> note questions like this: http://www.mentby.com/albert-cervera-i-areny/not-packaging-portv3-into-26-installer.html
<jam> which are exactly my problem, but no answers
<GaryvdM> jam: Please can we try moving the file out. You need to do. (admin)
<jam> GaryvdM: sure, I have to relog
<jam> though I thought I set the perms to be 'bzr' == Full Control
<jam> did you check?
<GaryvdM> No - let me try
<GaryvdM> jam: Nope - I cant
<GaryvdM> jam: We could maybe try exclued PyQt4.uic - let me check I we use it
<GaryvdM> *if
<jam> GaryvdM: I think we need it
<GaryvdM> jam: looking at the code, we only use it as a dev tool, in extras/build_ui.py, in both qbzr and bzr-explorer.
<GaryvdM> jam: The results are commited, so it is not even needed at build
<mgz> can you exclude build_ui.py from the packaging then?
<GaryvdM> Is it even included
<jam> GaryvdM: py2exe is bundling it, which is why we are having the failure
<jam> GaryvdM: try it now, I edited out the troublesome line
<GaryvdM> ok
<GaryvdM> jam: In which file?
<jam> PyQt4/uic/__init__.py
<GaryvdM> ok
<cebesius> i think i might have ruined my development branch when i did a bzr pull --overwrite. is there a way to back that out somehow? i tried revert but that didn't seem to have any effect.
<GaryvdM> cebesius: Look at bzr heads --all
<GaryvdM> cebesius: See if you can find the revision in there.
<cebesius> bzr: ERROR: unknown command "heads"
<GaryvdM> cebesius: Ah - you need the bzrtools plugin
<GaryvdM> cebesius: What os?
<cebesius> ok thanks. sorry i apologize for the noobery
<cebesius> ubuntu
<cebesius>  sudo apt-get install bzrtools ?
<GaryvdM> yes
<cebesius> i see the branch nick for my development branch. at the end of the HEAD: line, it says (dead)
<GaryvdM> cebesius: ok - now you can do bzr pull . -r <revid> --overwrite
<GaryvdM> cebesius: You will then have diverged branches, and will need to do a merge in one of them
<GaryvdM> cebesius: you can also do bzr merge . -r <revid>
<cebesius> GaryvdM: that just took care of it. thanks!
<GaryvdM> jam: wack-a-mole time: http://pastebin.org/375740
<GaryvdM> cebesius: Glad I could help.
<GaryvdM> jam: Don't you want to try give me permission to that dir.
<jam> GaryvdM: I think I did
<jam> I did try again
<GaryvdM> jam: ok - let me try access
<jam> so there are other entries according to grep, let me grab them
<GaryvdM> jam: I can edit now.
<GaryvdM> jam: It's building \o/
<jam> k, I hacked out a few more files
<jam> Compiler/qtproxies.py, objcreator.py pyuic.py and __init__.py are all touched
<GaryvdM> jam: setup.py py2exe succeeded. Now running whole script.
<GaryvdM> jam: If I edit something in any of the existing build branches, I get this error: http://pastebin.org/375786
<jam> mgz: so what is your thought on the -OO issue with user-installed plugins? Should we just back out the change? Should we just push harder on getting plugins fixed?
<jam> GaryvdM: you're not allowed to edit that way
<jam> by design
<GaryvdM> jam: note that the change I made was in bzr/setup.py, note in qbzr as the error indicates
<jam> we want to build from committed code
<jam> the qbzr-en.po stuff, I only see when that is actually regenerated
<mgz> well, we have to either fix bug 600803 or backout the setup change for the moment
<ubot5> Launchpad bug 600803 in Bazaar Windows Installers "Plugin pyo files may be ignored and recreated from source (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/600803
<jam> mgz: ugh, timezone issues?
<mgz> the bug will want fixing anyway, and it might still be best to backout the installer change for this release
<jam> what is your TZ?
<mgz> BST currently.
<mgz> GMT+1
<mgz> but it's when the installer is used that matters I think.
<mgz> library.zip isn't affected because though the zip is time shifted, the files inside get their stamps from the zip metadata
<GaryvdM> jam: the error also happens if I run build.py installer  (as as appose to bulid.py installer bzr.dev or bulid.py installer bzr-2.2.) But I guess that is something I can look at later...
<jam> mgz: it looks like the build host is Pacific Time UTC-7
<jam> you know what...
<jam> timestamp == Unix seconds from epoch.. Do we adjust for TZ or not
<jam> always been a bit wonky on Windows, IIRC
<jam> GaryvdM: I thought the qbzr stuff was because we weren't building a snapshot with newly generated .po files, but I could be wrong
<mgz> well, currently I wonder if the problem is actually our code or in nsis or whatever we use
<jam> mgz: where do you get the magic from? (what bytes)
<mgz> inside the pyo files - but it's being compared to the mtime of the py files
<GaryvdM> jam: yes - I think the error report incorrectly reports the project.
<jam> mgz: sure, but where in the pyo
<jam> so I can compare
<mgz> look at the first 8 bytes of the pyo files, first four are the magic, next four are little endian int_4 stamp
<GaryvdM> maybe I'm wrong
<mgz> so, if nsis is packing the files as localtime, and unpacking as localtime, that would break for anyone not in the same timezone as where the installer is created
<mgz> either that, or py_compile is borked.
<jam> mgz: they match here
<jam> os.lstat('commands.py').st_mtime == 1278013301.0
<mgz> what's your timezone?
<jam> struct.unpack('<i', open('commands.pyo', 'rb').read(8)[4]) == (1278013301,)
<jam> well not that exactly but you get the idea
<jam> TZ == UTC-7 I believe
<jam> (mine is -5, but build host is on Amazon EC2)
<jam> so it could be NSIS
<jam> mgz: what platform are you on?
<mgz> Xp
<jam> you know what, I can just set the TZ for that machine to UTC, who cares, right?
<jam> let me try that
<GaryvdM> jam: Please let me know when that is done
<mgz> worth a go.
<jam> GaryvdM: done
<GaryvdM> jam thanks
<mgz> might not work, but is easy to see if it does.
<jam> note, though, that this is on the old-windows-installers stuff
<jam> GaryvdM: and I'm being lazy and building as admin, since I don't want to relog
<GaryvdM> jam: I don't think that that would affect anything.
<GaryvdM> building as admin...
<jam> GaryvdM: well, it screws up perms for the rest of us
<jam> and is generally something I like to avoid
<jam> (consider running make as root)
<jam> just a 'hygiene' thing
<mgz> okay, bad news, don't think changing builder to gmt will help
<mgz> just checked the before and after stamps on 2.2b3 which I just installed (as in, in the summer, not the winter)
<mgz> and it's 8 hours out.
<jam> mgz: so you're saying that changing *your* timezone affected it?
<jam> the build is just about done
<mgz> I'm saying when my timezone changed one hour, the difference also changed an hour, which suggests my localtime matters, as well as the build slave's
<mgz> ie, it's doing localtime(a)->localtime(b) not localtime(a)->gmt
<GaryvdM> bla - wack-a-mole: http://pastebin.org/375882
<mgz> hm, so, it's either looking in the wrong place for the c runtime libraries, or they should be being copied there and they aren't
<mgz> not sure that's much help to you gary
<GaryvdM> http://pastebin.org/375893 - yhea - they are not there
<GaryvdM> So close, but yet so far...
<GaryvdM> jam: I'm stuck. http://pastebin.org/375882 Any ideas?
<jam> GaryvdM: if you look at build.py (or bazaar_releases.py) it mentions looking for where the msvcrt runtime redistributable stuff is
<jam> let me check
<jam> GaryvdM: DEFAULT_MSVC_REDIST_DIR
<jam> I see 3 msvc* dlls there
<jam> and build.py has a check if "self.python.find(26)" (which IMO is a bad check), then it tries to copy the msvcr90.dll over
<GaryvdM> jam: Ah - there is msvcr90.dll in build-win32\release\bzr
<GaryvdM> jam: Ah - there is msvcr90.dll in build-win32\release\bzr-dev\win32_bzr.exe\Microsoft.VC90.CRT
<GaryvdM> So it is copying into a subdir
<jam> sounds like it might be the wrong place
<GaryvdM> ah - see comment in bulid.py line 408
<GaryvdM> I'm going to modify that.
<GaryvdM> I cant' belive it. It built!!!! \o/ !!!!
<GaryvdM> http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~garyvdm-setup.exe
<GaryvdM> mgz, jam ^
<GaryvdM> Installed. bzr-explorer works, but I got this error: http://imagebin.org/103818
<jam> GaryvdM: strange, bundling "" certainly seems wrong :)
<GaryvdM> jam: I only get it when tbzr is selected
<GaryvdM> jam
<GaryvdM> jam: And toverlays is not getting installed.
<GaryvdM> So I think thats related
<jam> GaryvdM: maybe we are setting the env var incorrectly, or not getting it passed into the right part of the build
<jam> you might check the iss file
<GaryvdM> jam: I'm also getting a Unable to import library 'launchpadlib' error
<jam> GaryvdM: I believe there was a "pipeline depends on launchpadlib so lets back out pipeline" maybe there is another on elike it?
<GaryvdM> jam: I'm going to send a mail to the ml, and then go home. I'll try again.
<GaryvdM> jam
<jam> k
<GaryvdM> jam: I'm really happy though that I got it to build. Thanks for all the help.
<jam> GaryvdM: isn't it already like 10pm there?
<GaryvdM> 9pm - thats still early :-)
<GaryvdM> The last 3 nights I was in bed after 1am...
<GaryvdM> :-p
<GaryvdM> jam: And I need to add the ability to specify a revision spec for everything....
<GaryvdM> jam: Thanks alot for all the help.
<GaryvdM> Good night all.
<jam> night GaryvdM
<mgz> thanks for doing all this jam and gone-gary
<mgz> I'll give your installers a try here when I cool down a bit.
<mgz> http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint <- perl... surely using bzrlib would be easier (if not shorter)
<mgz> throwaway scripts are done in what you're familar with I guess
<jam> mgz: yeah, you could do a lot with bzrlib and just extract the raw texts in an optimal order
<jam> its a fairly sizeable branch
<jam> mgz: so I was wrong, it seems to be strictly dependent on the number of files in a given directory., my perl fu is pretty weak, and there is some ... interesting... syntax
<GaryvdM> Wow Brazil out...
<jam> GaryvdM: unexpected
<GaryvdM> Uruguay and Ghana in overtime...
<jam> mgz: my version: http://paste.ubuntu.com/458491/
<jam> takes about 20s to iterate 540 revs
<jam> I could probably do better if I got down into some hardcore details
<jam> but my graph looks just like his :)
<mgz> ah, much better after bath, still hot though
<lifeless> :>
<mgz> jam: that's really neat. making a proper commandline tool of it is dedication
<lifeless> of what ?
<mgz> ah, I linked this earlier: http://gwolf.org/blog/debian-its-numbers-seen-keyring-maint
<mgz> and jam answered my "would be better with bzrlib" by... doing a pretty (non-perl) version
<mgz> interesting just to see how much of the internals you need to understand to write a short script like that not going through the command line ui
<mgz> okay, tested the tz installer, and indeed the bug is still there, the stamp is now an hour out
<mgz> I'll try and find some nsis docs I think.
<mgz> http://sourceforge.net/tracker/index.php?func=detail&aid=2581469&group_id=22049&atid=373085
<mgz> probably that.
<ubot5> Error: <Bugtracker.plugin.Sourceforge instance at 0x2364bd8> bug 2581469 not found
<lifeless> -lol-
<mgz> hey, it tried!
<mgz> hm, how did I do that link-to-upstream-bug thing in launchpad before? does it need a launchpad project registered as well as the sourceforge one?
<lifeless> 'affects project', paste url.
<mgz> ...doesn't seem to like that
<mkanat> No subtrees yet, right?
#bzr 2010-07-03
<jam> mgz: ** Bug watch added: SourceForge.net Tracker #2581469    http://sourceforge.net/support/tracker.php?aid=2581469
<jam> I think it worked
<ubot5> Error: <Bugtracker.plugin.Sourceforge instance at 0x2364bd8> bug 2581469 not found
<jam> ubot5: the bug is 1.5years old, surely you can find it
<jam> mgz: well, in Vim I have !M<enter> as a macro to fill out all of the def main() import Optparse sort of stuff
<jam> so it is pretty trivial
<jam> I really don't like top-level scripting
<lifeless> why not use bzr's command infrastructure?
<lifeless> I do, or the stuff I put into testrepository
<jam> lifeless: I certainly could, and just write a plugin, I just started as a script here
<jam> both work
<jam> main is pretty trivial to get up and running
<jam> and I don't always depend on bzrlib
<jam> lifeless, mgz: http://paste.ubuntu.com/458547/
<jam> I set that up before bzr existed I believe
<jam> anyway, back to family time
<lifeless> vila: are you around perchance?
<mgz> not had to read pascal for a long time
<mgz> seems the right fix for installer bug is easy though, once I actually er... got the right bit of software
<GaryvdM> Hi mgz
<mgz> good timing.
<GaryvdM> I'll do a build with your patch now.
<mgz> can I twist your arm to try...
<mgz> right, that.
<mgz> thanks!
<GaryvdM> Bla - I have all sorts of uncommited channges - need to deal with them before I merge your branch...
<mgz> shelve!
<GaryvdM> Shelving some of it, commiting some of it.
<mgz> bad habit forming that, I have too much stuff stashed in pseudo-diffs in a hidden folder rather than getting finished
<mgz> I did only use it with hg, but have started using with with bzr as well.
<GaryvdM> I'm not sure how well the build script handles changes, so I'm doing a full build, rather than a incremental, just to be sure.
<GaryvdM> So it will take about 10min
<GaryvdM> mgz:http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~3-setup.exe
<mgz> getting.
 * GaryvdM tests using wine...
<GaryvdM> Bla fix for tbzr not working...
<mgz> meh, and seems timestamps ar still messed up
<GaryvdM> mgz: my branch that I am building with: lp:~garyvdm/bzr-windows-installers/maybe
<mgz> oddly, it's an hour *and a minute* out...
<mgz> >>> time.gmtime(struct.unpack("<2i", file(r"C:\Program Files\BazaarBeta\plugins\bzrtools\__init__.pyo", "rb").read(8))[1])
<mgz> (2010, 7, 3, 19, 17, 43, 5, 184, 0)
<mgz> >>> time.gmtime(os.stat(r"C:\Program Files\BazaarBeta\plugins\bzrtools\__init__.py").st_mtime)
<mgz> (2010, 7, 3, 18, 17, 42, 5, 184, 0)
<mgz> *second
<GaryvdM> mgz: maybe useful for debugging: http://innounp.sourceforge.net/
<mgz> will check, but I looked at their source and it seemed like the flag would do the right thing
<mgz> oaaaa... I have a bad feeling
<mgz> I'm going to try running the setup again, but this time setting TMP to my main NTFS drive first
<mgz> nope, still a second out.
<mgz> back to the pascal...
<GaryvdM> mgz: I thing you have made the change in the wrong place.
<mgz> this is possible, I hate build stuff.
<GaryvdM> mgz: templates/inno/bzr.iss
<mgz> it's not even clear to me if that was the input of a script or the output
<GaryvdM> Don't worry - I'm just as confused....
<mgz> the one-second problem won't be helped though... is the build slave on FAT rather than NTFS?
<GaryvdM> I'll check
<mgz> no... that wouldn't explain it either I don't think... grrr
<GaryvdM> NTFS, on both drives
<mgz> C:\>innounp -v bzr-2.2~bzr.dev~3-setup.exe | grep bzrtools.__init__
<mgz>       3689  2010.07.03 19:17  {app}\plugins\bzrtools\__init__.py
<mgz>       3249  2010.07.03 19:24  {app}\plugins\bzrtools\__init__.pyo
<mgz> so, it's stored as the right hour, but doesn't give me the seconds to check
<GaryvdM> mgz: let me know If I can run things on the build host to debug.
<mgz> well, did that cog thing get overwritten by the build process?
<mgz> should I try moving the change to the templates dir?
<mgz> that would at least fix the hours-out problem
<GaryvdM> I don't think that the cog file gets used at all.
<mgz> uuuu.
<mgz> okay, I'll move it, push, and if you could try again...
<GaryvdM> See Ian's comment here: https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/569077
<ubot5> Launchpad bug 569077 in Bazaar Windows Installers "Bazaar 2.2b2 install fails, Vista SP2 x64 (affected: 2, heat: 6)" [High,Confirmed]
<mgz> actually, I'm going to uncommit, I've made enough recored dumb mistakes on this bug already
<GaryvdM> https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/569077/comments/7
<mgz> can we not just... delete things that aren't used any more... why else do we use version control...
<GaryvdM> mgz: I've just stated doing the builds...
<mgz> I'm not blaming you
<GaryvdM> mgz: yes - I agree..
<mgz> but, speaking of blame, there's blame in that cog file from Ian,
<mgz> Date:
<mgz> 07/03/2010 11:54:07
<mgz> which is ... dammit!
<mgz> not a US date.
<mgz> so, it's not today ;)
<GaryvdM> lol ...
<mgz> okay, pushed the move, if you could pull and try that...
<GaryvdM> mgz: ok
<GaryvdM> I also want to try a different fix for the tbzr issue.
<mgz> if we have to add code to do % 2 on every py file mtime, I'm going to be annoyed
<mgz> http://www.jrsoftware.org/ishelp/topic_setup_timestamprounding.htm
<mgz> okay, that's to blame for the rounding
<mgz> just changing that would fix the issue fully for nearly everyone, but potentially screw fat people
<mgz> seems like and improvement though so I'll add it to my existing branch
<mgz> pushed that as well if you've not started the new build yet
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~4-setup.exe (without time stamp rounding)
<mgz> will test that, thanks.
<mgz> don't worry about the new change yet.
<GaryvdM> mgz: I'll kick off a another build
<GaryvdM> mgz: that was an incremental build. Let me know if you don't see any change.
<mgz> will do, nearly downloaded
<GaryvdM> Maybe later we can look at trying to make the install smaller. I think there are some pyqt .pyd files we don't need.
<mgz> excluding stuff like that script you mentioned yesterday and seeing if that helps sounds worthwhile
<mgz> okay, that build has the right hour.
<mgz> so incremental seems to be fine, as does my FAT tmp drive
<mgz> just need to see if my last push also sorts out the second
<GaryvdM> \o/ TortoiseOverlays bug fixed.
<mgz> go gary.
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~5-setup.exe
<mgz> wgetting
<GaryvdM> We can remove 6mb (uncompressed) unneeded pyqt files
<GaryvdM> But other things first.
<mgz> works.
<mgz> timestamp matches, qbzr help displays
<mgz> pipeline-launchpadlib issue still needs fixing
<mgz> was sure Aaron had another crack at making that lazy-loaded, is there not a pending rev to pull or something?
<GaryvdM> mgz: But what functionality do we lose buy not having the lib?
<GaryvdM> mgz: I thing better to just add the lib.
<mgz> lp-propose and some other bits I think
<mgz> the problem is it's not just the lib
<mgz> it's a maze of setuptools dependencies and related mess spanning eight or so packages
<mgz> it doesn't even *let* you install it by the normal methods
<mgz>   File "C:/Program Files/BazaarBeta/plugins\pipeline\__init__.py", line 161, in <module>
<mgz>   File "C:/Program Files/BazaarBeta/plugins\launchpad\lp_api.py", line 43, in <module>
<mgz> DependencyNotPresent: Unable to import library "launchpadlib": No module named launchpadlib
<mgz> (with -Derror so pipeline has an indirect need via launchpad plugin apparently)
<GaryvdM> mgz: Bug  569717
<ubot5> Launchpad bug 569717 in Bazaar Windows Installers "bzr-2.2b2-setup.exe - error re: launchpadlib/pipeline (affected: 1, heat: 3)" [Undecided,New] https://launchpad.net/bugs/569717
<mgz> okay, that's trivial, he's catching the wrong error
<mgz> it's in an except ImportError wrapper, but launchpad plugin is reraising as bzrlib.errors.DependencyNotPresent
<mgz> I can fix that in pipeline and defer the should-and-how over launchpadlib
<GaryvdM> mgz: I think better to put effort in adding launchpadlib to the installer.
<mgz> bzrlib.errors isn't something we try and load lazily is it? comes under huge-but-essential.
<mgz> by all means have a look at it, but... I bet it won't be fun.
<GaryvdM> mgz: Making it lazy import is tricky.
<GaryvdM> mgz: I have a branch which dose it. I did not submit - to hackey.
<mgz> right, so I can just import and not worry.
<GaryvdM> mgz: lp:~garyvdm/bzr/more_lazy
<mgz> ...think I should file a new bug against bzr-pipeline or add the project to the existing bug/
<mgz> don't know launchpad ettiquette here
<mgz> /=?
<GaryvdM> First check for existing bugs in pipeline...
<mgz> didn't find anything searching for "launchpadlib"
<GaryvdM> mgz: I would say they are 2 different bugs.
<GaryvdM> installer does not have launchpadlib
<GaryvdM> pipeline does not lazy import launchpadlib
<GaryvdM> So IMO log a new pipeline bug.
<mgz> k, will file new bug against pipeline.
<mgz> can you try an installer build with a bzr-pipeline from my branch rather than trunk, or is that hard to do?
<GaryvdM> I can do that. Branch lp url?
<GaryvdM> mgz ^
<mgz> lp:~gz/bzr-pipeline/no_launchpadlib_needed_601466
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~4-setup.exe
<GaryvdM> mgz: http://dl.dropbox.com/u/4494367/bzr-2.2~bzr.dev~5-setup.exe
<GaryvdM> 5 not 4
<mgz> the last one was also ~5?
<mgz> that is, I have a ~5 on disk already
<GaryvdM> Oh - opps - sorry
<GaryvdM> Here I am, building a version control system , and I can't count...
<mgz> it's a different size so I'm guessing it is actually a new build :)
<GaryvdM> Yes
<GaryvdM> Drop box did not warn me that I was overwriting :-(
<mgz> that seems to have worked
<mgz> no more pipeline complaints.
<GaryvdM> Cool - I'm going home shortly. I'll be around tomorrow morning.
<mgz> I'm out of problems to make you test.
<GaryvdM> :-)
<mgz> I'll throw up a branch with a bzr setup.py change that's easy but ugly, but doesn't need experimenting with.
<GaryvdM> mgz: I need to make the new scripts accept a taged revision, try bundle launchpad lib, remove unneeded pyqt revisions, find a better solution to the PyQt.uic.port_v3 problem, create a test build with bzrw.exe, try removing unused build code (such as the cog files).....
<GaryvdM> *unneeded pyqt files
<GaryvdM> :-)
<mgz> lp:~gz/bzr/installer_plugin_script_timestamp_rounding <- the change
<mgz> not sure it's really a good idea, and that py2exe stuff all needs to live in bzr-windows-installers rather than core, but hey
<GaryvdM> Yes Yes Yes
<GaryvdM> Or in plugin setup.py
<mgz> simple enough to write that having thought of it earlier as an option may as well just propose and let others decide
<GaryvdM> You rock.
<GaryvdM> Cheers mgz.
<mgz> evenin'
#bzr 2010-07-04
<mkanat> I wish I had a meliae for Perl. :-|
<mgz> I wish there was one and only one python memory tool instead of the five or so currently used
<mkanat> Well, at least they are reasonable and sane.
<lifeless> mgz: there is only one.... worth knowing
<lifeless> mgz: I've done subunit and testtools releases.
<lifeless> mgz: is that thread fully pulled on now ?
<mgz> I believe so. Got some updates for bzr, but that wants to lag a bit anyway.
<mgz> bug 582113 and some other misc testtools regressions that I've still not got round to filing, then maybe followup for Parth and Alexander who got stuck on writing unicode tests prviously
<ubot5> Launchpad bug 582113 in Bazaar "Tests don't run under Python 2.7 (unittest._WritelnDecorator has moved) (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/582113
<mgz> ^fix that by using testtools bits rather than unittest bits
<lifeless> lets nuke the use of WritelnDecorator too
<mgz> right. it's a fantasically pointless class.
<lifeless> its surprising for new players
<mgz> anyway, we want testtools runner and texttestresult
<mgz> which avoids the issues with 2.7
<lifeless> any reviewers around ?
<mneptok> The plot was thin, and the actors seemed both disinterested and wooden. A script rewrite is in order.
<lifeless> well roughly
<lifeless> turns out that using bzrlib.lsprof.profile in a threaded app is a little .. risky
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/lsprof_lockout/+merge/29165 is the result
<mgz> risky as well as being pointless as per bug 579185?
<ubot5> Launchpad bug 579185 in Bazaar "lsprof records profile from sub threads, but does not save them. (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/579185
<lifeless> shrug
<lifeless> that is fixable - I thought GaryvdM had a fix pending in fact
<lifeless> mgz: but since you are here, you can review my patches ;)
<mgz> didn't look easy to do cleanly when we looked at it, but part of that was just the display of the results
<mgz> the locking you've added looks sane to me, but I don't understand the actual problem
<lifeless> minimally showing them as separate top level entry points would be better than nothing
<lifeless> we call threading.setprofile
<lifeless> thats a 'change a global
<lifeless> so when 579185 is fixed
<lifeless> say you have a threaded webapp - I dunno, a wsgi server, or launchpad, or whatever.
<lifeless> if in two threads at once you do 'profile(sublayer, args)'
<lifeless> the second entrant to profiler.start()
<lifeless> will override threading.setprofile
<lifeless> new threads started by *either* request
<lifeless> will get collected to the second entrant.
<lifeless> also new threads started after either exit will not get collected at all because we reset the profile function for new threads to None
<mgz> ah, right, I get it, thanks.
<mgz> seems like threading._profile_hook should really be thread-local
<lifeless> so new threads would use a trampoline to pass it on each time as well
<lifeless> and you'd get a graph of threads with it set appropriately? Yes.
<lifeless> that would be nice.
<mgz> yup. your fix looks good, I'll just test it here.
<lifeless> thanks
<lifeless> have I mentioned I hate distutils ?
<mgz> who doesn't?
<lifeless> tar tzf ../testtools-0.9.4.tar.gz | grep compat
<lifeless> I hate setuptools/distribute more
<mgz> likewise.
<lifeless> |o/
<mgz> distutils is just messy and barely documented. setuputils is actively evil.
<mgz> *setuptools
<lifeless> god, why isn't it finding it
<mgz> hmm, interesting
<mgz>     return _win32_fixdrive(mkdtemp(*args, **kwargs).replace('\\', '/'))
<mgz> RuntimeError: maximum recursion depth exceeded
<mgz> wonder what the *top* of that stack was
<lifeless> \o/
<lifeless> I'm fairly sure thats not my patch :>
<lifeless> IMBW
<mgz> I'll try dev and see if it's a recent thing there
<mgz> yup, it's on dev... gra.
<lifeless> ><
<lifeless> have you perhaps looked into how distutils finds files before ?
<mgz> ooh, I just upgraded testtools yesterday
<lifeless> mgz: teehee
<mgz> wonder if it's related to that rather than a bzrlib change... hope not.
<lifeless> ok, MANIFEST existing messes setup.py up.
<lifeless> ><
<mgz> nope, regression from r5326 - sorry vila
<lifeless>  /o\
<mgz> the problem with tests... need them to be static to be reliable, but then they become full of cruft and bad examples
<lifeless> well
<lifeless> I don't really care about old cruft badness; I care about performance and maintainability.
<lifeless> Folk that use tests as examples of production code are being optimistic IME.
<mgz> the problem with that is expecting new contributors to write tests when bzr has changed style substantively several times across its lifetime
<lifeless> and new tests have fluent folk reviewing, so at most a little rework happens when someone copies.
<lifeless> which the reviewer can usually trivially do.
<mgz> I'm still not sure how to write a bunch of things I'd like to be testing... and I quite like tests
<lifeless> mgz: yeah, there is some overhead there, but new contributor % vs total-test-base-size  :>
<lifeless> mgz: just ask !
<mgz> okay, poping the stack, need to check your lsprof ones still
<mgz> passes with 5326 merged out.
<lifeless> today is yak shaving day.
<lifeless>  /o\
<lifeless> james_w: if you're up, have you looked into bug 588060 any further? I'm hitting it now with a fairly simple rename (util.py -> compat.py in testtools)
<ubot5> Launchpad bug 588060 in bzr-builddeb "unversioned executability issue, perhaps in builddeb (affected: 2, heat: 8)" [High,Triaged] https://launchpad.net/bugs/588060
<mgz> okay, fixing osutils is easy, though I'm a little confused as to what vila was trying to change there
<mgz> ah, I see, ugly lazy import interaction
<mgz> and mostly pointless, I don't think you can even do `bzr rocks` without importing tempfile
<lifeless> lazy import is a bit overused as a tool
<mgz> osutils should just... not shadow things in the os module, it's bad, wrong, and confusing
<lifeless> no real opinion either way here
<lifeless> OT1H the function names are well defined and we do supply less broken versions
<lifeless> OTOH they are shadowing the real ones.
<mgz> well, it's better than monkey patching ntpath at least, but what, off the top of your head, is the difference between os.rename and osutils.rename for instance?
<lifeless> handles open files
<lifeless> that one is more questionable
<mgz> ...think I'll keep this a one-line fix, rather than trying to make the code sane
<lifeless> :>
<lifeless> that reminds me
<lifeless> have you seen withhacks? I think you'll appreciate the evilness
<lifeless> mgz: ^
<mgz> ah, no, but... I've seen the sort of things ruby people do
<lifeless> http://pypi.python.org/pypi/withhacks
<mgz> using with to create tree structures like html DOMs and anything else they want an indent for
<mgz> okay, that really is quite horrid. the javascript-style with is bad enough, but the xargs class is just... insane
<mgz> why would anyone ever think doing that is a good idea...
<mgz> one thing I would like the with statement for (and I'm not all that keen on it, it's a whoops-we-screwed-up-scoping-originally type modification like the javascript 'let')
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=we
<mgz> is lazy imports.
<mgz> could do lazy imports with with, and then not have any of that string parsing mess
<lifeless> mgz: there was a thread on that on python-ideas just recently
<mgz> I stopped reading python-ideas shortly after it was created
<lifeless> :)
<mgz> seemed like python-shutup-and-get-off-dev, has it improved?
<mgz> what was the thread subject?
<lifeless> looking
<lifeless> explicitation lines
<mgz> reading.
<mgz> seems very alien for python (and not just because of the french word)...
<mgz> using to just being able to read forwards, rather than in every direction at once as per functional languages
<mgz> *used
<fax8> hi guys, I've checked out from a .htaccess password protected directory repository. Now each time I bzr up it asks me the username/password twice.. is this a bug?
<mgz> yes.
<fax8> ok, I'm on bzr 2.1.2.. new versions fixes that?
<lifeless> I've not heard of the bug before
<mgz> trying to find bug, but I might have hallucinated it.
<lifeless> I'd check you have your authentication.conf setup correctly.
<lifeless> mgz: set a message on your installer merge... and land it:)
<lifeless> mgz: you can use lp-propose -m to set the message when you create it
<mgz> fax8: other thing you can try is -Dhttp and look at the log
<mgz> have I got perms to land on the installer project lifeless?
<lifeless> mgz: you put a merge up for bzr
<lifeless> mgz: you would for the installers if you joined ~bzr no ~bzr-core, I think.
<mgz> oh, that bit, doh.
<mgz> ...maybe I should join ~bzr, given yesterday
<mgz> poking bzr lead to changes across three different projects
<fax8> here is the log http://pastebin.com/wfPS3VmQ
<fax8> I'm still not too bzr savy to understand what's happening there
<vila> mgz: Was your fix a one-line change to use tempfile.mkdtemp instead of mkdtemp ?
 * vila passing around *very* briefly
<mgz> it was: https://code.launchpad.net/~gz/bzr/win32_mkdtemp_infinite_recursion/+merge/29166
<mgz> fax8: so, the thing that jumps out there is the 401-401-401-200 sequence
<mgz> *401-404-401-200
<fax8> ok, what should I do?
<vila> SHUDDER, introduced after a review tweak :-( And as such not tested on babune :-( :-(
<lifeless> vila: regressions hide around every change
<vila> which is daunting as this was part of an effort to make the test suite *pass* on windows :-(
<vila> lifeless: yeah, I don't run enough tests...
<mgz> to avoid it for the moment you can probably put the password in authentication.conf as lifeless suggested earlier
<mgz> I'll have a go at repoing here later.
 * vila goes back tightening his hanging rope
<mgz> fax8: `bzr help authentication`
<mgz> what was I doing... oh yeah, commit message
<vila> mgz: was it at least caught by a fialing test ?
<mgz> it made the whole test suite blow up.
 * vila put the rope aside
<vila> mgz: sorry for that and thanks for the fish^H^Hx
<mgz> ...launchpad doesn't seem to have a way of unproposing yourself of a team
<mneptok> mgz: did you mistakenly try to join worldcup-fr?
 * mneptok woggles an eyebrow at all the French present
<mgz> heh
<GaryvdM> Hi all
<mgz> morning gary.
<GaryvdM> mgz: Any luck with removing the win32 installer stuff out of setup.py?
<mgz> ha, I'm too smart to launch on that one ;)
<GaryvdM> mgz: I think I'm going to have to add to if for launchpadlib, and it feels wrong putting it in to bzr.dev/setup.py....
<GaryvdM> s/if/it
<lifeless> GaryvdM: to shave the yak, or yak the shave?
<mgz> yeah, half the file is qbzr/tbzr/py2exe already... needs doing, just a little painful
<lifeless> the question to ask is
<lifeless> 'if someone is installing directly from source, do they need this'
<lifeless> if the answer is yes, do it in setup.py (or something imported into setup.py)
<GaryvdM> I feel the answer is no.
<lifeless> then do it outside of setup.py
<lifeless> whatever is in setup.py is irrelevant at this point :)
<mgz> on the fax8 http auth problem from earlier, does this (typing guest/password as prompted):
<mgz> bzr branch http://float.endofinternet.org/bazaar/testauth
<mgz> also prompt twice for everyone else?
<mgz> there are a lot variables with bzr and http
<lifeless> twice
<lifeless> love the domain
<mgz> thanks, I'll poke around later and see if I can find the problem.
<lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167
<lifeless> we'll want to port the basic support for this to bzrtools too
<lifeless_> 20:44 < lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167
<lifeless_> 20:44 < lifeless> we'll want to port the basic support for this to bzrtools too
<lifeless> now where was I
<lifeless> thats right, merge-upstreaming
<iocor> is it possible to get the changes to file contents from a TransformPreview object?
<lifeless> should be possible
<lifeless> I think it offers the tree interface
<lifeless> and thus tree.get_file(file_id) -> file contents
<iocor> .get_preview_tree.get_file(file_id).read()?
<lifeless> yea
<iocor> thanks
<iocor> lifeless: how would I do the same thing post-commit? (I'm using a builder to do the commit)
<lifeless> I need a little more context to help
<iocor> lifeless: so I'm looking to get all the file contents of all the files in my branch after a commit
<lifeless> are you using the API ?
<lifeless> or command line
<lifeless> ....and packages for testtools and subunit uploaded to debian.
<iocor> bzrlib
<lifeless> so, you have two options
<lifeless> a post comit hook
<lifeless> or after calling commit, you can obtain the revision tree from the repository for the committed revision
<lifeless> revid = tree.commit(..)
<lifeless> revtree = tree.branch.repository.revision_tree(revid)
<lifeless> revtree.lock_read()
<lifeless> revtree.get_file(fileid)
<lifeless> etc
<GaryvdM> mgz: I've managed to move the py2exe code to it's own file in bzr-windows-installers. It feels a bit hackey. Maybe you could take a look, tell me what you think. http://bazaar.launchpad.net/~garyvdm/bzr-windows-installers/maybe/annotate/head:/build_bzr_py2exe.py
<GaryvdM> Let me see if I can build an installer with it...
<iocor> ok, I have the following code: http://dpaste.com/214454/ and the following trace: http://dpaste.com/214456/. For some reason post-commit the file hasn't changed even though the TransformPreview contains a change to the repo. Why is this?
<fbond> nit
<fbond> (Sorry, empathy window stole my keyboard focus.)
<PrinceAMD> hi guys, does bzr make 2 copies of images when a client do a fetch/checkout, i'm using svn right now, and if my image folder has 100 images inside .svn it has the same so it uses 2x the space
<jam> PrinceAMD: no
<jam> it will have a compressed copy in the local repository, but it doesn't need the pristine copy that svn uses
<PrinceAMD> ok jam , also image does not compress that well, so i might end up with same result
<jam> PrinceAMD: there will be a fair amount of 'it depends' involved.
<jam> such as, you could do a lightweight checkout
<jam> or if you have a shared repo, there is only 1 copy across all your branches, etc.
<PrinceAMD> hm.. lightweight checkout looks nice, i'll test it
<GaryvdM> Hi jam.
<lifeless> mgz: small meta: when commenting on bugs, be lovely if you can triage at the same time.
<lifeless> you don't have too, and perhaps you usually do - if either apply just ignore me :)
<mgz> GaryvdM: the py2exe move looks pretty good to me, surely it's not that easy though :)
<mgz> lifeless: I don't have perms. well, I can confirm, and assign to myself, but I can't set prio or any of the rest
<lifeless> garh
<lifeless> ok
<lifeless> so I can add you to bzr; want to be in there ? cost: lots of mail. pros: no more process friction.
<mgz> I was looking at that this morning
<mgz> the main is gmail won't let you filter on X-Launchpad-Message-Rationale
<mgz> +pain
<lifeless> oh
<mgz> so, it'd probably nuke my nice orderly mailinglist account
<lifeless> I filter on the rationale paragraph at the bottom of the mail
<lifeless> 'because you are a member of' :P
<mgz> ah, the "You received this bug notification because..."
<lifeless> you can also do a direct subscription in LP
<mgz> that sounds like it'd work
<lifeless> and then turn off things
<lifeless> e.g. don't care about mac installers? subscribe to that with a no-mail subscription
<lifeless> mgz: your mkdtemp patch needs landing :)
<mgz> hm, this might be a bug, it seems "because you are a member of..." overrides "because you are a direct subscriber..."
<mgz> don't want to archive bugs I actually filed
<lifeless> so this is something deryck is very interested in
<lifeless> they are overhauling the bugs subscription stuff at the moment.
<lifeless> I can has review? https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/29139
<mgz> me no know looms 'm 'fraid
<mgz> ah, you're just deleting something. and... is adding the matchers there serving any purpose?
<lifeless> oh! oversight
<lifeless> I was going to make the same change I made a few revisions earlier to per_interbranch
<lifeless> where the test is duplicated
<lifeless> I changed my mind.
<mgz> ...either I'm going mad, or there's no way to add the "inbox" label back to a thread with the basic gmail web interface
<lifeless_> o/~ I hate huawei E160's o/~
<lifeless_> 08:38 < lifeless> oh! oversight
<lifeless_> 08:38 < lifeless> I was going to make the same change I made a few revisions earlier to per_interbranch
<lifeless_> 08:38 < lifeless> where the test is duplicated
<lifeless_> 08:38 < lifeless> I changed my mind.
<mgz> Isee.
<lifeless_> (changed and deleted instead)
<mgz> does per_interbranch cover what per_branch is testing anyway?
#bzr 2011-06-27
<jelmer> that means it's not as accidental I guess, makes me a bit nervous :-/
<jelmer> lifeless, what are you running, a bzr release/bzr.dev/whatever is in the lp tree?
<lifeless> bzr revno ~/source/baz/bzr-test-fixes/
<lifeless> 5809
<lifeless> apparently
<lifeless> which is apr 21st
<jelmer> thanks
<lifeless> I'll update to tip
<lifeless> not being a bzr dev I've become kinda slack :)
<jelmer> :)
<jelmer> please let us know if that helps
<jelmer> plenary here at 9 tomorrow, which means I should get some sleep
<jelmer> g'night!
<lifeless> its what, midnight now? sleep well
<jelmer> yep, midnight
<Kamping_Kaiser> is there a bash bit to display bzr status in PS1 (ala git)?
<bob2> http://www.brokenbuild.com/blog/2008/06/30/getting-git-subversion-and-bazaar-version-control-information-into-your-bash-prompt/
<Kamping_Kaiser> bob2: thanks. thought there migth be something in bzr, but i'm happy with whatever :)
<Kamping_Kaiser> is bzr import-orig meant to revert local changes made to a branch? its just deleted several files i added/modified, and i'm unsure why that would be. its help indicates it should be usable to merge a ds
<Kamping_Kaiser> c
<Kamping_Kaiser> wonder if its becuse i hadn't tagged a release with my changes (since there was no release yet)
<Kamping_Kaiser> so its reset to the tags it had, then upgraded from there.
<maxb> import-orig? You mean import-upstream?
<Kamping_Kaiser> i don't appear to havea n import-upstream
<Kamping_Kaiser> i was refering to import-dsc (sorry)
<maxb> import-dsc is intended to be used in a tree without any local changes
<maxb> it should probably complain if it doesn't do that already
<Kamping_Kaiser> odd. the last paragraph makes it sound like its supported.
<maxb> It's strictly an import tool. If you're doing something merge related, it's the wrong command
<Kamping_Kaiser> ok. that last para probably needs fixing then
<maxb> The last paragraph refers to importing a new version of a .dsc that was prepared by someone unware of the version control system
<maxb> I'm not sure how it could be "fixed", I find it a reasonable description of a use-case
<Kamping_Kaiser> so its not intended to handle the case where someone does an upload and you've made edits to the vcs in the mean time?
<maxb> Oh, I see
<maxb> In that case you'll need to branch from the proper point of ancestry for the upload, then use import-dsc, and merge it
<Kamping_Kaiser> ok. thanks for clearing that up
<Kamping_Kaiser> does bzr often mark files conflicting when they are identical? I've never seen it before, wondering if it happens to otehrs
<Kamping_Kaiser> and whats the correct resolution procedure, simply mark it resolved?
<bob2> mark = textual conflicts or file-tree conflicts?
<Kamping_Kaiser> `bzr conflicts  --text` lists nothing, so i assume file-tree?
<bob2> two people adding files with the same name are conflicts
<Kamping_Kaiser> fwiw, it was a merge with bzr merge-package
<Kamping_Kaiser> i must have chosen the wrong revision as my merge root, as those files are upstreams
<ssbr_> What places are there to host bzr projects, other than launchpad?
<jave> I have a local bzr repo that I would like to be able to push to github. is "dpush git" the correct solution? dpush seems to be aimed at the remote foreign repo is the master but that is not the case here
<gour> ssbr_: SF is one
<Kamping_Kaiser> gnu savannah do, and i think gna can
<gour> check https://www.mergebox.net/ as well
<Kamping_Kaiser> alioth does too, but not sure if its debian only or not
<ssbr_> alright, I'll look into these. Thanks!
<poolie> vila, hi :)
<maxb> Hi, could someone requeue --auto qbittorrent on jubany please?
<poolie> hi maxb
<maxb> Hello
<poolie> done
<poolie> ssbr_: i'm curious if there's something that blocks you using launchpda or if you just wanted to know all the options ...?
<maxb> There are 3 bugs containing various other more complex jubany wrangling, but they can all wait for someone to have a reasonable block of time to consider them
<poolie> ok
<poolie> did you start a ppu proposal?
<poolie> i'd like to for jubany access for you but it would help to have a 'who on earth is max' page to point to
<maxb> I did not yet - didn't get time over the weekend
<poolie> np, just didn't want to stall it
<poolie> i have a lot of unread mail
<daniel4> hi.  is anyone familiar with hooks: http://doc.bazaar.canonical.com/bzr.2.3/en/user-guide/hooks.html ?  I can't get the first example working because I don't know what "your configuration directory" means--BRANCH/.bzr/ ?
<daniel4> ah it means ~/.bazaar/plugins/
#bzr 2011-06-28
<wrtpeeps> guys, any clues at all why I'm getting this error when trying to branch:  http://paste2.org/p/1492524
<lifeless> wrtpeeps: I'm not sure; could you file a bug? i tlooks like something to do with your temporary directory - pehraps permissions
<wrtpeeps_> lifeless, a bug? after 5 mins of using it? That must be a record! :D
<lifeless> wrtpeeps: it may be a local configuration issue on your machine
<lifeless> bzr definitely works on windows
<wrtpeeps> hm
<lifeless> 12:10 < lifeless> wrtpeeps: it may be a local configuration issue on your machine
<lifeless> 12:10 < lifeless> bzr definitely works on windows
<wrtpeeps> im running the bzr command line as admin
<wrtpeeps> i wonder if it's pageant
<lifeless> there should be a more complete backtrace in your bzr.log
<lifeless> bzr --version will tell you where that is
<lifeless> back soon
<ssbr> poolie: we don't seem to get along well, that's all. Lots of small things that have driven me insane by now.
<nad> hi, when doing 'bzr launchpad-login <myUsername>' from the terminal I get the following error regarding proxy auth:'bzr: ERROR: Connection closed: curl connection error (Received HTTP code 407 from proxy after CONNECT)'. New to ubuntu dev, using natty. Added my ssh key to launchpad successfully. Any ideas? http_proxy env variable is set
<nad> http_proxy env is correct, able to use apt-get successfully using this
<spiv> nad: 407 is "407 Proxy Authentication Required"
<lifeless> nad: IIRC thats because your proxy wants proxy authentication
<spiv> vila may remember how to configure bzr to auth to your proxy
<nad> spiv, lifeless: thanks for the quick response. I cannot seem to find a way to set the authentication settings in bzr through curl.
<nad> should have googled bazaar instead of bzr, getting a lot more results :-)
<poolie> nad, see https://bugs.launchpad.net/bzr/+bug/363019
<ubot5> Ubuntu bug 363019 in Bazaar "bzr fails to do proxy authentication" [Low,Fix released]
<nad> ubot5: seems to work when i export my https_proxy with the same value as http_proxy, which contains my username and password. Thanks
<ubot5> nad: I am only a bot, please don't think I'm intelligent :)
<thumper> jelmer: ping
<jelmer> thumper: p0ng
<iwata> part
<poolie> gz, are you around perchance?
<poolie> maxb, i sent a proposal to the tb about you
<poolie> getting access to jubany
<maxb> ok, I will try to write something about my existence on wiki.ubuntu.com
<iwata> jelmer: Hello. https://bugs.launchpad.net/bzr-svn/+bug/795994 This problem is critical for me. Can I reopen it ?
<ubot5> Ubuntu bug 795994 in Bazaar Subversion Plugin "Files with non-ascii path are not pushed to svn" [Undecided,Incomplete]
<jelmer> iwata, hi
<jelmer> iwata, I've reopened it; a test case would be very nice
<jelmer> jam: ping
<jelmer> jam: bug 441125 - do you know why your fix for that would not have landed?
<ubot5> Launchpad bug 441125 in Bazaar "bzr reconcile doesn't work on stacked 2a repositories" [High,Confirmed] https://launchpad.net/bugs/441125
<jelmer> jam: nevermind
<iwata> jelmer: Thank you.
<spiv> vila: https://code.launchpad.net/~spiv/bzr/faster-branch-open/+merge/66165
<RobOakes> Good morning. Is this a good place to ask questions about bzr recipes?
<spiv> RobOakes: sure.  #launchpad too.
<RobOakes> Cool. I'm trying to create a daily build recipe for LyX, a word processor that uses LaTeX. I've got a separate packaging branch and my source branch and they merge alright. However, the build fails because it can't find or read the debian changelog.
<RobOakes> (Which is found at debian/changelog. I've taken the debian folder directly from the lyx package and can't figure out why the build is failing.)
<RobOakes> I'm also not the package maintainer, just one of the regular devs. So, this is all kind of new to me.
 * spiv pokes jelmer
<jelmer> RobOakes, what is the recipe?
<RobOakes> It can be found here: https://code.launchpad.net/~lyx-outline-devel/+recipe/lyx-2.1-daily
<RobOakes> but, #bzr-builder format 0.3 deb-version ...
<RobOakes> branch
<RobOakes> nest-part packaging lp:packaging-branch debian
<spiv> RobOakes: ah
<spiv> "debian/changelog didn't contain any parseable stanzas."
<spiv> You need to indent lines 3 and 4 of debian/changelog I think
<spiv> Just like the existing entries.
<RobOakes> Oh. (I hate it when I oversee stupid things like that.)
<spiv> I *might* be wrong
<threeve> is the pager plugin dead?  is there an alternative for having commands like diff and log automatically run through less other than just defining aliases?
<jelmer> RobOakes, have you tried the build locally?
<RobOakes> Yes. I run into the same packaging errors, but I wasn't sure if it as from my recipe, my debian directory, or the fact that my computer doesn't like me.
<spiv> RobOakes: I think your open-minded approach to debugging :)
<spiv> s/think/like/
<RobOakes> It's served me well.
<RobOakes> Right, so I just fixed the formatting errors in changelog, hopefully that will fix it ...
<RobOakes> Do I also need to import the .dsc file? (I'm not sure how to nest a branch to the root of the src tree.)
<RobOakes> (And I know virtually nothing about packaging.)
<RobOakes> Hmm. I think that may have fixed it.  Thanks for pointing out the problem :)
<RobOakes> Yay! Now I have an entirely new set of errors, patches aren't applying. I'm probably going to need to talk to the debian package maintainers. Thanks for your help.
<stub> Who maintains the beta PPA? The pipeline package seems to needs to be updated to cope with bzr 2.4
<maxb> We (mostly I) do
<stub> maxb: Should I file a bug report on Launchpad?
<stub> ** Unable to load plugin 'pipeline'. It requested API version (2, 3, 0) of module <module 'bzrlib' from '/usr/lib/python2.7/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 4, 0), and the maximum is (2, 4, 0)
<maxb> You're welcome to file the bug, but in practice it's more useful to file in debbugs
<maxb> Or, just trust I'll remember to fix :-)
<jelmer> w00t, we're past r6000 :)
<fullermd> That's not nearly as important as being past RS/6000   :p
<threeve> Is the pager plugin still alive (doesn't look it), or is there something similar that will automatically run output through $PAGER or similar?
<jelmer> threeve: The pager plugin is the only option I'm aware of; IIUC it should still work
<threeve> jelmer: thanks...  any idea how I get it?  The home page appears to be dead: http://bzr.oxygene.sk/bzr-plugins/pager/
<jelmer> threeve, https://launchpad.net/bzr-pager
<threeve> at least, that's the one linked from the wiki plugins page
<threeve> ah, thanks
<LeoNerd> bzr tags --help   mentions the  --sort=ARG  option, but I don't see a list of allowed values anywhere.
<LeoNerd> I want to view the tag of the most recent version
<jelmer> LeoNerd, there's an open bug about that
<LeoNerd> Ah OK. :) in the meantime then can anyone tell me a useful value? :)
<jelmer> LeoNerd: IIRC the values are natural, alpha and time
<LeoNerd> Ahhh... alpha and time look useful to me; the nature of my tags means they're the same. Thanks
<LeoNerd> natural I'm guessing is the default, because it puts the wrong one at the end..
<LeoNerd> Well, wrong in my use-case
#bzr 2011-06-29
<ipsy> hi :)
<ipsy> full chan great!
<ipsy> anybodye alive ?
<ipsy> pls
<ipsy> i need osme help
<bob2> need to ask a question first!
<ipsy> yes :)
<ipsy> ok
<ipsy> thanks for replay
<ipsy> i just instaled this Bazaar ap
<ipsy> i want to make bootabile usb stick
<ipsy> i got nix iso
<ipsy> i want to copy it somehow on usb stick to be bootabil
<ipsy> can i do it with bazaar ?
<bob2> bzr's a distributed revision control system
<ipsy> what
<ipsy> so im not on right place ?
<bob2> what do you think bzr is?
<ipsy> ar u bot ?
<ipsy> !cc la
<lifeless> bob2 is trying to help you
<ipsy> hmm
<ipsy> thanks all
<ipsy> sorry for troubles
<lifeless> you might try answering his question
<Riddell> how can I convince someone to review my gpg bits again?  I'd like to get it in before the beta next week  https://code.launchpad.net/~jr/bzr/bzr-gpgme/+merge/64859
<jelmer> Riddell, maybe we should go over it with a few people this afternoon
<jelmer> Riddell: I have some concerns with the bigger picture of it, and that's held me back from reviewing
<thumper> hi
<thumper> when did bzrlib.tests move?
<thumper> I was using TestCaseWithTransport
<thumper> and now it isn't in bzrlib.tests
<thumper> :(
<thumper> new package doesn't seem to have it
<thumper> WTF?
<jelmer> thumper, do you have python-bzrlib.tests installed?
<thumper> no
<thumper> just noticed
<thumper> jelmer: when did that turn up?
<thumper> jelmer: oneiric?
<jelmer> thumper: it's a separate package now as half of our code was actually in the tests, and the main package is arch-specific, the tests aren't
<jelmer> thumper: we changed it in natty IIRC
<thumper> jelmer: how to I write the depends in my debian file now?
<thumper> jelmer: my natty vm worked
<jelmer> thumper: if you're running the tests in your debian/rules file you should add python-bzrlib.tests to your Build-Depends
<thumper> so I'm guessing it is oneiric
<thumper> jelmer: but I want it to handle < oneiric
<jelmer> thumper: add something like this:
<jelmer> python-bzrlib.tests | bzr (<< 2.4.0~beta1-2)
<thumper> jelmer: branches pushed and recipe builds pending
<jelmer> thumper, \o/
<thumper> broken...
 * thumper enfixorates
 * thumper will find jelmer later
<Red15> having issues uploading 2.3.3 branch to a 2.1.x host, the host location is using a shared repository
<Red15> i just upgraded the host to 2.3.3 as well but still no-go
<Red15> http://paste.ubuntu.com/635034/
<jelmer> hi Red15
<jelmer> Red15: I'm not sure what the issue is - can you file a bug about it?
<Red15> jelmer, not sure what to report
<Red15> 've been using it plenty of times before i'm not sure what has changed to reproduce this error
<jelmer> Red15, the backtrace you just pasted
<jelmer> Red15, and that information on what the symptoms are (that it worked fine before, earlier)
<maxb> Isn't the info that matters going to be on the server, possibly in its .bzr.log ?
<Red15> the only issue i can think of is that i'm uploading quite large sql dumps
<Red15> around 120mb of sql data and a few commits of them (daily commits)
<Red15> argh... and now the commit didnt fail ...
<Red15> maxb, this is server side I think : http://paste.ubuntu.com/635054/
<Red15> strangly though, now the push worked (i removed the placeholder directory on the server) it is saying that it cannot update the working-tree on the server but there is no working-tree as I had specified 'bzr init-repo --no-trees'
<Red15> all is well now though, so bzr came through with it's "just works" philosophy :)
<jelmer> still strange though :-/
<Red15> yes, unfortunatly dont have the time to dig deeper into it
<poolie> jam, could you rereview https://code.launchpad.net/~mbp/bzr/regexps/+merge/64500
<Noldorin> hello. can anyone recommend a good free/open-source Continuous Integration system that works with Bazaar?
<wrtpeeps> Noldorin, no. write your own. :P
<luks> bazaar itself uses jenkins
<Noldorin> wrtpeeps, need a server too ;-)
<Noldorin> luks, ah, looks pretty nice. has a bzr and msbuild plugin, which is all (i think) i need
<Noldorin> ooh and an mstest plugin too
<Noldorin> thanks.
#bzr 2011-06-30
<Noldorin> do bzr branches maintain soft links?
<jelmer> Noldorin, bzr can version sym links
<Noldorin> jelmer, symbolic links = soft links no?
<jelmer> Noldorin, yes
<Noldorin> ok
<Noldorin> cool
<Noldorin> jelmer, btw how is bzr-svn these days? does it work with codeplex servers yet?
<Noldorin> or bzr-tfs even
<jelmer> Noldorin, bzr-svn doesn't work with codeplex servers; codeplex servers aren't real svn servers, and they provide inconsistent data
<Noldorin> so it seems yeah
<Noldorin> jelmer, how about tfS?
<jelmer> Noldorin, it seems unlikely bzr-svn will ever work with codeplex servers until the server side is fixed
<Noldorin> they probably hacked SVN to work with TFS over there
<Noldorin> so maybe never :-(
<jelmer> bzr-tfs would be a better candidate, but I haven't seen much movement on it recently
<Noldorin> yeah, nor have i it seems
<Noldorin> oh well
<Noldorin> cheers for the update.
<jelmer> sorry I can't give you better news
<jelmer> it'd be interesting to see a bzr-tfs happen
<Noldorin_> jelmer, no worries. yeah, i check bzr-tfs regularly and will probably continue. nothing exciting there yet though
<BlindWolf8> Hey spiv
<bignose> I need to âcherry-pickâ the removal of a specific change a while ago on a branch.
<bignose> (temporarily, to demonstrate a failure for a regression test)
<lifeless> merge . -r x..x-1
<bignose> would that involve some funky â--revisionâ spec?
<bignose> ah yes
<bignose> hmm. the revision I'm interested in targeting is from a merge.
<bignose> can I say â1658.1.1575..before:1658.1.1575â?
<bignose> would that be equivalent?
<lifeless> bignose: it will take the left hand side of that
<lifeless> but yes, should do what you want
<Lo-lan-do> Hi all :-)
<Lo-lan-do> I'd like to gently poke jelmer (or anyone) about #628973â¦
<jelmer> bug 628973 ?
<ubot5> Launchpad bug 628973 in Nikki and the Robots "FEATURE: move camera in terminal OEM" [High,Fix released] https://launchpad.net/bugs/628973
<Lo-lan-do> Nah, the other 628973, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628973
<ubot5> Debian bug 628973 in bzr-svn "bzr-svn uninstallable in unstable" [Grave,Open]
<jelmer> :)
<jelmer> Lo-lan-do, there is a weird bug in subvertpy/libapr that's preventing uploads of bzr-svn at the moment
<jelmer> launchpad bug 803353
<ubot5> Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353
<Lo-lan-do> Ah.  Okay.  I'll mark the packages as on hold in my aptitude, then.
<Lo-lan-do> Thanks for the info.
 * jelmer comments o nthe debian bug
<maxb> jelmer: Oh, also, bzr-pipeline needs an update too, though there's no bug about that. I was thinking of doing a snapshot merge into the alioth branch and asking you to sponsor, if that's ok?
<jelmer> maxb: sure, happy to
<maxb> Just checking I wasn't going to duplicate work :-)
<maxb> Ok, I'll have something pushed by tomorrow
<jelmer> maxb: thanks for checking. I should probably do that more too
<jelmer> I think we should get the commit email notifications back up for alioth
<__yhvh__> hey so is there a way to revert files modified like (properties changed: -x to +x) ?
<__yhvh__> I even tried feeding the list through xargs chmod but not happening
<jelmer> __yhvh__, revert should also revert property changes
<__yhvh__> yeah I imagine it should but it doesn't seem to work, the files end with * is that significant?
<__yhvh__> to be clear the list of modified files all get appended *
<jelmer> __yhvh__, that * indicates they have changed properties
<__yhvh__> yeah I really don't know what's happening here, bzr revert lists all the files with changed permissions, does the resolution passes, no effect
<__yhvh__> it did revert an actual edit I made
<jelmer> __yhvh__: what platform are you on? Does "bzr st" still list the reverted files as modified?
<__yhvh__> fedora 15, and yes it does
<__yhvh__> bzr 2.3.3
<jelmer> are you specifying any arguments to revert?
<__yhvh__> no
<jelmer> __yhvh__: that definitely sounds like a bug (but a quite unusual one)
<__yhvh__> might just be me being dumb, chmod -x file fails silently
<jelmer> oh, interesting - is this on a vfat fs perhaps?
<poolie> hi all
<jelmer> 'morning poolie
<__yhvh__> fuseblk
<jelmer> __yhvh__, it sounds like a file system bug if it's silently ignoring requests to change the mode; it should set some sort of error (ENOSYS?)
<__yhvh__> jelmer: yup touched a new file and it's created a+x
<__yhvh__> sorry for noise and thanks
<poolie> hi all
<brad_> does bazaar have anything like hg update null?
<LeoNerd> Maybe? But since most of us in here probably don't use hg we're unlikely to know what that is. Could you describe it generally?
<brad_> it basically is a state of the working directory that precedes the first revision, so the working directory has no files checked out
<LeoNerd> Oh.. Hmm..
<LeoNerd> Well, you can blow away the checkout, and leave only the branch. Is that what you're after/
<brad_> sort of
<brad_> but I want an easy way to get it to the state from any other state
<brad_> so in mercurial, it is just hg update null
<LeoNerd> I believe it's  bzr zap
<LeoNerd> To remove the checkout
<brad_> let me try that
<fullermd> remove-tree
<brad_> that worked
<brad_> remove-tree
<brad_> what do I do to get the tree back, since update doesn't seem to be working
<LeoNerd> bzr checkout
<fullermd> checkout
<brad_> thanks
<brad_> I see the help mentions that
<brad_> my bad
<brad_> very nice
<brad_> ok, that seems to be essentially what I was looking for
<brad_> does bzr have plugins out of the box for doing a clone of a subversion repository?
<maxb> Most definitely
<LeoNerd> Depends what "box" you mean :)
<brad_> hehehe
<brad_> well, from the official release on the website
<LeoNerd> There's bzr-svn which is available in Debian/Ubuntu/.. probably others.. I don't think it's corecore though...
<brad_> mercurial at least has a convert plugin included that does a convert, but it isn't exactly a clone
<LeoNerd> bzr-svn lets you branch from svn, or just use the bzr tool as an svn client; so your workdir can either be a bzr branch/checkout or svn
<LeoNerd> Depends what you're wanting
<brad_> yeah, I want to clone it, and be able to pull down changes, push changes back up
<brad_> basically, have bzr act like a svn client
<brad_> I was able to do that in mercurial with hgsubversion
<brad_> but it seems a bit buggy
<brad_> so trying to find the version control I feel most comfortable with, and which one makes the process as effortless as possible to setup.
<LeoNerd> So, your question still seems a bit mixed. These are two different use-cases...
<LeoNerd> 1. Branching a native bzr branch off a svn repo, working on it natively in bzr, then pushing it back. 2. Using the bzr commandline tool as a client for your svn checkout workdir.
<brad_> well, 1 I think it what I want primarily
<brad_> I don't need bzr to work from an svn checkout
<LeoNerd> Ahrighty. Yes; that's the common use-case.. but I just wanted to clear up the question to be sure :)
<brad_> I just want to be sure that I can pull down changes from svn as other people commit stuff, and be sure that I could push stuff back to svn if I have something I'd want/need to commit
<brad_> so I just need the bzr-svn plugin?
<LeoNerd> Should do, yup
<LeoNerd> Admittedly a year since I last used it, but that's how it worked when I did
<LeoNerd> maxb: How is that going, by the way? Are your bzr-related evangelisms getting anywhere?
<maxb> Hah, at MX you mean?
<maxb> Mainly stalled on lack of a true need for a DVCS given current development practices
<poolie> hi maxb, lenerd
<poolie> *leonerd
<LeoNerd> Ahyes..
<thumper> poolie: if I use set_append_revisions_only(true) on a remote branch (i.e. LP) will it do the right thing?
<poolie> it should
<thumper> cool
<Red15> How does one remove all traces of a branch inside a shared repo ?
<Red15> i'm having difficulty (those who were here yesterday might recall)
<Red15> commiting, because the commit is quite large and bzr is souping up all the memory available in the server
<Red15> finally the kernel kicks in and kills the process
<jelmer> Red15, the easiest way is to create a new repository and clone all branches you do not want to remove into that
<Red15> ouch ...
<Red15> sounds like quite the hassle
<Red15> do shared-repositories complain when you move then around or do they not care for their parent directory ?
<briandealwis> Red15: as I understand it, shared repos are self contained â it's the branches that are contained under the repo that are position sensitive.  So as long as you move the shared repo further up (towards the root), you'll be ok â providing there isn't a shared repo there already
<Red15> ok, that's what i figured thanks for confirming briandealwis
<Red15> am noticing shared-repos are quite bad for bzr memory usage
<briandealwis> Red15: how so?  A standalone branch has a repo too â it's just not shared (bar lightweight checkouts)
<Red15> i was maintaining a big-shared-repo for our company
<Red15> but the hosted server has ~1gb of ram
<Red15> the total dirsize of the shared repo is ~1gb
<Red15> when committing the bzr smart server process uses all the memory in the server causing kernel-oom-measures to fire
<briandealwis> Red15: I wonder if you're hitting a repacking threshold.
<Red15> briandealwis, how can i tell?
<briandealwis> I've just hit one myself with one branch, and it's painful
<briandealwis> Red15: look at the logs
<Red15> this was on server side : http://paste.ubuntu.com/635054/
<briandealwis> You'll need to look before that.  Mine has sometime like "648.407  Auto-packing repository GCRepositoryPackCollection(CHKInventoryReposito
<briandealwis> ry('file:///Users/bsd/Manumitting/Projects/e4/.bzr/repository/')), which has 28
<briandealwis> pack files, containing 28102 revisions. Packing 21 files into 1 affecting 21102"
<briandealwis> Red15: but it sounds like you could really benefit from adding some more RAM to your server
<Red15> this one is today : http://paste.ubuntu.com/635806/
<briandealwis> But that didn't fail, right?
<Red15> actually nvm that one
<Red15> http://paste.ubuntu.com/635807/ that one failed
<briandealwis> Red15: that one is definitely repacking.  I wonder if there's a way to avoid repacking â it's an optimization, not a requirement, as I understand it.
<Red15> https://bugs.launchpad.net/bzr/+bug/184237
<ubot5> Ubuntu bug 184237 in Bazaar "autopacking should be optional" [Undecided,Invalid]
<Red15> or this one : https://bugs.launchpad.net/bzr/+bug/736001
<ubot5> Ubuntu bug 736001 in Bazaar "Re-packing happens at inconvenient times and blocks further operations" [Medium,Confirmed]
<briandealwis> Red15: I've installed John's bzr-prompt-repack plugin; you could adapt it for your server to always skip repacks on your server, and schedule a repack for the evenings (once you've added more memory)
<Red15> for now i've decided to not use shared repo's anymore and i think that should steer clear of the problem for now
<mgz> ah, jml just proposed his bug 660852 branch
<ubot5> Launchpad bug 660852 in testtools "text failure report is too gassy" [Wishlist,In progress] https://launchpad.net/bugs/660852
<jml> yes what?
<jml> mgz: please play with it. Am interested in feedback.
<jml> (also, interested in better ways to code it)
<mgz> I saw a few nits looking at an earlier iteration, will review and see if there's anything still needing sorting if you like
<mgz> the general plan looked good.
<mgz> okay, so, you have u"" literals in tests, python 3 gets sad at them.
<jml> mgz: oops. sorry.
 * jml really needs to tweak 'make check' to run with all local Pythons
<mgz> also, using doctestmatches with unicode is asking for pain.
<jml> yeah, there's a bug about that isn't there
<mgz> there's a bug against testtools I've got a branch for, but also,
<mgz> doctest screws us majorly on that front
<mgz> because inside an innocently named `_indent` function, they encode to whatever the sys.stdout encoding is
<jml> mgz: ok. I'll stick with Equals.
<mgz> which... clearly is no good for testtools/subunit passing things cross process
<jml> mgz: once this patch is ok, I want to resurrect your tb stack frame patch
<jml> but I guess a bunch of other bugs ought to get fixed first.
<mgz> yup, we need to find a near(ish) way of doing that.
<mgz> *neat
<jml> mgz: as far as I'm concerned, we can use __unittest and make sure that testtools' own runner re-sets __unittest to False.
<mgz> sticking __unittest = True at the top of all modules is ugly, but adding our own _is_relevant_tb_level would work too
<mgz> the changes to _details_to_str look sensible to me.
<mgz> I wonder if it shouldn't become a public api, or some part of it. bzrlib doesn't want to stay doing str(_StringException) forever and needs to have some means to show the test information during the run.
<jml> mgz: hmm. interesting thought re details_to_str becoming public.
<jml> mgz: I've pushed up changes to make tests pass with Python 3
<mgz> that all looks good. removing the underscore can probably wait till I find whether I need to delve into privates for bzr.
<jml> mgz: poolie was just trying my branch w/ bzr. The traceback still comes up in curly braces. I'm not sure why that's the case.
<jml> (I don't really know much about bzrlib.tests any more0
<mgz> yeah, that's the traceback-1 stuff probably
<poolie> jml, i put an example failure on the bug
<mgz> remember spiv hacking around a test duplication issue where each test grew a new traceback every time an instance of it failed?
<poolie> o/ mgz
<jml> mgz: ? it says 'traceback', not 'traceback-1'
<mgz> hm. wrong guess then.
<spiv> mgz: yeah, I'm pretty sure I fixed that issue
<mgz> jml: _details_to_exc_info needs changing to mkae bzrlib work
<jml> mgz: ah, I see.
<jml> mgz: I have to say,  I don't really understand what the purpose of the code path is, why things would go down it
<mgz> I'm a little worried about 'reason' vs 'traceback' too, I don't quite see where that'll be handled
<mgz> as in, skip vs error
<jml>             except TypeError:
<jml>                 # have to convert
<mgz> ^it's confusing, basically, it's the compat with the unittest api
<mgz> which deals in exc_info not details dicts
<jml> so it catches the decorated thing not understanding the details kwarg?
<mgz> yup.
<jml> and what about this bit:
<jml>                 # extract the reason if it's available
<jml>                 try:
<jml>                     reason = ''.join(details['reason'].iter_text())
<jml>                 except KeyError:
<jml>                     reason = _details_to_str(details)
<jml> I mean, I don't see how that squares with your reason vs traceback worries.
<mgz> ah, that's me answering my own question
<jml> :)
<mgz> hey, spiv and poolie were both awake... aus has migrated to the northern hemisphere?
<jml> mgz: Canonical hack-a-thon in Dublin.
<mgz> aha.
<poolie> thanks for looking at the subunit unicode bug
<jamdahl> Hi, I'm having a problem with directories when using bzr through the command line
<jamdahl> I run the command \
<jamdahl> bzr init "C:\Users\jamdahl\Documents\New folder (2)\"
<jamdahl> and it says the directory does not exist
<mgz> jamdahl: what does `mkdir "C:\Users\jamdahl\Documents\New folder (2)\"` say?
<jamdahl> it says it already exits
<jamdahl> Ah, I found the problem, it's the \ at the end
<mgz> okay, then try removing th...
<mgz> you got there first :)
<mgz> file a bug.
<mgz> your command line was wrong, and bzr does tell you how, but could be clearer
<jml> mgz: can you please take a look at https://code.launchpad.net/~jml/testtools/doctest-unicode-safety-672056/+merge/66500
<mgz> jml: that's not enough unfortunately.
<jml> mgz: oh?
<MadGirl> well, oh is that all?
<mgz> is DocTestMatches designed to take arbitrary objects and stringify them though?
<jml> mgz: it does make the test pass :)
<mgz> jml: printing the output also gets messed up
<mgz> I need to leave in a sec but I'll see if I can throw my branch up somewhere for you to look at
<jml> mgz: ok, thanks.
<mgz> jml: see lp:~gz/testtools/unicode_doctestmatches_764170
<jml> mgz: thanks.
<mgz> there are... all kinds of annoying interactions here with different python versions
<jml> mgz: yeah.
<mgz> I'm not sure the bug you duped against was the same thing either, will look at when I get back.
<jml> mgz: I'm wondering whether it's acceptable to just mangle output
<jml> mgz: as the least of all evils.
<mgz> yeah, that sometimes happens currently, and it's better than breaking entirely (which that branch does currently on 2.6)
<mgz> okay, I'm gone.
<Noldorin_> jelmer, hello, you around?
<jelmer> Noldorin_, hey
<Noldorin_> jelmer, yesterday you told me bzr supports symlinks...does it support them on windows though?
<jelmer> Noldorin_, no, it doesn't support them on Windows (how would it?)
<Noldorin_> well Windows does have symlinks...
<Noldorin_> they just require admin rights to create :-S
<Noldorin_> jelmer, guess it still doesn't support them though
<jelmer> Noldorin_: yeah, bzr doesn't create them - we should probably just not be creating any files in disk but remembering the existing symlinks that are already in the tree
<Noldorin_> jelmer, yes that would probably be a good idea.
<Noldorin_> what's the easiest way to get the tag of a certain revision?
<LarstiQ> mgz: here by chance?
<LarstiQ> the behaviour on 803796 seems to be weird, or I'm doing something rather wrong
<mgz> LarstiQ: it is weird, but with the latest bzr you should get a neat error message rather than a traceback, if you could confirm that
<LarstiQ> mgz: "Tree is up to date at revision 0 of branch /tmp/bzr"
<mgz> hm, that's not as useful as I thought it'd be.
<LarstiQ> mgz: I filed bug 804037 about the weirdness I ran into
<ubot5> Launchpad bug 804037 in Bazaar "bzr branch -r 0 downloads more than expected" [Medium,Confirmed] https://launchpad.net/bugs/804037
 * LarstiQ didn't dig very deep 
<LarstiQ> so could be wildly off, but I'm suspecting a null: vs None conversion problem
<mgz> blast, riddell's branch isn't linked from bug 242175
<ubot5> Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175
<mgz> https://code.launchpad.net/~jr/bzr/242175-empty-branch-merge/+merge/61152
<mgz> okay, so somehow we're not hitting that error message codepath, but also not getting the old traceback
<mgz> or do you get it when you run `bzr update` in your -r 0 branch?
<LarstiQ> mgz: that message is `bzr update` in my -r0 branch
 * LarstiQ doesn't get a traceback
<mgz> okay, so that part is okay then, it's just the transfer that I agree is suprising.
<Noldorin_> how cna i find out which revisions in a branch have tags and what they are?
<mgz> `bzr tags`?
<Noldorin_> mgz, oh dear, how did i miss that! thank you
<timrc> I'm getting http://pastebin.ubuntu.com/636053/ when I create (bzr init) a new tree and then push it to an existing project... any idea how I can rectify this?  Appears to be some sort of compatibility issue...
<jelmer> timrc, your branch is in a bzr format with more capabilities than the format the default development branch is in
<timrc> jelmer, it throws an exception in Python, but is it actually problematic?
<jelmer> timrc: the development branch appears to be in an old format, so you might want to upgrade it to the current format unless it needs to be accessible by hardy bzr
<jelmer> timrc: IIRC it doesn't actually push any data if it gives this error
<timrc> jelmer, thanks for the assistance :)
#bzr 2011-07-01
<milleja46> hi
<milleja46> ok...so i've created a project on launchpad and i need to know how to post my code on there using bzr...is there a guide to do it anywhere?
<lifeless> milleja46: bzr push lp:~youruserid/yourprojectname/branchname
<milleja46> lifeless: will that work since it's just the initial code for the project?
<milleja46> apparently not..... i did "bzr push lp:~milleja46/m46sgoffice/trunk" and it reported "bzr: ERROR: Not a branch: "C:/Python27/projects/M46 Office Suite/"."
<milleja46> is there a reason for that? i sholdn't have gotten that error if this is the first code for the project...
<milleja46> well...i'll be back in the morning...gotta go to bed before i fall asleep at the computer...
<alkisg> Um, if I did `bzr revert file`, is there any way to undo that action?
<alkisg> (I typed the wrong filename there :-/)
<alkisg> The man page mentions that revert backs up the file, is there a command to restore the backup, or I do it manually?
<Peng> alkisg: Just do it manually. ls -ltr file*
 * alkisg did it manually - thank you
<vila> poolie: I'm happy to make you a happy child ;-p http://www.happychild.org.uk/islands/O.htm
<jelmer> haha
<vila> jelmer: of course he missed the joke which is waiting for his laptop to be opened again ;)
<jml> mgz: I'm giving up on those issues for now. Have tagged them all with 'unicode' in case it makes sense to fix them in a cluster. https://bugs.launchpad.net/testtools/+bugs?field.tag=unicode
<milleja46> ok...i created a project last night on launchpad...but my question is...how do i upload my current code i have on my computer to at least have that basis there?
<maxb> You probably want to read some of the introductory Bazaar documentation
<milleja46> maxb: well i thought i would just do lp~milleja46/m46sgoffice/trunk but doesn't seem to work...
<maxb> You're missing a colon
<maxb> lp:......
<milleja46> i forgot it on that when posting on here...i actually put it when i did the push command
<maxb> Then you need to explain "doesn't work"
<milleja46> it reports "bzr: ERROR: Not a branch: "C:/Python27/projects/M46 Office Suite/"."
<milleja46> ^that's what i mean by doesn't work
<jamdahl> Hey, is there a way I can configure bazaar to automatically add files in a directory rather than doing so manually?
<jelmer> jamdahl: you can run "bzr add" (without arguments) to add all unknown files
<jamdahl> Thanks jelmer, is there a set of arguments for add to add all files in subfolders but not in main directory?
<jelmer> jamdahl: "bzr add" works recursively, so it should work if you specify the subfolders
<jamdahl> Is there a way to do that without specifying?
<jamdahl> In my particular case, I know there is going to be some junk in the main folder I don't want versioned but stuff added to folders that I always want versioned
<milleja46> can anyone answer my question? i have a new project on launchpad but i need to know how to seend my code i have so far to it...how do i do that? the command it tells me on the page doesn't work...reports it's not a branch
<jelmer> jamdahl: you should be able to add the junk to .bzrignore and then run "bzr add" - it should ignore things that are in .bzrignore
<jelmer> milleja46: can you be more specific, what command does it tell you to run?
<milleja46> bzr push lp:~milleja46/m46sgoffice/trunk <-but it reports that where i'm pushing from isn't a branch...i don't think it should because i need to put my latest code on there right now...
<jelmer> milleja46, what's the exact error that command gives you?
<milleja46> "bzr: ERROR: Not a branch: "C:/Python27/projects/M46 Office Suite/".
<jelmer> milleja46, you don't have a branch locally, so it has nothing to push
<jelmer> milleja46, you should be able to create one with "bzr init" and then add your files with "bzr add"  and "bzr commit"
<milleja46> i know...but i need to put the inital code on the project...
<jelmer> or see http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ for the tutorial
<jelmer> milleja46, you have to create a branch locally before you can push that branch to Launchpad
<milleja46> jelmer: ok...now that i've run through that...how do i convert it to a branch so that i can use it with launchpad?
<jelmer> milleja46, run the push command you tried earlier
<milleja46> i did that and now it reported "bzr: ERROR: Not a branch: "C:/Python27/projects/M46 Office Suite/m46sgofficesuite/.bzr/branch/": location is a repository."
<jelmer> milleja46: It seems like you just created a repository, not a branch; what commands did you run
<jelmer> ?
<milleja46> the ones to make it a repository but ti doesn't say ones for making my code the original code for the project
<jelmer> milleja46, you have to create a branch as well
<jelmer> (not just "bzr init-repo", but "bzr init" too)
<milleja46> how do i do that? i've forgotten how to do it...
<jelmer> milleja46: "bzr init" to create an empty branch (see http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ for background)
<jam> spiv: if you're around, poolie is looking for you
<spiv> jam: ok, I'll head to the lp room
<dchilton> I've noticed that the size of my local repo was getting huge; tracked it down to having ~ 50 packs in '.bzr/repository/packs'.  running 'bzr pack --delete-obsolete-packs' fixed the issue -- back down to reasonable size, with just one pack.  but as i continue to pull/add/etc, the packs are accumulating again.
<dchilton>   is this normal behavior?  shouldn't packs be getting auto-managed?  or do i need to keep manual exec of 'bzr pack' as part of my regular maint
<spiv> dchilton: they are auto-managed, and the obsolete pbacks will be gradually removed over time
<dchilton> spiv the oldest of those ~50 packs was around 4 months old ...  i had NO packs in /repository/obsolete-packs.
<dchilton> something not configured right on my end?
<dchilton> the total repository had swelled, because of those unmanaged packs, to around 35x the size of the actual managed files/dirs
<magmatt> When I install bzr on my mac, it installs bzrlib in the site-packages of an old install, not my current install
<magmatt> How can I tell the installer which python to use (because it's not using the one given by "which python")?
<dchilton> magmatt do you need/use anything in the 'site-packages of an old install'?  if not, what happens if you temporarily move that dir out of the way?
<magmatt> lemme try
<magmatt> dchilton: I moved it then installed from the dmg.  The installer recreated the directory :) http://paste.pocoo.org/show/425906/
<magmatt> And filled site-packages with bizarre things
<magmatt> *bazaar
<magmatt> is there a way to install from source?
<poolie> magmatt: to install bzr from source? or ptyhon?
<dchilton> magmatt: fwiw, i pull the bzr repo, then 'make', 'python setup.py install'.
<poolie> that should work
<dchilton> magmatt: ah, are you using a Mac package installer?
<magmatt> poolie: bzr
<magmatt> dchilton: yes
<poolie> dchilton: bzr should normally repack them
<dchilton> $5 sez it's presuming a target dir.  try the source install.
<poolie> unless you're running a very early 2.0 version maybe
<magmatt> dchilton: yes, I'm trying from source right now
<magmatt> poolie: 2.6.6
<poolie> Riddell: can you tag your gpg bugs so we can link them together to see the overall state of it?
<magmatt> actually, I'm trying easy_install first
<Riddell> I think I did
<magmatt> easy_install wins
<Riddell> poolie: they all have the tag "gpg"
<dchilton> poolie: that's what i figured.  apparently, in my case, it isn't.  i'm running '2.3.4dev'
<dchilton> magmatt: er, 2.6?
<magmatt> dchilton: python 2.6.6, bzr 2.4b4
<dchilton> ah
<magmatt> dchilton: thanks
<dchilton> worked?
<dchilton> poolie: fwiw, atm, every new commit seems to create an additional pack file.
<dchilton> what's being created seems small ... likely proportional to the size of the commit?
<maxb> dchilton: IIRC, it'll go 1 commit per pack, then when you hit 10 commits, those will be repacked into a single one. And then repeat that pattern.
<maxb> When you get to 10 * 10 commit packs, they get repacked into 1 100 commit pack
<maxb> etc.....
<dchilton> maxb: that sounds like a reasonable approach. at least for a default.  again, apparently not happening here.
<maxb> dchilton: So, I just ran a quick shell for loop to commit 1001 revisions to a repository, tracking the pack count - it's as I suggested
<maxb> You get up to 27 packs at r999 before you drop back to 1 at r1000
<maxb> ooh, that's pretty
<maxb> The expected number of packs if bzr is left to autopack automatically is the sum of the value of all the digits in the number of revisions :-)
<dchilton> maxb: unclear to me whether my case falls within those 'tortured' constraints. so can i override this?  basically, i'd like NOT to have a 35GB repo for 1GB of files being tracked ... solely due to unmanaged packs.  of course, i *can* add 'bzr pack' to my mgmt repertoire ... just useful to know if that's the only/best/recommended way to handle this.
<maxb> I don't understand why your repository is so big
<maxb> Repeated manual 'bzr pack' should never be necessary - in particular because it has to do I/O over the entire history of the repository each time.
<maxb> How much of your tree is changing in every commit?
<dchilton> maxb: well, it's cuz there are, well *were*, lots of really big packs ... each about the size of the files/dirs under mgmt
<dchilton> maxb a few files at a time.  not a whole bunch.
<poolie> dchilton: oh they're accumulating in obsolete packs?
<poolie> or they're in plain packs/
<poolie> hi maxb
<dchilton> poolie: nope. there is *nothing* in ../obsolete-packs. ever.
<dchilton> all just in ../packs
<poolie> hm
<poolie> that's strange
<poolie> is there anything unusual about your environment?
<dchilton> poolie: unusual --> probly that *I* am involved ...
<dchilton> other than that, not really
<maxb> I suppose if you commit a large amount of changed files in several successive commits, you might end up with a bloated repository until the next autopack kicks in
<dchilton> maxb: sure.   but, i don't think i've ever committed more than about 20 edits to text files at a time ...
<maxb> Quite mysterious
<dchilton> hm.  would '.bzrignore' interpret/parse these two entries differently?:  "./test/*" and "./test/"
<dchilton> maxb poolie so, until if/when i find a gremlin, is there any *harm* to occassionally/regularly running 'bzr pack --delete-obsolete-packs' ?
<maxb> You mean --clean-obsolete-packs?
<maxb> You've seen the warning in bzr pack --help, right?
<maxb> Other than that, the only harm is wasted time
<dchilton> maxb: yes, --clean...  yes, saw the warning.  re: wasted time ... a tradeoff: less than backing up bloated repos.
<dchilton> thx.
<dchilton> off for moar coffee ... ta!
<[1]reggie> bzr gurus -- how do I undo a push?
<spiv> [1]reggie: 'bzr push --overwrite -r OLDREV'
<[1]reggie> spiv, thx
<mgz> man I hate doctestmatches
<MarkAtwood> is there a "better way" to make a reverse patch than to do:
<MarkAtwood> bzr diff -r-1..-2 >..reverse.patch
<MarkAtwood> patch -p0 <../reverse.patch
<MarkAtwood> bzr commit -m "reverse previous commit"
<MarkAtwood> ?
#bzr 2011-07-02
<johnf> If I committed a 200MB file to a branch accidently a few revisions ago is there a plugin to help purge it from the repository yet. Or would I need to do a fast-export fast import? (This is a research questions I haven't actually done this. Well not recently anyway :) )
<niklas__> I want to change history such that that commit contains only some of its changes and after that that create a separate commit for the other patch
<niklas__> basically, I want git rebase -i :)
#bzr 2011-07-03
<BlindWolf8> Anyone up?
<cheater__> hi!
<cheater__> i have a problem, i was commiting a (new) file to my repository and lost the internet connection. now this happens:         bzr: ERROR: Cannot lock LockDir(sftp://bzr@aaa.dyndns.org/srv/bzr/aaa/.bzr/branch/lock): File exists: '/srv/bzr/aaa/.bzr/branch/lock': Failure: unable to mkdir
<cheater__> (when i try to commit)
<cheater__> what can i do now?
<cheater__> halp!
<cheater__> i've tried doing bzr break-lock to no avail
<LarstiQ> cheater__: hmm
<LarstiQ> cheater__: what url do you give to break-lock, and what does it say?
<cheater__> LarstiQ, that's all it says!
<LarstiQ> cheater__: this is what break-lock says?
<cheater__> break-lock says nothing
<LarstiQ> cheater__: what argument do you give to break-lock?
<cheater__> none
<cheater__> what should i be giving it?
<cheater__> oh btw, the lock file that commit mentions changes every time
<LarstiQ> cheater__: (it helps if you address me so I get a highlight and check this channel)
<LarstiQ> cheater__: try `bzr break-lock sftp://bzr@aaa.dyndns.org/srv/bzr/aaa/`, possibly with 'aaa' replaced by the relevant information
<cheater__> ok let me try
<cheater__> LarstiQ, no improvement
<LarstiQ> cheater__: same error?
<LarstiQ> or, same nothing?
<cheater__> same error
<cheater__> cannot LockDir
<cheater__> bzr: ERROR: Cannot lock LockDir(sftp://bzr@aaa.dyndns.org/srv/bzr/aaa/.bzr/branch/lock): File exists: '/srv/bzr/aaa/.bzr/branch/lock': Failure: unable to mkdir
<LarstiQ> cheater__: is /srv/bzr/aaa/.bzr/branch/lock a directory or a file?
<cheater__> just a sec
<cheater__> it's nothing.
 * LarstiQ blinks
<cheater__> it used to be a dir, but i was getting that error, so i moved it to lock-old
<cheater__> and the error persists
<LarstiQ> euh
<LarstiQ> that is at least somewhat weird
<LarstiQ> cheater__: does ~/.bzr.log have more info?
<cheater__> on the account i'm trying to commit from?
<LarstiQ> cheater__: yeah
<cheater__> just a sec
<cheater__> yeah
<cheater__> in fact i think it's a lock that's on client side
<cheater__> how does bzr do locking on the client side?
 * LarstiQ would need to read code for that
<cheater__> lockdir.py
<LarstiQ> among things :)
<cheater__> that's where the exception happens
<LarstiQ> cheater__: I believe there are some traces of os locking left
<LarstiQ> cheater__: do you have a full traceback?
<cheater__> http://pastebin.com/E3BREgAv
<cheater__> LarstiQ, ^
<LarstiQ> ah hm
 * LarstiQ looks at the code
<LarstiQ> cheater__: the code notices .bzr/branch/lock doesn't exist and tries to make it, and that then fails
<LarstiQ> not sure why
<LarstiQ> cheater__: if you are in a position to make a backup of /srv/bzr/aaa that might aid future debugging as to what is going on here
<cheater__> yeah i'm root on that server
<LarstiQ> cheater__: as to a workaround now, what happens if you create .bzr/branch/lock/ yourself?
<LarstiQ> cheater__: another idea is to use bzr+ssh:// instead of sftp://
<LarstiQ> cheater__: you said earlier you had a problem so you moved it out of the way
<LarstiQ> cheater__: hm
<cheater__> yeah i moved it on the server
<cheater__> but this error seems to be happening on the client
 * LarstiQ wonders if something funky is going on with the filesystem
<LarstiQ> cheater__: the client is reporting the error it gets from the transport
<LarstiQ> cheater__: but you could check if there is a /srv/bzr/aaa/.bzr/branch/lock on the client
<cheater__> no, /srv is empty.
<LarstiQ> right, so I remain convinced then that it is reporting about the serverside situation
 * LarstiQ goes through the release-notes in the meantime
<LarstiQ> cheater__: not the same bug, but https://bugs.launchpad.net/bzr/+bug/733350 got fixed in 2.3.2
<ubot5> Ubuntu bug 733350 in bzr (Ubuntu Natty) "LockContention error when pushing (with new tag) to a bound branch" [High,Fix committed]
<LarstiQ> cheater__: I need to run to the store before it closes
<cheater__> let me have a look
<cheater__> LarstiQ, thanks for your help. if you have time afterwards please give me a shout.
<LarstiQ> cheater__: yeah, I'll be back in 45 minutes or so
<cheater__> LarstiQ, cool!
<LarstiQ> cheater__: messed up timing with dinner a bit, before I go back, did you try making the lock directory and seeing how that changed things?
<cheater__> LarstiQ, actually no, let me try
<cheater__> actually the lock dir has been created automatically.
<cheater__> i tried committing again, and now it argued that a subdir of lock exists
<cheater__> bzr: ERROR: Cannot lock LockDir(sftp://bzr@aaa.dyndns.org/srv/bzr/aaa/.bzr/branch/lock): File exists: '/srv/bzr/aaa/.bzr/branch/lock/gacus7hzmf.tmp': Failure: unable to mkdir
<LarstiQ> cheater__: it sounds like something weird with either the filesystem or ssh is going on
<cheater__> i restarted ssh and it didn't help
<cheater__> oh wait!
<cheater__> it did!
<cheater__> but not really.
<cheater__> now, bzr forgot my name ??
<cheater__> i need to do whoami again on the client. wtf?
<cheater__> hah it's uploading
<cheater__> yay, restarting ssh did it
<cheater__> but why did bzr forget who i am?
<cheater__> that's just bizarre.
<LarstiQ> cheater__: *blink*
<LarstiQ> cheater__: did something happen to your bazaar config files?
<LarstiQ> strange indeed
<cheater__> nope!
<cheater__> the thing is i'm on a very faulty internet connection
<cheater__> like 30% packet loss
<cheater__> i've had to kill bzr a few times when trying to commit
<cheater__> maybe it was in a half-open state or something
<LarstiQ> ah hmm
<LarstiQ> cheater__: amything weird in ~/.bazaar ?
<LarstiQ> leftover locks maybe
<cheater__> let's see
<cheater__> nope ~/.bazaar/lock is empty
<cheater__> but of course it could have been non-empty before
<cheater__> in FACT
<cheater__> what i think might have happened is that i killed bzr by ctrl-c but somehow an ssh connection kept lingering
<cheater__> i've noticed runaway processes when i do ctrl-c on bzr: i'll do ctrl-c while it's logging in, and it will later keep spamming my tty with ssh authentication challenge dialogs
<cheater__> so i'm thinking maybe restarting openssh on the SERVER has taken that out
<cheater__> i think that's fairly clunky. i was actually fairly disappointed.
<LarstiQ> cheater__: that ssh repeating is an openssh thing
<LarstiQ> don't know about serverside lingering processes
<cheater_> LarstiQ, i think the process was lingering CLIENT-side
<cheater_> except when the server quit, so has the client process
#bzr 2012-06-25
 * jelmer waves
<gour> do you believe bzr-git will get push support or is better to lean (some) git when needs arises to contribute to git-based project?
<gour> *learn
<jelmer> gour: it depends on whether somebody will work on push support
<jelmer> gour: that's a hard question to answer for a FOSS project
<gour> jelmer: well, if you yourself is using git when you need it, probably not many people within bzr community are into it ;)
<SteveA> I'm trying to use bzr-svn on ubuntu oneric to connect to a svn server that uses https
<SteveA> the problem is, gnutls doesn't like the certificate the server uses
<SteveA> how do I fix this at my end?
<jelmer> hi SteveA
<jelmer> SteveA: On oneiric, you might be able to specify "svn+https" rather than "https" as the scheme to work around it
<jelmer> bzr-svn *should* also pick up the certificate settings from SVN itself
<jam> james_w: thanks for letting us know about the storm pushback
<james_w> np
<jelmer> so if you run "svn ls" on that URL, it will ask you if you want to trust that certificate
<jelmer> gour: I'm not seeing myself put a lot of effort into push support for bzr-git in the near future
<jelmer> gour: I'm still using bzr-git myself, though I use git sometimes too
<SteveA> jelmer: thanks, that worked... now I just need to figure out how to add authentication (goes to read docs...)
<gour> jelmer: ok. thanks. we might try to learn (some) git as well
<ubot5> Announcement from my owner (jussi): #ubuntu-discuss can-voices
<KombuchaKip> Where is bzr glog fetching the author avatar images from?
<jelmer> KombuchaKip: it uses gravatar
<KombuchaKip> jelmer: Interesting...
<bob2> hah
#bzr 2012-06-26
<jelmer> moin
<jazon> hello everybody I have a problem with my bzr server when I do a push on command line it say me 'not a branch', when I try with bzr explorer it say me 'This transport does not update the working tree'
<jelmer> jazon: is the location you're pushing from aqctually a branch?
<jazon> Yes
<jelmer> jazon: what does "bzr info" say about it?
<jazon> jelmer http://pastebin.com/4RuAA94X
<jazon> can you help me?
<jelmer> jazon: I mean, what does "bzr info" say about your local branch?
<jazon> I wasn't in good directory...
<jazon> http://pastebin.com/fVr1VAyK
<jelmer> jazon: so 'bzr push' works now?
<jazon> no, it's say me look at bzr help working-trees
<jazon> I don't understand what is the matter
<jelmer> jazon: if you push to a remote location, bzr will only update the remote branch
<jelmer> not the remote working tree
<jelmer> for that, you need to run 'bzr up' on the remote server
<jazon> I have to be connected permanently on my server with ssh?
<jelmer> jazon: no, you just have to run 'bzr up' after you push to the branch
<jelmer> jazon: (if you care about the working tree on the server side)
<jazon> I have to run bzr up on the server no?
<abentley> jelmer: thanks for your comment on my merge proposal.  Did you mean to vote "approve"?
<jelmer> jazon: if you want to have the working tree up to date, yes
<jelmer> abentley: Euhm, yes.. one sec
<jelmer> abentley: done
<abentley> jelmer: thanks.
<Qaghan> Guys, for some reason I cannot commit this project to Launchpad, even though I got my ssh set up and everything. I keep getting the bzr: ERROR: Cannot lock LockDir() error
<mgrandi> hello
<jelmer> hi mgrandi
<mgrandi> do you happen to have gpg installed without an agent?
<jelmer> mgrandi: I didn't hit this particular issue but some other people did
<mgrandi> yeah
<mgrandi> well i meant
<mgrandi> i'm writing up a response now, but from reading the gpg man page, it seems that $GPG_AGENT_INFO will be defined if you have an agent
<jelmer> mgrandi: mgz was able to reproduce it, apparently withtout a gpg agent
<mgrandi> and i'm trying to make sure thats the case
<mgrandi> cause then we can just check to see if that variable is define, and do the right thing from there
<mgrandi> i have no idea what happens on windows
<jelmer> mgrandi: I'm wondering if we should be specifying this option at all - shouldn't gpg already try to do this by itself?
<mgrandi> thats what i think
<mgrandi> but the whole issue was that while bzr explorer, that gpg would be printing stuff out to a tty
<mgrandi> gpg: cannot open `/dev/tty': No such device or address
<mgrandi>  bzr: ERROR: Failed to GPG sign data with command "['gpg', '--clearsign']"
<mgrandi> caused that ^
<jelmer> mgrandi: without a gpg agent?
<mgrandi> that was with an agent
<jelmer> mgrandi: why would it need a tty if you have an agent?
<mgrandi> good question. gpg says on the --no-tty option: "Make sure that the TTY (terminal) is never used for any output. This option is needed in some cases because GnuPG sometimes prints warnings to the TTY even if --batch is used."
<mgrandi> and --quiet means "try and be as quiet as possible"
<mgrandi> i dont know what happens if you tried to use bzr explorer to sign without an agent
<jelmer> mgrandi: it's not wrong to use the TTY
<mgrandi> yes, but on linux it was saying that it can't find /dev/tty
<mgrandi> which makes me think that it doesn't "have" a tty to print out to
<mgrandi> cause its a pyqt4 app
<jelmer> mgrandi: was that bit fatal though?
<mgrandi> it caused signing to fail
<mgrandi> the code just says "failed to gpg sign" if gpg doesn't return 0
<jelmer> mgrandi: but it tries to use the gpg agent first
<mgrandi> i know
<mgrandi> i just tried on my mac, if you enter the wrong password, it prints "gpg: Invalid passphrase; please try again ..."
<mgrandi> to the terminal
<jelmer> rigfht, it falls back to the tty if using the gpg agent doesn't work
<mgrandi> im not exactly sure whats going on with the original bug report, since it worked on windows and mac fine
<mgrandi> with just 'gpg --clearsign'
<mgrandi> but then on linux, somehow running bzr explorer meant it didn't have a tty?
<mgrandi> should it have one?
<jelmer> mgrandi: I think we should revert the use of --no-tty for now, as it causes a serious regression
<jelmer> mgrandi: right, bzr explorer usually wouldn't have a tty
<mgrandi> hmm.
<mgrandi> thats why i was thinking of just checking to see if we have an agent
<mgrandi> cause --no-tty works fine if you have an agent, but if you dont, you need the terminal to enter your passphrase
<jelmer> mgrandi: that means there won't be any fallback to the terminal if the gpg agent doesn't work
<jelmer> mgrandi: I'm worrying we're trying to do gpg's job for it
<jelmer> this sort of logic really belongs in gpg, not bzr
<mgrandi> yeah. so if we don't want to use --no-tty, then how do we solve the original problem , with signing failing cause of no /dev/tty
<mgrandi> you say you want to use terminal as a fallback, but then if we are using bzr explorer, then there is no terminal (in most cases) to fall back to
<mgrandi> err, 1/3 cases
<jelmer> mgrandi: I think that might warrant some more investigation, but this is a serious regression.. let's at least fix that bit
<mgrandi> yeah
<mgrandi> go for it
<mgrandi> or do i have to do something
<jelmer> mgrandi: no, that's okay
<mgrandi> it seems that all of this is just sprouting from the fact that we are using gpg as a separate program rather then a nice api we can bind to, but don't think there is any way around that
<jelmer> mgrandi: it would be interesting to use pygmge to do the actual signing
<jelmer> but that's a significantly larger change
<mgrandi> yeah
<mgrandi> but we might have to cause we are juggling where bzr is being run as
<mgrandi> command line, bzr explorer started from terminal, bzr explorer without a terminal,
<mgrandi> and isn't that the thing that is required to check signatures?
<jelmer> mgrandi: how do you mean?
<mgrandi> if you try and run bzr verify signatures without it installed you get this: bzr: ERROR: python-gpgme is not installed, it is needed to verify signatures
<jelmer> mgrandi: ah, yes, it is
<mgrandi> looking at 'gpgme', the gpg folks say that applications should use that, so that seems like that would be the better solution
<jelmer> mgrandi: perhaps the best thing to do is to revert this fix, and just consider moving gpgme for signing a proper fix for bug 847388
<ubot5> Launchpad bug 847388 in bzr (Ubuntu Precise) ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,Fix released] https://launchpad.net/bugs/847388
<mgrandi> yeah
<mgrandi> i say revert it, the bzr explorer bug can be worked around by just using the terminal to commit
#bzr 2012-06-27
<jml> hello
<jml> just wondering, bzr has some need profiling stuff
<jml> what should another project do if it wants to make heavy use of callgrind?
<jml> re-use bzrlib.lsprof?
<mgz_> iiiggggg
<mgz_> so, a fair bit of that file pre-dates the existence of various profiling in python updates
<mgz_> but... as alwasy, not everything arrived in the standard library
<mgz_> comparing the contents of that file with cProfile should give an idea
<mgz_> (both use _lsprof directly)
<jml> oh, interesting.
<jml> http://pypi.python.org/pypi/pyprof2calltree is actually a cousin of bzrlib.lsprof
<jml> in that it descends from exarkun & itamar's lsprof module too
<mgz_> right.
<jelmer> mgz: any chance of a review of https://code.launchpad.net/~jelmer/bzr/gpg-no-tty/+merge/112245?
#bzr 2012-06-28
<stewart> hi! i have a "bzr pull --overwrite" (as part of jenkins build) that didn't, in fact, overwrite the tree.
<stewart> instead the checkout failed :(
<stewart> with can't delete and conflicts.
<stewart> which then said "now on revision X"... but files appear to be missing
<spiv> stewart: what does 'bzr status' report?  Does 'bzr revert' and or 'bzr clean-tree' help?
<spiv> Also, I'm guessing the build products are in the same tree as the source?
<stewart> spiv, yes, build products are there.
<stewart> spiv, I get about every file under "removed"
<stewart> spiv, and a bunch of renamed from foo to foo.OTHER
<stewart> spiv, a usual set of "ignored" and a whole bunch of conflicts
<stewart> spiv, befor etrying revert/clean-tree, any debugging info i can gather?
<stewart> spiv, I've actually modified the jenkins bzr plugin so that on failure to check out it wipes the tree clean and tries again (solves the problem of bzr getting into unrecoverable state on killing it during checkout/pull)
<stewart> spiv, and what's interesting here is that the bzr process completed "successfully"
<spiv> stewart: it sounds like the usual "bzr produces a ton of conflicts when a tree update operation wants to delete a directory with unversioned files" bug
<spiv> stewart: The config option mentioned in http://doc.bazaar.canonical.com/beta/en/user-reference/conflict-types-help.html#deleting-parent will probably help
<stewart> spiv, other thought... would "bzr branch --stacked" work for checking out for jenkins builds? our problem for lightweight checkouts was the huge network IO of pulling everything down for each build, would we get any less with --stacked ? and should/does this work with "bzr pull --overwrite" ?
<spiv> It will probably help, and it should work fine.
<spiv> (It will definitely help a fair bit if jelmer got around to finishing my patch to itâ¦)
<stewart> spiv, we run a variety of bzr versions around as we have everything from lucid to centos5
<stewart> spiv, so it's a bit of an adventure :)
<spiv> Ah, heh.
<spiv> Well, maybe it won't work out, but give it a shot :)
<stewart> spiv, we've had fairly bad experiences with shared repositories on jenkins hosts whenever more than 1 process tries to do something with them at any one time.
<spiv> Yes, Twisted has had the same problem.
<spiv> There is (was?) a bug with concurrently inserting the exact same pack into a repo
<spiv> Which is exactly what tends to happen when you want N builders to fetch and test the latest revision.
<stewart> spiv, yep :)
<stewart> spiv, so... jenkins does "bzr revision-info -d /path/to" and " bzr log -v -r revid:foo" ... should that fit with stacked on ?
<stewart> spiv, because if so... we could just stack on the launchpad branches and be done with it...
<spiv> Sure, stacking is transparent (aside from the cost of hitting the stacked-on repo over the network if you need to access data from older revisions)
<stewart> spiv, (and i'd likely go and push this into the jenkins bzr plugin)
<stewart> spiv, it never does that. it's only ever current revision or pulling a tree with --overwrite.
<spiv> The downside stacking used to have is that you couldn't commit to a stacked branch, but that's fixed for 2a
<spiv> (And has been for a year or so)
<stewart> spiv, and a jenkins checkout should probably never be committed to anyway (the bzr jenkins plugin doesn't)
<spiv> Right
<stewart> spiv, as it's really just using bzr as a transport to get the latest tree.
<spiv> Right.
<spiv> Which is something that bzr really ought to support as a cheap operation!
<spiv> And either creating a stacked branch or lightweight checkout are the obvious ways the UI provides that *should* do it.
<stewart> spiv, when was stacked introduced?
<stewart> spiv, yeah, the lightweight checkout isn't really lightweight :)
<spiv> But I haven't kept up with bug fixes/new features, so I don't know if they have been fixed to meet that goal yet.
<stewart> spiv, so, bzr revert seemed to fix things up.... I'm kinda tempted to add that to the standard bzr jenkins plugin checkout procedure.
<stewart> spiv, it may have been fixed, but only in more recent versions... which is fun when you have ancient systems like CentOS 5
<stewart> heck... until earlier this year we had debian 5
<stewart> and centos5 will exist approximately forever.
<spiv> (If not, I can point you to an old branch of mine on lp that is a working proof-of-concept for making stacking work reasonably fast for this case)
<spiv> Well, so long as you can install bzr plugins, there's hopeâ¦
<spiv> But first it requires that the bzr on the server (in this case Launchpad?) has the necessary features :)
<stewart> spiv, yeah, we always point at launchpad trees, so it's a non issue for us :)
<stewart> spiv, i gather things would explode if somebody put a sftp:// branch or something with --stacked ?
<spiv> stewart: it won't be hugely efficient, but it shouldn't be utterly horrible either.
<stewart> spiv, awesome. Basically it was a "should I make a configuration variable for this" :)
<stewart> spiv, I'm kind of tempted to remove the functionality for checkouts and just replace it with stacked branches. I'm struggling to see the benefit of checkout over stacked branch.
<spiv> stewart: probably they tickle different performance bugs depending on the bzr versions involved :/
<spiv> (And really they ought to be about as efficient as each other for this use case)
<stewart> spiv, yeah, ought to be but aren't :)
<mwhudson> stewart: bzr super-revert is rm -rf *; bzr revert :)
<mwhudson> (maybe bzr remove-tree --force; bzr checkout)
<spiv> mwhudson: or 'bzr clean-tree --ignored --unknown --detritus; bzr revert' I think :)
<mwhudson> spiv: yeah something like that
<mwhudson> bzr ls -R0 | xargs -0 rm ?
<spiv> mwhudson: then do alias hulk_SMASH='â¦'
<mwhudson> :)
<hacosta> i ran bzr mv on a directory, but then i regreted that, so i mv'ed them back
<hacosta> and now when i run bzr status i get a bunch of renames that show the same path
<hacosta> e.g
<hacosta> a/b/foo.c => a/b/foo.c
<hacosta> will that appear how do i remove that
<hacosta> i haven't commited anything at this point
<fullermd> That probably means something in the dir tree wasn't mv'd back, but took on a new identity.
<fullermd> You can use revert to throw things back (trickier if you have content or nearby changes to preserve)
<hacosta> i had a couple of modifications on some files :S
<fullermd> Well, you could stash a diff and reapply it by hand.  Or try shelving.
<bob2> bzr mv --help
<bob2> tl;dr after or whatever it is
<Oli> How do I drop all the changes in a working branch (so that it drops back to the state it was at the last commit)?
<jelmer> Oli: 'bzr revert'
<Oli> Duuh. Thanks jelmer!
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr/rm-get-ancestry/+merge/112090
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr-upload/install-lazy-named-hook/+merge/97942
<jelmer> vila: bug 863261
<ubot5> Launchpad bug 863261 in Bazaar Git Plugin "allow roundtripped revisions in id map cache" [High,Triaged] https://launchpad.net/bugs/863261
<jelmer> vila: triiiiing
<jelmer> vila: and bug 544776
<ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,Triaged] https://launchpad.net/bugs/544776
<jelmer> vila: if you feel like doing more bzr reviews, I have some more.. :-)
<vila> jelmer: trying to *commit* in all my pies currently ;)
<jelmer> hehe, okay
<dobey> hey all
<dobey> so bzr 2.6 removes Hooks.create_hook() which was deprecated in 2.4, but switching code to use that breaks compat with bzr 2.1 and 2.3 which are shipped in lucid and natty
<dobey> anyone have a suggestion how to deal with this in a reasonable way?
<dobey> or does one just have to duplicate the calls by doing try/except?
<dobey> i guess try/except with a bit of magic is the way to goo. nevermind me
#bzr 2012-06-29
<Noldorin> hey jelmer
<jelmer> hi nopf
<jelmer> sorry
<KombuchaKip> Is the nautilus bzr plugin abandoned?
<jelmer> hi Noldorin
<Noldorin> hi jelmer
<Noldorin> what's up these days?
<jelmer> Noldorin: not much :)
<Noldorin> fair enough
<Noldorin> jelmer: what you working on for canonical these days?
 * fullermd . o O ( the ceiling? )
<james_w> yay, database is locked error!
#bzr 2012-07-01
<leo_rockway> greetings
<leo_rockway> I'm trying to checkout/branch a subdirectory within a branch.
<leo_rockway> this is the branch: http://bzr.savannah.gnu.org/r/gnuzilla/icecat/
<leo_rockway> and I want this subdirectory: browser/branding/unofficial
<leo_rockway> I tried bzr branch http://bzr.savannah.gnu.org/r/gnuzilla/icecat/browser/branding/unofficial
<leo_rockway> and got bzr: ERROR: Not a branch: "http://bzr.savannah.gnu.org/r/gnuzilla/icecat/browser/branding/unofficial/".
<leo_rockway> which is correct, brwoser/branding/unofficial is not a branch... but I'm not sure how to get only one subdirectory
<leo_rockway> I searched online, but I'm probably using the wrong terms, because I can't find the answer to this.
<leo_rockway> so, if anybody can point me in the right direction, that would be great. Thank you.
<AfC> leo_rockway: I'm not sure off hand if there's a means to do that; given a branch you can extract individual files with `bzr ls`
<leo_rockway> mmhh... too many files to do that manually.
<leo_rockway> I mean, for individual files.
<leo_rockway> thank you, though.
<AfC> leo_rockway: ah, no, export will do it no problem:
<AfC> $ bzr export booga file:///home/andrew/src/java-gnome/mainline/src/util
<AfC> resulted in a booga/ directory containing just the src/util/ tree of the branch at ~/src/java-gnome/mainline/
<AfC> ta-da
<leo_rockway> I see.
<AfC> Me puts another penny in the "we love Bazaar today becuase of ___" jar.
<leo_rockway> well, the main reason why I was trying to branch off only the "unofficial" directory is because that one is about 10MB while the whole branch is 350MB.
<leo_rockway> with this method I still need to download the whole branch.
<leo_rockway> 350MB is not a lot, but it's much more than 10MB.
<AfC> leo_rockway: if you do what I suggested you will only need to download sufficient data to extract the tree in question. No guarantee that it's only 10MB. Might be (considerably) more depending on how it is packed and the shape of its history.
<AfC> s/tree/subtree/
<leo_rockway> alright, thanks a lot =]
<AfC> leo_rockway: to be honest, if you have the bandwidth you're probably better off just having a local mirror of the branch. {shrug}
<AfC> DVCS and all
<leo_rockway> that would be so, but I don't plan to develop on this branch. I just wanted to find a way to get the unofficial branding from GNU IceCat to use it in my local build of Firefox.
<leo_rockway> I'm not even interested in the history, so I might use the lightweight option
<leo_rockway> goodnight
<AfC> Or you could have just exported like I told you to. {sigh}
<ryanprior> I'm having trouble pushing to Launchpad from my colleague's Windows machine. He gets an error saying that authentication failed, despite having Pageant running and his SSH key showing in Pageant with the same fingerprint as the one shown by Launchpad. Any Windows users in here who could help troubleshoot this?
#bzr 2013-06-24
<tuvwx> where can i read/learn about how to use bzr with multiple, possibly divergent remote branches? what are my options? (no local changes)
<tuvwx> i have a local branch from one remote branch. now i want changes from another remote branch. 'bzr missing <new-remote-branch' says: You have 3 extra revisions, and You are missing 65 revisions
<tuvwx> how do i keep my 3 extra revisions and get the missing 65 revisions?
<tuvwx> do i just 'merge <new-remote>', or is there a safer way?
<jelmer> tuvwx: yeah, just 'bzr merge <new-remote>' should work
<tuvwx> jelmer: and how do i recover if the merge goes bad? (go back to pre-merge state)
<jelmer> tuvwx: 'bzr revert' will revert any pending changes in the working tree
<tuvwx> the problem is: after the merge i will diverge from all remote branches. if i want to, how do i go back to being identical to one of them?
<jelmer> tuvwx: you can 'bzr pull --overwrite <remote-branch>' to make your changes the same as the remote branch
<tuvwx> jelmer: great! many thanks!
<tuvwx> jelmer: btw, what is a good, compact source for such information? searching rarely lands me on breaf, to-the-point references
<tuvwx> *brief
<jelmer> tuvwx: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/index.html might help
<tuvwx> jelmer: see, i can't find --overwrite in there
<jelmer> tuvwx: I don't think that's a very common thing; the docs on "bzr pull" will have some notes on overwrite I think
<mgz> jelmer: (unrelated to anything) `bzr pull -d co:trunk` does surprising things
<mgz> it's not at all like `bzr pull -d ../trunk` which is the anathingy I was expecting
<tuvwx> i did the merge, and got no conflicts. how can i confirm that the working directory has code from the two source branches? version-info shows info for the original branch only
<tuvwx> 'status' shows modified files (not committed yet)
<tuvwx> i can't find any reference to the new branch after the merge
<__marco> hello, how can I see if a pull will create collisions?
<__marco> I have a big change that I decided to break in smaller pieces. I created a clone of my repo, made and committed some changes and now I would like to pull to my changes back
<mgz> __marco: merge --preview
<mgz> specifically, assuming branches original and new, `cd original; bzr merge --preview ../new`
<__marco> mgz: now I now because it was not mentioned in the doc, no such option. my bazaar version is to old I think
<mgz> just merge then diff then, but I suspect you just tyoped, preview has been in for ever
<__marco> I am sorry, I read missing instead of merge
<mgz> the relevent thing is what you are doing is a merge, not a pull.
<__marco> mgz: a merge that is a pull because I made no changes in the original branch. So i looked only to the missing and pull documentation
<__marco> and missed that
<__marco> thanks
<jelmer> mgz: doesn't it just pull the changes from the trunk colocated branch into the current branch?
<mgz> jelmer: does something odd like switches the working tree... leaves the branch pointer alone, which is very confusing
<xnox> is there a command line way to lookup sha1 of a given revno?
<jelmer> xnox: I think "bzr revision-info" might show it
<mgz> yeah
<jelmer> xnox: otherwise there is "bzr cat-revision"
<jelmer> xnox: but the output of that is format-specific, so it's not necessarily a good idea to use
<xnox> jelmer: i'm after something like: get_testament_sha1(self, repo, revid):
<jelmer> xnox: IIRC there was "bzr testament" as well
<xnox> jelmer: now..... i just want testament locally to be the same as produced by udd =))))
 * xnox is getting different sha values locally......
<xnox> smells fishy
<xnox> thansk a lot.
<pindonga> hi... does anyone know of an easy way to get the timestamp for a given commit (by revno)
<pindonga> using bzrlib
<jelmer> pindonga: b = Branch.open(PATH); b.repository.get_revision(b.revision_id_to_revno(REVNO)).timestamp
<pindonga> cool
<pindonga> jelmer, if I do this: br.repository.get_revision(br.revision_id_to_revno(br.revno()))
<pindonga> I get a NoSuchRevision error
<pindonga> looks like it's not expecting a revno after all?
<pindonga> I could use br.last_revision() instead
<pindonga> but I'd like to use br.revno() as it's easier to read for humans (when I present the info)
<jelmer> pindonga: sorry, br.get_rev_id() rather than br.revision_id_to_revno()
<pindonga> ack
<pindonga> thx
<pindonga> jelmer, worked like a charm, thx!
<jelmer> quicksilver: hi, did you hear back much in reply to your lazyweb post about activity trackers?
#bzr 2013-06-25
<quicksilver> jelmer: was that me?
<jelmer> quicksilver: sorry, wrong person
<quicksilver> :)
<quicksilver> well it sounded like me, I'm very lazy and I like tracking things :)
#bzr 2013-06-27
<fullermd> Urg, annotate holds a lock on the WT?  That's annoying.
#bzr 2013-06-28
<jelmer> fullermd: it shouldn't have to - fixing that is probably an easy fix
<jelmer> fullermd: IIRC annotate doesn't require a working tree, it's probably just that it takes a lock on the working tree if there is a working tree
<bob2> tree.try_lock_all_the_things()
<jelmer> roughly
<lifeless> fullermd:  jelmer: annotate annotates local edits too
<lifeless> edit the file, then annotate it, local changes will show up appropriately.
<jelmer> lifeless: that depends on the arguments though
<lifeless> right, but thats' the default
<lifeless> and fullermd didn't specify args.
<jelmer> lifeless: e.g. 'bzr annotate -r3' takes a lock on the working tree where it shouldn't
<jelmer> I didn't realize fullermd was doing a non-arguments annotate
<lifeless> jelmer: I don't know if he is or isn't ;)
<fullermd> I am, but even if it needs to lock to do that, it shouldn't sit around holding the lock forever   :p
<fullermd> "bzr ci ; mmm...   ; bzr ci ; ... wtf is holding a lock?   *search* *search* *search* Oh, look, there's a ^Z's less off in another terminal..."
<fullermd> (not that I'm _entirely_ sure why ann'ing local changes requires locking the dirstate either, but hey, locking for a second or two to do the ann is ignorable...)
<lifeless> fullermd: so this is more a dirstate bug than annotate
<lifeless> fullermd: because the dirstate can't be *read* safely without locking; the new one I put up a proof of concept of fixes this.
#bzr 2013-06-29
<jelmer> james_w: hi
#bzr 2013-06-30
<Azendale> I have a project that so far I have only worked on. I would eventually like to release it to the public with BZR revision history eventually. The problem is that I just realized that I accidentally committed a password to the branch a few commits ago.
<Azendale> Is it possible to remove that password from the branch (which has not been shared with anyone) without loosing the commits since, or worse, all the commit history up to this point?
<Azendale> I'm thinking bzr rebase is the key, but my head isn't wrapping around the time travel involved well enough to come up with what steps I would have to take.
<mwhudson> Azendale: yes you need to do something like rebase to do that
<Azendale> mwhudson: Do you know the general steps I would follow? I've read the man page but haven't been able to figure out the steps I would take
<mwhudson> Azendale: no, i've never used it
<mwhudson> Azendale: if it's just a few commits back you can sort of do it by hand
<Azendale> mwhudson: I think it's something like 5 commits or so
<Azendale> mwhudson: I have considered branching before the bad commit, then using bzr diff to make a patch to apply, then manually copying the commit messages. Is that what you're suggesting I do?
<mwhudson> Azendale: yeah
<Azendale> mwhudson: Ok, thanks for the help
<lifeless> bzr replay may be a good way to nab those commit messages
<jelmer> Azendale: in theory the diff + patch step can be done by "bzr replay" (which is part of the bzr-rewrite plugin that rebase also lives in)
<Azendale> ok, thanks :)
<mwhudson> ah yes
<mwhudson> i knew there was an automated solution somewhere :)
<Azendale> mwhudson, lifeless, jelmer: I got it to work. Branched before the commit with the password. Then did a cherry pick merge of the bad commit (bzr merge -c <badcommit>), because I did have changes I wanted in there. Then I had it forget the merge (bzr revert --forget-merges). I removed the password and commited that. (Thereby keeping the good changes from the commit with the password)
<Azendale> mwhudson, lifeless, jelmer: Then I did bzr replay -r<commit_after_the_password_commit>.. <path_to_branch_with_password>
#bzr 2014-06-24
<mbruzek> Good morning bzr folks.
<LeoNerd> Morning. Well, afternoon actually
<mbruzek> I am trying to get a system that has limited network access be able to use the bzr commands such as bzr init, bzr whoami, bzr add, and bzr commit.  What ports do I need to allow in the firewall to use bzr?
<LeoNerd> Nothing in particular.
<LeoNerd> It's not going to talk networking at all if it's local
<LeoNerd> If you're going to push it over, say, ssh; you just need ssh access
<mbruzek> It doesn't need to dial home?
<LeoNerd> Where's "home"?
<mbruzek> launchpad.
<LeoNerd> bzr init; bzr add "some files"; bzr commit -m "here's a message"
<LeoNerd> ^-- makes something local
<mbruzek> oh!
<LeoNerd> bzr -could- talk to LP if you want it to, but it won't normally
<LeoNerd> It's decentralised
<mbruzek> Thank you LeoNerd I didn't understand that
<mbruzek> which would also explain why my search has not turned up very much.
<mbruzek> Thanks very much LeoNerd.
<LeoNerd> :P
<mbruzek> LeoNerd what if I am trying to contact launchpad.net for example "bzr branch lp:juju"
<LeoNerd> Well, then it'll try to pull from LP.. likely over HTTP
<LeoNerd> So as long as you can make outbound HTTP requests you'll be fine
<mbruzek> I obviously need to open the firewall to launchpad
#bzr 2014-06-26
<frecel> hello
<frecel> I'm trying to build a source packgae for a PPA and I'm running into some issues
<frecel> http://pastebin.ubuntu.com/7706616/
<stbatduke> Hello all
<stbatduke> I'm new to bzr, and I'm looking for some very basic assistance
<stbatduke> I'm trying to push a branch to a new location on another server we have
<stbatduke> the branch seems to be created, but shows a different parent
<stbatduke> but none of the files copy, and I can't bzr push or bzr pull to make the copy happen
<stbatduke> so, in summary, I'm rather confused :)
<stbatduke> anyone there ?
<fullermd> The parent on the pushed copy probably won't mean anything (actually I wouldn't expect it to be set)
<fullermd> And what do you mean "none of the files copy"?  If you mean "there's no working tree", that's expected.
<stbatduke> I'm trying to branch (unsure of terminology) from server "prod" to "dev", in order for our developers to look into some broken code.  They can't have access to the actual "prod" server
<stbatduke> so I did a bzr push bzr+ssh://dev.blah.com/path/to/desired/destination and it created the .bzr file on the dev  (destination) server as I wanted it to,
<stbatduke> but there are no files that ended up in the destination location
<stbatduke> besides the .bzr folder and it's normal files anyways
<stbatduke> also in the branch folder in .bzr, the branch.conf lists a different parent_location than where I tried to push from
<stbatduke> probably the original code base from when we pulled the code into prod before I started
<stbatduke> soooo .... part of what I don't understand is what a branch is, whether or not it's considered new code, or a new a new branch of the same code (alternate universe?), or if its something else
<fullermd> The branch is the history; that's what push and pull move around.
<fullermd> Generally you don't push to locations people work; you push to a shared location that they pull from there into a local branch to do their work.
<fullermd> (you _could_ work in a place that's somebody's push target; there's no _technical_ boundary.  But it's likely to lead to all sorts of confusion as things change out from under you)
<stbatduke> well yes, I'm pusing to a shared location that they will then pull from
<fullermd> So you've got all you need.  pull only talks to the VCS internal stuff, it doesn't care anything about checked-out files in the working tree.
<stbatduke> ok so push just moves the branch (history)
<stbatduke> ok
 * fullermd nods.
<stbatduke> so how does the developer then get the actual files then?
<fullermd> When they 'branch' from it, they'll get a local copy with the files all checked out.
<stbatduke> ok, so they'll use 'bzr branch <new shared location>' and it will then copy the files?
 * fullermd nods.
<stbatduke> nifty, no need to file copy until they want to get the files!
<stbatduke> then they request and bzr takes care of the details
<stbatduke> so, the working tree would be the actual files of a branch at the original location (parent location or parent branch?)?
#bzr 2015-06-22
<throstur> what's the proper way to escape " inside comments in bzr commits?
<throstur> is it just a standard '\'? bzr commit -m "did \"this\" thing"
<vila> throstur: it depends on your shell, bzr doesn't care, it only receives a string without the quotes
<throstur> thanks vila, I'll play it safe and sanitize by replacing double quotes with singles then
<vila> throstur: right, I do the same when I face the issue ;)
<throstur> :)
<fullermd_> You can probably use 'echo' for quick tests.
<throstur> fullermd_: I don't know anything about the shell of the invoker
<throstur> (I'm integrating bzr command lines into another tool)
<fullermd_> Well, I'd expect that tool to be exec'ing bzr directly, rather than via a shell ('cuz that's Stupid And Evil), so you wouldn't really have any quoting worries anyway.
<fullermd_> As an alternate, does -F take '-' and read from stdin?  And if not, why the heck not?
<fullermd_> If you're going through a shell from arbirary input, you're gonna have all sorts of escaping problems.
#bzr 2017-06-28
<jvelasquez> hi. I made /etc a repo, added everyting in /etc to it, commited, and then wanted to "relocate" (terminology from svn) the repo to a real server,  so I did a 'switch --force',  but now I have nothing in /etc.
<jvelasquez> is there an easy way to restore my /etc?
<jvelasquez> or any way?
<jvelasquez> I suppose it's on my server and I just need to check it out.  :|
<jvelasquez> damn. there's nothing on the server.
<jvelasquez> I wonder what this command did:   bzr switch --force bzr+ssh://j@jv.lan/srv/bzr-etc/trunk
<mgz> jvelasquez: pastebin `bzr info -v /etc`?
<mgz> you should still have the repo under there, but you've pretty seriously borked the branch
<jvelasquez> says:  bzr: ERROR: Unrecognised value for BZR_SSH environment variable: ssh
<jvelasquez> I think the data is gone.  /etc/.bzr doesn't have much of anything.
<jvelasquez> I guess it's gone.  I'll start rebuilding from new.  :|
<fullermd> I wouldn't expect it to really blast away the repo...
<fullermd> Though I couldn't even guess what switch --force would do on an initially standalone branch.
<fullermd> There might be micro black holes involved.
<jvelasquez> well, what was I supposed to do?
<jvelasquez> I hope, at least I can learn the right commands.
<fullermd> Mmm, probably depends on a lot of details, but my first impulse would be something like push ; bind.
<fullermd> How'd you populate the j@jv.lan/srv/bzr-etc/trunk branch before the command?
<jvelasquez> opened a shell on that machine directly, and did,  bzr init-repo bzr-etc; cd bzr-etc; bzr init trunk
<fullermd> 'k.  So you created an empty branch, then tried to switch your existing /etc over to it.  So, winding up with an empty tree makes sense.
<fullermd> I would _presume_ that there's still a bunch of stuff in /etc/.bzr/repository though.
<fullermd> (I mean, it'll probably be small, since /etc is all little tiny text files)
<fullermd> So your WT would be screwed up, and so would the branch.  But theoretically, the repo is fine.
<fullermd> So...
 * fullermd contemplates.
<jvelasquez> yes. lot's of stuff in /etc/.bzr/repository
<fullermd> Well, first off, tar up /etc/.bzr just as a backup, so when I suggest something stupid you only get annoyed instead of hunting me down.
<fullermd> Then...   hm.  OK, copy/untar the whole .bzr in /tmp/etc (or whatever scratch space)
<fullermd> Manually blow away the checkout/ and branch/ dirs inside .bzr.
<fullermd> Hm.  Probably can't just use 'init' blindly, but...
<fullermd> 'bzr reconfigure --use-shared' should make the repo think of itself as shared, then you can 'bzr init xyz' to create a /tmp/etc/xyz empty branch.
<fullermd> Then from in there, you can use 'bzr heads --dead' (from bzrtools, I think) to fish out the old head revision id from the repo, and then use 'bzr pull --force -rXYZ .' to pull it out.
<fullermd> And check it over.  If that works, you can just do a pull from that into your switch-ified /etc to blat the info up into the new repo and restore the WT.
<fullermd> (won't restore permissions though, so you'll have to do that manually, or master.passwd or shadow or whatever will be world readable, etc)
<jvelasquez> etckeeper was also setup, for permissions
<fullermd> That'd make that part easier.
<mgz> fullermd: thanks for doing the brain-work
<fullermd> Well, it was either that or do my _actual_ work, and that's boring and annoying   ;)
<jvelasquez> yes. thank you.  I've been too busy following your steps, than to thank sooner.
<fullermd> Well, don't thank me 'till it works   :)
<jvelasquez> before `bzr reconfigure --use-shared`, /etc is 12MB. after is 9MB.   it asks me for my passwd to the other host, twice.
<fullermd> Mmm.  I was saying to do that off in a temp copy, after blowing away the branch/checkout dirs; it shouldn't be trying to contact anything else then, just flipping the bit in the repo.
<fullermd> Maybe it did a repack or something.
<jvelasquez> ahh!  "blowing away the branch/checkout dirs"!
<jvelasquez> I'll repeat.
<jvelasquez> your right. it doesn't ask any more.  but it also dumped it's repository.
<jvelasquez> maybe I can return the repository without it noticing.
<fullermd> Hm.
<fullermd> I thought reconfig would alter the repo.  I mean, it tries doing stuff with the branch too, but I thought on a bare repo...
<fullermd> Wow, it completely blows it away.
<jvelasquez> I think I got it!
<jvelasquez> yep!
<fullermd> Goodie, I was looking for an excuse to file some bugs to harass mgz...
<jvelasquez> basically exactly what you said.
<fullermd> 'k, I think the 'bit' is just a file.
<fullermd> So touch .bzr/repository/shared-storage in place of the reconfigure step.
<mgz> fullermd: :P
<jvelasquez> I think I'm actually starting to learn some of this.
<jvelasquez> fullermd,  thanks so much.  maybe after friday, I can send you $50
<jvelasquez> least i could do. :|
<fullermd> Oh, that's unnecessary.
<fullermd> 'course, after mgz notices me reassigning all my bzr bugs over to brz, I may need the getaway money...
<jvelasquez> and so is the effort to help.
<fullermd> Eh, I consume support, I provide support...  it all evens out in the end.
<fullermd> As long as nobody tallies my consumption too carefully, anyway.
 * mgz chews on fulldermd
<mgz> -d
<mgz> too much of a mouthfull
<fullermd> 4 out of 5 dentists advise against recreational fullermd chewing.
<mgz> only because they haven't tried it yet...
<jvelasquez> ok.  so now for a "push" and a "bind"
<fullermd> 'push' will take what you've got in that local branch and make a copy of it in the remote location, and then 'bind' ties your local branch to that remote so commits automatically go upstream.
<fullermd> Effectively moving you from "local branch owns everything" to "remote branch owns everything, and i have a local checkout"
<fullermd> (modulo my usual checkouts-vs-bound grumblings, anyway)
<jvelasquez> has anyone ever seen a bunch of your files, all renamed with the postfix str ".~1~"
<fullermd> That's where things get renamed when bzr needs to move them out of the way.  e.g., 'revert'd changes, pre-existing unknown files when you merge/pull in new files with conflicting names, etc.
<jvelasquez> `bzr info` lists Related branches,  but the push branch is wrong.  I'd like to update it.
<fullermd> push --remember
<jvelasquez> :)
<jvelasquez> to think i trashed the whole working copy and repo, just cause of that old push branch.
<jvelasquez> So,  I did a push to a remove location, inside of a repo, inside a shared repo,   but yet when I open a shell local to the repo, it says the content I added is "Unversioned"
<jvelasquez> I guess it's versioned here, locally,  and it's been pushed to a remote location, and that remote location is inside a repo,  but the files were not actually added to the repo.
<fullermd> I suspect you're probably mixing up what's where with working trees, etc.
<fullermd> Particularly, pushing to a remote repo won't touch anything in its WT.  And as a central repo location, there's no reason for it to _have_ a WT in the first place.
<jvelasquez> WT = working tree?
 * fullermd nods.
<jvelasquez> ok.  so do I have it right?
<jvelasquez> I want to version my files, and centralize their location.   they say "unversioned",  and this is ok!
<fullermd> It depends on exactly what "they" are in this context.
<fullermd> If "they" are the files in the location where you're doing stuff (i.e., somesystem:/etc), no.
<fullermd> If "they" are files sitting aroud in the filesystem where your central repo is (i.e., jv.lan:/src/bzr/etc/trunk), who knows; that has no necessary relation at all to what's in the _bzr repo_.
<fullermd> (which is why I say, generally don't even have WT's in central repo places; looking at them will only ever confuse things)
<jvelasquez> I guess they are not being edited.   They're being centralized,  so that I can check them out from other hosts, where they will be Hot or Live
<fullermd> The simplest way to be sure of what's actually in that centralized branch is probably just to make a scratch checkout in /tmp or somewhere, and make sure you get what you expect.
<jvelasquez> ahh.  so using term "trunk" is inappropriate here
<fullermd> It's a social term, not a technical one; it's a matter of how you use and arrange your pieces.  The pieces themselves just sorta float around independently.
<jvelasquez> but I believe that's what I want.  cause I'm collecting a few repos which are "current effort" aka trunk,  but later I will collect other similar sets of repos, which are different branches from it.
<fullermd> Sorta like "central repository" (which probably more strictly means "central branch" in this case); there's nothing technical intra-bzr you do to make it Central, what makes it Central is just how you use it.
<jvelasquez> ok.  but the versioning was originally done on my machine, and then I just pushed the whole repo to a fileserver for later.
<fullermd> The terminology can trip things up a bit; technically you pushed the branch.
<fullermd> You pretty much never interact with a _repository_, only with a branch.  The distinction in speech often doesn't matter, but sometimes it can cause confusion when discussing details.
#bzr 2017-06-29
<fullermd> So: you had a branch in the place where you're using the files.
<fullermd> You used 'push' to make a copy of that branch somewhere else.
<jvelasquez> so different people will be able to checkout that branch, from the file server, and all work on it like other VCS?
<fullermd> You socially want that "somewhere else" to be the central home, so you declare it such.
<fullermd> So you socially want that original branch to function like a checkout of the branch branch, and you use 'bind' to make it act like that.
<fullermd> Then you use 'checkout' from that central branch to make new checkouts of it anywhere else you want 'em.
 * fullermd nods.
<fullermd> And then you use 'update' in those various other branches any time you want to catch up to the central repo.
<fullermd> You usually don't want to use "pull" in a checkout.  Or rather, you maybe often do, but it may not do what you think if you're used to standalone branches.  So for simplicity...
<jvelasquez> Would I have been better off,  tar cf of my branch,  and then untared it into the central repo,  so that way the central repo has stuff that's versioned ?
<jvelasquez> using tar instead of push ?
<fullermd> No, your central repo has stuff that's versioned.
<fullermd> It just doesn't have a useful working tree.  And probably shouldn't.
<fullermd> Generally you'd just have branches and their repos (individual or shared; doesn't make a fundamental difference) in the central place.  You'd only have WT's in the various checkouts.
<fullermd> Or alternately, if it's anything other than the stuff in .bzr/, none of push/pull/branch/checkout/merge/etc will ever read or write or care anything about it.
<fullermd> (leaving aside various edge cases that don't affect the main point)
<fullermd> So if a central place exists to store the history and provide a target to be checkout'd etc (which is generally the case), there's no reason for it to have any files other than the .bzr/ stuff.
<fullermd> Is that all making things clearer, or muddier?
<abentley> fullermd: --use-shared changes a branch to *use* a shared repository.  It doesn't convert a repository into a shared repository.
<fullermd> abentley: Yeah, I knew it did that; I thought I remembered it doing the slightly-unsettling double duty too.
#bzr 2017-06-30
<jvelasquez> fullermd, heh.  I tried mixing my repo with working trees,  and discovered that you were correct.   But I did back it up first.   now I run it with "--no-trees"   :)
<jvelasquez> fullermd,  i guess it was one mistake I just had to make my own.
<jvelasquez> How can I find out if a file is versioned or not?   or in some directory, see which files are versioned, and which are not?   like,  `ls` but with dVCS basics?
<jvelasquez> nevermind, I found it
