CVS Vs JDI?
1) Can we use CVS for Netweaver Projects say Webdynpros, Enterprise portal components if so what are the pro's and con's which you faced <b>practically</b>!!!
- when it comes to JDI we source safe the code, build the project and test and transport. How much capable CVS in source safeing Netweaver projects (is there any practical experience?)
> I have WebDynpro Dc's Dc to DC connection which inurn made as an i view in EPortal i want version this scenario till the production,is it possible to acchive same using CVS ( in what extension format i can store my applications is it .sca ,.ear,.par
-Can any one share <b>Practical experience</b> in differentiating CVS and JDI capability ?
Is it possible to source safe Webdynpro Dc's in CVS if so what procedure i can follow till testing and transporting in to Production.
Your help is appreciated
Manohar Sreekanth replied
If you use CVS (instead of JDI) to develop projects with technologies like WebDynpro, you'll face the following consequences:
1) You'll get only the version control functionality from CVS (which corresponds to the DTR part of JDI) - which means you'll have to invent mechanisms to build your projects and manage your codelines on your own. In JDI, these aspects are handled by CBS (plus Build-Plugins) and CMS).
2) Integration of the specific technology (like WebDynpro) with the version-control steps of the development process will not be as good as it is with JDI. For instance, you'll have to figure out what files to add to version control. This becomes particularly difficult in modelling environments like WebDynpro, because they generate a lot of files, some of which are relevant to be placed under version control (since they represent the models) and some are not (since they represent files generated out of the models). With JDI + NWDS, the developer gets an automatic notification on what to add to source-control, which makes this a lot easier.
3) You'll have to develop scripts to build your projects, and figure out the right order to build your projects. While this latter part may be simple for small projects, it becomes increasingly difficult to manage dependencies (to ensure that there are no cycles) and find the right order to build once the number of components increase. This is where JDI (with its Build-Plugins, and its Component Model support) helps by automating all these tasks.
4) If you are an ISV, and you wish to deliver some sources to your customers (for further adaptation), this will have to be managed manually in CVS. With JDI, you get an integrated infrastructure which makes this this very easy to handle (thanks mainly to DTR's distributed versioning functionality).
These are some of the points that immediately come into mind. The main message here is that JDI is more than just a version control tool like CVS - it is an infrastructure that offers services across the different phases of the software development lifecycle.