using subversion for version control

[wcoenen]

I have succesfully setup version control of EA packages with subversion by following the steps in the version control white paper.

However, I'm a bit baffled by the fact that the svn repository now only contains the project packages in xml format, but no project file that can be opened by EA. It seems you need the original (unversioned!) .eap file to be able to work on the packages in the working copy.

I assume I'm missing something here, because this seems very strange. At this point it makes more sense to just manually put the .eap files under version control, and to ignore the version control integration in EA.

[sbockheim]

You need to setup a subversion working folder on the new client computer. Then configure a version control settings in a ea for that working folder. Then you can use the get package feature under package control to pull down the xml from subversion into a new eap.

let me know if you need more specific steps.

Scott

[wcoenen]

OK, I see now that it does make sense to do version control at the package level, and to let people pull these packages into their private ea "project" as needed. I was a bit confused because that wasn't what I expected.

[Jan Pacovsky]

That's right, but still - you don't have version control of project related things (that aren't stored in any package). For example project issues, glossary, etc.

My final solution I've set up is: version control of all packages, one shared EAP with all project-related stuff. If you're online you work with shared EAP. If you want to work offline, you have to create your own private copy of shared EAP. After you are online again you commit your changes into version control repository and then you can delete our private copy of EAP. Final step is to open shared EAP and update it from version control repository.