Version control
Gerhard Wessels
Subversion is the clear winner.
What I'd like to know is how third party components are handled? I don't
suppose there's a way to check in the versions of components used for a
project and have those "magically" appear in the IDE when the project is
checked out - assuming the currently installed component set is
different from the one used for the project. I'd be more that happy to
restart the IDE :-)!
Gerhard
Thomas Mueller
Gerhard Wessels wrote:
> I have read with interest the posts on version control and it seems that
> Subversion is the clear winner.
Yes.
> What I'd like to know is how third party components are handled? I don't
> suppose there's a way to check in the versions of components used for a
> project and have those "magically" appear in the IDE when the project is
> checked out - assuming the currently installed component set is
> different from the one used for the project. I'd be more that happy to
> restart the IDE :-)!
Unfortunately it isn't that simple, but:
SubVersion offers something called svn:externals, which means that you can
add links to other subversion repositories to your source and they will
automatically checked out and updated together with your project sources.
We use this in the following way:
Lets assume we have got a project called ExcitingProg which relies on Indy10
and the JCL 2.0.3
We have got an svn repository "3rd" into which we check in the 3rd party
sources we use in the following structure:
\-- JCL
| \-- official -> contains the JCL sources as released by JEDI
| \-- 2.0.0
| \-- 2.0.3
| \-- internal -> contains an internal release of the sources
| \-- 2.0
| \-- 1 -> first internal release = usually a copy of the
| official release
| \-- 2 -> second internal release with some bugfixes
\-- Indy
\-- official
| \-- 9.0
| \-- 10.0
\-- internal
\-- 9.0
\-- 10.0
\-- 1 -> first internal release = usually a copy of the
official release
\-- 2 -> second internal release with some bugfixes
You get the picture. Since copies in SubVersion are cheap because it only
creates a reference rather than copying the content, this won't pose a
space limitation. And since every internal release will be available for
all of eternity (a good backup system taken for granted), you can easily
refer to the internal release of a library you were using for a project's
release.
Now this is done like this:
You have got a project repository containing the usual structure:
\-- trunk
\-- branches
\-- tags
\-- 1.0 Release
\-- 1.1 Beta
\-- 1.1 Release
etc.
Lets assume your 1.0 Release was still using Indy10, internal release 1, so
it has an external reference on its main directory like this:
svn:external:
libs/indy https://yourserver/svn/3rd/Indy/internal/10.0/1
Now, when developing version 1.1 you found a minor bug in Indy and fixed it,
releasing it internally. Now you change your external reference to:
svn:external:
libs/indy https://yourserver/svn/3rd/Indy/internal/10.0/1
If, for whatever reason you later on need to know with which version of Indy
your project was released, all you have to do is look at the external
reference.
To actually use this, we remove the directories added to the library path by
the installer and instead add references to the subdirectories under libs
to the search path of the project:
libs\indy;libs\jcl\source;libs\jcl\source\common;libs\jcl\source\windows
(Note the relative paths! The IDE will add absolute paths, so you have to
correct it manually, which is a pain in the lower back.)
This way we ensure that the program will always be compiled the correct
sources of the 3rd party library.
Unfortunately this will not help with installing the correct packages into
the IDE, so that is still done manually by loading the .dpk files, building
and installing them. Extra care must be taken because sometimes the
filenames of the packages conflict. Of course some of this could be
automated using a batch file but that's more work than we want to invest
for now.
MfG
twm
ps: If anybody has got some ideas on how to improve on this system, I'd like
to hear them.
Roger Lascelles
"Thomas Mueller" <nos...@dummzeuch.de> wrote in message
news:45f0...@newsgroups.borland.com...
> Unfortunately this will not help with installing the correct packages into
> the IDE, so that is still done manually by loading the .dpk files,
building
> and installing them. Extra care must be taken because sometimes the
> filenames of the packages conflict. Of course some of this could be
> automated using a batch file but that's more work than we want to invest
> for now.
> ps: If anybody has got some ideas on how to improve on this system, I'd
like
> to hear them.
Thanks for the clear post. I have been just checking out my libraries
instead of using externals - I'll have a look at your method.
The Delphi component system is "broken" once you require multiple versions
of components, and switching components brings opportunities for error.
Therefore I never install *any* 3rd party or in-house components, but
created them at run time. This removes a burden of care and lets Subversion
take over all the details. It also means you can switch jobs without
closing the Delphi IDE. Plus you can zip a directory tree and send an
entire project to a colleague with no concern for which version of controls
they are running. Absolutely everything required is in Subversion and you
can move to a new PC with no drama.
It may seem too hard to live without new visual controls, but there is peace
of mind knowing that you have access to scores of projects going back for
years, all safely stored in subversion and available.
Roger Lascelles
David M
a project (eg, have components in the project group), so that when you
opened the project the components were installed, and when you closed it
they were uninstalled. That way components could live directly in your
versioned source tree just like all your other source.
I've heard of people faking this via the Delphi Configuration Manager, but
it's completely broken for me for BDS 2006 so I haven't tried it.
Cheers,
David
"Roger Lascelles" <rogerlasAToptusnet.com.au> wrote in message
news:45f08e69$1...@newsgroups.borland.com...
Gerhard Wessels
components we use are visual control e.g. Toolbar2000 and Virtual
Treeview - neither of which I could live without.
Gerhard Wessels
Thank you for your detailed reply. We'll look into this a little further.
I hope CodeGear addresses this basic requirement in their 64bit (hint!!)
IDE/compiler before they "invest" in esoteric features. We're still
"stuck" on Delphi 7 since later versions have nothing in it for us that
warrants the investment of the upgrade. We do low level (non-.Net) work.
A 64bit compiler would have been useful and since this is probably still
a year or more away we'll probably have to look Visual Studio.
Anyway I digress...
Thanks for the advice.
Gerhard
Bruce McGee
> Unfortunately this won't work for us since many of the 3rd party
> components we use are visual control e.g. Toolbar2000 and Virtual
> Treeview - neither of which I could live without.
It doesn't have to be all-or-nothing.
I put components that make sense to create dynamically in directories
that are in my library path and check them in to source control.
Components that make more sense to install, are just installed. When I
do a major re-install, I install the IDE(s), install each of my "must
install" libraries and check out my projects and any remaining third
party code. Once I add back my library paths (I should probably save
these off), I just re-build everything (FinalBuilder rocks!) to make
sure I didn't miss anything. The whole process is usually pretty quick.
A colleague had the idea of checking in all third party components and
being able to re-install everything back into the IDE unattended. His
idea of recovery would involve installing the IDE(s) and running his
custom install for everything else, and he's done. Sounds cool, if
labour intensive so set up.
--
Regards,
Bruce McGee
Glooscap Software
Thomas Mueller
Bruce McGee wrote:
> When I do a major re-install, I install the IDE(s), install each
> of my "must install" libraries and check out my projects and any
> remaining third party code.
I also put installers of any tools and 3rd party components that require
installs into a repository and link them as externals if they are used in a
project. Just to make sure I still know which version was used for a
release and that I can get it again in case I don't remember a download
link etc. These files are quite large, but since they don't change it
doesn't matter that much.
> A colleague had the idea of checking in all third party components and
> being able to re-install everything back into the IDE unattended. His
> idea of recovery would involve installing the IDE(s) and running his
> custom install for everything else, and he's done. Sounds cool, if
> labour intensive so set up.
I actually had some script based system in place to recompile and install
3rd party packages (Indy, OpenXML, ReportBuilder, TeeChart) from the
sources in SubVersion, but in the long term it turned out to be too labour
intensive, as you say. You don't set up a machine for a project that often,
so I eventually settled for using the installers.
MfG
twm
Matthew Jones
installed later - typically ones that I've deprecated and uninstalled. The
solution to these is easy - I just open the DFM and copy the details of
the component to the FormCreate. A bit of editing later and you have the
code to create the component as required but at run-time, and now it all
carries on working.
This technique would allow a form to be prepared with all the components
in the IDE, and when moved to a build machine to be converted to code. I
suspect that a little app with a list of components to move to FormCreate,
and perhaps also to do them the other way, might be easy to write and
handy for this sort of thing.
/Matthew Jones/
Thomas Mueller
Matthew Jones wrote:
> FWIW, I use some components on forms that then find themselves not
> installed later - typically ones that I've deprecated and uninstalled. The
> solution to these is easy - I just open the DFM and copy the details of
> the component to the FormCreate. A bit of editing later and you have the
> code to create the component as required but at run-time, and now it all
> carries on working.
GExperts has a function to do exactly that automatically, but unfortunately
it requires the form to be open so the components must be installed.
> This technique would allow a form to be prepared with all the components
> in the IDE, and when moved to a build machine to be converted to code. I
> suspect that a little app with a list of components to move to FormCreate,
> and perhaps also to do them the other way, might be easy to write and
> handy for this sort of thing.
That's only feasible for applications that are no longer actively developed.
I wouldn't want to start guessing what a form looks like by only seeing the
creation code.
MfG
twm
Kyle A. Miller
> SubVersion offers something called svn:externals, which means that you can
> add links to other subversion repositories to your source and they will
> automatically checked out and updated together with your project sources.
Excellent post! Very useful information for those coming into the world
of Subversion. Don't forget your turtle! http://tortoisesvn.tigris.org/