[Ffmpeg-devel] libswscale merged into the FFmpeg repository

[Michael Niedermayer]

Hi

On Thu, Jul 27, 2006 at 11:42:39PM +0200, Diego Biurrun wrote:
> 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

and if the patch doesnt apply cleanly? or if some specific files
arent at the latest revision maybe with half of the changes in svn already?
(both where true for me for the cvs->svn move and iam sure for many others
too)


> 
> > 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?

next time we move somthing between mplayer and ffmpeg we can restart this
disscussion from the begin again as the same problem will hit us


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

in cvs moving files is consistent, consistent here means not contradicting 
itself, having a unused and not compiled file in the past is not inconsistant
and isnt a real problem, sure its not correct and it doesnt match the real
past but i see no inconsistancy in it ...


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

the resulting repository will be inconsistant wont it? 
inconsistant here means that theres a file with revision R and date D and
one with revision r and date d and R>r && D<d

thats not something i can accept unless i have a some proof that this is
allowed in svn if not theres a good chance it will cause problems in the
future and fixing them could be a nightmare ...

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