SVN folder with metadata being placed in every folder of the project. Until recently, the problem with this solution was that SVN protocol required an. The solution to the problem is to use an external SVN client to keep track of changes in the NWDS workspace, without Eclipse being aware of it.
The problem is that, unlike the recent NWDS for AS 7.3, the older NWDS for AS 7.0 (in my case 7.0.25) is built on an old Eclipse version 2.1.2, which does not have many SVN plugins. All this, naturally, might get you thinking about using an SVN repository to track changes to your NWDS projects. Moreover, you are not always develop using Development Components (DCs) architecture required by NWDI. Sometimes you just need to be able to revert to or compare a file in your project with its version in the repository. But to setup a fully functioning NWDI is not always an option. Normally, you should take advantage of NetWeaver Developer Infrastructure (NWDI) when developing with Java in NWDS, which takes care of revision control for you (among other things). It takes along whole bunch of unnecessary files, which make it difficult to track anything in SVN-log.In this post I will show how we can setup and work with a popular code source and revision control tool - TortoiseSVN - together with the NetWeaver Developer Studio for AS version 7.0. IMO SVN should serve the user and not the other way around.Īlso branch re-integration never merges only those files that have actually changed.
When keeping bugfixes as "local changes" you have three-way comparison: in "Check for modifications" you can see all the bugfixes in current release, and with WinMerge you can see all the newest trunk-changes (if compare "Release X.Y" with "trunk"-folder)Īlso it seems over-obsessive to keep everything in SVN. WinMerge offers you much finer control over which changes to merge and which not (on file-basis, not commit-basis). It seems much easier to use WinMerge-utility for merging newest bugfixes into some "Release X.Y"-folder, than using tortoise-svn's "branch integration". I find it troublesome to upkeep these bugfixes in branches, and wonder why not store them as "local changes" in some "Release X.Y"-folder (on build-machine)? Can this work, or is branching the only way? Then we receive support requests, and sometimes are forced to make quick bugfixes between releases.
Normally we wait for newest changes to stabilize, then tag subversion version as release, and install than version to customer. We are deploying and upkeeping web-sites to different customers.
0 kommentar(er)
