Re: [PROPOSAL] product groups

["B. W. Fitzpatrick" <fi...@red-bean.com>]

Henri Yandell <ba...@generationjava.com> writes:
> 
> 
> On Tue, 4 Nov 2003, Justin Erenkrantz wrote:
> 
> > --On Tuesday, November 04, 2003 23:16:50 +0000 Stephen Colebourne
> > <sc...@btopenworld.com> wrote:
> >
> >
> > > The one potential spanner in the works for me is subversion. When 99% of
> > > the world uses CVS, I really struggle with this one.
> >
> > Have you tried Subversion?  It really eases a lot of pain that CVS causes.
> 
> Can I use a Subversion server with an existing CVS client? Some kind of
> backwards compatibility bridge thing?

No, but you can convert your CVS repository to a Subversion repository
using cvs2svn.py (Although it still has some issues with converting tags
and branches, it can convert the trunk very nicely).

I understand that this might be a problem, but Subversion's model
doesn't map to CVS very well since Subversion has a lot of things that
CVS doesn't (versioned directories, for one--for the whole list see
http://subversion.tigris.org/).
 
> > Renaming files is just so, gosh darn, beautiful; copying between projects
> > is painless and cheap.  That said, if using Subversion is the *only*
> > bottleneck preventing a Jakarta Commons project from coming to the Apache
> > Commons, I'd be fine with them still using CVS if they were a pre-existing
> > project.
> 
> Not only pre-existing projects on CVS though. If a new project is split
> off of an existing project, it's not going to want to go and use
> subversion. If developers from one of the CVS projects have a new idea,
> they're not going to want to go and make those new ideas be in a
> subversion project.

I would prefer to poll developers rather than assume that all developers
feel that way.  

-Fitz

--
Brian W. Fitzpatrick    <fi...@red-bean.com>   http://www.red-bean.com/fitz/

Re: [PROPOSAL] product groups

["B. W. Fitzpatrick" <fi...@red-bean.com>]

Rodney Waldhoff <rw...@apache.org> writes:
> My concerns with using SVN are more social than technical.

*nod*
 
> While I think it's pretty clear the SVN is technically superior, it's also
> pretty clear that substantially more users, contributors and committers
> are going to be familiar with CVS, and have a CVS tool chain set up and
> ready to use.  Using SVN puts up a barrier (and while not an enormous
> barrier, it is not a trivial one either) between those potential
> contributors and their contributions.  There's a little hump they'll have
> to get over.
> 
> The size of this hump may not be significant for "large" projects, like
> HTTPD or Tomcat for example, but for tiny little components like those
> that comprise apache-jakarta-commons and likely apache-commons as well,
> the hump is as big or bigger than the contribution itself.  I think it is
> likely that many potential contributors will find that hump not worth the
> trouble, and potential users, contributors and contributions will be lost.

> What I'd like to see is a larger installed based of SVN
> *clients*, because I'm afraid too many folks are going to find installing
> a SVN client to check out, or contribute a small patch to, a tiny commons
> component more trouble than it's worth.  I think the way to get to that
> installed base is to start with a larger project.  Convince a major
> project to convert to SVN first.

Excellent point, and I suspect that is one of the reasons that Justin
agreed to setup a CVS repository for components that transfer to common.

-Fitz

--
Brian W. Fitzpatrick    <fi...@red-bean.com>   http://www.red-bean.com/fitz/

Re: [PROPOSAL] product groups

[Rodney Waldhoff <rw...@apache.org>]

On Tue, 4 Nov 2003, B. W. Fitzpatrick wrote:

>
> Henri Yandell <ba...@generationjava.com> writes:
> >
> >
> > On Tue, 4 Nov 2003, Justin Erenkrantz wrote:
> >
> > > --On Tuesday, November 04, 2003 23:16:50 +0000 Stephen Colebourne
> > > <sc...@btopenworld.com> wrote:
> > >
> > >
> > > > The one potential spanner in the works for me is subversion. When 99% of
> > > > the world uses CVS, I really struggle with this one.
> > >
> > > Have you tried Subversion?  It really eases a lot of pain that CVS causes.
> >
> > Can I use a Subversion server with an existing CVS client? Some kind of
> > backwards compatibility bridge thing?
>
> No, but you can convert your CVS repository to a Subversion repository
> using cvs2svn.py (Although it still has some issues with converting tags
> and branches, it can convert the trunk very nicely).

My concerns with using SVN are more social than technical.

While I think it's pretty clear the SVN is technically superior, it's also
pretty clear that substantially more users, contributors and committers
are going to be familiar with CVS, and have a CVS tool chain set up and
ready to use.  Using SVN puts up a barrier (and while not an enormous
barrier, it is not a trivial one either) between those potential
contributors and their contributions.  There's a little hump they'll have
to get over.

The size of this hump may not be significant for "large" projects, like
HTTPD or Tomcat for example, but for tiny little components like those
that comprise apache-jakarta-commons and likely apache-commons as well,
the hump is as big or bigger than the contribution itself.  I think it is
likely that many potential contributors will find that hump not worth the
trouble, and potential users, contributors and contributions will be lost.

What I'd like to see is a larger installed based of SVN
*clients*, because I'm afraid too many folks are going to find installing
a SVN client to check out, or contribute a small patch to, a tiny commons
component more trouble than it's worth.  I think the way to get to that
installed base is to start with a larger project.  Convince a major
project to convert to SVN first.

(Also, I'll argue that the benefits of SVN are more tangible to larger
projects than to tiny commons components as well.)

>
> -Fitz
>
> --
> Brian W. Fitzpatrick    <fi...@red-bean.com>   http://www.red-bean.com/fitz/
>

- Rod <http://radio.weblogs.com/0122027/>