What is a good non-branching non-local alternative to subversion/git?

Question

So, you won't hear me say that svn and git aren't extremely powerful and versatile tools, however for non-local developement (a central network share) it doesn't play well (two people can actually work on the same file) and creates a fair amount of overhead, so concretely I was wondering whether there are any alternatives out there which work well on central network shares (the primarily features used are blame and identifying stable code and development code).

I am aware this is a fairly broad question and I hope this falls within the scope of Stackoverflow, but as similar questions didn't get closed I decided to give this question a go.

---

In the reactions there seems to be a common misconception: right now we're using subversion and we're committing our changes and we are using tags to differentiate between versions and pushing only tagged changes to production. Additionally there seems to be the believe that local copies are somehow the holy grail of collaborative development. Let me tell you that if you only work with 4 developers max on the same project at any time it's ideal to work on the same files provided you're not using some ancient low level language which requires compilation of all the code and a single grammar mistake breaks the entire application. True enough, once in awhile this does cause unwanted errors as well, but in general it works incredibly well and helps speed along development just fine. The actual main problem lies in the fact that svn tends to break a lot if different people commit and work on the same svn checkout. Additionally there are a few other things that tend to cause trouble (and svn seems to either way not like sitting on a share, though one of the answers might help in 'fixing' that), but the fact is that all those things are caused by the fact that SVN and GIT are all based around the idea of individual developers working on their own local copies which does not fit well with the tightly knitted development style on a shared code base as we are doing.

After talking this through we concluded that we could imagine a simpler less advanced source control system more suited to this development style (e.g. a fully automatic revision tracking system like the experience a user has with google drive documents + additionally some form of 'tagging' files) and we assumed that others must have thought of this as well and that's where this question was coming from. And if you think that our development style is bad than allow me to point out that our company is currently able to reach an efficiency of around 3-5x as high as similar bigger web application development companies we compete with (and the choice not to grow is a conscious one) and, yes, this setup is one of the reasons helping in reaching that efficiency, because no matter how beautiful the popular version control systems are: they add a lot of overhead. As I was saying in one of the comments below, for us to set up local development environments would mean that around 50x4=200 different development applications would have to be set up to run. That would mean on each development system 3 different IIS instances (due to a limitation of an 'addon' we're using and the necessity of 3 different versions of this 'addon'), one apache/tomcat instance and an apache/jetty instance. Plus separated over these 5 instances for each developer a different subset of 50 applications. (And I don't want to even think how to get these 5 instances running alongside eachother and what to do about cross application requests) Comparing all that against the current setup where we only need three different instances of each application (development, staging and production) it's simply not justifiable. And I didn't even mention that only around 2 or 3 people in the company know how to set up these instances... which btw is a mess (for new project we have migrated away from this mess already, but for all the old projects which are still supported that's irrelevant).

I attempted making this question as generic as possible to prevent it from only applying to us, but the kind of reactions some people are giving in some of the answers and comments are just incredibly arrogant. Honestly, we have thought about this and I asked a fairly specific question. And if the question is asking for an alternative to svn/git it's just so presumptuous to come and give answers: "use svn"/"use git" or "the question made me cry". And no offence@David W. cause unlike some others I recognize that you honestly tried to help, but I seriously just considered quitting stackoverflow after seeing those comments. </rant>

Either way, I still hope somebody will be able to point me to some radically different approaches to source control, but from the looks of it that's not going to be the case. Might be that one day I will end up writing it myself, but right now I don't have the time for that, so I was kinda hoping somebody else had already done that.

Answer 1

The other answers have already pointed out that in general multiple people working on one server simultaneously can be problematic. I agree - however, you write that this works for you, so I won't argue about that.

That said, my solution for version control would be:

• Have one repository per project, with three branches (dev, staging,prod).
• On each server, the branch corresponding to the server's role (dev/staging/prod) is always checked out.

That way, multiple people can work on one server. They just commit as usual, coordinating with any colleagues who happen to be working on the same system. This is a bit easier with Git, as it makes it easier to only commit a subset of the changes in the working copy, but it would work with SVN as well.

Code is exchanged between the systems by merging. If a new feature is done in "dev", the "dev" code can be merged into "staging", and then "staging" into "prod". Tags can be used to identify versions that are suitable for merging to the next stage - so you would not just merge the latest "dev" into "staging", but a tag "featureX-dev" that points to an older revision on branch "dev".

If you use Git, local branches could be useful if you must interrupt your work and have work in progress . You could then commit your work in progress to a local, scratch branch, leaving the working copy (and the main branch) clean so others can work on the same server. Of course, this requires temporarily checking out your scratch branch, so you'd need to coordinate with anyone else working on the same system.

Answer 2

Let me tell you that if you only work with 4 developers max on the same project at any time it's ideal to work on the same files

Lie. Even for 2 developers around single common (really common as mapped network drive) code-base you can't guarantee, that they will not modify the same file at the same time and overwrite foreign changes (except using ancient "lock and wait" model), thus - have a lot of headache

The actual main problem lies in the fact that svn tends to break a lot if different people commit and work on the same svn checkout

The actual main problem is not Subversion (which doesn't break anything, if used in a Right Way (tm)) - but untrained users, using a microscope for nailing

for us to set up local development environments would mean that around 50x4=200 different development applications would have to be set up to run

You can (have) change your workflow to using Subversion properly without building LDE. Just add layer of local workplaces (where devs edit code in personal WCs) and post-commit hook on server for updating Server Development Environment (and, probably, start using branches if update+merge before commit /for outdated WC/ will annoy developers)

we could imagine a simpler less advanced source control system more suited to this development style

Well, it's WebDAV - linear versioning without anything on top of this. For end-user it will be same shared drive

Answer 3

I was wondering whether there are any alternatives out there which work well on central network shares

I'm afraid, but real alternative is "changing your lazy workflow and habits" - you want (now) to combine incompatible things

"50-100 different projects" is just 50-100 repositories (on central location) and 50-100 Working Copies on Dev Boxes (some work for creating this is required, yes, but it's one-time operation) and ONE (two in case of DVCS - push added) additional action for developer in development-process later - commit.

It's minimal overhead for replaced "Unmanaged Anarchy" with well-defined and manageable process of development and fair price

Answer 4

If there is no server to regulate modifications, there isn't much you can do to prevent two people from modifying the same file at the same time. It's why you shouldn't use the file:// protocol in Subversion when you have more than one person working on a project. You should never use it on a net share.

For Subversion, you can use the svnserve process to create a lightweight server on the system containing the share. It's simple and quick. It's even possible to set it up as a Windows service. Once done, you can use the svn:// protocol and the svnserve process will regulate the changes.

Git may really shine in this instance. With Git, you normally have a master repository where you push and pull changes, but that's really using Git much like Subversion and you don't gain the full power of Git that way.

Git allows you to have multiple repositories, each pulling and pushing changes to each other. In fact, you don't even need a master Git repository at all. And, this is why Git might be the best way for you to handle your setup.

You and your coworkers can all have their own private Git repositories. You do your own checking in and out. You sync with each other via email. No server. No Windows share. No problems with two people trying to change the same file at the same time.

I use Dropbox to store my Git repository, so I have my repository available at home and at work.

Word 'o Warning: If you use Dropbox like this, you can't have two people pushing to this Dropbox Git repository at once. You can have multiple people do pulls, but not pushes.

However, this Dropbox Git repo isn't shared between me and others. It's mine and only mine. I use it on my computer at work, go home, and then continue to work from home. I sync that repository with other people in my project using email as explained above.