On Wed, 2010-09-08 at 00:22 -0600, Adams, Brian M wrote:
> I have a project whose subversion repository needs to be split across networks and I'm seeking ideas for how to best manage this. There are mailing list posts addressing public/private on the same server, but I didn't find much relevant to cross-network...
>
> While the core of the project can be in an svn repo hosted on a public network, some components must be retained in an svn repo hosted on a private network, inaccessible from the public one. While developers on the public side need only work with public content, developers on the private side want the private content to augment the public content as seamlessly as possible. A few possible ideas:
>
> 1. As the project already manages all it's third-party libraries with svn externals, we could create core repos on public and private sides, then meta-packages on the respective networks, composed primarily of externals which pick up the right pieces to assemble the public or private version of the software. For example if the repos were laid out as
> * public/project/src
> * public/project/openlibs
> * private/project/closedlibs
> then there could be a public meta-package containing nothing but externals to public/project/src and public/project/openlibs, whereas the private meta-package would contain externals to all three components. While this seems straightforward,there are many more directories with public/private versions or components, it would require involved reorganization of content, a more complex release process traversing and tagging the externals, and additional complexity on the development team (or the tools they maintain). The advantage is a single cohesive checkout.
>
> 2. We could revert to script-based management of our version control process on the private network, for example, notionally: (1) svn co public/project/core project/core; (2) cd project/local && get_private_repo_parts.sh, which could augment the repo with the necessary private components. This defeats some of the appeal of using externals and would probably require private developers to have a set of utilities to wrap svn commands to make sure the private parts of the project/ directory get traversed when doing any svn command. That said, it's probably far simpler than (1) and I suspect is how other projects with various levels of publicity might manage their releases.
>
> 3. (Not possible to my knowledge) Notionally, the best way to manage this might be for the public repo to contain "optional externals" which point to the private repo. In this scenario, developers on both networks would just svn co public/project and for public users, those externals pointing to the unreachable private network would timeout or could be disabled at checkout time with a command line switch, whereas users on the private network would get all parts. I don't think this possible with current subversion capability, but perhaps I'm wrong. It's the closest concept to the way we'd organize the repo in any case.
>
> What other subversion features or approaches might I consider?
A variation of option 3 is to provide a name service alias so that the
externals accessed from the public network resolve to the public server,
and the same externals on the public server, when accessed from the
private network, resolve to the private server. To do this, a domain
name alias for the private server name could be placed in the public
network. This would require a high degree of structure overlap between
the 2 repositories to work.
>
> Thanks,
> Brian
>
--
Tony Butt <tony.butt_at_cea.com.au>
CEA Technologies
Canberra
Received on 2010-09-08 08:40:57 CEST