[00:00] lifeless, would you mind reviewing this? https://code.edge.launchpad.net/~abentley/bzr/unbreak-merge/+merge/19556 [00:01] ok, when it has a diff :) [00:01] abentley: perhaps it should try for the tree config and fall back to the branch config after that ? [00:01] abentley: rather than not permitting tree level configs? [00:02] lifeless, it was never trying for the tree config. [00:02] abentley: ah! then its trivially ok, JFDI [00:03] abentley: you seem to have unrelated stuff in the diff [00:03] lifeless, yeah, weird. [00:03] pages of it :). I suspect 2.0 -> trunk, or something ? [00:03] anyway, the intent of the change you describe is fine. [00:04] +1 [00:04] lifeless, Ah, I proposed it against 2.0 instead of 2.1 as I intended. === maxb_ is now known as maxb [00:18] mwhudson: The format of loggerhead/1.17 needs to be updated: [00:18] bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/.bzr/) [00:18] is not compatible with [00:18] KnitPackRepository('bzr+ssh://bazaar.launchpad.net/~loggerhead-team/loggerhead/1.17/.bzr/repository/') [00:18] different serializers [00:18] Or Peng, if you're around and mwhudson isn't, I suppose. [00:19] I got that trying to check it out over http, too, fwiw [00:19] its upgrading now [00:19] Yeah, I think it's because one is stacked on the other. [00:19] https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17 [00:19] lifeless: Thanks. :-) [00:19] there is a clicky clicky button in the webui [00:20] Ahh. :-) [00:20] mwhudson: is that button in the API now ? [00:22] lifeless: no idea [00:36] mkanat: is upgraded [00:36] lifeless: Thanks! :-) [00:36] justdave: ^^^ [00:37] does it need to mirror out or something? still getting the error [00:46] proxy cache on bazaar.launchpad.net needs flushing I suppose [00:46] there isn't one [00:46] there is however a mirrored copy [00:47] I'm poking, gimme a sec [00:50] upgrade didn't seem to do much [00:51] oh hi spiv [01:12] rockstar: where do upgrades get logged ? [01:13] rockstar: trying to upgrade https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17, it doesn't seem to be actually, well, /doing/ anything. [01:13] mwhudson: thumper: ^ perhaps you know [01:14] lifeless: i don't know anything off hand [01:14] hmm... [01:14] well [01:14] if we had abentley's job console, we'd be able to see something there [01:14] for now we just need to do db queries [01:15] ! [01:15] as in "ask a losa" [01:15] which we can't do [01:15] I would have thought it would log like imports to, to somewere about the branch [01:15] we do [01:15] but the logs are synced daily [01:15] that would let any user get an idea ;) [01:15] unless you ask a losa [01:15] that doesn't sound like the import system [01:15] it isn't like the import system [01:16] thats ok; I'm just trying to be clearer about my comment 'I would have thought...' [01:17] lifeless: noted [01:18] mbarnett: are you around? [01:18] thumper: should I file a bug that upgrade output isn't visible on the branch [01:18] lifeless: yes please [01:47] mbarnett: around? [01:47] mbarnett: https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17 isn't upgrading properly, we need a log looked at [01:54] morning all [01:54] hi poolie [01:54] igc: just! [01:55] lifeless: well I did some work in the morning 11 hours ago so it's morning #2 for me :-) [01:56] hello igc [01:56] igc: :) [01:56] i'm so glad parthm liked that [02:08] * spiv -> lunch [02:11] spiv/igc/lifeless: i'd like to turn off --verbose in 'make check' so that pqm failures are not so ridiculously long [02:17] https://code.launchpad.net/~mbp/bzr/trivial/+merge/19567 [02:20] poolie: it might be nicer just to turn subunit on [02:20] poolie: and let it run the entire test suite, so you get all the failures at once [02:20] nicer, but harder :) [02:20] the bug about this has a suggested recipe [02:21] bet you can't do it in one character [02:21] so you shouldn't need to think hard ;) [02:21] poolie: bet I can't either [02:21] but aside from that, yes [02:21] so it would send the whole subunit output? [02:21] it sounds good [02:21] especially with tribunal [02:21] yes [02:21] but it will kind of suck for people wanting to just look at the mail [02:24] so do xml test reports [02:24] which other projects do by default [02:25] if we could send mail with a short failure in the body and the subunit in the attachment that would be sweet [02:26] poolie: file a bug - I'm not about to do that immediately, but it certainly sounds nice. [02:26] in fact, I'd want all the failures in the body [02:30] hm [02:30] actually this could be mostly in subunit generally [02:31] sure. [02:31] anyhow, as I say the recipe has been hammered out for you [02:31] 'the'- 'a' recipe that should work [02:32] this is "how to run --subunit and have pqm still have teeth?" [02:32] yes [02:32] once we're doing that reliably I'll happily change PQM to go 'oh look subunit, I'll have teeth no matter what'. [02:32] but its harder to deploy pqm changes, so I don't want to do that willynilly [02:56] poolie: small present for you (apt) [02:57] ? [02:57] bug 22354 [02:57] Launchpad bug 22354 in apt "apt-cache doesn't differentiate sources that share protocol, host, release and archive name" [High,Confirmed] https://launchpad.net/bugs/22354 [02:57] oh yay === eugeneoden_ is now known as eugeneoden [03:05] straw poll: It's currently possible to commit a revision whose tree has no root, but this isn't well-supported. Should we forbid committing rootless trees or fix the support? [03:06] abentley: do you mean a root of TREE_ROOT, or actually no root ? [03:06] lifeless, no root, like the null: tree. [03:06] abentley: I thought that no root at all wasn't support; and that TREE_ROOT was dependent on the repo [03:06] abentley: and presumably no content either? [03:07] lifeless, no content either. [03:07] lifeless, it's possible to do when committing a TreeTransform or using the CommitBuilder directly. [03:08] abentley: I'm surprised. I can see a theoretical argument to permit it, but I'm fairly sure it would provoke a lot of bug reports from code assuming things have /some sort/ of root. [03:08] my poll response: forbid [03:08] unless you have a need for it, in which case - talk on [03:09] lifeless, I don't need it. [03:10] lifeless, the possible problems with forbid are: [03:10] lifeless, 1. if there are such commits in the wild already (I have no data) [03:11] lifeless, 2. If there's a risk that it will happen in the future, despite us forbidding it in a given codepath. [03:12] lifeless, end of list. [03:12] so, for 1 I'd expect that from custom code, not general use - as it has to be totally empty. I think its near-zero probability. [03:12] as for 2, well, we do what we can. [03:17] poolie, in your review, you say "I would like to see the actual code changed to be 'propose' not 'submit'.". This means changing class and module names, etc? [03:17] yes [03:20] poolie, this is an underhanded scheme to make me write some tests, isn't it? [03:20] :) [04:04] poolie: regarding turning off --verbose in make check, it hasn't really bothered me greatly, so I'm pretty neutral on the idea. I agree that it would be nice to get the failure(s?) in the body and the complete log as an attachment. === eugeneoden__ is now known as eugeneoden [04:05] spiv, ok, [04:05] poolie: with some test suites it can be helpful to have a "I'm running test X now" log in case one test hangs, but historically that hasn't been much of a problem for bzr. [04:05] spiv: pqm does that [04:05] spiv: for subunit, now. [04:05] lifeless: right, but that's not turned on (etc etc) [04:05] true [04:06] Gotta run; later. Ring or SMS if you want me. [04:06] (I see you just had this discussion, I don't mean to make you go in circles!) [04:09] hi igc? [04:15] poolie, it would have been nice if you had raised the canonical_url thing earlier in the process. [04:15] sorry [04:16] just because it's better to get the whole review in one go? [04:16] poolie, I think that replace('api', '') is a much worse idea than replace('https://api.', 'https://code.') [04:17] poolie, because "api" can easily appear anywhere in the URL, while "https://api" is really unlikely to appear anywhere other than the front. [04:17] i know [04:17] otoh this function won't work for bugs [04:17] poolie, because I feel like either I do it the wrong way to get it merged, or I have to do another round. [04:17] hi poolie [04:17] anyhow it's gross that this is not provided by lplib [04:18] well, it's negotiable [04:18] let's look [04:18] it's time to get this merged [04:18] poolie, rationale for removing the https:// ? [04:18] i keeping wanting to use it :) [04:19] actually [04:19] never mind about the replacement [04:19] i would kind of like you to point to the bug, and to think about changing the name [04:19] either expression is kludgy and mine isn't especially better [04:19] poolie, the name in the Launchpad codebase is 'canonical_url', which is why I used that name. [04:19] oh ok [04:19] fair enough [04:20] note that i'm using replace(x,y,1) which is maybe more robust against the term /beta/ turning up later in the url [04:20] i don't know if that will actually happen [04:20] poolie, canonical_url is not exposed over the API because it's a function, and functions don't exist in our REST API. [04:21] right [04:21] but perhaps it should be in lplib? [04:21] or for that matter it could be an object property? [04:21] as it is, variations of this code are copy-and-pasted into every lp api client [04:21] spiv, to follow up from before [04:22] poolie, this should definitely be provided elsewhere, ideally through the REST API directly. [04:23] poolie, and making it an object property would be a reasonable way of doing that. [04:23] spiv, http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html#backports discusses the use of bugtasks for backports [04:23] patches welcome [04:23] and that page is just impossible to find :/ [04:23] igc, is anything still needed on escudero or did the cron job run ok? [04:23] poolie: ah right, I did find that eventually actually, but not before mailing you [04:23] abentley: ok so feel free to merge without changing that [04:23] poolie, but that wouldn't be a 1:1 reflection of the native API. [04:24] poolie: the cron job kicked in thanks [04:24] what is 'that'? [04:24] poolie: we still need a bzr.2.2 directory as requested by jam [04:24] and for those files you emailed me about to be deleted [04:24] poolie, providing the URL as an object property on all REST API objects. [04:24] poolie: I don't seem to have permissions to do any of that [04:26] igc, ok [04:26] abentley: ok, well, i hope it gets solved somehow [04:26] igc: i want to unfold the 'enhancing bazaar' section in http://doc.bazaar.canonical.com/bzr.dev/developers/ [04:27] it's too hard to guess where the bug guidelines would be [04:31] poolie: fine with me. Go for it! [04:31] * igc lunch [04:37] igc, new page is nice, go for it [04:37] poolie: thanks [04:48] spiv, what do you think of my suggestion at the bottom of https://bugs.edge.launchpad.net/bzr/+bug/376388 [04:49] Ubuntu bug 376388 in etckeeper "~/.bazaar created owned by root (when run under sudo)" [Medium,Confirmed] [04:50] poolie: hmm [04:50] poolie: now is the time in the 2.2 cycle to try that sort of idea out :) [04:51] i was going to suggest parthm try it [04:51] Hi poolie. I just saw your comment "backport to 2.0 sent to pqm" and didn't understand it. (on https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483) [04:51] poolie: I guess the most obvious failure mode is "directory writeable by me, but not owned by a user I can chown to" [04:51] hey [04:51] i mean, i cherrypicked your fixes onto a branch of 2.0 [04:51] and have sent it for automatic testing [04:52] poolie: is this about porting the backup.bzr perms? I have that against 2.0. Was waiting for the final merge in trunk so that any additional changes can also be put in. [04:53] Oh cool. Then I won't bother. [04:53] yeah, it's ok [04:53] generally speaking it's easier to do the review and merge against the older branch first [04:53] and then we can merge it forward [04:54] poolie: for the case of writing to a file/dir in $HOME, I think your suggestion is good... I haven't thought of any likely scenarios where it will be worse than the status quo [04:54] Yes. I was thinking of merging 369501_2.0_ver_on_bzr_cmd forward to 2.1 and 2.2. [04:55] We typically tend to just merge all of 2.0 into 2.1 periodically (and 2.1 into 2.2, etc) [04:56] Oh OK. Then should I just let that be for now? [04:56] That sounds like a good idea. [04:56] you can just let that be for now [04:58] OK. I had a question regarding fixing of bugs. Is there a policy on deciding if the bug should be fixed againt 2.0, 2.1 or trunk? [05:03] poolie: the site upgrade has been merged now. I'm not sure how often the cron job runs but it will hopefully be live soon [05:05] poolie: I'll grab some lunch, reply to some support Qs and then take a look at templating next. Getting rid of manual updates will be good I think [05:07] parthm: there's a little bit about it at http://doc.bazaar.canonical.com/bzr.dev/developers/cycle.html#bug-work (and the "Feature and Performance Work" section too) [05:08] parthm: we probably should have a more formal description somewhere, I think maybe poolie has sent one to the list at some point? [05:08] parthm: roughly speaking, the safer and more valuable a bug fix is, the more likely we are to accept it into stable branches [05:09] Speaking of docs, is there some good way to make random sweeping statements about parts of them needing skilled work? [05:09] Thanks spiv. I will go through the docs and also see if I find something on the list. [05:13] So a fix for a very rarely hit bug that has a significant chance of other regressions, we wouldn't accept that for 2.0. [05:14] But a small, obviously correct fix for something pretty visible we would. [05:15] fullermd: "good" in what sense? In the sense that people won't be offended, or in the sense that saying it will cause the docs to be improved? :) [05:15] Well, the former is nice (though in this case, I doubt anybody who'd be offended would still be around :p), but the latter was more what I was thinking. [05:16] (And they aren't necessarily mutually exclusive options, of course) [05:16] I'd talk to igc about that, then. [05:16] I could mention it here, and have it disappear. Mail the list, probably ditto. File a bug, it ends up being one of those overly-fuzzy "X could be improved" sorts of things... [05:17] He seems to be pretty good at building enthusiasm for that sort of work in a way that causes stuff to happen. [05:18] And more importantly, why am I being disturbingly general when I have something specific in mind? [05:18] The "Performance Roadmap" needs rewriting. Big chunks of it talk about things we'd like to evaluate based on 0.16 for use in a possible pack-ish format. This doesn't seem important to have prominent in our docs. [05:19] fullermd, I'd consider that a historical document at this point. [05:19] Well, there's still some good stuff in it about minimal-work evaluation of various commands too, so it doesn't (at first glance anyway) seem like a "OK, we can just discard this now". [05:20] But making it up-to-date useful is pretty skilled labor, so it's not low-hanging stuff. [05:20] fullermd: I'd say that's possibly a specific-enough issue for a bug report [05:20] fullermd, some of that will be out of date too, as we've gained more experience and implemented different things. [05:21] Yah. Hm. I guess I'll put it on my list to try drawing up a few specific slices on it and file something. [05:21] See, this is why I avoid reading docs. It just leads to more work :p [05:22] For that matter, the "Bazaar Release Cycles" doc needs to be updated; it's still written as a proposal, when it's now fact. [05:33] fullermd: it's true it's out of date but [05:33] it's real audience know tha [05:34] you can put up a patch that deletes stuff you're pretty sure is obsolete [05:34] a lot of it is [05:34] i share your doubts about the value of bug reports like that [05:34] vague ones [05:36] Yeah, it's tricky. I know enough to believe there are parts of it that are still useful going forward, but not to be sure which parts qualify (and those that do need updating too). [05:36] It probably ends up being not so much even "clean out obsolete", as "take useful bits and make a differently targetted article around them" :| [05:37] Right. [05:37] Y'know, to occupy all that spare time everybody has going to waste. [05:37] I mean, in its current state it's barely useful at all; I know I haven't referred to that doc for ages, even though as a developer I am in the target audience for it. [05:39] right [05:39] i'd welcome someone being a bit deletionist there [05:39] we can always get it back if we remember something was useful [05:45] Agreed [05:46] igc, blah, the doc/www directory is root-owned [05:46] poolie: yep ;-( [05:47] Another idea: Twisted IIRC has a 'historical' directory in their docs for docs that aren't worthless but are also nowhere near current. [05:47] yeah [05:47] we'll have them on the web in old branches though [05:47] fullermd: so if you're keen, delete away [05:48] igc i'll file an rt [05:49] Oh, I don't have a dog in it at all :) [05:49] Just struck me as worth mentioning while it was in my brain. [06:06] igc: rt sent [06:08] parthm: https://code.edge.launchpad.net/~parthm/bzr/262450/+merge/19483 bounced [06:11] poolie: I am not quite sure what to make of the error. On my system it appears the sftp tests were skipped. [06:11] 19 tests skipped [06:11] bzrlib.tests.blackbox.test_upgrade.SFTPTests.test_upgrade_url is leaking threads among 9 leaking tests. [06:12] Is this against 2.0? [06:12] well this was actually an ftp test [06:12] but they might be skipped because you need an external library to run them [06:21] poolie: These tests were skipped for me (FTPServerFeature). Installing medusa right now. [06:21] cool [06:30] igc, perms are fixed [06:30] so i now removed the thing i asked you about [06:30] poolie: thanks [06:32] just fixing the links to 2.0 docs [06:39] poolie: Its seems the higher perm bits were causing the problem. masking with 0777 fixes this. ie. "target.mkdir('.', stat.st_mode & 0777)" in copy_tree [06:39] cool [06:39] well spotted [06:40] i've got to go now but i'll have a look tomorrow [06:41] OK. Good day. Will push the changes. [08:12] * igc diinner [08:13] heya! [08:16] hi, I have a question about teams and bugs, anybody here? [08:17] I'm here, but I doubt I know the answer. [08:19] np, poolie helped me already on #launchpad [08:19] :D [08:19] I was right, I didn't know the answer to that question. :D [08:24] but you know answers on many others, I'm sure [08:24] :) [08:54] hm, bzr merge gives me a pretty confusing error message: http://paste.ubuntu.com/378919/ - am I doing something wrong or is bzr in lucid just not handling this correctly? [08:58] Even "bzr log -r 98 lp:~lifeless/ubuntu/lucid/apt/bug-22354" fails. Perhaps the branch is screwed up? [09:16] thanks peng, I guess lifeless needs to check, I imported the patch via a download now [09:35] mvo: I would suspect a damaged branch [09:36] mvo: perhaps try branching it locally, and using that copy [09:36] mvo: and if the local copy fails, try 'bzr reconcile' on it [09:36] mvo: (and please do file a bug) [09:39] spiv: thanks, reported as #523703 [09:40] spiv: branching locally makes it all work it seems === Wellark1 is now known as Wellark === bigjools is now known as bigjools-lunch [13:27] good morning. Can I discuss a use case with someone before I set this repo up. We have a src license for our ERP system, so we do our own enhancements and modifications. This code is not repackaged. The code is in 3 main dirs, one of which is a vendor branch. [13:28] the number packages to trac are 1121, 278, and 5359. The dir with 1121 is the most active [13:29] for the 1121 and 278 dirs, we have a prod bracnh and test branch [13:30] i am trying to decide between one repo with 5 dirs or 5 repos [13:30] any advice is appreaciated === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === bigjools-lunch is now known as bigjools === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado === froosch_ is now known as froosch === beuno-lunch is now known as beuno === deryck is now known as deryck[lunch] [17:42] How does the Bazaar project itself merge changes into multiple stable branches? [17:43] slestak: I know this is a little late, but if you still need help I might be able to give you some advice to your question [17:44] davidstrauss: I'm not sure what you're asking. Are you asking how they merge branches into multiple "versions" of bzr? Like if a fix affects 2.0 and 2.1, how do they get the fix into both? [17:44] rubbs: exactly [17:45] rubbs: You know, without pulling other 2.0 or 2.1 changes into either. [17:47] I'm not a dev with commit access, so I don't know for sure, but my guess is that they keep the originating branch open and merge it in multiple branches. For example: fix_branch is merged into 2.0 and that fix_branch is kept around and then merged into 2.1. When you merge a branch in, you don't automatically lose that branch. [17:47] but I'm not sure if that's exactly how they do it, since I don't do it myself ;) [17:49] rubbs: but if someone branches from 2.1 and writes a fix on it, merging that branch into 2.0 will pull all the missing 2.1 changes, too [17:50] ah, good point. [17:50] unless they export the changes as patches and apply those patches in manually. [17:50] honestly I don't know [17:51] rubbs: but that's not a merge :-/ [17:51] davidstrauss: you can merge specific revision ranges [17:51] Tak: I'm trying to avoid cherry picking, which isn't tracked. [17:56] No, bzr just always completely merges branches upward. [18:11] davidstrauss: the usual approach is to do it the other way around [18:11] do fixes based on older revisions and merge them to all the necessary branches === deryck[lunch] is now known as deryck [18:13] you've probably seen it before, but this page nicely explains an extreme variant of this - http://www.monotone.ca/wiki/DaggyFixes/ [18:20] hi all, I just installed bazaar and would like to change the location where it looks for the configuration files (by default in /home/username/.bazaar), could anyone help me please? [18:21] Why do you wish to change that? [18:22] because i installed bazaar in a usb, so i'd prefer if the config files are in the usb too [18:23] You can set BZR_HOME in your environment to point at the USB stick I suppose [18:23] but you'll have to always do that [18:23] alternatively you try changing bzrlib/config.py on the stick (specifically config_dir()) === radoe_ is now known as radoe [18:24] i see, i'll give the config.py option a try then, thanx :) [18:38] Thanks alot Kinnison! worked like a charm :D [18:40] james_w: are you still around? [18:40] I was wondering if you had a response to https://bugs.edge.launchpad.net/udd/+bug/508251/comments/3 [18:40] Ubuntu bug 508251 in udd "Failure to import when decoding changelog authors" [Medium,Confirmed] [18:41] hi jam [18:41] I've found the error for gnome-panel [18:41] which is iso-8859-1 data in the changelog portion [18:42] while we are searching for "[AUTHOR NAME]" sections. [18:42] I posted some possible fixes [18:42] and wondered which you would like to see me implement [19:02] jam: thanks for the analysis [19:02] jam: I'm not sure what the best would be [19:02] jam: we have to decode at some point, but deferring could work. [19:03] jam: perhaps try: decode('utf-8') except: try: decode('iso-8859-1') except: pass [19:05] james_w: right, I was thinking to do the double try as well [19:06] james_w: do you think it is reasonable to just do the regex match on the 8-bit string first? [19:06] and then deferring to after we at least find [ ] would save some effort [19:06] right [19:06] I think so [19:06] I think there might be a reason that it is that way [19:06] not necessarily a correct reason, but... [19:08] I think the idea was to handle re.UNICODE [19:08] but that would only matter if you were using '\w' [19:08] hello [19:08] rather than [^\]] [19:08] regex? [19:08] hi anddam [19:09] james_w: ^^ [19:09] hi there [19:09] jam: sounds about right [19:09] I'm not used to distributed VCS, can I import from a mercurial repository using bazaar? [19:09] jam: I think it might have been to UnicodeDecodeError using re.match on 8-bit strings [19:10] anddam: there is a 'bzr-hg' plugin which should let you convert [19:13] jam: is it a bazaar plugin? [19:13] anddam: yes [19:13] lp:bzr-hg [19:13] you'll need to have mercurial installed as wlel [19:13] well [19:14] jam: so to me it'd be transparent, wouldn't it? [19:15] I'm trying to pick up one in the triad and Google project hosting is something to consider [19:15] anddam: I don't think bzr-hg makes it as transparent as we would prefer [19:16] I don't think it yet supports 'round-tripping' [19:16] thanks, I'll check out [19:16] (pull from hg, commit in a bzr branch; push back to hg; pull back to bzr) [19:16] it probably will eventually [19:19] james_w: would you like to see a trace.mutter (or warning?) if we have to trigger the fallback? [19:19] why not? [19:19] just wondering if it is helpful or just noise [19:19] and wondering whether mutter or warning is appropriate [19:24] I'd say mutter it [19:24] though it probably is just noise [19:36] bye === salgado is now known as salgado-afk [20:24] bzr: ERROR: Tree transform is malformed [('unversioned executability', 'new-368'), ('unversioned executability', 'new-367')] [20:24] sigh [20:25] rubbs: hi, ty for seeing my previous request. I would like to discuss it if you have maybe 10 minutes. [20:26] sure, I'll be in and out, but I'll always respond within a few minutes at most [20:26] just a sec while I re-read what you were asking again. [20:27] ok, I remember my question now. Do any or all of these projects share similar code and/or history? [20:27] it is one project, with code divided in 3 dirs [20:28] 2 of the dirs have a PROD and TEST label [20:28] the 3rd dir is a vendor branch [20:28] so that can be taggeed every now and then if we ugrade [20:28] ah, I c. so you have the Vender, testing and production branches, but they are all based off of the same "core" code right? [20:28] yes [20:29] what I am afraif of if I set this repo to track too many targets, it will be slow for every operation [20:29] that is why I was thinking about maybe 3 or 5 repos. [20:29] then I would suggest doing a shared repo because they are going to share most of the same history. for the most part other operations won't be affected too much. [20:30] that would make sense, the code is all one erp app [20:30] the advantage of having them all under the same repo (with different branches) is saving disk space and merges etc between branches would go pretty quickly [20:31] yes. now. at the beginning, I am the only person motivated to use scm [20:31] i think that will be ok, I think for a time I will just have commit statements liek "Scale is workign on the website, isse 456" [20:31] hopefully without all the type, but not likely [20:31] typos! [20:31] haha [20:32] I do it all the tie [20:32] time* [20:32] haha [20:32]