Thread: Re: [PATCHES] CVS should die
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@bluetwanger.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@dunslane.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@dunslane.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Greg Stark said: > > Andrew Dunstan <andrew@dunslane.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