--- xml/htdocs/proj/en/glep/glep-0058.html 2008/10/28 07:47:52 1.1 +++ xml/htdocs/proj/en/glep/glep-0058.html 2010/01/13 01:02:36 1.2 @@ -4,7 +4,7 @@- +
If other Manifests are added (such as per-category, or protecting -versioned eclases), the size of the MetaManifest will be greatly -reduced, and this specification was written with such a possible future -addition in mind.+
If other Manifests are added (such as per-category, per first-level +directory, or protecting versioned eclases), the size of the +MetaManifest will be greatly reduced, and this specification was written +with such a possible future addition in mind.
MetaManifest generation will take place as part of the existing process by infrastructure that takes the contents of CVS and prepares it for distribution via rsync, which includes generating metadata. In-tree @@ -287,12 +287,12 @@
With only two levels of Manifests (per-package and top-level), every rsync will cause a lot of traffic transfering the modified top-level -MetaManifest. To reduce this, per-category Manifests are strongly -recommended. Alternatively, if the distribution method efficently -handles small patch-like changes in an existing file, using an -uncompressed MetaManifest may be acceptable (this would primarily be -distributed version control systems). Other suggestions in reducing this -traffic are welcomed.+MetaManifest. To reduce this, first-level directory Manifests are +strongly recommended. Alternatively, if the distribution method +efficently handles small patch-like changes in an existing file, +using an uncompressed MetaManifest may be acceptable (this would +primarily be distributed version control systems). Other suggestions +in reducing this traffic are welcomed.