[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

[Michael Niedermayer]

Hi

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

maybe its possible to "reverse" changes by using branches?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is