[Ffmpeg-devel] swscale recently broke (in mplayer)

[Michael Niedermayer]

Hi

On Fri, Aug 18, 2006 at 05:27:02PM +0200, Diego Biurrun wrote:
[...]
> > diego, could you explain how that repo breakage happened and how you fixed it?
> > is the svn repo now in a true history matching state?
> 
> If you are referring to this trunk/img_format.[ch] issue, then yes, it
> now matches history.

yes i was refering to that


> 
> If you are referring to the MPlayer repository in general, then no it does
> not match history.  It never has because the CVS repository from which it
> was created has had *massive* manual fiddling applied to it.  It's closer

well, i agree though "*massive*" sounds exagerated a little ...


> than ever, though.
> 
> > furthermore iam asking the admin team offically to NEVER attempt to rebuild
> > the ffmpeg repository no matter what the reason, this is far too dangerous
> > a single typo can wipe out the whole repo and whats worse errors can sneak
> > in unnoticed and throw everything into an inconsistant state
> 
> Admins can always do massive damage with single typos, that's why it's
> so important to make backups.  We have daily backups of all repositories
> so the window for dataloss is 24h 

with the img_format.[ch] issue it took more then a month to be noticed
thats much more then 24h, and backups arent that usefull for that anymore


> and it's not very hard to recreate
> commits from the mailing list archive.

if the repo is in a messed up state then fixing it is generally not possible
without breaking existing checkouts, the question is just how many are
affected, that could be none if the mess is in the distant past or noticed
quickly if its noticed after several month then many checkouts might break
thats unacceptable, especially when you consider that these rebuilds are 
done to fix minor errors in the history, things which cvs could not
represent correctly, IMO NONE of these fixes should have ever been done
after the svn repo had been created, the advantages simply are non existant
while the risks are massive
i dont want to think about what would happen if revision numbers would
change during such a messup/fix 


> 
> When I work on the repository I of course never work on the live
> repository, but on a copy.  There is no way that the live copy can ever
> be wiped out.
> 
> I'll make sure to triplecheck next time I make changes to a repository,
> but given how many times I made changes my record is still not bad.

you should IMO post every change in some way to mplayer-dev before doing it


> 
> Anyway, I'm not aware of any outstanding issues with the FFmpeg
> repository so the point is moot.

maybe, but i say it again, DO NOT rebuild the ffmpeg repository
ever, if ffmpeg where hosted somewhere else i would have moved it away
by now already, the admin team is not there to mess with the internals
of projects, the admin team should keep the server running and it should
do the admin jobs which the users need and want done but cant do themselfs
its not the admins job to invent rules interfering with internal
project work (cvs admin -o / svn cp reversal rules) and even less is it
the admins job to try to improve the repository by rebuilding it constantly

and diego, sorry for the flames, i really didnt want to flame but i really
think the admin team is "overdoing" things a little and that these repo
rebuilds need to be disscussed more carefully and not just done because
one or two persons think its a good idea and just a minor change ...
IMO and i think not only mine it is a very bad idea and very intrusive
change, not something which should be done as daily excercise

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is