Can SVN and RTC access a common folder to sync with the latest code change
Hi,
Has anyone come accross a situation where both SVN and RTC accessing a shared folder, syncing with the folder to get the latest code changes. (Not a one time activity the sync should happen always)
- SVN will put the latest code into a shared folder
-
RTC should look for any update and it should fetch the code if anything new is available and update the streams accordingly.
3 answers
I am pretty sure: No
Usually any IDE only allows one SCM system per item and forces to disconnect.
I don't think there is a sustainable solution to sync both SCM systems and there is no solution for this requirement.
Use only one SCM system or set up a delivery pattern where you deliver the code only at major milestones and share that over the last baseline from before.
I agree with the statement that you'd should only use 1 SCM tool, however in practice there are situations where that's simply not an option, hence my reaction here:
Yes, it can be done. We've done it, but I won't advise to do it bi-directional; one SCM environment is actively maintained, while the other environment only follows the updates.
We used it during a short period of time (max. 3 months) while we were migrating SVN to RTC. We offered the teams a 'Riskless and Effortless'-migration, while the team continued to work in the 'old' environment, until our team setup and configured the 'new' build environment and the build yielded the same build results, before we let the team switch SCM environments from SVN to RTC. Once switched, we'd reverse the synchronization from RTC to SVN, so if the new SCM environment didn't work out, they'd fine all work done in RTC back in SVN. None of the teams switched back to SVN.
We imported the entire SVN repository dumpfile first to retain the history and kept the imported files up-to-date while we were setting up the new build environment in parallel to the existing build environment.
It's a poor-mans version of data synchronization: it will update your files, but it won't spot refactoring; moving files or directories will be seen as 'deleting' the files/directories at one end and 'newly created' files/directories at the other end, thereby breaking the file's history.
Because you're using a shared drive, you also have a migration hazard as in: It is possible to update the file's you're synchronizing between the updates from SVN and the imports into RTC.
Because you're using a shared drive, you also have a migration hazard as in: It is possible to update the file's you're synchronizing between the updates from SVN and the imports into RTC.
You can do it manually using e.g. Tortoise, but when you use e.g. Jenkins you can automatically trigger a script to import the SVN Revision that triggered the Jenkins build to import the updated sandbox to update the associated RTC Workspace using the RTC CLI commands. The details of the SVN Revision can be copied into the check-in and deliver comments of RTC's changeset. You'll get a near 1:1 Revision to changeset migration. Yes, it will happen that a collection of SVN Revisions trigger 1 Jenkins Build. In such cases you copy and concatenate all Revision numbers and text into 1 changeset to keep the traceability.
Setting up your 'shared drive' for this sync is tricky, but can be done. Make sure the SVN Hash file directory (.svn) is in your .jazzignore file.
If you load the RTC Component as the root folder of your sandbox, its .jazz5 directory will be in the root of your sandbox (i.e. parallel the root of your component folder, in any case ensure that its not -in- the root of your component folder), so you don't need to ignore this .jazz5 directory in SVN. In e.g. Tortoise, or through Jenkins, load your files into the root of your component folder, so you need to instruct RTC to ignore the .svn folder.
To prevent (SCM) migration issues, you need to make sure that the 'shared drive' is only accessible by SVN and RTC to prevent file changes outside your SVN repository creeping into your RTC repository.
The component folder will already have files loaded from the RTC Workspace. Tortoise, or Jenkins, will update these files. Acknowledge in your SVN client that you want to update the existing files. The SVN Hashfiles are ignored, so for RTC the files will appear updates as if updated by any IDE/Editor and these updated files will be recognized and imported in RTC.
Using the same setup of your 'shared drive' you can allow RTC to update the sandbox and SVN to detect the changes and import these. Since the RTC Hash files (.jazz5) are -not- in the same directory, you shouldn't have any difficulties.
If you setup your sandbox and you'll load from SVN first and then load RTC into the same sandbox, you'll find that RTC will load its file versions thereby overwriting SVN's perviously loaded files. (your SVN file versions will have moved to the .jazzshed directory IF you've configured RTC to safeguard local changes into its shed... )
The basic question here is why you want to use both svn and jazz scm? RTC has an option to import svn data to RTC. Alternatively you can link svn commits with RTC work items. Both options work well. You can find more information on
Integrating Rational Team Concert and Subversion.