You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2004/01/08 18:38:21 UTC

Migrating to SVN

Jason Webb wrote:
> Noel J. Bergman wrote:
> > How do you feel about SVN?  :-)  Want to be the first
> > James guinea pig?  We are going to have to start migrating to
> > it, anyway, soon enough.

> Will all the James projects go to SVN at once or will we
> keep CVS and SVN together for a while?

> Any idea on timeframes as well?

When SVN version 1.0 is released, which is anticipated to be this month, we
should expect that a request will come from the infrastructure team to start
migrating on a voluntary basis.  As I understand it, sometime around the end
of the year, any stragglers will be asked to migrate on more of a mandated
basis.

Steve Brewin wrote:
> Danny Angus wrote:
> > Noel J. Bergman wrote:
> > > about SVN?  :-)  Want to be the first James
> > > We are going to have to start migrating to it,
> > > anyway, soon enough.
> > No. That should be a PMC decision

Of course it should be a PMC decision.  I was simply asking Steve in terms
of feeling him out for his thoughts on this new codebase, before raising the
question more broadly.

> > and I think we do it once-for-all, when we're asked/invited
> > to not before

That will most likely be this month, although we won't be asked to move
immediately.  But we won't have to move immediately, and we should make sure
that all Committers are comfortable.  Anyone using cvs from the command line
should be fine.  The major problems would be for anyone relying upon the
integrated CVS support in eclipse v3, as I understand it.  See
http://scm.tigris.org for various client tools.  I've experience so far with
the SVN CLI and with TortoiseSVN.

> > and not piecemeal.  Moving to SVN is potentially a substantially
> > disruptive step and while I would welcome the benefit I don't think
> > we should be rushing into it.

Agreed.  How we get into SVN is our business, and we'll need to plan it.  I
am wondering, and want to find out, if the CVS -> SVN process would create
separate trees in branches/, and make it easier to help merge branch_2_1_fcs
with MAIN.  But if we have committers for whom it would be difficult to go
to SVN, that's a moot point.  In terms of management, I have been doing some
of the SVN configuration, and it is very easy.  And so far, both of the
major projects that moved from CVS to SVN have done so quite smoothly.

> > Splitting the project across two different versioning systems
> > offers more disadvatages than advantages.

> If Sieve will eventually have to be moved to SVN and the SVN
> support is in place, it may as well start out there.  As it
> will be a new, independent, module it will have no impact on
> when and how James transitions to SVN, save for the fact that
> I may learn a few things which may help James later.

That is the same reasoning I had applied behind my inquiry.  JSieve being a
totally separate packaging, I thought that it would give us a chance to work
with SVN before we have to make the migration for our major released
product.

> Not sure this will make it through your filter :-)

I have replaced all occurrences of the word most likely causing trouble with
its abbreviated form.  That may help.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org