On Friday 27 July 2007 12:02, CPD wrote:
> We produce variations based on a (mostly) common codebase. In CVS I set up
> "environment" modules for each platform, then when you are working on that
> platform, you simply check out the correct environment and build. Only the
> needed code and tools are exposed in that environment (this is important as
> clients must NOT see each other's code and most customers have some
> customization). I do this by defining and renaming modules in the CVSROOT
> modules file.
this sounds very close to what i'm trying to achieve at the moment.
> Does GIT support anything like this? Or another way to acheive the same
> end?
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@xxxxxxxx/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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
