[Ffmpeg-devel] About swscale

Uoti Urpala uoti.urpala
Wed Jun 28 23:12:14 CEST 2006

On Wed, 2006-06-28 at 21:56 +0200, Michael Niedermayer wrote:
> > If by "changes revission numbers or dates" you mean you don't want those
> > to change even for the swscale files then I think it's not possible to
> > move it into its own repository.
> well, iam starting to hate svn ...

Moving parts between repositories is generally not doable perfectly
without losing some history since there are inter-file dependencies (how
do you move a commit which touches files both inside and outside the
part?). CVS can only do it "perfectly" because it completely omits that
information from the history to begin with, so there's nothing left to
lose later. SVN also uses sequential revision numbers which can only
work in the repository they were first created in.

> > I think leaving swscale in mplayer and making it external in ffmpeg
> > would cause problems. MPlayer would then have two copies of swscale (the
> > "real", probably unused where it is, implementation somewhere and then a
> > copy under its external ffmpeg).
> no, mplayer doesnt have ffmpeg.c either, neither does it have the vhook
> directory

Ok there doesn't need to be another copy if the location in FFmpeg is
not under anything that would be included in MPlayer for other reasons.
That still leaves practical problems with external directories. FFmpeg
commits could not change the swscale files. swscale changes would not
appear in the FFmpeg history. Specifying an FFmpeg version with a
revision would not include swscale. Would the swscale files be supposed
to follow the FFmpeg coding style even if they're in the MPlayer

> > Just adding the files to ffmpeg without previous history and making sure
> > the history is readily accessible elsewhere might be the most practical
> > solution.
> iam against that and that decission is final

What are your requirements for an acceptable solution? I get the feeling
that they might be inconsistent or impossible to satisfy except by never
moving files out of the repository they were first created in.

More information about the ffmpeg-devel mailing list