[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE development with git
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2007-07-13 8:02:51
Message-ID: 200707131002.52307.hausmann () kde ! org
[Download RAW message or body]


On Friday 13 July 2007 09:09:05 Boyd Stephen Smith Jr. wrote:
> > imports of other
> > project history in git have shown that in average the size of the entire
> > history compressed is usually just as big as a single source checkout.
>
> That's not my experience on *any* of the numerous trees I've pulled down
> via git-svn.  Now, the compressed history is smaller than I expected in
> some cases, but it's still quite a bit larger that a flat source checkout.

Are you sure your repository is compressed?

Two examples:

My kdelibs checkout is ~130MB (just sources, without .git). My .git containing 
4 months of history is 126MB.

I have an import of WebKit that contains the entire history of /trunk. The 
pure checkout is ~330 MB, the .git directory is ~300MB.

I use git-svn to maintain both imports.

> Which, IMO, is *fine*.  I'm not concerned with the footprint on my disks --
> just the time from between thinking "I'll checkout project X" and being
> ready to hack on project X is quite long.  E.g., I'm been continually
> pulling down KDE revisions for *weeks* since I issues my git-svn clone
> command.  (I'm not sure if git-svn supports --depth yet.)

Yes, you can start history in git-svn from any revision on. I usually start at 
the top like this:

	mkdir foo
	cd foo
	git-svn init $SVNURL/trunk/foo
	svn info $SVNURL/trunk/foo
	--> find last revision in that path
	git-svn fetch -r1234

So the initial fetch decides where to start history with git-svn. From that 
point on it just follows, so the -r argument is needed only once and git-svn 
fetch or git-svn rebase work as expected.

> > I
> > don't think repository size is an argument with git, provided we get the
> > project boundaries right (which isn't hard I think).
>
> I'd prefer keeping everything together like it is now, and using a VCS that
> lets users that want less than everything check out individual directories
> or files (like SVN).
>
> If things are divided up in the future, it should be made easy to maintain
> history when moving a class or application across the boundaries.  E.g.
> from koffice to kde<something> to kdelibs or playground to review to trunk
> to (maintainence or historical) branch or a combination of those two
> moves.

Git makes it very easy to migrate history between repositories with tools like 
git filter-branch for example.


Simon

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]