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

Mon Feb 26 02:28:10 CET 2007

Hi

On Mon, Feb 26, 2007 at 01:13:14AM +0100, Diego Biurrun wrote:
> 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?  

well it was broken a few times IIRC ...

> Did you ever do it?

no

> 
> > and this is in general not noticed immedeately
> 
> This is - at the very least - overly generalized.  When would this be
> the case?

well, look at svn, its state does not match svnlog IMO this is broken
you dont seem to be aware of that or dont care so i would say its not
noticed ...
also i guess it could have broken local git "mirrors" of svn have you
even considered this? what about other version control systems users
and developers might use locally?

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

that would be unreasonable, what is reasonable is to assume that if i
added 1 vulnerabilities in X month in the past by being a human who
is not perfect then its likely that i will also in the future add 1
every X month on average, now how otften did you hack the repo
and how often did something break?

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

no its not just the checkouts, its everything which references svn by the
revission number that are mails in archives, webpages, other projects
security advisories and so on, IMO breaking security advisories is enough
to call it breaking

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

and is there a missing revission number afterwards or are all later revisions
decreased by one? in the later case all the issues with adding a revision
apply

[...]
> > * 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?

if they are many like a year then id say "get over it and let it be"

[...]
> > 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.

well there might be people who like to keep the whole svn localy in a
other version control system, simply using svnlog for that is a reasonable
choice, fetching the changes via svn di and svn log surely is possible too
either way it will break fatally with any internal low level svn edits

and if its not announced in public that could even lead to lost work
for the developer using such a non svn system locally

[...]
> 
> 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?

you assume that the human has figured out that there are 2 more likely
is that he just searches once and never sees the more recent change
with proper revert the more recent has its own uniqur revission number

[...]

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

notification about svn repo hacks is also incomplete i think

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

well everyone can change their vote if people beleive the facts arent
correct
also we can vote again anytime if anyone wants ...

> 
> IMO a vote should be a last resort, not the beginning of a discussion.

yes it was disscussed enough already, and you again proposed to hack the
repo, thats why the vote was started

> I consider them a bad idea in 90% of the cases.  If consensus cannot be
> reached there is likely some other problem.

well at least to me it appears that we have consensus with you as
exception

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/20070226/9ce57a8e/attachment.pgp>