3

I am currently playing with the idea of pitching DSCM to management in my company. We currently use the full vertical TFS stack (SCM, Bug Tracking, Project Management etc.) - however I want to specifically target the source control (as I don't think retraining QA with something like Redmine would be achievable).

Probably the biggest issue here is re-training a very large amount of developers to use the new SCM (and this includes the distributed train of thought) - which is probably not feasible at all. There needs to be some form of skills migration with the new system: this is where GIT fails horribly, as that would take months to catch on (and we are not a little startup shop - this is a very large company with real commitments).

The next issue is the fact that we currently require check-ins to be associated with a real bug or task (work item) - I doubt management would bite if we couldn't control this. Ideally the developer machines should be zero-configuration, i.e. it should prevent 'illegal' pushes even if you just have the bare-bones SCM client installed. Being able to update TFS work items would also be a big plus - even if I had to write custom code, but once again this should be controlled by the central repository and not on developer machines.

I know that in the long run DSCM alleviates many of the problems that we are facing day-to-day, but we can't afford the time of developers having merge issues or such. For example, my first GIT merge took me a good 2 days to figure out, because I was so used to the TFS mindset. This isn't acceptable when real deadlines are taken into consideration.

Tooling is a big concern: it's incredibly easy to push in a merge marked-up file directly back into source control; which would result in a build failure - TFS doesn't allow you to do anything silly like this.

Finally, having 'nice things' to show would probably help the pitch. We have a review process, showing off GitHub FI Commit Comments would be a strong example of why this stuff could be better - however, as stated, GIT is probably really the wrong route to go.

TLDR; I have found most DSCMs to be tools and not frameworks (e.g. GIT is designed to be this); allowing you to easily shoot yourself in the foot - TFS is a framework and that is something valuable in the company.

Has anyone ever tackled these types of issues when migrating to DSCM? What DSCM platforms did you use? What challenges did you face? Do you have any ideas on how this process could be streamlined and almost made painless?

Improve this question
6
  • 1
    Have you taken a look at kiln?
    – Oded
    Sep 19, 2011 at 9:58
  • I should mention that cloud-based solutions are not an option. It needs to be on-premises.
    – Jonathan Dickinson
    Sep 19, 2011 at 10:00
  • @Oded you could make that an answer, it's really helpful and deserves upvotes.
    – Jonathan Dickinson
    Sep 19, 2011 at 10:04
  • See also stackoverflow.com/questions/5683253/…
    – VonC
    Sep 19, 2011 at 10:26
  • 1
    You mentioned pitching the idea of moving from TFS to a DSCM and mentioned many of the possible problems you have identified, however, you have not mentioned your motivations. What are the pros you have identified? I assumes those are the things you should pitch and the others are issues you need to figure out how to overcome. - Perhaps you should ask a specific question for each issues you have identified and a separate discussion for pros and cons of DSCM in general.
    – Danny Varod
    Sep 19, 2011 at 12:54

2 Answers 2

Reset to default
2

Kiln might be a good option for you.

It is based on mercurial and has full support by fog creek and good documentation to boot.

Improve this answer
1
1

I'm a big fan of Github. The hardest part for me with Git was actually setting it up (properly) SSH keys, managing them, etc. It can be a pain, especially for those that are use to a clean wrapper around it like GitHub.

GitHub, of course, is a managed service. However, there is an option of GitHub Firewall Install - basically an on-promise setup of GitHub, which alleviates a lot of that headache, and is fully supported. It doesn't come cheap, but if your organization is willing to shell out for TFS, then I don't see how this wouldn't be a potential option.

As far as getting developers involved, and trained - that's tough. The nice thing about Git is that it's really hard to do permanent damage (but possible). Git allows history re-writing. I'm not fond of that, but it's very useful when something unintentional or unexpected happens. It does require a lot of knowledge of Git to even be able to do that though.

There are GUI wrappers around Git, like Tortoise-Git, that make it more manageable for people that don't like / aren't comfortable with the command line.

Another possible option for you is Veracity. It has built in bug-tracking, etc. It doesn't quite have all of the features of Git - but it has all of the needed ones and then some. Perhaps that's a good thing for your team. It's easy to set up, and is aggressively being developed.

Improve this answer
3
  • Thanks for the veracity link, but the big problem with Git (although I love it for my own stuff) is that we will waste a huge amount of time with bad pushes - time we can't afford.
    – Jonathan Dickinson
    Sep 19, 2011 at 12:53
  • @JonathanDickinson Perhaps developers could work in dev-branches, and a "merge team" would be responsible for merging in the changes correctly? (Just throwing ideas out there).
    – vcsjones
    Sep 19, 2011 at 12:58
  • @JonathanDickinson Danny makes a good point above - what problems are you trying to solve?
    – vcsjones
    Sep 19, 2011 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.