[Scummvm-devel] Subversion is here!

Jonathan Gray jsg at goblin.cx
Thu Jan 19 15:57:01 CET 2006


On Fri, Jan 13, 2006 at 09:38:30AM +0100, Max Horn wrote:
> 
> Am 13.01.2006 um 03:09 schrieb Jonathan Gray:
> 
> >On Fri, Jan 13, 2006 at 12:28:51AM +1100, ?ystein Eftevaag wrote:
> >>Internally, subversion is CVS "done right" and is far more extensible
> >>and flexible than CVS.
> >>
> >>Practical reasons though:
> >>* Subversion is a lot faster
> >
> >Where is this compared?  Also know that GNU CVS has lots of things
> >in it that limit speed that are not problems with CVS as such but
> >the specific implementation.
> 
> Subversion is faster because e.g. a lot of things happen locally, and  
> not file-by-file (as CVS does it) but for whole dirs at once.. Think  
> about "cvs diff", for example.

The thing that matters is update. In the subversion way you have to
do an update before you can get a proper up to date diff.

I don't think you gain much if anything here.

> 
> 
> >>* Subversion actually makes deleting files, directories, and moving
> >>stuff around, trivial.
> >>Compared to CVS where it's... not.
> 
> 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.

> * branching / tagging is as simple as a copy/move operation. Yay, no  
> need for me to re-explain every time how the cryptic branch feature  
> of CVS works.

I fail to see how branch is cryptic.

> * diffing branches / tags becomes trivial. Yay, no need to specify  
> complicated tag/branch statments to CVS where you have to lookup the  
> details everytime. No you just specifiy directories
> * svn merge helps a lot in merging changes between branches
> * yay, file properties are versioned, too. No "executable bit set, go  
> modify the repository manually to change it" mess anymore!
> * yay, atomic commits. No more partially check in because of Ctrl-C  
> during a lengthy commit!
> * yay, binary diff's, too! Binary files are first class citizens!

Binary diffs would only be useful if you had large files under
version control to help updates.  Its not like you can look at a
binary diff and tell what it is doing at all.
And if this is the case you need to double the size of the large
file becuase of how subversion works.

> 
> 
> >>
> >>The structure of Subversion is also purely directory based, and does
> >>away with
> >>the branches and modules of CVS. This makes some things more  
> >>difficult,
> >>but a lot more intuitive and easy to manage.
> >
> >The size of the source tree is doubled because it keeps copies.
> 
> 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.

> 
> 
> >diff does not seem to take arguments.
> 
> Wrong, ise "svn --help diff" to see that you need -x / --extension to  
> pass arbitrary options to diff; in fact you can use --diff-cmd to use  
> *any* diff command of your choice! The old "pass any argument I don't  
> know to diff" hack was really a bad thing, I am glad they fixed this  
> misfeature.
> 
> 
> >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.

> 
> 
> >man page might as well not exist it is so useless.
> 
> It doesn't contain much information, true, but... did you *read*  
> it? :-) It points to
> * svn help
> * in particular: "svn help diff" would have answered your other question
> * <http://svnbook.red-bean.com/>
> * <http://subversion.tigris.org/>
> 
> The latter has e.g. a FAQ <http://subversion.tigris.org/faq.html>  
> which would have clarified your statement about keywords, BTW:  
> <http://subversion.tigris.org/faq.html#auto-props>

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!!!

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

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.

http://marc.theaimsgroup.com/?l=bugtraq&m=111021890218456&w=2

3. Problem description:

Subversion versions up to 1.0.2 are vulnerable to a date parsing
vulnerability which can be abused to allow remote code execution on
Subversion servers and therefore could lead to a repository compromise.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0397 to this issue.

Subversion versions up to and including 1.0.4 have a potential Denial of
Service and Heap Overflow issue related to the parsing of strings in the
'svn://' family of access protocols. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-0413 to
this issue.

http://marc.theaimsgroup.com/?l=bugtraq&m=108780380414941&w=2

1)  problem description, brief discussion, solution, upgrade information

    Subversion is a version control system like the well known CVS.
    The subversion code is vulnerable to a remotely exploitable buffer
    overflow on the heap. The bug appears before any authentication took
    place. An attacker is able to execute arbitray code by abusing this
    vulnerability.

    There is no temporary workaround known.

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

> 
> 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 and lose documentation and the ability of people
familiar with cvs to easily use it.  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.

So to sum up what we already knew, I would rather things
stayed as CVS.  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.




More information about the Scummvm-devel mailing list