General Information on Version Control Software

Hi,

thanks for the input, i would like to leave the question open for a couple of more days to see if there is any other input.


Thanks

Jester

For MS Windows users (I also am, usually) the official distribution that can be dowlnoaded here http://git-scm.com/ is just fine. The page is official and contains also distributions for the other OS'es. Then nice "free" add-on is the on-line book by Scott Chacon "Pro Git" http://git-scm.com/book -- it is mostly command-line oriented, but it explains principles that you need to know also for work with other tools as they are buit on the top of the git core. The first three chapters are enough for the majority of users.

The git gui command and gitk are just fine GUI tools for normal use. Although you may want to use third party GUI tools -- see the references at http://git-scm.com/downloads/guis

For Git and Microsoft Visual Studio, the Visual Studio 2013 supports Git out of the box. The support for older versions has the form of the add-on.

Feedback has been good, thanks all.

Another question
do any of the source control software above  (GIT, mercurial, SVN) support locking? or are they all optimistic?
is locking worthwhile or more inconvenience than it's worth?

As a note, I have only used GIT.

@craisin: Git uses its own internal compressing tool, no worry then (and this would create problem over distribution if it was relying on other 3rd parties (more precisely not integrated) programs

you "have to work out where the changes have been made"!

It does not mean that you have to find where this happened, but that you will manually edit the changes.

Although it might seem slightly frightening at first, it is not the case in real life:
- I forgot to mention an essential part of Git, how it is easy to "branch" the code if you are making important changes, and to be able to switch very easily from one branch to the other: so if you are working on large changes, you will probably "branch" your development and will later merge them into the master branch... at which time of course you will be able to see all the changes involved
- if you get a conflict between your local version and the remote master (common to all participants); you can "hide" (stash) your change, update your local version, then unhide your changes and see how they fit with the new code.

This gives a great freedom to develop, and then later easily merge your changes.

jester: what do you mean "locking"?
This is somewhat used in SVN where you lock the files you are going to change... but in Git you change first and merge later, nobody is locked out of anyfile.
When different people / teams are working in parallel on changes over different sections of code, this will ususually be done thru branching and then later merge.

Branching in SVN is some kind of nightmare, not so in Git

somewhat off topic (maybe)

we have multiple environments

can any of the software listed be used as a monitor to keep all three environments in sync and automatically flag any discrepancies? we have had instances of "immediate" fixes that have been applied directly to prod, doesn't happen often, maybe twice a year, but the person making the fix has not down synced the file(s), which has had some unfavourable consequences when doing another update and the "immediate" fix gets overwritten.

I have a feeling I read in the documentation of GIT that this was possible.
The best place to look at documentation on GIT is at:
http://git-scm.com/book/en/Distributed-Git (Click on the "Chapters" link once the page loads....

Non authoritative comment: I believe it is possible thru branches and I plan to do that... but coming from SVN we are not here yet...

somewhat off topic ... can any of the software listed be used as a monitor to keep all three environments in sync

Actually, this is where Git shines. You possibly do not want to have tool that check if the branches are synchronized. Instead, you can merge one branch to another easily. It is also easy and usual to create a branch for solving a specific problem. The solution can be merged to whatever branch later, this means to your dev, preprod, and prod.

Have a look at "Use gitk to understand git" by Joshua Flanagan:
part 1 -- http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand-git/
part 2 -- http://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand-git-merge-and-rebase/

The workflow is usually organized more systematically -- have a look here http://git-scm.com/book/en/Git-Branching-Branching-Workflows

I would like to thank everyone for their input; as this was more informational than technical there is no "correct" answer so don't be offended if your answer is "assisted"

there were three contributors, all will be awarded a share of the points.


thanks again.

B-) Glad we could help. Thx for the grade and points.