Board index » delphi » Re: Comments on managing large project with many dependencies

2005-11-16 02:48:46 AM
delphi209
Ryan McGinty writes:
prefer VMWare, you might like or have Virtual PC), or once the project is
"done", create a facsimile in a virtual machine. That way any future
maintenance work can be done in the VM with the IDE exactly the way it
was, without worrying about altering your main development IDE.
--
-Brion
There's no such thing as 'one, true way;'
- Mercedes Lackey
 

How do most of you that have large projects with multiple third-party
libraries handle working on past versions for critical updates? I have
everything in a VCS, but the project itself is only half the battle (and
the half that I have figured out). Let's say that your project's old
version used Indy 9.0.16 and the latest development is using 9.0.28. I
don't want to redeploy a new version of the components for one line of
code to my old project. I am having a time trying to figure out how to
"rollback" the IDE because of the amount of time involved in recompiling
the component libraries etc... Any ideas? Can you use the
Configuration Manager to do this type of thing? Thanks for any advice!
Ryan
 

Ryan McGinty writes:
have an in-house developed build automation program, which downloads
all the source for referenced third party components as part of its
automated build script. Because of this, it is trivial to download vX-1
from SourceSafe (when the DB isn't corrupt, that is ;-), and apply a
patch to an older version. In fact I had to do that last week.
The reason we can operate this way is because we don't make use of the
VCL forms designer for any of our projects. Not sure I fully agree with
the rationale behind this decision, as the major argument is to ease
migration issues between Delphi versions and we're still on D6. But
because of this, it does make our source code easily transportable
between development machines, and makes it very easy to reproduce an
environment for a project at any given time.
--
Cheers,
David Clegg
XXXX@XXXXX.COM
Vote 1 cc.borland.com/codecentral/ccweb.exe/listing :-)
Now supports Google Groups searching with Dyna-extend(tm) technology!
QualityCentral. The best way to bug Borland about bugs.
qc.borland.com
"This donut has purple in the middle. Purple is a fruit!" - Homer
Simpson
 

Ryan McGinty <XXXX@XXXXX.COM>writes
<437a2d87$XXXX@XXXXX.COM>
components into the IDE but just use them in the code by dynamically creating
them instead. RAD is great for laying out GUI's, but then once the GUI's are
laid out, it loses its appeal, because of this versioning dilemma with
third-party code, among other things.
This is what I have done with Indy, for example. I am using Indy 10 but the prior
version of Delphi I was using had Indy 9 installed, which I needed to keep
installed for another project. By creating the Indy 10 components dynamically
as I needed them I was able to use Indy 10 in one project even though Indy 9
was the version installed in the IDE.
You can place different versions of the third party components in different
directories and set your individual projects to look at the specific directory
for the version they are using.
--
Check out the latest beta preview of
JSNewsreader at
www.jsnewsreader.com/Preview3.zip
Posted with JSNewsreader Preview 1.0.4.1556
 

Ryan McGinty writes:
think it is too much work. But it works for me rather well.
I use Perforce as my source code control system. One of the features of
Perforce is the client workspace - a cool little thing that allows you
map portions (or versions) of our source code control tree to different
local directories. For example, I have Indy 9 in one source code
directory, and Indy 10 in another. I label each version that I check
in, so I can have multiple versions of Indy 9 (or 10) layered on top of
each other, each nicely labelled.
Using the client workspace feature, I map the appropiate third party
components - and the appropiate version - into a project directory on my
dev system. For each 3rd party component, I keep a BPG with all the
projects that need to be installed. Each project has it is own
components (and versions) and I use the BPG to install the
component/version into the IDE.
Works pretty well and keeps 3rd party components separate. I am still
working on automating the swapping down to a single command line
operation, but for the moment, the manual part isn't terribly difficult.
Jason
 

We put everything - including third party components - under
source control. Branch codeline at each release. Use virtual
machines to keep a full development and test environment for
each release.
 

Hi Brion,
Not a bad approach, except that we have 22 component suites we are using,
and it takes an awful long time to install them even on a normal machine,
let
alone a virtual PC. Too bad there isn't a way to just clone an environment
to
a virtual PC.
-- Larry Maturo
"Brion L. Webster" <XXXX@XXXXX.COM>writes

"Larry Maturo" <XXXX@XXXXX.COM>writes
www.vmware.com/products/p2v/
 

In article <437a69a0$XXXX@XXXXX.COM>, XXXX@XXXXX.COM
says...
Had much success with Alohabob PC Relocator.
At any rate, it is still better to install once
a clean development environment in a virtual
machine, and clone it for each developper.
That spared us days of setup
 

with the same environment. Configuration
management made easy :-)
 

Everything useful is placed under sourcecontrol (CVS), .pas like .bpl.
Getting back to an old version/branch is then just a matter of stopping
Delphi (so BPLs files aren't locked by the IDE), swiching to the branch,
and re-starting Delphi.
Eric
 

Yeah, I was telling a friend that this is one of the few times that
visual development bites - having everything source has an advantage
when rolling back the entire project. However, the benefits we get from
visual development are immeasurable and I am going to have to find a
way to handle packages being installed. We have approx 20 3rd party
components. Indy could be created dynamically, but the visual things
like grids, inspectors, and page controls cannot without MAJOR work.
I'm actually in the process of trying to make everything MORE visual for
efficiency. Thanks for the feedback!
Ryan
John Jacobson writes:

I'm looking for whatever works, even if it is an effort to setup. This
is actually the path we were on. I have a runtime and designtime
package list project groups (though I could probably combine them) and
environment variables pointing to the root of the source tree for
everything (components, project, etc). In theory, if I checked out an
older version of everything, rebuilt the packages from the package list
bpg, and used DCM to switch to a clean registry set for Delphi, I think
it would work out ok. Now to just make sure that everything is using
relative paths!
Thanks for the feedback - I think this is probably what we are going to
do to keep everything the most organized.
Ryan
Jason Swager writes:

Perhaps you can use the "big package list" approach like we are going to
try to do. I got sick of loading all the 3rd party components every
time I reloaded my computer. I finally checked ALL the source under one
develop\components subdir and have two bpgs to rebuild the runtime and
designtime packages in one swoop. Installing works pretty well and
doesn't make me cringe at reloading. Of course you have to have a big
ol' list of paths too for each component suites source directory, but I
have it in a text file that I can just paste in with an environment
variable pointing to the top folder of the source tree...
Ryan
Larry Maturo writes:

This is almost identical to what I am dealing with. I have an
application framework that multiple projects are built on, and then a
ton of 3rd party packages. I have the components, framework, and each
project all separate in the VCS (since the pieces are shared) and as
long as I properly label everything, I think I will be ok. You pretty
much nailed it on the head with all your goals. Those are my goals or
future goals too. You are also right that it is not something that I
see a lot about. I am glad a bunch of people responded though. There
are a lot of approaches and hopefully everybody can benefit from the info.
Tor writes: