Can somebody explain to me the tags / POM versioning / release scheme?

[Mark Lundquist <ml...@wrinkledog.com>]

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

Re: Can somebody explain to me the tags / POM versioning / release scheme?

[Mark Lundquist <ml...@wrinkledog.com>]

Okay, I'm slowly getting my head around all this.  Just one thing  
left, I think.  In order to actually build the stuff, I'm going to  
need a "build root", i.e. an instance of project "cocoon-project".  I  
figured how which directories in tags/ correspond to things in the  
directory tree of this root project (e.g. core/, blocks/, parent/,  
tools/ etc.) (and I still have to work out how to check those modules  
out to a particular version in git, but I'm sure I'll be able to  
figure that out); however I don't see where cocoon-project itself is  
tagged anywhere.  So... I assume that I should branch from trunk at  
the Subversion rev. when the cocoon-6 tags (at least for the core  
stuff?) were made.  Is that right?  I want to make sure I get pom.xml  
and settings.xml (anything else?) that are correct for building Cocoon  
2.2 (or parts of it, anyway).

What about branches/, is there anything I need to be aware of there?

thx-a-lot,
Mark

Re: Can somebody explain to me the tags / POM versioning / release scheme?

[Reinhard Pötz <re...@apache.org>]

Mark Lundquist wrote:

<snip>interesting stuff</snip>

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

Cocoon 2.2 is based on two subprojects:

  . Cocoon Configuration
  . Cocoon Servlet-Service Framework
    (only needed if you want to use Servlet services, ie the servlet:
     protocol)

Cocoon core consists of a bunch of modules. The complete list can be 
found in 
http://svn.eu.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-core/cocoon-core-2.2.0/pom.xml. 
See all the dependencies that have the groupId "org.apache.cocoon".

The version numbers are set in the parent modules of Cocoon core:

http://svn.eu.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-core-modules/cocoon-core-modules-6/
and
http://svn.eu.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-6/pom.xml


If you checkout one of the tagged modules, Maven 2 should be able to 
build it for you. This is probably your best chance to add your changes. 
  The change the version number to e.g. "1.0.0-mark". Then use this 
version of a particular module in your custom project POM instead of the 
  officially released version.

HTH

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                          http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: Can somebody explain to me the tags / POM versioning / release scheme?

[Mark Lundquist <ml...@wrinkledog.com>]

On Jul 30, 2008, at 1:23 AM, Grzegorz Kossakowski wrote:

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

Gladly.  Once I get it worked out, I'll document it (maybe Daisy would  
be the place for that).

>> [...snip]
> 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.

I agree!

This morning I was worried that I gave too much background in my  
email.  I thought "nobody will care enough to read through all this  
crap!"  I'm glad people seem to recognize this as a valid use case,  
not just some goof-ball cowboy idea...

> Anyway, I hope there will be other use-cases for Git at Apache...

Me, too... I think it's inevitable :-)

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

Right. I still have to figure out how I'm going to handle that in my  
git setup, but I think you and Reinhard have set me on the right track  
here.

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

Yes.

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

Actually, the only reason I emailed you first was specificatlly that I  
didn't know how "publicized" Jukka wanted this to be.  I mean it's no  
big secret, he posted it on infra, but... still I didn't want to be  
the one to say "hey everybody... git party at Jukka's server!" :-)  I  
guess he did say he could probably handle a few hundred users...

cheers,
—ml—

Re: Can somebody explain to me the tags / POM versioning / release scheme?

[Grzegorz Kossakowski <gr...@tuffmail.com>]

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