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

[Diego Biurrun]

Hmm, I wrote a reply to this yesterday, somehow it got lost..

On Mon, Feb 26, 2007 at 02:28:10AM +0100, Michael Niedermayer wrote:
> 
> 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:
> > > > 
> > > > 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 ...

IIRC it was broken only once.

> > Did you ever do it?
> 
> no

Well, you all know what I did ;-p

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

I assume by 'svnlog' you mean the mailing list where log messages
arrive...

Log messages are easily recreated, so I don't see a problem here, the
updated message would be seen ..

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

I haven't considered effects on other version control systems, such uses
have always been unofficial to me..

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

I would guesstimate that I made 50+ modifications to the repo before it
went online and something like 10-20 after it was online.  As I said
above, IIRC it broke only once and was fixed immediately.  Also, it was
nothing unrecoverable and (again IIRC) only a handful of people were
affected.

Fixing the repository involved editing the metadata by hand (a task for
which I could have provided a small shell script if it had affected a
considerable number of people) or patching the output of 'svn diff' into
a fresh checkout.

This was of course very unfortunate, but my mistake was not of a kind
that has a considerable risk of being repeated.

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

Yes.  This breakage, however, is outside of the repository, that's what
I wanted to clarify.

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

You can have empty revisions.

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

I share this sentiment on another issue :)

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

I again assume that you mean the mailing list by 'svnlog'..

If somebody wishes to use the mailing lists to fetch changes I cannot
stop them, but this is clearly not something that has to be supported.
The repository can provide you with the same information in a much more
efficient and easy to handle way.

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

This is a non-issue, it has always been announced in public and there is
no reason to assume it would not always be.

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

This assumes that he overlooks the flamewar attached to the first log
message.  Highly unlikely to say the least IMO.

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

By the very nature of the change the repository cannot notice it and
send a notification automatically.  This has to be announced manually,
but this is not a problem.  Such modifications are few and far between
if they happen at all.

> > 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.
> 
> well at least to me it appears that we have consensus with you as
> exception

I can and will accept any decision that is reached.  The problem is that
this decision does only affect myself and if I know that it is based on
misinformation/misinterpretation then you will have to understand that
it is bound to cause me quite a bit of frustration.

Diego