[00:16] <poolie> hi spiv
[00:17] <poolie> and riddell
[00:59] <dash> okay so i'm still getting 'checksum mismatch' when doing a new branch from svn  into a standalone branch
[01:10] <poolie> i think its clashing with your bzr-svn cache
[01:10] <poolie> which might be in ~/.bazaar/
[01:10] <poolie> you could try savinga copy and moving it away
[02:04] <ptressel> I'm trying to extract a working tree from a branch for which I have only the .bzr directory. (Background is that I did a bzr branch, but that failed just at the end when it could not create a symlink on windows. Looks like the repo is intact though.) I cd'd to the branch directory where .bzr was, and did "bzr checkout". That got Error 183, file exists, on the .bzr directory itself.
[02:04] <poolie> hm
[02:05] <ptressel> I'd like to redo the checkout under cygwin, which can create symlinks, but the above error is stopping that.
[02:05] <poolie> try 'bzr checkout broken other'  - ie into a different directory
[02:05] <ptressel> Is there something wrong with my syntax for "bzr checkout"?
[02:05] <ptressel> Ah, ok.
[02:05] <ptressel> And then move the files back in?
[02:07] <ptressel> Almost worked...  That didn't get the "file exists" error, but...it still couldn't make the symlink.
[02:08] <ptressel> I thought that was the usual workaround for symlinks on Windows.
[02:08] <poolie> oh, it failed under cygwin?
[02:08] <ptressel> Right
[02:08] <poolie> :/
[02:08] <ptressel> Odd.
[02:09] <ptressel> I've asked the person who put the symlink in to take it back out, but it might be a while...
[02:09] <ptressel> :(
[02:09] <ptressel> cygwin can create symlinks -- just checked.
[02:10] <ptressel> Hmmm, I wonder if the fix that added the "unable to create symlink" error message is checking for attempted symlink creation *before* trying it...
[02:11] <ptressel> The workaround of using cygwin was mentioned before that fix.  https://bugs.launchpad.net/bzr/+bug/81689
[03:07] <CarlFK> after bzr branch foo, how do I back up a rev? (need to figure out which of the last 5 - 10 commits broke it)
[03:11] <ptressel> CarlFK, if this is a throwaway branch and you've got the real code saved elsewhere, you can back out each change in turn by doing "bzr uncommit" then "bzr revert".
[03:12] <CarlFK> ptressel: it is, thanksl
[03:12] <ptressel> Welcome!
[03:12] <spiv> CarlFK: you can use "bzr revert -r REV" to revert just the files to the state at a particular rev
[03:12] <spiv> CarlFK: and then plain "bzr revert" to restore the files back to the current revision
[03:13] <ptressel> So that doesn't affect anything but the working tree?
[03:14] <ptressel> Safer... ;-)
[03:14] <spiv> Right.
[03:16] <ptressel> So one could go backwards down the revisions with "bzr revert -r -1", "bzr revert -r -2", etc.
[05:37] <lifeless> .
[05:38] <elmo> does anyone have an example of a plugin that extends or overrides a builtin command?
[05:39] <elmo> the docs for 'extending an existing command' are 'TO BE DOCUMENTED.'
[05:40] <lifeless> loom overrides status
[05:41] <elmo> lifeless: ta
[05:41] <lifeless> loom is also one of the older plugins; its stule may be a little... idiosyncratic
[05:44] <elmo> is there a concept of repository specific plugins?
[05:44] <elmo> i.e. any user of the (shared) repository runs the plugins
[05:44] <elmo> I can see why there wouldn't be ... ;-)
[05:44] <lifeless> no, security considerations
[05:44] <lifeless> there is the ability for a plugin to do nothing on repositories it doesn't know about
[05:44] <elmo> bah humbug
[05:44] <lifeless> e.g. in the repo config you provide the config for the plugin
[05:44] <lifeless> and you install the plugin globally for all users.
[05:45] <elmo> oh, that'd work
[05:45] <lifeless> the plugin then checks for a config and if none found on a repo does nothing.
[05:46] <elmo> lifeless: can I get bzr to tell me the default plugin paths or shall I UTSL?
[05:47] <lifeless> gmm, I thought it was in bzr --version
[05:47] <lifeless> but no
[05:47] <lifeless> ah
[05:48] <lifeless> check in ~/.bzr.log
[05:48] <elmo> lifeless: aha, ta
[05:49] <lifeless> basically your plugin becomes a submodule of bzr
[05:49] <lifeless> see the setup.py for loom etc
[07:04] <marvin2> Hi, could someone please explain how "bzr split" works?
[07:04] <marvin2> I need to create a branch out of a directory in an existing tree.
[07:05] <marvin2> Whatever changes I commit to files inside that directory should be stored only in that directory's own repo - is this how it works?
[08:50] <jam> morning all
[08:50] <Merwin> Hum, is a way to do a "lightweight" checkout from a lp repo? Downloadin lp:openerp-addons is around 500Mo wheras I ust want to "get the latest version", not especially all the commits...
[08:58] <spiv> Merwin: "bzr branch --stacked", except there's bugs that make that much slower (and transfer more bytes) than it needs toi
[08:58]  * spiv goes to pick up his kid
[09:10] <Riddell> hola
[09:24] <gour> jelmer: hello, any hint about this one: http://pastebin.com/4Wp3nr3H
[09:33] <vila> English experts, what means 'not wild' in 'Not wild this is added for all tests regardless of the flags.' ?
[09:34] <jelmer> vila: I think it's short for "I'm not wild about X" (I'm not enthusiastic about it)
[09:35] <vila> jelmer: makes sense, thanks
[09:35] <jelmer> gour: It means bzr-git found an error trying to create an object from scratch again - the resulting object didn't match the sha it expected
[09:36] <jelmer> gour: bzr-git is now a fair bit more pedantic about it, older versions got it wrong in some situations
[10:12] <spiv> vila: FWIW, I agree with jelmer about "not wild"
[10:13] <vila> spiv: great, yeah, made sense, never encountered that usage before and I was wondering if it was a typo...
[10:14] <vila> I thank mgz (and you guys ;) for teaching me more sophisticated English ;)
[10:18] <fullermd> Nah, if it were a typo, you'd have intuitively understood it   ;p
[10:47] <Riddell> how many hours does it take to do a branch of emacs?
[10:54] <jelmer> Riddell, jam probably has some experience with that..
[10:54] <jelmer> it used to take quite a while, I'm not sure if that's changed with 2.4
[11:03] <gour> jelmer: so, there is no workaround to update the repo?
[11:07] <jelmer> gour: no, you'll have to create a fresh clone
[11:12] <vila> fullermd: hehe
[11:13] <gour> jelmer: ok. i did it
[11:18] <jam> Riddell: from gnu or from lp?
[11:18] <jam> AIUI it is quite a bit faster from lp
[11:45] <nooga> hi
[11:45] <jelmer> hi nooga
[11:45] <lifeless> vila: subunit-sum could go in subunit ;)
[11:45] <nooga> i've created new project on my laptop and i'd like my friend to co-work with me via local network
[11:46] <nooga> how do i allow him to access my branch and make changes?
[11:47] <jelmer> nooga: if you give him ssh access, he can use bzr to make a checkout if you both have write access to the bzr branch
[11:47] <vila> lifeless: thanks, that's the middle-term plan, I don't want to wait for it to be released to be able to use it (and there may be some tweaks required to land in subunit which may break the way I intend to use it)
[11:48] <nooga> so i need to make a user account for him in my system and let him log in via ssh
[11:49] <jelmer> nooga: just sftp access or the ability to run the bzr command should be sufficient
[11:49] <vila> lifeless: one concern raised by jam (for example) is to use a single 'counter' dict detail (including all counters) in the subunit stream instead of one detail per counter, what's your feedback on that ?
[11:50] <jelmer> nooga: After that, he should be able to run something like "bzr co sftp://yourlaptop/path/to/bzr/dir" or "bzr co bzr+ssh://yourlaptop/path/to/bzr/dir"
[14:25] <vila> jam: cicp-add approved, can you land it ? I'd like to include it in 2.4b4
[14:25] <vila> jam: oh, forgot to mention in th review: line too long :-}
[14:26] <jam> vila: copied from a line that was too long, but I can try to fix
[14:26] <vila> hehe
[14:47] <jam> vila: re-wrapped, and sent to pqm, you just have to wait for the backlog (and hope there aren't NEWS conflicts)
[14:47] <jam> in the test suite now, I guess
[14:47] <vila> jam: yeah, so no news conflicts
[15:03] <psynaptic> hey
[15:03] <psynaptic> I have done it again
[15:04] <psynaptic> merged trunk into my working copy with changes
[15:04] <psynaptic> is there an easy way to fix it or do I have to manually edit each file?
[15:04] <psynaptic> I know I could shelve each hunk, but that assumes they are not mixed changes
[15:38] <jam> vila: landed
[15:39] <vila> jam: yup, saw it, I'm having an issue with an added test for selftest-config-stats I can't reproduce locally though :-/
[15:39] <jam> sorry to hear that, bbiab
[15:39] <vila> jelmer: do you have other landings planned ?
[15:42] <vila> ha crap, I'm pretty sure this is an outdated subunit/testtools combo on pqm :-/
[15:43] <jelmer> vila: nope, nothing important in the queue for bzr.dev
[15:44] <vila> jelmer: ok, I'll cut 2.4.b4 as  soon as I sort this mess out, better if pqm is free for that :0
[15:51] <psynaptic> git rules
[16:32] <Riddell> basic python question, I'm running a for loop over a method which returns names, what's a good way to count the number of times each name is returned?
[16:38] <vila> Riddell: without more context, I'd go with a dict of names -> number of occurrences
[16:39] <Riddell> vila: but if I do mydict[name] += 1 then it fails on the first time because mydict[name] doesn't exist yet
[16:40] <vila> yeah, that sucks :) except KeyError: mydict[name] = 1
[16:41] <james_w> .setdefault()
[16:41] <james_w> mydict.setdefault(name, 0)
[16:41] <james_w> mydict[name] += 1
[16:41] <james_w> or use defaultdict if it's in the oldest Python you support
[16:42] <vila> ha right, I knew it somewhere in the back of my head but it refused to pop up ;)
[16:42] <james_w> that's what I'd do at least
[16:44] <Riddell> groovy, thanks james_w, vila
[17:10] <Noldorin> can someone please clarify the differnce between a repository, branch, and working tree? are these meanings universal between VCSs?
[17:13] <maxb> They are roughly universal in core concepts, but they often have rather different UI
[17:13] <maxb> A repository is a place in which history is stored on disk.
[17:13] <maxb> A branch is a representation of an ongoing line of development
[17:14] <maxb> A working tree is an area on disk where new revisions are prepared before committing
[17:14] <maxb> Bazaar repositories are *really* only about storage
[17:15] <maxb> Mercurial and Git repositories also behave as a container for a set of branches - whereas Bazaar's container for a set of branches is "Your filesystem"
[18:09] <amdahlj> Hi, does anyone know if it is possible to call the visual diff viewer in bazaar explorer from command line?
[18:10] <amdahlj> rather than the standard command line output you'd get just by calling bzr diff
[18:21] <amdahlj> does anyone know if it is possible to call the visual diff viewer in bazaar explorer from command line?
[18:27] <Buttons840> if i init-repository with --no-trees   then the branches will not have working trees, but i'm not sure what this means?
[18:30] <amdahlj> pretty quiet in here so far buttons, I'm taking a look at your question though
[18:32] <Buttons840> well, basically my question is just "what is a working tree"   i've read the docs and help but i'm not understanding
[18:32] <Buttons840> just a conceptual question
[18:32] <jelmer> amdahlj, I think you're looking for "bzr qdiff"
[18:32] <amdahlj> thanks jelmer
[18:32] <amdahlj> will try it out
[18:32] <amdahlj> Yes, you are right jelmer, thank you very much
[18:33] <jelmer> Buttons840, a working tree is an area with the actual files in it so you can prepare a commit - I think somebody else explained it well earlier:
[18:33] <jelmer>  A repository is a place in which history is stored on disk.
[18:33] <jelmer>  A branch is a representation of an ongoing line of development
[18:33] <jelmer>  A working tree is an area on disk where new revisions are prepared before committing
[18:33] <jelmer> (from maxb)
[18:34] <jelmer> if you want to be able to edit files, you need a working tree
[18:34] <Buttons840> jelmer: so how is --no-trees even possible; that's like saying "don't allow changes to repository" or "don't allow changes to the files on the disk"   at least, that's my view
[18:35] <jelmer> Buttons840: You can still push revisions into or pull revisions out of a branch without a working tree
[18:36] <jelmer> Buttons840: --no-trees is useful if you have a server where your history is stored, but where you don't do direct editing
[18:37] <Buttons840> so what information is stored in a working tree? i though no information was stored until i commit?
[18:37] <Buttons840> thought*
[18:38] <jelmer> Buttons840: no history exists until you commit
[18:38] <jelmer> Buttons840, the files in the working tree that have been added with "bzr add" are in the working tree
[18:38] <jelmer> Buttons840, say you want to store a file named "README" in a bzr branch
[18:39] <jelmer> Buttons840, only in a working tree would that file actually exist in the file system so that you can open it with your editor
[18:41] <Buttons840> ok, that makes more sense
[18:41] <Buttons840> thanks
[18:45] <Buttons840> are there branch naming conventions i should conern myself with?
[18:47] <jelmer> Buttons840: not really
[18:53] <MarkAtwood> how come running "bzr log -r-3..-1 lp:myproject" downloads half a meg, slowly, from launchpad?
[18:54] <jelmer> MarkAtwood: it's not a very well optimized code path,
[18:54] <MarkAtwood> does it pull down the entire changelog over the network, and then just display the 3 most recent entries?
[18:54] <jelmer> it's also a fair bit better in newer versions of bzr, though still not as quick and efficient as we'd like
[18:55] <jelmer> MarkAtwood: no, it's more efficient than that but it falls back to reading some of the actual files in the repository rather than streaming just those three entries
[18:56] <MarkAtwood> Bazaar (bzr) 2.2.1
[18:56] <MarkAtwood>   Python interpreter: /usr/bin/python 2.7.0
[18:56] <MarkAtwood>   Python standard library: /usr/lib64/python2.7
[18:56] <MarkAtwood>   Platform: Linux-2.6.35.9-64.fc14.x86_64-x86_64-with-fedora-14-Laughlin
[18:56] <MarkAtwood> ok
[18:56] <jelmer> The initial wait of a few seconds for every connection to Launchpad is a bug in Launchpad that jam has been working on
[18:57] <jelmer> the speed will improve further as we implement more calls in the smart server directly
[18:59] <MarkAtwood> ok
[19:00] <MarkAtwood> this is a pattern i use a lot, because i coordinate the merges from suggested merges into lp:drizzle/build then lp:drizzle/staging and then finally lp:drizzle
[19:00] <MarkAtwood> and so im always "peeking" at the top of the log for each of those, to keep track of where I'm at
[19:01] <MarkAtwood> lp:drizzle/build and lp:drizzle/staging are picked up and ground up by our Jenkins array
[20:24] <briandealwis> Hi everybody.  I'm using bzr 2.4b2 & bzr-svn 1.1.0dev.  I'm trying to set up a custom layout for bzr-svn.  The setup is almost like "trunk", where branches are found under branches/ but the actual trunk is in trunk/product.  Adding "branches = branches/*;trunk/product" to my subversion.conf leads to an error when I try 'bzr svn-layout URL': bzr: ERROR: <bzrlib.plugins.svn.remote.SvnRemoteAccess object at 0x12f3bd0> does not support co-located 
[20:26] <briandealwis> I tried wiping out my ~/.bazaar/svn-cache to no avail
[20:28] <jelmer> briandealwis, hi
[20:28] <briandealwis> hi jelmer
[20:28] <jelmer> briandealwis, can you post the full backtrace?
[20:28] <briandealwis> sure, hold on
[20:29] <briandealwis> jelmer: http://pastebin.com/wu9RGZNw
[20:44] <jelmer> briandealwis, is it just "bzr svn-layout" or do other commands give this as well?
[20:46] <briandealwis> Hmm, good question: I hadn't tried.  But trying to branch the trunk seems to work.
[20:47] <briandealwis> jelmer: huh, and 'svn-layout URL/trunk/product' works
[20:47] <briandealwis> as does 'svn-layout URL/branches/<<branch-name>>'
[20:48] <briandealwis> but 'svn-layout URL/branch' or 'URL/trunk' fails
[20:49] <jelmer> briandealwis: Looks like it's just invalid handling of a particular exception at the moment
[20:49] <jelmer> briandealwis: can you file a bug about this?
[20:49] <briandealwis> will do
[20:49] <briandealwis> thanks jelmer
[20:49] <jelmer> thank you :)
[20:54] <santagada> there is really no bzr record/staging?
[20:55] <santagada> I have to shelve everything and then unshelve and commit?
[20:58] <jelmer> santagada: hi
[20:58] <jelmer> santagada: yes
[20:59] <santagada> jelmer: is there any plans to implement something like the hg record extension?
[20:59] <santagada> I just want to filter my commits
[21:00] <jelmer> santagada: What does hg record do?
[21:01] <santagada> jelmer: I think it is mostly the reverse of what shelve do, the same as git interactive commit
[21:03] <santagada> jelmer: it asks if you want to commit each piece of a file/the whole file
[21:04] <santagada> jelmer: very simple and makes me wonder why bzr has only the inverse (shelve)
[21:04] <santagada> well it is useful, if you want to test each patch before commiting
[21:05] <amdahlj> is there an easy way to exclude a particular file from qdiff?
[21:06] <amdahlj> something like -x for commit
[21:07] <jelmer> santagada: I don't think there is anything like that (yet)
[22:43] <poolie> hi all
[22:45] <vila> poolie: hey !
[22:52] <jelmer> 'evening poolie, vila
[22:54] <vila> jelmer: _o/
[23:11] <poolie> vila, thanks for updating all the bugs
[23:12] <poolie> closing the closed ones, i mean
[23:12] <poolie> not just today
[23:12] <vila> poolie: hehe, -w option on check-newsbugs is a treat :)
[23:14] <poolie> is it?
[23:14] <poolie> is that for --write?
[23:14] <poolie> tnhat's cool
[23:14] <vila> --webbrowser
[23:15] <vila> when they are all opened in tabs, it's really easy to update them
[23:15] <poolie> i think we talked at the sprint about systematic release naming
[23:15] <poolie> i think we should
[23:15] <poolie> i noticed openstack are doing this too
[23:15] <vila> really ? I may have missed that one
[23:15] <vila> you mean, giving names to bzr releases ?
[23:18] <poolie> yes
[23:18] <poolie> at the moment the naming's a bit arbitrary
[23:18] <vila> hmm
[23:19] <poolie> i think we talked about matching the letter of the ubuntu release they synchronize with
[23:19] <vila> you're ~2h late for 2.4b4, or are you thinking about the series instead ?
[23:19] <vila> ha, right series then
[23:20] <vila> well, I'd like that too, if only to make references simpler
[23:20] <poolie> the series
[23:21] <poolie> and/or the final release
[23:21] <poolie> i don't think betas need names
[23:22] <vila> yup, nor point releases
[23:23] <poolie> so we need a scheme
[23:23] <poolie> perhaps famous markets in the world
[23:23] <vila> haaa, worth searching a bit
[23:24] <poolie> or islands
[23:24] <poolie> needs something with reasonable coverage of every letter
[23:24] <vila> yup, well, at least the remaining ones ;)
[23:35] <Riddell> what island begins the O?
[23:35] <poolie> Oahu?
[23:36] <poolie> or Old Spitalfields, as a market (according to wp), though the 'Old' is cheating a bit
[23:36] <Riddell> Oronsay
[23:36] <Riddell> I'm not convinced the world has that many famous markets
[23:36] <poolie> there's a lot of Oronsays apparenttly
[23:36] <poolie> yeah, that is a bit of a problem
[23:37] <poolie> using a scottish one would be nice
[23:37] <Riddell> I agree :)
[23:38] <Riddell> Orkney, Outer Hebridies
[23:39] <Riddell> Oigh-Sgeir, could start a trend of hard to pronounce ones :)
[23:41] <jelmer> Riddell, :)
[23:47] <vila> ok, 2.4b4 frozen, uploaded, already fixed ... and babune on its way to turning blue again (including OSX !) leaving only windows as the ugly duckling ;)
[23:48] <vila> that was quite a day (including my elder daughter starting her final exam and generating a lot of stress across the whole family ;)
[23:48] <vila> so, have fun guys and see you tomorrow, well, in a few hours