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.
(Note. In the next paragraph, I used (for the want of better
wording) the word "unrelated" to mean "indeed related,
but without need to be in sync at whole-tree commit
level, and probably insisting to be in sync at that level
has more disadvantages than advantages". Think of it to
refer to the relationship among more-or-less independent
project subcomponents in my earlier example).
Well, the fact is, it does not make any difference to CVS if you
put unrelated projects in a single "repository", because CVS
does not even have the concept of managing a project as a whole.
Except perhaps that you can give the same tag to individual
files and treat the set of the revs of the files that have that
particular tag forms a revision of a project. And even that is
just a kludge -- if you throw a totally unrelated project into
such a "repository" and give files a tag that happens to be the
same name as the one used in another project, the tool happily
lets you do so and checking out a revision by the tag will pull
files from totally unrelated projects together. We happen to
use the words "repository" and "revision" in git but what they
mean is quite different because we are more whole-tree oriented.
It misses the point to compare CVS and git and say CVS allows
placing unrelated things in the same "repository". CVS does not
even track the whole tree state, so it does not hurt the user
nor the tool even if you did so. With a tool that tracks the
whole tree, you need a bit of thinking and planning.
I do not think, by the way, we are aiming at much different
things. We both know that our current tools do not support
either mode of operation; the direction you are coming from
where everything is under one roof and only parts are accessed
while others are left untouched, or an organization where
loosely-related projects from different repositories are checked
out into a working tree hierarchy. You alluded to "split index"
in another message, and the project organization I suggested to
keep component projects in their own separate repositories would
also have separate indices in component repositories.
I am certainly not opposed to the idea of making operations in
such a tree (built either way) go seamlessly for the users. A
Porcelain that supports such mode of operation needs to be built
or enhanced, because we do not have one.
What I am saying is that I suspect everything-under-one-roof
approach would incur higher damage to the core than multiple
repositories approach. It is my understanding that Cogito has
such a light-weight subproject support that lets you have
separate repositories laid out in a single working tree.
For example, users of such a Porcelain most likely would not
worry about what is stored in .git/index and .git/remotes/
directories of individual repositories that appear in such a
single working tree. The Porcelain would keep track of which
files are locally modified, what components are checked out in
which subdirectory, where their upstream repositories are, and
things like that. It will use .git/index and .git/remotes/ of
component repositories to implement the unified tree, but the
use of the individual .git/ directories is its implementation
detail. It is likely to do its own bookkeeping that is beyond
what the current core offers, but I do not think it needs much
additional core support. If such bookkeeping turns out to be
useful and necessary to have it in the core for whatever reason
(either performance or interoperability across Porcelains), we
could certainly talk about putting that into the core.
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.
-
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