i couldn;t find any ready way to do it.... but i've hacked up a few preliminary thoughts on how this might work in git. comments and feedback are welcome :-)
the basic idea is to import each snapshot of each vendor release as a tagged root commit, then push all these tagged root commits into a central "library" repository. each tagged root commit stands alone and functions as a cvs module.
library repos are set up as remotes under git, and a simple script will import a set of snapshots into a brand new project as a baseline for customization.
the three shell scripts, and the two control files used by them, are included here:
==> vendor-tracking.sh <==
###########################################################
#
# Import a vendor snapshot into a "library" repository.
#
# To import a vendor snapshot, unzip the snapshot into
# a new folder. Then go into the folder and type
#
# xxx-import <library> <tag>
#
# This will create an empty git repo in the current
# snapshot folder and create a root commit in
# it which holds the snapshot. This root commit will be
# tagged as "tag" and then pushed into the "library" repo.
#
# No error checking is done.
#
###########################################################
xxx-import ()
{(
repo=$1
tag=$2 export GIT_DIR=/tmp/$$.$tag
rm -rf $GIT_DIR
mkdir -p $GIT_DIR
git init
git add .
git commit -s -m "Import $tag"
git tag $tag master
git push $repo refs/tags/$tag:refs/tags/$tag
rm -rf $GIT_DIR
)}
###########################################################
#
# Use a vendor release in the current project.
#
# To use a copy of some vendor snapshot in the current
# project, go to the top level of your current project,
# then type
#
# xxx-use <library> <tag> <path>
#
# The tagged snapshot will be fetched from the library
# and deposited into the <path> subdirectory, then committed
# to the project.
#
# No error checking is done.
#
###########################################################
xxx-use ()
{(
repo=$1
tag=$2
path=$3 git fetch $repo refs/tags/$tag:refs/tags/$tag
git read-tree --prefix=$path/ $tag
git commit -s -m "Use $tag as $path"
)}
###########################################################
#
# Create a new project from a set of vendor components.
#
# To start a new project with a known array of vendor
# components, create a remotes file describing the libraries
# and an manifest file describing the components and how they
# will be used. Then, in a new folder, type
#
# xxx-start <remotes> <manifest>
#
# This will create a new Git project in the current folder,
# add a remote for each library repository, then proceed to
# fetch and commit each vendor component into the new project.
# The new project is now ready to be customized.
#
# No error checking is done.
#
###########################################################
xxx-start ()
{(
remotes=$1
manifest=$2 git init
cat $remotes |
while read name url
do
git remote add $name $url
done
cat $manifest |
while read path remote tag
do
xxx-use $remote $tag $path
done
git checkout -f master
)}
==> remotes <== lib1 ssh://me@home.com/home/me/work/library lib2 //filesrv/git/library
==> manifest <== path/to/A lib1 vendorA/componentA/version1 path/to/B lib2 vendorB/componentB/version2
i would prefer to import and tag raw tree objects, since i get some of my snapshots as pre-assembled collections of (modified copies of) several components. it would therefore be convenient to have several tags per snapshot pointing at the subtrees corresponding to each component. however, fetch and push seem to prefer commits over trees....
as it stands, the vendor snapshots have no "history" to them. each snapshot stands in isolation. there was an interesting thread a few days ago about importing ancient kernel history as a series of trees, then "stitching together" a "synthetic history" from a collection of trees. i would see something like that as the basis for "vendor tracking branches", which could be restitched if an older snapshot is received "out of order".
hope it helps ray
