Going against the common source control used in the organisation_问答_开发者

The company I work for exclusively uses Clearcase. I feel it is not worth the effort to learn and use it as my project would not involve too many people(max of upto 3 people), neither would it involve fancy development flow. How do I convince my manager on using a separat开发者_如何学运维e source control for this when they bring up the point of "IT supported and uniform source control through out the company" against my suggestion? Or is that particular point valid and I should go with Clearcase?

Thanks...

PS: I was thinking of using Subversion.

If it's the company standard, then there should be people in the company that know it that can help you get started with it. They should be able to set up your particular IDE to work with it, and make everything as seamless as possible for you. You shouldn't have to learn anything crazy in order to use it - there should be clear instructions.

If there's not, then you're not getting the benefit of "IT supported and uniform source control through out the company" and it makes no difference what you use.

After working through this process, if an argument can be made that there's a better source control that would work better through the firm, you should make it. If it's a company standard, it shouldn't be a pain in the neck to use.

First of all, my condolences.

Is Clearcase that difficult to learn? If yes, I'd consider that a strike against it. If not, you might be better off just going with the flow and learning it.

The 3 people on your team aren't likely to be the ones that maintain the code over its software life, so that argument goes against you as well.

How big is the organization? It's easier for 3 people to learn Clearcase than for X to learn Subversion.

It would depend a lot on your boss and his/her willingness to consider alternatives.

Subversion would certainly be easy to set up and use. I'd hate to be using Clearcase myself.

But there are a lot of factors against you. Good luck.

If I were you then I'd want to use SVN because I just love it but just like anything with developement most of the time you have to go with the flow. Same as if you were extending a framework and you decided to do it your own way completely different to the rest of the framwork it would be frowned upon even if your way was much better. Also what would happen if you and your team got hit by a bus? OK SVN is easy to learn but there is still a learning curve that could slow down other people continuing your work.

You could also view this as a chance to learn a new source control system and make yourself more marketable. You could still prefer subversion, you can't be forced to change your opinion. As @Erick says if this is the company standard they should be able to support you and I'd hope you'd be able to get this factored into your timescales.

There's always the tried & true (albeit risky) approach of having your team use Subversion (how appropriate!) within itself and making the occasional show check-in to Clearcase.

Your argument against Clearcase are

it is not worth the effort to learn
my project would not involve too many people neither would it involve
fancy development flow.

Is it difficult to learn? If your company already using it, you will have many people to ask help from. Since your company already have clearcase, you are 80% done with clercase admin works. It will be fairly simple to create vobs, project etc.

In fact your project is small makes it more important to use standard within company. We had some fancy projects done using our standard SCM and some projects without the standard SCM. For the one which used standard SCM, when the projects is scrapped, the code is still safe with in organization. Other products, we lost people and code.

Are you using ClearCase with UCM? It is simpler than base clearcase.

As I mentioned in "Are There Any Reasons To Still Use SVN?", you can't just decide to put a new server on the side, especially for sensitive data like code sources. At some point, they need to be versioned in a central referential.

Any server for that kind of persistent and important data should be:

funded (you can't just manage a VCS on your workstation, you need an actual server)
supported (your jobs is to develop, not to manage /troubleshoot your team in term of SVN operations)
integrated (no problem on that front for SVN)
administrated (again, your job isn't to manage/monitor the SVN server)
documented (where is your SVN server?, what are the backup procedures?, is there any backup/DRP server?, ...)

For all those reasons, your manager might consider leveraging the existing infrastructure/support around the main VCS (ClearCase, condolences ;) ).

^{But that won't prevent you to manage a DVCS within a ClearCase snapshot view though.}

I don't know Clearcase, so I can't say whether it's good or bad or how it compares to Subversion.

But the whole point of source control is that there's supposed to be a single repository where everyone knows they can go to check out their code. If one team uses Clearcase and your team uses Subversion and another uses Git and another uses CVS, etc etc, then anyone wanting to check out source code not only has to look in ten places, but they have to learn to use ten different source code control systems.

Unless you can make a case that Subversion is clearly better than Clearcase in some relevant and important way, I'd say just bite the bullet and learn Clearcase. If it was me, I'd see it as an opportunity to learn something new. After I did, maybe I'd conclude that Clearcase sucks big time and I should try to convince the powers that be to switch to something else. Or maybe I'd conclude that Clearcase was the greatest advance since the invention of USB. Either way, you now know a little more. If nothing else, it's one more bullet to put on your resume the next time you go looking for another job.

Are you working full-time for this company or is this a one-off project as a contractor?

If it's your full-time role as an employee then it's time to buy that "Clearcase for Beginners" book.

If you're looking to deliver a project quickly, then perhaps just keep your head down and use Subversion as an expedient. Ask someone to check the finished article into Clearcase as you run out of the door.

Use a DVCS like Mercurial or Git and make a branch of it to keep synced up with ClearCase. Your team can do the day to day work using a better tool but your organization still has your work products accessible the usual way (which is important). Sync up with ClearCase on a regular basis, and consider adding the output of your systems DVCS log (eg hg log) to a file in the ClearCase branch, so people can see the more granular steps if needed.

DVCS systems are also usually pretty easy to set up, and often can be easily hosted on a network share or something like that. Since all developers will have a copy of the full tree it provides a certain amount of built in backup and redundancy.

This workflow is not uncommon -- gitsvn and hgsvn are both scripts people have set up to let them use those tools by themselves but sync up with folks on another repository.