cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist ...@wrinkledog.com>
Subject Can somebody explain to me the tags / POM versioning / release scheme?
Date Tue, 29 Jul 2008 19:39:57 GMT
Hi Devs,

I need some help understanding the temple of mystery that is http://svn.apache.org/repos/asf/cocoon/tags/

.  If I wanted to build my own 2.2 artifacts, how would I do that?

Some background, I'll *try* to make it as short as possible :-/ (and  
while it involves git, you don't need to understand git to be able to  
follow it)...

I use Cocoon to implement dozens of customer web sites/applications.   
I develop on my laptop when possible, and we have a development server  
for staging and some content updates, and a production server.  A few  
years ago, I realized that I needed to be able to maintain the Cocoon  
source tree (the parts of it I needed) in my own Subversion  
repository.  The main reason for this was to be able to upgrade  
projects to new versions of Cocoon in a controlled way, as smoothly as  
possible.  Also, on rare occasions I would find a bug and submit a  
patch for the fix, and I needed the ability to push that fix into  
production in the version of Cocoon that my project builds were  
using.  To make all this possible, I developed an application of the  
"Vendor Branch Strategy" described in the Subversion book, and  
documented it here: http://wiki.apache.org/cocoon/CocoonVendorBranch.

Unfortunately, that technique still turned out to be too labor- 
intensive, to the point where it failed to accomplish its main goal of  
giving me an easy way to upgrade Cocoon versions.   Meanwhile... the  
lack of merge tracking and offline commits in Subversion was making it  
harder and harder to get work done, so I started using SVK (http://svk.bestpractical.com 
) as my front-end to Subversion on my laptop.  After a little bit of  
experience with SVK, I realized that it provided the ability to  
radically simplify my "vendor branch" strategy.  All I needed to do  
was to create a local SVK mirror of the ASF Cocoon repository and I  
would be off and running.  Unfortunately... it didn't work, the mirror  
sync operation would always fail with a low-level error in the  
Subversion layer.  So I gave up for a while.  Then, last month I  
started researching the problem again, and learned that the problem  
had been due to the Apache "mod_dontdothat" policy implemented by  
Apache infra in order to thwart some kind of abuse that had been going  
on.  Sadly, this also made it impossible for SVK to mirror the  
repository.  About that time, Grzegorz was running into the same  
problem, but he was trying create a git-svn mirror of the repository.   
That was fortuitous for me, because I was getting seriously interested  
in git (having experienced that SVK is broken, and come to the  
realization that the whole concept is lipstick on a pig).  There was  
this whole long discussion on the infra list, and they finally reached  
a compromise where mod_dontdothat would be turned off... but only on  
eu.svn.apache.org, and only in the https:// scheme, which would then  
be subject to authentication — so, this was available to committers  
only.  There was actually a brief window of time when mod_dontdothat  
was turned off for Europe, and during that time I was able to 'git-svn  
clone' the repository.  But a few weeks later, I tried to rebase my  
git-svn mirror (like doing "svn up") and it failed because by then eu  
infra had closed off non-mod_dontdothat'd access on http://, so...  
back where I started.

BUT THEN... one of the Apache committers put a lot of work into  
figuring out how to create a git-clonable, public git-svn mirror of an  
Apache project... and he did it, and published mirrors of a bunch of  
Apache projects, including Cocoon.  It's brilliant.  It took me 20  
minutes to git-clone the mirror, vs. the 40 hours of running time to  
make my own (short-lived) git-svn mirror.  I just rebased to pick up  
the last week's worth of changes to the repo, and it just took a  
couple of seconds.  And in my local git repository, I can do  
*anything* that's possible in git.  I really think this is the answer  
to my problem.

NOW... I want to start porting all my Cocoon projects, which are all  
stuck on Cocoon 2.1, to a Cocoon build based on the 2.2 release.  This  
would be 2.2 + a couple of minor bug fixes which did not make it into  
the 2.2 release, so it needs to be from my own local (git) branch...  
plus, this puts me on the right path to do everything I originally was  
trying to do with "subversion vendor branch", i.e. controlled Cocoon  
upgrades in the future w/ minimal hassle, continuing to add minor  
local patches as necessary so I can use them before they appear in a  
release, etc... except that it will actually *work*.

All that's missing is being able to identify the baseline of source  
code that was used to build the 2.2 release.  I need to be able to  
build the core and a few modules.  Can somebody help me figure this out?

thanks a _lot_,
Mark


Mime
View raw message