I have a client that uses Subversion for code management. Has anyone ever worked on a project that uses Subversion that can tell me any issues that I will have and any things that I must take into consideration?
Pinned topic Using Subversion for code management
tmparker 120000EHB3516 PostsACCEPTED ANSWER
Re: Using Subversion for code management2013-08-21T15:28:54Z in response to george.baker
I personally don't use any of the source control tools but I have dealt with a few customers who have used subversion. The only issue that comes to mind that I have seen is more of a problem with the studio itself and not specifically HATS. When you have code that compiles in the project, if you have some files that are checked out from subversion and then some new files that you may have created that have not yet been created and checked into subversion, it may give you errors for class not found. I saw this recently and that was the only conclusion we could find. I'm not exactly sure what the issue is with the source control but I do think you have to be aware in case you find some strange and unexpected errors.
Re: Using Subversion for code management2013-08-22T03:23:46Z in response to tmparker
This is good information to know.
Here is the process that we followed that looks most promising, but it has its issues.
First we must want to create a new Subversion repository for our new project, so we do the following (some steps are simplified)
- We Export the old v7.5 version of the project to a workstation file system, e.g. c:\temp
- We open RAD/HATS and create a workspace
- We Import an Existing Workspace, selecting the c:\temp directory and the project within
- We use the option to copy the assets into the workstation
- We Migrate the application from V7.5 to V8.5
- We copy the subdirectories for the project and the EAR back to the directory that has the files under Subversion control and Check into Subversion
Now the V8.5 version is in the Subversion repository. Here are the procedures we use to load it onto each developer's workstation:
- Start RAD/HATS, creating a new workspace
- From Windows Explorer we Import the V8.5 project and EAR file into the workspace directory. We do this so that the files will be tagged for SVN as they are modified in the studio.
- Then we switch back to RAD and File --> Existing Projects into workspace
- Selecting the current workspace, RAD finds the projects. We do not select Copy into existing workspace (they are already there)
- The projects are now installed and ready for work.
After modifying and testing the project we switch to Windows Explorer and Check-in the changed files so that others can use them.
When viewing the project in HATS Project or Navigator view we can see the .svn folders where all of the controls are kept regarding changed files. They are everywhere, causing the HATS Projects view to show folders that are normally hidden when not used, e.g. Struts Pages or /WEB-INF/Web Service Definitions.
It runs on server just fine as I would expect.
When I export for deployment to the server these SVN files are also exported.
Any thoughts if this will ultimately be a problem?
Anyone else have any comments on how we shoudl be working in this type of environment? We do not have the luxury of having Eclipse plug-in to do the work for us.
smithkenny 100000SFNS23 PostsACCEPTED ANSWER
Re: Using Subversion for code management2013-09-19T19:00:29Z in response to george.baker
Subversion was my scm of choice before RTC came along. Subversive is the best plugin to handle it within the RAD IDE. The hot-potato approach you mentioned above should be abandoned. All source should be checked in/out with the Subversive client. Don't use the Windows explorer client to do version control of these assets.
Regarding the subversion files being exported, yes, but they will not affect the running of the application.
As a tip, I highly recommend you add the following files to the .svnignore file:
<hats prjoject>\Web Content\WEB-INF\profiles\resourceUpdate.sts This is a timestamp that will change every time and drive you nuts trying to keep it in sync
<EAR_PROJECT\logs\* (none of the logs should be versioned)