On Sat, Apr 14, 2007 at 05:02:47PM -0700, David Lang wrote: > > - 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). > > - 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. > > - 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. > > - 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@xxxxxxxxxx GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Attachment:
pgp6JNvsKYcwQ.pgp
Description: PGP signature