I work for a small company, which means that at any given time, we could have 3 or 4 different versions of code on developer machines that have not yet been committed to the repository. Nowadays, I would certainly go with a distributed version control system. Setup is faster since you don't need to set up a version control server and everything, all you usually need to do is initialize a certain directory within your development box for version control and you're good to go. They also seem like the way to go these days. If it were 2001, I would recommend a centralized system like Subversion. But it's 2011, everyone is moving to distributed systems and user interfaces and supporting tools tend to get better.
Some suggestions:
Git: Powerful. May take some time to understand but evolves rapidly
Tortoise svn: TortoiseSVN is an easy-to-use SCM / source control software for Microsoft Windows
Darcs: Easy to learn and has all the features you will usually need
Mercurial: Mercurial is a distributed version control system. Mercurial is dedicated to speed and efficiency with a sane user interface. It is written in Python.
All four of them should be available in your Linux-based OS or Windows through the usual package management solutions.
We use TortoiseSVN for our version control system, which gives us the ability to branch/merge without too much difficulty, as well as being able to view the update log or revert our local copies to an earlier revision pretty easily.
we would fall under the group of developers who attempts to keep, at all times, a stable Trunk, and we branch new code and test it before merging it back into the Trunk. We also make an effort to keep "snapshots" of each version release so that, if necessary, we can easily check out an earlier version and re-build it, without incorporating any new features intended for a future release (This is also a great mechanism for tracking down bugs, as you can use earlier versions of code to help determine when a particular bug was first introduced into your code. However, one thing to be careful of is if your application references common code that is maintained separately from your version-ed code, you will need to keep track of that too!).
Deploy your webapp with SVN:
Since it is not always a simple task, so I just point out this artical which may be of interest for your project.
General principle:
Some suggestions:
Git: Powerful. May take some time to understand but evolves rapidly
Tortoise svn: TortoiseSVN is an easy-to-use SCM / source control software for Microsoft Windows
Darcs: Easy to learn and has all the features you will usually need
Mercurial: Mercurial is a distributed version control system. Mercurial is dedicated to speed and efficiency with a sane user interface. It is written in Python.
All four of them should be available in your Linux-based OS or Windows through the usual package management solutions.
We use TortoiseSVN for our version control system, which gives us the ability to branch/merge without too much difficulty, as well as being able to view the update log or revert our local copies to an earlier revision pretty easily.
we would fall under the group of developers who attempts to keep, at all times, a stable Trunk, and we branch new code and test it before merging it back into the Trunk. We also make an effort to keep "snapshots" of each version release so that, if necessary, we can easily check out an earlier version and re-build it, without incorporating any new features intended for a future release (This is also a great mechanism for tracking down bugs, as you can use earlier versions of code to help determine when a particular bug was first introduced into your code. However, one thing to be careful of is if your application references common code that is maintained separately from your version-ed code, you will need to keep track of that too!).
Deploy your webapp with SVN:
Since it is not always a simple task, so I just point out this artical which may be of interest for your project.
General principle:
- Configure Web server ( ie. Apache ) on your development server so that it picks up your checked out working copies as separate subdomains. Using this, you can simply make a checkout of your project and it will automagically be up and running. No need to touch the Apache configuration. You need a DNS wildcard entry so that all subdomains of dev.example.org go to your development server.
- Use dnsmasq so you can achieve the same effect on your own development machine. That way you can develop your web applications locally and you won't need a central development server. In my examples I will be assuming you use subversion for your version control, but it works virtually the same with other version control packages, such as git or bazaar.
No comments:
Post a Comment