[00:04] <ionel_mc> isn't bzr supposed to be easy_install-able ?
[00:06] <beuno> igc, I was wondering, since you kinda nodded at the sprint when I asked if you could help with the IDE Integration team, do you think you might have some time these coming weeks to help me put together the basics for an integration guide?  Mainly the structure, I can fill the blanks and/or poke people to do so after that
[00:07] <beuno> I can't really think of a good structure for it  :(
[00:15] <igc> beuno: sure. I'd like to keep focus on 1.5 this week so how about bugging me about it again next week?
[00:15] <beuno> igc, sure, sounds good. Thanks  :)
[00:22] <lifeless> jam: poolie said you'd need the branch friday?
[00:22] <jam> lifeless: yeah, by friday to do 1.5rc1
[00:23] <lifeless> jam: if I make it early it misses merges
[00:23] <lifeless> jam: its best to make it at th etime
[00:24] <jam> lifeless: as long as it happens, I'm okay with that
[00:24] <jam> I could always do a merge from bzr.dev as the first thing
[00:26] <lifeless> no need, I'll make it late my friday
[00:26] <lifeless> it will be there pristine when you get up
[00:27] <lifeless> ionel_mc: I think we support that but not 100% sure
[00:28] <lifeless> ionel_mc: however having folk run arbitrary scripts over the internet isn't really a great idea, so few of us are deeply interested in that install path
[00:30] <ionel_mc> lifeless, i think you completely misunderstood easy_install
[00:30] <lifeless> possibly
[00:31] <lifeless> I realise that what I said above does not encompass the entire thing
[00:32] <ionel_mc> rather silly regarding easy_install as "running arbitrary scripts over the internet"
[00:32] <poolie> lifeless: can you have a quick look at my RemoteBranchLockableFiles mail, just saying "yes" to john would be enough
[00:32] <ionel_mc> regardles, here's the problem (on win32): http://rafb.net/p/CQ4V9N22.html
[00:33] <ionel_mc> should be fixed by providing a corect egg for win32
[00:33] <lifeless> poolie: when are you arriving ?
[00:33] <bob2> same problem on lunix
[00:34] <lifeless> thats strange, I'm sure we include setup.py in the tarball
[00:35] <ionel_mc> lifeless, ah yes, the download link is broken on the pypi entry, should be http://launchpad.net/bzr/+download instead of http://bazaar-vcs.org/Download
[00:36] <lifeless> poolie: ^
[00:36] <ionel_mc> lifeless, that tarball is for slackware only
[00:36] <bob2> heh, it is downloading a slackware tarball
[00:37] <poolie> !!!
[00:38] <bob2> ionel_mc: which of the files on the launchpad page would be easy_installable?
[00:38] <ionel_mc> bob2, depends on the platform
[00:50] <poolie> lifeless: i think you misunderstood my text
[00:52] <lifeless> poolie: ko
[00:52] <lifeless> *ok*
[00:54] <lifeless> I thought you were saying that the thing was intercepting the wrong api, and not allowing the server to provide the configuration, and that you proposed to make the method deprecated
[00:57] <lifeless> -> caffiene, to avoid other misunderstandins
[01:31] <MattCampbell> It occurred to me that section 4.2 of the user's guide should mention the bzr+ssh URL scheme instead of or in addition to sftp, because if you're pulling from another developer's machine via SSH, chances are that machine has bzr too, and bzr+ssh would work.
[01:34] <lifeless> MattCampbell: good point
[01:34] <MattCampbell> Plus bzr+ssh works without paramiko.
[01:35] <MattCampbell> on Unix at least
[01:39] <MattCampbell> On the other hand, I suppose you may wish to emphasize, especially in early chapters, that bzr requires no special server or protocol of its own.
[01:53] <ionel_mc> lifeless, bob2, any resolution on the easy_install issue?
[01:53] <lifeless> not sure what we can do
[01:53] <lifeless> the first url on the page is the right one
[01:54] <lifeless> pypi is pointing at the right page
[01:56] <ionel_mc> not quite
[01:57] <ionel_mc> hmmm
[01:57] <ionel_mc> looks like easy_install -f http://launchpad.net/bzr/+download bzr doesn't help
[01:58] <ionel_mc> looks like setuptools pick up the wrong package, either that slackware package is named wrong or there is some problem in seuptools's parsing
[01:59] <Peng> bob2: Oh, hi.
[01:59] <ionel_mc> lifeless, either way, you could just upload the packages to pypi for a quickfix
[02:11] <Peng> Err.
[02:14] <MattCampbell> It seems to me that chapter 7 of the user's guide, currently called "Best practices", should instead be called something like "Advanced features".
[02:15] <Peng> Is branching a dirstate branch over bzr+http supposed to result in a traceback?
[02:15] <Peng> Crap, may just be a corrupt branch.
[02:17] <spiv> Peng: no, nothing is supposed to result in a traceback :)
[02:18] <Peng> Haha.
[02:18] <spiv> (And I don't know of any bugs open about bzr+http + dirstate)
[02:21] <Peng> Ok.
[02:40] <Peng> .bzr.log and info at http://paste.pocoo.org/show/48226/ . Want me to file a bug?
[02:41] <spiv> Peng: interesting
[02:41] <spiv> Peng: I wonder if reconciling the branch will fix it?
[02:41] <Peng> spiv: Didn't try it.
[02:42] <spiv> Peng: that probably is worth a bug report, although it *might* be a duplicate.
[02:44] <Peng> Reconciling did not help.
[02:44] <lifeless> poolie:  ?
[02:44] <Peng> Oh, look, lots of developers are here now.
[02:44] <Peng> Hint hint. :P
[02:45] <lifeless> where? I want to meet one
[02:49] <Peng> Ok, not http-specific. Also happens with bzr+ssh from Launchpad.
[02:53] <AfC> I don't have anything earth-shattering to say to you today, but wanted to wave all the same.
[02:53] <AfC> so,
[02:53]  * AfC waves
[03:26] <yminsky_> I have a question about how to use tailor with bzr.
[03:27] <yminsky_> I have two related bzr repos that I would like to export to hg.  I'm not sure how to do this in a way that tailor preserves the fact that the repos are related.  Anyone know how to do this?
[03:29] <MattCampbell> Have you looked at the bzr-hg plug-in? (I only know it exists.)
[03:30] <MattCampbell> According to the description at Launchpad, it can transfer in both directions.
[03:30] <yminsky_> I have not.  that sounds promising.
[03:31] <Peng> Haha.
[03:32] <Peng> I ran my VPS out of memory with bzr+http.
[03:32] <lifeless> mmm, bzr-hg is not able to push to hg last I checked
[03:33] <yminsky_> Anyone know how to use the plugin?  I downloaded and installed it, but I don't know how to invoke the plugin.
[03:34] <MattCampbell> Oh, I guess I overlooked the word "eventually" in the Launchpad description. :(
[03:37] <mneptok> yminsky_: i think the problem is that there just haven't been a lot of cases where people want to move from bzr to Hg  ;P
[03:37] <yminsky_> Nice.
[03:38] <mneptok> sorry, couldn't resist.
[03:38] <yminsky_> Anyone else have thoughts on how to achieve this?
[03:38]  * mneptok takes some getting used to.
[03:40] <MattCampbell> Any particular reason you want to go from bzr to hg?
[03:41] <mneptok> yminsky_: have you broached this subject with the Hg community? converts from bzr to Hg will be more readily found there, i would think.
[03:41] <yminsky_> Nothing deep.  We use hg extensively at work, and so I am now VERY familiar with it, and I'd like to convert some old bzr repos that I have up to hg.
[03:42] <mneptok> yminsky_: not trying to blow you off, but as an answer doesn't seem to be immediately forthcoming here ...
[03:42] <mneptok> *shrug*
[03:42] <yminsky_> I'm actually a little surprised that this isn't easier.  I feel like I've heard a lot of talk about how it doesn't matter that much which DVCS you use because you can transfer changesets from one to another....
[03:42] <yminsky_> Fair enough.  I'll poke the mercurial folk.  I just thought there might be some experience here.
[03:50] <mneptok> yminsky_: there may be. but i think "not at the moment" is a fair assumption. so start looking elsewhere in case that expertise never shows up here. make sense?
[03:50] <yminsky_> yup.
[03:51] <mneptok> good good. glad you don't feel unlove ... bah
[03:51] <igc> yminsky_: we're working with the git guys to improve interoperability via fastexport/fastimport. You can use that approach as well for getting from Hg to Bzr. If and when the Hg guys support fastimport, you'll be able to get from Bzr to Hg that way too.
[03:52] <igc> hg has an import extension but it doesn't support Bazaar to my knowledge
[03:52] <igc> there just isn't the demand for people moving from bzr to hg :-)
[03:52] <mneptok> igc: keep talking to yourself and Mark will buy you a dinner jacket like mine.
[03:52] <mneptok> nice white coat, but the sleeves are much too long. ;)
[03:53] <igc> speaking of food, lunch for me :-)
[03:53] <mneptok> could you loosen my restraints a little on the way out?
[04:18] <eMxyzptlk> hey guys, is there anything similar to darcs "push apply-as" feature? I'd like to give read/wrtie ability to users but not manually only with bzr
[04:30] <bob2> you can give them ssh access such that they can only run bzr
[04:36] <poolie> igc: thanks very much for the doc review
[04:37] <igc> poolie: np
[04:37] <igc> poolie: the real test will be jam using it on Friday, of course
[04:40] <lifeless> mneptok: we love you just the way you are....
[04:49] <eMxyzptlk> bob2, yea this is possible by specifying COMMAND before the ssh public key, but I'd like them to have ssh access but not enough to manually alter the repositories..
[04:56] <Peng> Um.
[04:56] <Peng> ubotu?
[05:01] <rockstar_> eMxyzptlk, so, no write access?
[05:02] <MattCampbell> Peng: Looks like it's ubottu now, if that matters.
[05:03] <eMxyzptlk> rockstar_, no they have right access, but I'd like it to be using sudo to another user who has write access, this way they'd have write access but not using the shell... it's similar to how darcs --apply-as works
[05:03] <bob2> that doesn't sound any different to ssh command= keys
[05:04] <eMxyzptlk> bob2, it does, coz if I specify command= keys then the user won't have normal SSH access
[05:04] <rockstar_> eMxyzptlk, well, you'd probably need two different accounts.
[05:05] <eMxyzptlk> rockstar_, hmmmm adding the commad= keys to that account ? sounds about right, except the users won't be able to update the public ssh key by themself... sounds like I need to write a wrapper to emulate apply-as behaviour
[05:06] <eMxyzptlk> rockstar_, how launhpad do it? they create a specific unix group for each project and add the allowed users to it ?
[05:07] <MattCampbell> Launchpad apparently has a custom SSH server (based on Twisted I think).
[05:07] <eMxyzptlk> Oh ok
[05:08]  * rockstar_ nods
[05:09] <eMxyzptlk> ok thx guys, I'll see what can I do, one last thing, is there any objective comparisation between Darcs and bazaar ? I'm currently using darcs and considering switching to bazaar just checking it out
[05:13] <Peng> ubottu: ping
[05:14] <Peng> I don't think it's announcing bugs though.
[05:15] <MattCampbell> I wonder why it was renamed, anyway.  Were people confused about how to pronounce ubotu?
[05:16] <nick125> u-bot-u...I don
[05:16] <nick125> 't see how it would be hard to pronouce
[05:18] <MattCampbell> Maybe a text-to-speech user got tired of hearing "u-bo-tu".  Since my job consists mostly of developing software for blind users (thus I use TTS a lot), that was actually my first guess.
[05:19] <Peng> I'm assuming it's a temporary nick. Like, if "ubotu" is already being used.
[05:20] <MattCampbell> nah, there's no ubotu online.
[05:20] <MattCampbell> Anyway, it's not important; I was just curious.
[05:20] <Peng> ubotu may have been online when ubottu connected, and it may not change its nick back when it becomes available.
[05:40] <poolie> i believe the original admin/owner of ubotu took it down and this is a different service as a replacement
[05:45] <MattCampbell> Ah, I figured a bot like that would have to be developed and run by Canonical, to integrate with Launchpad.
[05:47] <mneptok> bug 1
[05:47] <mneptok> ubottu?
[05:48] <mneptok> thank you, you clanking pile of clattering bolts.

[05:52] <Peng> Augh, that bug has 658 comments.
[05:52]  * Peng apologizes to Firefox.
[06:02] <mwhudson> i get mail every time someone comments on that bug :(
[06:05] <sili> hello. one of my employees borked a branch. he was in /devel and issued "bzr branch bzr://localhost/bug/10". it was supposed to be "bzr branch bzr://localhost/devel bzr://localhost/bug/10". how can I remove or otherwise fix this? I have no idea what happened, but I can't bzr remove or remove-branch that directory or anything. if I do a checkout and try to merge /devel into it, it tells me that my tree is out of date.
[06:05] <sili> bzr update just removes all the files I merged
[06:06] <sili> it's strange and I just want to kill that directory to start over. any suggestions?
[06:06] <lifeless> rm -rf 10 ?
[06:06] <sili> lifeless: is it that simple/
[06:07] <lifeless> ' bzr branch URL' creates basename(URL) locally
[06:07] <lifeless> so it should be, yes.
[06:07] <sili> there is some kind of "10" directory in the repository though
[06:09] <lifeless> what does bzr info 10 show ?
[06:09] <sili> from from the working dir?
[06:09] <lifeless> well, wherever your 10 is
[06:10] <sili> from the repo dir: Shared repository (format: pack-0.92) Location: shared repository: /....
[06:11] <lifeless> does it list the branch root as 10 ?
[06:12] <sili> oh, it also shows "respository branch: 10"
[06:13] <lifeless> sounds like 10 is a branch
[06:13] <lifeless> ls -l 10 will list a .bzr directory if it is
[06:13] <lifeless> andyou can just rm -rf branches to remove them; use bzr log 10 to see whats in it
[06:14] <sili> it does, but there's no files. trying to merge /devel into it makes crazy things happen
[06:14] <sili> I see
[06:14] <sili> I'll try to move it out of the way in case I need to put it back
[06:19] <sili> lifeless: seems to work. thanks
[06:34] <vila> lifeless: reagrding strace tests, what about running them in their own process (i.e. spawing a python process that will then invoke strace on itself) ? This a bit ugly but we can use that as an *interim* solution until either strace is fixed or all the other conflicting tests are :-/
[06:37] <lifeless> uhm
[06:37] <lifeless> how many conflicting tests are there (have you tried my 2-liner suggestion ?)
[06:41] <vila> see my mail, 1089 tests are leaking threads
[06:42] <vila> the mail includes the simplest patch I could think of so you can try for yourself for more details
[06:42] <LaserJock> is there a way to like compress or compact a .bzr?
[06:42] <bob2> there's 'bzr pack', but it happens every now and then automatically
[06:43] <bob2> and is only for pack formats
[06:44] <LaserJock> argg
[06:44] <LaserJock> bzr pack almost doubled the size of my .bzr :/
[06:48] <LaserJock> why on earth would it do that?
[06:49] <bob2> .bzr/repository/obsolete_packs
[06:50] <LaserJock> ah
[06:50] <LaserJock> what are those?
[06:52] <lifeless> insurance
[06:52] <lifeless> against NFS particularly, but any file system in general
[06:52] <lifeless> future commits will clean them out automatically
[06:53] <vila> lifeless: I forgot to mention in my mail: AIUI, the problem is that strace is not cleaning up properly when receiving SIGQUIT (and neither when receiving SIGINT or SIGTERM, so we're doomed so far), that's why I consider it the real culprit.
[06:53] <lifeless> (as will pull)
[06:53] <lifeless> vila: if we can file a genuine bug on strace that would be a good thing
[06:53] <vila> #103133
[06:53] <vila> bug #103133
[06:55] <LaserJock> lifeless: do you know of anybody who's tried to do benchmarking on using bzr on the linux tree?
[06:56] <vila> lifeless: we were bitten by a slight variation of that bug (since we don't use -f anymore), but I'm pretty sure it's the same root cause
[06:59] <lifeless> LaserJock: yes
[07:00] <lifeless> LaserJock: I am pretty sure ian does, and I have during various performance work
[07:05] <berto-> i'm running bzr push sftp://[...] and it's taking *forever* on a new branch that only has 10 revisions.  is there any way to speed it up?
[07:08] <spiv> berto-: are you using the current branch & repository format (pack-0.92)?
[07:08] <berto-> spiv: yes.
[07:09] <spiv> berto-: older formats could be very slow with pushing/pulling branches that contain many files (even if there were few revisions)
[07:09] <spiv> berto-: hmm.  And the remote side is in that format too?  How big is the repository?
[07:09] <berto-> spiv: i just downloaded bzr two days ago, then made a branch of the dev tree, then ran make to compile stuff.  I presume i'm running the fastest bzr available.
[07:10] <berto-> spiv: it's a standalone tree weighing in at 1.2M
[07:10] <berto-> spiv: as reported by du -sh .bzr
[07:10] <spiv> Ok.  ("bzr info -v" can tell you the size too, btw.)
[07:11] <spiv> That does seem unusually slow.
[07:11] <berto-> spiv: i decided to try out bzr by versioning my dotfiles (.bashrc, .bash_profile, .emacs, etc.)  by any chance is it doing a directory listing of the entire contents of my home directory before doing a push?
[07:11] <spiv> No, I don't think so.
[07:12] <spiv> You could try doing "bzr -Dhpss push bzr+ssh://[...]"
[07:12] <berto-> Repository:
[07:12] <berto->         10 revisions
[07:12] <berto->        905 KiB
[07:12] <spiv> And then looking in the ~/.bzr.log file to see where it's spending its time.
[07:12] <spiv> Right, that's pretty small.  With packs, pushing that over the network shouldn't take long.
[07:12] <spiv> (unless you're on dialup!)
[07:12] <spiv> So something strange is going on here.
[07:13] <james_w> hi spiv
[07:13] <berto-> bzr command not found on the other end.  is there a way i can specify the full path to bzr ?
[07:13] <james_w> does autopacking kick in on push?
[07:13] <james_w> berto-: BZR_REMOTE_PATH I think
[07:14] <bob2> (set that env var on the local side)
[07:14] <spiv> james_w: yes
[07:14] <berto-> bzrlib not in PYTHONPATH ... i thought bzr was able to autodetermine where that thing was based on its install location?
[07:15] <spiv> But even autopacking 1M of data over the network shouldn't take "forever".
[07:15] <james_w> berto-: if it is co-located yes, but not if it is a system-wide install
[07:16] <berto-> "forever" quantified was on the order of ~1.5 minutes.  that really seems way too slow.
[07:16] <james_w> spiv: yeah, but would it be uploading all the data, then downloading it all, repacking, and pushing it back? Is there a fast-path for this?
[07:16] <spiv> i.e. you can make a checkout of bzr.dev, and point "BZR_REMOTE_PATH" to that, and it will work
[07:16] <berto-> running bzr -Dhpss push bzr+ssh://[...] on a tree that didn't have to push anything took 7.2 seconds.
[07:16] <spiv> james_w: not yet, that's on the "make push fast" hit list.
[07:17] <james_w> berto-: ~/.bzr.log may have something interesting
[07:17] <berto-> spiv: that's exactly what i did.  ;)
[07:17] <spiv> james_w: it really ought to a) happen entirely server-side when using smart protocols, b) let the user known what's going on otherwise
[07:18] <spiv> My best guess atm is that an autopack happened, which happens from time to time.
[07:18] <berto-> spiv: is a "smart" protocol one that can run bzr on the "other end" ?  seems like that is what bzr+ssh does.
[07:18] <spiv> berto-: right
[07:18] <berto-> i'll stick to that as it seems "smarter"  ;)
[07:18] <spiv> But ~1.5 minutes still seems a bit slow to me, even when autopacking.
[07:18] <berto-> i'm going to see if i can make a couple more revs and try pushing with bzr+ssh
[07:19] <berto-> i want to see the speed difference.
[07:19] <spiv> berto-: if you don't mind, please keep using -Dhpss for a little while, so if you do see the slowdown the logs will have lots of details about the network conversation
[07:19] <berto-> spiv: will do.
[07:20] <berto-> i'm adding an alias so i don't forget.
[07:20] <spiv> I'm currently doing some infrastructural work on the smart protocol stuff, but once that's out of the way I'll be specifically working on speeding up push with the smart protocol.
[07:21] <spiv> There's lots of stuff we can do to make it faster :)
[07:21] <berto-> oh, is there some way to add "auto paging" to bzr commands, e.g. "bzr log" automatically uses "less" ?
[07:21] <jamesh> spiv: you could buy everyone faster internet connections
[07:21] <jamesh> that'd help
[07:22] <spiv> jamesh: if I could buy a faster speed of light, to reduce intercontinental network latency, that'd definitely help
[07:22] <jamesh> spiv: we could always switch to least-distance cabling
[07:23] <jamesh> there are shorter paths from australia to england than a great circle
[07:23] <spiv> jamesh: dig holes to China, that sort of thing?
[07:23] <jamesh> just use a straight line
[07:23] <RAOF> jamesh: Do you suggest burrowing directly through the mantle?
[07:24] <RAOF> You could build a tube system from the Thursday Next novels while you're at it!
[07:24] <jamesh> spiv: well, a hole to china would only get you part of the way there
[07:28] <berto-> pushing up a new 12k file using bzr+ssh took ~11 seconds.  still a bit slow, but much better.  as a comparison, using scp to copy the file took 4.8 seconds.
[07:30] <spiv> berto-: well, bzr has to do more work to determine exactly which data needs to be transferred, and it needs to transfer metadata as well as just the file contents
[07:30] <spiv> berto-: so it's not a totally fair fight :)
[07:31] <berto-> spiv: i totally understand.  i should have cleared things up.  i wanted to "normalize" the time, i.e. subtract 4.8 to get the "bzr working time"
[07:31] <spiv> berto-: take a look in ~/.bzr.log for some idea of what bzr currently does
[07:31] <berto-> so, roughly speaking, bzr took ~6 seconds to do its job.  is that "fast enough" ... dunno.
[07:31] <berto-> spiv: i'm actually looking at it as we speak.  :)
[07:35] <berto-> is it okay to paste a few lines here or is there a pastebin?
[07:35] <spiv> pastebins preferred.
[07:35] <spiv> pastebin.com or rafb.net/paste
[07:36] <berto-> http://dpaste.com/48642/
[07:38] <berto-> bzr is fast figuring out its setup (i.e. i'm going to be transporting over ssh).  i suppose it took up to 6.2 seconds to transfer the file, then 5 to do its housekeeping (merge + other stuff)?
[07:39] <spiv> berto-: if you use "bzr -Dhpss ..." the log file will contain more details than that
[07:40] <berto-> spiv: on which end?  [berto@70-12-91-0][530]$ alias bzr
[07:40] <berto-> alias bzr='bzr -Dhpss'
[07:41] <berto-> hmm, wonder if the time command doesn't use my alias ... doh!
[07:43] <spiv> berto-: d'oh
[08:05] <lifeless> spiv: that error with the log - an exception in a cleanup trigers it I think
[08:08] <spiv> lifeless: huh, interesting
[08:46] <lifeless> yay, down to 3 failing tests
[08:46] <lifeless> thats all folks
[08:53]  * igc dinner
[10:16] <berto-> nite, all.
[14:26] <renton> hello
[14:27] <renton> does anyone know plans for tortoisebzr? it seems to have been idle for several months now
[14:29] <hmeland> There has been some mailing list traffic on design considerations.
[14:29] <hmeland> I haven't followed it too closely, but I think there is a merge request for a design document (possibly already merged).
[14:32] <renton> okay, thanks
[14:34] <renton> btw, couldn't a lot be shared between tortoisehg and tortoisebzr
[14:42] <jam> morning all
[14:59] <beuno> mornin' jam
[14:59] <jam> morning beuno
[16:03] <igc> night all
[16:11] <Winterstream> I'd like my repo to forget some recent commits. Am I right that revert doesn't rewind the repo history? If so, how can I do it?
[16:11] <LeoNerd> revert just modifies the working copy
[16:14] <jamesh> Winterstream: "bzr uncommit" will undo commits
[16:14] <fullermd> You can also use pull.
[16:14] <LeoNerd> Will only remove the top one(s) though... you can't remove something from the middle by doing that
[16:14] <jamesh> it won't make everyone else's computers forget about them if you've published them though.
[16:14] <fullermd> (of course, neither will make the _repo_ forget.  They just make the branch forget that those revs are its.)
[16:14] <Winterstream> Ah. I'm blind. Thanks jamesh & fullermd.
[19:06] <Vadi> Where can I find documentation on the python get_config() method? Best place I found is here (http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.remote.RemoteBranch.html#get_config), but it's not exactly helpful. I need to see what options besides user_email() can I get out of it :/
[19:07] <beuno> Vadi, I think looking at the code in that specific bit should be fairly straight forward
[19:08] <Vadi> Sorry, where can I find the code?
[19:08] <Vadi> I was having enough trouble navigating to that link hehe
[19:09] <beuno> Vadi, you can get the lastest with: bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
[19:27] <Vadi> ﻿beuno: This is a bit beyond me, but would ".get_config().get_nickname()" return the commiters name? (instead of user_email() which returns their email)
[19:29] <beuno> Vadi, I believe it's .username()
[19:33] <Vadi> Thank you
[19:33] <beuno> you're welcome
[19:39] <statik> dumb question, how do I garbage collect old revisions from a shared repo, say after I do a bunch of uncommits?
[19:40] <beuno> shouldn't uncommit remove them from the shared repo?   (I have no idea how it works though)
[19:41] <fullermd> No, uncommit doesn't remove anything, it just moves the branch head.
[19:41] <fullermd> There isn't a gc command.  Closest is making a new repo, branching everything into it, and blowing away the old one.
[19:41] <statik> fullermd: ta
[19:41] <statik> that is good enough
[19:42] <beuno> hrm, that doesn't sound like a very long-term usage plan
[19:43] <beuno> s/very/very good
[19:43] <gnomefreak> is there docs on bzr-svn?
[19:44] <beuno> gnomefreak, I found these: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#id24 and  http://samba.org/~jelmer/bzr-svn/FAQ.html
[19:44] <gnomefreak> beuno: thanks
[19:45] <beuno> gnomefreak, np, sorry to make you bounce over here  :p
[19:46] <gnomefreak> beuno: its ok i have this channel on alias its just a hectic day
[22:40] <demod> hi
[22:42] <acemo> hey demod
[22:45] <mw> is there an easy way to make "bzr status" not show all the files that bzr doesn't know about (Makefiles, etc)
[22:46] <bob2> -V
[22:46] <mw> yeah, just worked it out :)
[22:46] <bob2> or 'bzr ignore Makefile' etc to add them to .bzrignore
[22:46] <ferringb> any trac-bzr users around by chance?
[22:46] <mw> yeah, i know about ignore, but it's sort of a nuclear option
[22:47]  * ferringb is wondering about their experience/opinions on it
[22:47] <mw> some big projects mostly have generated makefiles, but a few hardcoded ones from other packages imported into their tree
[22:47] <acemo> bob2: great idea :)
[22:47] <bob2> mw: ah, right (but note you can still add the ones you specifically want)
[22:48] <mw> bob2: too many to do that
[22:48] <mw> bob2: i'm working with firefox source, and there are 900 of them in my working directory
[22:50] <acemo> bzr ignore Thumbs.db would ignore all Thumbs.db files in all folders or only in the current folder?
[22:50] <bob2> all
[22:50] <mw> hmmm, is there a way to get a result analogous to bzr status -V with bzr commit?  bzr commit --show-diffs results in a pretty unwieldy buffer
[22:50] <acemo> yay no more ugly microsoft Thumbs.db files
[22:52] <bob2> --show-diffs will only show diffs for files listed by status -V (that is, versioned files)
[22:54] <mw> bob2: right.  but the buffer i get shows two changed files, almost 1400 files bzr doesn't know about, and then the actual diffs
[22:55] <mw> bob2: well... plus space above that where i'll write my commit msg
[22:55] <fullermd> Well, see?  If you'd quit writing commit messages...
[22:56] <bob2> ah, --show-diffs does list unknown files, that is annoying
[22:56] <mw> and it's --show-diff
[22:56] <mw> i always screw that up ;)
[23:14] <Peng> ubottu: bug 83039
[23:36] <poolie> hello
[23:55] <igc> morning
[23:58] <poolie> hello igc
[23:59] <lifeless> hi poolie