How do you organize your Delphi projects?
Kyle A. Miller
-------------
We are migrating our VC system to StarTeam, and I want to verify our
thinking on how ST projects are organized.
The Delphi IDE supplies the current project name as a new ST project
name. This implies it's best to have one StarTeam project per Delphi
project, but I thought I read somewhere that it is not best to think of
ST organization that way. ST projects should act as a grouping of
related applications and code.
The organization migrating has, like most companies, a set of code that
is general enough to reuse with any application, components specific to
the application suite, and a file directory hierarchy containing the
application suite code including shared code.
My initial thinking is that the general use code (libraries and such)
should reside in a ST project. All of the application suite code
including the suite components should be in its own ST project.
Is grouping the best answer or should there be a ST project for each
Delphi project?
Ryan McGinty
> Delphi project?
I have our apps' complete structures under one project per app, meaning help
files, tests, source for 10 or so modules, etc. It works perfectly.
I then have a project for our application framework and another for components,
both of which are shared amongst different products. What I CAN'T tell you
is what to do with the shared code as far as having some of that shared code
in your application project. I am a little confused by that myself since
the frameworks stuff is NOT in the folder structure... I just haven't had
time to sit down and read about it more to find out... Hope this helps some.
I would say to definitely keep everything related to one whole product together
(all the the unique info for that product - not the shared stuff).
Ryan
Kyle A. Miller
> I have our apps' complete structures under one project per app, meaning
> help files, tests, source for 10 or so modules, etc. It works perfectly.
If I understand you correctly, you have one ST project for each Delphi
application. Right?
Ryan McGinty
> application. Right?
Yes, and each application has a number of Delphi projects.
Ryan
Fabio Scognamiglio
each one of the ST project map with a Delphi projects.
it is correct?
we have a different situation, one ST Project with multiple delphi projects organized in dirs.
Each directory map with a Delphi Projects. Each application EXE is part of a suite.
some application share common code that reside into another dir.
Delphi Projects
\
\Build
\Common
\App1
\App2
\..
\Database stuff
etc
it all work ok with external ST client, but while we are in the process
of upgrade evaluation to BDS2006 Architect we are concerned about ST integration:
1. the integrated ST client is very slow.
2. The association of multiple Delphi projects of the same suite into one ST Project is not possible.
3. difficulty to manage other directory (like the one above 'database stuff')
non directly related with a Delphi Project.
Fabio
Ryan McGinty ha scritto:
Ryan McGinty
> projects organized in dirs.
No, I have the same thing you have. I have a source dir with multiple dirs
under it, each containing a different Delphi project. It also has directories
for installation, help files, automated testing - all under the same ST project.
> 1. the integrated ST client is very slow.
Ours is not "very slow" but it is a little slower than the Win32 client.
If I undertstand correctly, the built in client is more like the java based
cross-platform client (but I know parts are .NET too), which is slower than
the Win32, but I also hear they are killing the Win32 client and only focusing
on the java one. So, sooner or later, this will be the only client available.
I would say mine is about 15% slower at max. One thing is that it doesn't
show its progress when it is working like the stand-alone. I think that
makes it look like everything is taking longer...
> 2. The association of multiple Delphi projects of the same suite
> into one ST Project is not possible.
I do this all the time, if I understand you correctly. When I set the manage
associations, it lets me pick the subdir in the ST project and subdir in
the project directory structure. I have a bdsgroup with 10 Delphi projects,
and all are in the same ST project.
> 3. difficulty to manage other directory (like the one above
> 'database stuff') non directly related with a Delphi Project.
I just do the "View Client" to get the StarTeam tab in the editor. You can
do everything there that you can in the stand-alone. Make sure that you
have the Structure window showing so you can navigate to folders outside
of the Delphi projects subdir (look at View->Structure).
Ryan
Fabio Scognamiglio
>> 2. The association of multiple Delphi projects of the same suite
>> into one ST Project is not possible.
>
> I do this all the time, if I understand you correctly. When I set the
> manage associations, it lets me pick the subdir in the ST project and
> subdir in the project directory structure. I have a bdsgroup with 10
> Delphi projects, and all are in the same ST project.
if i understand you are correct only for Delphi Project that map directly to one and only one subdir
of a ST Project.
The problem i'm facing is for the common directory source that we share for
all the Delphi Projects (unit files, forms, bitmaps, icons etc.)
How do you map the files that reside out of the Delphi Project subdir(and by consequence out of
the mapped ST dir)?
How do you check-in and check-out those files from the integrated client?
maybe i am missing something.
ciao,
Fabio.
Ryan McGinty
> subdir(and by consequence out of
> the mapped ST dir)?
> How do you check-in and check-out those files from the integrated
> client?
> maybe i am missing something.
Actually, that I have not figured out myself. I currently have to open the
shared code projects (we have numerous BPLs that are shared amongst the projects)
and manage the files that way. I have been meaning to take the time to investigate
how to integrate the shared files into my application projects as well, but
I just haven't had time. Anyone else want to comment on how they do this?
Ryan
Kjell Rilbe
For one set of closely related projects I have had for years the
following setup:
- One ST project for each Delphi project.
- One "Common" project for the common files. All files here are
contained in one single folder. These are just a set of shared units.
- In each "non Common" ST project, create a "Common" subfolder and share
any files you need from the "Common" project to that subfolder. (I've
found this better than sharing the entire "Common" folder, to avoid
having newly added files in the Common project popping up in all
projects out of my control.)
- When a unit that has been project specific becomes shared, I share it
from the specific project into the common project, delete it from the
specific project, then share it back from the common project.
I haven't used it for CR:s.
Kjell
--
---------------------------------------------------------------------------
Kjell Rilbe
Home: +46 8 7610734
Cell: +46 733 442464
---------------------------------------------------------------------------
"If there's a price for bein' me, that's one I'll have to pay"
Aaron Tippin
---------------------------------------------------------------------------
Kyle A. Miller
> I just do the "View Client" to get the StarTeam tab in the editor. You
> can do everything there that you can in the stand-alone.
I know how you switch Views in the integrated client, but where do you
access the View properties? In Win32 client, it's easy, View\Properties.
Kyle A. Miller
> 1. the integrated ST client is very slow.
I find it slower making the initial connection to a server, but that's
about it. The integrated client does not work with VPNs. :-(
> 2. The association of multiple Delphi projects of the same suite into
> one ST Project is not possible.
I am doing that now. I may not understand your challenge. Maybe Manage
Associations will help you. I have multiple Delphi projects in one ST
project.
> 3. difficulty to manage other directory (like the one above 'database
> stuff')
> non directly related with a Delphi Project.
Yea. I located all of our stuff under a single development root
directory. Everything under the root dir is managed ST, including shared
source files.
Kyle A. Miller
> it all work ok with external ST client, but while we are in the process
> of upgrade evaluation to BDS2006 Architect we are concerned about ST
> integration:
My concern about ST integration is whether it will be there when DevCo
splits. According to the BDNradio broadcast, there will be some cross
licensing, but all bets are off as to whether they still with Borland
products for ALM. Together or StarTeam or both could be axed. :-(
Fabio Scognamiglio
but i not see licensing problem for starteam client integration...
for Together is another story.
Kyle A. Miller ha scritto:
Markus Humm
> sure, you are right... :(
> but i not see licensing problem for starteam client integration...
> for Together is another story.
>
>
I'd classify StarTeam as a developer related tool, because you don't
manage requirements with it and it isn't a full blown bug-tracking
system as well. So afaik ST will belong to DevCo.
Greetings
Markus
Ryan McGinty
>> but i not see licensing problem for starteam client integration...
>> for Together is another story.
> I'd classify StarTeam as a developer related tool, because you don't
> manage requirements with it and it isn't a full blown bug-tracking
> system as well. So afaik ST will belong to DevCo.
I don't think so. It is an integral part of ALM. Look at the Borland website
now - it is the "change management" portion
Ryan
Markus Humm
> I don't think so. It is an integral part of ALM. Look at the Borland
> website now - it is the "change management" portion
I think about the persons using it. I think these are mostly developpers.
Greetings
Markus
Ryan McGinty
> developpers.
It really depends. StarTeam also tracks documentation, integrates with CaliberRM,
and other things. In small organizations, all of the ALM tools would be
used directly by the developers... I really don't think StarTeam is going
with the IDE group.
Ryan