[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