At our company we currently all work on one shared network drive. The source code is not under any kind of source control, which for me is a big no-no. I’d love to be able to set up SVN and us all work of separate repositories and just commit back to a trunk or branch, but our tech manager doesn’t agree. The way I see it, there are two major issues:
- The source has no history – if there is a problem, we can’t roll back
- We overwrite each other’s changes if we work on the same file
How do other people manage this situation? Having source control on the network drive is fine, but that doesn’t solve the problem of overwriting each other’s changes does it… And setting everyone up with VMs or local repos doesn’t wash with the tech manager. Would a solutions such as each having their own checkout and then the shared network drive automatically update work? What about slowness in updating – people making a change and having to wait a while before it takes effect probably wouldn’t wash with our tech team, and committing back every tiny change seems a bit silly.
What about other source control (i.e. not SVN) – do you think it would suit us? I’m open to suggestions, except for Visual SourceSafe. Preferably something that integrates well with Eclipse, and is also cross platform (we use a mix of Windows, OSX and Linux), but something that also works well without Eclipse… tall order perhaps?
February 5th, 2010 at 12:05 pm
http://www.joelonsoftware.com/articles/fog0000000332.html
Just use SVN. If your end-goal is to get everyone using source control then you want as few barriers to entry as possible. SVN has the best client tools, and most developers worth their salt know it backwards. Use TortoiseSVN with Windows, and (IMO) Subversive with Eclipse, although it doesn’t handle tree conflicts very well.
Don’t be tempted by the shiny new toys of distributed source control, it’s (mostly) command-line only and designed to solve a problem you don’t have.
February 5th, 2010 at 12:38 pm
Perhaps the title is a little misleading – I don’t mean distributed as Git and non-centralised source control, I mean non-distributed, as in our source code is shared on a network drive.
That’s the biggest problem using SVN – it requires everyone to have their own check out. We have a development server that has the source, which we all work on the network drive. It’s slow and it annoys the hell out of me, but it’s the way we have to do it because I can’t do anything about it. That’s why it presents such a challenge, you follow me?
February 5th, 2010 at 12:52 pm
I do get the frustration of it… that article I linked is meant to address exactly the situation you’re talking about.
So… putting source control aside for the moment, what other steps can you take to improve your process? (Forget about everyone else for the moment). Lets take this “single dev server” thing. What’s stopping you from running your own, local Apache and only “committing” changes back to the network drive when they’re ready for testing?
Never being the guy who breaks the dev machine sounds like a major win to me.
February 5th, 2010 at 1:11 pm
I’ll give it a go, but I think there is quite a few hard coded paths I’d have to fiddle with, plus I’d still have to use the dev server database (mainly because it’s several GB in size, and there’s no versioning in it).
I suppose it’s easy enough to do something like that, but it doesn’t solve the problems for anyone else… I want everyone to benefit, ya see?
I wasn’t sure if there was a way of doing what I wanted, I know using SVN we could solve problem #1, but problem #2 would still exist (overwriting other people’s changes if editing the same file)… I suppose the only solution for #2 is to each use own checkouts… which the tech manager doesn’t want (I don’t understand why not, but hey, I don’t have a choice).
I did scan that article and it did look useful – I think I’ll have a proper read of it when I get a chance, and maybe at some point set up my own local checkout
February 5th, 2010 at 2:51 pm
In /theory/ good practice drives out bad. If it works for you, other people will pick it up. Better to light a candle than curse the darkness. etc etc etc.
It seems we need to keep stepping back until we find the smallest unit of work you can do that will improve your process, and therefore your company’s process. If you’ve got hard-coded paths, then extract them into a config file. It’s a baby step, but it’s a prerequisite for all kinds of other good things – local dev servers, one-step build, continuous integration, automated testing… even source control, which isn’t going to work terribly well if everyone’s constantly tweaking (and checking back in) hard-coded magic values.
February 5th, 2010 at 4:46 pm
Good plan David – thank you, you’ve been very helpful as always
February 5th, 2010 at 5:03 pm
Well I’m not sure how useful the advice is going to be when you try it out in the real world… but please write more posts as you progress – I’m very interested in how you get on.