cvs vs. clearcase?
I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike <[EMAIL PROTECTED]> writes: > I have a director asking why I don't want to user the company's > clear case server. One item I mentioned is the lack of integration > into unix tools and the lack of a unix client. Are these good/valid > reasons? What are other reasons? Economic: - Cost per seat of support of Clearcase can be high - Cost of View servers and Vob servers can be high - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. Political: - Many people do not trust the security of running a system that needs to modify the operational integrity of the kernel on both their clients and servers in order to operate effectively with Clearcase. - Clearcase is a primarily US-based SCM system while CVS is used by a large part of the international community. Technical: - If you already have a highly integrated environment using CVS, you should be able to write a technical paper on the cost of the transition from CVS to Clearcase for your particular area. - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. - Adding additional features to CVS is possible as you have the source, forcing IBM to change anything for you is not as easy. Ideological: - The future of Open Source development looks bright and you wish to attract Open Source community into joint development with one or more of your projects. Social: - Your developers will quit if they are forced to use Clearcase. - Your developers will require many hours or re-education if they are forced to transition to a new SCM system and they do not like change. Examples: Has the director already paid for a license for clear case for all of your users? Has the director already paid for the infrastructure for adding additional view servers and vob servers to your environment to handle the projects currently managed under CVS? Has the director already added to his forecast and budget for growth of your development team and accounted for the marginal cost of using a propietary source control system? There are ideological reasons to use an Open Source source control system over a proprietary source control system. You can search the web for ideas on that line. There are at least two major versions of CVS supported actively on the net (CVS and CVSNT) and all of the *BSD communities use CVS for development, so CVS is not going to fall into disuse anytime soon. Is your company able to get an agreement to escrow the source code for ClearCase should the vendor (IBM now owns Rational which purchased Pure which purchased Atria that originally wrote ClearCase) choose not to continue to provide the product at some future date? If your projects closely coordinate with open source projects, you might be interested in having your workers use a single 'cvs' for both tasks. Clear case has 'reasonable' support for many commercial versions of UNIX (Solaris, HP/UX and AIX for example). They probably have some kind of support for GNU/Linux boxes and no support for FreeBSD, NetBSD and OpenBSD. It is reasonable to look at the various SCM tools available for Linux http://www.linuxmafia.com/faq/Apps/scm.html It is reasonable to do a survey of the capabilities of CVS: http://cvsbook.red-bean.com/ http://www.cvshome.org/ If you have a large invested use of 'cvs' in your shop, then transition to clear case could be expensive. Certainly there are different administration problems with the extra hardware needed for View and Vob servers and the cost of doing distributed development using MultiSite can be high in terms of dollars and man-hours of effort. If you have lots of binary files to be managed by your SCM, then you probably want to avoid using CVS as it is not well suited for that task and there are other alternatives possible. If you do not yet have a large body of CVS use or other technical or ideological reasons for choosing CVS, then you may wish to consider if this is really a fight you wish to pursue. CVS is fairly old and other tools such as subversion are in the wings to address some of its weaknesses. Whatever arguments you choose, you will probably need to revisit them every few years, so be sure to keep track of what are the political, technical, economic and social issues that drive the use of a particular SCM system in your area. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBq1Qg3x41pRYZE/gRAnYtAKDYWFrT+nTZbwLq0MtcNiEHHm5m6wCfaZaI 1qqoERrtBtXTu9I1FG0aapA= =YaaZ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
Mike <[EMAIL PROTECTED]> wrote: > I have a director asking why I don't want to user the company's > clear case server. One item I mentioned is the lack of integration > into unix tools and the lack of a unix client. Are these good/valid > reasons? What are other reasons? No Unix client ? I thought there was one, you'd better research that a little more. I need more context here. Is the rest of the company already using ClearCase, supported by the IT staff and with a pais up license ? Would you be working on joint projects ? If so, get the staff to install the client on all your machines, get yourself trained, join the team and add the bullet point to your resume. If however *you* would be in charge of administering CC locally, the picture changes. You can draft an estimate of conversion costs, including: licenses, training, staffing. CC doesn't run itself. You didn't list the alternatives. What rev control system would be using if CC wasn't in the picture ? -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
These are not valid reasons. Here's why: - ClearCase MVFS is a filesystem that offers the same access to Unix tools as any other filesystem. They need not be ported to specialized environments to run under ClearCase. - ClearCase clients are available on several flavors of Unix, including Solaris, HP-UX, AIX, Linux, and others. Also, ClearCase views can be mounted via NFS so that unsupported systems can also use them. Consider being open-minded about ClearCase. Its capabilities are far superior to CVS, and it even supports concurrent development. On Nov 29, 2004, at 5:25 AM, [EMAIL PROTECTED] wrote: I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
On Nov 29, 2004, at 8:53 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike <[EMAIL PROTECTED]> writes: I have a director asking why I don't want to user the company's clear case server. One item I mentioned is the lack of integration into unix tools and the lack of a unix client. Are these good/valid reasons? What are other reasons? Economic: - Cost per seat of support of Clearcase can be high For 50 seats, the price of initial licensing is about $4k/seat, then $400/yr thereafter. After the first year, its cost is in the noise floor. - Cost of View servers and Vob servers can be high But not significantly higher than the cost of the file servers you'd need to buy otherwise. Also, ClearCase offers enough opportunities for disk space sharing that you will likely need fewer of them. On the other hand, your network must be rock solid, and it must be fast; this may be an issue for some shops. If you're worried about this, consider using ClearCase snapshot views, which are more like CVS workspaces. - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. This is true. Political: - Many people do not trust the security of running a system that needs to modify the operational integrity of the kernel on both their clients and servers in order to operate effectively with Clearcase. The drivers supplied with ClearCase undergo a commercial grade quality assurance program, and their reliability is comparable to the kernel. The application itself also undergoes a commercial grade quality assurance program, a claim that CVS cannot make. - Clearcase is a primarily US-based SCM system while CVS is used by a large part of the international community. Depends on where you draw the bar that qualifies "primarily". Last I heard, 30%-40% of ClearCase revenue comes from outside the USA. It's used heavily in India, Israel, and the Arab world. Technical: - If you already have a highly integrated environment using CVS, you should be able to write a technical paper on the cost of the transition from CVS to Clearcase for your particular area. I was able to convert a CVS-based shop to ClearCase, including some 400k lines of code in a week, and supplied daily conversions while the development groups switched over. - Technical training/expertise of the support staff favors CVS, so you need to train or hire Clearcase administrators. This is true. - Adding additional features to CVS is possible as you have the source, forcing IBM to change anything for you is not as easy. On the other hand, some believe that ClearCase does everything already. :-) It certainly supplies most of the features requested in this forum to be implemented in CVS. Also keep in mind that such claims as the above are only theoretical; source code doesn't make up for bad design, and I have personally have been unable to implement certain capabilities well with CVS because its architecture simply wasn't compatible with the problem I needed to solve. Ideological: - The future of Open Source development looks bright and you wish to attract Open Source community into joint development with one or more of your projects. Many companies don't care about this... Social: - Your developers will quit if they are forced to use Clearcase. In practice I doubt this is true. I know of two cases where the developers would have been ecstatic to use anything other than CVS. Ask around before making this claim. - Your developers will require many hours or re-education if they are forced to transition to a new SCM system and they do not like change. I had developers productive with ClearCase after a 1-hour lecture and 30 minutes' practice. The learning curve for the everyday stuff is pretty low. The learning curve for ClearCase in total is high, but most users don't need to access its complete functionality. Is your company able to get an agreement to escrow the source code for ClearCase should the vendor (IBM now owns Rational which purchased Pure which purchased Atria that originally wrote ClearCase) choose not to continue to provide the product at some future date? There's little need for this. Once you have purchased ClearCase licenses, they don't expire. So as long as you have compatible hardware and OS, you can access ClearCase. If maintenance stops for whatever reason (by the customer's choosing or not) then it's relatively easy to pluck out the data and metadata to convert to something else. If you have a large invested use of 'cvs' in your shop, then transition to clear case could be expensive. Certainly there are different administration problems with the extra hardware needed for View and Vob servers and the cost of doing distributed development using MultiSite can be high in terms of dollars and man-hours of effor
RE: cvs vs. clearcase?
Title: cvs vs. clearcase? Ouch. I first met Clearcase in a solely Unix environment. With a couple of config files to set up views everything ran perfectly and seamlessly off the command line. It worked by using symbolic links for all unchanged files to the repository somehow (it was 6 years ago and I never really got into how it worked). If you changed a file you simply removed the symlink and copied the file into your working directory to edit it. Since using Clearcase I have met a few different versions of version control systems, but Clearcase remains one of my favourites. We used it to have different branches for slightly different products. We set up views to pull common functionality from a single branch, and then all other code came from the relevant product branch if it differed from the core code but from the core code otherwise. You could set up wildcards int he branch specification. It was really cool. Anyway, the argument that it does not integrate well with Unix is not valid. It may be a bit more tricky to set up, but it does work really well. Alastair. From: [EMAIL PROTECTED] on behalf of MikeSent: Mon 29/11/2004 13:25To: [EMAIL PROTECTED]Subject: cvs vs. clearcase? I have a director asking why I don't want to user the company'sclear case server. One item I mentioned is the lack of integrationinto unix tools and the lack of a unix client. Are these good/validreasons? What are other reasons? Mike___Info-cvs mailing list[EMAIL PROTECTED]http://lists.gnu.org/mailman/listinfo/info-cvs This e-mail has been scanned for all viruses by Star Internet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
Mark D. Baushke wrote: - Adding additional features to CVS is possible as you have the source, forcing IBM to change anything for you is not as easy. How many times do you alter the source code to provide site specific functionality? And what do you do when the next version of CVS comes out? There are at least two major versions of CVS supported actively on the net (CVS and CVSNT) and all of the *BSD communities use CVS for development, so CVS is not going to fall into disuse anytime soon. Is your company able to get an agreement to escrow the source code for ClearCase should the vendor (IBM now owns Rational which purchased Pure which purchased Atria that originally wrote ClearCase) choose not to continue to provide the product at some future date? Actually Apollo (and old workstation company) created Clearcase but it was called DSEE (Distributed Software Engineering Environment). HP purchased Apollo and the engineers working on DSEE did not want to see their creation disappear. So they left HP/Apollo and formed Atria. If you have lots of binary files to be managed by your SCM, then you probably want to avoid using CVS as it is not well suited for that task and there are other alternatives possible. If you care at all about versioning of directories then you might consider Clearcase. AFAICT CVS does not version directories, which is handy and which is often confusing to users at first, but with a small amount of thought it makes perfect sense. And considering Clearcase's installed base I highly doubt that it'll be going away anytime soon. -- I went to a general store, but they wouldn't let me buy anything specific. begin:vcard fn:Andrew DeFaria n:DeFaria;Andrew adr:;;6265 Kelez Court;San Jose;California;95120-2819;United States email;internet:[EMAIL PROTECTED] tel;work:408-979-4311 tel;fax:408-997-6900 tel;home:408-997-6900 x-mozilla-html:TRUE url:http://defaria.com version:2.1 end:vcard ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs vs. clearcase?
On Tue, 21 Dec 2004, Andrew DeFaria wrote: > How many times do you alter the source code to provide site specific > functionality? And what do you do when the next version of CVS comes out? You merge! On a previous job, I maintained site-specific extensions to WinCVS, and merged them against new public releases. (In one case, the merge was quite difficult, because the framework for handling columns in the file browsing view was rewritten, so the columns I added had to be retargetted to that framework). Most of the merges were easy though. Of course, I used CVS for the merging. These days, I'd use my Meta-CVS, which has better support for tracking third-party sources. A normal branch can be used as a vendor branch, and the import tool ``mcvs grab'' figures out renames (and looks at symbolic link reconfigurations and execute permission changes too). So merging is possible even if you have locally renamed or moved some files, and the new snapshot does the same. -- Meta-CVS: the working replacement for CVS that has been stable for two years. It versions the directory structure, symbolic links and execute permissions. It figures out renaming on import. Plus it babysits the kids and does light housekeeping! http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
CVS vs ClearCase, was RE: cvs -n update vs cvs diff
How should a working directory be used? What should be done within it, and what should be done in a separate working directory? And how should the status of the files within one's working directory be determined? I'm used to ClearCase, where a person worked within a dynamic view and you could build, label (tag), branch, merge and do everything within the same workspace. How does CVS differ from that model? It would really help me out if somebody could provide some direction on this. I keep stumbling over the differences between how CVS and ClearCase handles these thing. -Original Message- From: [EMAIL PROTECTED] [mailto:woods@;weird.com] Sent: Tuesday, October 22, 2002 2:14 PM To: Kris Thielemans Cc: [EMAIL PROTECTED] Subject: RE: cvs -n update vs cvs diff [ On Tuesday, October 22, 2002 at 16:17:25 (+0100), Kris Thielemans wrote: ] > Subject: RE: cvs -n update vs cvs diff > > > By default, diff compares against the version you checked out. If you > > want to compare against the top of the tree, you have to specify -r > > HEAD. > > this has given me some problems before. I think it would be helpful for a > lot of users to make this *very* explicit in the usage message output by > 'cvs diff --help' (and of course in the manual). That would more properly be "cvs -H diff", btw, as per the message from "cvs -?": (specify -H followed by a command name for command-specific help) That would suggest then that your users are working under some nearly fundamental misconceptions about how a working directory is used and how the status of the files within it can be determined. I don't think adding more info to the usage message would help override their misconceptions. You'll have to fix this problem at its root. It may also suggest that your users are not really very aware of what the rest of their team might be doing too, and that's another problem best solved at the root where it starts :-) -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS vs ClearCase, was cvs -n update vs cvs diff
On Tue, 22 Oct 2002, Johnson, Susan wrote: > I'm used to ClearCase, where a person worked within a > dynamic view and you could build, label (tag), branch, > merge and do everything within the same workspace. > > How does CVS differ from that model? In that it does not have dynamic views; only the sandbox model. A mirror image of what is in the repository is replicated in the local filesystem. This is known as a working copy, but most people use the ``sandbox'' jargon. On the other hand, ClearCase is integrated into operating systems at the filesystem level. When you look at a dynamic view, you are not looking at regular files on your hard drive, but at an MVFS (ClearCase multi version filesystem) mount. If the version control system is integrated into your operating system kernel, it can do things much differently from a sandbox-based version control system. With the sandbox model, you still do everything within the same workspace, but you have a replica of the objects from version control. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS vs ClearCase, was RE: cvs -n update vs cvs diff
--- "Johnson, Susan" <[EMAIL PROTECTED]> wrote: > I'm used to ClearCase, where a person worked within > a > dynamic view and you could build, label (tag), > branch, > merge and do everything within the same workspace. > > How does CVS differ from that model? This is pretty much how I use CVS. One big difference between ClearCase's dynamic views and CVS is that, for files that are not checked out (ClearCase meaning), when someone checks it in, you'll see the changes automatically by default. CVS's working directories work more like ClearCase's sandboxes (I think this is the right term). Personally, I never liked the default dynamic view behaviour since it meant less control over what I'm working with (eg someone can break my build at an inconvenient time). At one point, I toyed around with the idea of changing the config spec so that LATEST meant 'now' (ClearCase meaning). Doing so would've given me the benefits of dynamic views (eg file system access to the repo) with the benefits of static (I like this terminology better) views (eg control over what's in my working directory). HTH, Noel __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS vs ClearCase, was RE: cvs -n update vs cvs diff
[ On Tuesday, October 22, 2002 at 14:01:12 (-0700), Johnson, Susan wrote: ] > Subject: CVS vs ClearCase, was RE: cvs -n update vs cvs diff > > How should a working directory be used? What should > be done within it, and what should be done in a > separate working directory? Well, that's really entirely up to you and your project and how (if it's a multi-person project) your team works together. For example if you're working on a relatively large program and you have rather diverse responsibilities to the project you might have several working directories "active" simultaneously, one for each major change you're working on, whether it be some new feature, or fixes on release branch(es), etc. Persons responsible for building releases and testing might have working directories "open" on each release branch as well as the main development branch(es) (which might be the trunk, depending on how you use branches in your project). > And how should the status of the files within one's > working directory be determined? With "cvs status", "cvs -n update", "cvs diff", etc. of course! ;-) > I'm used to ClearCase, where a person worked within a > dynamic view and you could build, label (tag), branch, > merge and do everything within the same workspace. > > How does CVS differ from that model? I believe the answer, at least on a conceptual level, is: not very much. The "view" in a given working directory in CVS can be dynamically changed without acquiring a new workspace. However as I suggest above you might actually want several workspaces if you're doing rather un-related things simultaneously. -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
