Re: Project- vs. Package-Level Branching in Git

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 28, 2011, 09:38 UTC
Message-ID: <m3tygt9xmn.fsf@localhost.localdomain>
In-Reply-To: <15B7CA2E-C584-4563-B9E3-D80861CD9565@shaggyfrog.com>

Thomas Hauk <tom@shaggyfrog.com> writes:

> On Jan 27, 2011, at 12:53 PM, Ævar Arnfjörð Bjarmason wrote:

Show 10 quoted lines

> > 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.

Show 6 quoted lines

> 
> 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