[Ffmpeg-devel] Re: [MPlayer-dev-eng] mphq2 - admins wanted

[Joshua Varner]

Hi

Since you are going to have to build all of this from scratch anyway,
you might look at setting up subversion. I think it can address some
of the issues of concern. Specifics below

On 9/5/05, Rich Felker <dalias at aerifal.cx> wrote:
> On Mon, Sep 05, 2005 at 07:25:31PM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2005 at 12:46:31PM -0400, Rich Felker wrote:
> > > On Mon, Sep 05, 2005 at 12:20:39PM +0200, Michael Niedermayer wrote:
> > > > On Mon, Sep 05, 2005 at 05:19:02AM -0400, Rich Felker wrote:
> > > > > On Mon, Sep 05, 2005 at 09:23:16AM +0200, Attila Kinali wrote:
[snip]
> 
> The lockfiles issue needs to be dealt with in a sane way. Can we fix
> cvs to get around this brain damage? IMO no lock files should be used
> for reading. In some cases this should be trivial to support; in
> others, the entire file should be copied before read operations, and
> if the source file changed during the copy operation, it should be
> copied again, etc. etc. etc. until it stops changing. :) For CVS write
> locks we could have a monitor program that removes the lock file is
> the process that created it no longer exists.
> 
> > how will cvslog messages be generated if theres nothing except cvs on
> > the server?
> 
Subversion hook scripts are launched in an empty environment, so
they could even run as separate user, since generating these messages
does not require write access to the repository.

> OK, maybe we need another binary; alternatively it could be generated
> by the external repository monitor..
> 
> > what about secholes in cvs itself, there where some in the past IIRC
> 
> AFAIK it was just in pserver, but I may be mistaken.
> 
> > they could be exploited to change the repository without generating any
> > cvslog messages

No program is without holes, but in the past 4 or 5 months on both the 
user and dev lists for subversion, the only security issue like this I've
heard is that users without write privileges in the repository could leave
empty revisions when authorization failed, but this wouldn't cause any
data loss. The only way to actually remove data from the svn repo is to 
dump it and filter the dump file, which can only be run from the command
line on the server. There are a number of tools for creating incremental
backups, so that you can send those to a separate secure place, to avoid
any corruption, accidental or intentional.

> 
> It would be nice to have a separate monitoring process that watches
> all changes to cvs tree and reports any inconsistencies with cvslog
> messages to the cvslog list.
> 
> > and cvs -o doesnt generate cvslog messages (sadly ...)
> 
> Let's just forbid it.. :)
> 

This is possible from hook scripts.

> > and last CVSROOT must be executeable and writeable for normal cvs
> 
> WTF? CVS sounds more and more broken by the minute..
> 

The entire history from CVS can be preserved with cvs2svn, and the only
major difference is somewhat bulkier command line syntax when dealing
with URLs, but this can be bypassed with shell variables, and is mainly
an issue only on initial checkout and when branching and merging. The rest
of the time the working copy has the URL cached.

I won't claim to be a subversion expert, but I am a partial commiter on that
project and share responsibility for the version control where I work, and
I can offer to help in this regard.

Josh