[Scummvm-devel] Subversion is here!
max at quendi.de
Fri Jan 20 00:52:04 CET 2006
Am 20.01.2006 um 00:56 schrieb Jonathan Gray:
> On Fri, Jan 13, 2006 at 09:38:30AM +0100, Max Horn wrote:
>> To get a bit deeper into it:
>> * you can *delete* files and directories. Yay, we would have needed
>> this a lot
>> * you can *rename* files! Yay, we would have needed that a lot
>> * you can *rename* directories, and they have a version, too.
>> * you can do almost everything you can do in CVS; those things you
>> can't do, you usually can't do for *very good reasons*
> So some things for users who don't have access to an admin become
> easier to manage.
Again, this is plain simply wrong. Moving files around inside the
repository (with admin access) is *NOT* in the least a replacement
for versioned file renemas/moves. To the contrary, it *breaks* old
versions. If you rename a file in the CVS repos structure (i.e. the
file system on the server), then you renamed it in every revision. In
particular, if now a user makes a check out of an older release
branch, that release branch is broken, because a file it needed is
missing (but instead a new file with a different name is present).
In subversion, the actual rename is versioned. In particular, you can
find out who did it, with which commit message, etc.; and you can
still use older branches/revisions.
>> Yeah. This makes a lot of things a lot faster. They figured (IMO
>> correctly) that for most people today, hard disk space is no issue,
>> but band width *is* an issue. Certainly true for me, I must say :-).
>> A clear argument *for* Subversion, I'd say :-)
> I don't think it makes all that much faster at all see above, in
> addition you have have extra commands like svn resolve or whatever
> it is to cope with the way it works.
You don't think so? OK, have you had first hand experiences? Because
I do work daily with both CVS archives and Subversion. And boy, does
it make a difference for me. Sure, it's only my "feeling"; I won't
try to give you any numbers. But seriously, what matter for me is my
user experience. I was skeptical, too, but I simply tried it. And for
me and my dev style, it simply works (e.g. I do diff's regularly,
before every single checkin, and I often do multiple of 'em in a row:
I see a problem in a diff; I fix it; I rediff; etc.).
Of course, maybe you are working differently, and it doesn't change
much for you.
>>> Keyword expansion seemingly has to be set on a per file basis,
>>> with no recursive options with no default keywords.
>> Wrong: <http://svnbook.red-bean.com/en/1.0/ch07s02.html#svn-ch-7-
> This claims it is possible but does not actually give an example,
> once again the documentation is lacking. This behaviour should
> happen by default like with cvs anyway so it is all rather silly.
Your oppinion is that it should be on by default and not putting it
off is silly. Other peoples is that it should be off by default and
that putting it on is silly. Who's right? ... Well, the SVN team
explains their reasons...
Anyway, it's trivial to do. I am sure you are glad to hear that :-)
> Yes because the internet is so accessible on 20 hour flights
> or coding in a park. That and I find the documentation style bad,
> I want a reference manual think K&R C book versus learn C in
> 24 hours!!!
No problem! It's normal that some people don't like a given book
style. Luckily, lots of people wrote books (including reference
manuals, and "Subversion for beginners" style). Just take a browse at
Amazon and make your pick :-)
>>> Many of the people responsible for the security problems in the GNU
>>> implementation of CVS seem to have moved to working on subversion...
>> Err... some of the people who made CVS happen in the first place
>> moved to Subversion, aye. So what? The design of Subversion is
>> *excellent*, while CVS never was designed but grew out of a set of
>> hacks atop RCS. It's silly to blame them for security problems (which
>> certainly exist) in a product which is currently used way beyond it's
>> original purpose.
>> And anyway, the fundamental security problems are one of the various
>> reasons why they wrote Subversion -- to make it right this time :-).
First off, to clarify what I wrote here: I don't claim that
subversion is bug free, or has no security problems. But it was
designed from the ground up, with various goals in mind, including
security. E.g. for CVS, ssh access was added as yet another hack &
afterthought. Certain aspects of the protocol make it impossible to
prevent a couple security scenarios.
> I have to call you out on this, you'll notice that most of the
> CVS problems where with pserver, which is why many projects started
> offering anonymous cvs access via ssh some time ago.
> I'm not convinced.
[... list of security problems in 1.0.2 and 1.0.4 ...]
Phew, I am glad we are using Subversion 1.2 then. And I am also glad
that you kindly left out the list of security problems in CVS,
because my email program tends to choke on mails that are bigger than
a couple MB ;-)
Seriously, though: Yes, you are fully right, there have been security
problems with Subversion in the past. And possibly there'll be new
ones in the future, it's near impossible to 100% avoid this. A sad
thing. But so far, all have been fixed very quickly. The power of
open source, don't we all love it :-)
>> I realize that you are dead set against Subversion at this point (and
>> I expected at least one, more likely 2-3 people to react like that),
>> but *please* let's keep out the silly GNU vs. BSD discussion line.
>> What you call "GNU CVS" is simply "CVS" :-)
> No there are multiple CVS implmentations hence it is GNU CVS.
There is CVS, and now there is OpenCVS. Hence it's CVS, and OpenCVS,
not GNU CVS, and OpenBSD CVS... Or am I missing any?
>> Currently tons of people are working on CVS replacements, and I
>> really hope we will see CVS be phased out for good in the next couple
>> years, in favor of any of Subversion, Monotone, Arch, darcs, etc..
>> Don't get me wrong, using CVS beats not using any version control by
>> far, but Subversion beats it by equally much in my eyes :-)
> With subversion you gain some easier admin functions, atomic
Not quite: As I pointed out, what you call "easier admin functions"
should be "renamed/move features that are fully impossible with CVS".
> and lose documentation and the ability of people
> familiar with cvs to easily use it.
Subversion was written with easy transition for CVS users in mind.
There are various manuals, HOWTOs, guides etc. out there, even a book
at amazon, that specifically is meant for CVS users switching to
I am fully convinced that any serious developer will be able to adopt
to Subversion in a matter of days; shorter, if they really sit down
to read one of those guides, instead of picking it up "on the go".
For our users, who are doing anon checkouts / updates, the only thing
that will change is that instead of "cvs up" they have to change "svn
> It remains to be seen how
> much the RCS design hinders people who try to go beyond what
> GNU CVS attempted but there are some interesting ideas being
> talked of.
You are talking about OpenCVS, right? Well, I am 100% convinced you
can do a lot of what Subversion does atop RCS. But you won't be
compatible to CVS (or, in your terminology, GNU CVS), so what does it
matter, since that is what 99.9% of the people out there use? The
subversion folks, BTW, nicely explain why they chose not to extend
CVS (which they initially wanted to do). Alas, I wish the OpenCVS
folks all the best anyway :-).
> So to sum up what we already knew, I would rather things
> stayed as CVS.
That was clear from your first email :-).
> I am likely outvoted and will have
> to cope with dealing with yet another subversion repository
> for a year or few months until everyone decides to jump
> onto the next version control flavour of the week.
So, let's take a step back. So far, you simply try to nullify my
arguments pro SVN. Personally, I see several strong features of
Subversion that are very useful to have, and that you either ignore
or apparently do not (yet) fully understand (like move/rename
support). But were are the arguments for staying with CVS? OK, if
there was little to be gained to CVS, then the biggest argument for
it would be the transition pain, agreed. In my eyes, move/rename
support alone would outweigh that, but IMO several other strong
reason support it. Oh yeah, you think that "keywords off by default"
is a counter argument. Personally, I think it's a matter of taste (in
particular, I can't argue it).
You claim better documentation for CVS. Fully agreed, after all it's
been around for much much longer. But the Subversion doc isn't bad
either (provided you are willing to look for it, e.g. via Google or
Amazon; of course if you want to prove something is bad, one tends to
forget these sites... :-).
Overall, I have the feeling that you simply do not like Subversion,
and that you are a fan of OpenCVS. Of course, it's not that much
different for me: I miss a lot of features in CVS that are available
in "real" versioning systems that I have used at work. Personally, I
don't insist on subversion (e.g. monotone looks nice, as do several
otthers). But realistically, that's what we have; and in the Open
Source scene, it seems to be by far second most used after CVS, with
rapidly growing support. And once SF.net rolls it out for all
projects, the number will explode, I am pretty sure about that. So I
don't think that Subversion will be gone again in 1-2 years, like you
predict. Of course it's possible that I am wrong. But then none of
the alternatives out there are nearly as mature or widely used either...
And no, OpenCVS, or any other CVS implementation, are no alternative
in my eyes. It can't fix the inherent lack of design of CVS (which,
to be fair, grew out of a hack on RCS, not out of a design :-).
More information about the Scummvm-devel