[MPlayer-cvslog] r19341 - in trunk/stream: Makefile asf_mmst_streaming.c asf_streaming.c network.c network.h pnm.c stream_ftp.c stream_netstream.c stream_rtsp.c stream_vstream.c tcp.c tcp.h

[Diego Biurrun]

On Sat, Aug 05, 2006 at 03:29:51PM +0200, Michael Niedermayer wrote:
> 
> On Sat, Aug 05, 2006 at 02:51:52PM +0200, Reimar D?ffinger wrote:
> > Hello,
> > On Sat, Aug 05, 2006 at 01:44:53PM +0200, Benjamin Zores wrote:
> > > hum, i also did some changes using #defines for error codes instead of -1/2/3.
> > 
> > Great, and how is anyone supposed to review like that?
> > I'd be really thankful if more people didn't behave if this was their
> > very code with nobody else using, caring or maintaining it.
> > Does anyone actually still care about stuff written in patches.txt or
> 
> seems many do not ...
> this is a very seriuos problem, if code cannot be reviewed then the code
> will become more and more buggy and or developers will turn away as its
> too much work to review messy changes
> i dont even want to think what happens if someone would commit malicious 
> code hidden in a unreviewable change
> 
> with cvs we could reverse changes, and try again,

I have said so before, I will say it again now: CVS has never and will
most likely never support reversing changes.  Now everybody repeat this
after me please.

'cvs admin -o' functions in a way that resembles reversing commits in
corner cases, but nothing more.  It's a dangerous tool that can easily
wipe out the wrong parts or all of a file's history.

Remember all the trouble that it caused, especially since there is
absolutely no notification of its use.  In my function as CVS admin I
forbid its usage for good reason.

> now if trojanized
> code got commited then reversal would remove it and a following clean
> change could be reviewd ... with svn it currently looks like we will
> flame and then go crying in a corner while leaving the change in svn
> this is not good at all and IMO overshadows any security advantage
> svn has over cvs ...
> 
> for ffmpeg iam starting to consider to ask the admins to disable
> svn accounts on the first such violation without warning, well i certainly
> dont like that but if we cant find a reasonable simple way to reverse 
> such change then such a meassure would at least reduce the number
> of such changes and thus make it more realistic to review them manually

IMO this is a policy problem, not a tool problem.  Yes, all developers
should adhere to the policy described in patches.txt and svn-howto.txt.
Some parts of it may need to get clarified or made more explicit,
though.  For example, svn copy is new, there are no clear guidelines on
when and how to use it.  We will just have to make those up now.

Diego