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