[Ffmpeg-devel] About swscale

[Uoti Urpala]

On Wed, 2006-06-28 at 23:50 +0200, Michael Niedermayer wrote:
> > 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. 
> 
> are you trying to say a commit libswscale/abc libavcodec/xyz will fail?
> if so, i doubt thats true and if it is its a bug/limitation in svn and
> should be dealt with accordingly (=bugreport)

It's not possible to make a single commit which would affect both files.
I haven't set up repositories to test what the commandline tool does if
you give it paths from different repositories (it might make independent
commits to them using the same comment, or it might just fail). At least
"svn commit" will not commit anything under externals.

> > swscale changes would not
> > appear in the FFmpeg history.
> 
> if there are no changes in ffmpeg then theres little need for them to appear
> there as a change of the revision number ...

I mean the global repository history (as shown by "svn log -v" at the
top level), that's more than just a change in revision numbers.

> > Specifying an FFmpeg version with a
> > revision would not include swscale.
> 
> same as with mplayer and lavc/lavf, or even all external libs mplayer uses

Yes, it's comparable to MPlayer and lavc/lavf, but I think it is a real
problem with MPlayer too so it shouldn't be ignored here just because it
already happens somewhere else.

> > > > 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
> 
> first requirement: leave me out of this idiotic disscussion
> second: distort the history as little as possible

If you don't agree with what I consider to be the most practical
solution but don't want to discuss your requirements further then I
think trying to come up with alternative proposals based on just
"distort the history as little as possible" would be a waste of my time.
I don't see keeping the previous history only in the repository where it
happened (and where it's readily accessible) as "distorting" it myself.