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

"Robin H. Johnson" [off-list ref] wrote:

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

quoted

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)

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.

The speed at which a DVD (or small box of CDs) travels through the
various postal systems might very well be faster than 33.6k modem.
:-)
 

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.

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

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.

Git won't do this for you.  We specifically don't mangle source[*1*].

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$

where 7fbf239 is the earliest commit that introduced that particular
version of path/to/file, even if that is months old.  That would
be most like what CVS would do.  8 char abbreviated commits should
be reasonably stable, and not too long to read or copy and paste.
A format like the above would also be easy to grab and copy into
a Git command line.

If we had a Git library that could access the repository, this would
a pretty easy program to write.  You are basically blaming each path
in the current HEAD commit on the parent, until you cannot blame
anyone else for that path.  You do this blame on the entire tree,
and then output the munged structure (or only the files you want
munged).

Its good we have a GSoC project working on libification!  ;-)

[*1*] Yes, I'm ignoring the nutso crlf support that's now in...  Even
      though I work on Windows, the only true line ending is LF.  ;-)

-- 
Shawn.