KDE development with git
Simon Hausmann
hausmann at kde.org
Fri Jul 13 09:02:51 BST 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070713/6e540c54/attachment.sig>
More information about the kde-core-devel
mailing list