[MPlayer-dev-eng] svn policy change [RFC][PATCH]

[Attila Kinali]

On Sun, 6 Aug 2006 22:03:31 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> ===================================================================
> --- svn-howto.txt	(revision 19349)
> +++ svn-howto.txt	(working copy)
> @@ -127,14 +127,21 @@
>    include filenames in log messages, Subversion provides that information.
>  
>  
> -8. Renaming/moving files or contents of files:
> +8. Renaming/moving/copying files or contents of files:
>  
> -  svn move <source> <destination>
> +  svn move <source> <destination>    / svn copy <source> <destination>
>    svn commit <source> <destination>
>  
> -  Do not move or rename files before discussing it on the mplayer-dev-eng
> -  mailing list first!
> +  Do not move or rename files maintained by others then yourself without
> +  discussing it on the mplayer-dev-eng mailing list first!
>  
> +  Always try to preserve the history and minimize the size of svn diff, dont
> +  copy or move a file by svn delete and svn add, always use svn move or 
> +  svn copy instead
> +
> +  To split a file in 2 use svn copy and remove the lines which are not needed
> +  in both files
> +

This sounds ok to me.

>    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.
> @@ -145,11 +152,10 @@
>  
>  9. Reverting broken commits
>  
> -  There is no Subversion equivalent of the 'cvs admin -o' command. Instead,
> -  be very careful about what you commit! If somehow you broke something,
> -  revert the changes locally and re-commit with a proper commit message.
> -  You may want to use 'svn cat -r<revision> <filename>' to inspect an older
> -  revision.
> +  You can revert a change by using svn copy from an old revision or by 
> +  reversing the change locally and re-commiting with a proper commit message.
> +  if the change was total nonsense like a policy violation or someone
> +  commiting the wrong file then svn copy is the correct way to reverse

I'd rather prefere the svn way of reverting changes.
Then every meta data we have stored in the repo will be as
it should be:

http://svnbook.red-bean.com/en/1.2/svn-book.html#svn.branchmerge.commonuses.undo
  


			Attila Kinali
-- 
心をこめて聞け心をこめて話せ