You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xml.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2004/06/11 12:17:27 UTC
CVS and Subversion
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: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: CVS and Subversion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 11 June 2004 23:23, Niclas Hedhman wrote:
> Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and
> commits.
Am I the only one who have this problem???
I am only using SVN CLI.
[niclas@f2 niclas]$ uname -a
Linux f2.hedhman.org 2.4.20-20.9 #1 Mon Aug 18 11:45:58 EDT 2003 i686 i686
i386 GNU/Linux
I have 2 ATA disks on the primary controller, and they are mirrored with
SoftRAID.
No other software I have, shows this type of lock-up, unless running out of
RAM and thrashing starts, in fact SVN behaves exactly like thrashing came
into the picture. Could that be the case??? I got 512MB and 'on a regular
day' "top" would report something like;
01:56:59 up 2 days, 20:42, 13 users, load average: 2.05, 0.97, 0.79
101 processes: 94 sleeping, 7 running, 0 zombie, 0 stopped
CPU states: 2.3% user 3.7% system 0.0% nice 0.0% iowait 93.8% idle
Mem: 513852k av, 507388k used, 6464k free, 0k shrd, 69212k buff
384884k actv, 1200k in_d, 11024k in_c
Swap: 1012072k av, 92016k used, 920056k free 212484k
cached
(sorry for the bad formatting)
Which I interpret that 'cached memory' is plenty and will be released if
necessary. Or does the intensive file reads (writes?) upset the Linux
algorithm of 'cached' vs 'thrashed' memory?
Hmmmm.... <headache quickly approaching from too much thinking>
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 11, 2004, at 5:33 PM, Brian W. Fitzpatrick wrote:
> On Fri, 2004-06-11 at 10:23, Niclas Hedhman wrote:
>> On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote:
>>
>>> 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.
>>
>> Another note that noone seems to consider, which I think is fairly
>> important
>> (read annoying);
>>
>> Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on
>> updates and
>> commits. Often so much that even the mouse is no longer tracking, and
>> always
>> making my entire desktop fairly unresponsive. And for Avalon that
>> means
>> ~1minute on my system (svn up)...
>
> Very interesting... I have never seen that behavior on my system, and
> I've worked with some pretty large repositories too...
For what it is worth on good old Sparc 5 systems and FreeBSD on a normal
486 or a pentium; we're talking 1-2Mbyte of exec for CVS and checkout
times
in the order of a few minutes top's; with SVN we needed to increase the
build
partitions with some 50 Mbytes and a normal check out on these
underspeced
machines with SVN can easily take 30-45 minutes for a large tree (say
apache, apr, tomcat, axis and some other bits from a local/private SVN
repository). On something like a pentium 4 I've never noticed the
difference.
But those dated dinosaurs are not exactly the infrastructure's I would
optimize
the ASF's toolchain for.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 10:23, Niclas Hedhman wrote:
> On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote:
>
> > 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.
>
> Another note that noone seems to consider, which I think is fairly important
> (read annoying);
>
> Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and
> commits. Often so much that even the mouse is no longer tracking, and always
> making my entire desktop fairly unresponsive. And for Avalon that means
> ~1minute on my system (svn up)...
Very interesting... I have never seen that behavior on my system, and
I've worked with some pretty large repositories too...
$ uname -a
Linux pantheon 2.4.19-pre10 #2 SMP Mon Jun 24 09:49:16 CDT 2002 i686
GNU/Linux
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Thom May <th...@planetarytramp.net>.
* Niclas Hedhman (niclas@hedhman.org) wrote :
> Another note that noone seems to consider, which I think is fairly important
> (read annoying);
>
> Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and
> commits. Often so much that even the mouse is no longer tracking, and always
> making my entire desktop fairly unresponsive. And for Avalon that means
> ~1minute on my system (svn up)...
>
Sounds like you don't have DMA enabled for your disks.
(I also have never seen this problem on a variety of machines)
-Thom
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Gianugo Rabellino <gi...@apache.org>.
On Jun 11, 2004, at 5:23 PM, Niclas Hedhman wrote:
>
> Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on
> updates and
> commits. Often so much that even the mouse is no longer tracking, and
> always
> making my entire desktop fairly unresponsive. And for Avalon that means
> ~1minute on my system (svn up)...
Weird, I've been using SVN from almost a year, way before I switched,
and never experienced/noticed that. Are you taking CLI subversion or
some GUI on top of it?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 11 June 2004 18:17, Dirk-Willem van Gulik wrote:
> 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.
Another note that noone seems to consider, which I think is fairly important
(read annoying);
Subversion eats almost all CPU cycles on a 2.4 Linux Kernel, on updates and
commits. Often so much that even the mouse is no longer tracking, and always
making my entire desktop fairly unresponsive. And for Avalon that means
~1minute on my system (svn up)...
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Felipe Leme <fe...@apache.org>.
I second what Niclas said. It's a rare situation, but when it happens,
it's a pain to recover (like, you press ^C because you regretted a
commit but you end up regretting have pressed ^C due to the mess it
caused :-)
Felipe
On Fri, 2004-06-11 at 12:11, Niclas Hedhman wrote:
> On Friday 11 June 2004 21:02, Jim Moore wrote:
> > Actually, the "all or nothing" part of the transaction isn't a big deal
> > because, as you said, it's very rare that a commit in CVS would fail.
>
> But I often change my mind half way through... (lazy thought-loading), Ctrl-C,
> and CVS is 'half way through' .
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 11 June 2004 21:02, Jim Moore wrote:
> Actually, the "all or nothing" part of the transaction isn't a big deal
> because, as you said, it's very rare that a commit in CVS would fail.
But I often change my mind half way through... (lazy thought-loading), Ctrl-C,
and CVS is 'half way through' .
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Jim Moore <lo...@mooresoft.net>.
"atomic commits" is accurate -- the transactional part is a consequence of
it. It's just that, in this case, the side-effect is cooler than the
"primary" feature.
But you're right in that it is different than most databases where you can't
usually get to the transaction information once it's committed; in SVN the
revision number is (effectively) the transaction id. In fact, what SVN
stores is more a "transaction log" than anything.
----- Original Message -----
From: "Vadim Gritsenko" <va...@reverycodes.com>
To: <co...@apache.org>
Sent: Friday, June 11, 2004 9:17 AM
Subject: Re: CVS and Subversion
> Jim Moore wrote:
>
> >Actually, the "all or nothing" part of the transaction isn't a big deal
> >because, as you said, it's very rare that a commit in CVS would fail.
> >
> >What is VERY cool about the atomic part is that all of your files in the
> >commit are part of the same transaction. With CVS it's a very difficult
to
> >determine what files were committed together. Take a look at what the
> >cvs-commit email program has to do in order to send out a single email
for
> >all the files you've committed to see an example, where it has to make a
> >bunch of assumptions like "What other files have the same commit
message?"
> >and "Were they committed at the same time (give or take a few seconds)?"
> >Reasonably intelligent changelog reports have the same problem, but they
> >have to do that for every file. Fortunately there are (nasty) perl
scripts
> >for figuring that kind of thing out, but it's simply a non-issue with
SVN.
> >If you want to know what other files changed as part of rev 1234 you
simply
> >ask the server what other files were part of that transaction since it
> >handles them all as one unit instead of bunches of seperate ones.
(Another
> >place it's nice is that if you have integration between your defect
system
> >and CVS you have to associate each file and rev back to the defect,
whereas
> >with SVN you only need to rev number as the files are implicit.)
> >
> >When I'm in "user" mode, I love the "move/rename keeps history" that
Brian
> >mentioned and don't really care about atomic/transactional commits.
> >However, when I'm doing tools & project administration, that's when the
> >transactions really rock.
> >
> >
>
> So, original mail ("atomic commits!") was misleading. It is really more
> about "SVN stores transaction log", but not about "atomic commit".
> Compare with databases, were transactions are atomic - but once
> committed, there is no way (usually) to find out which records were
> modified as part of transaction.
>
> Thanks for clarification.
>
> Vadim
>
>
> >-Jim Moore
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jim Moore wrote:
>Actually, the "all or nothing" part of the transaction isn't a big deal
>because, as you said, it's very rare that a commit in CVS would fail.
>
>What is VERY cool about the atomic part is that all of your files in the
>commit are part of the same transaction. With CVS it's a very difficult to
>determine what files were committed together. Take a look at what the
>cvs-commit email program has to do in order to send out a single email for
>all the files you've committed to see an example, where it has to make a
>bunch of assumptions like "What other files have the same commit message?"
>and "Were they committed at the same time (give or take a few seconds)?"
>Reasonably intelligent changelog reports have the same problem, but they
>have to do that for every file. Fortunately there are (nasty) perl scripts
>for figuring that kind of thing out, but it's simply a non-issue with SVN.
>If you want to know what other files changed as part of rev 1234 you simply
>ask the server what other files were part of that transaction since it
>handles them all as one unit instead of bunches of seperate ones. (Another
>place it's nice is that if you have integration between your defect system
>and CVS you have to associate each file and rev back to the defect, whereas
>with SVN you only need to rev number as the files are implicit.)
>
>When I'm in "user" mode, I love the "move/rename keeps history" that Brian
>mentioned and don't really care about atomic/transactional commits.
>However, when I'm doing tools & project administration, that's when the
>transactions really rock.
>
>
So, original mail ("atomic commits!") was misleading. It is really more
about "SVN stores transaction log", but not about "atomic commit".
Compare with databases, were transactions are atomic - but once
committed, there is no way (usually) to find out which records were
modified as part of transaction.
Thanks for clarification.
Vadim
>-Jim Moore
>
>
>----- Original Message -----
>From: "Vadim Gritsenko" <va...@reverycodes.com>
>To: <co...@apache.org>
>Sent: Friday, June 11, 2004 8:21 AM
>Subject: Re: CVS and Subversion
>
>
>
>
>>Ceki Gülcü wrote:
>>
>>
>>
>>>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?
>>>
>>>
>>"Atomic" as in "transaction" -- either all or nothing, should not crash
>>in-between. I've not seen such crashes with CVS, but apparently other
>>people encountered them.
>>
>>
>>
>>
>>>2) How easy is it to migrate an existing CVS repo to subversion?
>>>
>>>
>>infra has nifty scripts to convert everything including branches and
>>history.
>>
>>Vadim
>>
>>
>>
>>
>>>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
>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 14, 2004, at 6:04 PM, Stefano Mazzocchi wrote:
> Dirk-Willem van Gulik wrote:
>
>> On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote:
>>> Brian McCallister wrote:
.. snipped subtle umask magic which needs to fit the
... operational culture of the community.
..
>>> good hint, thanks.
>>>
>> As we had some conflicting requirements we pretty much killed all use
>> of svn over ssh - and forced people to use HTTP/DAV (even on
>> localhost). That solved 80% of those problems :-)
>
> can you elaborate more on this? [very interested]
>
Eh not much to elaborate - by removing SSH and direct repo
access/direct accounts - and only allowing a) svn through
apache (and some backup scripts) the whole per-user umask, group access
persm etc goes away - there is just the
user ID of the web server and the uid of hte backup and that is it.
(Though backup and recovery has a bit more
perms than I like (and we get nice certificate based user mngt - which
is really nice as you aint have to keep no
stinking per user secrets).
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Dirk-Willem van Gulik wrote:
>
> On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote:
>
>> Brian McCallister wrote:
>>
>>> [mccallister@kamajii mccallister]$ umask
>>> umask 0002
>>> [mccallister@kamajii mccallister]$ umask -S
>>> u=rwx,g=rwx,o=rx
>>> and set the group sticky bit on the repository home so that group is
>>> preserved
>>
>>
>> good hint, thanks.
>>
> As we had some conflicting requirements we pretty much killed all use of
> svn over ssh - and forced people to use HTTP/DAV (even on localhost).
> That solved 80% of those problems :-)
can you elaborate more on this? [very interested]
--
Stefano.
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 11, 2004, at 10:35 PM, Stefano Mazzocchi wrote:
> Brian McCallister wrote:
>
>> [mccallister@kamajii mccallister]$ umask
>> umask 0002
>> [mccallister@kamajii mccallister]$ umask -S
>> u=rwx,g=rwx,o=rx
>> and set the group sticky bit on the repository home so that group is
>> preserved
>
> good hint, thanks.
>
As we had some conflicting requirements we pretty much killed all use
of svn over ssh - and forced people to use HTTP/DAV (even on
localhost). That solved 80% of those problems :-)
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian McCallister wrote:
> [mccallister@kamajii mccallister]$ umask
> umask 0002
>
> [mccallister@kamajii mccallister]$ umask -S
> u=rwx,g=rwx,o=rx
>
> and set the group sticky bit on the repository home so that group is
> preserved
good hint, thanks.
--
Stefano.
Re: CVS and Subversion
Posted by Brian McCallister <br...@apache.org>.
[mccallister@kamajii mccallister]$ umask
umask 0002
[mccallister@kamajii mccallister]$ umask -S
u=rwx,g=rwx,o=rx
and set the group sticky bit on the repository home so that group is
preserved
-Brian
On Jun 11, 2004, at 3:00 PM, Stefano Mazzocchi wrote:
> Brian McCallister wrote:
>
>> We hit this a number of times with svn+ssh until we got everyone to
>> properly set their umask. haven't had it happen since then, however.
>
> uh, interesting, what umask did you use?
>
> --
> Stefano.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian McCallister wrote:
> We hit this a number of times with svn+ssh until we got everyone to
> properly set their umask. haven't had it happen since then, however.
uh, interesting, what umask did you use?
--
Stefano.
Re: CVS and Subversion
Posted by Brian McCallister <mc...@forthillcompany.com>.
We hit this a number of times with svn+ssh until we got everyone to
properly set their umask. haven't had it happen since then, however.
-Brian
On Jun 11, 2004, at 2:15 PM, Stefano Mazzocchi wrote:
> Pier Fumagalli wrote:
>
>> On 11 Jun 2004, at 22:02, Jim Moore wrote:
>>> Actually, the "all or nothing" part of the transaction isn't a big
>>> deal
>>> because, as you said, it's very rare that a commit in CVS would fail.
>> Problem being (though) is that I've seen Subversion (1.0.2 under
>> Linux) fail right because of that... Somehow an "atomic" transaction
>> was left open on the server, don't ask me why...
>> Basically, after that commit failed, the entire repository was so
>> slow that most TCP/IP connections were failing after 3 minutes for
>> timeouts...
>> Only solution was to run a "svn recover" followed by a "svn rmtxt"
>> and again followed by another "svn recover"...
>
> I am experiencing random svn corruptions with svnserve over ssh with
> svn 1.0 (how do I find out the real version btw? why isn't svn
> -v|--version give me the version?) over linux 2.6.4
>
> any clue?
>
> --
> Stefano.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian W. Fitzpatrick wrote:
> On Fri, 2004-06-11 at 13:15, Stefano Mazzocchi wrote:
>
>>Pier Fumagalli wrote:
>>
>>
>>>On 11 Jun 2004, at 22:02, Jim Moore wrote:
>>>
>>>
>>>>Actually, the "all or nothing" part of the transaction isn't a big deal
>>>>because, as you said, it's very rare that a commit in CVS would fail.
>>>
>>>
>>>Problem being (though) is that I've seen Subversion (1.0.2 under Linux)
>>>fail right because of that... Somehow an "atomic" transaction was left
>>>open on the server, don't ask me why...
>>>
>>>Basically, after that commit failed, the entire repository was so slow
>>>that most TCP/IP connections were failing after 3 minutes for timeouts...
>>>
>>>Only solution was to run a "svn recover" followed by a "svn rmtxt" and
>>>again followed by another "svn recover"...
>>
>>I am experiencing random svn corruptions with svnserve over ssh with svn
>>1.0
>
>
> Please be careful to distinguish "corruption" from "my repository needs
> to have 'svnadmin recover' run on it."
>
> Could you be running into a repository permissions error?
>
> http://subversion.tigris.org/project_faq.html#permissions
>
>
>>(how do I find out the real version btw? why isn't svn -v|--version
>>give me the version?) over linux 2.6.4
>>
>>any clue?
>
>
> 'svn --version' works for me:
>
> $ svn --version
> svn, version 1.0.2 (r9423)
> compiled Apr 28 2004, 17:16:48
> ...
hit me with a baseball bat!
--
Stefano, crawling back in his corner :-(
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 13:15, Stefano Mazzocchi wrote:
> Pier Fumagalli wrote:
>
> > On 11 Jun 2004, at 22:02, Jim Moore wrote:
> >
> >> Actually, the "all or nothing" part of the transaction isn't a big deal
> >> because, as you said, it's very rare that a commit in CVS would fail.
> >
> >
> > Problem being (though) is that I've seen Subversion (1.0.2 under Linux)
> > fail right because of that... Somehow an "atomic" transaction was left
> > open on the server, don't ask me why...
> >
> > Basically, after that commit failed, the entire repository was so slow
> > that most TCP/IP connections were failing after 3 minutes for timeouts...
> >
> > Only solution was to run a "svn recover" followed by a "svn rmtxt" and
> > again followed by another "svn recover"...
>
> I am experiencing random svn corruptions with svnserve over ssh with svn
> 1.0
Please be careful to distinguish "corruption" from "my repository needs
to have 'svnadmin recover' run on it."
Could you be running into a repository permissions error?
http://subversion.tigris.org/project_faq.html#permissions
> (how do I find out the real version btw? why isn't svn -v|--version
> give me the version?) over linux 2.6.4
>
> any clue?
'svn --version' works for me:
$ svn --version
svn, version 1.0.2 (r9423)
compiled Apr 28 2004, 17:16:48
...
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 11 Jun 2004, at 22:02, Jim Moore wrote:
>
>> Actually, the "all or nothing" part of the transaction isn't a big deal
>> because, as you said, it's very rare that a commit in CVS would fail.
>
>
> Problem being (though) is that I've seen Subversion (1.0.2 under Linux)
> fail right because of that... Somehow an "atomic" transaction was left
> open on the server, don't ask me why...
>
> Basically, after that commit failed, the entire repository was so slow
> that most TCP/IP connections were failing after 3 minutes for timeouts...
>
> Only solution was to run a "svn recover" followed by a "svn rmtxt" and
> again followed by another "svn recover"...
I am experiencing random svn corruptions with svnserve over ssh with svn
1.0 (how do I find out the real version btw? why isn't svn -v|--version
give me the version?) over linux 2.6.4
any clue?
--
Stefano.
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 17:43, James Duncan Davidson wrote:
> On Jun 11, 2004, at 08:45, Pier Fumagalli wrote:
>
> > That is when I started feeling that having all my history in big
> > berkeley DB files which I could not "cat" was kinda scary...
>
> Yeah, it's a bit scary for the largish project that I'm currently
> setting up on SVN as well. But we're working around this by using a
> derivative of hot-backup.py to keep multiple point-in-time backups of
> the complete database around as well as dumps of the repository
> alongside.
In Subversion 1.1.0, you will be able to choose between BDB and new
filesystem backend 'libsvn_fs_fs' that uses flat files to store all
data. I suspect that a lot of people will prefer this option for
smaller projects.
> Disk is cheeeap. :)
Amen, brother!
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by James Duncan Davidson <du...@x180.net>.
On Jun 11, 2004, at 08:45, Pier Fumagalli wrote:
> That is when I started feeling that having all my history in big
> berkeley DB files which I could not "cat" was kinda scary...
Yeah, it's a bit scary for the largish project that I'm currently
setting up on SVN as well. But we're working around this by using a
derivative of hot-backup.py to keep multiple point-in-time backups of
the complete database around as well as dumps of the repository
alongside.
Disk is cheeeap. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 14, 2004, at 8:37 AM, Ask Bjørn Hansen wrote:
> On Sat, 12 Jun 2004 00:45:31 +0900, Pier Fumagalli
> <pi...@betaversion.org> wrote:
>
>> That is when I started feeling that having all my history in big
>> berkeley DB files which I could not "cat" was kinda scary...
>
> That's why the Subversion developers kindly gave us all sorts of ways
> to make backups:
>
> http://svnbook.red-bean.com/svnbook/book.html#svn-ch-5-sect-3.6
>
> :-)
>
Aye - and they (including CVS to massage them) have saved my ass on an
almost monthly basis prior to 1.0.2. :-(
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Ask Bjørn Hansen <ah...@gmail.com>.
On Sat, 12 Jun 2004 00:45:31 +0900, Pier Fumagalli <pi...@betaversion.org> wrote:
> That is when I started feeling that having all my history in big
> berkeley DB files which I could not "cat" was kinda scary...
That's why the Subversion developers kindly gave us all sorts of ways
to make backups:
http://svnbook.red-bean.com/svnbook/book.html#svn-ch-5-sect-3.6
:-)
- ask
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11 Jun 2004, at 22:02, Jim Moore wrote:
> Actually, the "all or nothing" part of the transaction isn't a big deal
> because, as you said, it's very rare that a commit in CVS would fail.
Problem being (though) is that I've seen Subversion (1.0.2 under Linux)
fail right because of that... Somehow an "atomic" transaction was left
open on the server, don't ask me why...
Basically, after that commit failed, the entire repository was so slow
that most TCP/IP connections were failing after 3 minutes for
timeouts...
Only solution was to run a "svn recover" followed by a "svn rmtxt" and
again followed by another "svn recover"...
That is when I started feeling that having all my history in big
berkeley DB files which I could not "cat" was kinda scary...
But on the other hand, we (VNU, at work) are still using subversion
because of all its other features (moving, copying,
tag^H^H^Hbranch^H^H^H^H^Hcopying) and its quite impressive speed over
slow/remote networks...
Pier
> What is VERY cool about the atomic part is that all of your files in
> the
> commit are part of the same transaction. With CVS it's a very
> difficult to
> determine what files were committed together. Take a look at what the
> cvs-commit email program has to do in order to send out a single email
> for
> all the files you've committed to see an example, where it has to make
> a
> bunch of assumptions like "What other files have the same commit
> message?"
> and "Were they committed at the same time (give or take a few
> seconds)?"
> Reasonably intelligent changelog reports have the same problem, but
> they
> have to do that for every file. Fortunately there are (nasty) perl
> scripts
> for figuring that kind of thing out, but it's simply a non-issue with
> SVN.
> If you want to know what other files changed as part of rev 1234 you
> simply
> ask the server what other files were part of that transaction since it
> handles them all as one unit instead of bunches of seperate ones.
> (Another
> place it's nice is that if you have integration between your defect
> system
> and CVS you have to associate each file and rev back to the defect,
> whereas
> with SVN you only need to rev number as the files are implicit.)
>
> When I'm in "user" mode, I love the "move/rename keeps history" that
> Brian
> mentioned and don't really care about atomic/transactional commits.
> However, when I'm doing tools & project administration, that's when the
> transactions really rock.
>
> -Jim Moore
>
>
> ----- Original Message -----
> From: "Vadim Gritsenko" <va...@reverycodes.com>
> To: <co...@apache.org>
> Sent: Friday, June 11, 2004 8:21 AM
> Subject: Re: CVS and Subversion
>
>
>> Ceki Gülcü wrote:
>>
>>> 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?
>>
>>
>> "Atomic" as in "transaction" -- either all or nothing, should not
>> crash
>> in-between. I've not seen such crashes with CVS, but apparently other
>> people encountered them.
>>
>>
>>> 2) How easy is it to migrate an existing CVS repo to subversion?
>>
>>
>> infra has nifty scripts to convert everything including branches and
>> history.
>>
>> Vadim
>>
>>
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
Re: CVS and Subversion
Posted by Jim Moore <lo...@mooresoft.net>.
Actually, the "all or nothing" part of the transaction isn't a big deal
because, as you said, it's very rare that a commit in CVS would fail.
What is VERY cool about the atomic part is that all of your files in the
commit are part of the same transaction. With CVS it's a very difficult to
determine what files were committed together. Take a look at what the
cvs-commit email program has to do in order to send out a single email for
all the files you've committed to see an example, where it has to make a
bunch of assumptions like "What other files have the same commit message?"
and "Were they committed at the same time (give or take a few seconds)?"
Reasonably intelligent changelog reports have the same problem, but they
have to do that for every file. Fortunately there are (nasty) perl scripts
for figuring that kind of thing out, but it's simply a non-issue with SVN.
If you want to know what other files changed as part of rev 1234 you simply
ask the server what other files were part of that transaction since it
handles them all as one unit instead of bunches of seperate ones. (Another
place it's nice is that if you have integration between your defect system
and CVS you have to associate each file and rev back to the defect, whereas
with SVN you only need to rev number as the files are implicit.)
When I'm in "user" mode, I love the "move/rename keeps history" that Brian
mentioned and don't really care about atomic/transactional commits.
However, when I'm doing tools & project administration, that's when the
transactions really rock.
-Jim Moore
----- Original Message -----
From: "Vadim Gritsenko" <va...@reverycodes.com>
To: <co...@apache.org>
Sent: Friday, June 11, 2004 8:21 AM
Subject: Re: CVS and Subversion
> Ceki Gülcü wrote:
>
> > 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?
>
>
> "Atomic" as in "transaction" -- either all or nothing, should not crash
> in-between. I've not seen such crashes with CVS, but apparently other
> people encountered them.
>
>
> > 2) How easy is it to migrate an existing CVS repo to subversion?
>
>
> infra has nifty scripts to convert everything including branches and
> history.
>
> Vadim
>
>
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 08:17, Brian McCallister wrote:
> On Jun 11, 2004, at 8:21 AM, Vadim Gritsenko wrote:
> >> 2) How easy is it to migrate an existing CVS repo to subversion?
> >
> >
> > infra has nifty scripts to convert everything including branches and
> > history.
>
> Subversion ships with a cvs2svn script which takes a long time to run,
> but does a pretty good conversion job.
I've spent the month of May substantially rewriting cvs2svn, and
although I'm not done yet, it's already faster--especially on Really
Large multi-gigabyte repositories.
> We used it on a big, hairy, cvs
> repository where I work and it performed flawlessly. Interestingly, it
> attempts to atomize commits by assuming anything in a 5 minute window
> is one commit.
It's not quite that simple...multiple CVS revisions committed in the
same 5 minute window *also* with the same author and the same log
message are treated as as a single Subversion commit (with a few
edge-case exceptions).
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Jun 11, 2004, at 8:21 AM, Vadim Gritsenko wrote:
> Ceki Gülcü wrote:
>
>> 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?
>
>
> "Atomic" as in "transaction" -- either all or nothing, should not
> crash in-between. I've not seen such crashes with CVS, but apparently
> other people encountered them.
I had meant that all of the changes checked in with a given commit are
included in one "bunch." The commit can be rolled back as a whole
instead of having to roll back each file (or rollback to a date, or
tag). Basically like putting a cheap tag on every commit,
automagically, which respects deletes, adds, moves in an expected
manner.
>> 2) How easy is it to migrate an existing CVS repo to subversion?
>
>
> infra has nifty scripts to convert everything including branches and
> history.
Subversion ships with a cvs2svn script which takes a long time to run,
but does a pretty good conversion job. We used it on a big, hairy, cvs
repository where I work and it performed flawlessly. Interestingly, it
attempts to atomize commits by assuming anything in a 5 minute window
is one commit.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ceki Gülcü wrote:
> 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?
"Atomic" as in "transaction" -- either all or nothing, should not crash
in-between. I've not seen such crashes with CVS, but apparently other
people encountered them.
> 2) How easy is it to migrate an existing CVS repo to subversion?
infra has nifty scripts to convert everything including branches and
history.
Vadim
> 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
>
..
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Ceki Gülcü <ce...@qos.ch>.
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: 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
--
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: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 08:29, Henri Yandell wrote:
> On Fri, 11 Jun 2004, Brian W. Fitzpatrick wrote:
> > I know of no uses cases for what you're describing... do you have one?
>
> Two of them.
>
> 1) Common for a piece of taggable code to inherit something outside of its
> directory, usually either a super-build.xml, or a super-project.xml. It's
> hard to tag these when you tag the directory. This one is possible, but
> quite a pain in SVN. I had to checkout just my releases/ directory, then
> do manual copying. I suspect that it wasted diskspace on the server as it
> wasn't url-url.
Nope. If there are no content differences, the Subversion repository
will do the most efficient thing and just copy the node (not the
contents).
> 2) I suspect others do this differently, but I've often released things
> from Jakarta Commons where we've not included a certain directory or bunch
> of files in the release because they're not ready yet. In this case, they
> shouldn't be tagged with that release either.
Fair enough. Those two cases are a bit difficult to manage in
Subversion.
> One option here might be to branch the code, then delete from the branch
> the things you don't want. As branching and tagging seem to be the same
> thing in SVN, I suspect this would work. Process change.
Yes it would.
> Yep. I suspect the solution is to modify the development process when it
> has problems, but I think I heard something about subversion supporting a
> property-tagging system at some point in the future that would work much
> like CVS? This was 3rd hand information, and you'd know better :)
No clue what this is about. Subversion does have the concept of
per-node (file or directory) metadata, and per-revision
metadata--they're called 'properties' and 'revision properties'
respectively.
See the section on Properties in the Subversion book:
http://svnbook.red-bean.com/svnbook/ch07s02.html
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 11, 2004, at 3:29 PM, Henri Yandell wrote:
>> I know of no uses cases for what you're describing... do you have one?
>
> Two of them.
>
> 1) Common for a piece of taggable code to inherit something outside of
> its
..
> 2) I suspect others do this differently, but I've often released things
>
From the peanut gallery - We encounter those a lot as well esp. with
code where
some files in a release where certified by some outside agency or link
to something
higher up - like the meta makefiles.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 11 Jun 2004, Brian W. Fitzpatrick wrote:
> On Fri, 2004-06-11 at 07:20, Henri Yandell wrote:
>
> > 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.
>
> Since a tag is essentially a 'copy' in Subversion, it is near impossible
> to 'tag' a directory without tagging its contents (to do so, you would
> have to copy the directory and then delete all of its contents). FWIW,
> you can copy a single file into the tags directory--that's essentially
> tagging a file, although it's not typically done that way.
>
> I know of no uses cases for what you're describing... do you have one?
Two of them.
1) Common for a piece of taggable code to inherit something outside of its
directory, usually either a super-build.xml, or a super-project.xml. It's
hard to tag these when you tag the directory. This one is possible, but
quite a pain in SVN. I had to checkout just my releases/ directory, then
do manual copying. I suspect that it wasted diskspace on the server as it
wasn't url-url.
2) I suspect others do this differently, but I've often released things
from Jakarta Commons where we've not included a certain directory or bunch
of files in the release because they're not ready yet. In this case, they
shouldn't be tagged with that release either.
One option here might be to branch the code, then delete from the branch
the things you don't want. As branching and tagging seem to be the same
thing in SVN, I suspect this would work. Process change.
> Subversion has constant time O(1) tagging (copying). That means that
> you can tag (copy) a tree containing 50,000 files in about 2 seconds.*
Yep, speed is nice. Especially with lots of binaries in there, and the
smaller space on the server too.
> This is one of several areas that Subversion is different from CVS.
Yep. I suspect the solution is to modify the development process when it
has problems, but I think I heard something about subversion supporting a
property-tagging system at some point in the future that would work much
like CVS? This was 3rd hand information, and you'd know better :)
I'm still a newbie to svn, but am generally finding svn a simple change on
the client side.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-06-11 at 07:20, Henri Yandell wrote:
> 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.
Since a tag is essentially a 'copy' in Subversion, it is near impossible
to 'tag' a directory without tagging its contents (to do so, you would
have to copy the directory and then delete all of its contents). FWIW,
you can copy a single file into the tags directory--that's essentially
tagging a file, although it's not typically done that way.
I know of no uses cases for what you're describing... do you have one?
Subversion has constant time O(1) tagging (copying). That means that
you can tag (copy) a tree containing 50,000 files in about 2 seconds.*
In CVS, that will take you somewhere in the neighborhood of 30 minutes
since CVS's tagging is O(n). The same goes for branching. Oh and this
copy only takes a tiny amount of space in the Subversion repository.
* This is true of URL to URL copies only--if you copy a huge tree to
another location in your working copy, of course, Subversion will have
to take time to copy the files on your filesystem.
This is one of several areas that Subversion is different from CVS.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 14, 2004 at 06:13:17PM +0200, Dirk-Willem van Gulik wrote:
>...
> Cause it actually lives on another machine than the repo (with
> an ocean in between). We tried this however for the toy site
> wleiden.webweaving.org:8080/svn/node-config/ (just 3.5Gb and
> a few thousands commits sofar) and ran into too many puzzles;
> like index.html; ensuring mod_perl did the right thing, etc. Though
> I am sure it is possible.
No, actually it isn't. Too many of the standard Apache modules (such as
mod_autoindex and mod_dir) look directly into the filesystem. We need a
"data store" mechanism in core Apache which those modules can use to query
"filesystem-ish" properties. We've discussed this a number of times on the
httpd developer list.
mod_perl could be used to write some filters to apply to the SVN content,
but some serious work in mod_perl (and possibly core apache) would be
needed for SVN to serve up Perl scripts to mod_perl to execute to generate
the content.
mod_php can't integrate well; the PHP parser actually requires a handle
onto the filesystem, so it isn't possible at this time to pick up scripts
from arbitrary data stores.
So... if you have anything beyond a basic site, you'd need to use Dirk's
suggestion of an auto-checkout (heck, you need it simply for index.html).
Eventually, we'll have better support in core Apache, but don't hold your
breath until then. It might be a while :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 14, 2004, at 6:02 PM, Stefano Mazzocchi wrote:
> Dirk-Willem van Gulik wrote:
>
>> On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote:
>>> 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?
>> In the company we right now use a small script, triggered by
>> the commmit - which syncs the website up everytime a
>> commit is made to the released branch/tag.
> curious, why not mod_proxy-it directly?
>
Cause it actually lives on another machine than the repo (with
an ocean in between). We tried this however for the toy site
wleiden.webweaving.org:8080/svn/node-config/ (just 3.5Gb and
a few thousands commits sofar) and ran into too many puzzles;
like index.html; ensuring mod_perl did the right thing, etc. Though
I am sure it is possible.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Stefano Mazzocchi <st...@apache.org>.
Dirk-Willem van Gulik wrote:
>
> On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote:
>
>> 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?
>
>
> In the company we right now use a small script, triggered by
> the commmit - which syncs the website up everytime a
> commit is made to the released branch/tag.
curious, why not mod_proxy-it directly?
--
Stefano.
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 11, 2004, at 2:20 PM, Henri Yandell wrote:
> 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?
In the company we right now use a small script, triggered by
the commmit - which syncs the website up everytime a
commit is made to the released branch/tag.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: CVS and Subversion
Posted by Henri Yandell <ba...@generationjava.com>.
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
Re: CVS and Subversion
Posted by Brian McCallister <br...@apache.org>.
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
Re: CVS and Subversion
Posted by "Peter B. West" <pb...@tpg.com.au>.
Thanks Dirk for addressing this issue, and thanks Glen for raising it.
It's a small nag I have had in the back of my mind for some time.
Peter
Dirk-Willem van Gulik wrote:
>
> On Jun 12, 2004, at 2:51 AM, Glen Mazza wrote:
>
>> I think it should be noted, for those unaware, that
>> the ASF Chairman is a team member on the Subversion
>> project. (http://www.lyra.org/greg/)
>
>
> Historically within the ASF people have separated their private life,
> role-at-work and other hobby-horses and their hat's quite well. And I
> strongly believe that Greg is doing so carefully as well.
...
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: CVS and Subversion
Posted by Dirk-Willem van Gulik <di...@asemantics.com>.
On Jun 12, 2004, at 2:51 AM, Glen Mazza wrote:
> I think it should be noted, for those unaware, that
> the ASF Chairman is a team member on the Subversion
> project. (http://www.lyra.org/greg/)
Historically within the ASF people have separated their private life,
role-at-work and other hobby-horses and their hat's quite well. And I
strongly believe that Greg is doing so carefully as well.
> Even if we're not being forced into SVN, this is
> something the Apache teams should be informed of.
I personally hope that things are kept separate. A lot of us have alter
ego's working on other open source projects, on standards bodies and on
proprietary code - and we really need to ensure that sound engineering
judgement is not compromised by this - instead it should be something
which strengthens.
But I can see that it may seem that there is a certain level of
evangelizing akin to the 'take-it-all' that seen in the
gnu/libtool/configure or in the qmail/djb-dns in that part of the
world. Sofar however I completely trust the Infrastructure team to help
the PMCs build the right infrastructure for the developers and for ASF
(rather than force the ASF to use Subversion for market-share reasons)
- and I've only seen the most professional of behaviours.
DO bear in mind that the ideas and concepts going into subversion
derive directly from the ASF: it tries to address, fix or mitigate
every fault and issue we have had over the past 5+ years in the ASF. So
it is hard not to see this as 'nearly ideal' from a functional and code
mntg perspective.
Ultimately however it is not the board, chariman or ASF who decides
what each projects use - that is something for each PMC and
each committer/developer community themselves to determine. And the
role of the ASF itself is limited to long term code custodianship which
is far removed from the operational choice of a code mngt platform once
the legal auditability and reconstruction needs are met.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: CVS and Subversion
Posted by Ted Leung <tw...@sauria.com>.
Glen,
There are a number of ASF members and committers who are involved in
the Subversion project. This has been well known since at least 2001.
Every year at ApacheCon there has been a presentation on Subversion.
Many of us have been waiting for Subversion to be ready, and this
pre-dates Greg's chairmanship.
There are a number of technical reasons why Subversion is preferable to
CVS. Please remember that the people who are running the ASF
infrastructure are volunteers, in addition to be developers on Apache
projects. Anything that we can do to ease the burden on these folks is
a benefit to the entire foundation. Of course more volunteers to help
with infrastructure tasks would be good too.
Ted
On Jun 11, 2004, at 5:51 PM, Glen Mazza wrote:
> Dirk-Willem,
>
> I think it should be noted, for those unaware, that
> the ASF Chairman is a team member on the Subversion
> project. (http://www.lyra.org/greg/)
>
> Even if we're not being forced into SVN, this is
> something the Apache teams should be informed of.
>
> Glen
>
> --- Dirk-Willem van Gulik <di...@webweaving.org>
> 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.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>
----
Ted Leung Blog: <http://www.sauria.com/blog>
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org
Re: CVS and Subversion
Posted by Glen Mazza <gr...@yahoo.com>.
Dirk-Willem,
I think it should be noted, for those unaware, that
the ASF Chairman is a team member on the Subversion
project. (http://www.lyra.org/greg/)
Even if we're not being forced into SVN, this is
something the Apache teams should be informed of.
Glen
--- Dirk-Willem van Gulik <di...@webweaving.org>
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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org