Developing with Version Control

By: Zerhash

Developing in a group setting and even just individually can be a tedious and annoying process. Taking a direction on a problem can lead to wasted time and irrecoverable code. Better yet, the possibility of an unexpected shutdown of your computer can result in lost files. Version Control makes work easier to develop either way.

In an environment where a simple mistake can cripple code, such as C, it is nearly impossible for multiple people to develop a file or let alone a few files at the same time. It would be required that everybody gets their file to a compilable state at the same time, then test at the same time as well. This is slow work, especially when some people may be doing touch ups that require regular updates.

I am going to be looking at two solutions to this with very similar software, Subversion and Git.

They commonality amongst most version control systems is that they provide somewhere to store the old code, while you work on the new code. When you commit, it saves the information. For the majority of the systems they save information by diff. Only the changes get sent, as it is often more compressed than sending the full file every time. As well it makes it easy to see the differences between a file at different stages of its life cycle.

Subversion

Is a popular version control system created in 1999 as a successor of CVS (Concurrent Versions System). CVS functioned on the principle of, someone checks out their file and works on it. When it is checked out the file is locked on the server and nobody could edit it. This was difficult for many reasons, especially if someone didnt unlock the file for technical or greedy purposes. This would put a lot of production to a stand still.

Subversion is based on having a centralized repository. A place where everybody commits the code to. People can work on the same file at the same time as the changes get merged so long as the files are not in conflict. This is convenient, however only works for text files. It is illogical to expect that at the binary level. Word files, are binary, but they have provided some solutions around it.

Cyberarmy, uses subversion to host its many projects, including dinah. The protocol works with apache so viewing the repository with your browser is possible.

Git

A distributed version control system, which in my opinion, is very similar to Hg and Mercurial. It calls itself the “fast version control system” which i can see as well. The biggest advantage to this system is that it works as a non-centralized distributed version control system. There is no requirement for the Internet as everything can be done locally.

Unlike subversion, when you make a commit it commits locally. So you can go back in time without having to worry about the main server being around. Central repositories are able to be done, however it isn’t quite as complex as setting up a SVN repository. All you need is to create a repo somewhere and you push and pull your commits to it. So you can commit until you are happy with your code, then push it to the main repository. Someone reviews your code, then commits it to the main repository. At that point its available for everyone who does an update from it.

Conclusion

Both systems are good and they have their purposes. I have my own repository with SVN set up with https. I like this set up, but as of lately i’ve been working on more and more restricted network machines. So getting my repositories is near impossible. Working with Git has worked like a charm. For those just starting out, I would look into Git before SVN as you can apply it sooner. For those who have been developing with nothing, I feel your pain.

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16