On Sun, Apr 15, 2007 at 12:31:46AM -0400, Shawn O. Pearce wrote: > Mail them a DVD of the Git import, have them load it locally, > and use --reference for all future clones. With Git its possible > to build fast throwaway trees from any random URL, so long as you > keep at least one repository available locally to act as a reference. Ok, that makes it even more worthwhile for them to keep one tree locally, I didn't think of that :-). > > the commit is accepted. The 'update' hook documentation suggests that > > ACLs should be possible and implemented via that. > Yes. I run probably the most paranoid update hook in existance. > If you want a copy let me know, I'll send it to you. Its a Perl > script that verifies the 'committer ' line matches the UNIX uid (by > doing a table lookup) for every new commit or tag being introduced > to the repository. It also verifies that the user can update that > branch, create it, delete it, or rewind it. > > It sounds like you would need to add some additional rules about > specific paths being modified only by certain people in certain > branches (for the SELinux stuff), and running other validations in > the documentation (whatever that is). Yes please, it would be greatly appreciated. I'll hack path ACLs into it, and feed it back to contrib/? (CVS and SVN ship ACL stuff in their contrib/, so we could probably follow suite safely). > What you could do is create a program that mangles the files before > delivery. You would probably want to do something like: > > $Id: 7fbf239:path/to/file$ There's one core problem with mangled after the fact there: It's going to break checksum/gpg verification later. Here's the existing CVS process as a comparison. 1. Developer creates/changes foo-1.2.ebuild. (cvs add, but not cvs ci). 2. Runs the local verify+commit tool (repoman). (these steps are done by repoman now) 3. Generates the initial Manifest (contains SHA256/MD5/RIPEMD160 etc.). 4. Commits the initial Manifest AND the files from the developer. 5. Gegenerated Manifest because of any keywords in the files. 6. Manifest is clear-signed with gpg. 7. Signed Manifest is committed. We can't require the re-processing of the files before they can be verified, as that removes the ability for users to easily verify them with standard tools (md5sum,sha256sum). The direct conversion of such a process to insert the $Id$ and then re-commit that $Id$ runs into chicken-and-egg problems as well, so either git needs to insert the keyword, or the file can't be changed. -- 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:
pgpeYGNN89lxh.pgp
Description: PGP signature