[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 Sun, Aug 06, 2006 at 02:04:22PM +0200, Michael Niedermayer wrote:
> 
> 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:
> > > > 
> > > > 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 ...

Your notion of repo vs file seems a bit misguided/unclear here.  It's
cleaner with Subversion because tools to convert and modify the
repository are included.  svnadmin and svndumpfilter are very handy,
there is no need to manually edit RCS files.

If you wish to fiddle with the repository some more you have to work on
dump files of single revisions, like I did for fixing the renames, but
you always interact with single files.  The format of the dump files is
also more convenient for editing that RCS files.

No, I insist, Subversion is both cleaner and superior in this regard :)

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

Not necessary.  The resulting repository will have one revision less of
course.  Checkouts can be adversely affected depending on circumstances,
but this is no different than CVS.  Since Subversion creates diffs
locally porting changes is easier.

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

That's not a policy change IMO, Subversion preserves history so you
*can* rename files now without losing history and the rest of the
paragraph is unchanged.

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

Agreed.

I want to take Ben out of the line of fire here.  He is just the first
to trigger discussions about the proper workflow with Subversion.  In
the past we did not have problems with best practices for moving files
around, for obvious reasons.

Diego