geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: private repo in svn questions...
Date Tue, 02 Dec 2008 14:08:55 GMT
Donald Woods wrote:
> 
> 
> David Jencks wrote:
>> In order to get the build to work with my use of nexus I've added the 
>> trunk svn repo (server/trunk/repository) to the nexus repositories.
>>
>> This makes me wonder if we should just set up a single repo in svn and 
>> put all our private builds there rather than having branch-specific 
>> repos.  Would this result in more or less or the same load on the svn 
>> server?
> 
> Seems that moving the artifacts out into a unique svn branch (from 
> geronimo/server/trunk/repository to geronimo/private/repo) would 
> increase the load, as now every server build would be hitting the svn 
> repo for artifacts (instead of just the /samples or /plugins builds.)

I think there is value in having all of the required elements for a G 
release in one svn branch.  It keeps everything together when we release 
in the tag.  How would we manage the artifacts if there were in a unique 
svn branch without the release process?  I know we don't exactly release 
these artifacts as the specified versions - but we implicitly release 
them when we create the Geronimo release.  Would they ever move to a tag 
if they were in a unique svn?

> 
>>
>> I also wonder if our policy of patching apache projects and coming up 
>> with our own psuedo releases is really the best idea or if we should 
>> just copy their code over in svn and build it more directly.
>>
> 
> I could go either way on this.  I would like to see us at least check-in 
> a tar/zip of the source for the patched artifacts into a branch, to make 
> it easier to reproduce patched builds if needed (and so end users can 
> rebuild everything if needed or used the patched source in a debugger.)

I guess the benefit of including all the code in our svn would be that a 
user could easily debug the code if necessary.  But I'm nervous that the 
changes might be difficult to track and migrate to newer releases 
without the patch (and an optional patch can be easily 
ignored/forgotten).  So I think I favor the process as it is today.  I 
think we really need to work harder to remove these private builds.

> 
>>
>> I also discovered a couple of weeks back that the lack of poms in this 
>> repo was causing significant build delays while maven was looking 
>> everywhere it could think of for them so I added them when I could 
>> easily find them in the artifacts.  I think we should add them for the 
>> other artifacts as well.
> 
> Agree.
> 
>>
>> thanks
>> david jencks
>>
>>
>>
> 


Mime
View raw message