--nextPart6181011.OEZt9yJa9k
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 contain=
ing=20
4 months of history is 126MB.

I have an import of WebKit that contains the entire history of /trunk. The=
=20
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 =
=2D-
> 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=20
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=
=20
point on it just follows, so the -r argument is needed only once and git-sv=
n=20
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 th=
at
> 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 l=
ike=20
git filter-branch for example.


Simon

--nextPart6181011.OEZt9yJa9k
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGlzGsWXvMThJCpvIRAobVAJ436yrRQ3s8cHevjO2JRUwXfkrHFgCghIZ9
IT8Wi5G6kK9TxeExjky4aRY=
=XHqe
-----END PGP SIGNATURE-----

--nextPart6181011.OEZt9yJa9k--