Using CVS with Webdynpro

[Former Member]

Hi,

can anyone share some experiences with this scenario? I'm especially interested in how well conflicts in webdynpro-dcs are handled.

thanks in advance

[Former Member · Accepted solution]

Hello,

i didn't use plain CVS in a project, but Serena PVCS, which is a commercial tool that in many aspects behaves like CVS.

Sadly, I have to tell you that the integration has not been too great, the pessimistic locking approach those tools need is not well supported/understood by NWDS team synchronization.

It happened quite often that generated code got committed, although the ignore options where set. When you check out a WD for editing, NWDS knows, that you need dependant files to be checked out as well, but was not able to do so automatically.

Overall, it worked, but caused a lot of trouble.

If you have any chance, try to use DTR.

2nd option: We made quite good experience with SVN. SVN doesn't require pessimistic locking , so you can just start to develop and all files are written and synchronized at once. It can get difficult though, if you have a larger team (>3) working on the same DCs, because keeping the merge in synch with your actual development is tricky. But I still prefer this over CVS.

Jan

[Former Member · Accepted solution]

>

> 2nd option: We made quite good experience with SVN. SVN doesn't require pessimistic locking , so you can just start to develop and all files are written and synchronized at once. It can get difficult though, if you have a larger team (>3) working on the same DCs, because keeping the merge in synch with your actual development is tricky. But I still prefer this over CVS.
> 

thanks for your input.

I think we'd give SVN a try. Can you share some experience on whats tricky when merging?

[Former Member · Accepted solution]

Hi Stefan.

like Daniel said, its a bunch of META and generated files. If two developers work on the same DC, lets say in a shared common WDComponent or a Model, you will not only have to merge the current file you are working on, but also the generated and dependant files to the exact same version. Otherwise precompiling fails and you wont be able to build the DC.

We didn't find a perfect solution other then separating responsibilities, keeping interfaces between Model/Comp and DCs stable, communicate a lot and delete the gen-dirs several times a day. I you have a small team in one room, its nothing that cant be done by common sense.

Jan

[Former Member · Accepted solution]

did you try flagging the gen-folders with svn-ignore?

Frankly, I already know this doesnt work too well with some normal eclipse implementations.

[Former Member · Accepted solution]

ignore is not the issue here. You have a local wd-file with corresponding java and xml files in gen. if you now merge the wd-file with the repo, wd-file and java/meta are out of sync. You need to build the DC (run precompile/compile).

Consider this with multiple Components and shared dependencies. your local precompile will fail which often leads to a deadlock that can only be solved by deleting the gen dirs, open/closing the project, restarting eclipse, ...

[Former Member · Accepted solution]

I'm working with SVN and NWDI also on separate projects and it depends... if you are working in small team (less than 10 peoples) and there are no release managers but only one man who decide when the upload to production system can be done than I thin it is better to use svn. NDWI is better for big companies and many programmers, because you do your release when it is ready and release manager decides when to make a deploy on a production system. We have used CVS before, but we migrate it to SVN, it's better with it.

Storing dc on svn is a little tricky. But if you do it once you will used to it. You must not store any directories that are generated by web dynpro because they usually gets you a lot of conflicts.

In SVN you must store the main folder of dc's and all subfolders with your projects.

it will look like this: .\<name>\DCs\<company>\<project path>\_comp

exmpl: 0\DCs\sap.com\ess\cat\_comp

One of the problems using svn with development components is that you must download your sources in an exact location (like .dtc in 7.0 and <workspace_name>.jdt in 7.1 ...I'm not sure about jdt extension)

If you store a web dynpro projects than you must ignore following folders:

bin, gen*. This folders are auto generated by web dynpro. And if you put them in the repository and commit them every time you will have conflicts all the time when somebody try's to update the project.

If you store different project(resource, portal application, etc...), folders are not the same, except bin folder (or the folder that you set for class file generation) you must always ignore it, because it is not needed in svn. I'm currently working with 7.0 and these are the folders that I have seen. I don't have 7.1 installed now, but I remember that there were other folder that are auto generated too and must be ignored.

When download projects from svn for the first time, you must go through all of them and repair structure and class path, then rebuild them. They will generate all the necessery files and you can start working.

And another thing... if you want to work with svn it is better to understand what is the meta information that sap files contains, because if there is a need of merging some files someone must know what he is doing. It is not so complex, but if you don't merge some files correctly then you can receive an errors in eclipse.

[Former Member · Accepted solution]

Hi,

NWDI is better for "big teams"? - Please, explain me how!

@Stefan: I will find the hyperlinks and will check if I can forward an internal document I made about this.

Regards,

Daniel

[Former Member · Accepted solution]

If you plan for using NWDI only for source storage and versioning it is better to use svn. NWDI is not only code storage it is part of application lifecycle management. You are not the only one that is working on the project, there are other people and not only developers. If you have a small team and only one client that you working with and make updates only on his production server thing are not so complex. You can track all the changes from your developers and plan all the releases easily. Now imagine you have more developers and 20 or more productive systems. The best case is all production servers to have the same version of netweaver, but they usually doesn't. Service packs are different, one thing works on one machine, one does not. Finally you will be forced to install another software just to track your releases. Or another variant is just every developer who makes some change in his code to deploy the last version on production system. I don't think this is a good solution. And it is not a necessity that your release manager must be developer. But in your case one must be. And what if you have 5 different projects and you have projects on portal 7.0 and 7.1? Then someone must have on his computer installed two NWDS - 7.0 and 7.1 and download all projects rebuild them all and after that start to think what project should be deployed on what server. I really don't like NWDI, because it is very slow and I think it can be optimized a lot. That is why we are using for our project svn, but the project is not big one and for now we are able to manage it.

[Former Member · Accepted solution]

Don't get confused, the decsission is not "SVN or NWDI". It's "SVN or DTR". The Design Time Reporsitory is the Source Control Module of NWDI and can be used stand-alone. It behaves very CVS-like and is in my opinion the best choice for DC development.

[Former Member · Accepted solution]

can it be installed Standalone too?

do we have to use CMS and all dependency import work when only using DTR? or on the same matter: how do we create SCs then?

[Former Member · Accepted solution]

Well, I've been working with Java for quite a while now. I never had problems in my automated Build's propagation using some Continuous Integration tool.

You can do all the stuff using simple Ant scripts. Deploy, FTP, even send workflows by email. I mean, its not even that hard to create a process that will work for your customer with minimal effort.

But I'm cool with the fact I wouldn't be choosing anything else than NWDI (DTR) when working with WDP. I used to work in a 20 developers team in SVN, two different projects sharing the same database, model objects and business layer. SVN, CI and selenium did all the trick.

[Former Member]

Hi,

I've used SVN to work with ISA (CRM), which is Struts. It makes a lot more sense than using NWDI and NWAS, since both are totally slow. I'm sure that the whole performance gain and Team capabilities were capped on top, since we were using a very fast source control tool which allows merging and a lightweight java container (Jetty).

I guess if you ever worked with NWDI you will know all it's problems. I like the something of its concept.. but very little.

But I think you should ask "WHY" use SVN / CVS while working with WDP? - I mean, WDP is based on META, so you wont be able to perform MERGE's. The Compoment Dependency in WDP doesn't help at all. And I don't think you can run WDP outside NWAS, so you are already tied to use the elephant.

I would recommend using NWDI, if you can. Most of all, do some extensive research on "HOW" to create your Components and their dependencies. When to use Java Beans instead of relating Context Attributes, when to Embed Models in a Component or keep them in a different DC. - Even this way I think it will still be slow, but acceptable.

Hope it helps,

Daniel

[Former Member]

>

> Hi, 
> 
> I've used SVN to work with ISA (CRM), which is Struts. It makes a lot more sense than using NWDI and NWAS, since both are totally slow. I'm sure that the whole performance gain and Team capabilities were capped on top, since we were using a very fast source control tool which allows merging and a lightweight java container (Jetty).
> 

how did you manage to assemble the components? we were unable to extract the SCAs provided by SAP for eCommerce 5 properly without NWDI.

>

> I guess if you ever worked with NWDI you will know all it's problems. I like the something of its concept.. but very little. 
> 
> But I think you should ask "WHY" use SVN / CVS while working with WDP? - I mean, WDP is based on META, so you wont be able to perform MERGE's. The Compoment Dependency in WDP doesn't help at all. And I don't think you can run WDP outside NWAS, so you are already tied to use the elephant.

we have trouble setting it up (again). performance is awful, configuration is complicated and we already spent days looking for the source of the error. we had similar problems in other projects with other NWDI releases. when imports take ages, it slows down productivity tremendously.

I think merging is not so relevant for us since you cant do it with DTR either. Since we dont use transport chains we could just build centrally.