Re: Repo strategies

On Fri, 2004-08-13 at 13:49 -0700, Marshall, Hunter wrote:
> What are some of the way that people are structuring their repositories? One
> large repository seems wasteful when I clone a repo for an isolated bit of
> development.

The answer to this is simple.  It only depends on what wants to be
logically grouped together, what your BK-based development model is, how
big your trees are, how many developers you have, whether you have
scripting and version control experts around, and how much time you have
to spare :-)

If you have tight dependencies between your files, they really want to
be in a single repo, regardless of any other considerations.  If not,
then it matters less whether you use one or several.

The BitMover guys each maintain a large pile of clones, each of which
contains one logical change to different branches of the same project.
They have one gatekeeper, who picks changes from these many tiny
branches for each "main line" associated with a release.

The lots-of-tiny-branches model is great, but clearly doesn't scale as
your source tree becomes very large, as clones are necessarily fairly
heavyweight operations, even using -l.  It especially doesn't scale if
you use "checkout: get" or "checkout: edit".

You then gravitate to a CVS-like model, where everyone can push changes
to a central branch that they're working one.  This is livable, but
sucks if you're trying to work on several unrelated changes at once.

Some BK customers have much more ambitious systems for managing multiple
loosely coupled repositories, where they have meta-repositories with
others nested inside, and they use wrapper scripts to manage some of the
interdependencies between them, tracking how the tags one one relate to
those in another, and so on.

Where I work, we use different models depending on the needs of
individual teams and how they prefer to work, since we have several
projects going at any one time, each with a small team.  Some people
like oodles of branches, and they do that.  Others long for the days of
CVS, and they live that way.  We've added very little by way of overhead
to "native BK", and it works well.  Would I do this if I were deploying
BK at a legion-of-half-trained-monkeys development shop?  No.

	<b

_______________________________________________
Bitkeeper-users mailing list
[email protected]
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the bottom of the web page.