Back at VeriSign we used branch-specs in Perforce to normalize
checked-in tooling to standard names (without version numbers). For
example:
Checked into the Perforce "releng" depot was the following:
//releng/
head/
vendor/
junit-4.1/
junit-4.1.jar
junit-4.3
junit-4.3.jar
branches/
same as above...
And a product specific depot may be:
//general
head/
...
branches/
...
The branch spec for a product would be:
//releng/branches/branch-name/vendor/junit-4.1 //workspace/releng/vendor/junit
...
You should be able to get the point. We supported workspace
composition, and the neat thing was that the build system itself was
versioned and could be separately versioned and changed as though it
were itself a product. But, as the build system was Ant based, rather
than constantly changing the build system to adapt to new versions of
junit, oro, and ivy jars, we simply used branch and view specs to
neutralize the workspace so the build system only referred to names
that lack version numbers. Further, a product could upgrade to a newer
version of the build system, almost always without consequence just by
changing these mappings.
So, is there some way to similarly accomplish this in Git? It was a
huge time-saver for release engineering at VeriSign, a pattern I'd
like to replicate using Git.
- Bob
--
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