Our v9.1D AppBuilders start in a directory on a network drive "P:\application\src". I thought we could have the same setup in Architect where our developers have their own workspace and project (plus project settings, preferences, etc.) but all the projects points to the same network directory so the same programs are available.
So I set up a project that uses "P:\application\src" as its working directory. But when I import my project into another workspace, it creates copies of programs from P:\application\src in the 2nd workspace's project. If I try to create another project that uses "P:\application\src" as its working directory, none of the programs in P:\application\src appear in the resources view.
If projects can't work from a shared depository of programs, I need suggestions on how to organise our development environment. Do I need to use the team programming and CVS mentioned in the Architect online help, version control software like Subversion/Subclipse or something else entirely?
You should think of the workspace as each developer's private sandbox. Set the PROPATH to point back to the common code repository for dependencies which are not currently being worked on, but put only the current work in the workspace. After all, you don't want to have a developer make a change that breaks a progam and have that in your shared code, do you?
There are a couple of types of mport. You probaby choose import files into project which copies the files. This isn't what you want usually. You were probably thinking of "import project" which just builds a refernece to the project. Or you can use linked directories, which links an individual folder as part of a project.
Normally, I'd recommended proper source code control like Roundtable, CVS, SVN, or git instead of shared directories. Pick whichever product works for you. In this setup, all your source code lives in the repository, including the project configuration files like .project and .propath files. Each developer has a local copy and updates it from the source control server whenever necessary.
Shared directories in Eclipse can work, but you will be forced to refresh whenever you need to pickup changes done by someone else. In this setup, you can either keep the .project and .propath files with the source code, or you can have each developer setup their own project and propath and used linked directories. Going this route requires each developer setup their propath and build envrionment which duplicates work. Linked directories are limiting since some version control software doesn't support them, and OEA imposes some restrictions on the build settings when using linked folders and classes.
The major drawback to working off a network is performance. The OEA plugins read r-code for content assistance and build dependencies, and Eclipse does its own reading of file information. Having local copies avoids this, but introduces the requirement to periodically update.
I tried importing archive file, existing project and file system but they all put local copies of programs in the project.
I think what we want is for our directory P:\application\src to be a repository but as you said, it's best to use some source code control to make it so. (I think I used 'shared directory' incorrectly). So for the moment I've added the src directory to the propath and we'll manually copy new finished programs to it. That's okay for now because we've only started converting programs to .NET so each developer is working on their programs.
But I'll get my manager to look at proper SCM asap. SVN seems popular plus it's free, which will make my boss happy, but it's not easy to choose which version as there're so many!
Subversion is excellent and you can use the Subclipse add-in for Eclipse/Architect
Subversion is excellent and you can use the Subclipse add-in for Eclipse/Architect
Perforce and the P4WSAD plugin are a great alternative as well.
Subversion? What's wrong with a Linux based hand written system based on chmod that sort of vaguely works & only occasionally overwrites all your work?
ROFL!! Good point - subversion doesn't eat your code if you try to check it in..
Vom 04.10. - 15.10.2010 bin ich nicht im Büro erreichbar. Bitte haben Sie Verständnis, dass ich Ihre Email nicht zeitnah beantworte.
In dringenden Fällen wenden Sie sich bitte an Herrn Fechner (mailto:mike.fechner@consultingwerk.de).
Mit freundlichen Grüßen / Kind regards
Marko Rüterbories