[FFmpeg-devel] [RFC] libswscale into the FFmpeg SVN repo

[Michael Niedermayer]

On Sat, Apr 04, 2009 at 03:52:15PM +0200, Stefano Sabatini wrote:
> On date Saturday 2009-04-04 12:54:24 +0200, Christian Iversen encoded:
> > M?ns Rullg?rd wrote:
> >> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
> >>
> >>> Hi all,
> >>>
> >>> the feat mentioned in the subject has been mentioned many times, and
> >>> IIRC there is also a general agreement about it.
> >>>
> >>> And I also remember that someone (Diego?) mentioned some technical
> >>> problems.
> >>>
> >>> Or maybe if we're going to do that step, maybe we could even afford to
> >>> do yet another one and migrate to git as planned.
> >>
> >> Diego once said there is a way to merge the svn repos while
> >> maintaining chronological history.  Alternatively, it can be merged as
> >> part of a transition to git.  It is not advisable to move to git and
> >> merge the trees at a later time since that would rewrite the entire
> >> history and invalidate any branches people might have.
> >
> > Generally, it's possible to merge the the file sets from 2 repositories,  
> > such that the revisions will be chronologically correct, and all files  
> > are available in the final repos. However, I don't think it's possible  
> > (at least easily) to merge to repositories while preserving old revision  
> > numbers. So if you do this chronologically-and-historically-correct  
> > merge, all the references to "fixed in rev xxxx" will be "broken".
> 
> We may add in the historical log commits:
> OLD-REPO-ID rXXX
> 
> This may be applied to both a SVN+SVN->SVN and a SVN+SVN->git merge.

iam against a SVN+SVN->SVN merge
randomizing revission nmbers outweights the philosophical gain of
swscale not being extern.
and i belive there is no consensus on a switch to git ...

i think the way CVS did versioning was more flexible and powerfull, and
no iam not saying the cvs implementation was good, with its non atomic
changes, lack of move&copy tracking per directory commit mails ...
Fixing the CVS implementation and storing the file path in the RCS files
instead of storing the RCS files in the path would have made cvs more
powerfull than svn is today. (that is instead of a tree with the rcs files
as leafs, there could be a flat list of rcs files where each stores where
in the tree it is under which name for each revission or if that revission
existed rather outside of the tree in a difeferent repo)
And with a RCS file upload/download (aka push/pull) cvs could have been
used offline and distributed ...
i never understood why people droped cvs and started to work on svn that
is in several ways inferrior (less secure, no moving between repos, database
shit, ...)
</rant>

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090404/afd565e1/attachment.pgp>