Which Version Control Schema

[ebeb]

Hi!

Until now, I was working on the EA model alone. I used a single eap file on a SVN repository. I didn't use EA's VC feature and instead commiting changes via the svn client.

Now, we're about to get some new employees and they also want to access and modify the model.

We are a small team, I guess we need access for 4-6 people, and maybe 2-3 persons accessing the model at the same time but presumably different packages.

Now I'm thinking about how to manage that. I read the EA VC white paper (which is a little bit out-dated) and the interesting parts of the help but there are still some questions left.

1.) From my point of view and according to the white paper the "work group" model seems to fit best:

It is envisaged that the size of the work group is small, with high levels of
communication between its members, for example, all working within the same
room.
EA manages edit access to the packages at a work group level, treating each
workstation within a work group as the same user.

Now, I don't understand what exactly "same user" means? How is a user defined? A SVn user or EA user? And what consequences does that behaviour have compared to a multi-user apporach have? Or should I use another shared or maybe even private model?

2.) Then I set up the SVN settings in my EA model. I read about the "package control options". Am I right to say that I need to enable VC for each package I want to have VC? What about the other packages that don't have package control enabled? I could still commit changes using the svn client, could I?

3.) What about having nested packages like:

Code: [Select]

package A
-- package A.1
-- package A.2
package B

Let's say, I enable VC for package A and A.2, what would happen to A.1?

4.) I read that you have to enter an XMI file name. Does EA create a new XMI file containing the package you have selected to be version controlled? If yes, what about the eap file? Is in that case the package beeing deleted from the eap file and moved to the XMI file?

Ok, I think, that's it for now You, see, I got a lot of questions!

I'd be glad if someone could answer them or point me to any documentation that answers my question!

Cheers,

Jan

[Geert Bellekens]

1) I've never used this approach, I don't really see the benefit of having a shared local folder for your files. I think they mean that, according to the version control system there is only one user that checks in/out files, so you wouldn't be able to say who changed what.
I recommend using the shared approach where each user has its own local working folder.
Depending on the size of the team you may also want to consider changing to a DBMS setup. (eap files are renamed MS Access files, and we all know how they behave when a lot of users are connected simultaniously)

2) you control each package seperately in VC. The packages you don't control are NOT controlled by version control. (you cannot add the eap file itself to VC as this would make it readonly for all but the user who checked out the eap file)

3) use the option "save nested packages as stub". If you have controlled each package in the example the xmi for package a will only contain a reference to the existence of package A.1 and A.2, and it will not contain the contents of those subpackages. If you only control A and A.2 then the whole contents of A.1 is contained in the xmi file for A.

4) Yes each package is controlled using an xmi file, but it is not deleted from the database (eap). Every time you check-in/out a file an xmi import/export is done. This has as a result that you better keep the controlled packages as small as possible because it might take quite some time to import/export a large xmi file.

Hope this makes it a bit clearer for you.

Geert

[ebeb]

Thanks, Geert!

Yes, that was very helpful!

1.) How do I enable that shared approach? In the white paper, these approaches are introduced but I can't see clearly what setting I have to make to set this up.

Is it only the private checkbox in the VC settings that needs to be unchecked? Or is there anything else?

I though about DBMS, but it would mean that offline work is not possible. Because we are very often not in the office and it could happen that we don't have online access.

2.) Is it really read only? I use SVN, not ClearCase. A check out doesn't mean that the file is read only. I could still commit a changed eap file behind the back of EA, couldn't I?

Jan

[Geert Bellekens]

Jan,

1.) Yes, just use one eap file on a shared drive and disable the "private" checkbox. BUT, if you want to work offline on a regular basis then I think you better opt for the multiple private models. I use that setup for my hobby project with a remote SVN server and that works fine.

2.) No you are right, it's just EA that forces an exclusive lock when checking out something (and it doesn't allow you to change anything when it isn't checkedout). On the other hand, if all you packages are version controlled then there is no need to version the EAP file, a regular backup should do. (its not like you could see differences between two versions anyway)

Geert

[ebeb]

1.) With multiple private, you mean the private model explained in the white paper, right? That means, we have a eap file in the SVN repository and each user checks out the file as a working copy to a local drive. Or does EA can do the job?
Then, once I check out the file using EA's functionality, EA creates an XMI file, also on the local disk. So far, so good. But what if multiple users change a package ( not even necessarily the same package) and thus the XMI file. Then the user checks in and the XMI file gets imported into the local eap file. This happens on two workstations. how does EA merge back two different eap files to the SVN repository? Binary merge won't be possible.
Is EA able to see that the eap file on the repository was changed since the last check out and will be able to merge?

Ok, and I just though about branching:
5.) Is it possible to branch a package or create a new package as a branch? Here is the use case: I create a model in EA that models a framework or softaware platform that is not supposed to work independently. Once a new customer is acquired, his requirements will be added to the model and thus some things must change. And on the other hand, if the platform will change (due to new customer independant features) we might want to add it to the model.

I know this taks seems a bit complicated but maybe its somehow possible we EA, probably not with VC but some other functionality...

Thanks!

Jan

[Geert Bellekens]

Jan,

1) no multiple private models means each user has its own eap file, that is NOT controlled in the VC. Only the xmi exports are controlled in the VC.

2) branching is very difficult and not supported very well by EA. There have been some topics about branching in EA that might help a bit. Try searching using the search button on the top left of the page.

Geert

[ebeb]

Hi,

I've recently tried the VC model where I have a eap file on a share drive and use SVN to manage package level check outs.

It seems to work quite ok. But I have two things to ask/mention:

1.) In case a package is not VC controlled, it is not controlled at all. I would have expected, that EA limits the write access to a shared file. But If two people open the same file and change something in the same element, the last one who saves something will overwrite any changes of the other.

Is it possible to lock the write access to one person who can grant access by adding a specific access to version control? Should I add all packages or maybe the root package to VC? Or what's the best practice here? I have a lot of 1st level packages (~15) and a lot of sub packages. Wouldn't it be a bit messy to add some sub-packages from time to time as needed?

2.) Maybe this is worth a bug report, but I wanted to discuss this first:
Imagine the scenario I discibed before. Currently I have access via OpenVPN to our Intranet where the share drive is located. Now, frm time to time, the connection is lost. Then EA crashes. It starts by giving a message about not finding the elements in the shared drive, repeating it over and over again until finnaly EA crashes.

Any idea?

Thanks,

Jan

[Geert Bellekens]

Jan,

I think it is a best practice to keep the whole model in VC, including the root package.
If you don't fancy to add each and every package to VC you could start with only the level 1 packages, and then add packages if the need arises. (e.g. you need to work with more people on a package, or the package itself is becoming too big to conveniently checkout/in because it takes too long to import/export the xmi)
I think there is also an option to add a whole branch to VC, but the disadvantage of that is that it creates xmi files that have the ID of the package as name, and not the name of the package, which makes it harder to do anything with those files outside of EA.

About the crashing when EA looses connection to the database: Yes I think its a good idea to file a bug report. There are more elegant ways to handle a situation like that.

Geert