www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: CVS and Subversion
Date Fri, 11 Jun 2004 11:04:54 GMT
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


Mime
View raw message