[00:38] Hi guys/girls, I'm confused as to how to restructure my repository to allow better developer visibility into each other's branches. I have set things up like this: http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch [00:39] If Alice creates a new feature branch in "project/alice/featureA", how can the other developers know that she created such a branch? [00:40] i dont think bzr will tell you, just gotta look or something [00:41] Hm yeah, this is not what I want then. Can you think of an alternate configuration (or some kind of plugin or web interface) that would make feature creation more visible? [00:41] http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html [00:42] Twelf, how do you want them to be told? [00:42] so it seems you just write a simple plugin [00:43] and then do in python however you want them to be notified, email, whatever [00:43] poolie: well, ideally, just by pulling project/alice [00:43] or some bzr command I'm not aware of [00:43] ok i thought you meant you wanted them to be mailed or something [00:44] you could have it branch to their machine by using python right? [00:45] hm, I'm not sure [00:46] I think I am operating under the mistaken assumption that a shared repo enables this sort of functionality [00:49] maybe multi-pull in bzrtools would help [00:51] yes i think that's what you want [00:51] that will soon be built in [00:51] as part of [00:51] https://lists.ubuntu.com/archives/bazaar/2012q1/074217.html [00:51] what does multi pull do [00:52] pulls all the branches from one repository [00:52] even if they are nested ? [00:53] like in that workflow twelf linked, where you have a branch that contains another branch, etc [00:54] in a sub directory? [00:54] i think it only goes down one level [00:54] http://wiki.bazaar.canonical.com/SharedRepositoryLayouts#nested-style-project-branch-sub-branch [00:54] i'm confused on if that workflow ^ means that every folder is its own branch or not, since bzr doesn't support that [00:54] so i think feature1 and feature2 are just folders? [00:55] featureA will be a directory containing a .bzr/branch [00:55] yep, that's what it looks like in my test [00:56] so the top level directory has a 'trunk' folder too (thats not shown)? [00:56] it says its a shared repo and a branch [00:57] I created a shared repo at "project", and then "project/trunk", "project/alice", "project/bob", "project/bob/featureA", etc. [00:58] yeah ok. [00:58] I wonder if bzr_access will be compatible with the new colo stuff. I do need to restrict access for some developers to certain branches [00:58] docs are slightly confusing in that regard, since it doesn't support nested branches (like svn) [00:58] biab [00:58] thanks poolie [07:32] hi all ! [09:12] morning! [09:13] morning mgz ! === yofel_ is now known as yofel [09:55] Hi, it appears that I have hit the bug where pycurl is not verifying the self signed cert. Is there any solution? [09:57] what version of bzr and what platform? [09:59] what you probably want is to install the self signed cert into your system's location for certificates [10:01] mgz: bzr = 2.4; ubuntu: 10.04 LTS [10:03] so, try copying the .pem to /etc/ssl/certs then run update-ca-certificates [10:03] * mgz is just googling this [10:25] Can I see the history of a file if it was previously deleted, then a new file of the same name created? [10:26] yup. [10:26] ...what, you want to know how? :) [10:26] Yes, although how is always the opposite of the way I want. [10:27] mgz: Yes please :-) [10:28] fullermd, please enlighten us. [10:28] A number of commands can take a revision and a filename. IME, they all lookup the fileid from the filename as of that revision, except for the ones where I want it to lookup the filename as of current and backtrack to that rev. [10:29] And I think I meant "except that" there. Dunno. Viri stealing my brainz. [10:29] basically `bzr log -r ` should work [10:30] alternatively you can find the fileid, then use that in some places [10:30] Probably have to dig through logs to find the rev where it was deleted, then do something like `log -r0..$THAT $FILE`. [10:30] Or maybe ..before:$THAT, since in $THAT it's deleted. [10:30] I've wished for the ability to explicitly pass fileid's to things like log/diff/etc a number of times in the past :| [10:32] that might make a few things easier indeed. [10:33] mgz: Thanks, I'll look into it now [10:36] Awesome, thanks folks, I have my old my.cnf back thanks to etckeeper :-) [10:37] good good :) [10:37] hm, dulwich has a copy of the lru_cache module [11:43] hi, I have a conflict I've not been able to resolve: Path conflict: bin/update_bds.OTHER / [11:43] the file is not there, how can I do this? [11:49] libertas: `bzr resolve bin/update_bds.OTHER` probably [11:49] though as it's an OTHER file you may have done something a little wrong during the merge, so I'd double check the diff of changes as well [11:50] it resolved now, strange, I guess I was inside bin/ and it wasn't doing it... [11:50] mgz thank you! [11:51] That probably means that you deleted the file in your branch, and the branch you merged made changes to it. [13:05] okay, first upgrade pain, consolekit hung itself [13:08] Luckily, that never happens to me. At least, I don't think it does. I dunno how I'd know if it did. Or what it is... [13:11] I suspect freebsd saves you from such an 'upgrade' [13:11] Well, as near as I can tell at a glance, it's some internal bit of gnome. Not messing with such a thing also saves me :p [13:26] can anyone recommend an approach to me regarding automatically updating a bug tracker when --fixes is specified on commit? ie should this be done at the repository side, if so how to do this from a push request? [13:27] i'm thinking it must be the repository side so that a public branch name is available === Merwin_ is now known as Merwin [15:39] crisb: trac-bzr might have some way of doing that? [15:40] Jesdisciple: concerning your commit message, if I understood it correctly: an editor pops up, write your message, and save and quit the editor [15:41] crisb: so you can have a hook local when the commit happens, or in some central location that gets pushed to (smart server hook if you use that, or then cron/inotify/something like that) === deryck is now known as deryck[lunch] [17:27] hello sirs. is threads support on python required unconditionally for bzr? [17:28] no. but we use the logging module which imports it. [17:29] dummythreading should be enough [17:29] +_ [17:32] so this logging module can be disabled? simple "bzr init-repository --no-trees " errors w/o threads support [17:34] python should work still provided you have the dummy_threading module [17:34] what's the extact error? [17:34] !pastebin [17:34] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [17:35] http://paste.pocoo.org/raw/548446/ [17:35] i know that i can fix it by adding threads support, i just want to make sure my distro has their dep list correct [17:38] ah, that looks like our fault [17:38] try hacking in something like: [17:38] import dummy_thread [17:38] hi, im trying to branch a package of launchpad and i allways get this error: bzr: ERROR: Revision {package-import@ubuntu.com-20110812122506-zko6c7zfexvyg71q} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))". [17:38] any idea what that means? [17:38] sys.modules['thread'] = dummy_thread [17:49] mgz: i'm no python guy but i hacked these 2 lines into /usr/lib64/python2.7/site-packages/bzrlib/bzrdir.py and it works, is that what you were thinking? [17:49] anywhere will do, it's a global change [17:50] I was thinking of the bzr script, but shows that dummy_thread is enough [17:50] grepping shows we only use thread.get_ident except in the smart server and testing using the smart server [17:51] fome: hi [17:51] fome: I think that can be avoided by disabling the up-to-date-ness check in bzr [17:51] mgz: /usr/bin/bzr is some kind of wrapper script on gentoo, i'll just report this and let our bzr and/or python maintainers decide what to do, thanks [17:53] jelmer: how would i go about that? [17:53] mgz: is this dummy_thread module a kind of "safe fallback" that will use threads when available, or do we need to use it conditionally ONLY when threads are not wanted? [17:54] iamben: I'm not clear from the python documentation on who the onus to do this fallback is, [17:54] fome: set launchpad.packaging_verbosity=False in the configuration [17:54] iamben: I suggest you just require a threaded python [17:54] either every python module that uses either the thread or threading module, [17:55] iamben: pretty much /every/ build of python out there that isn't on tiny embedded systems is threaded. [17:55] or the maintainers of python distributions that build without threading enabled [17:55] i'll just report with a suggestion to force threading, and mention the possibility of dummy_thread [17:57] iff building without thread support is really something we want, then I'd argue this is a bug in the logging module [17:58] well, I think logging actually uses threading, which *does* fall back to dummy_threading correctly [17:58] but thread does not automatically fall back to dummy_threading [17:58] and a few of the smart bits import it just for get_ident (the actual smart server does want to start threads), [17:59] but for some reason we're pulling in enough in bzrdir to import thread in some train from there apparently [18:01] hmm, odd [18:01] anyway, EOD.. time for some lp hacking :) [18:02] that's what I'm guessing from the traceback and grepping around at any rate, I've not actually traced it [18:03] I need to finish bending twisted to my will first... === deryck[lunch] is now known as deryck [18:44] gah, that was a silly error to waste half an hour on [19:02] mgz: twisted? [19:04] don't ask >_< [19:05] the best way I found of debugging this test was waiting the 120 seconds for the timeout [19:05] there was a timeout param on an object that din't actually change the duration [19:23] mgz: d'oh [19:27] I think there are probably cleverer ways of doing lots of these things but I've yet to learn them [19:28] okay, done [19:28] time to head down [19:32] hm, now what [19:38] wgz: should I close a bug as Inv [19:39] alid if work somewhere else has already taking care of it? [20:14] LarstiQ: hm. [20:15] s/taking/taken/ [20:15] in this case that's probably the best option, [20:15] * LarstiQ was looking for a "Not For Us" option [20:15] as we want a record of the bug, but aren't going to be changing how we use os.listdir for this reason [20:16] * LarstiQ nods [20:39] I've noticed that the update-manager branch for lucid is out of date [20:39] Is there something that can be done to fix this?