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

Michael Niedermayer michaelni at gmx.at
Fri Feb 23 22:03:26 CET 2007


Hi

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:
> > Hi
> > 
> > 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
> > 
> > -- 
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > 
> > No snowflake in an avalanche ever feels responsible. -- Voltaire
> 
> > 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 and this is in general not noticed
immedeately 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

also theres no real advantage in repo hacking, all the usefull things
break the repo
* you cannot add a revision
* 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 ...)
* reverting a commit can be done with svn ci or svn cp theres no need
  to play with the repo at low level
* 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 ...

also turning a svn add+ci into a svn cp by hacking the repo causes a
heap of problems
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

PS: my vote of course is YES to the policy change

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070223/12657433/attachment.pgp>


More information about the MPlayer-dev-eng mailing list