Re: [PATCHES] CVS should die

Ian Barwick wrote:
> flat-file based backend ... and the docs mention possible issues with
scalability.

My impression from being on the Subversion mailing lists:

The FSFS backend (flat-file system) scalability issues remain largely
theoretical. In practice, it appears to work at least as well as BDB.

Some performance issues with having many small files as part of the
back-end repository implementation (which FSFS does) are more likely to
manifest themselves on some filesystems that have trouble with that
condition. Such filesystems seem to mainly exist for Windows. Unix
systems seem much more immune to that type of degradation.

Heikki Linnakangas wrote:
> Interestingly, the subversion repository is 585MB, and the CVS
repository is only 260MB,

BDB or FSFS back-end? FSFS seems to require less space. (The BDB
backend tends to pre-allocate space though, so maybe there was a big
jump, but then growth will slow markedly, so making a comparison for a
repository that will continue to grow is difficult.)

If you are interested in some significant-sized projects that are known
to use Subversion, some are listed on the testimonials page:
http://subversion.tigris.org/propaganda.html

I'm just a happy user of both Subversion and PosgreSQL.

-Travis

On Fri, 5 Nov 2004, Travis P wrote:

> Heikki Linnakangas wrote:
>> Interestingly, the subversion repository is 585MB, and the CVS repository
> is only 260MB,
>
> BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend
> tends to pre-allocate space though, so maybe there was a big jump, but then
> growth will slow markedly, so making a comparison for a repository that will
> continue to grow is difficult.)

BDB.

- Heikki

В Птн, 05.11.2004, в 21:40, Heikki Linnakangas пишет:
> On Fri, 5 Nov 2004, Travis P wrote:
>
> > Heikki Linnakangas wrote:
> >> Interestingly, the subversion repository is 585MB, and the CVS repository
> > is only 260MB,
> >
> > BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend
> > tends to pre-allocate space though, so maybe there was a big jump, but then
> > growth will slow markedly, so making a comparison for a repository that will
> > continue to grow is difficult.)
>
> BDB.

Here's what the subversion book has to say about that:

http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A

We use svn over ssh and recently switched to fsfs because of the umask
problem and because read-only access to bdb causes writes to the
database.

--
Markus Bertheau <twanger(at)bluetwanger(dot)de>

Markus Bertheau wrote:

>В Птн, 05.11.2004, в 21:40, Heikki Linnakangas пишет:
>
>
>>On Fri, 5 Nov 2004, Travis P wrote:
>>
>>
>>
>>>Heikki Linnakangas wrote:
>>>
>>>
>>>>Interestingly, the subversion repository is 585MB, and the CVS repository
>>>>
>>>>
>>>is only 260MB,
>>>
>>>BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend
>>>tends to pre-allocate space though, so maybe there was a big jump, but then
>>>growth will slow markedly, so making a comparison for a repository that will
>>>continue to grow is difficult.)
>>>
>>>
>>BDB.
>>
>>
>
>Here's what the subversion book has to say about that:
>
>http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A
>
>We use svn over ssh and recently switched to fsfs because of the umask
>problem and because read-only access to bdb causes writes to the
>database.
>
>

This just reinforces Tom's well-made point about maturity/stability. I
rejected using SVN on another project a few months ago for just this
sort of reason.

cheers

andrew

>>>> Heikki Linnakangas wrote:
>>>>
>>>>> Interestingly, the subversion repository is 585MB, and the CVS
>>>>> repository is only 260MB,

So apparently this is a limitation of svn2cvs. It uses a lot more space to
represent tags and branches than would be required if they had been created in
svn directly. Unfortunately it's a hard problem to solve any better than it
is.

> Markus Bertheau wrote:
>
>> Here's what the subversion book has to say about that:
>>
>> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A
>>
>> We use svn over ssh and recently switched to fsfs because of the umask
>> problem and because read-only access to bdb causes writes to the
>> database.

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:

> This just reinforces Tom's well-made point about maturity/stability. I rejected
> using SVN on another project a few months ago for just this sort of reason.

I'm not sure what this says about maturity, you realize read-only access to
CVS also does writes to the repository? There are patches to change this
floating around but it's never been merged "upstream" because there is no
"upstream" maintainer any more. I guess if you want mature software you can't
get any more mature than using orphaned packages.

--
greg

Greg Stark wrote:
>
> >>>> Heikki Linnakangas wrote:
> >>>>
> >>>>> Interestingly, the subversion repository is 585MB, and the CVS
> >>>>> repository is only 260MB,
>
> So apparently this is a limitation of svn2cvs. It uses a lot more space to
> represent tags and branches than would be required if they had been created in
> svn directly. Unfortunately it's a hard problem to solve any better than it
> is.
>
> > Markus Bertheau wrote:
> >
> >> Here's what the subversion book has to say about that:
> >>
> >> http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A
> >>
> >> We use svn over ssh and recently switched to fsfs because of the umask
> >> problem and because read-only access to bdb causes writes to the
> >> database.
>
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
> > This just reinforces Tom's well-made point about maturity/stability. I rejected
> > using SVN on another project a few months ago for just this sort of reason.
>
> I'm not sure what this says about maturity, you realize read-only access to
> CVS also does writes to the repository? There are patches to change this
> floating around but it's never been merged "upstream" because there is no
> "upstream" maintainer any more. I guess if you want mature software you can't
> get any more mature than using orphaned packages.

When software reaches perfection, it doesn't need a maintainer.

(Bruce ducks for cover.)

LOL

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Greg Stark said:
>
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> This just reinforces Tom's well-made point about maturity/stability. I
>> rejected using SVN on another project a few months ago for just this
>> sort of reason.
>
> I'm not sure what this says about maturity, you realize read-only
> access to CVS also does writes to the repository? There are patches to
> change this floating around but it's never been merged "upstream"
> because there is no "upstream" maintainer any more. I guess if you want
> mature software you can't get any more mature than using orphaned
> packages.
>

I am painfully aware of CVS's behaviour - it's given us plenty of grief
getting it right on pgfoundry, as well giving me occasional grief w.r.t.
other repositories I am responsible for.

CVS is on the way out, for plenty of very good reasons. It is past its
use-by date. I don't think anyone seriously disagrees with that. Choosing
when to switch to an alternative, and what the alternative will be, is the
issue.

For example, unless I'm wrong there is not yet a subversion equivalent of
CVSup. That's something I would personally be very reluctant to lose.

cheers

andrew