[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Archives vs. categories vs. versions

From: John A Meinel
Subject: Re: [Gnu-arch-users] Archives vs. categories vs. versions
Date: Mon, 15 Nov 2004 14:08:52 -0600
User-agent: Mozilla Thunderbird 0.9 (Windows/20041103)

Dimitrie O. Paun wrote:
Hi folks,
I have recently stepped into the wonderful world of arch,
and am trying to put some order into all the new flexibility
that arch allows.

Namely, with arch working transparently across archives, it
is not that clear anymore where the boudaries for archives should be.

Consider for example a large organization, like Mozilla. They
have many projects (let's assume 100s or even 1000s for the
sake of discussion), and many of their projects are rather large.

Currently, they have one big CVS repository with everything in
it. The same can be done with arch:
and inside we have:

But we know that big archives are a bit of a pain in arch, so
we break them (a bit arbitrary) by date:

However, why not break them by project:
and then inside have:
(any better suggestions?)

Or even, an arhive for each version:

But wait. In Firefox 1.7 we may have a new feature
for popup blocking. Why not create an archive for it:

Can one do this? Is it feasible? What are the pros/cons?
Any good examples of archive/category/branch organization
out there that scales well to _large_, very active projects?


Well, I can't say that I've created very large archives, but I do have an archive with lots of projects. Right now I have about 90 projects in my archive.

I'm not sure how painful large archives are, so much as large projects. The issues is that when you do a "tla changes" it has to do a whole tree inventory, so if there are a lot of files, it has a large inventory. We solved this by breaking the source up into more projects and working off of that.

Also, because of how version numbers work, we wanted a separate project (and thus separate version) for every independent piece. Our work involves a lot of pluggable libraries, so each one is it's own category. This complicates things a little, as if you are doing multi-category changes you have to remember to commit in each one. And you lose some of the effect of having all changes bundled up into changesets (changing a library means you have to change the code that uses it, but these are 2 separate commits.)

The advantage is that it makes it very easy to have the libraries used by multiple front ends, as they are all different projects which can be grouped by a config file.

So in your case, I might have the archive:


With the projects:

nprs--dev--1.0 <-- or whatever the mozilla portable runtime is called.
radial-context--dev--1.6 <- this is one of the mozilla extensions

Basically anything that is considered a library and would be subject to reuse gets it's own category.

Now, I might break things up into archives based on major project, so there would be a address@hidden, address@hidden, address@hidden (possibly postfixing these with -2004).

creating lots of archives doesn't really hurt, as arch merges between them rather easily. But I like to do it at logical big boundaries, and then use logical small boundaries (like libs) to determine categories.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]