Thomas Hauk <tom@xxxxxxxxxxxxxx> writes:
> On Jan 27, 2011, at 12:53 PM, Ævar Arnfjörð Bjarmason wrote:
> > You'll be much better off if you have project-specific repositories.
>
> But how often do you have a project that has no external or internal
> dependencies on any other packages or libraries? Any project I've
> ever done, big or small, has relied on some existing
> codebase. Imagine a project that uses liba and libb, which both
> reference libc. To use Git, I'd have to have copies of libc existing
> in three repositories, and copies of liba and lib in two
> repositories each. What a nightmare... and that's only a trivial
> hypothetical example.
That is only if lib{a,b,c} is _internal_ dependency. In usual case
project A might depend on library B *to be installed*, but it doesn't
mean that source code of library B has to be in repository for project
A. And in usual case when project A depends on library B, it relies
on library B public stable API (its build system might check if you
have new enough library B installed). If you depend on specific
version of library, patched, that is your problem...
In the case of internal dependency, where you co-develop both project
A and library B, it makes most sense to have separate repositories for
A and for B, and tie them up using submodules or subtree merge.
In the case you describe you would need three *checkouts* of libc (if
checkout is needed for development, see above), but not necessary
three copies (three clones) of libc *repository* - one copy should be
enough.
>
> I understand that Git was designed with a specific feature set in
> mind -- to manage Linux kernel development -- and as such isn't
> going to satisfy everyone. But I'm having trouble figuring out how
> to integrate it as the SCM in my projects, which aren't organized
> any differently than any other projects I've seen.
Well, you are braindamaged by your SCM ;-) ... just kidding.
Take a look how LibreOffice (Go-OOo), KDE, GNOME, GNU SourceMage Linux
distribution organize their repositories -- all of them are highly
modular / componentized.
> Surely I can't be the only person with these difficulties? Git just
> doesn't seem to scale when it comes to componentized projects. Do
> other distributed VCSs work better than Git in this respect?
Perhaps you could abuse Bazaar in that fashion, but I think most DVCS
use branching of whole project (branch in repository) model, rather
than the branching is copying (branch is folder) model that Perforce
and Subversion use.
Whole project branching has just too many advantages, or conversely
branch as folder (directory) has too many disadvantages.
> I'm really trying to get on the Git bandwagon, here.
World domination is not on agenda :-) The main goal of Git is to make
it easy for open-source projects to collaborate.
P.S. There are commercial DVCS: BitKeeper, Vault,...
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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