Level of version control

[jasfranklin]

Hi,

the company I am working for is currently using Enterprise Architect 6.5. Recently it has been decided to start putting our models under version control. The version control system to be used will be a subversion repository. The deploment model that we intent to use is a shared .EAP file that multiple users access over a network folder.
Also, multiple users will be working in the same package. However, the documentation I've gone through seems to indicate that only one user can check out and edit a package at a time, while the other users have to wait until the package is checked in again, before being able to edit. Can this be the case?

Kind regards,

Jason

[thomaskilian]

Makes sense somhow. How would you manage to check in different inconsistent packages? So the key is to split the packages meaningful and distribute responsibilities.

Or maybe you wonder about the term checked out? Each developer can check out, but only one of them may hold the lock for changes to a package. All others will have the r/o package.

[potterm]

Jason,

No I don't think that's strictly true - if you put the SVN working folder on the fileshare and configure the model such that all users are using the same working folder, then I believe you can have shared check-outs across the whole team.  The downside to this is that the SVN check-ins may have to be made under a single user account (i.e. you set-up a group user for SVN, and whenever anybody checks in a package, the SVN version history will show that single user account and not the actual user that performed the check-in).

I recommend you look at the Sparks White paper on version control, which explains all this.  I think it's what they call the "Workgroup Deployment Model".

HTH.

Cheers,
Martin.

[Martin Terreni]

Don't do it to your self. Shared artifacts in VC are a pain in the model . You'll be stcked with merging and all sort of nasty staff.
Better exporting to XMI and checking in-out package by package, may be it will bemore work, but it saves many head aches.

[potterm]

Don't do it to your self. Shared artifacts in VC are a pain in the model . You'll be stcked with merging and all sort of nasty staff.
Better exporting to XMI and checking in-out package by package, may be it will bemore work, but it saves many head aches.

Agree that shared artifacts are a pain in the proverbial but that's not what I'm suggesting.  If you use the workgroup model as proposed in the Sparx whitepaper then merging doesn't come into it - everyone sees the same model and there is only one working copy of each package's XMI file (not one per user), so merging isn't necessary.

[Martin Terreni]

Hooo, I maust have missundertood you. this is what I meant also

[rhurst]

I didn't see the correct answer here. So I'm adding my two cents.
The EAP file is a binary file. As such it is not subject to merging. SVN has facilities to merge text file sources but it has no way to merge binary files.

With that said, an EAP file would have to be checked out with a lock. This means the next person would not be able to work on it until it is checked back in.

[Martin Terreni]

The EAP file is a binary file. As such it is not subject to merging.

The EAP file not, but XMI files from its packages - yes.
You better use VC from within EA and not put EA in version control. Just put the packages in VC from withing EA, so it will be exported to XMI, and then every one can lock them separately.

[potterm]

I didn't see the correct answer here. So I'm adding my two cents.
The EAP file is a binary file. As such it is not subject to merging. SVN has facilities to merge text file sources but it has no way to merge binary files.

With that said, an EAP file would have to be checked out with a lock. This means the next person would not be able to work on it until it is checked back in.

I suggest you read the Sparx Whitepaper on version control, specifically the bit that describes the work-group model then you'll understand what I'm getting at