Value of using Git with ClearCase, AccuRev or Perforce? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 6 years ago.

I am interested in the value (or lack thereof) of using a traditional SCM product (ClearCase, AccuRev, Perforce, etc.) along with Git for large projects with distributed teams.

Is there a significant value-add in terms of increased visibility into team activities? Control of branching and merging? Access control and security? Release engineering? Other factors?

Or is it better to Git by itself? Or is there an open source SCM that would be equivalent to the commercial products mentioned above?

Thanks.

Answer 1

Use as few systems as you can get away with. If you don't see an advantage in using anything other than git alone, then just use git alone.

Most projects use just one VCS (e.g. git or Subversion) and can do everything they need to do (branching, ..) so unless you have a requirement you know of which is unusual, you can be pretty certain that one product will do everything you need.

Answer 2

Integrating Git with ClearCase or SVN isn't something I am looking for at the moment, mainly because a Git repo cannot keep the same kind of data (binaries) or volume (number/size of files) than traditional centralized repos.
See "What are the Git limits?".

I am trying to introduce Git right now in a corporate ClearCase-SVN environment, as a stand-alone alternative.

While the speed, private commits and merge features are very much appreciated, I am asked to solve real issues in term of:

• centralization: central repositories are still mandatories, to act as reference for many teams to synchronize their code to
• modularization: there is no way to create just one Vob (ClearCase) or one Subversion repo and start putting everything in it: each git repo needs to be much fine-grained in order to add a coherent value when tagging or branching (those operations concern the all Git repo, not a subdirectory within said repo).
• authentication: each user is referenced in a LDAP and I need to come up with prereceive hooks in order to have at least one commit made with the right user.name config (i.e. a user.name equals to the common name cn in the LDAP of our company). (a bit like the gitolite script 'contrib/update.email-check', but for user.name, not for email).
• right access: gitolite is a huge help here to get very precise ACL for those central repos.
  But using ssh private/public keys also means having private keys with pass-phrase (mandatory according to our security team), and that isn't trivial to integrate with Hudson or other tools.

In short, I still find Git better, but since I am in charge of implementing its installation/administration, I fully agree with my previous analysis made in the SO question "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?" ;).

Answer 3

There is value.

1. Use flexibility and convenience of cheap local branching to facilitate developer work flow in your local (machine) environment, use the centralized system for easy control of role based permissions and conglomeration of large numbers of files.

2. Developer task-based branching stays in the distributed system and keeps centralized history cleaner.

3. Centralized systems can be used to off load large binary assets from distributed systems.

There is cost.

1. Supporting/training for a hybrid environment.

2. Requires locating/maintaining a translation layer between systems.