Rogan Dawes <lists@xxxxxxxxxxxx> wrote: > Shawn Pearce wrote: > > > > > - Higher level projects should drive subprojects. > > > > Higher level projects tend to be composed of specific revisions or > > specific generations of subprojects. > > > > Part of the content of the higher level project is just what > > those subproject specifications are and how those subprojects > > should appear in a working directory. > > > > > > >I used the term "generation of subprojects" as not everyone wants > >to bind their root project to a specific revision of a subproject. > >Indeed that may not be entirely practical. Instead just a particular > >lineage of development (e.g. "Version 1.0" vs. "Version 1.2") > >may be all that is needed. > > > > Does it not make sense that a commit of the higher level project should > include the contents of its subprojects at that particular moment in time? If the subproject is a Git repository we can simply record a commit SHA1 or a tag SHA1 and assuming we can locate the objects for that repository in the future we can fully recover that subproject. No subtree tracking necessary. If the subproject is an SVN repository we can simply record the branch/tag path and the specific revision number and fully recover that subproject, assuming we have access to the central SVN repository. If we don't or we are concerned about that then we would want to use git-svn/git-svnimport to mirror the SVN repository and treat it as a proper Git subproject. If the subproject is a Monotone or Darcs project I believe we could also store some small token for a unique directory state of that subproject and recover that from Monotone or Darcs without importing the entire subproject into Git. If you don't trust Monotone or Darcs then maybe you should be importing/mirroring that project into Git. At which point its a proper Git subproject. If the subproject is CVS then you either need to trust the CVS tag or import the tree into Git. If you are going to import the tree into Git then you might as well just treat the subproject as a proper Git subproject and use some sort of CVS import or mirror to keep that in sync. Etc... My basic point here is that a subproject already has its own SCM and if its not Git you probably either are going to convert it to Git via a Git bridge (git-svn anyone?) or you are going to keep it in its "native" SCM as you probably don't want to incur the disk costs of storing it twice (once in its native SCM and once in Git). So subtree tracking is probably unncessary. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html