Junio C Hamano wrote:
A Large Angry SCM <gitzilla@xxxxxxxxx> writes:
Junio C Hamano wrote:
...
Having said that, I do not necessarily agree that highly modular
projects would want to put everything in one git repository and
track everything as a whole unit.
And yet that's exactly how a lot of developers use CVS. You can argue
that some other way is better but when they move from CVS they're
looking for continuity of productivity which often means not radically
changing how they work. At least in the short term.
[...]
I suspect that everything-under-one-roof approach is coming from
an observation that:
- with CVS, projects that share the same cvsroot can be updated
with single 'cvs update' command in a directory close to the
root.
- with git, if you use multiple repositories checked out at
right places in the working tree hierarchy, you need to run
around and say "git checkout" or "git commit" everywhere.
and the latter looks very inconvenient.
But of course the latter is very inconvenient. The current "git
checkout" nor "git commit" are not such subprojects-aware
Porcelain commands. But that does not mean you have to house
everything in the same repository and make partial check-in to
work. You will be enhancing or replacing the same "git checkout"
and "git commit" commands to do so anyway.
I used CVS as an example but I've seen the "everything-under-one-roof"
approach, as you put it, used in other VCS' that do work with
changesets. One instance, in particular, has all the source and config
files in a single tree that (I'm told) would take several Gigs of
filesystem space to checkout fully. The codebase is modular to a great
extent but any particular project in it usually required files from a
large number of other projects. There is a lot of automation to find the
required parts for builds and other actions on a project's codebase.
Could this be done with multiple repositories? Yes, but we're talking
hundreds (no exaggeration) and many of those would likely end-up
including a large percentage of the other repositories the way the Git
repository includes the Gitk repository. It could work but their
existing approach already works and is likely better suited for their
codebase. Git can not, currently, do all the things that this
organization wants a VCS to do, working with partial checkouts is a key one.
There is no fundamental reason Git can not support partial
checkouts/working directories. In fact, there is no fundamental reason
Git can not support operations on partial (sparse?) repositories in both
space (working content/state, etc.) and time (history); it's just a
matter of record keeping[*1*]. That isn't how the Linux kernel
developers want to use their VCS but it _is_ how others want to use theirs.
Notes:
[*1*] I'm currently working on determining the minimum requirements
needed to support repositories with partial or sparse history.
-
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