[MPlayer-dev-eng] [PATCH] repo hacking policy

[Diego Biurrun]

On Fri, Feb 23, 2007 at 10:03:26PM +0100, Michael Niedermayer wrote:
> 
> On Fri, Feb 23, 2007 at 08:25:55PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Friday, 23 February 2007 at 17:51, Michael Niedermayer wrote:
> > > 
> > > the attached patch adds a rule to the policy which forbids repo hacking
> > > except when removing illegal (=is illegal for us not to remove ...) content
> > > 
> > > i will apply this in a week or so if we have 2:1 majority that is
> > > YES > 2*NO
> > > 
> > > Index: svn-howto.txt
> > > ===================================================================
> > > --- svn-howto.txt	(revision 22325)
> > > +++ svn-howto.txt	(working copy)
> > > @@ -308,6 +308,7 @@
> > >      mplayer-dev-eng mailing list, so that all developers can benefit from them.
> > >      IRC is good for quick discussions, but nobody is there 24/7.
> > >  
> > > +14. Hacking the SVN repository is forbidden except when removing illegal content
> > 
> > Please elaborate on the downsides of repo hacking.
> 
> well it is very easy to break the repo

false

What makes you assume this should be the case?  Did you ever do it?

> and this is in general not noticed immedeately

This is - at the very least - overly generalized.  When would this be
the case?

> also repo hacking did break the repo in the past so its not
> unreasonable to assume that it will break again next time its done

This is a logical fallacy.

I'm sure if I dig a bit I can come up with some vulnerability that you
added to FFmpeg.  Is it therefore not unreasonable to assume that you
will add a vulnerability the next time you commit?

> also theres no real advantage in repo hacking, all the usefull things
> break the repo
> * you cannot add a revision

You can do this of course, it's even trivial and the repository does not
break in the least.  It's the checkouts from this repository that have
trouble coping with it.

> * you cannot remove a revision (it breaks checked out files
>   with that revision at least and possibly causes more serious issues,
>   in cvs revision removial is completely safe except the checkout
>   breakage, in svn iam not so sure ...)

If by "removing a revision" you mean shortening the history like 'cvs
admin -o' does, then you are wrong, this can be done.

> * reverting a commit can be done with svn ci or svn cp theres no need
>   to play with the repo at low level

We have flamed about 'svn cp' (ab)use to revert commits before, I won't
get into it again.

> * changing a svn add+ci to a svn cp does NOT need any repo hacking you
>   just remove the file and then svn cp from the correct past revision
>   and then recommit all the later changes which should be few ...

Now if this is not a hack...  And what if they are not few?

> also turning a svn add+ci into a svn cp by hacking the repo causes a
> heap of problems

No, it's actually the most trivial operation of them all.  Just add

  Node-copyfrom-rev:  12345
  Node-copyfrom-path:  /trunk/foo/bar.c

to the file header in a revision dump file and suddenly your file will
have bar.c, revision 12345 as predecessor.

> first it makes the svn log list missmatch svn (we used cvslog to recover
> a few files after mphq hd died i wont even try this again with current svn
> knowing how consistent all the things are currently ...)
> 
> second it doesnt show the change in svn log which pretty much makes
> the whole thing idiotic and useless (we want to change to svn cp to
> make it more revwiewable)
> 
> now of course you can fabricate the svn log mail which shows the change
> and thus fixes point 2 but svn log will now be completely inconsistent
> as there will be 2 _different_ commits with the same revision number
> on svnlog, this causes confusion both to humans and scripts trying to
> rebuild some file from svn log

Oh come on, please, this is completely non-sequitur ..

1: mplayer-cvslog is not a backup.
That we were forced to do this in the past proves nothing except that
the project server was run by a Bastard Operator From Hungary.  We have
daily offsite backups in different countries now.  There will never be
the need to parse mails to extract diffs again, at least not in order to
rebuild the repository.

2: Getting a new log mail is trivial.
But you said this yourself even ..

3: There is no way to confuse log messages for humans.
One of them will of course have a long flame thread attached to it.  And
they will have different dates.  Given that we don't have time machines,
how much confusion can arise about which one is in the repo?

4: There is no way to confuse log messages for scripts.
Quite simply because scripts will be fed the messages by humans.  When
we recovered the CVS repository the script was fed a prepared mbox as
well.  Not that this would be necessar now, we have proper backups.

5: The Subversion repository has always been consistent - unlike CVS.
There were some ugly 'cvs admin -o' revert wars back in the days that
never made it into Subversion because they quite simply disappeared from
the CVS repository without log message, notification or anything.


Voting seems to be popular these days.  If we need to have them, can
they at least be based on facts, not assumptions?

IMO a vote should be a last resort, not the beginning of a discussion.
I consider them a bad idea in 90% of the cases.  If consensus cannot be
reached there is likely some other problem.

Diego