[Ffmpeg-devel] Re: Advocating periodic releases

[Panagiotis Issaris]

Hi,

On Fri, Oct 06, 2006 at 05:32:52PM +0200, Oded Shimon wrote:
> [...]
> > > 16:57 ods15 at crate15 ~/sources/mplayer/ffmpeg $ svn export . bah
> > > Export complete.
> > > 16:57 ods15 at crate15 ~/sources/mplayer/ffmpeg $ du -sh bah
> > > 12M     bah
> > > 
> > > You can't compress these or anything, they have to be in raw form 
> > > regardless of how past history is stored.
> > When I was talking about the GIT repository size, I was talking purely about the
> > repository, not about the checked-out files.
> > 
> > The files in the repository are stored as deltas and compressed (and rather
> > heavily so it seems).
> 
> Does this mean that if I use ffmpeg/git, the entire source tree will take 
> 12+9 MB? I suppose that is impressive and better than svn's 29mb...
Yep, and not just the current source tree, all previous versions of all files
too whereas SVN only stores the current revision and your (possibly modified)
checked-out source tree. IOW I can view all patches starting from 2001 to now
while being offline.

> > GIT handles this very nicely IMHO. It actually handles this implicitly: When
> > compressing the repository it notices that two files are identical or even
> > when they are only _nearly_ identical, it will say something like this:
> >  rename dlls/{kernel/tests/module.c => kernel32/tests/module.c} (100%)
> >  rename dlls/{kernel/tests/path.c => kernel32/tests/path.c} (98%)
> >  rename dlls/{kernel/tests/pipe.c => kernel32/tests/pipe.c} (100%)
> 
> Am I misunderstanding you or was it not clear when I said _across 
> repositories_ - meaning, taking a file/dir from mplayer repo and 
> copying/moving it to ffmpeg repo...
In GIT moving files between repositories is quite common, as the normal way of
checking out a tree is cloning it to a separate repository. So, in order to get
patches back in you _need_ to be able to get files from this to that repository.

> Also, I don't understand your explanation of the git rename thing, 
> renaming shouldn't be implicit, it should be on demand when actually 
> renaming a file, and should be done so with full log and anontate... Not 
> by some magic rename detection...
It is not magic, it is just that GIT uses the _contents_ of the file to address
is, not the file name any point of the files lifetime. 

In GIT ofcourse you still have to rename the file, but just using your systems
rename:
echo "hello" > a.txt
git add a.txt
git commit -a -m "New"
mv a.txt
git add b.txt
git commit -a # Here it will see that it is a rename

But, the nice thing is, if you create copies of files, it will also
automatically know that they are linked. So, lets say you create a new
videocodec based on snow.c, and you modify the rain.c, it will now that
it's "parent" is snow.c (based on similarity).

And for pure renames, there is surely no magic involved, just an identical MD5
checksum.

With friendly regards,
Takis