Compare with Control Version and SVN

[Dale McDonald]

I've recently starting using Subversion to control packages and share them with a distributed team. So far the basics seem to work, ie CheckOut, CheckIn, Undo CheckOut.

But I've hit a problem using the Compare with Control Version. If I checkout a package, and make some changes, then use Compare with Control Version, EA seems to pull the latest XMI xml file from SVN and replace the local version. The Compare appears to work fine and shows the differences, BUT when I go to check-in the package, EA cant due to the local XMI being read-only and also not being the locked version.  

To work around the issue, I've use Tortoise to break the lock on the file, then SVN to re-lock the file again to me.  Then I use EA to re-sync the package to match SVN. Noiw I can complete the CheckIn.

Seems like a bug, help please

[shimon]

Is my memory didn't fail me ( i read up in this a few months age and didn't use any on it yet), the procedure for comparing requires a few steps which is documented in the Sparx documentations.

You have to check out the element, save a version of it in the model (create baseline), then take the previous version from SVN and do the compare with the baseline that you saved in the previous step.
To me it sounded pretty dangerous so I wouldn't try it on my production model but would open an additional EAP and play over there.

[qwerty]

Even if you get that running (it will cost you hours of waiting with a fairly complex package) you will be lost with the differences shown. It should be the modelers task to document why they made changes to the model, not the architects task to find it out by making a diff.

q.

[Sam Courtney]

Qwerty makes a great point, this should not be done by the architect during reviews, but he should be guided by the chng request completion done by the developer which would document what chngs were made to the model. The architect can use the previous version to identify prior structure and verify that the new model meets the initial chg request requirements.

If you follow this best practice, you can use branch and merge techniques for the chngs and then modify your production version once you verify it can be done safely after you complete the final quality testing.
 

[Dale McDonald]

The primary reason for using this feature would be for me to confirm what I had changed prior to checking in my changes not for communicating changes to others (But I should try that also).

Our model is an ArchiMate model, not a low level application model, so the amount of change won't typically be overwhelming and Sparx provides a nice compare feature so I wouldn't be walking through XML; the feature highlights elements that I added, or modified.

btw: Branch and Merge isn't supported but with Version Control under Sparx, its a CheckOut/CheckIn pattern.

Seems like its just an issue with the Subversion implementation. I would have thought that Sparx would have copied the subversion XMI to a working/temp version, or kept my changes in a working file.