[00:20] poolie: http://twitter.com/mkanat/status/8520484742 [00:21] mkanat: thanks, I've reweeted :P [00:21] lifeless: Yay. :-) [00:22] oh nice [00:22] how big is the repo? [00:23] mathrick: Oh, um, about 7000 revisions on trunk. [00:23] http://bzr.mozilla.org/ [00:23] aha, that's pretty modest [00:23] Yeah, not enormous. [00:25] its not how big it is :P [00:26] lol [01:36] morning [01:54] bzr support https? [01:58] Can you be more specific? [02:01] i was trying to find a bug report i saw earlier [02:01] it was throwing an error because I am using a self-signed certificate for an internal https server [02:04] https://bugs.launchpad.net/bzr/+bug/82086 [02:04] that one [02:04] Ubuntu bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged] [02:04] it's marked as fixed released a long time ago [02:05] oh it was changed [02:15] G'day [02:16] I was wondering if anyone could offer some advice for storing file modification times along with file contents in bazaar. [02:16] dcoles: perhaps some context on why? [02:17] if it is for e.g. make, then 2.1 will do better for you [02:18] Sure. I'm trying to use bazaar as a way to track modifications on a website using wget --mirror. I'm mainly interested in the Last-Modified header which gets stored in the mtime of the file. [02:18] AfC: you pung [02:19] dcoles: so, the closest you could get would be to script bzr via the python api to do one commit per timestamp you see, of only the modified fiels with that timestamp (using a fuzz factor to group changes) [02:20] AfC: sms me. [02:20] -> food [02:20] lifeless: I think I was looking to see if you were coming into Sydney for Beer last Friday. I've subsequently gathered you're out of town [02:20] Hmm... I guess that's one option. Would I be able to add it as metadata to the file, say, just before commiting the changes? [02:29] I never metadata I didn't like. [02:30] Kilroo: Something similar to `svn propset` would likely suit my purposes, but I don't think I've seen a way to access it via the bzr command. [02:31] Might just be easier to generate a 'last-modified' file and track the changes in that instead. [02:32] If you don't want it any more granular than that, couldn't you just look at when you committed? [02:36] Well I really wanted to know the server side 'last-modified' of the html files rather than when I mirrored the file. If it turns out to be too hard I guess I'll just run the mirror script each day and have to be satisified with just a 'day' resolution. [02:39] What I meant was, if you only get as specific as when that one file was last modified, then you're only going to get one modified time per commit. If you aren't committing shortly after making changes I suppose it could be significant to know when that one file was changed instead of when you committed, but I didn't think of that at first. [02:41] Oh. I see what you mean. [02:42] ('need at least bzr 2.1.0rc2 (you use %r)', (2, 2, 0, 'dev', 1)) [02:42] that seems wrong to me? [02:42] Kilroo: wget with --mirror sets the file timestamps to what ever the server says for 'last modified', so there could potentially be a few different modification times [02:43] But not for the one file you were going by. [02:43] Or did you mean make a file and record the last-modified times for everything else IN it as text? [02:43] Yes. [02:43] Gotcha. That makes me wonder two things. [02:44] `ls -l` or something a little less hackity [02:44] First, does wget output the last modified times as it processes the files. [02:44] ...and that was my second suggestion. [02:45] Heh. I actually have been working on setting up something at work to let me use a combination of rsync and bzr to pretend that the stuff we still have on plain ftp is version controlled. Modified times hadn't even occurred to me. [02:47] The experience has, however, convinced me that all our log files should be kept above the web document root to make version control easier, instead of just for all the other reasons I'd already had. [02:48] Kilroo: Alas no. I'd pondered just dumping stdout, but it only mentions if a file is 'newer' or 'not modified' [02:50] It'd be really easy if it was on a local machine, but it's a small external website we need to keep tabs on. [02:52] While the original intent was for me to check by hand, sounds like a great thing to have automated. [02:53] Anyway. Thanks for the advice. Given me a few more ideas to play with. :) [02:54] I'd probably go with putting the modtimes into a text file after every sync and versioning that, if you can't find a convenient way to set custom metadata in bzr. And submit a ticket suggesting that the ability to track that be added, although I think typically in a version controlled environment most people are going to care more about the commits. [05:18] what's the best practice for registering a project with Launchpad? I have a Drupal site that I want to user vc with but it is large ~2gb. [06:15] RyNy_: what do you mean by 'best practice' [06:16] I think I figured it out. I was wondering how much of the drupal install I should I send to LaunchPad. I suppose only the files that I change. [06:17] well if you are making a branch of drupal, surely you'd upload it to the drual namespace :) [06:19] why does the beta PPA have any versions newer than 2.0.1? [06:20] *doesn't [06:39] no, my changes have to do with personal configuration changes: new modules, or server configurations [07:02] does anyone have workflow tips for managing a LAMP server with bazaar [07:03] Do I create a branch for the whole server? [07:04] what are you planning to put in bzr? [07:04] I've never used a vc before. I like the idea but am wondering how much of the server should go in vc [07:05] depends what you're doing [07:06] Do I initialize the whole server? [07:07] you don't put / in bzr [07:08] just what I'm working on? [07:08] the source code for your app might be in version control, and etckeeper is great for /etc [07:08] er, the source code for your app should always be in version control, but you might not deploy to servers using version control [07:09] I'm changing some of the config files in LAMP and then my cms [07:09] "LAMP"'s pretty vague [07:10] but putting the config files under version control (if they're not in /etc already) is a good idea [07:29] hi all [07:30] mathrick: lack of man power or automation, take your pick :-/ [07:31] vila: well, possibly, but it goes directly against what the links from the Download page tell you (it explicitly lists 2.1.0bX) [07:33] mathrick: I'm pretty sure there is a thread about re-thinking the whole experience there on the mailing list [07:33] aha [07:34] mathrick: '[rfc] focus on Ubuntu updates rather than PPA packaging' [07:35] mathrick: the underlying problem is about being able to put a working set of bzr + plugins there without running into broken PPAs where one plugin breaks with a new bzr version [07:35] mathrick: your input and use case could only help the debate, so please reply there [07:36] vila: unfortunately that's not possible today and I don't know if I'll manage to squeeze it into the upcoming days :\ [07:37] mathrick: then rest assure that the problem is known [07:37] s/assured/ [07:39] mhm, thanks [07:41] mathrick: just for the record, are you using the beta PPA ? [07:43] vila: I have it added to sources, but that doesn't do much, because the Karmic debs are newer [07:44] mathrick: I see. But what are you interested in exactly: getting newer stable versions or something even newer ? [07:45] vila: trying out 2.1.0rcs, because I wanted to see how that performs on the Emacs repo, which hits 550MB resident mem in 2.0.3 [07:45] so yes, I want something even newer [07:46] mathrick: hmm. But bzr.dev and building the extensions from source is not attractive to you I presume... OS ? [07:46] Ubuntu [07:46] plugins ? [07:47] vila: it's not because I've done it in the past, and it's a pain to keep track of things yourself. With .debs I can just push a button and go do something else [07:47] mathrick: I know what you mean.... I have >10 setups maintained here but most of them can do with stable releases [07:50] mathrick: so, there is little for you *today* but as we approach 2.1.0final, there should be a way [07:50] yeah, that can wait [07:50] little == bzr.dev [07:50] anyway, thanks, I need to go do something else now [07:50] mathrick: more precisely lp:bzr/2.1 [07:50] mathrick: you're welcome, enjoy your day :D [12:08] um, I can't seem to figure out how to resurrect a file removed in revision 74 [12:08] actually just the equivalent of 'svn up -r SOMEOLDREVNO' would suffice [12:10] bzr cat -r 73 path > path kinda works [12:11] I'd be tempted to try merge [12:24] mgedmin, bzr revert -r 74 file ? [12:25] tried it, got an error (path not versioned or some such) [12:26] ended up doing bzr cat ; bzr add [12:26] so now it's kinda difficult to test "correct" solutions [12:28] Hi, I may be missing something obvious but I cannot find documentation on bzrlib. Got a clue for me? ;-) [12:29] mgedmin, that's weird, it works here [12:30] actually I tried bzr revert -r 74 subdir/file1 subdir/file2 [12:30] henninge: The source code is well-documented, and there's probably some starter info in the developer docs. There's also an API site somewhere, but I assume it's just generated docs. [12:30] henninge, http://doc.bazaar.canonical.com/bzr.dev/en/ [12:30] D: [12:30] Err, :D * [12:30] yeah, it should've worked, according to bzr help revert [12:30] mgedmin, both file1 and file2 are deleted ? [12:31] also is subdir versionned ? [12:31] rev 74 deleted a whole bunch of files, two of them by mistake [12:31] the subdir still exists and has files [12:31] try to revert each on separately ? [12:31] ah, I just realized I could've got a sort of an equivalent of "svn up -r 73" by doing bzr branch -r 73 ... [12:32] beuno: Thanks. I've been there and that's all about using "bzr" from the command line. But in pyhton scripts I want to import from bzrlib. I think I'll just browse the code like Peng suggested. ;) [12:33] well, thanks anyway [12:35] henninge: bzrlib/builtins.py is a good place to start, since it's where commands are implemented. [12:35] henninge: So, if you're trying to automate a command or something, you can just steal the code. :D === mrevell is now known as mrevellunch [13:01] bzr is crashing with an internal error referencing "Unknown kind 'relocated'" [13:04] quotemstr: what bzr revision, what are you doing [13:08] I have a branch at emacs/c++1x and I'm trying to merge from emacs/trunk. [13:08] So with CWD in emacs/c++1x, I run 'bzr merge', and get the above error. [13:08] It's bzr 2.0.3. [13:09] What actually happened was that I ran 'merge' once, got a bunch of conflicts, then ran 'bzr revert .'. [13:09] Then when I tried to merge again, I started getting that error. [13:14] And now it's just pegging the CPU meter, spinning while checking 'bzr check'. [13:18] Yeah..."bzr check" will not be fast on emacs. === mrevellunch is now known as mrevel === mrevel is now known as mrevell [14:20] henninge: http://wiki.bazaar.canonical.com/Integrating_with_Bazaar [14:20] henninge: http://starship.python.net/crew/mwh/bzrlibapi/ [14:20] hth === salgado is now known as salgado-lunch [14:57] That's a useful wiki page. I think I might add a mention of enable_default_logging and ui_factory, unless anyone knows they are covered elsewhere? [15:32] hi folks, i get peding merges how i can commit them? [15:32] ovnicraft: so you've done the merge, and you just want to commit? [15:33] yes [15:33] when i try to commit, tell me bzr: ERROR: Selected-file commit of merges is not supported yet: [15:33] yet: myfile [15:34] oh, you can't do a commit of just one file after a merge. just do a commit without any files listed. so like this "bzr commit -m "merged in things"" [15:43] and i get warning conflict tag: tagfromproject, is posible solve that? [15:43] mmm... I'm not sure how to resolve a tag conflict. [15:44] maybe someone else here can help [15:45] bzr pull --overwrite probably will (along with the other, potentially more dangerous things it does). === salgado-lunch is now known as salgado [16:01] morning [16:02] Could anyone clarify what does it mean for a repo to have or not have a working tree? [16:02] Repos don't have or not have working trees. Branches do, though. [16:02] Well, that is, repos never have working trees. [16:02] sorry branches* [16:03] devmod: A working tree is, ehh, uh, when it creates copies for all of your files so you can edit them and commit and whatever/ [16:03] devmod: Sometimes you don't need one -- e.g. a central branch on a server [16:04] i guess I understand what they are, just not sure when am I supposed to have them [16:04] when you need to 'work' with the branch [16:04] as in, edit files and commit changes [16:05] you don't need to have a working tree when you are using the branch only as a revision storage [16:05] ohh ok got it [16:06] This is possible because Bazaar supports (and recommends) creating repositories with no working trees (--no-trees). [16:07] that gave me the idea that repo have or not working trees [16:07] That just controls the default setting for branches created in that repo. [16:07] but Peng says they never do [16:07] ok got it [16:07] BTW, you can create or remove a working tree with "bzr co" and "bzr remove-tree". [16:08] There is no command to change the repo's default, but you can touch/rm .bzr/repository/no-working-trees. [16:08] ok thanks its clear now [16:09] I think you can do it with bzr reconfigure, but I never know how to use that command [16:10] Maybe. [16:11] I've been using bzr longer than reconfigure has existed, and I haven't learned it well. :P [16:12] I think that's not the problem :) [16:12] I've managed to learn new commands [16:12] but reconfigure is ... "special" :) [16:12] Indeed. === henninge_ is now known as henninge [16:29] does bzr use urllib for http and pycurl for https? [16:29] by default [17:17] Given that format 2a doesn't support subtrees what's the most current subtree compatible format? From "bzr help other-formats" it looks like development-subtree is the one, is that correct? [17:19] Hi! bzr push over sftp is causing me trouble: http://dpaste.com/153770/ [17:19] First push seems to have hit some kind of timeout somewhere. Now it looks as if things were in some form of inconsistent state. How can I recover from this, short of deleting and reinitializing the repo? [17:20] * MvG has to go AFK for a while, but would really love to read some advice when coming back. [17:22] muffinresearch: there are not any stable subtree formats [17:23] MvG: check using e.g. lftp whether the pack its trying to rename already exists in the packs directory [17:24] MvG: if it does, please file a bug - we should handle this case, and if you use bzr dump-btree repo/.bzr/repository/pack-names we can check if the new pack is actually referenced or not [17:25] lifeless: Are there likely to be in the future for nested trees? [17:26] once its finished, yes. [17:29] lifeless: ok, so if I want to experiment I can use development-subtree assuming I use bzr.dev? [17:29] sure [17:29] just understand we aren't making a strong commitment to whatever data you put in it at the moment ;) [17:31] lifeless: ok np! [17:36] kfogel, do you know if savannah is going to run the bzr smart server at some point? [17:39] jelmer: I'm sure they will at some point. How soon that point is is anyone's guess. They're actively looking for a volunteer to help them maintain bazaar on Savannah. I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high. [17:39] jelmer: but, you know, if you've got a lot of spare time on your hands... [17:39] * kfogel ducks [17:40] kfogel: :-) [17:42] jelmer: I'm only half kidding. You'd be much more competent at it than I would be. But if it's to be on Canonical time (which IMHO would be appropriate) then should obviously be discussed w/ manager. [17:42] hello kfogel, jelmer [17:42] 'evening Martin [17:43] poolie: hey :-). You know GNU is looking for a volunteer to help maintain Bazaar on savannah? [17:43] poolie: from backscroll: [17:43] jelmer: I'm sure they will at some point. How soon that point is is anyone's guess. They're actively looking for a volunteer to help them maintain bazaar on Savannah. I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high. [17:44] I've read the info at Bug#302987 and Bug#437626 and I'm still not sure what is holding up a 2.0.2 backport to hardy. I've got some time to volunteer would that help move 2.0.2 into hardy? :-) [17:45] lifeless: Now have an sftp connection. The 4c52ee0586adc8546ec9d26e89e64abc.pack it mentions does exist. Will now try the dump-btree... [17:47] lifeless: bzr: ERROR: pack-names is not an index of type . === keithhub_ is now known as keithhub [17:47] lifeless: For compatibility reasons that's an 1.6 format repo. Maybe that's responsible in some way? [17:52] lifeless: Got the pack-names by hand, and it seems that the pack in question isn't mentioned in the index. [17:52] lifeless: I'd now go ahead file a bug report... [17:53] MvG: please do [17:54] lifeless: I guess before I do I'll give current bzr.dev a go... [17:55] hey [17:56] MvG: no need, I can tel you its not fixed ;) [17:56] lifeless: thx. bzr.dev is giving me a hard time just now, for reasons unknown... [17:57] "bzr: ERROR: No module named testtools" in response to "bzr push". [17:57] hey [17:57] MvG: bzr.dev now depends on the testtools package [17:57] although I think it shouldn't need it for "bzr push" ... [17:57] yippieh! [17:57] lifeless: is testtools required for more than just the testsuite ? [17:57] no [17:57] but I bet its a buggy plugin [17:58] Want a bug report for that as well? [17:58] that is loading its tests on normal calls [17:58] MvG: please, with a backtrace [17:58] bzr --no-plugins push was in fact the first I tried. [17:58] MvG: try bzr push --no-plugins [17:58] MvG: oh, ugh. please yes file a bug [17:58] as I know bzr-svn complains about a version mismatch on a regular basis when used with the non-system bzr setup. [17:58] How do I get the backtrace for this? [17:58] -Derror [17:59] anyone who exactly knows how WorkingTree.update works? [17:59] yes [17:59] I think I fixed the double merge problem now [17:59] but I don [17:59] 't exactly know how it works now [17:59] :p [18:00] lifeless: thx. It's at http://dpaste.com/153798/ but will go into the bug report as well, once I manage to get that far. [18:00] it passes all selftests but I'm not sure that's enough [18:01] gerard_: how do you avoid the two merges? [18:01] jelmer: I don't, just do them in an order that will prevent the commits with itself [18:01] I just swapped the order the merges are performed around [18:02] and stop if there are any conflicts after the first merge [18:02] hmm, lets try that first sentence again [18:02] gerard_: why not just stop if the first merge conflicts? [18:02] gerard_: So you update the working tree to the local branch first [18:03] it stops when the first merge conflicts [18:03] jelmer: exactly [18:03] What's the suggested way to give large numbers of people access to a smart server? Is there some setup that does so with a single system account, using ssh pubkeys to differentiate users with different permissions, the way some git servers work? [18:04] now what? do I push it to launchpad and add a merge request? [18:04] I guess it might be a good starting point for someone who actually knows what is going on [18:05] any need for cleaning up the commit messages? I guess there may be some in dutch still [18:07] lifeless: when you don't swap the order of merges around you have trouble rerunning the update command [18:07] as it is not clear anymore that the branch you wanted to update from was out of date [18:07] at least, that's what I guess was one of the problems I has [18:07] had [18:08] also, it was quite illogical to first see the conflicts with the master [18:08] hmm, I was sure it did local branch first [18:08] anyhow, local first, then stop if conflicts sounds fine to me. [18:08] anyway, I have only a faint idea of what's going on and why, but I added some tests for the double merge, and it passes those and the rest of the selftests [18:09] if something is still wrong it is also a bug in the tests ;) [18:09] I'll try to push to launchpad now ;) [18:12] ok, it's at lp:~gerard-/bzr/update [18:12] note that this is unrefined ;) [18:12] not ment for actually merging in [18:14] whoops, let me check it again... it failed a test [18:14] lifeless: first issue reported as https://bugs.launchpad.net/bzr/+bug/516179 [18:14] Ubuntu bug 516179 in bzr "bzr push confused by existing pack file" [Undecided,New] [18:17] ok, fixed [18:17] lifeless: would be great if you could take a look at it [18:18] and maybe explain why I sometimes need basis and sometimes the lca for the second merge... [18:21] lifeless: And the other is https://bugs.launchpad.net/bzr/+bug/516183 [18:21] Ubuntu bug 516183 in bzr "sftp transport module requires testtools" [Undecided,New] [18:29] mwhudson: ping. I wanted to talk a bit about removing the revision graph cache whenever you have a sec. [18:45] brb, fixing a flat tire [18:49] gerard_: uhm, you are hacking on bazaar while driving a car?? [19:00] mkanat: hi [19:00] mwhudson: Hey. :-) [19:00] mwhudson: Are you around for a bit? [19:03] mkanat: i'm just starting work, so yeah :-) [19:04] mwhudson: Okay, cool. [19:04] mwhudson: So I've started to look into the possibility of removing the revision graph cache. I checked out bzr-historycache, and so on. [19:05] mwhudson: So, as I recall, loggerhead used to have a disk cache, but doesn't use it anymore (at least, not with serve-branches). Was there a reason we stopped using the disk cache? [19:05] mkanat: no, it does [19:05] it doesn't cache the revision objects themselves any more [19:06] because bzr got so much faster that stopped making sense [19:06] Ahh, okay. [19:06] mwhudson: Right, there's basically no reason for us to cache anything other than the revno -> revid mapping, right? [19:07] mwhudson: Because if we have that for a whole tree, we theoretically don't even need the actual graph for most of the pages. [19:07] mwhudson: Because we could just numerically sort the revnos. [19:07] it still caches files-changed info and the revno graph to disk [19:07] Oh, right, files changed. [19:08] (quite possibly caching files-changed info with 2a branches isn't needed) [19:08] mkanat: well, revno -> revid and revid -> revno [19:08] mkanat: and a few other things, tbh [19:08] Ah, yeah, both ways. [19:09] mkanat: look in history.py, the uses aren't hard to find [19:09] * mkanat nods. [19:10] mkanat: in particular i have no idea what get_merge_point_list is trying to do :-) [19:11] MvG: thanks [19:11] It seems like a lot of what we want to do really should be in bzr or in some plugin. [19:12] Though I can understand some cases where it's more appropriate for it to be in loggerhead. [19:13] mwhudson: I wonder if some of this is a holdover from hgweb. [19:14] mwhudson: BTW, have there been any more hangs with codebrowse? And is it actually still leaking memory? [19:17] mkanat: it might well be hgweb hangover, yes [19:18] mwhudson: I think what I'll do is just try to remove the revision cache and then do some profiling, and see which of the slow code paths are actually necessary.. [19:18] mkanat: seems reasonable [19:19] mkanat: excellent [19:19] mkanat: its been on the 'would be nice' for some time [19:24] mkanat: it does seem the loggerhead is hanging much less now, so that's good news [19:24] mwhudson: Cool. I haven't seen another hang reported in the log since the 19th. [19:24] I mean, in the bug. [19:25] nothing in the incident log either [19:26] mwhudson: Cool. [19:26] mwhudson: What about the memory usage? I couldn't really reproduce a leak after about 10 hours of trying, the other day. [19:26] it's using 1.2 gigs, which is a lot i guess but not crazy [19:26] Hmm. That does seem like a lot, though. [19:26] On my system it only uses about 300m. [19:27] I could make it grow to 1.5GB briefly (annotate a huge file) but it would shrink again. [19:27] mwhudson: That's 1.2B RSS? [19:27] *GB [19:27] mkanat: yeah, 1.5 gig VIRT [19:28] Okay. [19:28] I'd be interested to know if that's growing or if it's just huge on launchpad for some reason. [19:28] mkanat: i bet your loggerhead doesn't have 200k potential branches to look at :-) [19:28] mwhudson: Yeah, that's probably a lot of it. [19:28] mwhudson: The most I tested with was 50 branches. [19:30] Okay, I'm off to lunch. [19:30] BBIAB. [19:42] * gerard_ is back === keithhub_ is now known as keithhub === salgado is now known as salgado-afk === radoe_ is now known as radoe [20:35] Peng, coming back to my question if I had a workflow "repo - (trunk , branches - (fix2blah, fix3blah))" Would I want to have trees or not? [20:36] devmod: on your server, if you don't actaully do the work on it, wouldn't need trees. [20:36] when you branch from them to your local machine, it would auto matically create the trees for you [20:36] automatically* [20:36] ohhh i get it now.. i thought it talked about how the repo behaved in general [20:37] it does [20:37] no it doesnt [20:37] i mean it doesnt apply to users [20:37] the server repo is different from the local one [20:37] right, a server repo is usually created with the "--no-trees" option [20:38] but your local branches are really copies of that repo [20:38] but with trees [20:38] got it [20:38] so when I branch from lp:bzr I get a working tree of bzr, but the server doesn't have a working tree. just the repo's history [20:38] cool [20:39] (for some workflows you might want to have non-tree branches also locally, but that's probably too confusing for now :)) [20:40] so on this doc, http://doc.bazaar.canonical.com/bzr.2.0/downloads/pdf-en/bzr-en-tutorial-centralized.pdf, when they talk about optimization do they refer to no-trees or trees [20:40] "As an optimization, it is possible for related branches to combine their storage needs so [20:40] that you do not need to copy around all of this history information whenever you create a new branch." [20:40] no [20:40] % bzr init-repo --trees ~ [20:40] it means that they share the same repository [20:41] which means that it will be stored only once if the branches have common history [20:41] ok which has nothing to do with trees [20:41] correct [20:41] as Peng said, you can very easily remove or re-create the tree [20:41] thanks [20:41] yes [20:41] with bzr remove-tree and bzr checkout . [20:42] so you don't need to worry about that too much [20:42] are there any advantages having a dedicated server vs using ssh? [20:42] yes [20:42] most people are using bzr+ssh [20:42] so ssh with bzr remotelly installed (as a command line app) [20:42] so, it doesn't have to dedicated (in that it's the only thing running) but using bzr+ssh will cause less network round trips [20:43] it's "smarter" so it will cause faster checkouts/branches [20:44] i see [20:46] i was also reading http://wiki.bazaar.canonical.com/SharedRepositoryLayouts?highlight=%28repo%29|%28shared%29#nested-style-project-branch-sub-branch [20:46] in which they recommended having a separated repo for each project instead of a single repo containing all projects [20:46] can u elaborate on why is that? [20:47] well, there is a few reasons [20:48] one, is just organizational, if you have a project, having a separate dir is just easier to "conseptualize" but this is the least important reason... [20:48] the big reason is that when you create a shared repo, all the history and meta data is stored in the shared repo. [20:49] this means that if you have two different (unrelated) projects sharing a repo, you get lots of inter-mixed data in the shared repo [20:49] this makes that repo ineffiecient [20:50] The more "similar" the contents of that repo is the more efficient (space and speed) it will be [20:51] so that means you can keep all your task branches and stuff in the same repo, but if you have a project for your web stuff, and you have a project for client stuff with totally different histories and directions of development, its best to keep those seperatied [20:51] separated* [20:51] ohh i see ok makes sense [20:52] but if you have a project that as sub projects that share a lot in common, then you can keep them under the same repo (ie. Core web site and sister sites that share a lot of code) [20:54] it doesn't really make a lot of difference for most things [20:54] true. [20:54] just the more divergent your projects get under the same repo, the bigger that repo becomes. [20:54] same as two repos :P [20:55] I had a problem when I commited some history of an unrelated project in a shared repo, and then tossed out that project [20:55] my repo is still that much bigger, but I can't delete it because my other (good) history is still intermixed [20:55] you could implement the gc command for us ;) [20:56] gc? [20:56] garbage collect [20:56] ah, [20:56] haha [20:56] I'm not much of a developer [20:57] I mostly write the docs... although I haven't contributed too much lately [20:57] * rubbs looks down in shame [20:57] so as the repo increase in size, the slower it will get u say? [20:57] well. yes and no [20:57] most operations would be fine, especially if you still have a local copy. [20:58] when you have a local copy, a pull would only have to pull the difference rather than the whole ting [20:58] thin* [20:58] thing* BAH [20:58]