[FFmpeg-devel] ffmpegs future version control system

[Reimar Döffinger]

Hello,
On Wed, May 09, 2007 at 02:41:35PM +0200, Michael Niedermayer wrote:
> On Wed, May 09, 2007 at 11:03:22AM +0200, Reimar Doeffinger wrote:
> > On Wed, May 09, 2007 at 10:23:20AM +0200, Guillaume Poirier wrote:
> > > Le 9 mai 07 ? 02:51, Michael Niedermayer a ?crit :
> > > > i would like to change ffmpeg from svn to git
> > > 
> > > Yeah, it certainly seems to be smarter than SVN in most ways. After  
> > > all, the migration to SVN happened with the death of MPHQ1, so there  
> > > hasn't been a thoughough discussion about the pros and cons of SVN.
> > 
> > I agree that it has many nice features, but the only case where there is
> > any "smartness" (that is in detecting copies) it like always proves from
> > time to time that artificial intelligence is just a step below natural
> > stupidity.
> 
> do you remember any specific cases where gits copy detection was seriously
> wrong, iam interrested to see such failures ...

Seriously wrong? No, I don't think so. But in my MPlayer git tree
(http://www1.mplayerhq.hu/~reimar/git/MPlayer/), afskip branch, af_skip.c was
created from af_dummy.c, and I would have liked to have this information preserved
(can of course be done via the commit message but that's not quite the
same).
git-blame thinks the code came from all over the place, which was not
really the place (at least not that much).
I attached that file, since git over http is not quite efficient you
might not want to clone that full repo.

> also keep in mind git was buggy until 3 days ago with blame/annotate and
> copy detection

My git is not _that_ up-to-date I admit ;-)

> also i think that all copy missdetections could be fixed simply by seperating
> copy from modify, that is check in a true copy first and then check in
> modifications. that way git could detected the ancestor file by simple
> file compare, and that wont be wrong

Probably, but then it's (IMO) even more of a pain than svn copy.
On the plus side contrary to svn it can handle file merges without extra
steps. I still do not like it because there simply is no algorithm that
can detect copying, it can only see that the data is (very) similar and
from past experience I extrapolate that programs attempting the
impossible are always a pain (I am certainly not saying that this makes
git as a whole bad!).

Greetings,
Reimar D?ffinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: af_skip.c
Type: text/x-csrc
Size: 2316 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070509/62e65cd9/attachment.c>