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

[Enrico Weigelt <weigelt@metux.de>]

* Jakub Narebski <jnareb@gmail.com> wrote:

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

To make it more clear: 

At buildtime, a _package_ (not project!) "A" requires a already built
and installed package B in some sane place where the toolchain can find it.
On deployment of package "A", it has to be made sure that package "B"
is also deployed (eg. by a dependency-handling package manager).

These are two entirely separate stages in a software's lifecycle.
Buildtime and deployment dependencies may be different (even deployment
and runtime deps may differ).

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

I, personally, wouldn't use submodules - too complicated. Instead have
just one tree per package(-variant) and keep these completely separate.

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

Well, I wouldn't say LO is really modularized, yet. (but we're
working on that ...).
 

cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------