Using GIT with Eclipse and repos' backup

Question

I'm totally new to 'Distribution version control system'(DVCS) and 'Centralized version control system'(CVCS). Somehow I understood the difference between them. Presently, in my office we are using CVS repository which is very old and I'm asked to upgrade to any new version. I don't know other than backing up CVS repos(/usr/local/cvsroot directory) and creating cvs users and I'll do this from webmin tool. The developers connect to cvs repositories and share their projects using Eclipse application.

I reviewed SVN which has some advantages and disadvantages over CVS. I would like to choose CVCS instead DVCS repository so that I'll have the repository in one place(because I'm thinking it's easy for me to backup repositories). SVN is CVCS based but I'm looking for something advanced which has only advantages over cvs not the limitations.

I heard GIT is best of all and is DVCS based repo. Finally I would like to use git but have no knowledge of it that how it works. My problem with this is it's DVCS which I didn't understand properly. Because it is said DVCS has no centralized repository and each user will have their own set of repositories on their local machine which could be shared among other users but isn't there any option to save all the users repos to a server which eases to backup centrally?. Eclipse is strictly used in my office and I'm thinking if it's possible to connect to git with eclipse(if it has plugin or anything should be done).

Finally what I'm trying to ask is if anybody could explain me how actually GIT works. I'm expecting totally practical explanation intead theory using eclipse and so on that if it's possible to connect to git and is there a way to store all repos centrally if not should I got to each machine and backup the repos?. If git doesn't suit for me then I will have to try svn. I'm totally confused!.

Thanks!

Answer 1

I'm totally new to 'Distribution version control system'(DVCS) and 'Centralized version control system'(CVCS). Somehow I understood the difference between them. Presently, in my office we are using CVS repository which is very old and I'm asked to upgrade to any new version. I don't know other than backing up CVS repos(/usr/local/cvsroot directory) and creating cvs users and I'll do this from webmin tool.

I strongly advice to get lot of experience on both CVS and the new VCS before you try to do a repo conversion. I did this three times (CVS->SVN, CVS->Git->Hg, SVN->Hg), and it was not a fun job, and you need detail knowledge both of CVS and the target tool (and the converting tool). Especially the CVS->AnythingOther part was problematic because there was a lot of reorganizing to do.

The developers connect to cvs repositories and share their projects using Eclipse application.

SVN, Git and Hg have Eclipse plugins, but I can't say anything about them, since I don't use them. But when your fellow developers use eclipse as the only CVS client, this point can be a big problem when the other plugins doesn't work good enough. This point is especially problematic, since the replacement of well-known tools can very easy lead to emotic reactions.

I reviewed SVN which has some advantages and disadvantages over CVS. I would like to choose CVCS instead DVCS repository so that I'll have the repository in one place(because I'm thinking it's easy for me to backup repositories).

You can use a centralized workflow with any DVCS, but you are not enforced to use the centralized one. Here we have a central Hg server, where the developers push the finished work. The centralized workflow basically consist of a central server with the shared repos wehere everyone can pull from and push to.

I would recommend SVN only if your local work flow depends on file locking, a feature which does not exist in a DVCS (at least none that I know of). In our company we use SVN for unmergeable files (CAD files), where we must be sure that there is only one editing these files. For new projects we use Hg.

I heard GIT is best of all and is DVCS based repo.

Git is the most popular one. I'm not saying that Git is bad, but there are other good tools on the field. Look at SCM choice for a new user? for a SVN vs. Git vs. Mercurial shootout.

Finally what I'm trying to ask is if anybody could explain me how actually GIT works.

http://hginit.com and http://gitimmersion.com are good tutorials for Hg and Git.

I'm expecting totally practical explanation intead theory using eclipse and so on that if it's possible to connect to git and is there a way to store all repos centrally if not should I got to each machine and backup the repos?.

http://www.vogella.de/articles/EGit/article.html and http://www.vogella.de/articles/Mercurial/article.html cover the Git and Hg Eclipse plugins.

Answer 2

The big advantage of DVCS over CVCS is the following:

• Developers can work on the code without being connected to the main repository (checkout, branch, change code, commit, etc.)
• As soon they are happy with the changes, they push their code to the main repository
• To make sure their code does not drift apart from the main repository, they update often so the "untouched" code on their local repository remains the same as on the main repository

So where is the main repository located?
This depends on the development team. They have to agree on one (e.g. github), so everyone knows about it.

Note: git eclipse plugin -> egit

Answer 3

When I moved a team from CVS to SVN, almost everyone in the office was thrilled: getting something close to changesets was wonderful, no more endless tagging before and after every checkin, and having some vaguely tolerable "move" functionality was great. The CVS options for "move" were awful and bad, and SVN made the downsides small enough to warrant renaming files as needed. We managed to throw away most of our custom Makefile recipes because they weren't needed any longer, SVN was that much better.

Not all users got the hang of 'directory as branches' and 'directory as tags' -- tags were too mutable, and branches didn't really feel like a separate development track. (Those users were good at CVS; I imagine I'd be rather upset if someone swapped out my text editor for a newfangled IDE that does almost everything better, but my fingers don't know.)

BUT, SVN still felt a little like the dark ages compared to the bright new shiny world of git. I understand SVN finally has merge tracking, which would help immensely, but last I checked it still didn't have much support for offline work, which is a nice giant feature from git.

SVN really delivers on its goal of being "CVS done right". But that's as far as it goes.

I suggest spending more time with git. You could create something almost like your central repository using a bare repository for git. Then configure ssh accounts for all your developers and get started.

You might find it helpful to nominate one person to 'own' the main repository (think of Linus Torvalds), but it can be an immense burden on one person (think of Linus Torvalds :). That one person could do all the work of git pull and fixing minor conflicts in a local working tree, then git push to the bare repository on the server for every one else to pull from again. Each developer could do this job individually, and probably each should, but you may find it helpful for administrative reasons to run all checkins to the 'main tree' through one or a handful of more experienced developers.