[FFmpeg-devel] [RFC] libswscale into the FFmpeg SVN repo

[Christian Iversen]

Michael Niedermayer wrote:
> On Sat, Apr 04, 2009 at 05:41:13PM +0200, Christian Iversen wrote:
>> Michael Niedermayer wrote:
>>> i think the way CVS did versioning was more flexible and powerfull, and
>>> no iam not saying the cvs implementation was good, with its non atomic
>>> changes, lack of move&copy tracking per directory commit mails ...
>>> Fixing the CVS implementation and storing the file path in the RCS files
>>> instead of storing the RCS files in the path would have made cvs more
>>> powerfull than svn is today. (that is instead of a tree with the rcs files
>>> as leafs, there could be a flat list of rcs files where each stores where
>>> in the tree it is under which name for each revission or if that revission
>>> existed rather outside of the tree in a difeferent repo)
>>> And with a RCS file upload/download (aka push/pull) cvs could have been
>>> used offline and distributed ...
>>> i never understood why people droped cvs and started to work on svn that
>>> is in several ways inferrior (less secure, no moving between repos, 
>>> database
>>> shit, ...)
>> I'm interested, how is it less secure?
> 
> IIRC it is vulnerable to simple off line password bruteforcing if one
> can listen to any svn traffic, and it is vulnerable to man in the
> middle attacks.

Well, I can't say for sure, but certainly, the only susceptible 
candidate would be the "svn" protocol.

Now, by far the 2 most widely used protocols are svn+ssh:// and https://

> cvs goes over ssh ...

If you use the ":ext:" protocol, yes. If you use ":pserver:", it 
actually goes in plaintext.

>> I've never used CVS a lot - what 
>> kind of support did it have for moving stuff between reposes?
> 
> you just copy the rcs files on the server, needs an account or someone
> with an account ...
> what was missing was that this didnt keep track of where the file previously
> was ...

Oh, like that. Yes, that was pretty neat. It's still perfectly possible 
with SVN though.

>> Besides, having one central RCS file work as a lookup-table is not terribly 
>> different from the current SVN approach.
> 
> what i suggested was 1 RCS file per file like CVS, just that the file path is
> stored in the rcs file not the rcs file stored in the path
> you can think of it as having the first line of each .c & .h file be the path
> and that first line just not being part of the vissible checked out file.

Ok, that makes sense. It could even work, but it would of course require 
  some kind of cache databases to be any kind of fast. These would be 
easy to rebuild it you merge in new files, but there's still some code 
to do.

Now, what it _doesn't_ buy you, is O(1) copy operations. Those are nice.

>> Also, if I understand you 
>> correctly, your approach wouldn't make it that much easier to merge two 
>> repositories. Specialized tools would still be required, no?
> 
> you need as much spezialized tools as for commiting the next revission.
> my idea would be a reimplementation of cvs that just keeps the underlaying
> RCS files and SSH based access, thus there would be "cvs cp repo0/x repo1/y"

Actually, I find the https:// access method much nicer than unix logins. 
I don't trust all my svn users to have ssh access, and if they don't 
have a shell, they're going to have a hard time using RC files. Having a 
server-like program run the user by an ACL works out really nicely in a 
diffentiated-access scenario. It is, for example, trivial to confine a 
user to a certain branch, or to make certain branches anynomous-readonly 
while making the rest of the tree authentication-required.

-- 
Med venlig hilsen
Christian Iversen