On Sat, 14 Apr 2007, Robin H. Johnson wrote:
On Sat, Apr 14, 2007 at 10:56:10AM +0200, Johannes Schindelin wrote:
Ah! Seems we finally have a user for shallow clones! ;-)
Heh. I'm specifically looking at git, trying to resolve the deficiencies
that were identified during by one of our (Gentoo) SoC2006 projects, on
the potential migration of the Gentoo CVS. Git has matured tremendously
since then.
The primary Gentoo CVS module (gentoo-x86), has 234672 files tracked,
and 1309603 CVS revisions. Between 350k and 500k changesets, depending
on how you merge those revisions.
Couple of the things that were identified either in the SoC project, or
since then.
- Shallow history checkouts are important to our low-bandwidth
ebuild-tree developers (people in places with 33.6k modems, because
the phone lines don't work well enough for 56k), or other high latency
setups.
note that for people on low-bandwideth lines, makeing too shallow a checkout can
actually end up costing more over time (they will have to pull full revisions
since they don't have the earlier versions to just pull a diff against)
- Shallow tree (subtree) checkouts, for the developers that focus on
specific portions of large modules and have no interest in the rest of
the that tree. Eg. Releng does their work in gentoo/src/releng.
this could either be shallow tree or subproject, depending on how you end up
orginizing things.
- ACLs specific to subtree commits. Something similar to the cvs_acls.pl
that FreeBSD uses would be great. Eg gentoo-x86/sec-policy/ is
restricted to members of the security team (SELinux policies).
since git isn't designed with a single repository, it also doesn't need to worry
about acl's (in fact, i don't think it has the concept of permissions at all).
this is up to the people maintaining the 'master' repository to pull from the
right people
- CVS Keyword-like behavior, to specifically place the path and revision
of certain files into the file directly, for ease of tracking when the
file is removed from it's original surrounding. I know this one is
going to draw some flack, but it's a very common practice for a user
to copy a file out of the CVS tree, make some modifications, and then
post the entire changed version up, esp. when the size of the changes
exceeds the size of diff.
I'm not understanding why you need this. git tracks the file content, not the
diffs betwen files. a developer does their work and git figures out when you do
a pull if it's better to send the file or a diff (and if you are sending a diff,
what you are doing the diff against, it may not be the file that had that name
before)
there's no need to place the path and revision in the file itself.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html