SVN

[Wishmaster84]

Hi,

I'm placing the model under version control with SVN. This is the first time with an external versioning system and I'm following steps instruction from the user guide.
The repository now contains different folders and a .EAB file. I suppose people that need to work with the same model need to checkout the files from the repository but it is not clear to me how they can import the model in EA.

Thanks,

[Geert Bellekens]

The easiest way to start is to use the same model from the start.

If that is not possible (or something get added later) they can import the xmi files from the svn working folder into their model.
They might need to do a few "Getlatest" operations to get the whole thing after importing the top level package.

I believe there is also an option to import the .eab file, but I don't generally use .eab files at all.

Geert

[Eve]

The eab file basically identifies a top level (as far as version control is concerned) package.  Once you have a lot of packages in version control it becomes hard to identify which ones are top level without it.

Use the Import Branch option to select one of these from the version control and it imports that package and all child packages.

[Wishmaster84]

Hi,

Thanks, I have followed the import a Model Branch... option and I'm able to import all the model with versioned packages. Anyway, all the packages are locked and I'm not able to unlock.
Thanks

[Geert Bellekens]

Hi,

Thanks, I have followed the import a Model Branch... option and I'm able to import all the model with versioned packages. Anyway, all the packages are locked and I'm not able to unlock.
Thanks

You have to do a checkout to unlock the packages.

Geert

[Wishmaster84]

When I checkout the branch i have a warning message saying that the packages are already checked out.

[Geert Bellekens]

Then you either have to check in the packages first (possibly from your other model)
Or you have to res-synch the status to get EA's status to correspond to SVN's status.

Geert

[bknoth2]

It's worth considering using a more robust database to hold the model and not using versioning. The svn process is cumbersome doesn't scale well (in my opinion). We've used Postgres backends for our last few projects and it's much easier (of course, you need to get the Postgres server set up). That's served our purpose well.

If you consider moving on past the svn approach, the more powerful relational databases work well in my experience.

[Geert Bellekens]

It's worth considering using a more robust database to hold the model and not using versioning. The svn process is cumbersome doesn't scale well (in my opinion). We've used Postgres backends for our last few projects and it's much easier (of course, you need to get the Postgres server set up). That's served our purpose well.

If you consider moving on past the svn approach, the more powerful relational databases work well in my experience.

On isn't an alternative for the other. Version control and central databases have different use cases.
Do make sure you choose for version control because of the right use case.

I usually combine version control with central databases.

Geert