cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Can somebody explain to me the tags / POM versioning / release scheme?
Date Wed, 30 Jul 2008 08:23:13 GMT
Mark Lundquist pisze:
> Hi Devs,

Hi Mark,

> 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.

Any chance for you to create a similar page documenting your new approach? I'm sure that there
would 
be a people benefiting from a nice cook-book document.

It's a chance to make Git more popular which is always a benefit, right? :-)

> 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.

Interesting. I'm not sure but when we have discussed Git advantages over svn on infrastructure
lists 
that point has not been discussed.

Even if only for that purpose it makes sense to provide Git clones of Apache repositories.
Anyway, I 
hope there will be other use-cases for Git at Apache...

> 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?

I would like to add only one note to Reinhard's answer:
Various parts of Cocoon are now released independently so version numbers can be completely

different. Anyway, in most cases it's ok if you just checkout certain module and patch it.

Fortunately, repositories provided by Jukka track all these branches and tags for different
modules 
so you will have no trouble with such setup.

> thanks a _lot_,
> Mark

No problem. Next time it's better to discuss such things publicly (yes, I'm sorry that I didn't

respond to your e-mail - as usual lack of free time). :-)

-- 
Grzegorz Kossakowski

Mime
View raw message