[00:06] lifeless, poolie: I'd like to put a patch up for per branch rules again [00:06] I'm thinking of a .bzr/branch/rules file that doesn't propagate [00:06] ala branch.conf [00:07] so some questions [00:07] Does that sound ok? [00:07] a) why not put it in branch.conf [00:08] I'll look into that [00:08] I suspect formatting might be an issue (but it might not if we agree to allow nested sections) [00:08] and sure, it sounds ok; presumably you need wt5 to use it, but you may be able to get away without a new branch format object as its not affecting historical data [00:09] (I honestly prefer new objects every time, but I get the objection folk have to that) [00:10] If it really affects the WT primarily, why put it in .bzr/branch/? [00:10] fullermd: that was my next question :). But I can come up with an immediate use case - checkouts [00:11] * fullermd doesn't follow. [00:11] igc: so here is a thing to think about [00:11] igc: consider a loom, or a git-branch-style setup [00:11] .bzr/checkout/ is always there (at least, unless there's no WT, in which case rules don't mean anything anywho) [00:12] igc: 'bzr switch foo' - that will have to backout-gone-and-apply-new rules [00:13] lifeless: yeah, good point [00:13] if it were .bzr/checkout/rules, that wouldn't be the case right? [00:14] igc: I think the root of the concerns I had about version-propogating rules derives from this basic thing; these transformations are inherently local to the tree object [00:14] but the proposed design really started/wanted to treat them as something related to the project - which we have no effective abstraction for [00:15] igc: right, .bzr/checkout/rules would keep a constant ruleset during 'bzr switch' [00:16] (in the absence of any other places for rules to be sourced) [00:16] lifeless: I expect tree-specific rules to override those in .bazaar/rules [00:17] igc: .bazaar/rules is constant for a single invocation though. I was referring to e.g. .bazaar/locations.conf based rules [00:17] (which is another case of trying to allow rules to be included in normal config files0 [00:21] hmm, I didn't mean to sidetrack things [00:22] getting a non-propogating tree-working-with-rules thing that people can use today++ [00:25] lifeless: thanks for the feedback. So I think we're agreed that .bzr/checkout/rules would be a step forward without causing obvious problems down the track? [00:31] igc: myself, I have a directory with all my trees for project X === ubott2 is now known as ubottu [00:31] igc: so *I* would want, until we have a good answer for 'project' to configure them in locations.conf [00:31] fullermd: implicitly knowing "the rules" just seemed the bzr way [00:32] igc: its where I configure email settings and default push locations [00:32] igc: which are the other project-wide settings I work with today [00:32] lifeless: I think we greatly under-utilise locations.conf as a feature of our product [00:32] One way to choose which problem to cause is considering the knock-on effects of each choice. [00:33] Like, if you plunked it in branch.conf, it could be used to try and force a resolution of the "allow per-branch config that propogates" chewtoy. [00:34] igc: I agree we want to end up with just knowing the rules, as much as possible [00:35] from memory, I originally proposed rules inside nested sections of branch.conf and locations.conf (and it got knocked back). Perhaps it's worth reconsidering that. I still have the branch supporting nested sections. :-) [00:35] lunchtime, got some chores to run too, back in a bit === Mario__ is now known as pygi [00:39] fullermd: yes [00:42] remind me, how do you change the branch location of a working tree? [00:42] say you've renamed the branch and want the tree to point to the new location [00:43] jml: "bzr switch" maybe? [00:43] spiv: it raises errors about the old branch not existing [00:43] Hmm, I thought I saw patches about that bug a while back. [00:44] The crappy way is to edit .bzr/checkout/something [00:44] Hmm - I'm talking crap. My nested sections stuff was related to defining shell hooks, not rules, it seems [00:45] spiv: there doesn't seem to be a reconfigure either. [00:45] perhaps switch could do something sensible if the working tree's basis revision existed in the new branch? [00:47] * Peng_ finally deletes old .pyc files. When was bzrlib/plugins/multiparent.py removed? :P [00:47] /renamed/whatever [00:49] Oh, heck, not even a year ago. [00:50] spiv: I filed https://bugs.edge.launchpad.net/bzr/+bug/313898 [00:50] Error: bug 313898 not found [00:51] Try bug 285055 and bug 308798 [00:51] Launchpad bug 285055 in bzr "switch --force on lightweight checkout connects to original remote branch" [Medium,Fix committed] https://launchpad.net/bugs/285055 [00:51] Launchpad bug 308798 in bzr "Unable to switch lightweight checkout when it's parent branch is renamed" [Undecided,New] https://launchpad.net/bugs/308798 [00:54] jml: thanks === Mario__ is now known as pygi [01:05] abentley: can you bounce BB please if you're around? [01:13] how would y'all feel about a bzr command that opened a branch's web page in Launchpad in the user's default browser? [01:15] jml, it would make me cry of joy [01:16] jml: we don't use Launchpad, so I wouldn't notice. [01:17] cool. I'll file a bug and say I'll mentor it (and maybe jfdi later) [01:21] beuno: https://bugs.edge.launchpad.net/bzr/+bug/313916 [01:21] Ubuntu bug 313916 in bzr "Command to open a branch's web page in Launchpad" [Undecided,New] [01:23] jml: now. If the branch metadata carried general notions like "our home page is $x, and our bug page is $y, etc" then a "Command to open a branch's web page" would be superlative. [01:23] AfC: yeah, I mention that on the bug. [01:23] jml: otherwise it's just another feature that makes people think that Bazaar is only for people who work at Canonical. [01:24] [as evidenced by the FUD in the latest GNOME VCS thread] [01:24] [but a) we're going to lose that one, and b) who cares, so that's not a very good example. The point holds, though] [01:25] AfC: the bug metadata is already there... it just has lousy APIs and not much in the way of command line access [01:26] jml: I would define that as "not actually there" then, but {shrug} [01:26] (o for a thousand days to hack) [01:26] indeed [01:27] but the sun is out, and it's 30℃, so forget hacking. I'm going to the beach. === Mario__ is now known as pygi [02:05] * igc lunch [02:15] If I deleted a file in one branch, and in another branch it was moved, how do I resolve the conflict when I merge that other branch, so that the file is deleted? [02:16] rockstar: if it was just moved it shouldn't conflict, if it was moved and edited then the edit will cause a conflict. Just remove it again [02:16] lifeless, I can't because the file doesn't exist... [02:16] rockstar: bzr st [02:16] Ah, bzr resolve worked. [02:16] Path conflict: / tools/run_debug.py [02:17] lifeless, ^^ === Mario__ is now known as pygi === Mario__ is now known as pygi [02:38] markh: btw with bugs [02:39] markh: you don't need to make things invalid on bzr, you can just edit the task to say its for bzr-gtk only === TheMuso_ is now known as TheMuso [03:31] spiv: ping [03:33] lifeless: pong [03:34] brisbane core has some networking implications [03:35] do you have a branch working on generating a stream [03:35] for push and pull [03:35] I do, for push. [03:35] http://people.ubuntu.com/~andrew/bzr/streaming-push (it's a loom) [03:36] cool [03:36] are there docs on the wire format you're putting together? I'd like to collaborate on that early [03:37] also, have you looked at what git does to determine the objects to include in its wire transfers? [03:42] lifeless: hmm, no docs yet, although it's still in flux a bit. [03:43] lifeless: it's more-or-less a series of bencoded tuples of the attributes of the ContentFactory objects returned by get_record_stream [03:44] And no, I haven't looked at what git does. Or rather, I've looked a bit, but I didn't manage to locate any clear docs on the subject so I went and did something else :) [03:44] ok, well to figure out anything git does I've found reading the source the best way [03:44] I don't suppose you have a bzr mirror of the git source handy? ;) [03:45] nope [03:46] what about the actual delta content [03:46] uhm [03:46] * jelmer has enough knowledge about the git wire protocol now that he's implemneted it :-) [03:46] let me be more precise in a couple of ways [03:46] jelmer: what I want is the algorithm for determining objects-to-include and objects-we-can-use-deltas-against [03:46] jelmer: I take you used the source to learn about it? [03:46] jelmer: if you could write that up that would be great [03:47] lifeless, that's two different processes [03:47] basically what happens is: [03:47] jelmer: things like is it chatty, does it assume cheap heads-lists, does it use the reflogs and so on [03:47] -> server sends list of HEADs it has [03:47] <- client sends "want " for each it wants to end up with [03:47] jelmer: this is push or pull use case? [03:48] jelmer: also is this full duplex or back and forth on each item [03:48] then the client starts sending "have " for the ancestors of its local heads, until the server confirms it has one of those revisions [03:48] lifeless, this is pull [03:48] lifeless, it's full duplex [03:49] so the client may see one of the acks from the server too late, but that's not a problem as sending a couple more "have "s is way cheaper than spending a roundtrip on each revision [03:49] breadth first traversal I presume [03:49] yup [03:50] after this process, the server sends the complete contents of a .pack file that can be written to disk immediately [03:50] and it does this per-local-head or all-in-parallel? if its all-in-parallel, does it trim when a particular head is reached [03:50] or just keep going until all have had revs reached [03:51] or until any-rev is reached? [03:51] [I can rephrase this as - whats the algorithm, as opposed to the mechanics:P] [03:51] all-in-parallel [03:52] it obviously stops sending "have " for the ancestors of a particular head as soon as the server has confirmed it knows about a particular head [03:52] it obviously stops sending "have " for the ancestors of a particular head as soon as the server has confirmed it knows about a particular *ancestor* of that head [03:52] doesn't it need to know all ancestors? I mean, consider a:[b,c] [03:53] if the server says it knows b, and we want a (but don't have a) that doesn't imply that the server has c [03:53] erm bad example. a:[b,c], b:[d,e] [03:53] yes, it needs to know all ancestors [03:53] want: a [03:54] anyhow, this is not surprising, its what I thought it did :) [03:55] the key differences to bzr are server-state-is-accrued and full-duplex [03:56] yeah, it's not rocket science but it is a really fast protocol [03:56] these are only rev ids though right, it doesn't recurse into dir objects at this stage [03:57] it infers those when building the pack [03:57] ? [03:57] lifeless, yes [03:57] lifeless, same for what to delta against what [03:57] secondly, I thought git had thin packs for pull and push [03:57] what are thin packs supposed to be? [03:57] which were *not* written verbatim to disk but instead expanded to meet the normal assertions about pack content [03:57] they are packs which have deltas external to the pack [03:58] lifeless, ah, right [03:58] lifeless, but at least as far as I can tell, those can exist in regular git packs as well [03:58] and if not, we have a dulwich bug :-) [03:58] oh also the HEADS list is something we try not to do, because that list can be _big_ [03:58] no, they are not meant to exist in regular git packs [04:00] lifeless: sorry, it's the list of refs in the case of git, not the list of heads [04:00] I don't think there's an easy way to find all heads in git even, short of scanning the repository (much like bzr) [04:00] jelmer: ah goo [04:00] *good* [04:01] so thats name:revid? [04:01] basically, yeah [04:01] ok [04:01] spiv: back to our discussion [04:01] hth [04:01] jelmer: it was useful [04:01] jelmer: still not clear on the logic for whats assumed held by the client for thin packs [04:02] lifeless, what do you mean with held by the client? [04:02] lifeless, what sha1-objects are held by the client? [04:02] jelmer: if you wanted to dig that up it would be interesting. (imagine a local repo with alternate A pulling from repo B - a thin object reference that is in A and not local would require another network op to fix the thin back (see git-index-pack --fix-thin). [04:02] lifeless: so, the current struct I send for a record is (sha1, record.storage_kind, record.key, parents, build_details, record.get_bytes_as(record.storage_kind)) [04:03] lifeless: jam has asked that I add the compression parent to that, for obvious reasons. [04:04] lifeless, "alternate A"? [04:04] lifeless, there is no such thing as ghosts [04:04] jelmer: look up git alternates - stacked repos [04:05] spiv: well compression information should be specific to the compressor [04:05] Right, that would be ideal. [04:06] I think you should refresh your memory of http://www.kernel.org/pub/software/scm/git/docs/technical/pack-format.txt at some point soon [04:07] just as a reference [04:07] e.g. we don't need the sha1 in this stream, its dead space. We can sha the entire stream for integrity checking [04:08] what are the build details? [04:09] record._build_details for 'knit-*' records, otherwise blank (signified by an empty tuple). [04:10] spiv: have you looked at group compress [04:10] Not recently. It's probably about time I refreshed my memory. [04:10] ok [04:10] basically [04:10] lifeless: As far as I can tell there's no particular special-casing for alternates so that would indeed require another network op [04:10] label: [04:10] sha1: [04:11] CONTENT [04:11] rinse and repeat, thats the entire format [04:11] lifeless, not entirely, the delta'ed entries don't have a sha1 [04:11] Basically the serialisation at the moment is pretty simple-minded, it just dumps out the attributes so that it's easy for the remote side to construct an equivalent object. [04:12] it will not fit at all well into what you seem to be proposing [04:12] spiv: yeah, thats what we did last time, and why I want to engage on this early ;) [04:14] nm, I thought you meant the separate entries [04:14] * jelmer gets some sleep [04:15] first suggestion I'd make is that your current bencode tuples be marked as substreams - a pathological case if you like (only one element) [04:15] but that would allow a number of group compress streams to be embedded [04:15] So, which things are constant for all records, and which can vary? [04:16] each of which contain N actual texts [04:16] (key, sha1, record_kind), and everything else depends on record_kind? [04:16] nope, a step up [04:16] stream = [substream ...] [04:17] substream = gcstream | knitstream | weavestream [04:17] knitstream = [bencode tuple ...] [04:18] gcstream = to be discussed (does it support parent meta-data, or is that forced up a level, etc) [04:18] weavestream = a weave verbatim [04:18] Ok, although that doesn't fit 100% neatly with the get_record_stream API. [04:18] it should fit perfectly [04:20] (the intent of get_record_stream is to be a least-assumption API, not to reflect what is in a wire byte sequence) [04:21] Ok. [04:22] I was thinking about stacking, but I guess that's handled by the caller of the repo(s), not the repo itself. [04:22] that was one of the problems with the prior network stream - it was setup to fit the knit api [04:22] but the knit api was random access and quirky [04:23] I'm not sure how stacking fits in here [04:25] is there a way to do 'bzr log -r(tag:foo+1)..' [04:25] after:/ [04:25] ? [04:25] dunno [04:26] spiv: so the fact there are knitstreams as subelements wouldn't be exposed by the api [04:26] nope [04:26] There's no "after:" rev spec. There's before:, but that's easier to define. [04:27] I guess after: might be well-defined in the context of a particular branch. [04:28] spiv: as for the individual text record, sha1: is redundant IMO, we should be aiming to regenerate the text as we receive it to determine the sha1, to prevent bad data being sent to us [04:28] lifeless: right, taking bytes off the network and turning them into a stream is straightforward there. But taking a stream and turning it into bytes seems less neat to me. [04:28] spiv: which is supported by the record stream API (None for sha1) [04:28] Probably you just peek at the first record to figure out what sort of (sub)stream to serialise. [04:29] well [04:29] a stream->bytes adapter would be nice [04:29] I imagine it would start with an empty output stream [04:30] then start eating records and outputting them as bytes, with record-storage-kind adapters to do things like eat all the records of a weave but output just the weave [04:31] [though weaves are a bad example because they just generate FullTextContentFactory objects, as I wanted 'works' not 'optimal' [04:31] ] [04:31] git-pack-records, for reference, holds a little metadata about every object, then decides based on that how to retrieve it and how to include it [04:32] (e.g. to just copy it, or to extract and redelta, etc) [04:33] concrete example though, in gc, record.get_bytes_as(record.storage_kind) -> nonsense-data [04:39] so, I started at 730 this morning, I'm going to call it now ;) [04:39] gnight poolie spiv igc jelmer etc etc etc [04:39] night lifeless [04:40] lifeless: g$timeofday [04:43] time to hit the review Q [04:44] if anything is particularly important in there, let me know [05:00] you know what would be great, if bzr was psychic enough to know I was idiotically pushing to the wrong branch... [05:01] DBO, so write a plugin offering mind-reading functionality. It's Python, right? -- there's probably a module for that. [05:02] yeah... [05:02] i should... but if we are going to read minds [05:02] we'll have to use lisp [05:03] DBO: it'll tell if you're pushing to a diverged branch. You want something more than that? [05:04] jamesh, mostly I am just noting that due to the wonderful way bzr remembers branches (really, I do love it), i often push to the wrong branch after a merge [05:04] or when i mean to merge =P [05:05] its really just me being stupid and coming to share a bit of feedback with you guys [05:06] i do have a real question though [05:06] is it launchpad or bzr that is god awfully slow for pushing and pulling? [05:12] DBO: mainly bzr, its getting fixed [05:13] lifeless, mind sharing whats going wrong, just for the curious [05:26] btw, I read something on python-dev that said Bazaar was "experimenting" with a time-based release process. [05:26] I chuckled a little. [05:28] jml: we even inhale! [05:28] spiv: :D [05:36] jml: maybe in a few years we'll find out if it was a worthwhile experiment [06:58] hi all and happy new year [07:10] hi vila! [07:12] vila: g'evening. [07:54] How do I change the parent branch url? I used to just do "bzr pull" in one of my local branches, but I've moved the branch on launchpad, and I can't seem to figure out how to get my local branch to cope with that. [07:55] soren: "bzr pull --remember NEW_URL" [07:56] *facepalm* [07:56] Of course. [07:56] spiv: Thanks! [08:05] spiv, vila: are you received mailing list emails this afternoon? [08:05] seems to be blocked somewhere? [08:06] igc: hmm, last one seems to date back 7 hours ago... [08:06] vila: thanks - so it's probably not me or my ISP then. :-) [08:09] igc: but I got mail from lp 2 hours ago [08:28] * igc dinner [08:28] night all === kiko is now known as kiko-afk [12:34] err, why is "bzr shelve" simply throwing away things and not actually shelving them? [12:35] abentley: is bzr shelve broken? [12:36] Keybuk: Not in my experience. [12:36] I do bzr shelve, it puts changes in "id 4" [12:36] then bzr shelf ls says [12:36] Patches on shelf 'default': None [12:37] (and then seems to leave the checkout locked) [12:37] bzr 1.10-1~bazaar1~intrepid1 [12:37] bzrtools 1.10-1~bazaar1~intrepid1 [12:37] The shelf command is from shelf1, and the shelve command is from shelf2. [12:38] err? [12:38] You want "shelve --list" [12:38] bzr: ERROR: no such option: --list [12:39] Are you sure you said shelve --list, not shelf --list ? [12:39] yup [12:40] Ah. --list is in not supported by 1.10. It'll be in the next release. [12:40] does shelve do something different now then? [12:40] where does it stash the changes? [12:41] Keybuk: Yes, shelve is much more thorough now. It stores the changes in .bzr/checkout/shelf [12:41] as patches still, or as a branch? [12:45] Keybuk: as a serialized TreeTransform. [12:45] I'll pretend I understood that so I look smart ;) [12:46] Keybuk: Essentially, as a delta-compressed working tree. [12:47] if you unshelve and there are conflicts, does it still throw the whole thing away? :p [12:48] No, when you unshelve, it does a merge. [12:48] bbl [12:50] \o/ [15:42] *sigh* [15:42] after I branched from a svn trunk... [15:42] someone had the bright idea of making part of that trunk read-only. [15:42] which makes merging back into it... non-trivial. [15:43] This place does not grok version control. === beaumonta is now known as abeaumont [17:01] I just did 'bzr shelve' in an svn checkout without realising it, and ... I'm quite surprised it actually works [17:36] LeoNerd, integration ftw (-: [17:37] indeed [17:50] jelmer, Loggerhead 1.10 landed in Jaunty. You rock, thanks [17:51] * jelmer hugs ubuntu autosync === menesis1 is now known as menesis [19:13] i think there's a bug in bzr-email [19:14] i think it does not honor post_commit_difflimit=0 like the docs say [19:14] emailer.py line 119 [19:14] i get empty commit emails when i set it to 0 [19:15] i'll just set it to 100000 for now === menesis1 is now known as menesis [19:45] poolie, ping [20:07] hi, i made a mistake and a file is corrupted, how can i get last commit of just this file? [20:08] burak575, bzr revert -r -1 path/to/file [20:08] beuno: thanks i am gona try it :) [20:09] it worked thanks again [20:09] np === Mario__ is now known as pygi [20:45] hi guys. I've been working as a private branch, and I'd like to make this a shared repo. I created a repo with init-repo. How do I now push all of the history of the branch to this repo? [20:46] Is the repo above the branch? [20:46] repo is in /srv/bzr/myrepo project is in /development/projects/myproject [20:47] Mmm. Are you wanting to move your working location over to that new spot? [20:48] no I want to keep working in /development, but have that bound to /srv/bzr/myrepo so that I can use that as a centralized repo [20:49] I work like that with another project, but its been like that since day one. I'm wanting to move this over [20:49] So, what you're wanting to have, is a branch in /src/bzr/myrepo/whatever, that you have a checkout of in /dev/projects/whatever. === bac is now known as bac_afk [20:50] I suppose so. But its a repo created with init-repo [20:50] Well, /srv/bzr/myrepo/project/whatever then; doesn't change anything substantial. [20:51] So what you need are actually 2 things; first, you need a branch at that new place, and second, you need your old place to become a checkout of it. [20:51] The first you can do with push; just push the existing branch to the new path. [20:51] (or use 'branch' to do it from outside; either way) [20:51] isn't a branch different to a repo? [20:52] Yeah, but you've made the repo already, right? [20:52] yeah [20:52] So the new branch (whether it be push-made or branch-made) will use it. [20:52] Other than making a repo, you pretty much never do anything that refers directly to it; it's implicit. [20:53] well I did bzr push /srv/bzr/myrepo [20:53] and bzr status shows that my working area is a checkout of the repo [20:54] but the file size of the repo is too small to have any history in it [20:54] Well, it's not technically an error to have a branch colocated with a shared repo, especially if it's no-trees. [20:54] OK, let's back it all up. Can you pastebin an 'info' output of both locations? [20:54] oo i forgot the no-trees bit [20:55] No big deal. That just sets a default. [20:55] You can use 'remove-tree' to whack the WT you don't need. [20:56] brb 2 mins going to get on main pc [20:57] that's better [20:59] right so my /srv/bzr/myrepo shows shared repository: . repository branch: . [21:00] So, yeah. That's a little unusual maybe, but it's valid. [21:00] i can just delete this repo and start again [21:00] I just want a centralised repo that I can access via SFTP from many machines [21:01] and unbind when I have no interwebs :) [21:11] FWIW, to make a repository no-trees, just touch .bzr/repository/no-working-trees (and for the reverse, delete it) [21:12] Perhaps someone can explain this workflow to me. In SVN, I would make a repository, and that would contain my branches. So how would I achieve that with bazaar, and what happens when I create / delete branches? [21:12] In svn, the repository has significant semantic meaning. In bzr, it doesn't. [21:12] right, I'm getting confused at the difference between a repository and a branch [21:13] There's no semantic difference between having 15 standalone branches in /srv/bzr/myproject/, or having a shared repo in /srv/bzr/myproject/ with 15 repo branches. [21:13] It just saves space and I/O. [21:13] ok, so how does a 'repo branch' differ from a standalone 'branch' ? === toytoy_ is now known as toytoy [21:14] CaMason, it stores data in the repository -- and thus doesn't have duplicate data stored between it and any other branch in that repo -- but that's under the hood; from a user perspective they're *exactly* the same [21:14] All branches have a repository; that's where the revisions are stored. Standalone branches have their repository internally; repo branches use an external shared repository (which presumably is also being used by other branches) [21:15] right ok this makes more sense [21:15] (this is a slight lie, because some side effects can leak through the abstraction, but it's near enough that you can ignore them) [21:15] Perhaps an example would help here. I basically have multiple clients, with multiple projects [21:16] so I have /srv/bzr/clients/myfirstclient/ [21:16] then myfirstclient will have multiple projects. So each 'project' would be a shared repository? [21:16] That would be one way to do it. [21:16] CaMason, so if /srv/bzr is a repository, and you push from the branch at /srv/bzr/clients/myfirstclient/project1 to a server that client owns (for instance), they get only the bits they own.. [21:16] And probably the best way. [21:17] You could have one repo for client. Or one repo for all your clients. Or one repo for all your bzr stuff. [21:17] CaMason, ...and the above is how I personally would do it, were fullermd (who knows better than me) not advising otherwise. [21:17] Or, the other way, one repo per branch (e.g., a bunch of standalone branches). There's not necessarily a right way. [21:17] However, you probably don't have much (or any) shared code between projects. So, spanning projects with one repo probably doesn't gain you anything. [21:18] ok. I've probably still got my SVN hat on somewhat [21:18] one repo for everything is maybe not a good idea for locking reasons [21:18] no, none of the projects will share any code [21:18] if multiple users are going to push to that [21:18] CaMason, oh -- if they don't share any code, then there's no need to have shared repos. [21:18] And some operations will necessarily scale to the size of the repo, so a single huge repo for everything may have some performance implications. === sdboyer is now known as morloch [21:18] CaMason, ...but if you're going to have different branches of any given project, you *will* want to have those branches within the same repo -- makes branching much cheaper (in both space and time) [21:18] I tend to have approximately a repo per project. It lets me keep things nice and organized. [21:19] right. So for a particular project, I may want to 'branch' the code off to work on two lines simultaneously === morloch is now known as sdboyer [21:19] so how do I branch that differently to a normal 'branch' procedure? [21:19] Having a repo per branch (bunch of standalone) wastes a lot of space and I/O. Having repos spanning projects gains very little, so... [21:19] CaMason, it's just a normal branch, as long as the path you're branching into is under the repo directory. [21:19] No differently. [21:19] I see. We're making progress :) [21:20] When you make a new branch /some/where, it will look and say "Hm, is there a shared repo at /some/where? If so, use it. If not, is there one at /some? Use it. If not, is there one at /?" [21:20] I see :) [21:20] And when it runs out of parent dirs to check, and hasn't found one, it makes a standalone branch. [21:21] Now, this means that if you have a branch in a repo at /some/where/repo/branch/, if you move that branch to /some/where/branch/, things will blow up, because it can't find its repo anymore. [21:21] right [21:21] But if you move it to /some/where/repo/extradir/branchfoo, it'll still work just fine, because it finds the repo at ../../ [21:22] (UNLESS you make a repo in extradir too, in which case it'll find that repo, but it doesn't have the revs branchfoo wants, in which case it'll blow up too) [21:22] makes sense [21:22] But you don't tend to run into situations like that, because you hardly ever make one repo inside of another, or move branches in and out of repos with mv. [21:23] ok, does this first part make sense then: http://pastebin.com/m2d6df460 [21:23] Why rich-root? [21:23]