[Ffmpeg-devel] libswscale merged into the FFmpeg repository

[Diego Biurrun]

On Thu, Jul 27, 2006 at 11:12:42PM +0200, Michael Niedermayer wrote:
> 
> On Thu, Jul 27, 2006 at 06:14:50PM +0200, Diego Biurrun wrote:
> > On Wed, Jul 12, 2006 at 05:43:18PM +0200, Diego Biurrun wrote:
> > > On Fri, Jul 07, 2006 at 07:59:24PM +0200, Michael Niedermayer wrote:
> > > > 
> > > > On Fri, Jul 07, 2006 at 06:45:26PM +0200, Diego Biurrun wrote:
> > > > > On Fri, Jul 07, 2006 at 04:09:36PM +0200, Diego Biurrun wrote:
> > > > > > 
> > > > > > As promised I have created a prototype of the FFmpeg repository where
> > > > > > libswscale has been added with complete history.  You can browse it
> > > > > > online at
> > > > > > 
> > > > > >   http://svn.mplayerhq.hu/ffmpeg.libswscale/
> > > > > > 
> > > > > > or check it out as usual
> > > > > > 
> > > > > >   svn checkout svn://svn.mplayerhq.hu/ffmpeg.libswscale/
> > > > > > 
> > > > > > What I did was filter out libswscale and postproc from the MPlayer repo
> > > > > > and then load those 444 revisions into the FFmpeg repository.  Dates and
> > > > > > author names have been kept, just all those new revisions have been
> > > > > > added.
> > > > > > 
> > > > > > This is what adding libswscale complete with history could look like.
> > > > > 
> > > > > Note that this will not break or harm current checkouts in any way.  The
> > > > > next 'svn up' will just make a bigger step than usual.
> > > > 
> > > > hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm ...
> > > > are you sure that what you did is ok? revison numbers and dates are not
> > > > monotone anymore ...
> > > 
> > > Revision numbers are monotone.  It's just that 444 revisions have been
> > > added.  The database cannot tell if this happened through 444 commits or
> > > loading one dump..
> > > 
> > > Yes, dates are not monotone anymore.  A workaround for this would be to
> > > commit all those 444 revisions with an adjusted current date, possibly
> > > also changing the author.
> > > 
> > > > what about checkng out a specific revision number or a specific date
> > > > will i if i check out yesterdays date get all files for for revision X
> > > > or all files with different revision numbers but the date of yesterday?
> > > 
> > > Checking out by revision number is not a problem.  Checking out by date
> > > is trickier.  Subversion seems to be doing some strange things. If you
> > > check out a snapshot from 20060420, libswscale/postproc is not there.  A
> > > checkout from 20060630 does contain postproc/, though.  The last
> > > revision before I added libswscale is from 20060707...
> > > 
> > > > and do you know of some docs/ML posts/source/whatever that says clearly
> > > > that such tricks are ok? i dont want to trash ffmpeg-svn ...
> > > 
> > > Not offhand.
> > > 
> > > There's always the possibility of just moving libswscale without
> > > history.  Given that the history is readily available in the MPlayer
> > > repository I don't think this is such a bad option.
> > 
> > So what's it going to be?  
> 
> its not possible to move libswscale from the mplayer repository to the
> ffmpeg repository while preserving history completly and consistently,
> svn does not support this so the only solution is to leave libswscale 
> in mplayers repository or create a new repository which of course would
> be alot of work for everyone and which would cause some troubble for
> everyone who has a modified ffmpeg source tree ...

Hardly a lot of trouble:

~/ffmpeg-checkout_old$ svn diff > ../local_changes.diff
~/ffmpeg-checkout_old$ cd ~/ffmpeg-checkout_new
~/ffmpeg-checkout_new$ patch -p0 -i ../local_changes.diff

> for the case of a new repository we could
> A. switch back to cvs (all problems solved except that roots at mphq will
>    kill me)
> B. put mplayer and ffmpeg in a single repository so moves become possible
> C. switch to some entirely different version control system
> D. just fix this single move and goto 1 for the next time we want to move
>    something

"goto 1" meaning here?

And no, there is no way in hell we are going back to CVS ;-p

> so my awnser here is again, leave it in mplayer, let ffmpeg check it out as
> external, the alternative
> is to start a disscussion about restructuring everything, which is fine
> but i dont want the swscale move to become dependant on that and be delayed
> until everyone agrees on such a restructuring ...

OK, then it shall be external.

> > 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, and no, being available somewhere else is as good as lost
> svn annotate, svn log, svn up with a date none will work,
> actually nothing will work ...
> what you suggest is like cvs add and cvs remove, thats 2 steps back

Speaking of "even with CVS this was possible" is nonsense.  As a
sideeffect of CVS having no notion of repository-wide revision numbers
it's possible to sneak RCS files into a repository and CVS will not
notice that they were not there before.  Still what you get is
inconsistent.  Checkouts from earlier dates will suddenly contain files
that were not present at the time, but were smuggled into the repository
later on.

What about the repository I created with libswscale added?  If we adjust
the dates we could possibly create an acceptable solution...

Diego