www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: CVS and Subversion
Date Fri, 11 Jun 2004 12:20:44 GMT

Two biggest problems I forsee with subversion:

1) Website needs to be in SVN, else we'll still need accounts for everyone
who wants to modify their site annd do releases. Are the SVN based
projects taking an approach that handles this? Will it?

2) Tagging is clumsy. (I may just not be seeing it in the manual). It
seems hard to tag a directory and files not in that directory with a tag,
or tag a directory without tagging every file in it.

Otherwise I'm enjoying using subversion. I'm going to try having a
structure of:

/site/
/trunk/
/distributions/
/jar-repository/

and see if I can manage to not give out any accounts.

Hen

On Fri, 11 Jun 2004, Brian McCallister wrote:

> I think the best way to sell Subversion is "atomic commits" and
> "move/rename keeps history" (big seller to the Java "we love cheap
> rename in [Eclipse | IDEA | JDEE]" crowd) ;-)
>
> Now we just need to talk about adding dummy -dP flags to update so that
> I can stop getting errors...
>
> Did I mention "atomic commits" ?
>
> -Brian
>
> ps: atomic commits
>
> On Jun 11, 2004, at 6:17 AM, Dirk-Willem van Gulik wrote:
>
> > In reaction to some worried emails related to some projects moving
> > from CVS to Subversion.
> >
> > ->	Do not panic.
> >
> > ->	There is no ASF driven push (yet) for this move, no deadlines, no
> > forcing.
> >
> > ->	It is you, the developers yourself, in each project who decide for
> > -yourself-
> > 	when and if it is time to go to Subversion - just let infrastructure
> > know
> > 	and they'll help you with the transition.
> >
> > ->	But I urge you to give it a look - it is a darn cool piece of
> > technology; and
> > 	it integrates very nicely with other tools.
> >
> > And although it is true that Subversion is young and has a serious
> > footprint - it does have
> > one important feature for projects like the ASF:  it no longer
> > requires user accounts in order
> > to do commits. So in theory it is easier to secure a box and guard
> > against changes under the
> > hood; i.e. done to the repository directly. And thus tamper with our
> > record of history - as right
> > now developers -must- have r/w access to disk with the repository
> > itself on the CVS machine.
> > With about a thousand committers using several thousands of machines
> > back home and a
> > ssh/password based access controls it is a given that things leak over
> > time. And one leak is
> > quite enough.
> >
> > Thus reducing history/repository access alone is something the ASF as
> > the legal steward
> > of the code cares about a lot. (Those who where around a few years
> > back during the last
> > compromise of the  CVS  machine may recall the countless hours of work
> > when we had to
> > pour over the CVS  records and backups to certify each and every
> > file). It also means that
> > subversion is easier to sandbox - thus further minimizing the damage
> > from 'real' exploits.
> >
> > So all in all - it is a step  forward; but yes a relatively young step
> > - and that is why we are
> > not yet making this an ASF wide compulsory change.
> >
> > Secondly Ben Laurie/infrastructure is working on a ASF wide
> > Certificate Authority in the
> > Bunker.co.uk using a machine specially donated by
> > Ironsystems.com/Cliff Skolnick. Once
> > that is in place we've added an other much needed layer which allows
> > us to continue to
> > scale in numbers of developers without suddenly needing a dozen full
> > time sysadmins :)
> > and it allows us to decrease the sensitive information, like password
> > files, which need
> > to be managed on a daily basis by multiple people on the machines even
> > more.
> >
> > And ultimately it means that it becomes more and more possible to rely
> > less on a
> > 'unix root' admin - and means that we can handle the mutations from
> > the then several
> > thousands of commtiters on a timely basis.
> >
> > So in sort - and to stress: there are no deadlines, pushing or sticks
> > to get projects
> > to move from CVS to Subversion. Just the above carrots. But unless the
> > early projects
> > hit some major snags with subversion - DO expect the ASF to move there
> > in the next
> > two or three years - to allow us to continue to scale the
> > infrastructure along with the
> > number of developers and their demands while being good stewards to
> > our  code
> > heritage at the same time
> >
> > On a positive note; do look at subversion; play with it - and note
> > that its modern
> > infrastructure and standard based protocols do allow for levels of
> > integration
> > previously hard to attain.
> >
> > Thanks,
> >
> > Dw,
> > --
> > Dirk-Willem van Gulik, President of the Apache Software Foundation.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: community-unsubscribe@apache.org
> > For additional commands, e-mail: community-help@apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message