Transitioning against the general control of the source used in the organization

The company I work for uses exclusively Clearcase. I believe that you should not try to learn and use it, because my project will not involve too many people (maximum 3 people), and this will not be associated with bizarre development. How do I convince my manager to use a separate source control for this when they raise the point of “supported IT and uniform source control through the company” against my offer? Or is this particular point valid and should I go with Clearcase?

Thanks...

PS: I was thinking about using Subversion.

+4
source share
10 answers

If this is a standard company, then there should be people in the company who know this, which can help you start with it. They should be able to configure your IDE to work with it and make everything as seamless as possible for you. You do not need to learn something crazy to use it - there must be clear instructions.

If this is not the case, you do not get the benefits of "supported IT and consistent version control through the company," and it does not matter what you use.

After completing this process, if you can make the argument that there is a better source of control that will work better through the firm, you should do it. If this is a standard company, this should not be a pain in the neck.

+8
source

First of all, my condolences.

Is Clearcase difficult to learn? If so, I would have thought it was a blow. If not, it might be better for you to just go with the flow and study it.

The 3 people on your team are unlikely to be the ones who maintain the code for the duration of its work, so the argument goes against you.

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

This will depend on your boss and his / her willingness to consider alternatives.

Subversion will certainly be easy to configure and use. I would really like for me to use Clearcase.

But there are many factors against you. Good luck.

+7
source

If I were you, then I would like to use SVN, because I just like it, but just something with development in most cases you need to go with the stream. Just as if you were expanding the scope, and you decided to do it in your own way completely different than the rest of the framework, you would frown at it, even if your path was much better. And what happens if you and your team get on the bus? OK SVN is easy to learn, but there is also a learning curve that can slow down the work of other people continuing your work.

+3
source

You can also see this as an opportunity to learn a new version control system and make yourself more accessible. You can still prefer subversion, you cannot make me change my mind. Since @Erick says that if this is the standard of the company, they should be able to support you, and I hope you can take it into account in your time scale.

+2
source

There is always a proven (albeit risky) approach for your team to use Subversion (as appropriate!) Internally and randomly register with Clearcase.

+2
source

Your argument against Clearcase

  • Not worth learning
  • In my project there would not be too many people would also not include
  • Fancy development flow.

Is it hard to learn? If your company already uses it, you will have many people to ask for help. Since your company already has a clear receipt, you are 80% the clercase administrator. It will be quite simple to create a voob, a project, etc.

In fact, your project is small, so it is important to use the standard internally. We had some interesting projects completed using our standard SCM and some projects without standard SCM. For those using standard SCM, when projects are put off, the code is still secure in the organization. Other products, we lost people and code.

Are you using ClearCase with UCM? This is easier than basic clarity.

+1
source

As I mentioned in “ Is there any reason to use SVN? ”, You cannot just decide to put a new server on the side, especially for sensitive data, such as code sources. At some point, they should be versioned in a central link.

Any server for such persistent and important data should be:

  • funded (you cannot just manage VCS on your workstation, you need a real server)
  • supported (your tasks should be developed, and not manage / troubleshoot your team during the execution of SVN operations).
  • integrated (no problem on this front for SVN)
  • is administered (again, your task is not to manage / control the SVN server)
  • documented (where is your SVN server located? what backup procedures?), is there a backup / DRP server?, ...)

For all these reasons, your manager may consider using the existing infrastructure / support around the main VCS (ClearCase, condolences;)).

But that does not stop you from managing DVCS in the ClearCase snapshot view .

+1
source

I don’t know Clearcase, so I can’t say whether it is good or bad or how it compares with Subversion.

But the whole point of source control is that there should be one repository where everyone knows that they can go to check their code. If one team uses Clearcase, and your team uses Subversion, and the other uses Git, and the other uses CVS, etc., then anyone who wants to check the source code must look for not only ten places, but also must learn to use ten different source code management systems.

If you can't make Subversion clearly better than Clearcase in some important and important way, I would say just bite the bullet and learn Clearcase. If it were me, I would see it as an opportunity to learn something new. After I did this, perhaps I would conclude that Clearcase sucks in a lot of time, and I should try to convince the forces that should switch to something else. Or maybe I would conclude that Clearcase has been the biggest success since the invention of USB. In any case, you now know a little more. If nothing else, this is another bullet to include your resume the next time you look for another job.

+1
source

Do you work full time for this company or is it a one-time project as a contractor?

If this is your full role as an employee, then it's time to buy this Clearcase for Beginners book.

If you want to get the project done quickly, maybe just keep your head up and use Subversion as appropriate. Ask someone to check the finished product in Clearcase when you exit the door.

:)

+1
source

Use DVCS like Mercurial or Git, and create a branch to sync with ClearCase. Your team can work every day using the best tool, but your work products are still available in your organization in the usual way (which is important). Synchronize with ClearCase on a regular basis and consider adding system DVCS log output (e.g. hg log) to a file in the ClearCase branch so people can see more detailed steps if necessary.

DVCS systems are also quite easy to configure, and often they can easily be placed on a network resource or something like that. Since all developers will have a copy of the full tree, it provides a certain amount of built-in backups and backups.

This workflow is not uncommon - gitsvn and hgsvn are both scripts that people have set up to allow them to use these tools themselves, but to synchronize with people in another repository.

0
source

All Articles