Subversive Repository

["Mark R. Diggory" <md...@latte.harvard.edu>]

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

Re: Subversive Repository

[Nicola Ken Barozzi <ni...@apache.org>]

Mark R. Diggory 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.

:-)

Are two jars that differ slightly actually not that different?

I had brought this up on this list in "Making releases -> publishing 
jars". Below is a relevant reply.


-------- Original Message --------
Subject: Re: Making releases -> publishing jars
Date: Wed, 17 Mar 2004 15:32:14 +0100
From: Nicola Ken Barozzi <ni...@apache.org>
Reply-To: repository@apache.org
To: repository@apache.org
References: <NB...@devtech.com>


Noel J. Bergman wrote:

 >>1 - people making releases have to log into the release server
 >>2 - there is no notification of files being put there
 >>3 - we are already experiencing issues with where to put jars
 >
 >>What if we make instead a SVN repository for releases?
 >
> Isn't that a bit heavyweight when all you appear to want is WebDAV
> with access control and notification?

Point taken.

> I just had an interesting chat with Sander about adding features to
> our WebDAV support. He seems to think that it would be fairly easy to
> add hook and authz support, so that authorizing access to a file
> system area would be
> the same as we use for SVN. Also, we'd have hooks that could perform 
> actions when changes are made.

This would be zuper.

...
 >>like for example publish the jars in a parallel
 >>structure that is used for the maven repo.
> 
> We've really got to work on eliminating the adjective there, and I
> applaud Mark's efforts to do so.

I do too.

Sorry, I have not helped much. Where do we stand now? What can I help to do?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

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
>