[00:05] * fullermd calls it late for lunch. [00:09] markh: if you're around, any idea off hand why getaddrinfo would fail on xp? [00:09] per https://answers.launchpad.net/bzr/+question/4949 [00:15] while I look - interesting pre-PEP on DVCS discussing hg and bzr - http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64 [00:16] poolie: 4949 is about dual-booting ubuntu? [00:17] heh [00:17] sorry, https://answers.edge.launchpad.net/bzr/+question/49498 [00:19] so, 10022==WSAEINVAL, so winsock doesn't like one of those params I'd guess [00:20] although windows seems documented as supporting AI_PASSIVE [00:26] however, "socket.getaddrinfo('www.google.com', 80, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)[0]" works for me! [00:31] (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:36] mm [00:36] here it's probably looking up 127.0.0.1:4155 [00:37] if she were on debian i'd almost suspect an ipv6-only configuration or something but that seems unlikely here [01:24] Today is the last day for PyCon 2009 submissions: http://us.pycon.org/2009/conference/proposals/ [01:59] alright, bazaar in, old sources imported with history, trac integrated. Thank you again LarstiQ if you see this. [03:22] 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:23] justizin, "pure" bzr? [03:24] 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] justizin, rich-root-pack is a standard supported bzr format, and will be the default at some point in the future [03:25] it stores more data than the current default, so there's no way to downgrade [03:25] oh, really? i was under the impression the current default was more modern.. [03:25] okay, well, if it's better, than i'll just roll with it. :) [03:25] it would be nice to be able to downgrade, still, but for my purposes, clearly not necessary. [03:25] if you mean the 1.6.1 format, there is a rich-root equivalent of that [03:26] 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] 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] thanks jelmer [03:27] hopefully it'll be the default in the next version [03:27] 1.8, or the next in 1.7 series? [03:27] no, more like 1.10 [03:27] that is: major / minor ? [03:27] ah ok [03:28] * justizin is so tired of .10 versions, seem to infect our whole python community ;d [03:28] i think zope is working on 2.12 :-P [03:39] is there a way to make a copy of a whole shared repository? [03:39] as if to branch the whole thing.. [03:39] justizin, I think there may be a plugin that can do that [03:39] any idea of keywords i might seek? :) [03:40] * justizin is so thankful for bzr this year, esp bzr-svn has made unimaginable things possible.. [03:40] i mean, there is svk, but, i dunno, i have a hard time sleeping with a process that depends on perl ;d [03:40] I'm not sure what the name could be [03:40] eh i'll sort it later [03:40] Odd_Bloke wrote it, but he's probably asleep atm [03:41] 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:42] 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:43] 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] so, yanno, i figured, make three copies of the deploy config, rip out the unneeded bits of each segment.. [03:43] now i want to update all dependencies, and have a merge path.. [03:43] probably something i should put some brain and coding time into if i want it. :) [03:44] sorry, I was about to get some sleep [03:44] 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] no worries jelmer, i ramble. rest your svn-battered mind :) [03:44] ciao.. [03:44] :-) ciao [03:44] :-P [03:45] 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] justizin, heh :-) [03:45] * justizin figures all good programmers have good beer taste [03:45] justizin, My favorite is "Hertog Jan", it's not too big in the US though I think [03:46] hm, i will look around. we certainly aren't a european import city, but we have lots of euro imports.. [03:46] i remember when i was in amsterdam, heineken was like budweiser in us [03:46] same in hamburg, actually [03:46] freakin' lager ;d [03:46] yeah, Heineken is the most generic beer you can get [03:47] well, i grew up in texas, before i was 21 heineken was a big step up from budweiser [03:47] but i dont think i had any when i went to AMS [03:47] Grolsch is also pretty common but a bit nicer (and probably available in the US) [03:47] i think we had guiness at the bull dog [03:47] grolsch i think we have at whole foods maybe [03:47] i'll try it [03:47] also tons of import taps in SF [03:48] buddy of mine just left high-end server gig to answer phones for amex top tier folks.. [03:48] we have nice microbrew, but import is always nice here and there [03:48] anyway, go crash [03:48] lol [03:48] didnt mean to keep you up [03:48] ttyl [03:49] oh yah and like "Server gig" i meant beer more than internet :-P [03:59] spiv, hi, did you decide in the end to work on that bug or to try the repo branch? [04:02] poolie_: trying out the repo branch. [04:03] how is it? [04:03] 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] nice [04:03] btw is there still anything i could review for you wrt usertest? [04:05] (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] Hmm, not sure, let me look. [04:06] I do miss the "just mail and forget" patch submission that bzr gets via bundle buggy. [04:08] poolie_: https://code.edge.launchpad.net/bzr-usertest/+activereviews lists two things that need review, IIUC what the UI is telling me [04:08] ok [04:08] :/ i didn't really want to get back into 100% code reviews [04:08] but i don't want things getting stale either [04:09] Well, maybe I should just merge them? [04:09] i'll have a look after i finish merging back to trunk === poolie_ is now known as poolie [04:36] poolie: ok. [05:05] spiv, all are done now [05:11] poolie: thanks [05:27] Wait, is there a subtree variant of the 1.9 format? [05:57] spiv, poolie: if it helps, I'm happy to review usertest stuff in the next few days [05:57] be a nice change from ploughing through my 2000+ emails :-) [05:58] hello igc [05:58] hi poolie [06:17] Peng_: development2-subtrees [06:36] spiv, can you send a paragraph or so about what you discovered about the repo branch and networking [06:36] if you're still online [06:38] Sure. [06:42] lifeless: Using a development format doesn't sound ideal. [06:42] Does "bzr pack" optimize how all of the data is ordered? [06:48] Peng_: a quick glance at the code suggests that it does [06:48] thanks [07:00] Peng_: true; OTOH its available in 1.7 and above I think [07:03] * Peng_ grumbles again about downgrading from subtrees to rich-roots. [07:04] hi all [07:05] hi vila [07:06] hi Ian ! [07:30] night all [08:49] 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] import md5" warning all the time [08:49] how to get rid of it? [08:49] it's, afaik, lifeless's plugin [08:54] You...ask lifeless to use hashlib instead? :P [08:54] (Well, try: hashlib and fall back to md5. Anyway..) [08:56] gour: If you know a bit of Python, it shouldn't be difficult to fix the warnings and send a patch. [08:58] (I don't mean to sound unhelpful, but not everybody has access to Python 2.6.) [09:00] Peng_: well, the question is more in line what's the bzr plan in regard of 2.6 support? [09:01] Oh. [09:02] A few patches to help Python 2.6 compatibility have been merged. [09:03] that's nice to hear [09:03] Or at least proposed.. [09:04] * gour replaced the calls ==> no warnings any longer [09:06] poolie: I think I'm calling it a day :P [09:06] 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:08] lifeless: Yeah. Having to remember to keep an eye on my repo is stupid. [09:08] Eh, sorry. [09:09] I'm grumpy about the subtree/rich root thing again. :P [09:09] gour: Yeah, the big Py2.6 patch was merged in bzr.dev r3751. [09:09] Peng_: fair enough, I'm not thrilled either; it is moving slowly [09:09] 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] Peng_: ta for the info [09:09] I'm not that impatient. [09:10] 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] (Well, maybe a little, when it's safe.) [09:10] there will be some format-removal in 1.9? [09:12] Is there anything really difficult about supporting going from subtrees to rich-roots or is it just that nobody's done the work? [09:15] Peng_: dev2-subtrees wouldn't be dogfooding as such, fwiw. Its just a label :). Anyhow .. [09:15] subtrees to rich roots requires checking that no inventory entry is a subtree [09:15] noone has optimised that check [09:16] gour: format removal breaks older clients; we try to keep the list of visible formats short [09:16] So it isn't difficult to do, it's just difficult to do quickly? [09:16] Peng_: right [09:16] Or at least nobody has done the work to figure that out yet. [09:16] lifeless: i understand. it's still, imho, too big [09:17] lifeless: Where does "bzr branch"ing from subtrees to rich-roots fit in? [09:17] It works, though it's not super-fast. [09:17] lifeless: let 'em upgrade or stay with older version. how long you will drag 'em around' [09:17] ? [09:17] gour: I'm not sure [09:17] gour: Some truly ancient formats are still supported. [09:18] anyhow, must go [09:18] Peng_: bzr init (repo) gives too many choices ;) [09:18] tere is a bug about presentation here [09:18] which would reduce the multiplication a lot [09:18] * lifeless goes [09:19] * gour just built r3818 pkg [09:22] nice, no more warnings... [09:23] ahh, there are still some [09:24] 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:25] i need to merge two branches without common ancestor, how to do it? [09:26] i'm trying with bzr -r x branch, but does not work [09:27] gour: bzr merge -r 0.. ../other [09:27] should do it [09:28] why -r ancestor:branch did not work? [09:31] 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:38] Peng_: so, 1.9 adds to the list of formats.. [09:38] gour: :) [09:39] the list of formats does not fit on one screen :-/ [09:40] it's pity if devs do not see it as a problem [09:40] I'm sure it'd fit with a 2048x1536 monitor and a small font. :) [09:40] heh, good joke [09:41] * gour is running 1450x laptop atm [09:42] running latest bzr with bzr-svn-0.4.13 gives: bzr: ERROR: Version mismatch [09:43] gour: Edit the compatibility info in bzr-svn's __init__.py. [09:44] Peng_: there is some new bzr-svn release around the corner? [09:44] * Peng_ shrugs [09:44] I run bzr.dev and bzr-svn's 0.4 branch. [09:45] They *are* compatible, but the compatibility checking hasn't been updated. [09:45] (Well, it has been since 0.4.13 was released.) [09:45] i see...still, my main problem with bzr-svn is lack of support for svn:externals [09:46] That won't happen until bzr supports it. [09:47] stacked branches are not enough? [09:48] Stacked branches are totally different. [09:49] err, nested branches? [09:50] Oh. Yes. I have no idea what state nested branch support is in, so I can't answer that. [09:51] Anyway, it's not considered production-ready.. [10:01] 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] It's kind of too late now. Backwards compatibility is important. [10:02] sure it is, but plethora of formats shows something is wrong with bzr-format [12:00] what do you think about http://rafb.net/p/WGzz9k72.html ? is it for bzr or push-and-update plugin? [12:03] gour: looks like a python 2.6 <-> bzr issue [12:04] Verterok: ahh, too bad :-/ [12:05] Verterok: should i submit ticket for it? [12:05] Uhh [12:05] Oh, never mind [12:06] 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] Verterok: hmm, what do you. 2.6 is default python here :-/ [12:07] gour: please, file the bug. I think there is some work-in-progress (tm) to support it [12:07] Even if it's not supported now, the only way to support it in the future is to fix the bugs. [12:07] s/bugs/compatibility issues/ .. [12:07] ok, i'm going to submit bug report [12:11] submitted - #293054 [12:16] gour: thanks === mtaylor_ is now known as mtaylor [14:06] abentley, ping [14:07] abentley, any eta for bzrtools 1.9? [14:07] jelmer: Sure, I'll see about it today. [14:17] james_w, hi [14:18] hey jelmer [14:19] james_w: I'm going to do more (sponsored) work on bzr-git [14:20] jelmer: great! [14:20] james_w: And I'd like to use your python-git module for that, extending it where necessary [14:20] um, sure [14:20] james_w: However, the name is a bit non-unique - what do you think about renaming it ? [14:20] let me know if I can help with anything [14:20] go ahead, it was just a weekend hack [14:21] thanks :-) [14:22] james_w: Btw, any news on my merge-upstream-branch patch for bzr-builddeb ? [14:22] It doesn't seem to fit well into the new infrastructure, should I adapt it to that? [14:23] let me take a look [14:31] hi [14:31] can some mailinglist admin moderate my email ? I'm not on the list! [14:35] jelmer: my only concern would be the upstream_branch_version() stuff [14:37] it looks sane, but it's quite magical [14:42] james_w: I can document it a bit better, perhaps let the user know where we got the version from? [14:42] yeah, that might help [14:42] james_w: It's only intended as fallback if the user doesn't specify a version [14:42] it looks like it would be doing what the user wants, and this merge-upstream stuff is quite magical anyway [14:50] james_w, I'll see about adding some docs and being a bit more verbose as to where the version comes from [14:50] james_w, what branch should I submit against ? lp:bzr-builddeb or lp:bzr-builddeb/2.0 ? [14:51] jelmer: the former please [14:51] 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:52] 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. [15:22] jelmer: is https://code.edge.launchpad.net/~jelmer/bzr-builddeb/452130/+merge/1511 fixed? === mm-mysql_ is now known as mm-mysql [15:24] james_w, yeah, you've already merged it [15:25] cool, thanks [15:29] I've just removed it (took a while to find the button) [15:40] hi mm-mysql, funny to see you around here :) [15:40] :) [15:41] 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] So, are you actually local to where we ran into each other or just visiting? [15:42] mm-mysql: *doh* :) [15:42] * mm-mysql waves at weigon [15:44] I live about a 15min walk from where we met. So I think that counts as "local" :) [15:44] what about you [15:45] I'm 5 minutes walk from Flossmoor Station...do you drink beer? :) [15:46] I've been known to have some from time to time. The Brewery there is a nice restaurant. [15:46] Well, if you're up for it sometime, we should meet up...even if not for beers. [15:46] definitely [15:47] james_w, I've pushed an updated version to http://people.samba.org/bzr/jelmer/bzr-builddeb/merge-upstream-branch/ [15:48] Peng_: bzr's user-manual says: " [15:48] ERC> [15:48] thanks jelmer, looking now [15:48] 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:49] what's the best way to see the history of merges in a repository [15:49] gour: It would take work, I guess. [15:49] i.e., I want to check which revision I last merged from another repo [15:51] Peng_: then better remove that sentence from the docs ;) [15:51] gour: "may one day" doesn't mean it has to be now. ;P [15:55] dissonans: Try qlog in the qbzr plugin [15:59] awilkins: thanks, trying that now [16:01] awilkins: can that tell me the parent revision from the other branch, though? [16:02] dissonans: you might also try: [16:02] bzr log -r ancestor:other/branch [16:02] or [16:02] bzr missing other/branch [16:02] depending on what you want [16:03] hello [16:04] Has the svn plugin been integrated directly in bazaar ? [16:04] "Integrated directly"? [16:04] It's still a plugin, but it works perfectly well. [16:05] I have the feeling he might mean "bundled with the installer", but I'm not sure. [16:05] Oh. [16:05] Ok I'm running the 1.9rc [16:06] and synaptic does not want to install the plugin anymore [16:06] I guess it hasn't been marked as compatible with 1.9 yet. [16:06] Should I install the plugin bymyself [16:06] and see if ti works? [16:06] jam: thanks, "missing" was the command I was missing :] [16:07] Peng_: it's not even compatible with 1.8? [16:07] actually it seems the plugin is still there because when i try to push it ask me to authenticate [16:07] mattions: It will work, it just might need to be marked as compatible. [16:07] to the SVN [16:08] but then I've got this error: [16:08] bzr: ERROR: Transport operation not possible: http does not support mkdir() [16:08] but I'm using https! === kiko is now known as kiko-fud [16:09] mattions: The secure version of the HyperText Transfer Protocol still uses the same protocol, which doesn't support mkdir(). :) [16:10] but before it worked! [16:10] well, anyway good to know [16:10] mattions: The same operation worked, or different operations? [16:10] so the question is: how? [16:10] same operation.. [16:11] added some directories with bzr and then pushed everything [16:11] in the svn [16:11] mattions: Pushed everything to SVN? And you've been able to push before? [16:12] yep [16:12] mattions: OK, look in ~/.bzr.log. [16:15] Odd_Bloke: I think I screw up something... let me check that .. [16:16] mattions: Sure. [16:26] Odd_Bloke: it worked [16:27] so the plugin has been deinstalled by synaptic [16:27] at some point, and I didn't notice [16:27] I installed the last plugin from the site directly and everything worked [16:27] even the "add" of new directories [16:27] mattions: Cool. [16:58] james_w, I've just filed two more merge requests [16:58] yeah, I was just about to reply to the get-orig-source one [16:58] do you want the response here instead? [16:59] james_w, Whatever works for you [16:59] k [16:59] My thought was that the try for get-orig-source would come before debian/watch, why did you put it the other way around [17:00] and also, if debian/watch exists, but uscan fails it doesn't try get-orig-source, is that what we want [17:00] mainly because it's a bit more verbose [17:00] obviously if the order was swapped then that would become more complex [17:00] since if get-orig-source doesn't exist in debian/rules you get an error message [17:01] would there be situations where you would want to use get-orig-source but also had debian/watch ? [17:01] I'm not sure [17:02] but I think if I had both I would want get-orig-source to be used [17:02] but having both would be confusing [17:03] yeah, I think having both is undesirable [17:04] I think I'll merge what you have, and deal with any bug reports [17:04] then at least I can ask how they expect this to be handled [17:04] thanks [17:04] for the other one, I'm not so sure [17:04] firstly, I don' think it fixes the bug Martin reported, does it? [17:04] it does, since it will use an existing file rather than overwrite it [17:05] it also fixes my problem with the checksum of the .orig.tar.gz changing [17:05] but Martin gets the failure when the file is copied back [17:06] sorry, moved to the result dir [17:06] ah, you're right - sorry [17:06] I should've read the bug report more closely [17:06] no problem, it may still be worthwhile [17:07] overwriting what was there was a concious choice when I implemented this [17:08] Reading the bug report again, I think overwriting is a fair choice [17:09] 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] in that case if you don't overwrite you build the wrong code [17:10] 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] yeah, there are several corner cases like that I guess - changing get-orig-source would be another [17:10] 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:11] but changing export_upstream_revision would break it [17:11] 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] which isn't that easy at the moment [17:11] hmm, you're right [17:12] I'll withdraw that one and give it some more thought [17:14] james_w, did you have a chance to look at merge upstream branch one ? [17:14] jelmer: yeah, I reviewed it === kiko-fud is now known as kiko [17:16] jelmer: yeah, I think I'll merge it, with a couple of tweaks, once I have merged 2.0 into trunk [17:16] thanks for working on it [17:17] james_w, thank you! [19:02] emmajane: ~1 hour until your session! [19:03] yup! [19:03] I'm already in teh classroom. [19:03] And I've almost got everything pre-typed... [19:04] jcastro: some of it may be too basic...I guess we'll find out though... [19:05] emmajane: it's ok alot of questions today have been by new users so this should work out just fine [19:05] cool [19:43] jcastro: I'm just making a quick tea and grabbing a snack. Notes at: http://pastebin.ubuntu.com/66903/ [19:44] oh, it's ubuntu open week again? [19:45] new release, I suppose that gets a fair share of new users [19:48] yup :) [19:48] btw you're welcome to run through those notes and let me know if you've got any comments. [19:48] cool [19:48] I've got the UBER basic session. :) [19:51] emmajane: not bzr related, but you mention using aptitude and then go on to use plain apt-get :) [19:52] LarstiQ: oops, yea. :) [19:53] thanks [19:53] 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] that is, bzr add without any argument [19:53] ahh, ok. [19:53] emmajane, Looks good :-) Also a minor thing - I think Launchpad should be spelled with a lowercase p [19:54] * emmajane removes the *. Not sure why I have that actually, I've never added files with an *. [19:54] emmajane: if you think it is clearer with an argument, I suggest 'bzr add .' instead of * [19:54] :) [19:54] bzr add * would also add ignored files [19:55] * emmajane nods. [19:55] * gone. [19:55] who needs stars anyway. ;) [19:56] emmajane: bzr diff -c might make more sense than -r if you are looking at historical changes [19:56] emmajane: -c revno does -r revno-1..revno [19:56] 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] emmajane: whereas -r revno compares the current state of the working tree against that version [19:56] I thought I had both? [19:57] LaserJock, not atm [19:57] isn't $ bzr diff -r# FILENAME current to revno? [19:57] and $ bzr diff -v -r#..# FILENAME compares two versions in history? [19:58] emmajane: ah, I misread a bit. [19:58] 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:59] emmajane: I'd also mention `bzr help topics` [20:00] thanks for the suggestions!! :) [20:00] emmajane: and `bzr viz` is always nice for pretty graphs ;) [20:01] LarstiQ: they won't have anything /to/ graph though. :( [20:01] bobbo might tackle that in his session. [20:02] emmajane: bzr get lp:bzr; cd bzr; bzr viz? [20:03] emmajane: when is this session btw? [20:03] I wish I could get my company to use bzr. [20:03] NfNitLoop: what is holding you back? [20:03] they've built this custom deployment system against svn. [20:04] so there would be a lot of stuff to change. [20:04] they also seem to be fond of having a monolithic svn repo for every project, much to my dismay. [20:05] but we're starting to get merging headaches because multiple teams will touch the same file/heararchy. [20:05] and every time I have to manually merge something in svn 1.4 I daydream of bzr. :p [20:06] 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] LarstiQ: started about five minutes ago. [20:06] NfNitLoop, have you tried bzr-svn? :) [20:06] nevans: I have. It breaks on our repo. [20:06] NfNitLoop, :-( it occasionally breaks on mine too. [20:06]