Johannes Schindelin wrote:
Hi,
On Tue, 26 Sep 2006, A Large Angry SCM wrote:
20060926.1715
You forgot the time zone ;-)
UTC of course. ;-)
[...]
After skimming your text, I imagine that it should be possible (read:
easy) to write a really simple script which does what you describe,
storing the relevant information about root or sub projects in the config.
However, you left out one of the most important aspects of subprojects:
the ability to manage the state of the root project: you can add, update
and remove subprojects.
Since each project can have subprojects, the root project is special
_only_ in that the initial checkout is _not_ handled by the build
machinery (make in my example). This means that adding and removing
subprojects should be no different for the root project. A subproject
should be able to stand on its own (with its subprojects); otherwise,
it's not a project but instead a directory tree versioned separately.
A while ago, Junio started playing with a new object type for subprojects
so that you could have tree objects containing subprojects in addition
to tree objects and blobs.
Which I though was awful. Subprojects are really much better managed by
the build machinery; it's more flexible and doesn't require all the
separate projects to use the same VCS.
Of course, the difficult thing about this is to teach all tools to behave
sensibly with the new object type.
And teach all the tools to gracefully handle subprojects using a
different VCS ...
Now, your approach of having multiple clones (sharing the object pool) is
more simple than Junio's approach: no need to introduce a new object type,
or adapt existing tools.
Taking this a step further, how about managing the root project in this
manner:
A root project is a branch containing just one special file,
"root-project". This file consists of lines like these:
-- snip --
f80a17bf3da1e24ac904f9078f68c3bf935ff250 next
03adf42c988195b50e1a1935ba5fcbc39b2b029b todo
-- snap --
The meaning: subdirectory "next" contains subproject "next" which is also
tracked in the branch "next" of the root project. Likewise for "todo". The
root project could even contain some administrative files like a Makefile,
a license, README, etc.
How the state (subproject list, branch names, etc.) is recorded in a
parent project is only important to the parent project. The parent
project must also know how to interact with with each of its subprojects.
For instance, if you were building some kind of internet appliance, it
could have a very large number of subprojects (kernel, various servers
and daemons, etc) with no common build tool or target set used by all of
them. What each parent project does in this situation is to "interface"
to the build machinery of each subproject so that when you command "make
appliance image" at the top level project, all the subprojects _and_ the
top level project do what is need to create the appliance image. The
appliance can depend on projects using many VCS'; Git for the kernel,
SVN for the web server, CVS for the SMTP daemon, Monotone for some other
part, etc.
You could even handle the update of root-project with each commit in a
subproject by a hook in that subproject's .git/hooks/post-commit, so that
you'd only need a script "git-checkout-root-project.sh" to initialize them
all, and probably a script "git-update-root-project.sh".
For _full_ subproject support, handling a tree of projects is required.
So treating the root project differently that any other parent project
(except of the initial checkout of the root project), means that you
can't work a subproject independent of its parent projects.
-
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