perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <go...@ectoplasm.org>
Subject Re: can someone explain the new modperl svn layout?
Date Sun, 21 Nov 2004 22:54:41 GMT
Stas Bekman wrote:

> I'm totally confused. Can someone who was working with infrastructure 
> at apachecon explain the new layout of modperl projects under svn. I'm 
> viewing http://svn.apache.org/viewcvs.cgi/perl and it doesn't make any 
> sense to me.

Well, first of all, if you want to browse the repository, you are far 
better of with regular http thru http://svn.apache.org/repos/asf/perl/
with a good old web browser.

> All I can see is:
>
> http://svn.apache.org/viewcvs.cgi/perl/modperl/docs/
> http://svn.apache.org/viewcvs.cgi/perl/modperl/
>
> which doesn't seem to be right at all, why modperl and not 
> modperl-2.0? the two generations are totally unrelated, so there is no 
> point making those 2 different branches. Why the docs are nested 
> inside modperl?

Well, that structure was more or less the result of a conversation with 
the folks in infractruture as they were moving a bunch of
projects under svn.

First, keep in mind that [svn]/perl is under our control (the modperl 
developers), so we are now entirely free
to make whatever changes we want and move things around, without the 
trouble it would have been with CVS.

Second, docs/ was placed under modperl/ because like most other 
projects, the convention is to place the website/documentation
beside trunk/ of the project it matches. It's just a convention.

Third, modperl-2.0 was made into modperl/trunk because it was the main 
development branch. Same reason httpd-2.1 was made
into httpd/trunk

> It should be something like (1):
>
> http://svn.apache.org/viewcvs.cgi/perl/modperl-docs
> http://svn.apache.org/viewcvs.cgi/perl/modperl-2.0
> http://svn.apache.org/viewcvs.cgi/perl/modperl-1.0

This sure is one possible layout. It would be quite different from the 
layout all the other asf projects are under though, and I
for one don't quite see how it improves things. It's different than what 
we have right now, but I fail to see how it's different
as long as people are handed out SVN Urls to download things from.

> If we are planning to do a different nesting to accomodate other 
> projects it could be (2):
>
> http://svn.apache.org/viewcvs.cgi/perl/modperl/docs
> http://svn.apache.org/viewcvs.cgi/perl/modperl/2.0
> http://svn.apache.org/viewcvs.cgi/perl/modperl/1.0
> http://svn.apache.org/viewcvs.cgi/perl/embperl/1.0
> http://svn.apache.org/viewcvs.cgi/perl/embperl/2.0
> ...

Or:

http://svn.apache.org/repos/asf/perl/modperl/trunk/
http://svn.apache.org/repos/asf/perl/modperl/docs/
http://svn.apache.org/repos/asf/perl/modperl/branches/1.x/
http://svn.apache.org/repos/asf/perl/embperl/trunk
http://svn.apache.org/repos/asf/perl/embperl/branches/1.x/

And IMO, this is an approach that remains closer than the way other 
project are structured too, like httpd for instance.

http://svn.apache.org/repos/asf/httpd/httpd/trunk
http://svn.apache.org/repos/asf/httpd/httpd/tags
http://svn.apache.org/repos/asf/httpd/httpd/branches
http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x
http://svn.apache.org/repos/asf/httpd/site

> In the future for this kind of grand changes please post a plan of 
> things you are going to do *before* doing them.

I absolutely agree on this one, and this is a good example of making a 
somewhat significant infrastructural change without
enough planning. This has been decided kinda on the spur of the moment 
at ApacheCon, and I am sure many other projects
are going thru a similarly annoying changing process.

> This is a huge change and it already wastes a huge amount of our time 
> :( sorry if it feels like I'm screaming, but I feel very blind at the 
> moment, because I have no idea what's going on.

But, at this point, I think moving forward with subversion is a good 
idea ;-) We have complete control of the content of [svn]/perl/* and can 
very easily "svn move" anything to wherever we want. Subversion is 
different to CVS in many places, and certain paradigms did change, but I 
think that the important thing at this point, and moving forward, is to 
discuss the remaining annoyances
left and tackle them on a one to one basis and I am sure we can get back 
to a nice, stable and comfortable development environment
in no time.

So, in a new thread, I'll start first a conversation on what svn repos 
structure we want to adopt.

Gozer out.

Mime
View raw message