Re: [PATCHES] CVS should die
Markus Bertheau
> 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 <twa...@bluetwanger.de>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Andrew Dunstan
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
Greg Stark
>>>> 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 <and...@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
Bruce Momjian
>
> >>>> 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 <and...@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
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Andrew Dunstan
>
> Andrew Dunstan <and...@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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Andrew McMillan
>
> One of the reasons I'm disinclined to move is that none of the proposed
> alternatives seem especially, um, mature. AFAIK this project has never
> had CVS lose any data in the eight years we've used it. I'd want a
> comparable level of trust in any replacement SCM, and I haven't got it.
A very sane reason. I've lost my share of stuff with SVN in trialling
it, but we are switching our company over to Arch, which seems to offer
significantly more benefits. From our trialling of it, I think it has a
more robust and mature repository structure too.
Watching the PostgreSQL team developing I would think that Arch would
provide much better support for the developers than SVN would.
Switching to Arch is more work, but it also offers a lot more benefits -
including the opportunity for individuals to maintain their own trees,
and be able to work out which patchsets from someone else's tree have
not been applied. If anything is going to become the open-source
BitKeeper it will be this, I think.
Cheers,
Andrew.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Planning an election? Call us!
-------------------------------------------------------------------------
Thomas Hallgren
> Switching to Arch is more work, but it also offers a lot more benefits -
> including the opportunity for individuals to maintain their own trees,
> and be able to work out which patchsets from someone else's tree have
> not been applied. If anything is going to become the open-source
> BitKeeper it will be this, I think.
>
Lord (the guy behind Arch)
http://web.mit.edu/ghudson/thoughts/diagnosing
and a reply from Greg Hudson (SVN developer)
http://web.mit.edu/ghudson/thoughts/undiagnosing.
Regards,
Thomas Hallgren
Thomas Hallgren
> (I'm rather interested to know whether any other SCMs have a better
> solution to this problem, and if so what it is. It's not obvious how
> to do better.)
>
I've been working with a few SCM's and IMHO only one of them really
handles this really well. That's ClearCase. I'm well aware that
ClearCase is not an option but I though it could still be interesting to
know how this can be managed when done right.
In ClearCase everything (both files and directories) are "elements". A
directory is a version of an element and it contains versions of other
elements. It's not very different from Unix and I-nodes although
everything is of course versioned.
Subversion claims they handle moves pretty well. When I checked it out,
it turns out that a move is a copy (versions and all) followed by a
delete, thus maintaining version history at both locations. I'd
recommend anyone who think CVS is insufficient due to file moves to
investigate subversion.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Anand Kumria
> Andrew McMillan wrote:
>> Switching to Arch is more work, but it also offers a lot more benefits -
>> including the opportunity for individuals to maintain their own trees,
>> and be able to work out which patchsets from someone else's tree have
>> not been applied. If anything is going to become the open-source
>> BitKeeper it will be this, I think.
>>
> For those interested in SVN versus arch, I found the following from Tom
> Lord (the guy behind Arch)
>
> http://web.mit.edu/ghudson/thoughts/diagnosing
>
> and a reply from Greg Hudson (SVN developer)
>
> http://web.mit.edu/ghudson/thoughts/undiagnosing.
>
There is a fairly detailed comparison in the GNU Arch wiki as well.
<URL: http://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison>
Note: if you're a postgres committer you may have more luck seeking out
your nearest SCM advocate -- almost all of them would regard Postgres
migrating to their preferred SCM as a 'win' -- let them work for you by
walking you through things.
Cheers,
Anand
Thomas Hallgren
> ... There aren't
> any alternatives that are enough better than CVS to be worth the
> changeover effort.
>
I've done some research over the last couple of days for a fairly big
project where we face the challenges of breaking up a monolith into
modules and consequently will be forced to move a lot of files. I now
second Tom's opinion. Here's why:
Subversion doesn't move files. They copy and delete. So if you have
parallel work on a file that is "moved", you are headed for problems.
See threads:
"Question about rename" on us...@subversion.tigris.org
news://news.gmane.org:119/cmsqci$s9q$1...@sea.gmane.org
and
"Misinforming the user on rename with local changes"
d...@subversion.tigris.org
news://news.gmane.org:119/419379F3...@ftml.net
What I find especially intriguing is that although Subversion have
version controlled directories, they still identify the content of the
files using the location in the repository rather than using a globally
unique identifier. Didn't they anticipate files being moved around and
perhaps linked?
This thread started due to CVS problems with moving files and Subversion
will perhaps get there eventually but IMHO they are certainly not there yet.
GNU-Arch seems promising in some respects. It really can rename files
and track them using an id, but it doesn't run on Windows without Cygwin
(and even then not too well it seems). Personally I dislike the fact
that the author seems somewhat religious about free software and hostile
towards Windows instead of focusing on delivering a portable solution.
In my case, the fact that GNU-Arch is not portable is reason enough to
discard it as a viable alternative and I think it would be unfortunate
if PostgreSQL locked Windows users out from repository access.
The other Open Source alternatives are, IMHO not mature enough to be
considered for serious projects yet.
I wish ClearCase was fast, free, and suitable for distributed
development :-) Unfortunately it's slow, expensive, and extremely
network intensive. My approach will be to wait and perhaps contribute to
Subversion if I get some time left. They really need a great database
backend.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Andrew Dunstan
Thomas Hallgren wrote:
>
> GNU-Arch seems promising in some respects. It really can rename files
> and track them using an id, but it doesn't run on Windows without
> Cygwin (and even then not too well it seems). Personally I dislike the
> fact that the author seems somewhat religious about free software and
> hostile towards Windows instead of focusing on delivering a portable
> solution. In my case, the fact that GNU-Arch is not portable is reason
> enough to discard it as a viable alternative and I think it would be
> unfortunate if PostgreSQL locked Windows users out from repository
> access.
>
>
s/unfortunate/totally unacceptable/
cheers
andrew
Travis P
On Nov 13, 2004, at 6:20 PM, Thomas Hallgren wrote:
> "Question about rename" on us...@subversion.tigris.org
> news://news.gmane.org:119/cmsqci$s9q$1...@sea.gmane.org
Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do
something useful with that URL have been unsuccessful and I can't find
the thread on the (usable) mailing list archive ( don't use the
tigris.org archive; use http://svn.haxx.se/ ).
> "Misinforming the user on rename with local changes"
> d...@subversion.tigris.org
> news://news.gmane.org:119/419379F3...@ftml.net
Might be easier to read with a browser here:
http://svn.haxx.se/dev/archive-2004-11/index.shtml
Yes, looks like it could be a potential problem/inconvenience if a file
is both moved and altered simultaneously.
I see the risk of problems as similar to those that if two people edit
the same section of the same file at the same time, complicated
conflicts could emerge. You could avoid this problem using
Lock-Modify-Unlock rather than Copy-Modify-Merge. Some people do.
Others (many CVS users) choose the productivity gains by using
Copy-Modify-Merge and then deal with the eventual problem when/if it
shows up.
It is too bad the Subversion design didn't anticipate this such that
it's not a problem at all, but in many environments, it may not be much
of an issue.
> This thread started due to CVS problems with moving files and
> Subversion will perhaps get there eventually but IMHO they are
> certainly not there yet.
It is worth noting that there is already huge improvement in this area.
There's a baby in that bathwater. :-) It's made my life much easier,
particularly for Java development where refactoring requires renames
and moves of files and directories more often than with some other
languages like C/C++.
I'm not really advocating a switch if you don't think it's worth it.
Just hoping to contribute constructively to the discussion where the
worth of the costs/benefits are measured by others.
Back to playing with the 8 beta for me, :-)
--Travis
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Kaz Kylheku
> > "Misinforming the user on rename with local changes"
> > d...@subversion.tigris.org
> > news://news.gmane.org:119/419379F3...@ftml.net
>
> Might be easier to read with a browser here:
> http://svn.haxx.se/dev/archive-2004-11/index.shtml
>
> Yes, looks like it could be a potential problem/inconvenience if a file
> is both moved and altered simultaneously.
You guys should check out the software that I developed called
Meta-CVS.
It creates a version control system that has directory structure
versioning, over top of the file versioning semantics provided by CVS.
Meta-CVS does not have problems with these corner cases, by design.
> I see the risk of problems as similar to those that if two people edit
> the same section of the same file at the same time, complicated
> conflicts could emerge.
In Meta-CVS, conflicts in the directory structure are exactly like
these conflicts, because the directory structure is marked up as a
straightforward text document.
When conflicts occur, you can read that document and it's obvious that
one user wanted to rename foo.c to src/foo.c, whereas another one
wanted to rename it to foobar.c.
Meta-CVS completely separates the directory structure from the files,
in the classic way: just like Unix file systems, and network file
systems like NFS and others. A file is known by an 128 bit identifier
encoded as text in hexadecimal.
So for example, even picking up a deletion to a locally modified file
is safe.
Suppose you have been editing a document foo.txt, do a ``mcvs up'' and
it's deleted. Your changes are still safe and can be committed. All
that happened was that your foo.txt was unlinked from the directory
structure. The real object, still exists, and has all your changes. It
can be committed to CVS. Independently of that action, you can
re-introduce your object into the directory structure: just change the
markup document (a file called MAP in the MCVS directory at the root
of your project) and then run ``mcvs up''. Meta-CVS will notice the
change, and link the file into the appropriate place, as requested by
the new markup. You can commit that markup change, and the file will
reappear in people's sandboxes when they pick it up.
> It is too bad the Subversion design didn't anticipate this such that
> it's not a problem at all, but in many environments, it may not be much
> of an issue.
Fortunately, I anticipated the problem before I laid down the first
line of code.
Thomas Hallgren
> Thomas (Hallgren): Unfortunately, my efforts to get Thunderbird to do
> something useful with that URL have been unsuccessful and I can't find
> the thread on the (usable) mailing list archive ( don't use the
> tigris.org archive; use http://svn.haxx.se/ ).
Thanks Travis. I'm not at all friend with Tigris mailing list archives
and I wasn't aware of haxx.se. Here are the relevant links:
http://svn.haxx.se/dev/archive-2004-11/0505.shtml
http://svn.haxx.se/users/archive-2004-11/0433.shtml
http://svn.haxx.se/users/archive-2004-11/0445.shtml
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------