[00:22] jml: http://pypi.python.org/pypi/testtools/0.7.8 [00:22] lifeless: yeah, someone filed a bug about it on the testtools launchpad page [00:24] :P [00:47] * SamB looks for the bzr reconfigure command to turn an SVN checkout into a BZR checkout [00:49] huh. it apparantly took it a while to figure out it can't do that ? [00:49] that was with --checkout [00:54] * SamB wonders why doing `bzr info --verbose' in his svn checkout of Coq uses so much CPU [00:56] info -v does some fairly silly things [00:56] it says something about browsing branches [00:57] info -v is a bit expensive for bzr branches, I can imagine it would be a bit ridculous with svn branches... [00:58] it's gone and crashed on me [00:59] SamB: bzr checkout fresh :). also perhaps file a bug on being abe to do the conversion via reconfigure. [01:00] upgrade? [01:01] james_w: what to ? [01:02] "bzr upgrade --default" might work [01:07] or it might eat you [01:07] 50-50 chance I reckon :P [01:07] mwhudson: search is fixed [01:08] lifeless: ta [01:09] maybe bzr should have a buildbot that tests a bunch of common plugins. [01:11] abentley: http://pastebin.ubuntu.com/129601/ [01:13] spiv: so have you satisfied your curiosity about that patch yet? [01:16] lifeless: more likely that it will just leave me with a working directory that isn't [01:16] rather than eating me === abentley1 is now known as abentley [01:17] http://pastebin.ubuntu.com/129601/ === mneptok_ is now known as mneptok [01:20] is someone writing a "bzr gc" command ? [01:22] jml: which patch? ;) [01:23] jml: you mean https://code.edge.launchpad.net/~jeanfrancois.roy/bzr/url-safe-escape/+merge/3417 ? ;) [01:23] SamB: actually, we were talking about that last night. [01:23] SamB: the new 'fetch_spec' part of the fetch API may make it pretty easy to write. [01:24] lifeless: did you add multiply_tests and so on in the same landing as removing adapt_tests? [01:24] spiv: yes that one -- the one that's blocking your review of my patch :P [01:25] jml: I don't actually see your patch [01:25] mwhudson: yes [01:25] spiv: that sucks. [01:25] what is revision.timezone stored as? [01:25] mwhudson: also, separately, see lp:testscenarios [01:25] or what does 43200 translate to? [01:25] lifeless: that makes life difficult for us :/ [01:25] thumper: 12 hours [01:25] how so? [01:25] thumper: assuming that's seconds [01:26] is the timestamp on a revision stored at UTC? [01:26] (doesn't everyone know that there are 86400 seconds in a day?...) [01:26] lifeless: it's much easier if i can land a launchpad branch that passes with bzr-as-in-sourcecode and bzr.dev [01:26] spiv: I sent it to bazaar@lists.canonical.com [01:26] last time i got spm to do a simultaneous landing i ended up getting phoned up when i was in a bar [01:26] spiv: but I haven't got any bundle buggy mail about it. [01:27] mwhudson: sorry about that [01:27] jml: I haven't got it at all, I doubt bb has either [01:27] jml: I'll check the mailman moderation thingy [01:27] thumper: heh, it's ok, but it motivated me towards doing things the other way [01:27] maybe i can just copy-paste bits of testscenarios into launchpad temporarily... [01:28] spiv: is the revision.timestamp in UTC? [01:28] mwhudson: but we were trying to make you look important by ringing your phone while you were in the bar!?!?! ;-) [01:28] jml: nope, not there either... [01:28] spm: heh heh [01:28] spiv: maybe gmail is broken. [01:29] spiv, jml: "list server is currently backed up" [01:29] thumper: no [01:29] thumper: its in revision.timezone [01:29] mwhudson: where's that from? [01:29] jml: #is on the private server [01:29] lifeless: so the utc time would be: revision.timestamp - revision.timezone ? [01:29] mwhudson: ahhh [01:29] thumper: there are normaliation functions around [01:30] lifeless: where? [01:30] in bzrlib [01:30] lifeless: can you be a little more explicit or shall I just grep? [01:30] I would be grepping to [01:30] ok [01:31] I have a small page cache :) [01:31] lifeless: really? [01:31] lifeless: I thought it was large [01:31] size is relative; I last looked at tz stuff about 2 years back [01:32] mwhudson: ta [01:33] btw, if someone wants to merge http://people.ubuntu.com/~mwh/extract-make-branch-scenarios-4109.patch [01:33] ,,, [01:33] ,,, [01:33] ... [01:33] ! [01:33] (also currently somewhere between here and bb) [01:35] mwhudson: looks sane and near-trivial to me, I'll merge. [01:35] spiv: thanks! [01:35] oh, looks like robert already did :) [01:37] mwhudson: oh :) [01:37] mwhudson: even better. [01:40] :P [01:43] mwhudson: sorry re: single landing, but its easier for bzrlib to not have duplication [01:47] i just want to delete this code from lp :( [01:52] lifeless: I was just talking with jamesh about revision.timestamp [01:53] lifeless: observations on the lp scanner would be that it is recording the timestamp in utc [01:53] lifeless: but the code seems to indicate localtime [01:53] lifeless: now I'm confused [01:55] thumper: See bzrlib.repository.CommitBuilder's __init__, it defaults the timestamp to time.time(), which is seconds since the epoch, in UTC. [01:56] ah so it is utc :P. oops :) === UdontKnow is now known as root === root is now known as UdontKnow [01:59] spiv: i would hope seconds since the epoch is timezone neutral! [02:00] * mwhudson sees jamesh making the same point in another place [02:02] mwhudson: it measures time since the epoch assuming that every day has only 86400 seconds [02:02] hmm, say I'm writing an elisp program and I want to know what the default destination for "bzr send" is ... how should I do it ? [02:04] SamB, hi [02:04] mwhudson: I'm just quoting the official docs :) [02:04] jelmer: hi! [02:04] SamB: You filed a bug about being able to run "bzr reconfigure --branch" in a svn working copy [02:05] jelmer: yes [02:05] mwhudson: if you want to improve them, you're the one with the commit privs for python, not me ;) [02:05] I'm either for or against [02:05] SamB, that doesn't make sense though, as subversion doesn't support working copies that carry a branch [02:05] SamB, you would have to upgrade to a bzr format first [02:05] jelmer: oh. why first? [02:05] that sounds inefficient [02:05] SamB, That's how reconfigure works [02:05] and also why does it take reconfigure so long to figure that out ? [02:05] SamB: "bzr upgrade" is really "bzr change-format" [02:06] SamB, it's pretty much instantaneous here [02:06] plus, the bzr upgrade part doesn't seem to work either :-( [02:06] (but usually the only time you want to change format is to upgrade to a newer, better one, hence the name.) [02:06] jelmer: what SVN server ? [02:06] SamB, gnome [02:07] huh. and you don't live in gnome? [02:07] SamB, it might do some analysis of the repo first, but that should be cached [02:08] jelmer: I don't see why it needs to analyze the remote repository just to figure out it can't do a reconfigure in that directory! [02:09] SamB, reconfigure probably looks at the branch tip before it tries to initialize a branch [02:10] and that requires bzr-svn to do some analysis [02:11] well, okay, lets move on to Bug 340854 [02:11] Launchpad bug 340854 in bzr-svn ""bzr upgrade" fails rather slowly on SVN working directories" [Undecided,Confirmed] https://launchpad.net/bugs/340854 [02:12] SamB, I've just commented on that one [02:12] oh. I wish it didn't take so long for email to make it from launchpad to gecko ... === bob2_ is now known as bob2 [02:14] * SamB frowns at Low [02:15] SamB, You can just checkout from svn in the proper format [02:15] jelmer: shouldn't it check whether or not it can finish the job before starting ? [02:16] it rather rudely moved all these directories in my checkout ... [02:16] oh, and I'm not quite sure what it failed to do, either! [02:16] why'd it leave me like this: [02:16] control: Meta directory format 1 [02:16] working tree: Working tree format 4 [02:16] branch: Subversion Smart Server [02:16] repository: Subversion Repository [02:17] isn't that a little insane ? [02:17] SamB: This is what I mentioned in my bug report, there's no way for bzr-svn to control the upgrade process [02:18] s/bug report/bug reply/ [02:18] SamB, Bazaar just assumes WorkingTree format 4 knows how to upgrade from a svn working copy [02:18] but it doesn't and blows up [02:21] jelmer: well, now I'm bitching about how Bazaar just assumes that [02:21] excellent new bzrtools. Off a packaging I go [02:22] SamB: yeah, that's a real bug [02:23] SamB: not many users try to "bzr upgrade" bzr-svn branches to other formats, but we would like it to work. [02:23] how would i make bzr st and friends just show the filenames themselves without the path [02:23] any idea what the "conflict adding file" business was about ? [02:23] spiv: or at least fail at the beginning instead of half-way ? [02:24] like: cd /working_path/foo/bar; bzr st [02:24] SamB: that would be a start [02:24] and all the files are prefixed with their paths... [02:24] SamB: actually working would be better :) [02:24] even if i do bzr st * [02:25] Hey all. I've been asking around a bit about this and spent anumber of hours on this. I was just curious, was there a good way to basically create a "glue" between git and bzr? TBH since I use git for 90% of my work, I'd prefer to be able to manage the bzr repositories I need to through git as well. I've read about the fast-export and fast-import, but have been having a lot of problems getting this all to work correctly. [02:25] and, of course, bzr-svn should be the package responsible for determining whether or not it works ... [02:26] SamB: right. The problem is that the upgrade code in bzrlib isn't yet flexible enough to let bzr-svn hook in when it needs to. [02:27] TDT, I'm working on a plugin called bzr-git that allows accessing git branches as if they were bzr branches [02:27] hmm, well, for some reason I decided to re-run the "bzr reconfigure --checkout" command after the "failed" upgrade run ... it hasn't failed yet, but there's still plenty of time for it to get around to failing ;-) [02:28] jelmer: oh, there isn't one yet? [02:28] and will it interoperate with git-bzr ? [02:28] SamB, bzr-git is a work in progress but doesn't support e.g. writing to git yet [02:28] jelmer: *nod* yeah I've been using git-bzr for the opposite of that, it's out of development now,and...the guy has no reason to bother, heh. [02:29] SamB: well, it won't recognize shared history with git-bzr [02:29] hmm. git-bzr isn't in my package database. maybe I don't care. [02:30] http://github.com/pieter/git-bzr/tree/master -- this is the project I was talking about [02:30] It's not standard included with git-0core, it's an addon. I don't know if others exist [02:31] TDT, yeah, I'm aware of it [02:31] TDT, it basically allows access to bzr branches from git, whereas git-bzr allows access to git branches from bzr [02:32] jelmer: you got your package's name backwards [02:32] jelmer: Yeah, but I'm kinda assuming both rely on the git-fast-export/import and bzr-fast-export/import, am I right? [02:32] TDT, no, bzr-git doesn't use fastimport/fastexport [02:32] Hmm, definitely perked my interst in how you got that to work then [02:33] SamB, whoops, sorry - it's getting late :-) [02:33] I want something that works the opposite, but it relies on way too many dependencies that it's causing issues..been a real pain anyways. Been reading way too much on it, it may turn into something I need to work on more over time. [02:33] hey, it's an easy mistake to make, especially in that conversation ;-) [02:34] TDT: what do you mean with "something that works the opposite" exactly? [02:34] TDT, bzr-git does more than just fetching from git into bzr and vice versa [02:34] TDT, it allows all of the Bazaar API to be used with git repositories [02:34] (or that's the goal, anyway) [02:35] jelmer: Yeah, I understand that. Your solution goes from the idea of using bzr as the baseline. My goal is to do the opposite, use git to read bzr branches and use git commands and "push" changes to a bzr bound branch. [02:35] jelmer: will it allow bzr upgrade --format=git ? [02:35] SamB, No, as the upgrade code in bzr isn't flexible for that yet as we've just concluded :-) [02:36] SamB: In due time, yes [02:36] jelmer: but you said it was the target format that was responsible for providing the conversions [02:36] so I figured that might be okay then ;-) [02:36] can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa [02:36] SamB: Right now the target format is responsible, it should be a combination of the source and target format though [02:36] spiv: https://lists.ubuntu.com/archives/bazaar/2009q1/054539.html [02:36] jelmer: yeah [02:38] TDT, I thought git-bzr just depended on ruby and fastimport/fastexport ? [02:41] jelmer: it does, it's going by a different idea than what you're doing - which is why I'm pretty interested in what you're doing :) For whatever reason the whole fastimport/fastexport thing is horribly broken for me right now [02:42] TDT: Something like bzr-git wouldn't be possible in git, as it doesn't have an API that's abstracted like bzr [02:44] TDT: It's just a collection of command-line tools with a specific file format [02:44] hmm. too bad git-fast-export doesn't support ASCII armoring of binaries ... [02:52] SamB, hmm [02:52] SamB, the fact "bzr upgrade" breaks the working copy is a bit annoying indeed, I've upgraded the bug to medium [02:57] :-) [02:57] * SamB wonders if this second "bzr reconfigure" is going to work [02:58] SamB, it might, but only because the working tree is now workingtree format 4 [02:58] yeah, I figured that was why it had gotten as far as it has [02:58] [######/ ] 18995kB @ 2kB/s | copying revision 3363/10231 [02:59] that looks about right [02:59] I'm just wondering if it's going to (a) crash part-way through complaining about [02:59] bzr: ERROR: bzrlib.errors.NoSuchRevision: has no revision svn-v4:c7f1d35c-780e-0410-8b2b-bc164f6bbeca:coq-local/trunk:8620 [03:00] or something else wierd [03:00] or ... will it actually work ? [03:00] SamB: Is there any reason you're upgrading an existing svn working copy rather than just doing "bzr branch " ? [03:01] jelmer: well, I might have some local changes [03:01] that, and I like trying things to see if they work [03:02] SamB, well, the latter is certainly appreciated :-) [03:03] and if they don't, I like them to fail as gracefully as possible [03:03] * SamB goes to bed [03:03] SamB, bug reports like these are useful, even if they're blocked by bzr :-/ [03:03] you're welcome [03:10] anyone? can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa [03:11] johnf: if they work for you, jfdi [03:11] -> lunch [03:12] fair enough. Only real issue is people will need a newer builddeb package [03:12] why's that? [03:14] <- lunch [03:14] james_w: it works but has an annoying deprecation error [03:14] usr/lib/python2.5/site-packages/bzrlib/plugins/builddeb/revspec.py:68: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12. [03:14] SPEC_TYPES.append(RevisionSpec_package) [03:14] about to go see if there is a bug [03:15] it's fixed [03:15] excellent [03:15] it's just a warning though, so it shouldn't prevent things working [03:26] jml: i'm using lp-open a lot now, thanks for doing that! :) === ja1 is now known as jam [04:23] poolie: AllowDeactivateGrabs in man xorg.conf [04:25] note that that setting effectively kills the security of the screen lock [04:25] kill the grab and alt+tab away from the screen saver [04:25] because people can send input to tasks behind it? [04:25] heh [04:26] DisableXorgBugs true [04:27] it isn't a bug: the feature works as advertised. [04:27] and there is a reason it is disabled by default [04:28] jamesh: actually, there is a new api for screen savers [04:28] if you need it and are not developing X software that performs grabs, then that is a bug [04:28] An API was written to such cases. If you enable [04:28] this option, make sure your screen saver/locker is updated. [04:28] jamesh: there are bugs; see under software [04:29] for instance, drag and drop in gnome takes grabs [04:29] and firefox === abentley1 is now known as abentley [04:52] hm [04:53] what are the chances that the latest change to bzr.dev will end up in 1.13? [04:53] i guess i can always cp it onto the branch of bzr we use === abentley1 is now known as abentley [05:04] mwhudson: should be pretty uncontroversial for a cherry pick to the release branch if you want to mail the list about it [05:09] mwhudson: what was it? [05:11] pulling out the branch scenarios generation to a helper [05:11] poolie1: moving the generation of branch scenarios into a separate function === abentley1 is now known as abentley [05:36] mwhudson: did you get the chk repo? [05:37] vila: p:~james-w/+junk/favourites-package [05:37] with an l of course [05:38] should we remove the feisty 1.12 packages from the beta ppa seeing as feisty is now EOL? [05:40] johnf: so, bzr-builddeb, what about it? [05:40] lifeless: works fine just a deprecation warning [05:40] which is already fixed in trunk [05:41] johnf: are you going to upload the fixed version to the ppa? [05:41] that was my next question. bzr-beta ppa doesn;t currently have builddeb packages. Do we want it to? [05:41] let me do a straw poll [05:41] I vote yes and am happy to make it happen :) [05:42] jelmer: are you going to create new bzr-svn packages in the beta-ppa or would you like me to do it? [05:44] johnf: so, mostly 'shrug', one 'no', couple of yeses [05:45] so - do it, I think. I'll wear the blame if its wrong :) [05:45] cool [05:46] lifeless: next thing is best way for me to get my packaging changes commited [05:47] I could just branch those repos into beta-ppa or maybe we just move them [05:47] probably makes more sense to have them there since most of the packaging work will happen in beta and then the final packages can just be copied to the bzr ppa [05:48] james_w: thanks ! [05:48] vila: no problem, let me know if the instructions aren't clear === abentley1 is now known as abentley [05:53] james_w: I'll do that [05:58] johnf: let me rename them [05:58] johnf: The price is that you update the docs and put forward a [MERGE] with the changes [05:59] I already have a heap of edits for ppa.txt that I'll put up soon [05:59] also some changes to the packaging scripts [06:00] johnf: what are the branches you need access to [06:01] lifeless: lp:~bzr/bzr/packaging-* although you can probably kill off feisty and lp:~bzr/bzrtools/packaging-* [06:02] oh hmm [06:05] johnf: ok, the easiest thing here is for you to join the bzr team [06:05] you'll get bugmail; but you have procmail ? :) [06:05] johnf: the ppa docs about joining the beta team to be able to do this are probably necessary but not sufficient [06:06] I have sieve but yes :) [06:06] ok [06:06] is it easier to just branch them into beta an pull every so often? [06:08] no, easiest is to give you lots of mail [06:09] fair enough [06:10] if thats ok [06:11] in a technical sense we probablt want a bzr-ppa team, which has bzr as a member, and owns all th epackaging branches [06:11] and is a member of bzr-betta-ppa, bzr-ppa, etc etc [06:11] but right now, JFDI time :) [06:11] whats your lp account name? [06:12] johnf: ^ [06:13] lifeless: johnf-inodes [06:14] done [06:32] New way to break the test suite: put a bzrdir in /tmp with a default_stack_on in its control.conf [06:32] slick [06:32] Bzr or Git? How do they differ? Why do you prefer Bzr? [06:33] http://bazaar-vcs.org/BzrVsGit [06:45] I heard about an SCM that was sprung from "mathematical" theory - with operations of more "logical" nature, supposedly created by academic people... anyone know what im talking about? [06:47] possibly monotone, or codeville, or darcs [06:51] must be darcs [06:51] thanks lifeless [06:57] Smiskis: no probs [07:05] vila: "Wed Mar 11 06:43:20 2009 UTC: Vincent Ladeuil , Request for non-PQM managed branch." ie your branch is going to bounce [07:08] pwd [07:13] poolie1: same for yours! [07:13] i know === poolie1 is now known as poolie [07:30] here's an interesting thing: orcadas got noticeably faster when it was upgraded to hardy [07:30] some combination of kernel and python [07:30] pqm could possibly get faster too [07:42] poolie: running parallel tests would probably be faster too :P [07:43] hi, anybody with Python 2.6 installed? I need a little help to check 2.6 behavior [07:43] bialix: sure [07:43] poolie: ooh, you broke bzr+ssh :P [07:44] can you check stream attribute as I shown here: http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/53539 [07:44] I'd like to finish my patch, because igc is busy [07:46] spiv, do you get a failure in __repr__? [07:49] bialix: python 2.6 shows the same behaviour here as in your email [07:50] thank you! [07:50] I'll add simple smoke test for that bug and will send the complete patch then === abentley1 is now known as abentley [08:58] Hi, a patch I sent has to be marked as superseeded by another one in Bundle Buggy. I don't have a login. How do I proceed? === montywi|zzz is now known as montywi === kiko__ is now known as kiko [10:33] hi [10:34] what's the difference between bzt init and init-repo? am i right in thinking that to create a repo, i can either bzr init, and if no repo exists in the parent dir, it will create one in the current dir? [10:37] init-repo doesn't create a branch [10:38] that's the main difference [10:38] that, and init-repo creates a repository whether you're in one or not, I assume ... [10:40] * SamB wonders what computer is pulling down data at 200K [10:40] init-repo creates a shared repository, that later branches can use (and share). [10:41] init creates a branch, which will use an existing shared repo if there is one, or create an internal [private, non-shared] repo if there isn't. === fullermd_ is now known as fullermd [10:42] oh, it can't be shared ? [10:42] init won't make a shareable one, no. [10:42] You could probably trick it into being sharable later by manual ad-hackery in the bzrdir. But I don't recommend it. [10:42] what's the difference between a shareable repo and an unshareable repo? [10:43] A shareable repo can be used in common by multiple branches. An unsharable one can't (and generally doesn't exist except hidden inside the branch that owns it) [10:43] Basically, a share repo is the only sort of repo you ever see or interact with in any way. [10:44] You never create a non-shared repo, it just happens when you make a branch that can't find an existing shared repo to use. [10:45] This also means that colloquially, any time somebody talks about a "repo", they almost certainly mean an explicitly-created shared repository, unless they're discussing internals or relatively arcane implementation details. [10:46] * SamB contemplates bzrcrush [10:52] thanks guys, that helps a bit! [10:53] a la git, switching from one branch to another in the same dir is simply a matter of checking out the different branch, how do i do this with bzr? the init-repo --no-tree option is confiusing me [10:54] That's probably a side effect of init-repo --no-trees not really having much to do with that problem :P [10:54] (well, it's usually a step in the process, but doesn't directly bear on it) [10:54] oh [10:54] trying to wrap my head around the user guide [10:55] The central command to think about in that case is 'switch', which throws a working tree from one branch to another. [10:55] is the only way to create a separate branch in a new dir and then merge? [10:55] George2: did you see the GitStyleBranches wiki page? [10:55] SamB: no? [10:55] well, it's kind of new [10:55] fullermd: oh, so just simply bzr switch newbranch [10:55] Yah. [10:56] wow, nice [10:56] Details like setting up a --no-trees shared repo are often parts of _setting up_ a layout where you later do that. But they're not strictly speaking necessary parts of it. [10:56] what's the no-trees option for then? [10:56] George2: are you using a lightweight checkout? [10:56] SamB: no, trying to get my head around normal checkouts! [10:56] oh, it just keeps your storage branches from having working trees [10:57] lightweight is history-less right? [10:57] Basically, it all makes a bit more sense if you grok the triumverate of Working Tree, Branch, and Repository. [10:57] George2: oh ;-) [10:57] lightweight is good for doing git-style switchable branch checkouts, actually [10:57] Don't worry about lightweight vs heavy checkouts, at least at the start. The differences shouldn't affect the semantics (if they do, it's probably a bug), and it can be a little confusing. [10:57] fullermd: oh? [10:57] fullermd: the userguide is great from what i've read - half way so far, but the intro about explaining the terms is perhaps the only weak part [10:58] what about the parent/push paths ? [10:58] (not to say the differences are unimportant, but..) [10:58] I'll agree that other differences are probably bugs [10:58] doesn't lightweight only affect what is pulled - ie. branch history? [10:58] See, this just goes back to my periodic bitchings about leaky abstraction on [heavy] checkouts :p [10:58] but don't try to convince me that bzr isn't full of bugs of that sort ;-) [10:59] George2: Basically, just use this rule of thumb; if the branch is on the local machine, use a lightweight checkout. If it's on a remote machine, use a regular (heavy) checkout. [10:59] oh [10:59] anyway, if you have a --no-trees repo with your branches in it in the next dir over, you still have all the history right there ;-) [10:59] well i'm looking for a single-dev local maching setup [10:59] I mean, assuming that's what the lightweight checkout is bound to [10:59] except depending on the project, my workflow may change, so i'm just trying to wrap my head around it all! [11:00] should i have a repo for each project, or can i have a projects dir? [11:00] anyway, if you do look at the GitStyleBranches page, please give any comments about what isn't clear enough [11:00] SamB: url? [11:01] Generally, a repo per project is a good demark. [11:01] I don't bother unless I actually want more than one branch [11:01] You could stick everything in one repo. Or you could not use shared repos at all. Or anywhere in between. [11:02] But sharing a repo across projects generally gives very little gain. And using more than a very few branches of one project without one is pretty wasteful. [11:02] http://bazaar-vcs.org/GitStyleBranches [11:02] George2: I can see why you wanted the URL [11:02] it doesn't really google too well yet, does it? [11:04] google's top hits on the wiki are RecentChanges and WordIndex ... [11:04] fullermd: i'm looking for a way to store a cms core, and modules for the cms. i essentially would like to be able to checkout the core files, and then the modules. but i maintain some modules, so can i have a repo inside the modules repo for each module i maintain? [11:05] Well, you can put one shared repo under another in the filesystem. But they don't have anything to do with each other. [11:05] I'd generally discourage that, just because it can open up chances for you to get confused about what's where. [11:06] SamB: first line: [...] it's true than many Git users like its approach and it does have benefits worth noting: -- add some context, does the quote refer to git or bzr? [11:06] George2: refers to git [11:06] fullermd: oh, so what solution would you suggest? [11:06] at least, I assume [11:07] George2: is that what you thought? [11:07] should i have a repo for others modules, and a repo for mine? [11:07] SamB: after reading a bit yeah, but it's not immediately clear. this is your site right? [11:07] oh no, sorry - hehe [11:07] * George2 checks the url ;) [11:07] I did make the wiki page though [11:08] but I didn't write that part [11:08] copied it from the linked section [11:08] Well, a lot depends on just how much breadth you get. [11:08] I mean, if you only have one branch of a given module, a shared repo buys you nothing. [11:09]