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

[Michael Niedermayer]

Hi

On Tue, Feb 27, 2007 at 01:42:21PM +0100, Diego Biurrun wrote:
[...]
> > > > 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.

yes but breakage is breakage and in this case its fairly serious breakage
outside the repo


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

yes but thats not the same as deleting a revision its changing one and that
would break even unmodified checkouts ...


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

yes


> in a much more
> efficient 

no, the user has to poll the server to see if theres anything new
which not only significantly increases the load on the server it also
adds a lag of a few hours which for development is unaccpetable

and with repo hacking checking for updates is not enough a user has to
fetch the WHOLE repository with all history once per hour or so, do you
call that efficient?
of course the user could just stay with the updates and hope that her
local revision control system has no problem with random internal changes
in its mother repo


> and easy to handle way.

debatable ...


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

you missunderstand, a script which fetches updates via svn or a mailinglist
can not make sense of your human readable announcement, a machine parseable
list of what was hacked and when IS needed and or a clear machine readable
announcement on svnlog like "hacked file-X rev Y"


[...]

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

well you are free to convince everyone that this is safe
but your argumentation is largeing in the direction that you dont care that
theres a difference between svn log and svn, that non svn revision control
systems are not supported so you dont care and that people are unlikely to not
search for a second messages with the same revision if theres a flamwar

if you broke svn once or 10 times again is debateable depening on how you
define breaking, with a weak definition its certainly is just once but with
a strict definition of svnlog-svn consistancy it is every time you did it

to me hacking svn is like editing /dev/hda while it is mounted, you cant
"unmount" svn as that means taking away everyones checkout and knowledgde
of all revision numbers
that said you can change /dev/hda while its mounted without breaking anything
its just not something i would do if i can avoid it especially not on a system
which contains data i care about

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- 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/20070227/6267878a/attachment.pgp>