Re: Weird shallow-tree conversion state, and branches of shallow trees

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Seriously again: I am at fault for putting the shallow support into Git, 
> failing to provide sensible test cases. This was partly due to my 
> laziness, and partly due to the overwhelming lack of demand.
I still haven't figured out a decent testcase for this, I need to dig
harder.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2@xxxxxxxxxx
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Attachment: pgpezcM94A2YP.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]