| * fullermd calls it late for lunch. | 00:05 | |
| poolie | markh: if you're around, any idea off hand why getaddrinfo would fail on xp? | 00:09 |
|---|---|---|
| poolie | per https://answers.launchpad.net/bzr/+question/4949 | 00:09 |
| markh | while I look - interesting pre-PEP on DVCS discussing hg and bzr - http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64 | 00:15 |
| markh | poolie: 4949 is about dual-booting ubuntu? | 00:16 |
| poolie | heh | 00:17 |
| poolie | sorry, https://answers.edge.launchpad.net/bzr/+question/49498 | 00:17 |
| markh | so, 10022==WSAEINVAL, so winsock doesn't like one of those params I'd guess | 00:19 |
| markh | although windows seems documented as supporting AI_PASSIVE | 00:20 |
| markh | however, "socket.getaddrinfo('www.google.com', 80, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)[0]" works for me! | 00:26 |
| markh | (in the more general case though, that user probably just needs to be made aware they can just 'push' to some other server - there's no real need to run an actual server on their box) | 00:31 |
| poolie | mm | 00:36 |
| poolie | here it's probably looking up 127.0.0.1:4155 | 00:36 |
| poolie | if she were on debian i'd almost suspect an ipv6-only configuration or something but that seems unlikely here | 00:37 |
| spiv | Today is the last day for PyCon 2009 submissions: http://us.pycon.org/2009/conference/proposals/ | 01:24 |
| Neil | alright, bazaar in, old sources imported with history, trac integrated. Thank you again LarstiQ if you see this. | 01:59 |
| justizin | hiya, i have branched some code from svn, and it is in a rich-root-pack repository for bzr-svn, i want to branch it for use as pure bzr with a more modern storage means, but when pushing to a shared repo, i get an error. is there anything i can do? | 03:22 |
| jelmer | justizin, "pure" bzr? | 03:23 |
| justizin | well, i mean, it uses rich-root-pack because bzr-svn requires that. i don't care about svn compat anymore, because i am abandoning it for this branch / project. seems i can't branch into another storage format.. | 03:24 |
| jelmer | justizin, rich-root-pack is a standard supported bzr format, and will be the default at some point in the future | 03:24 |
| jelmer | it stores more data than the current default, so there's no way to downgrade | 03:25 |
| justizin | oh, really? i was under the impression the current default was more modern.. | 03:25 |
| justizin | okay, well, if it's better, than i'll just roll with it. :) | 03:25 |
| justizin | it would be nice to be able to downgrade, still, but for my purposes, clearly not necessary. | 03:25 |
| jelmer | if you mean the 1.6.1 format, there is a rich-root equivalent of that | 03:25 |
| justizin | yah i guess i should try it with a branch on a machine with newer bzr, i am still on ubuntu LTS with system packages... will be moving our svn / bzr / trac to ibex next weekend or so. | 03:26 |
| justizin | anyway, if rich-root-pack is not a bad format to use for just using bzr, then that's fine, i thought it was some kind of compromise, but i guess it makes sense that it is, well, duh, richer.. ;d | 03:26 |
| justizin | thanks jelmer | 03:26 |
| jelmer | hopefully it'll be the default in the next version | 03:27 |
| justizin | 1.8, or the next in 1.7 series? | 03:27 |
| jelmer | no, more like 1.10 | 03:27 |
| justizin | that is: major / minor ? | 03:27 |
| justizin | ah ok | 03:27 |
| * justizin is so tired of .10 versions, seem to infect our whole python community ;d | 03:28 | |
| justizin | i think zope is working on 2.12 :-P | 03:28 |
| justizin | is there a way to make a copy of a whole shared repository? | 03:39 |
| justizin | as if to branch the whole thing.. | 03:39 |
| jelmer | justizin, I think there may be a plugin that can do that | 03:39 |
| justizin | any idea of keywords i might seek? :) | 03:39 |
| * justizin is so thankful for bzr this year, esp bzr-svn has made unimaginable things possible.. | 03:40 | |
| justizin | i mean, there is svk, but, i dunno, i have a hard time sleeping with a process that depends on perl ;d | 03:40 |
| jelmer | I'm not sure what the name could be | 03:40 |
| justizin | eh i'll sort it later | 03:40 |
| jelmer | Odd_Bloke wrote it, but he's probably asleep atm | 03:40 |
| justizin | i could probably keep it all in one shared repo and share data, but maybe what i really want is like nested shared repos that can be treaated as branches, which i probably shouldn't pontificate on, on a sunday evening. :) | 03:41 |
| justizin | like i took a set of build files, and made them into three sets. then, i decided i wanted to do new work with trunk/head/whatever dependencies, so i want to branch those three sets, which is a shared repo with three branches of one upstream branch.. | 03:42 |
| justizin | right now, i have one deployment config with database config, software install, and app server config, and i want to separate those so that they can use different python installs, or at least not break each other when testing python updates, and for other reasons.. | 03:43 |
| justizin | so, yanno, i figured, make three copies of the deploy config, rip out the unneeded bits of each segment.. | 03:43 |
| justizin | now i want to update all dependencies, and have a merge path.. | 03:43 |
| justizin | probably something i should put some brain and coding time into if i want it. :) | 03:43 |
| jelmer | sorry, I was about to get some sleep | 03:44 |
| justizin | hoping to snag some big contracts which will depend on branching / forking lots of upstream code and reorganizing some.. bzr is so great for that. | 03:44 |
| justizin | no worries jelmer, i ramble. rest your svn-battered mind :) | 03:44 |
| justizin | ciao.. | 03:44 |
| jelmer | :-) ciao | 03:44 |
| justizin | :-P | 03:44 |
| justizin | hey jelmer if you are still around, can you recommend a good nl beer? i have good imports here in SF and get tired of my same old rounds.. :) | 03:45 |
| jelmer | justizin, heh :-) | 03:45 |
| * justizin figures all good programmers have good beer taste | 03:45 | |
| jelmer | justizin, My favorite is "Hertog Jan", it's not too big in the US though I think | 03:45 |
| justizin | hm, i will look around. we certainly aren't a european import city, but we have lots of euro imports.. | 03:46 |
| justizin | i remember when i was in amsterdam, heineken was like budweiser in us | 03:46 |
| justizin | same in hamburg, actually | 03:46 |
| justizin | freakin' lager ;d | 03:46 |
| jelmer | yeah, Heineken is the most generic beer you can get | 03:46 |
| justizin | well, i grew up in texas, before i was 21 heineken was a big step up from budweiser | 03:47 |
| justizin | but i dont think i had any when i went to AMS | 03:47 |
| jelmer | Grolsch is also pretty common but a bit nicer (and probably available in the US) | 03:47 |
| justizin | i think we had guiness at the bull dog | 03:47 |
| justizin | grolsch i think we have at whole foods maybe | 03:47 |
| justizin | i'll try it | 03:47 |
| justizin | also tons of import taps in SF | 03:47 |
| justizin | buddy of mine just left high-end server gig to answer phones for amex top tier folks.. | 03:48 |
| justizin | we have nice microbrew, but import is always nice here and there | 03:48 |
| justizin | anyway, go crash | 03:48 |
| justizin | lol | 03:48 |
| justizin | didnt mean to keep you up | 03:48 |
| justizin | ttyl | 03:48 |
| justizin | oh yah and like "Server gig" i meant beer more than internet :-P | 03:49 |
| poolie_ | spiv, hi, did you decide in the end to work on that bug or to try the repo branch? | 03:59 |
| spiv | poolie_: trying out the repo branch. | 04:02 |
| poolie_ | how is it? | 04:03 |
| spiv | poolie_: so far it looks like there's no network regressions according to my bzr-usertest branch -- once I merge current bzr.dev in. | 04:03 |
| poolie_ | nice | 04:03 |
| poolie_ | btw is there still anything i could review for you wrt usertest? | 04:03 |
| spiv | (Although curiously it appears that maybe initial push gotten slower on high-latency links in bzr.dev vs. the bzr.dev the repo branch was merged up to...) | 04:05 |
| spiv | Hmm, not sure, let me look. | 04:05 |
| spiv | I do miss the "just mail and forget" patch submission that bzr gets via bundle buggy. | 04:06 |
| spiv | poolie_: https://code.edge.launchpad.net/bzr-usertest/+activereviews lists two things that need review, IIUC what the UI is telling me | 04:08 |
| poolie_ | ok | 04:08 |
| poolie_ | :/ i didn't really want to get back into 100% code reviews | 04:08 |
| poolie_ | but i don't want things getting stale either | 04:08 |
| spiv | Well, maybe I should just merge them? | 04:09 |
| poolie_ | i'll have a look after i finish merging back to trunk | 04:09 |
| === poolie_ is now known as poolie | ||
| spiv | poolie: ok. | 04:36 |
| poolie | spiv, all are done now | 05:05 |
| spiv | poolie: thanks | 05:11 |
| Peng_ | Wait, is there a subtree variant of the 1.9 format? | 05:27 |
| igc | spiv, poolie: if it helps, I'm happy to review usertest stuff in the next few days | 05:57 |
| igc | be a nice change from ploughing through my 2000+ emails :-) | 05:57 |
| poolie | hello igc | 05:58 |
| igc | hi poolie | 05:58 |
| lifeless | Peng_: development2-subtrees | 06:17 |
| poolie | spiv, can you send a paragraph or so about what you discovered about the repo branch and networking | 06:36 |
| poolie | if you're still online | 06:36 |
| spiv | Sure. | 06:38 |
| Peng_ | lifeless: Using a development format doesn't sound ideal. | 06:42 |
| Peng_ | Does "bzr pack" optimize how all of the data is ordered? | 06:42 |
| spiv | Peng_: a quick glance at the code suggests that it does | 06:48 |
| Peng_ | thanks | 06:48 |
| lifeless | Peng_: true; OTOH its available in 1.7 and above I think | 07:00 |
| * Peng_ grumbles again about downgrading from subtrees to rich-roots. | 07:03 | |
| vila | hi all | 07:04 |
| igc | hi vila | 07:05 |
| vila | hi Ian ! | 07:06 |
| igc | night all | 07:30 |
| gour | hi, i upgraded my system to python-2.6 and now i get "/home/gour/.bazaar/plugins/search/index.py:22: DeprecationWarning: the md5 module is deprecated; use hashlib instead | 08:49 |
| gour | import md5" warning all the time | 08:49 |
| gour | how to get rid of it? | 08:49 |
| gour | it's, afaik, lifeless's plugin | 08:49 |
| Peng_ | You...ask lifeless to use hashlib instead? :P | 08:54 |
| Peng_ | (Well, try: hashlib and fall back to md5. Anyway..) | 08:54 |
| Peng_ | gour: If you know a bit of Python, it shouldn't be difficult to fix the warnings and send a patch. | 08:56 |
| Peng_ | (I don't mean to sound unhelpful, but not everybody has access to Python 2.6.) | 08:58 |
| gour | Peng_: well, the question is more in line what's the bzr plan in regard of 2.6 support? | 09:00 |
| Peng_ | Oh. | 09:01 |
| Peng_ | A few patches to help Python 2.6 compatibility have been merged. | 09:02 |
| gour | that's nice to hear | 09:03 |
| Peng_ | Or at least proposed.. | 09:03 |
| * gour replaced the calls ==> no warnings any longer | 09:04 | |
| lifeless | poolie: I think I'm calling it a day :P | 09:06 |
| lifeless | Peng_: btw development formats are stable, just not long term supported; so you can get support etc, just not expect to leave the repo unattended for 3 or more releases | 09:06 |
| Peng_ | lifeless: Yeah. Having to remember to keep an eye on my repo is stupid. | 09:08 |
| Peng_ | Eh, sorry. | 09:08 |
| Peng_ | I'm grumpy about the subtree/rich root thing again. :P | 09:09 |
| Peng_ | gour: Yeah, the big Py2.6 patch was merged in bzr.dev r3751. | 09:09 |
| lifeless | Peng_: fair enough, I'm not thrilled either; it is moving slowly | 09:09 |
| lifeless | Peng_: the point of --development is to allow folk that need a fix (e.g. performance/features) to access it before its finalised-forever | 09:09 |
| gour | Peng_: ta for the info | 09:09 |
| Peng_ | I'm not that impatient. | 09:09 |
| Peng_ | I did upgrade a couple repos to --1.9 shortly after it was finalized, but I don't feel like dogfooding much anymore. | 09:10 |
| Peng_ | (Well, maybe a little, when it's safe.) | 09:10 |
| gour | there will be some format-removal in 1.9? | 09:10 |
| Peng_ | Is there anything really difficult about supporting going from subtrees to rich-roots or is it just that nobody's done the work? | 09:12 |
| lifeless | Peng_: dev2-subtrees wouldn't be dogfooding as such, fwiw. Its just a label :). Anyhow .. | 09:15 |
| lifeless | subtrees to rich roots requires checking that no inventory entry is a subtree | 09:15 |
| lifeless | noone has optimised that check | 09:15 |
| lifeless | gour: format removal breaks older clients; we try to keep the list of visible formats short | 09:16 |
| Peng_ | So it isn't difficult to do, it's just difficult to do quickly? | 09:16 |
| lifeless | Peng_: right | 09:16 |
| Peng_ | Or at least nobody has done the work to figure that out yet. | 09:16 |
| gour | lifeless: i understand. it's still, imho, too big | 09:16 |
| Peng_ | lifeless: Where does "bzr branch"ing from subtrees to rich-roots fit in? | 09:17 |
| Peng_ | It works, though it's not super-fast. | 09:17 |
| gour | lifeless: let 'em upgrade or stay with older version. how long you will drag 'em around' | 09:17 |
| gour | ? | 09:17 |
| lifeless | gour: I'm not sure | 09:17 |
| Peng_ | gour: Some truly ancient formats are still supported. | 09:17 |
| lifeless | anyhow, must go | 09:18 |
| gour | Peng_: bzr init (repo) gives too many choices ;) | 09:18 |
| lifeless | tere is a bug about presentation here | 09:18 |
| lifeless | which would reduce the multiplication a lot | 09:18 |
| * lifeless goes | 09:18 | |
| * gour just built r3818 pkg | 09:19 | |
| gour | nice, no more warnings... | 09:22 |
| gour | ahh, there are still some | 09:23 |
| Peng_ | Blaah. | 09:24 |
| * Peng_ converts one of his subtree repos to rich-roots using the init/pull trick, since it only has one branch and is unimportant anyway. | 09:24 | |
| gour | i need to merge two branches without common ancestor, how to do it? | 09:25 |
| gour | i'm trying with bzr -r x branch, but does not work | 09:26 |
| poolie | gour: bzr merge -r 0.. ../other | 09:27 |
| poolie | should do it | 09:27 |
| gour | why -r ancestor:branch did not work? | 09:28 |
| Peng_ | BTW, branching bzr-svn's 0.4 branch from pack-0.92-subtree to 1.9-rich-root took 2 or 3 minutes. Doing it from 1.9-rich-root to 1.9-rich-root took 4.54 seconds, including building the working tree. Nice. | 09:31 |
| gour | Peng_: so, 1.9 adds to the list of formats.. | 09:38 |
| Peng_ | gour: :) | 09:38 |
| gour | the list of formats does not fit on one screen :-/ | 09:39 |
| gour | it's pity if devs do not see it as a problem | 09:40 |
| Peng_ | I'm sure it'd fit with a 2048x1536 monitor and a small font. :) | 09:40 |
| gour | heh, good joke | 09:40 |
| * gour is running 1450x laptop atm | 09:41 | |
| gour | running latest bzr with bzr-svn-0.4.13 gives: bzr: ERROR: Version mismatch | 09:42 |
| Peng_ | gour: Edit the compatibility info in bzr-svn's __init__.py. | 09:43 |
| gour | Peng_: there is some new bzr-svn release around the corner? | 09:44 |
| * Peng_ shrugs | 09:44 | |
| Peng_ | I run bzr.dev and bzr-svn's 0.4 branch. | 09:44 |
| Peng_ | They *are* compatible, but the compatibility checking hasn't been updated. | 09:45 |
| Peng_ | (Well, it has been since 0.4.13 was released.) | 09:45 |
| gour | i see...still, my main problem with bzr-svn is lack of support for svn:externals | 09:45 |
| Peng_ | That won't happen until bzr supports it. | 09:46 |
| gour | stacked branches are not enough? | 09:47 |
| Peng_ | Stacked branches are totally different. | 09:48 |
| gour | err, nested branches? | 09:49 |
| Peng_ | Oh. Yes. I have no idea what state nested branch support is in, so I can't answer that. | 09:50 |
| Peng_ | Anyway, it's not considered production-ready.. | 09:51 |
| gour | ok. that's not so important considering that i can do 'svn up' for those repos where i fetch, but reducing number of formats is definitely more serious issue | 10:01 |
| Peng_ | It's kind of too late now. Backwards compatibility is important. | 10:01 |
| gour | sure it is, but plethora of formats shows something is wrong with bzr-format | 10:02 |
| gour | what do you think about http://rafb.net/p/WGzz9k72.html ? is it for bzr or push-and-update plugin? | 12:00 |
| Verterok | gour: looks like a python 2.6 <-> bzr issue | 12:03 |
| gour | Verterok: ahh, too bad :-/ | 12:04 |
| gour | Verterok: should i submit ticket for it? | 12:05 |
| Peng_ | Uhh | 12:05 |
| Peng_ | Oh, never mind | 12:05 |
| Verterok | gour: that would be ok, but I don't think that 2.6 is a supported version (2.4 and 2.5 are) | 12:06 |
| gour | Verterok: hmm, what do you. 2.6 is default python here :-/ | 12:06 |
| Verterok | gour: please, file the bug. I think there is some work-in-progress (tm) to support it | 12:07 |
| Peng_ | Even if it's not supported now, the only way to support it in the future is to fix the bugs. | 12:07 |
| Peng_ | s/bugs/compatibility issues/ .. | 12:07 |
| gour | ok, i'm going to submit bug report | 12:07 |
| gour | submitted - #293054 | 12:11 |
| Verterok | gour: thanks | 12:16 |
| === mtaylor_ is now known as mtaylor | ||
| jelmer | abentley, ping | 14:06 |
| jelmer | abentley, any eta for bzrtools 1.9? | 14:07 |
| abentley | jelmer: Sure, I'll see about it today. | 14:07 |
| jelmer | james_w, hi | 14:17 |
| james_w | hey jelmer | 14:18 |
| jelmer | james_w: I'm going to do more (sponsored) work on bzr-git | 14:19 |
| james_w | jelmer: great! | 14:20 |
| jelmer | james_w: And I'd like to use your python-git module for that, extending it where necessary | 14:20 |
| james_w | um, sure | 14:20 |
| jelmer | james_w: However, the name is a bit non-unique - what do you think about renaming it ? | 14:20 |
| james_w | let me know if I can help with anything | 14:20 |
| james_w | go ahead, it was just a weekend hack | 14:20 |
| jelmer | thanks :-) | 14:21 |
| jelmer | james_w: Btw, any news on my merge-upstream-branch patch for bzr-builddeb ? | 14:22 |
| jelmer | It doesn't seem to fit well into the new infrastructure, should I adapt it to that? | 14:22 |
| james_w | let me take a look | 14:23 |
| BUGabundo_work | hi | 14:31 |
| BUGabundo_work | can some mailinglist admin moderate my email ? I'm not on the list! | 14:31 |
| james_w | jelmer: my only concern would be the upstream_branch_version() stuff | 14:35 |
| james_w | it looks sane, but it's quite magical | 14:37 |
| jelmer | james_w: I can document it a bit better, perhaps let the user know where we got the version from? | 14:42 |
| james_w | yeah, that might help | 14:42 |
| jelmer | james_w: It's only intended as fallback if the user doesn't specify a version | 14:42 |
| james_w | it looks like it would be doing what the user wants, and this merge-upstream stuff is quite magical anyway | 14:42 |
| jelmer | james_w, I'll see about adding some docs and being a bit more verbose as to where the version comes from | 14:50 |
| jelmer | james_w, what branch should I submit against ? lp:bzr-builddeb or lp:bzr-builddeb/2.0 ? | 14:50 |
| james_w | jelmer: the former please | 14:51 |
| james_w | I'm going to merge the latter in to the former soon, and just keep the latter for any critical bug fixes for Intrepid | 14:51 |
| james_w | thanks for looking at it. I kind of want to think about it some more, but I'm aware that I don't actually do that and it just ends up un-merged, so I'm tempted just to merge it. | 14:52 |
| james_w | jelmer: is https://code.edge.launchpad.net/~jelmer/bzr-builddeb/452130/+merge/1511 fixed? | 15:22 |
| === mm-mysql_ is now known as mm-mysql | ||
| jelmer | james_w, yeah, you've already merged it | 15:24 |
| james_w | cool, thanks | 15:25 |
| jelmer | I've just removed it (took a while to find the button) | 15:29 |
| jam | hi mm-mysql, funny to see you around here :) | 15:40 |
| mm-mysql | :) | 15:40 |
| mm-mysql | I should hang out here more often, we often run into things we'd like to talk to you guys about on my team. | 15:41 |
| mm-mysql | So, are you actually local to where we ran into each other or just visiting? | 15:41 |
| weigon_ | mm-mysql: *doh* :) | 15:42 |
| * mm-mysql waves at weigon | 15:42 | |
| jam | I live about a 15min walk from where we met. So I think that counts as "local" :) | 15:44 |
| jam | what about you | 15:44 |
| mm-mysql | I'm 5 minutes walk from Flossmoor Station...do you drink beer? :) | 15:45 |
| jam | I've been known to have some from time to time. The Brewery there is a nice restaurant. | 15:46 |
| mm-mysql | Well, if you're up for it sometime, we should meet up...even if not for beers. | 15:46 |
| jam | definitely | 15:46 |
| jelmer | james_w, I've pushed an updated version to http://people.samba.org/bzr/jelmer/bzr-builddeb/merge-upstream-branch/ | 15:47 |
| gour | Peng_: bzr's user-manual says: " | 15:48 |
| gour | ERC> | 15:48 |
| james_w | thanks jelmer, looking now | 15:48 |
| gour | Peng_: "Plugins are helpful at feature retirement time as well, e.g. deprecated file formats may one day be removed from the Bazaar core and be made available as a plugin instead." why it is not followed? | 15:48 |
| dissonans | what's the best way to see the history of merges in a repository | 15:49 |
| Peng_ | gour: It would take work, I guess. | 15:49 |
| dissonans | i.e., I want to check which revision I last merged from another repo | 15:49 |
| gour | Peng_: then better remove that sentence from the docs ;) | 15:51 |
| Peng_ | gour: "may one day" doesn't mean it has to be now. ;P | 15:51 |
| awilkins | dissonans: Try qlog in the qbzr plugin | 15:55 |
| dissonans | awilkins: thanks, trying that now | 15:59 |
| dissonans | awilkins: can that tell me the parent revision from the other branch, though? | 16:01 |
| jam | dissonans: you might also try: | 16:02 |
| jam | bzr log -r ancestor:other/branch | 16:02 |
| jam | or | 16:02 |
| jam | bzr missing other/branch | 16:02 |
| jam | depending on what you want | 16:02 |
| mattions | hello | 16:03 |
| mattions | Has the svn plugin been integrated directly in bazaar ? | 16:04 |
| Peng_ | "Integrated directly"? | 16:04 |
| Peng_ | It's still a plugin, but it works perfectly well. | 16:04 |
| jam | I have the feeling he might mean "bundled with the installer", but I'm not sure. | 16:05 |
| Peng_ | Oh. | 16:05 |
| mattions | Ok I'm running the 1.9rc | 16:05 |
| mattions | and synaptic does not want to install the plugin anymore | 16:06 |
| Peng_ | I guess it hasn't been marked as compatible with 1.9 yet. | 16:06 |
| mattions | Should I install the plugin bymyself | 16:06 |
| mattions | and see if ti works? | 16:06 |
| dissonans | jam: thanks, "missing" was the command I was missing :] | 16:06 |
| dissonans | Peng_: it's not even compatible with 1.8? | 16:07 |
| mattions | actually it seems the plugin is still there because when i try to push it ask me to authenticate | 16:07 |
| Peng_ | mattions: It will work, it just might need to be marked as compatible. | 16:07 |
| mattions | to the SVN | 16:07 |
| mattions | but then I've got this error: | 16:08 |
| mattions | bzr: ERROR: Transport operation not possible: http does not support mkdir() | 16:08 |
| mattions | but I'm using https! | 16:08 |
| === kiko is now known as kiko-fud | ||
| Odd_Bloke | mattions: The secure version of the HyperText Transfer Protocol still uses the same protocol, which doesn't support mkdir(). :) | 16:09 |
| mattions | but before it worked! | 16:10 |
| mattions | well, anyway good to know | 16:10 |
| Odd_Bloke | mattions: The same operation worked, or different operations? | 16:10 |
| mattions | so the question is: how? | 16:10 |
| mattions | same operation.. | 16:10 |
| mattions | added some directories with bzr and then pushed everything | 16:11 |
| mattions | in the svn | 16:11 |
| Odd_Bloke | mattions: Pushed everything to SVN? And you've been able to push before? | 16:11 |
| mattions | yep | 16:12 |
| Odd_Bloke | mattions: OK, look in ~/.bzr.log. | 16:12 |
| mattions | Odd_Bloke: I think I screw up something... let me check that .. | 16:15 |
| Odd_Bloke | mattions: Sure. | 16:16 |
| mattions | Odd_Bloke: it worked | 16:26 |
| mattions | so the plugin has been deinstalled by synaptic | 16:27 |
| mattions | at some point, and I didn't notice | 16:27 |
| mattions | I installed the last plugin from the site directly and everything worked | 16:27 |
| mattions | even the "add" of new directories | 16:27 |
| Odd_Bloke | mattions: Cool. | 16:27 |
| jelmer | james_w, I've just filed two more merge requests | 16:58 |
| james_w | yeah, I was just about to reply to the get-orig-source one | 16:58 |
| james_w | do you want the response here instead? | 16:58 |
| jelmer | james_w, Whatever works for you | 16:59 |
| james_w | k | 16:59 |
| james_w | My thought was that the try for get-orig-source would come before debian/watch, why did you put it the other way around | 16:59 |
| james_w | and also, if debian/watch exists, but uscan fails it doesn't try get-orig-source, is that what we want | 17:00 |
| jelmer | mainly because it's a bit more verbose | 17:00 |
| james_w | obviously if the order was swapped then that would become more complex | 17:00 |
| jelmer | since if get-orig-source doesn't exist in debian/rules you get an error message | 17:00 |
| jelmer | would there be situations where you would want to use get-orig-source but also had debian/watch ? | 17:01 |
| james_w | I'm not sure | 17:01 |
| james_w | but I think if I had both I would want get-orig-source to be used | 17:02 |
| james_w | but having both would be confusing | 17:02 |
| jelmer | yeah, I think having both is undesirable | 17:03 |
| james_w | I think I'll merge what you have, and deal with any bug reports | 17:04 |
| james_w | then at least I can ask how they expect this to be handled | 17:04 |
| james_w | thanks | 17:04 |
| james_w | for the other one, I'm not so sure | 17:04 |
| james_w | firstly, I don' think it fixes the bug Martin reported, does it? | 17:04 |
| jelmer | it does, since it will use an existing file rather than overwrite it | 17:04 |
| jelmer | it also fixes my problem with the checksum of the .orig.tar.gz changing | 17:05 |
| james_w | but Martin gets the failure when the file is copied back | 17:05 |
| james_w | sorry, moved to the result dir | 17:06 |
| jelmer | ah, you're right - sorry | 17:06 |
| jelmer | I should've read the bug report more closely | 17:06 |
| james_w | no problem, it may still be worthwhile | 17:06 |
| james_w | overwriting what was there was a concious choice when I implemented this | 17:07 |
| jelmer | Reading the bug report again, I think overwriting is a fair choice | 17:08 |
| james_w | for the case when you have "export_upstream" with no "export_upstream_revision", and then the upstream branch changes without the upstream version number changes | 17:09 |
| james_w | in that case if you don't overwrite you build the wrong code | 17:09 |
| james_w | Martin's bug report is a separate issue that doesn't even need export_upstream to trigger it, and I have an idea of how to at least improve that situation | 17:10 |
| jelmer | yeah, there are several corner cases like that I guess - changing get-orig-source would be another | 17:10 |
| james_w | would it work if we made it so that it didn't overwrite if you had export_upstream_revision, or you were using the ~bzr magic? | 17:10 |
| james_w | but changing export_upstream_revision would break it | 17:11 |
| james_w | I don't think it's soluble unless we store the revid of the version used to create the tarball with the tarball | 17:11 |
| james_w | which isn't that easy at the moment | 17:11 |
| jelmer | hmm, you're right | 17:11 |
| jelmer | I'll withdraw that one and give it some more thought | 17:12 |
| jelmer | james_w, did you have a chance to look at merge upstream branch one ? | 17:14 |
| james_w | jelmer: yeah, I reviewed it | 17:14 |
| === kiko-fud is now known as kiko | ||
| james_w | jelmer: yeah, I think I'll merge it, with a couple of tweaks, once I have merged 2.0 into trunk | 17:16 |
| james_w | thanks for working on it | 17:16 |
| jelmer | james_w, thank you! | 17:17 |
| jcastro | emmajane: ~1 hour until your session! | 19:02 |
| emmajane | yup! | 19:03 |
| emmajane | I'm already in teh classroom. | 19:03 |
| emmajane | And I've almost got everything pre-typed... | 19:03 |
| emmajane | jcastro: some of it may be too basic...I guess we'll find out though... | 19:04 |
| jcastro | emmajane: it's ok alot of questions today have been by new users so this should work out just fine | 19:05 |
| emmajane | cool | 19:05 |
| emmajane | jcastro: I'm just making a quick tea and grabbing a snack. Notes at: http://pastebin.ubuntu.com/66903/ | 19:43 |
| jelmer | oh, it's ubuntu open week again? | 19:44 |
| LarstiQ | new release, I suppose that gets a fair share of new users | 19:45 |
| emmajane | yup :) | 19:48 |
| emmajane | btw you're welcome to run through those notes and let me know if you've got any comments. | 19:48 |
| jelmer | cool | 19:48 |
| emmajane | I've got the UBER basic session. :) | 19:48 |
| LarstiQ | emmajane: not bzr related, but you mention using aptitude and then go on to use plain apt-get :) | 19:51 |
| emmajane | LarstiQ: oops, yea. :) | 19:52 |
| emmajane | thanks | 19:53 |
| LarstiQ | emmajane: 'bzr add' has the effect of adding all files in the tree, 'bzr add *' could miss things that the shell doesn't expand to (like .files) | 19:53 |
| LarstiQ | that is, bzr add without any argument | 19:53 |
| emmajane | ahh, ok. | 19:53 |
| jelmer | emmajane, Looks good :-) Also a minor thing - I think Launchpad should be spelled with a lowercase p | 19:53 |
| * emmajane removes the *. Not sure why I have that actually, I've never added files with an *. | 19:54 | |
| LarstiQ | emmajane: if you think it is clearer with an argument, I suggest 'bzr add .' instead of * | 19:54 |
| LarstiQ | :) | 19:54 |
| luks | bzr add * would also add ignored files | 19:54 |
| * emmajane nods. | 19:55 | |
| emmajane | * gone. | 19:55 |
| emmajane | who needs stars anyway. ;) | 19:55 |
| LarstiQ | emmajane: bzr diff -c might make more sense than -r if you are looking at historical changes | 19:56 |
| LarstiQ | emmajane: -c revno does -r revno-1..revno | 19:56 |
| LaserJock | anybody know if it's possible to get bzr multi-pull to output more data like bzr pull? like showing the changed files | 19:56 |
| LarstiQ | emmajane: whereas -r revno compares the current state of the working tree against that version | 19:56 |
| emmajane | I thought I had both? | 19:56 |
| jelmer | LaserJock, not atm | 19:57 |
| emmajane | isn't $ bzr diff -r# FILENAME current to revno? | 19:57 |
| emmajane | and $ bzr diff -v -r#..# FILENAME compares two versions in history? | 19:57 |
| LarstiQ | emmajane: ah, I misread a bit. | 19:58 |
| jelmer | emmajane, perhaps mention "bzr status" before the commit ? that should also be helpful when doing incremental commits and for example forgetting to add new files. | 19:58 |
| LarstiQ | emmajane: I'd also mention `bzr help topics` | 19:59 |
| emmajane | thanks for the suggestions!! :) | 20:00 |
| LarstiQ | emmajane: and `bzr viz` is always nice for pretty graphs ;) | 20:00 |
| emmajane | LarstiQ: they won't have anything /to/ graph though. :( | 20:01 |
| emmajane | bobbo might tackle that in his session. | 20:01 |
| LarstiQ | emmajane: bzr get lp:bzr; cd bzr; bzr viz? | 20:02 |
| LarstiQ | emmajane: when is this session btw? | 20:03 |
| NfNitLoop | I wish I could get my company to use bzr. | 20:03 |
| LarstiQ | NfNitLoop: what is holding you back? | 20:03 |
| NfNitLoop | they've built this custom deployment system against svn. | 20:03 |
| NfNitLoop | so there would be a lot of stuff to change. | 20:04 |
| NfNitLoop | they also seem to be fond of having a monolithic svn repo for every project, much to my dismay. | 20:04 |
| NfNitLoop | but we're starting to get merging headaches because multiple teams will touch the same file/heararchy. | 20:05 |
| NfNitLoop | and every time I have to manually merge something in svn 1.4 I daydream of bzr. :p | 20:05 |
| nevans | NfNitLoop, for svn, it often makes sense to have a monolithic svn repo. less for sysadmin's to maintain. no overhead to creating a new project. | 20:06 |
| emmajane | LarstiQ: started about five minutes ago. | 20:06 |
| nevans | NfNitLoop, have you tried bzr-svn? :) | 20:06 |
| NfNitLoop | nevans: I have. It breaks on our repo. | 20:06 |
| nevans | NfNitLoop, :-( it occasionally breaks on mine too. | 20:06 |
| NfNitLoop | I haven't tried the bzr1.9rc/bzr-svn combo. | 20:06 |
| NfNitLoop | I'd love to use bzr-svn for my own branches. :) | 20:07 |
| nevans | NfNitLoop, I'm actually testing that out now to see if that combo works on my repo (it was broken in 1.7, 1.8) | 20:07 |
| NfNitLoop | yeah, I don't think bzr-svn worked with 1.8? | 20:08 |
| NfNitLoop | nevans: let me know if it fixes your issue and I'll give it a go with ours. :) | 20:08 |
| nevans | I've gotten into situations where "bzr pull" would work with an already exported repo... but an initial "bzr branch" wouldn't. | 20:08 |
| NfNitLoop | it'd be cool to just have svn for our trunk and then have bzr branches everywhere. :p | 20:09 |
| LarstiQ | emmajane: cool, dropping by as backup | 20:09 |
| NfNitLoop | nevans: w/ 1.9? | 20:09 |
| emmajane | thanks, LarstiQ :) | 20:09 |
| nevans | NfNitLoop, not sure yet. still doing the initial dump. | 20:09 |
| LarstiQ | NfNitLoop: I started using bzr-svn for my own branches of stuff in svn. | 20:10 |
| NfNitLoop | nevans: Yeah, there are known issues with bzr branch w/ large svn repos. svn1.4 python bindings have a memory leak. | 20:10 |
| nevans | it takes more than two hours to do a branch of my main project. | 20:10 |
| NfNitLoop | nevans: you can work around it by only pulling X number of revisions at a time. | 20:10 |
| LarstiQ | NfNitLoop: now two of us are doing things in pure bzr, and two others have started using it as well (that's half the development team there) | 20:10 |
| jelmer | NfNitLoop, the stock svn python bindings are no longer used | 20:10 |
| NfNitLoop | jelmer: Oh? Nice! | 20:10 |
| NfNitLoop | jelmer: is that new in the 1.9-compatible versoin? | 20:10 |
| NfNitLoop | nevans: Yeah, that bit's no fun, but once you have it in bzr, you can branch to other bzr branches, no? | 20:11 |
| NfNitLoop | and that should be speedier. | 20:11 |
| nevans | NfNitLoop, yep | 20:12 |
| jelmer | NfNitLoop, no, that's been in there since 0.4.11 | 20:12 |
| jelmer | (compatible with bzr 1.5) | 20:12 |
| nevans | jelmer, ps u | grep [b]zr\ branch | awk '{ print $6 }' tells me that I'm using 1371548 and slowly growing. :( | 20:12 |
| NfNitLoop | Ohrealy? (Has it been *that* long since I've played w/ bzr-svn?) | 20:13 |
| NfNitLoop | nevans: Yeah, that's the issue I had. | 20:13 |
| nevans | copying revision 11839/15819 (been running for over an hour) | 20:13 |
| nevans | NfNitLoop, in the olden days, it would have run out of memory *long* ago | 20:13 |
| NfNitLoop | hehe. | 20:13 |
| NfNitLoop | well, hrmm, now I want to give it a try. | 20:14 |
| gour | jelmer: 0.4.14 works with 1.8? | 20:14 |
| jelmer | gour, no, with 1.9 | 20:14 |
| jelmer | gour, 0.4.13 works with 1.8 (although it may warn about being possibly incompatible) | 20:14 |
| gour | jelmer: hmm, then i cannot upgrade my archlinux pkgbuild 'cause arhc has bzr 1.8 | 20:15 |
| gour | yes, 0.4.13 spits some warnings | 20:15 |
| jelmer | but other than that it should work fine with1.8 | 20:16 |
| nevans | NfNitLoop, one thing to be aware of with bzr-svn: there are currently some nasty race conditions (because bzr has different locking assumptions than svn), so I think that the "rebase/dpush" workflow is probably the safest right now. | 20:18 |
| NfNitLoop | nevans: I'm not familiar with rebase/dpush... | 20:19 |
| gour | jelmer: ok. i already put 0.4.13 in AUR | 20:20 |
| jam | jelmer: I saw you released 0.4.14, but I don't see the tag in lp:bzr-svn | 20:23 |
| jam | I guess it is in the 0.4 branch | 20:24 |
| jelmer | yeah, it's there in the 0.4 branch | 20:24 |
| jelmer | the debian-experimental branch has debian-0.4.14-1 as tag I think | 20:24 |
| NfNitLoop | aww, 1.9/0.4.14 has the same issue w/ our svn repo. | 20:29 |
| NfNitLoop | SubversionException: ("REPORT request failed on '/svn/app/!svn/bc/19280'", 17500 | 20:29 |
| NfNitLoop | 2) | 20:29 |
| NfNitLoop | which I haven't really bothered tracking down. | 20:29 |
| nevans | :( | 20:30 |
| nevans | I'm still waiting for my branch: copying revision 12981/15819 | 20:31 |
| emmajane | jelmer and LarstiQ thank you thank you thank you!!!! | 20:48 |
| LarstiQ | emmajane: np :) | 20:48 |
| NfNitLoop | aha, apparently the REPORT issue is due to some incorrect proxying. | 20:49 |
| NfNitLoop | svn log <url> gets the same error. | 20:49 |
| NfNitLoop | (after showing quite a few revisions) | 20:49 |
| NfNitLoop | I'll bug my sysadmins. :p | 20:49 |
| LarstiQ | emmajane: thank you for running this intro session | 20:51 |
| poolie | hello LarstiQ, emmajane | 20:54 |
| jelmer | np :-) | 20:54 |
| jelmer | 'morning poolie | 20:54 |
| emmajane | LarstiQ: np :) | 20:54 |
| poolie | and jelmer | 20:54 |
| jam | poolie: hi, I forget DST switched :) | 20:56 |
| poolie | so confusing! | 20:56 |
| poolie | i actually bought a watch with a utc display :) | 20:56 |
| poolie | i wonder if it's tax deductible :-) | 20:56 |
| jam | business expense, right? | 20:57 |
| jam | I think it would be here | 20:57 |
| poolie | anyhow, want to talk soon? | 20:57 |
| poolie | my net connection seems flakey so if i can't get through to you, can you call my landline? | 20:57 |
| jam | with the caveat that 2% of your total income can go to business expense before they start actually giving you a deduction. | 20:57 |
| poolie | hm | 20:57 |
| LarstiQ | hi poolie | 20:58 |
| jam | poolie: yeah, I'm just trying to get setup.exe working and documented on Kerguelen, give me a few minutes and I'll give you a call | 20:58 |
| poolie | ok | 20:58 |
| poolie | hi | 20:58 |
| emmajane | thanks again everyone. that was awesome. :) | 20:58 |
| LarstiQ | emmajane: cool :) | 20:59 |
| emmajane | I resisted from saying, "That's not a beginner question!!" for most things. :) It was great to have you there as a backup! :) | 20:59 |
| poolie | what did you do, emmajane? | 21:00 |
| emmajane | poolie: I taught people how to make and use a time machine^H^H^H^H Bazaar :) | 21:00 |
| poolie | nice | 21:01 |
| james_w | hey poolie. It's Ubuntu open week again. | 21:01 |
| poolie | oh, cool | 21:01 |
| === dobey_ is now known as dobey | ||
| nealmcb | I just ran into this bug in my electionaudits project: https://bugs.edge.launchpad.net/bzr/+bug/245170 | 21:16 |
| ubottu | Launchpad bug 245170 in bzr "file modification time not preserved by checkout" [Undecided,Confirmed] | 21:16 |
| nealmcb | Am I missing anything? | 21:16 |
| * poolie looks | 21:16 | |
| poolie | no, it's just not implemented | 21:17 |
| poolie | we could have an option to set them to the time of the original commit | 21:18 |
| poolie | i'm not sure about storing the mtime they had when they were committed | 21:18 |
| poolie | perhaps that could be done in a plugin though | 21:18 |
| nealmcb | poolie: thanks for looking. would you know if there is an easy way to get python setup.py sdist to only include versioned files? | 21:18 |
| * nealmcb is using setuptools_bzr | 21:19 | |
| poolie | for bzr, or for something else? | 21:19 |
| nealmcb | for my project | 21:19 |
| LarstiQ | and there is the problem of stupid buildsystems that look at timestamps, forcing you to touch everything to get what you're working on installed. | 21:19 |
| LarstiQ | Yes distutils, I'm looking at you *glare* | 21:19 |
| nealmcb | poolie: setting the files all to the same time (e.g. commit time) wouldn't help me at all. the mod time data is important to preserve for this. | 21:22 |
| lifeless | nealmcb: right now, we don't do that, You may find that etckeeper however has a layer on top to do so | 21:23 |
| nealmcb | LarstiQ: can you give an example? I like smart build tools (make) that leverage timestamps. That's why I want bzr to preserve that. There was a huge flap when Nautilus stopped preserving file mod times in hardy | 21:23 |
| jam | nealmcb: you might look at the "etckeeper" project. I don't know if it preserves mtime, but I know it tracks file permissions, etc | 21:23 |
| jam | morning lifeless | 21:23 |
| nealmcb | jam thanks - I've looked at it before but didn't think of actually using it for this - hmmm | 21:24 |
| lifeless | nealmcb: *however* file systems datetime is not really an audit-safe property except on a couple of very specific file systems; myself I would not depend on it. | 21:24 |
| LarstiQ | nealmcb: python setup.py install; bzr revert; python setup.py; curse at no changes being made to installed packages | 21:24 |
| poolie | what did Nautilus do? | 21:24 |
| LarstiQ | nealmcb: or maybe it is slightly more complex with two different branches | 21:24 |
| poolie | i suppose you mean preserving them when copying files or something? | 21:24 |
| jam | does anyone know the exact revision for the qbzr 0.9.5 release? I'm packaging the win32 installer, and I just remembered that there may be some bugs in the tip of trunk | 21:24 |
| LarstiQ | nealmcb: but I run into that too frequently :( | 21:24 |
| lifeless | nealmcb: for starters on FAT datetime on a file is only accurate to 3 seconds | 21:24 |
| nealmcb | LarstiQ: right - I call that a bug in bzr, not in distutils | 21:25 |
| LarstiQ | nealmcb: this has nothing to do with bzr though | 21:25 |
| LarstiQ | nealmcb: it works equally badly without using bzr at all | 21:25 |
| LarstiQ | oh hmm, bzr revert would actually work | 21:26 |
| LarstiQ | nealmcb: the problem, as far as I have determined, is that distutils looks at the timestamps of files it's about to install, and if they're older than what is installed, it does not execute that step | 21:26 |
| nealmcb | nautilus bug: https://bugs.edge.launchpad.net/ubuntu/hardy/+source/nautilus/+bug/215499 | 21:28 |
| ubottu | Launchpad bug 215499 in glib2.0 "Nautilus not preserving timestamps" [Medium,Fix released] | 21:28 |
| nealmcb | lifeless: what do you mean by audit-safe? | 21:29 |
| lifeless | nealmcb: I mean can be modified with the modifier not necessrily visibl | 21:33 |
| nealmcb | lifeless: hmm? I'm still unclear on that | 21:35 |
| LarstiQ | nealmcb: you need cooperation from everyone/tool that touches your files for the scheme to work. | 21:36 |
| LarstiQ | nealmcb: it breaks very easily. So, using dates in filenumbers for example is a lot more robust to get chronological sorting. | 21:36 |
| nevans | I've got a problem where a revision in one repository has a different parent from a revision in another repository (because of a race condition in bzr-svn) | 21:40 |
| emmajane | LarstiQ: thanks again for sticking around to answer questions in #ubuntu-classroom. It's very much appreciated!! | 21:40 |
| emmajane | and james_w too, of course. :) | 21:40 |
| nevans | I've uncommitted the bad revisions from my branches... but I still can't pull from the good repo, because the bad revisions are still in the repo | 21:40 |
| nevans | is there an easy way to remove the revisions from the repo? | 21:40 |
| NfNitLoop | nevans: are they the most recent ones? | 21:40 |
| nealmcb | LarstiQ: true. but e.g. my input files come from election software which doesn't do timestamping in the filename, and asking the user to get it right when they name hundreds of files is not good. And this is just one example - file mod times are used all the time. | 21:41 |
| NfNitLoop | nevans: if so, 'uncommit'? | 21:41 |
| nevans | NfNitLoop, uncommit pulls them out of the branch... but pull still fails with ERROR: Revision {svn-v3-trunk1:0487d25d-142b-0410-8fcf-b82ac621bf97:crms%2Ftrunk:48813} not present in ... | 21:41 |
| jelmer | nevans, uncommit doesn't remove revisions from the repository | 21:42 |
| nevans | jelmer: yeah I know. how can I remove them from the repo now? :) | 21:42 |
| jelmer | nevans, but you can create a copy of the branch, that should hopefully not copy unreferenced revisions | 21:42 |
| nevans | it's a shared repo that I use for lots and lots of branches... I'd rather not recreate the entire thing. | 21:42 |
| LarstiQ | nealmcb: do you have any influence over the tool that is used to process the files? | 21:43 |
| NfNitLoop | Hrmm, wasn't there an addon that did garbage collecition for shared repos? | 21:43 |
| LarstiQ | nealmcb: as a workaround, you could store the timestamps in a seperate file and commit that | 21:44 |
| nealmcb | I wish. democracy wishes. but it is closed source from the elections industry | 21:44 |
| nealmcb | LarstiQ: easier to just package a zip file, since there would be a post-install step anyway.... | 21:45 |
| nevans | NfNitLoop, yeah. that's basically what I'm looking for. | 21:45 |
| NfNitLoop | jelmer wrote a "remove-revisions" plugin. | 21:45 |
| NfNitLoop | http://bazaar-vcs.org/BzrPlugins | 21:45 |
| LarstiQ | emmajane: np | 21:46 |
| * LarstiQ needs to go to sleep now though | 21:46 | |
| LarstiQ | emmajane: so thanks and succes with the rest of it :) | 21:46 |
| emmajane | LarstiQ: sleep well and thanks and you're welcome. :) | 21:46 |
| NfNitLoop | nevans: but it was last updated in feb '07... dunno if that still works. :p | 21:47 |
| nevans | I might just take the long route: copy all of the branches into a new shared repo. | 21:48 |
| nevans | NfNitLoop, jelmer, at any rate, bzr-svn 1.9/0.4.14 seems to be working for me again (even if it did take 2.5 hours to do the initial branch) | 21:51 |
| jelmer | nevans, cool | 21:52 |
| NfNitLoop | nevans: cool. *jealous* :p | 21:53 |
| lifeless | spiv: sp | 22:21 |
| lifeless | *so* | 22:21 |
| lifeless | the initial push, is it transcoding perhaps ? | 22:21 |
| spiv | lifeless: hmm, that's pretty likely actually. usertest isn't really geared for test-this-format, it's geared around test-this-tool. | 22:22 |
| spiv | lifeless: I can try tweaking development3 to be the default format | 22:23 |
| lifeless | now for the slow fetches | 22:23 |
| lifeless | that 100 batch smells like the converter code I wrote | 22:24 |
| lifeless | repository.py:3188 | 22:24 |
| spiv | Ah, I see. | 22:25 |
| spiv | That does look highly likely.k | 22:25 |
| * emmajane waves to meastp | 22:43 | |
| emmajane | I know that meastp had some follow up questions about Bazaar from Ubuntu Open Week, but I have to head out for a class. Hopefully there's still a few people around? :) | 22:43 |
| emmajane | Thanks again to everyone for their help today. It was great! | 22:44 |
| meastp | Hi! I have a problem with repositories. I have done: init-repo --no-tree, branch lp:footrunk, done checkout on trunk, and branch lp:foofeature1. However my feature branches are empty... | 22:45 |
| lifeless | meastp: because you used --no-trees | 22:54 |
| lifeless | meastp: you will need to checkout each branch separately | 22:54 |
| meastp | oh.. What structure do you recommend for a shared repository? | 22:56 |
| meastp | *file structure... with --no-trees I have ../trunk and ../features/feature1-n | 22:57 |
| lifeless | thats fine | 22:57 |
| Daniel999 | hi | 22:58 |
| meastp | but can I keep that with --no-trees? Oh, so no-trees just affect the file structure _inside_ the brances? | 22:58 |
| lifeless | it just determines if a 'checkout .' is done implicitly after branching | 22:59 |
| Daniel999 | Hello everybody | 22:59 |
| lifeless | you would use --no-trees on servers, or when you want a separate work area to your collection of branches | 22:59 |
| meastp | oh, so it has nothing to do with file structure, then? | 22:59 |
| lifeless | nothing at all | 23:00 |
| Daniel999 | I'm having problems with cygwin branches, using sftp on non-common ports | 23:00 |
| meastp | oh.. I didn't understand that last bit, but I guess it doesn't matter for now... | 23:00 |
| Daniel999 | i guess somebody could give me a hint here.. | 23:00 |
| lifeless | Daniel999: you haven't described your problem or asked a question | 23:01 |
| Daniel999 | ok, i'll describe the problem: | 23:01 |
| Daniel999 | this is the command i'm using: | 23:02 |
| Daniel999 | bzr branch -v sftp://dan@machine.com:3999/var/rep/terra_qa/testengine | 23:02 |
| meastp | lifeless: ok, I did branch trunk and a feature branch. Unmodified files are in the feature branch, though...? | 23:03 |
| lifeless | meastp: I don't know what you are asking | 23:03 |
| Daniel999 | and i get this : bzr: ERROR: [Errno 20] Not a directory: '/tmp/testengine/.bzr/checkout/limbo/new-4/hernan@machine.com:3999' | 23:03 |
| Daniel999 | it seems like bzr is trying to make a temporal directory using a string containing ":" | 23:04 |
| lifeless | Daniel999: please file a bug; that is an internal path that we probably need to url escape to accomodate the ':' as ':' isn't usable on windows | 23:04 |
| Odd_Bloke | james_w: Thanks for looking at my installation thing BTW. :) | 23:04 |
| lifeless | Daniel999: as a workaround, create a .ssh/config file with an alias - something like | 23:04 |
| lifeless | Host port399 | 23:05 |
| lifeless | hostname machine.com | 23:05 |
| meastp | lifeless: the feature branches are not sharing files with trunk... all files are in all three branches.. | 23:05 |
| lifeless | port 3999 | 23:05 |
| lifeless | meastp: thats what you asked bzr to do | 23:05 |
| meastp | lifeless: do I have to run a 'sync' command? | 23:05 |
| lifeless | meastp: sync to do what? | 23:05 |
| Daniel999 | cool! that should solve my problem | 23:06 |
| lifeless | meastp: I think you're assuming I know something about what you want to achieve that I don't know | 23:06 |
| lifeless | Daniel999: please do file the bug though :0 | 23:06 |
| Daniel999 | oh yeah! | 23:06 |
| Daniel999 | thank you all! | 23:06 |
| meastp | lifeless: I'm sorry, could you please tell me how to use a repository? It is supposed to share files between brances, but I can't get it to work... | 23:07 |
| lifeless | meastp: ok, you've misunderstood what a repository does | 23:07 |
| lifeless | meastp: *all* it does is means that the history of your branches is not duplicated per-branch | 23:07 |
| lifeless | meastp: it doesn't affect your working areas where you write code or the behaviour of branches or anything else | 23:08 |
| lifeless | meastp: if you look in your repository at the top level there is a .bzr/repository directory | 23:09 |
| lifeless | meastp: inside that there is all the history of all your branches | 23:09 |
| lifeless | meastp: each branch has a .bzr directory too, but they don't have a '.bzr/repository' directory. | 23:09 |
| lifeless | meastp: and thats the space that you save | 23:09 |
| orospakr | argh, I hate it when I ^C an ssh password prompt, and while the bzr process dies right away, the ssh process keeps running for a while and spams the terminal with error messages. :( | 23:10 |
| lifeless | orospakr: hmm, would be nice to clean that up for you | 23:10 |
| orospakr | :D | 23:11 |
| lifeless | meastp: if you want to work with many feature branches and not have a lot of disk space taken up by your working files, bzr can do that too | 23:11 |
| meastp | lifeless: oh, so the common revision history isn't duplicated? I get it now... Your patience is appreciated :) | 23:12 |
| meastp | I guess what I thought is was, isn't really useful, anyway.. | 23:12 |
| meastp | I could just branch trunk, remove files I don't need (for this feature) from the branch, right? | 23:14 |
| Odd_Bloke | meastp: If you were willing to fix their removal when you merged back into trunk, yeah. | 23:15 |
| lifeless | meastp: uhm, what are you trying to accomplish with this deletion ? | 23:15 |
| meastp | Odd_Bloke: , lifeless : Yeah, just me being silly, I guess. It would not be very useful, when I think about it. I'm quite new to vcs'es, and dvcs is even more to learn, so bear with me :) | 23:17 |
| lifeless | meastp: in a feature branch you should make those changes that you want made to trunk when you merge it | 23:18 |
| lifeless | meastp: nothing more, nothing less | 23:18 |
| meastp | yeah... I just thought perhaps you didn't have to branch the whole trunk, for, say, a minor feature... | 23:19 |
| lifeless | you can branch and switch a working tree to the new branch, which is less IO than making a full new working tree | 23:19 |
| lifeless | but if you're new to all these things don't worry about optimisation | 23:20 |
| lifeless | just get used to working with dvcs | 23:20 |
| meastp | I'll stick too basic branching for now, I guess... and focus on the project;) Past midnight already, and up at seven - I should go. You have been very patient and helpful. I really appreciate it! | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!