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

[John A Meinel]

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:
>   address@hidden
> and inside we have:
>   <project>--<branch>--<version>
>
> But we know that big archives are a bit of a pain in arch, so
> we break them (a bit arbitrary) by date:
>   address@hidden
>
> However, why not break them by project:
>     address@hidden
> and then inside have:
>     <committer>--<branch>--<version>
> (any better suggestions?)
>
> Or even, an arhive for each version:
>     address@hidden
>
> But wait. In Firefox 1.7 we may have a new feature
> for popup blocking. Why not create an archive for it:
>     address@hidden
>
> 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?
>
> TIA,
> Dimi

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:

address@hidden

With the projects:

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

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.

John
=:->

signature.asc
Description: OpenPGP digital signature