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

[Michael Niedermayer]

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.

cvs goes over ssh ...


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


>
> At least the nfs fsfs storage model works pretty well. BDB-related troubles 
> have been gone for a long time.
>

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


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090404/b93cb5dd/attachment.pgp>