> On May 16, 2016, at 7:13 AM, Alex Zavatone <z...@mac.com> wrote: > > Would it make better sense to use a workspace at the top level, have that in > a git repo, then each of the sub projects in their own repo? Structurally, > this seems to actually be proper.
Personally, I’ve never used an Xcode workspace. Instead, I just nest projects. I’ve just never run into a situation where I want a container that has no function except to aggregate other projects. Anyway, first consider whether you actually want multiple Git repos. This adds flexibility but also a lot of complexity. It’s useful if the components are separable enough that people would be using one without another, or if they’re developed by separate teams. If you do, then I don’t know if you can just drop one Git repo into a source tree that’s part of another repo. This configuration would confuse other source control systems I’ve used, because operations on the top-level repo will descend into the tree of the nested repo and think it controls them too. In any case, this is an unstable situation because there’s no relation between the revisions checked out in the multiple repos. You can just check out any revision of each, and they may not work together. If you ever want to roll back time and go back to an earlier version (and of course you do, that’s why you use version control) you’d have to consult some chart of which revision of A goes with which revision of B. Instead, you want to use either Submodules or Subtrees, which will link the revisions together. I use Submodules. This is a complicated topic and I don’t have time to explain it; but if you search you can find tons of documentation (and SourceTree supports both.) —Jens
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
