[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared Source
From: |
Pierre Asselin |
Subject: |
Re: Shared Source |
Date: |
Thu, 8 Jul 2004 11:28:21 -0400 |
User-agent: |
tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.19-7.0.1 (i586)) |
Chris Puccio <address@hidden> wrote:
> I need to be able to have one main "Core Product" code base, then be able to
> suck down only certain pieces of that "Core Product" code base, which will be
> the framework for another clients product.
Possible, with restrictions. Bundle up the shared code in subtrees,
so any client product can get shared subtrees grafted under it, rather
than pick and select files at random. It forces you to organize your
shared code, but that is probably a good thing. Two recommendations:
1) The "Core Product" should probably be a <<client>> like
all the others. Its only distinguishing feature would be that
it has all the shared subtrees under it.
2) Each shared subtree should be a self-contained entity that
you can check out individually. It should have its own test
suite, for example. That way you can work on it in isolation
and later propagate the changes to the client products.
This doesn't preclude you from making the changes you want
from a "Core Product" sandbox, it just broadens your options.
> I then need to be able to have any
> changes made to the "Core Product" be sync'd with any "Child" products that
> received code from the "Core Product" code base.
The sync would occur every time you run a "cvs update" in a "Child"
sandbox. Hmmm, notice how I've been using "client" instead of "Child" ?
> If anybody can give me some proper keywords on the CVS term to do this, it
> would make googling much easier right now ;)
Amperstand modules.
- Shared Source, Chris Puccio, 2004/07/06
- Re: Shared Source,
Pierre Asselin <=