Geek Answers Handbook

How to interact source code in multiple places

We have a VMWare image running a gforge instance on our local network. We would like some outside people to be part of the dev process. We would like to keep this repository as the main repository of SVN. What options are available for sharing code with external resources and combining it in our local repository.

Other options may be to place this completely outside our network (on some of the hosting providers), this is unacceptable, as it allows employees to access code outside our network.

We are looking for suggestions to solve this problem.

+6
version-control svn build
source share
5 answers

SVN is not a distributed VCS. If you want to stick to SVN, you will have no real alternative than giving them access to the local server from the outside.

If you want them to be able to make a separate external repo that is not physically connected to your internal server and merge their changes into a central repository manually, you will need to look at a distributed VCS, such as Git or Mercurial .

+6
source share

Subversion is a centralized (compared to distributed) version control system. It is designed to work together, performing parallel operations with a single repository. So you basically have two options:

  • Adhere to centralized version control and allow external access to the repository (most routers and firewalls allow you to redirect specific ports, so this should not be a big problem).
  • Switch to distributed version control (Git, Mercurial, Bazaar ...).

Everything else will be a difficult workaround.

+2
source share
  • You can set up a VPN and let them transfer directly to the host.
  • You can switch to distributed VCS as Git.
  • You can configure another SVN for them and combine them. I think that are associated with a headache.
+1
source share

Important for you should be:

if you look at developers who work and commit the changes they make to their code, then SVN is good.

if you look at developers who themselves work on large chunks and want to combine their code base as soon as they are confident in the integrity of what they worked on, go with Git or Mercurial.

I would also like to add that Git can do a good job even with constant integration, however, if your developers are more familiar with SVN-based tools, then it might not be very useful to incur overheads forcing them to learn a new tool.

+1
source share

In a separate distributed VCS repository (Git, Mercurial, Bazaar), bindings can be fixed that send patches for the gatekeeper (a person with svn access) to enable distributed developer contributions.

Update / clone / check hooks on a distributed VCS can also update / pull / compress from the svn repository, keeping your distributed VCS synchronized with svn.

This approach will support your svn server and the workflow and backup process that now works for you. Only new distributed developers should learn the new VCS (Bazaar, Git, etc.).

Now I have to do this in the project and update it with the details.

0
source share

More articles:


All Articles