Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] retention policy for builds

On Wed, Jun 15, 2011 at 3:30 PM, Thomas Hallgren <thomas@xxxxxxx> wrote:
> 1. Adding a p2.index file to the same directory as the compositeContent.jar
> (or .xml) will minimize the number of accesses that p2 will need in order to
> identify the type of repository. p2 always looks for this file first. If it
> isn't found, it will look for content.jar, content.xml,
> compositeContent.jar, compositeContent.xml (in that order). For people
> sitting across the big pool, each 404 in that process costs at least half a
> second.

Good point. More information can be found here: .

> 2. The performance when downloading meta-data is degraded each time a new
> repository is added to the composite. The degradation is more or less
> linear. This can be perceived negatively by your users so if you have a
> large number of children, it might be better to merge them into one single
> plain repository.

Are there command line tools to merge repositories?

> 3. An alternative to the composite approach might be to say that the main
> (most commonly used) repository is the child that contains the latest stuff
> and inform the user that a more complete repository (containing all history)
> can be found using another URL. My guess is that 99% of your users will be
> happy with your latest release.

Agreed. We maintain composite repositories that we recommend to users
that only have the latest release which are different from the ones
used by integrators. If you wanted to get the latest Mylyn version
compatible with Helios you would want to use this repository for
instance: . Since
it's so easy to manage composite repositories the cost of adding
additional repositories is low.


Steffen Pingel
Senior Developer,

Back to the top