[Ffmpeg-devel] libswscale merged into the FFmpeg repository

Michael Niedermayer michaelni
Fri Jul 28 01:32:01 CEST 2006


Hi

On Fri, Jul 28, 2006 at 01:05:00AM +0300, Uoti Urpala wrote:
> On Thu, 2006-07-27 at 23:12 +0200, Michael Niedermayer wrote:
> > On Thu, Jul 27, 2006 at 06:14:50PM +0200, Diego Biurrun wrote:
> > > I vote for moving libswscale without history.
> > > It shouldn't be a great inconvenience, the history is available in the
> > > MPlayer repository...
> > 
> > i will not accept that the history is "lost", even with cvs we where able
> > to preserve it
> 
> cvs was able to preserve the file-specific changes but not the
> repository state in a way that would have allowed checking out old
> versions etc.

checking out old versions worked fine, they compiled fine and this was
used by many people for debugging


> 
> > , and no, being available somewhere else is as good as lost
> 
> Exaggeration.

so you propose to drop all version control, as revision history will
be available somehow somewhere anyway?


> 
> > svn annotate, svn log, svn up with a date none will work,
> > actually nothing will work ...
> 
> annotate:
> After moving without history, would require one more step to check the
> other repository for changes older than the move. So this is negative
> for moving without history, but nothing as bad as "as good as lost".

its unaceptable.


[...]

> svn up with a date:
> Would work correctly. Without moving it will NOT work for any date after
> the external is added. If the entry in the ffmpeg repository says "check
> out the latest libswscale here", it will say "latest" whatever revision
> of ffmpeg you check out. So this works much worse with externals. It
> might be possible to work around it with hacks that make the external
> definition versioned and then automatically commit changes to ffmpeg
> changing the versioning whenever something in libswscale changes.

*  it will NOT work correctly in the way you describe because move ==
   external in mplayer, no move == external in ffmpeg one will break
*  libavcodec, libavformat, ... MUST be checked out with the correct dates
   in mplayer or checking out old versions will break, so your argument
   is attacking the current libav* external in mplayer design as much as
   libswscales
*  svn up -r {2006-07-06} . libavcodec/ libavformat/ libavutil/
   works (correct dates checked out, not what you describe), case closed


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




More information about the ffmpeg-devel mailing list