[Ffmpeg-devel] Re: Advocating periodic releases

[Oded Shimon]

On Fri, Oct 06, 2006 at 05:26:41PM +0200, Panagiotis Issaris wrote:
> Hi,
> 
> On Fri, Oct 06, 2006 at 05:04:59PM +0200, Oded Shimon wrote:
> > On Fri, Oct 06, 2006 at 04:55:34PM +0200, Reimar D?ffinger wrote:
> > > Hello,
> > > On Fri, Oct 06, 2006 at 04:19:17PM +0200, Panagiotis Issaris wrote:
> > > > One of the nice things is that the entire source code of the FFmpeg project, with
> > > > every revision of every file included, fits into 9MiB using GIT. And you always
> > > 
> > > How did you do that? I canceled the SVN import for MPlayer after ca. 500
> > > MB because my HD was full...
> > 
> > I fail to see how it is possible at all, because the ffmpeg _source_ alone 
> > is 12mb.
> > 
> > 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...

> > BTW, I'm really pleased with svn. The history past the current revision is 
> > useless in 99% of normal cases, and I've seen it handle just about 
> > anything I threw at it perfectly. The only thing it doesn't support easily 
> > is the moving of files/directories across repositories, an action which 
> > can't even be easily defined anyway and doesn't really make sense. (If you 
> > disagree, try to think what is the best way for this to be done, and 
> > you'll find that everyone has a different opinion on this...)
> 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...

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

- ods15