Source Control questions

Question

I have a few questions of source control. Myself and another web developer have joined a company to take over software development of old and future projects. The company has no source control, as old projects were developed by external contractors with there own versioning systems. I want one setup ASAP but I have some questions about the 2 popular choices that I have been unable to find answers too, so not just another GitHub vs Subversion topic.

Some background on the projects to be stored. There are several older projects, mostly driver/firmware. New projects by myself will be more .Net/Java based, and the web developer will be wanting to store website content.

From what I have read and tried, I prefer Github, but the web developer is becoming more adamant on using Subversion. Another consideration maybe I am on a Windows machine and the web developer is on a Mac, so the clients available will differ. I am hoping we can both use the same source control, rather than go our separate ways. The first source control I used was team foundation server, where we had one repository and subdirectories for each project from the root.

Q1. Concerns about GitHub, the basic package will allow for 10 repositories. Considering there are already 5 websites, dozen older software projects, 3 new projects and even more still to come, I feel we would be limited on the number of projects we could host, even if the edits are few and far between as projects get older. Given with Git you seem to clone/checkout the whole repository. Would I be correct in assuming I could not store several projects in one repository, just under different sub directories.

SoftwareRepo/Project1/Code

SoftwareRepo/Project2/Code

SoftwareRepo/Project3/Code

SoftwareRepo/Project4/Code

Or instead of subdirectories try using branching, so you have an empty repository which you branch from, where each branch contains the content for each different project. The drawback I see here is when you switch branches (or projects in my case) the files of the old project become hidden in file explorer until you switch back to the previous branch (previous project).

I think what we need is a higher number of repositories, and a cap on the disk space they use up as we may have dozens of smaller projects that are one offs and really only require source control during active development, and then a few bigger projects that would make use of GitHubs powerful features like branching.

For the clients, I have found SmartGit to be very useful in managing the test repositories I created, against the command lane which I originally tried to use.

Q2. If we use SubVersion, we could host it ourselves. I have a i7 with 6GB ram so offered to run up a virtual machine but the web developer is unhappy that I maybe out the office so the subversion server would down, and neither are they happy with my machine running 24/7 like a server. We do have a business server but the outsourced administrator is extremely touchy on running processes so we cannot place subversion on that either. The server harddrive is atleast backed up daily. Is it possible to store the repository files on our business server and just use clients to access subversion files, or is a subversion server process required for clients to access the repository files. The web developer is considering running an SVN server in the Amazon E2C cloud, but I have no experience with it so cannot comment. My concern with subversion is I have used it before, and had some very strange error messages with TortiseSVN that had me deleting my checked out folder and redownloading the source from the repository due to conflicts (that didnt seem to exist), before I could checkin any code.

If you had lots of small projects of varying types, which source control client would you pick and which approach would you take (online host, host ourselves). Im trying to work out what is the best solution out of the options available.

EDIT

Disappointingly, We have gone with SVN in the end. Not my personal choice but we had incredible difficulty in trying to setup Git on a windows machine and run it as a server. It requires lots of additional installs, setup of SHH, and management via the command line. As shown in this guide - http://www.timdavis.com.au/git/setting-up-a-msysgit-server-with-copssh-on-windows/ SVN on the otherhand we used VisualSVN Server, pointed it to a network drive to store repositories and we were on our way. A single installer and easy to use management console. If Git could be done as a single installer with a management GUI we would have used it as I think it is more flexible and reliable given we have had SVN error messages already, (corrupt files/files doe snot exist/run cleanup etc.)

Answer 1

To satisfy your svn friendly web developer, you can have svn to be your central repo and you can use git on your local machine and talk to svn server using git-svn.

Given with Git you seem to clone/checkout the whole repository.

Doesn't have to be a complete clone from revision 1. You can clone from a specific revision.

Q2. If we use SubVersion, we could host it ourselves. I have a i7 with 6GB ram so offered to run up a virtual machine but the web developer is unhappy that I maybe out the office so the subversion server would down, and neither are they happy with my machine running 24/7 like a server.

If its possible, ask your client to get a NAS and set up your svn repo there. You can have your personal (git) clone to work on even if you are not in the office. The web developer can also be happily working with svn.

Answer 2

GitHub is not a version control system, it is a hosting service for git. Git can be hosted locally very easily. (See, e.g., gitolite for hosting multiple git repositories using ssh.)

I would strongly recommend that you use the same program, whether Subversion or Git, for both of you. Personally, I would recommend Git, with individual repositories for each project, and use a locally hosted server such as gitolite, although it's not quite as snazzy as GitHub. I have a strong preference for not relying on third parties to provide access to such a critical resource as my source code.

Answer 3

If I were you, of course I'd have a separate git repo for every unrelated project. I call two projects 'unrelated' when you don't usually need to make coordinated changes to both, you don't need to make a commit to both simultaneously. Maybe you don't have so many unrelated projects, and only need 3-4 repos. I work in a huge project releasing a number of independent products, and we only have 3 git repos.

Yes, a subversion server is a process that needs to run in order to allow svn clients to communicate with it. Notice that svn hosting is also widely available.

You can also make the SVN repo follow your git repo, so each of you get his/her preferred interface. Explore this some day.

If you use git, you can also self-host it: [1], [2], etc. This may not be as sexy as github, but do you really need all these features? If you do, though, 20 repos cost $22/mo., and 10 repos, $10/mo. or so. Amazon EC2 would probably bill you similarly.

But if you're not very strained financially, I suppose that you buy commercial SVN and git hosting, and offload administration, backup, etc from your shoulders. With git, you have a full copy of repository on each machine anyway, it protects against a number of failures.

Answer 4

I think you've missed the point a little bit on git. From the man page: "Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols." That not only means you can host it yourself from your i7 if you want, but if your "business server" has already set up one of those you can use it without needing the sysadmin to install anything else.

Also, the distributed nature of git means you don't need to have only one central repository, and you don't need to have all your repositories always online. As long as you are regularly online to share changes with one another, you can each host your own git repository wherever you want, checking in changes to your own as needed, and pulling changes from the other as needed. That kind of flexibility sounds ideal for your type of situation.