Re: [Gnu-arch-users] repository/ projects assumption

[Matthew Dempsky]

Zenaan Harkness <address@hidden> writes:

> It is easier to have all the code that the team develops in a single
> project/ package/ repository.
>
> If for example, "library" code is separated into a separate project, the
> overhead (at least in Aegis) for developers to create additional
> "changes" each time they factor something into the 'library' is simply
> too high, and so they don't do it.

I think arch handles the situation of having parts of a project broken
up across different packages as well as to be expected.  I frequently
have trees built with any combination of package-framework, hackerlab,
tla, furth, pika, systas, etc.

> So (at least when I was using Aegis) doing the above ended up being
> counter productive, and left the library to stagnate, when we separated
> the library code into a separate project.
>
> Given the concepts of a "modern" SCM, there is the ability to (nicely)
> merge changes across such separate packages as "library" and "admin app"
> and "server", at least I'm assuming.
>
> Is this assumption correct?

How you'd want to structure this probably largely depends on how tight
the coupling between the library, app, and server are.  For example,
tla uses libhackerlab as a ground work for almost all operating system
interaction and this is stored in a seperate package.  However, the
tla package also includes a few convenience libraries that are
(currently) not very generic and thus used solely for tla: libawk,
libfsutils, libarch, etc.

If you're frequently making patches that change parts of two or more
of these (library, app, server), then it's likely they should stay in
the same package.  If you notice that the patches you're making to
each component are largely independant and the components are useful
independently, then you can try packaging them seperately in arch.
(It's also quite possible to move from a monolithic package to modular
packages with arch, and the reverse is also possible, but a little
trickier.)

I believe some of the future plans Tom posted a while ago (zoomed
trees in particular) might also provide you with the best of both
worlds.  (Check the bug database if you're interested.)