[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 Sun, Aug 06, 2006 at 11:47:24AM +0200, Diego Biurrun wrote:
> On Sat, Aug 05, 2006 at 05:07:59PM +0200, Michael Niedermayer wrote:
> > 
> > On Sat, Aug 05, 2006 at 03:51:45PM +0200, Diego Biurrun wrote:
> > > 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 does support reversing the n last changes, furthermore you can rebuild
> > the RCS files to remove any change in the middle, it of course requires
> > an account on the server and we never did this to remove an old change
> > but its possible, svn supports that too it just requires everything to
> > be done to the whole repository instead of a single individual file so its
> > a much bigger mess
> 
> It sure is *possible*, but Subversion has a clean way of offering this
> functionality by dumping and reloading the repository.

rebuilding whole repo vs. rebuilding one RCS file, seems we agree, just
that you consider the first to be cleaner and i consider the second to be
cleaner, so our dissagreement is just about what is cleaner ...


> 
> Suppose you wish to remove r12345, just do
> 
>   svnadmin dump --incremental -r 0:12344 REPO > dump_file1
>   svnadmin dump --incremental -r 12346:HEAD REPO > dump_file2
>   svnadmin create new_repo
>   svnadmin load new_repo < dump_file1
>   svnadmin load new_repo < dump_file2
> 
> And this works just as easily if the commit spans 5 directories and 20
> files.

a minor nitpick ... i think (though i might be wrong, iam no svn expert)
that you will have to add a dummy 12344->12345 change in the above thing

furthermore you might have to do a little manual work if any later changes
conflict, both are needed for cvs too of course


[...]

> 
> > > It's a dangerous tool that can easily
> > > wipe out the wrong parts or all of a file's history.
> > 
> > fully agree, the solution IMHO would be backups + restrict cvs admin to 
> > root at mphq
> 
> Unfortunately CVS did not allow this out of the box.  Subversion is a
> clear improvement in this regard.

agree


[...]
> > > 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.
> > 
> > policy said not to copy or move files by remove and add but to ask arpi/root
> > to do it IIRC
> > surely it should mention svn cp/mv now but its not like it wasnt clear about
> > what wasnt allowed
> 
> I think your memory needs a quick freshup:
> 
>   8. Renaming/moving files or contents of files:
> 
>     svn move <source> <destination>
>     svn commit <source> <destination>
> 
>     Do not move or rename files before discussing it on the
>     mplayer-dev-eng mailing list first!
> 
>     Don't do a lot of cut'n'paste from one file to another without a
>     very good reason and discuss it on the mplayer-dev-eng mailing
>     list first. It will make those changes hard to trace.
> 
>     Such actions are useless and treated as cosmetics in 99% of cases,
>     so try to avoid them.
> 
> So maybe this could have been discussed a bit more, but it surely was
> not forbidden.  

r18708 said:
------
8. Renaming/moving files or content of files, removing empty directories:

  You CANNOT do that. Ask the CVS server admin to do it!
  Do NOT remove & readd a file - it will kill the changelog!!!!
...
------
that IMO means: no you cannot move the content of a file

did i miss the disscussion of the policy change?


> IIRC Ben informed people of his plans on dev-eng, I'm
> not terribly sure about this, though.  However you know that our devs
> are lazy to react to such mails, but quick to flame after the fact :(

i see no problem here, the alternative would be to ignore issues on
commits when a patch had been posted to dev-eng and was missed/not reviewed
by anyone
it might be less nice to complain late, but its better then to ignore
an issue because everyone was lazy and didnt read the mail on dev-eng

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