EALite integrated into Full version

[duaneC]

We keep our eap file in TFS. The typical case is to open the file to see th UML within, not to change it. The file, under version control is read only, and therefore can't open.

I don't want to check the file out for edit, nor do I want to change the permissons outside of version control - just to read the file. Beside being inconvenient, neither option is good practice.

If the full version can tell that the file is read only, could it not allow the user to choose to read the file in the viewer?

[smendonc]

I don't think EA is the issue here.  An EAP file is an MS-Access database which needs to be read/write for its contents to be viewed either by the full version or EALite.  The check out from TFS unsets the read only flag on the EAP file which makes it available for use by either the full version or Lite versions.

Stan.

[duaneC]

Yes, the full version of EA needs the file to be modifiable, which is unfortunate if you don't want to mess with that level of protection just to read the UML

EALite doesn't care, from the test I just ran. This tells me that the full version of EA could easily handle read only files. As a user, I would rather EA offer to let me open the file read only (in a viewer mode) than to say no.

This is definitely a request for the feature. I did not mean to suggest that anything is broken or that this is an obvious flaw.

[Geert Bellekens]

We keep our eap file in TFS.

There's your mistake, never keep eap file themselves in VC, better to integrate TFS with EA and leave the EAP files read/write.
If you have controlled your whole model it will be effectively read-only for users who haven't checked (a part of) it out.

There is really no sense in keeping your eap file in VC as a diff with a previous version would only give you a bunch of binary crap.

Geert

[duaneC]

I went through the VC setup and ran some experiments. That isn't something I want to repeat. I'm also not thrilled about sticking my network password into a project file - and I am really not thrilled that deleting the password from the settings did not trigger a prompt for a password on the next check out. Providing an invalid password results in a TFS connection failure. Providing no password still allows checkouts. My network password is permanently in the project file, and hopefully only on my local machine - but I wouldn't know.

There are many reasons to keep a file in VC. The ability to diff different versions of human readable text files is just one.

The method I stumbled on in my other post works much better. Associate eap with EALite so that I can take a quick look at read-only files when needed, and run full EA on checked out files on the rare occasions I need to make a mod.

[Paul Lotz]

Geert isn't advocating not using version control.  He's just recommending you version control the packages, not the eap file.  Geert's approach seems to be the recommended one, and it is what we do as well.

We do share our eap files, but that's a different thing.  Also, we release versions in a separate configuration management database.

[duaneC]

Thanks to Paul and Geert. I think the disconnect here (for me) is that the metphore for the project is atypical for us. The eap appears as a single file that is a database file that can have its parts extracted into package files that represent the real artifacts that you would want to save in VS. We are used to makefiles, text based files (like VS solutions or project files) and such.

I definitely see the advantage of the underlying philosophy for more sophisticated users. We (I) use EA as a white board early in development, which is definitely not scalable - thus the recommended approach of importing/exporting the packages.