Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Sat, 13 Sep 2003 12:40:00 +0200
Subject: Re: [RT] Starting 2.2
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <02b901c36e5b$758733a0$fb590644@cruiser>
Message-Id: <A044CA6C-E5D6-11D7-BAA9-000393D2CB02@apache.org>


On Friday, Aug 29, 2003, at 20:27 Europe/Rome, Jay Freeman ((saurik)) 
wrote:

> Stefano:
>
> I totally agree on the "evolution" thing. To start, the process of 
> moving to
> Subversion would be a repository import, not starting from scratch.
>
> As for tools:
>
> http://subclipse.tigris.org/
> (Subversion plugin for Eclipse, although only on Win32 currently, 
> haven't
> tried it as I hate Eclipse; it seems like it could be gotten to work 
> on Unix
> easily, just would require compiling the JNI stubs on your platform 
> yourself
> and dropping them in as the subclipse people are currently relying on 
> some
> precompiled binaries)
>
> http://ankhsvn.tigris.org/
> (Subversion plugin for VS.NET, a little slow at times, but usable)
>
> They already have it integrated into ViewCVS (which is what I thought 
> Apache
> used, might be wrong; there was a lot of impetus to do it as the guy 
> who
> originally forked ViewCVS from CVSWeb is one of the lead Subversion
> developers). I've been working with the Chora (another web interface) 
> people
> and we have it working in that as well.
>
> What I think would be more productive, both for Cocoon and for 
> Subversion,
> is to have more than a flat out "no, stick with something that works" 
> but
> instead to put forward a list of requirements from a revision control 
> system
> for it to be considered an "evolutionary move". Then people who work on
> version control know where to apply effort and people working on 
> Cocoon have
> a roadmap for their evolution (rather than just getting stuck with 
> existing
> systems and never moving).
>
> It's somewhat like deciding to switch to a different underlying 
> framework
> for component/block management; one wouldn't want to just say "hey, 
> this is
> newer and has one better feature, let's do it", but if that one 
> feature is
> crucial enough you'd want to have a list of requirements of a new 
> system
> (one that obviously includes everything important from the old system) 
> so
> that you'd know when you _would_ be able to move to it and when it 
> would be
> worth it.

All right, what the hell, you are right, let's move out of the 
"impasse".

let's do a quick poll: who would be absolutely against using Subversion 
for the Cocoon 2.2 tree (granted that we can safely import the existing 
CVS tree into it)?

state your reasons and try to be as less inertial and defensive on your 
status quo as possible.

[as win2k->macosx/mozilla->Mail.app switcher I can attest that 
sometimes changing your habits is dramatic and painful, but can help 
you a lot down the road and you never look back. This sounds another 
one of those situations]

--
Stefano.