Heu.., a couple of questions from the totally ignorant (me).
1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it?
2) How easy is it to migrate an existing CVS repo to subversion?
Thanks in advance for your response, even if it is RTFM.
At 01:04 PM 6/11/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
