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

On Sat, Apr 14, 2007 at 05:02:47PM -0700, David Lang wrote:

quoted

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

Yes, I'm aware that it may be more efficient over the long term for them
to pull given blocks, and I'm going to recommend that developers have a
full history anyway, but I suspect that they will still make heavy use
of shallow trees, esp. as some do throwaway trees often.
(This one is a moot point anyway, the shallow history support in Git is
pretty much done baring the bugs I posted about previously).

quoted

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

shallow tree, because we really do have people that check out arbitrary
sub-divisions (the web translation teams come to mind, they just have
checkouts of English and their own language), and going sub-project
would be insane for that.

quoted

- 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

I should have mentioned that we aren't following the kernel model here.
All of the developers will have git+ssh access to the central tree, to
push their own changes to it. On a similar tangent, in some subtrees
(our documentation mainly) we have server-side validation tests before
the commit is accepted. The 'update' hook documentation suggests that
ACLs should be possible and implemented via that.

quoted

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

The tree that goes out to users is NOT git or CVS. What you point to
here is impossible unless we forced all of the users to migrate to git
(a truly herculean task if there was ever one).
It's a tarball or an rsync of an automatically managed CVS checkout.
(Tarballs go onto the release media, and are also widely used by those
that sneaker-net their trees to machines for security reasons).
Alternatively, the users browse the viewcvs, and pull something from the
Attic. Regardless of where they get the file from, the problem is that
the file doesn't contain any markers to help the developers merge it
back again.

A frequent occurrence of this is where the user takes rev X of a file
(because it was the latest one at the time), makes a local (non
version-controlled) copy, and submits it back our Bugzilla some months
down the line. Thanks to the $Header$ in the file he submits, we can
produce a diff against the original revision, and figure out how best to
merge it with the latest revision.

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