2

Background: we are a small webdevelopment company. We have 5 programmers that produce 70% of the time simple PHP websites (with some MySQL for news / product catalog / etc), and 30% of the time we work on larger projects (often custom-made ERP systems). We have a central server located at the office, use Linux among all users (and the server), and work by simply mounting the server and working in the directories (website projects) we need to work at. This currently works fine. There are two things that make me consider version control:

  • A pretty strong case by numerous websites, people, etc.
  • Potential problems that might arise in the future when the company grows and several people work on one project at the same time.

However, despite having people seen being hammered down when mentioning reasons not to use version control, I have a certain hesitation due to these points:

  • We do a lot of changes, but they are often very small changes.
  • It virtually never happens that we need to reverse a change.
  • We make frequent backups that can be used in case of needing something 'previous'
  • It hardly ever happens that several people work on the same code at the same time. A project generally 'flows' from person to person, as different people are in charge of different development phases (HTML/CSS/PHP/MySQL)
  • When a project is more complicated, we assign it generally to one person.
  • We are pretty swamped with work right now

So I DO see benefits of version control, but I'm just concerned with the overhead it takes when developing a site. I have never used such a system before. And I feel that things are so easy and fast now, that we will lose time when using VC. Checking in, checking out, etc. adds up if you want to make 20 small changes to 20 different sites throughout the day. At least, that's what I think. So my question is: should we switch to VC rather sooner than later, or should we not lose our time on this right now? Is it difficult to learn this? And finally, is GIT significantly more time-consuming (learning & using) than SVN? (I like the non-centralized aspect of GIT, but this is not a necessity).

NOTE: we all code using regular text editors like VIM or jEdit.

Community
  • 1
  • 1
user852091
  • 3,070
  • 5
  • 23
  • 21

4 Answers4

6

With the scenario you have described, version control should be simpler to work with - and thus the overhead should be very low. For instance, with what you're describing, all you'd basically have to do is (example of Git):

  1. Start work: git pull
  2. Do work (normally what you already do)
  3. git add . (in the top level directory)
  4. git commit -m "A quick message saying what you did"
  5. git push

And that's it.

Amber
  • 507,862
  • 82
  • 626
  • 550
  • 2
    I find Git a lot more complex than SVN so ther eis more overhead in learning it from my perspective. That said i agree with Amber... given the workflow you described what she has outlined shoudl be all you need to really know for now. When you need to know more then you can worry about learning about branching/merging, stash, and all the other stuff git offers. – prodigitalson Jul 24 '11 at 01:48
  • This looks awfully simple. Should we not create sub-projects for every site, or can we just group them under one project so we do not need to switch? – user852091 Jul 24 '11 at 01:58
  • @user852091 You may actually find it *easier* to have separate repositories (assuming your projects are normally in separate folders). Setting up git repos isn't hard (`git init --bare` on the server). – Amber Jul 24 '11 at 02:12
  • 2
    Git has more *potential* for complexity (and thus more *power*), but it doesn't *have* to be complex - you can use a subset of its features and keep it very simple. – Amber Jul 24 '11 at 02:51
1

Using a hosted solution such as github or a similar provider, you can be up and running in about 30 minutes and be able to check code in and out. Competency with more advanced features and uses of your VCS will come with time. As you get more comfortable and knowledgeable with VCS, you will even begin to use version-control to help track down bugs faster (git bisect, etc...but don't worry about that now)

JofoCodin
  • 1,965
  • 16
  • 11
1

Even if you decide to use something other than subversion for version control, you would be well advised to read the first three chapters of the subversion book. The commands for all the popular version control systems are not radically different from tool to tool (even when the distribution system is) and it will solidify the day to day details of what using version control means from both the 10000 ft view and the 1 ft view.

It will soon become obvious that using version control doesn't add an appreciable amount of time to your development process. About 20 seconds for a big check-in and 2 to 3 seconds for a small one. Much cheaper than the 20 minutes trying to research archives finding out if there were changes in a module (assuming you have easily grep-able archives of each "build". I know you assume that such a thing never needs to happen, but if you have to do it even once, it may pay for itself in time.

Additionally, without version control, how do you know that you're latest changes aren't just reintroducing issues removed by changes made six months ago? Memory is a good tool, but it is far from infallible.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
1

Use version control, there should be no question.

You say that :

It virtually never happens that we need to reverse a change.

By that logic, nobody should wear a seat-belt since virtually everyone drives safely in their car every day.

At some point you will need to go back to an old change, and having SCM is the only way to do it correctly. Think of SCM as a backup parachute, you hope you never need it, but when something goes wrong, it is a life safer.

You also say that using SCM is too much overhead. I don't see how you can support that statement. For a total beginner, the time to setup and use basic git should only take a few hours, max. After you figure that out, it may add a few seconds or 1 or 2 minutes extra to your day. That's it.

One simple thing you could do is just instruct each developer to install a cron command to check-in your local repository every 1 hour or so and push to your server. Now I don't recommend this, but with a setup like that, you won't really every have to think about SCM again, and then when you need it, it will be there.

Secondly, once you start using an SCM like git, you'll find that it becomes integral to your daily activities. People who don't use SCM might not understand the features that you are missing:

  • Instantly switching between branches of code
  • Undoing temporary changes to any save point, and re-applying later
  • Automatically merging changes from multiple developers
  • Have a record of who was the last one to change a line, or who was the original author
  • Having a temporal record of when/what is changing in your code
  • Being able to synchronize bugs and code commits.
  • etc ...

I hope this convinces you! Good luck.

cmcginty
  • 113,384
  • 42
  • 163
  • 163