Version control system


I’m sorry if this is not the right place for this question. Please
feel free to point me in the right direction.

Also take into consideration that we have never used a version control
system so my questions might just be due to lack of knowledge and/or
understanding as of how to use the VCS.

Is there a version control system (be it git, TortoiseSVN, other…)
that will be able to take care of the following scenario?

Having a ‘vanilla’ version of an application we have 3 customers, each
with enough changes to their version of the application that no
version can be merged back to the vanilla one, hence ending up with 4
versions: the vanilla one plus 3 others, one per customer.

We need a VCS that will allow us to make changes to the main ‘vanilla’
version and propagate those changes to the other versions and, better
yet, to propagate those changes selectively, meaning to only 1, or 2,
or the 3 other versions on demand.

Thanks in advance.

On Apr 10, 3:25 am, pepe [email protected] wrote:

that will be able to take care of the following scenario?

git is pretty smart at merging stuff between branches (way more so
than svn which would end up being a bit of a nightmare in this case).
I’d bear in mind that even with git helping you you are increasing
your maintenance burden significantly - everytime you add a new
feature or fix a bug you need to be taking into account the 4
variations of the app and how the differences between them might
interact with the change you’re making. If you can manage it it may
make your life easier to keep one codebase but make each deployment of
your app more configurable.


On 10 April 2010 03:25, pepe [email protected] wrote:

Also take into consideration that we have never used a version control
system so my questions might just be due to lack of knowledge and/or
understanding as of how to use the VCS.

Well, distributed version control is going to be your friend here, but
you are going from a standing start to pretty much the most
complicated use of it.

Personally, I’m a Mercurial fan, but Git is very similar. Either way,
both tools allow developers to maintain their own clones of a central
repository, and to make as many commits as they like to give them a
safety net as they work. At whatever interval (normally for me, it’s
when a “feature” is working and passing tests) their local changes are
pushed up to the repository (and merged if necessary, but if they’ve
been doing lots of little commits, the merge is often done for you).

At that point, cloning out features to the other branches would need
to be done (probably by a dedicated person who knows the individual
systems well). “propagate those changes selectively” is almost
certainly going to mean a large level of manual intervention, but
again, this is much easier to decipher with the incremental commits
that become the signature of DVCS.

Check out for a very good “getting started” guide for
I use a “Turnkey Linux” server for my Mercurial machine, but you can
install it on anything and configure yourself. The benefit of the
Turnkey machine is that you get up and running in about 15mins, and
can play with a few different systems for comparison.
Revision Control | TurnKey GNU/Linux

Thanks guys.

Based on what I’ve read so far about VCSs and especially about git I
know that I can ‘fork’/‘clone’ the repository but I still didn’t get
the answer (or I am too thick to get it) that I am looking for.

Fred, I thought branches are just used for development that later on
have to be merged to the master/trunk. If that is the case a branch
would not be a ‘version’/‘fork’ from the main vanilla version because
in the end it would end up merging. I might have misunderstood what
you were saying?

I also understand that any change to the code would have to be
determined to be a ‘vanilla’ feature or a specific one to the
client(s) using a particular version of the application.

What I need is to know if it is possible to ‘push’ out mods from the
vanilla version to the other ones and which VCS would allow that. I am
very new to this so I might not understand how to do it yet but I
need sort of a yes/no answer to at least know if that is possible, and
optionally if it can be more or less automated. Once I have that
answer it would just be a matter of getting deep into learning the

Thanks so much guys.


To echo what others have said here you are going to want to use a
distributed version control system for this and the two most popular
are Git and Mercurial.

Both do what you want equally well but Mercurial is (IMO) simpler to
learn and use as it has some implicit assumptions that Git does not.
There is am O’Reilly book on Mercurial and a nice APress book on Git.
I would read these before you deploy to decide which system more fits
the features you want.

Personally, I use Mercurial as I am not on a large team with
complicated n-way branch/merge scenarios. If I were then I would
prefer Git. As with all things in life there is a trade off between
complexity and simplicity. If Mercurial does what you need you will
find a smaller learning curve to get “good” at using it.

I believe you would effectively want a main “branch” for the base
product and an individual branch for each customer version. After you
update the main branch with new features you should be able to pull
those changes into the customer specific branches and rectify any
issues that would effect individual customer implementations.

On Apr 10, 2:58 pm, pepe [email protected] wrote:

you were saying?
How you use branches is up to you - nothing is going to get merged
unless you ask it to. Using shortlived branches for the purpose of
developing a particular feature is a common strategy but that’s just a
particular way of working - branches can be long lived too. (Eg the
rails git repository has a 2.3.stable branch, 2.2.stable branch, and
at some point will have a 3.0 stable branch. Work usually happens on
master with specific changes being backported when necessary).


Very good point Fred.

Thank you all for all your comments. I really appreciate it.

On Apr 10, 2:25 pm, Frederick C. [email protected]

Excellent Michael. Thank you very much for your comments.