[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

[Uoti Urpala]

On Sat, 2006-08-05 at 17:19 +0200, Michael Niedermayer wrote:
> > works, this should NOT be the default way to revert a commit: unless
> > there is something exceptional, commits should be reverted with a normal
> > commit changing the code back.
> 
> why? it seems like its perfect default way to reverse the last commit

It has at least the following disadvantages (there might be more, I
haven't though about it that much):
- It conflicts with any local changes. The file is deleted and then a
new one is created. What would happen on the local copy is probably that
svn would not delete the local file when merging the delete because the
file contains changes, and would then fail to create the new file
because a local file with that name already exists. Not sure if it makes
any difference if both the delete and creation are merged in the same
commit.
- It makes the repository structure more complicated as files are
getting copied, deleted and replaced. This increases the chances of
problems when doing repository operations later, and might affect
performance (I haven't looked at the data structures svn uses).
- Apparently you need to commit the deletion before you can commit the
copy, so it's necessary to create a temporarily broken state in the
repository where a file is missing.

In comparison the only advantage of this method seems to be that "svn
annotate" for revisions after the reverted commit might show more
relevant revisions for some lines if the reverted change really was
completely wrong/irrelevant.