Received: from spf1.us4.outblaze.com (spf1.us4.outblaze.com [205.158.62.23])
	by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id iAFK9xRp024622
	for <migo@freeshell.org>; Mon, 15 Nov 2004 20:10:00 GMT
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
	by spf1.us4.outblaze.com (Postfix) with ESMTP id B126B53EF7
	for <migo@homemail.com>; Mon, 15 Nov 2004 20:09:54 +0000 (GMT)
Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33)
	id 1CTnJM-000303-RV
	for migo@homemail.com; Mon, 15 Nov 2004 15:18:52 -0500
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1CTnJ1-0002zv-5d
	for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 15:18:31 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1CTnJ0-0002zg-NX
	for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 15:18:30 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1CTnJ0-0002zd-KA
	for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 15:18:30 -0500
Received: from [129.255.60.186] (helo=ct.radiology.uiowa.edu)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1CTn9v-00078H-Us
	for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 15:09:08 -0500
Received: from [192.168.1.11] (12-217-241-0.client.mchsi.com [12.217.241.0])
	by ct.radiology.uiowa.edu (8.11.6/8.11.6) with ESMTP id iAFK94300782;
	Mon, 15 Nov 2004 14:09:04 -0600
Message-ID: <41990CD4.9050003@arbash-meinel.com>
Date: Mon, 15 Nov 2004 14:08:52 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Dimitrie O. Paun" <dpaun@rogers.com>
Subject: Re: [Gnu-arch-users] Archives vs. categories vs. versions
References: <20041115191000.GA30577@rogers.com>
In-Reply-To: <20041115191000.GA30577@rogers.com>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Cc: gnu-arch-users@gnu.org
X-BeenThere: gnu-arch-users@gnu.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: a discussion list for all things arch-ish <gnu-arch-users.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
	<mailto:gnu-arch-users-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/gnu-arch-users>
List-Post: <mailto:gnu-arch-users@gnu.org>
List-Help: <mailto:gnu-arch-users-request@gnu.org?subject=help>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/gnu-arch-users>,
	<mailto:gnu-arch-users-request@gnu.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1636859071=="
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 4806
Lines: 138
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1636859071==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigB70945AE0B5BA6C459FB64E7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB70945AE0B5BA6C459FB64E7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:
>   dev@mozilla.org--mozilla
> 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:
>   dev@mozilla.org--2004-mozilla
> 
> However, why not break them by project:
>     dev@mozilla.org--mozilla-firefox
> and then inside have:
>     <committer>--<branch>--<version>
> (any better suggestions?)
> 
> Or even, an arhive for each version:
>     dev@mozilla.org--mozilla-firefox-1.7
> 
> But wait. In Firefox 1.7 we may have a new feature
> for popup blocking. Why not create an archive for it:
>     dev@mozilla.org--mozilla-firefox-1.7-blockpopup
> 
> 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:

dev@mozilla.org--2004

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 dev@mozilla.org--firefox, dev@mozilla.org--mozilla, 
dev@mozilla.org--thunderbird (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
=:->

--------------enigB70945AE0B5BA6C459FB64E7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBmQzYJdeBCYSNAAMRAtsfAKCV/dPf5rQElPDvRclzl5djLR6yuACgynLi
mcIL0VxC99Pd5GjjnIL0EE4=
=P0VW
-----END PGP SIGNATURE-----

--------------enigB70945AE0B5BA6C459FB64E7--



--===============1636859071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
--===============1636859071==--