Our software development is divided among several sites, one in the US and
two in Canada. Insuring that the source repositories are accessible from
all sites gives us the option to readily move work between sites. However,
some of our work is covered by US export restrictions and mustn't be
accessible to the Canadian sites and cannot be physically stored in Canada
regardless of who has access to the data.
Our tools group thinks it is Very Important for the company to have a
single repository. This makes little technical sense because the projects
implemented by the different sites currently have no common code. One
obvious solution is to keep the complete repository on disk at the US site
and use permissioning to block Canadian access to the restricted
directories. However, the US site is the very new kid on the block -- so
it is difficult for the decision-makers to conceive of moving all of the
company's source code there.
Although the single repository meme can't be confronted directly, perhaps
it can be subverted. It occurs to me that a collection of repositories
that all reside in a common directory might be considered a single
repository from a nontechnical point of view. Suppose each site had such a
repository cluster, with the permissions of each member repository set
according to the applicable data-sharing policy. Now lets get weird ...
suppose each repository intended to be accessible from a remote site were
NFS mounted to that remote site's repository cluster. Would such a trick
allow repositories to be accessed in essentially the same way regardless of
whether you were local or remote? (Assume we can enforce an identical path
to the base directory of the repository cluster at each site and unique
repository names across all sites.) This would be helpful for peopole
temporarily assigned to another site.
(I saw the FAQ regarding using NFS version that implement lock/unlock.)
I'm standing on my head to avoid a nontechnical fight. Is this approach
safe (that is, doesn't break svn), or should I take the bull by the horns
and pick a fight?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Sep 13 11:21:44 2005