[Scummvm-devel] Subversion is here!

[Max Horn]

Am 20.01.2006 um 00:56 schrieb Jonathan Gray:

> On Fri, Jan 13, 2006 at 09:38:30AM +0100, Max Horn wrote:

Jonathan


[...]

>>
>> 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-
>> sect-2.4>
>
> 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
> commits


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  
Subversion.

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  
up".



>   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 :-).



Cheers,
Max