Re: Subversive Repository

[Brett Porter <br...@gmail.com>]

Hi Mark,

Interesting idea. Doing this always makes me feel a little uneasy,
though given the reasons you've listed I can't think of any problems
other than a gut feel.

I guess the reason for that is that JARs really shouldn't be changed
once published. The exception is snapshots (not even timestamps, just
the ones file that constantly gets overwritten with latest).

I'm ok with having an SVN artifact handler written for Maven (only to
deploy, not to retrieve though). If we want to continue that path,
then I'd like to bring it up with the other Maven developers though.

But I'd also like to be able to develop a best-practice solution for
handling a file system repository (after all, the Maven project is all
about making best practices easy :)

An idea I've heard in the past that might be worth reviewing is having
separate SNAPSHOT and release repositories. On download, we can
provide a common view using a repository front end or even Apache
rewrites, or have clients specify both.

The release repo might include timestamped builds, though I'd hate to
get stuck with the Jelly situation again where a 1-year old nightly
became the defacto latest release :)

If this separation was the case, the release repository could have
much tighter controls: the original publishing user could have the
only write permission for example.

Cheers,
Brett

On Wed, 29 Sep 2004 12:13:31 -0400, Mark R. Diggory
<md...@latte.harvard.edu> wrote:
> Here's a thought that has been propagating through my neurons.
> 
> What if the ASF Repository content was maintained in Subversion and
> exported into dist/java-repository for mirror propagation using some
> automation? Given Subversions binary diffing, this would be manageable.
> 
> 1.) This would allow us to control permissions at the same level as the
> cvs/subversion source control. As such:
> 
> Jakarta Commons Jelly
> 
> and
> 
> Jakarta Commons Collections
> 
> would have enough fine grained permissions to control to separate who
> gets the right to add/remove/modify content at that level instead of
> what we have right now, which are only the groups in the shell (ie xml,
> jakarta etc).
> 
> 2.) This would give us a layer (automated update of
> dist/java-repository) to catch issues such as:
>     a.) md5 and signature errors.
>     b.) dated-build vs full version releases.
> 
> The downfall is that Repository Clients (Like Maven) would need to be
> capable of doing svn commits etc to publish artifacts instead of ssh/scp
> requests.
> 
> -Mark
> 
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>