Is it possible, that MSSCCI make VFP project loading slow? Project has 1000+ files, workspace is server. Project loads about 120+ seconds. Network traffic is greater during loading, CPU and memory no significant change. How can I optimalize loading project please?
SOLUTION:
NO, it seems that slow loading is consequence of using MSSCCI provider for little large projects source controlled in VFP.
We looked into moving from Visual SourceSafe to TFS a few years ago. When the VFP project was integrated with TFS, opening the project took longer than with VSS. There were also other oddities with the integration, such as not being able to see when a file was already checked out by someone else. We ended up abandoning the idea and stuck with VSS. That said, I wouldn't necessarily blame the MSSCCI provider. It probably has more to do with the way VFP queries source control data.
Note that you are not required to use the VFP project integration. You can use a separate source control client to check files in/out. You'll need a process for generating text versions of binary files (SCX, VCX, etc.).
FWIW, opening projects with VSS can also be slow. Upgrading our VSS server made a big difference. You may find the same if you are running TFS on an older/slower server.
I am not using it so I cannot directly comment on it.
A project is merely a table, and a project with 1000+ files would be roughly mean around 2Mb which is nothing for today's networking (even if it meant to bring down all that data). Normally it should open instantly or with 1-2 seconds delay at most (assuming you are not using an extremely slow network).
Please provide more details about your environment.
Make sure your TFS and MSSCCI are used latest version.
Try on another client machine to see whether your issue would be reproduced.
Create a new workspace to see whether the performance persists.
Related
I have two PCs both with XE2. I thought that I had installed identically on both but have problems installing 3rd party packages on one while the other is just fine.
I want the same on both anyway. The easist would probably just to "migrate" the working set-up by moving in into my Dropbox folder. Can I do that? If so, how?
If not, can I (easilly) backup my registry settings on one machine and then import them on the other?
I suppose I could just sort out the problem on the one PC, but am not having much luck so far. I would rather invest the time in only having one Delphi setup. And since I am moving lots of other stuff to DropBox anyway ...
The tool for this is now built into Delphi XE8 and higher.
It's found here:
C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\migrationtool.exe
Online documentation:
http://docwiki.embarcadero.com/RADStudio/Rio/en/Settings_Migration_Tool
Install CnPack wizards from http://www.cnpack.org
From the CnPack toolbar select IDE Config Backup/Restore (image below) and save this file somewhere safe
Copy the components to the second delphi machine . Keep the exact same directory structure.
I store my components as follows this helps backing up, moving etc., but you can use your own structure
D:\components_bds\DCU
D:\components_bds\BPL
D:\components_bds\ComponentsThemselves
Use the restore config file from CnPack to restore your components on the new machine
This is also useful if your testing components that you plan to remove later and keeping a backup of your installation incase something goes wrong you can save time with new delphi installation if hard drive dies. Keep a copy on flashdrive or somewhere safe
You may compare/diff the config file created by cnPack using a tool like Beyond Compare and see what the differences are to find out why third party components give problems on one of the machines. It may be a Delphi registry/installation problem or a problem in the paths of the thirdparty components. Components need to be installed in an order perhaps it did not find the needed dcu or dll it depends on.
I don't know of any way to do so with DropBox. Here's an old post I made (related to Delphi 7, but with correction of registry keys still applicable) in the CodeGear newsgroups; hopefully it will help.
(It probably goes without saying, but back up the existing registry settings on the destination machine before starting by using RegEdit and exporting them, just in case. You'll at least be able to get back to the point you're at now if something goes wrong by deleting the imported entries and then importing the saved ones.)
You can't, without some difficulty anyway. (Especially if you have
third party components installed, as they may have placed files in the
%SYSTEM% folder you may not know about.)
You may be able to (for going from the old computer to the new
computer running the same exact version of Windows!) by exporting the
registry keys under HKCU\Software\Embarcadero and
HKLM\Software\Embarcadero from the old machine, and then after
installing Delphi on the new machine (in the exact same folder
location) importing that registry file.
Many of the compiler, linker, and other settings are configured on a
per-project basis, and should transfer over when you move your source
code to the new machine.
Third-party components are a problem, as I mentioned above. You may be
able to get away with using the registry export/import if you copy
each third-party component set from the old computer into exactly
the same location on the new machine before importing the registry
file. You'll probably have to track down some .BPL files that end up
in the $(BDS)\Bin and possibly other folders under the $(BDS)
tree; the IDE will tell you about missing stuff when you try and start
it. Make sure you answer "Yes " when asked if you want to try and load
it again next time!
Most of my development is hobby stuff or wannabe releases. Instead of dying trying to move my XE2 Pro from my Dell Inspiron N7110 Win 7 machine to my new Win 10 SSD machine, I'm seriously thinking of switching to Lazarus. I've used Lazarus 2.x with Indy 10, ZeosLib, and Firebird and successfully created a working distributed internet system. I also created Lazarus version of my XE2 Blackjack program. When compared to XE2, Lazarus (IMO) has only two weakness and neither are deal breakers for me. BTW, I have successfully duplicated Lazarus (with all installed components) from one machine to another simply by copying and pasting the Lazarus directory and it works. Try that with Delphi.
Sam
With the desire to be able to reproduce a given revision of a project that is utilizing 3rd party visual component packages, what goes in SVN and what's the best way to implement/structure the SVN repos?
For non-visual components, the rule seems simple to ensure no reliance on outside repos - "no svn-externals reference to any outside repo allowed". I have a shared repo that I control, which is the only 'svn-externals' reference allowed. This makes it easy to implement and share these types of runtime itemss with sourcecode in different SVN projects. Any reference this internal shared repo is by 'svn-externals' using a specific revision number.
Visual packages seem to go counter to being able to be version controlled easily as they may have to be reinstalled at each revision. How to best create a SVN project which is able to be recreated later at a specific revision number...is there a recommended solution?
Previously we didn't worry about 3rd party components as they don't change often and we never had a real good solution. I was wondering if others have figure out the best way to handle this problem as I'm doing a spring cleaning/internal reorganization and wanted to do it 'better' than before.
Technically, the RTL/VCL source should also be in the SVN repo as well (if there's a Delphi hotfix/service pack released.)
My solution will likely be to create a virtual machine with a particular release of the Delphi environment with all visual controls installed. As we add/update visual controls, or update Delphi with hotfixes/service packs then we create a new version of the virtual machine. We then store an image of this VM revision on a shelf somewhere. Is this what you do? Does the Delphi activation/licensing work well (or at all) in this scenario?
Thanks,
Darian
You can prepare "start IDE" (and possibly "build") scripts for your projects and maintain them as project evolves in repository.
Regardless of your decision about keeping components in separate repositories and using externals, or including them in a single repository with possible branching, you should also include compiled bpl files for every component build and for every branch prepared for a specific Delphi version.
You should definitely try to keep most (if not all) of paths relative, in a worst case use environment variables to point to your root project dir.
Start IDE script allows you to keep each project and Delphi version environment spearately configured on a single Windows installation.
It should include necessary registry keys for your project and Delphi:
Windows Registry Editor Version 5.00
[-${DelphiRegKey}\Disabled Packages]
[-${DelphiRegKey}\Known Packages]
[-${DelphiRegKey}\Library]
[${DelphiRegKey}\Known Packages]
"$(BDS)\\Bin\\dclstd${CompilerVersion}.bpl"="Borland Standard Components"
"$(BDS)\\Bin\\dclie${CompilerVersion}.bpl"="Internet Explorer Components"
"$(BDS)\\Bin\\dcldb${CompilerVersion}.bpl"="Borland Database Components"
(...)
"${CustomComponentPack}"="Custom Components"
[${DelphiRegKey}\Library]
"Search Path"="${YourLibrarySourceFolder1};${YourLibrarySourceFolder2}"
(...)
You can then prepare batch file:
regedit /s project.reg
%DelphiPath%\bin\bds -rProjectRegKey Project.dpr
Where ${DelphiRegKey} is HKEY_CURRENT_USER\Software\Borland(or CodeGear in newer versions)\ProjectRegKey.
Basically it is easier when you will dump your current working configuration from registry, strip it from unnecessary keys, change paths to relative and then adapt to make it work with your project.
In such configuration, switching between projects and their branches which have different sets of components (and/or possibly using different Delphi version) is a matter of checking out a repository only and running the script.
Fortunately for us, we don't have to worry about a hotfix/service pack; we're still on Delphi 5. :D
Sigh, there was a time when an entire application (settings and all) would exist within a single directory - making this a non-issue. But, the world has moved on, and we have various parts of an application scattered all over the place:
registry
Windows\System
Program Files
Sometimes even User folders in "Application Data" or "Local Settings"
You are quite right to consider the impact of hotfixes/service packs. It's not only RTL/VCL that could be affected, but the compiler itself could have been slightly changed. Note also that running on the same line of thought, even when you upgrade Delphi versions, you need to build using the correct version. Admittedly this is a little easier because you can run different Delphi versions alongside each other.
However, I'm going to advise that it's probably not worth going to too much effort. Remember, working on old versions is always more expensive than working on the current version.
Ideally you want all your dev to be be on main branch code, you want to minimise patch-work on older versions.
So strive to keep the majority of your users on the latest version as much as possible.
Admittedly this isn't always possible.
You wouldn't want to jump over to the 'new version' without some testing first in any case.
Certain agile processes do tend to make this easier.
By using a separate build machine or VM, you already have a measure of control.
TIP: I would also suggest that the build process automtically copy build output to a different machine, or at least a different hard-drive.
Once you're satisfied with the service pack, you can plan when you want to roll it to your build machine.
It is extremely important to keep record of the label at which the build configuration changed. (Just in case.)
If your build scripts are also kept in source control, this happens implicitly.
When you've rolled out the hotfix/service pack, fixes to older versions should be actively discouraged.
Of course, they probably can't be eliminated, but if it's rare enough, then even manual reconfiguration could be feasible.
Instead of a VM option to keep your old configuration, you can also consider drive-imaging.
To save on the $$$ of VMWare LabManager, look for a command-line driven VM Player.
You might have to keep 2 "live" machines/VMs, but should never need more than that.
It's okay for an automatic build script to fail because the desired configuration isn't available. This will remind you to set it up manually.
Remember, working on old versions is always more expensive than working on the current version.
Third Party Packages
We went to a little bit more effort here. One of our main motivations though was the fact that we use about 8 third party packages. So doing something to standardise this in itslef made sense. We also decided running 8 installation programs was a PITA, so we devised an easy way to manually install all required packages from source-control.
Key Considerations
The build environment doesn't need any packages installed, provided the object and/or source files are accessible.
It would help if developers could fairly easily ensure they're building with the same version of third party libraries when necessary.
However, dev environments usually must install packages into the IDE.
This can sometimes cause problems with source compatibility.
For example new properties that get written to IDE maintained files.
Which of course brings us back to the second point.
Since Third Party packages are infrequently updated, they are placed within a slightly different area of source-control.
But, NB must still be referenced via relative paths.
We created the following folder structure:
...\ThirdParty\_DesignTimePackages //The actual package files only are copied here
...\ThirdParty\_RunTimePackages //As above, for any packages "required" by those above
...\ThirdParty\Suite1
...\ThirdParty\Suite2
...\ThirdParty\Suite3
As a result of this it's quite easy to configure a new environment:
Get latest version of all ThirdParty files.
Add _DesignTimePackages and _RunTimePackages to Windows Path
Open Delphi
Select Install Components
Select all packages from _DesignTimePackages.
Done!
Edit: Darian was concerned about the possibility of errors when switching switching versions of Design Packages. However, this approach avoids those kinds of problems.
By adding _DesignTimePackages and _RunTimePackages to the Windows Path, Delphi will always find required packages in the same place.
As a result, you're less likely to encounter the 'package nightmare' of incompatible versions.
Of course, if you do something silly like rebuild some of your packages and check-in the new version, you can expect problems - no matter what approach you follow.
I usually structure my repository in SVN like this:
/trunk/app1
/trunk/comp/thirdparty1
/trunk/comp/thirdparty2
/trunk/comp/thirdparty3...
I have, right in the root folder (trunk) a project group (.groupproj, or .bpg on old delphi) that contains all my components. (allcomponents.groupproj).
Installing on a new machine, means opening that package, and installing the designtime components. That's a drag on all versions of Delphi older than 2010, but 2010 and XE have a lovely feature so you can see at a glance, which components are designtime components.
I also, sometimes, will save myself the trouble of installing those components by hand, by making a build.bat file, and a regcomponents.bat file. The regcomponents just runs regedit , and imports the keys needed to register all those components, after build.bat has built them, and everything else.
When you move up from one delphi version to another, it's sure good to have both a batch and reg file, and a group project, to help you. Especially if you have to go through and do a lot of opening of project/packages and saving them as MyComponent3.dpk instead of MyComponent2.dpk, or updating the package extension from 150 to 160, or whatever your packages do.
Searching with '[Delphi] "source control"' didn't return much, so here goes: For those of you Delphi programmers working on your own, what source control do you like? I know about TortoiseSVN (which can be used without a server), but I'd like to know if there are better options before choosing it.
Thank you.
SVN will be more than enough as you'll mostly use it for backing up and diff'ing versions.
You can use VisualSVN Server and TortoiseSVN with Delphi IDE Integration. All of these are freeware. If you wish to use any other freeware SCM with Delphi IDE integration you'll need to buy SourceConneXion or Athlant. Also, if you're using D2009 you'll need to convert strings to ansistrings in order to get TortoiseSVN addon for delphi to work.
I use Mercurial, and have used Bazaar and Perforce (free for small teams). All are good, but nowadays I tend to prefer Mercurial. Mercurial comes with its own tortoise
which, while not quite as polished as TortoiseSVN, is perfectly usable:
(source: sourceforge.net)
For users of RAD Studio XE or XE2, Uwe Schuster has published an IDE add-on called Version Insight Plus that adds Mercurial and Git support to the IDE's built in version control support.
For all the systems I have mentioned, no central server is required.
I would recommend Git which is free & open source and:
Doesn't require you to even set a central server even if you want add more developers or machines.
Is Extremely Fast (imo)
Encourages the use of branches
I use it for almost every new project, even when it's just me on the project. It's an extremely fast distributed version control system and was written by Linus Torvalds and is now used in high profile projects like the Linux Kernel and Ruby on Rails.
Git isn't hard to use from the Command line but also has it's own "Tortoise" package (TortoiseGit - albeit not as polished as it's SVN cousin).
SourceGear Vault is free for a single user. I like to use the external client because I work in different environments, but If you want Delphi IDE integration, you can use Source ConneXion (not free).
You might look at some of the responses here (Stack Overflow) if you do have Delphi in mind. As mentioned in the answers there, I use Team Coherence which integrates very nicely with Delphi's IDE, and is aware of Delphi file groups (.pas with .dfm etc). I think it's written in Delphi too.
Having said that, the other comments already made are true - you shouldn't really let your choice of language dictate your choice of VCS.
Even though you've said single user, I would look for a solution that allows you to easily host it on a server/other desktop machine, so you have separated your development machine from your source repository. I'm probably teaching granny to suck eggs but you ought to check that whatever you choose can be easily backed-up too (even to a USB key or external drive would be fine). :-)
I know you have asked for Source Control, but if you are always planning to be a 'single developer' you might like to consider an automatic backup solution like AJC Active Backup instead. Yes, you lose the ability to check in and out specific versions, but at the same time you avoid the need to check stuff in and out all the time when it is only you working on a project. And you can recover or diff any previous source files by date for as far back as you care to configure. It's very much a set-and-forget solution, until you need to recover something, when it is invaluable. And the archive itself can be backed up in the normal way.
I use TortoiseSVN, but store my repositories as files on my laptop (on a share that can be accessed by mutilple VMs), not managed by a server. This means that I have full access to the repository regardless of server access, but also allows me to easily backup the repositories to the company file server when connected.
Since I am the only programmer I have not needed a separate server so far. I have seen Nick Hodges (Delphi Development Manager) say very nice things about VisualSVN Server, and I aim to check this out, to see how easy it is to backup/restore the repository: if that can be automated, and done very quickly, then I will probably adopt that.
Longer term I am going to look at the various flavours of distributed VCS, as that may be better suited to multiple laptop-based developers; I'm not sure yet, as I've not reached that page of my to-do list ;-)
One of the things supposedly in the pipeline for Delphi is integrated support for VCS. I've no details on that, or on any implications for current users of the various traditional or distributed VCS.
The language you use doesn't really matter in the choice of the SCM you will use.
It can matter if your favorite IDE supports or not this SCM.
TortoiseSVN is just a svn client, if you choose svn you can have several client.
I use Tortoise, and subclipse for committing in the same svn repository.
I would suggest using SVN server on a separate machine (either VisualSVN as suggested before or CollabNET Subversion Server) and TortoiseSVN with JVCL integration expert (also as suggested before).
Besides getting all the good stuff from the version control, you'll also automatically have backup on a different computer, which is always a good thing.
I know this will get down voted, but I feel it has to be said.
I've used Version Control software for many years at my job, and it is required when multiple people work together - to make absolutely sure that no two people overwrite one-another's work.
But for my personal development at home I don't use one. I find them overbearing and inconvenient for a simple one-person project. And I've tried several packages including Source Gear Vault and some others that other people have mentioned.
What I do instead is at every significant change to my program that I might want to go back to, I make a copy of the entire program directory. If I screw up in the next change, I can go back to the copied directory.
I also permanently keep copies of all my directories of every release of my program. If I ever need to do comparisons between my current version and previous releases, or between two different previous releases, I use Beyond Compare by Scooter Software - a simply great tool for diff-ing and copying changes between versions. If you use Source Control software, Beyond Compare will integrate into it nicely.
So I mention this simply because I have often heard everyone pushing Version Control Software, even for the individual developer. For some of us, it's overkill.
You may want to consider this simpler solution.
I use Bazaar with Delphi and it works well, especially for solo developer workflows. It has it's own TortoiseBzr but it isn't as good as some of its cousins so I recommnend the excellent Bazaar Explorer instead. One of the great things about Bazaar is it's flexibility and the ease with which you can change workflow or include another developer in a project that started off solo.
A lot of articles about Bazaar will tell you it is a lot slower than Git or Mercurial. They are out of date, now it takes a similar time to acomplish operations as they do and is faster on some operations.
My team use StarTeam and I have never used something else like SVN so it is hard for me to do a good compare. Starteam has both positive and negative sides.
Pros:
You can register Change requests and
connect them to checkins. This make
changes more trackable.
I feel more comfortable with a real GUI compared to commandline or some Shell
extension.
Cons:
Expensive, as most products from
Borland...
Latest version use Java. It is almost like the previous Win32 version and they have added more features, but I still feel that it is some slower and more memory hungry than before.
GUI could be a bit more intuitive.
I'm not big on version control, but use SVN/Tortoise and am quite happy with it. The main benefits that I see for a single developer is being able check out older versions of the application, and use multiple computers for development (desktop / laptop) - other than the obvious backup benefit. I tend to not need it for diffing files, as I find the version control tools within the Delphi IDE fairly good for this - provided the "bug" was introduced recently.
I think most Delphi developers use SVN/Tortoise (making it a fairly safe choice) - but there are trendyer options such as Mercurial and Git.
As a single developer, I have used Perforce for a number of years. It has been great. Aside from a CLI, you can use the P4V client. There's also an explorer plugin available, as well as Delphi IDE integration. I actually just found this free integration on Torry yesterday:
p4delphi
I've installed it in Delphi 2010, and it works pretty good.
Perforce is free for two user, it would require you to install perforce server, but the server footprint is very, very small. you can use P4V (Perforce visual client) which is far more convenient than tortoise, it also provide Windows explorer extension to be have just as tortoise (but you could skip this installation). Delphi integration could be done using P4Delphi.
I am using subversion, bug tracking and simple to use project planning for my latest delphi project from an web service provider. http://www.unfuddle.com has a free account for projects less than 200mb with 1-2 developers and the user interface is easy to use.
Is there currently a feature that allows a exclusive checkout in SVN?
Is there a good plugin for Delphi that allows the access via IDE?
SVN has a concept of "locking" which roughly corresponds to the exclusive checkout. For example, in TortoiseSVN this is exposed via Get lock and Release lock menu entries.
JCL contains a SVN version control expert which works quite fine. Besides other things, tt gives you access to the locking functionality from the IDE.
TortoiseSVN can be added into the Delphi tools menu. I've not tried this myself, since I'm happy using it as an Explorer extension.
Regarding the exclusive checkout, I'm guessing you mean so only one person can edit it at a time? That's not really the idea behind Subversion, the idea is you have working copies and then check in your changes. It'll then try to merge your changes in (this usually works most of the time). If there are conflicts you'll need to resolve them manually.
I believe one of the reasons why people sometimes enquire about locking items in a Subversion repository is because they have their Delphi DFMs saved in a binary format, which makes committing/merging problematic.
An alternative to changing DFMs etc to text is use Scooter Software's Beyond Compare.
Beyond Compare is written in Delphi, and natively knows how to read binary DFMs. This means that it then becomes less of an issue (or even no issue) whether your DFMs are stored in Subversion in binary or text. Beyond Compare V3 also does 3-way merging which makes it really easy to merge multiple commits etc. Even ignoring the ability to diff binary DFMs, it's still a much better diff viewer than TortoiseSVN's built-in tools. I can highly recommend it, and it's very inexpensive.
Currently the only things that I lock in our repository are COM type libraries (*.tlb and their associated *_TLB.pas files).
Regarding exclusive checkouts. It can be done, but it's a pain and generally not worth the time. If you do have dfms saved as binary, convert them to text.
Regarding delphi addins, I have a post at Delphi addins for subversion.
I use the jedi jcl, and TortoiseSvn.
There are also Delphi svn and Delphi addin in for Tortoise svn that I know of.
Maybe I'm naive, but why would anyone want to go to the enormous trouble of merging their changes? Merging might be a simple matter if programmers were editing text files whose contents are easily understood, and which therefore could be merged by virtue of the programmers knowing the meanings of the changes. However if you're using SVN with MS Visual Studio, where changes to one file frequently case changes to other files you didn't know about, and where the encoding of information in such files may be completely unknown to the programmers (who would therefore have no concept of how to interpret much less merge such files) and may even be binary, why would you go to the enormous trouble and risk of having multiple people simultaneously editing things?
The locking paradigm is simple. Only one person edits at a time. Merging is never required. Programmers don't need to know the encodings of (possibly binary) files that they don't even realize that they're modifying. Nobody can stomp on anyone else's changes. Locking (i.e. locking by default) sounds much preferable to me.
What do you mean by "exclusive checkout"? Do you mean that after you check out, nobody else can check out?
That's called a lock and subversion can do this (see Locking), though it's not recommended in general as the purpose of version control is to allow multiple people to simultaneously work on the versioned item.
For first part, I was using Visual Source Safe which is support locking (you have to check out before use), SVN has locking command, but it's against it's concept, you need few time to get used with it, and you will never use the locking command again.
For second part of your question, The TortoiseSVN can be used as external tool, or you can get it working with File Browser bundled with Delphi 2007 and above, and you can use IBrowser which work with older versions.
and Subversion add-ins for Delphi summarize the available SVN plug-ins for Delphi IDE, beside SourceConneXion which is commercial product.
I just got a new laptop with Windows 7 (32-bit) and I have to install the following things:
SQL Server 2005 (Dev edition)
SQL Server 2008 (Dev edition)
Visual Studio 2008 Prof.
Delphi 2007
Delphi 2010
In addition I need the usual suspects such as Office 2007 etc.
I was thinking of doing it in the order listed above but would like to know if this is the best way.
On my old system I must have done something wrong as I have had lots of problems with broken help files etc. especially in Delphi.
Thanks.
IMHO: You shouldn't!
Instead, install each development enviroment on different virtual machines.
(Eg VMware Workstation)
The disadvantages are minimal. Perhaps some more costs (VMware + additional OS license).
But the advantages are invaluable!
Portability. If you get a new (physical) machine, it is very simple to copy the virtual machines from the old one to the new one. (You can even save the vm's on a USB-stick and run them on different computers).
Snapshots. Before you do any changes in your dev.env. (updating, adding and removing sw) you can take a snapshot of the vm, and roll back to this state at any time! Make sure you've got your documents and source code on the host machine or a server, though. Because everything is rolled back. Every file is restored to the state it had at the time the snapshot were taken.
Forks/branching. If you are working on a new feature, you can create a branch of the dev.env. (via snapshots), and easily switch between the experimantal dev.env and the production dev.env. at any time.
Using snapshots you can maintain multiple (virtual) operating systems without having to buy several OS-licenses. (You can't run these branches of the OS simultaneously, of course).
More testing environments on the same (physical) machine. Different combinations of OS-versions and MS Office-versions etc)
Protection when testing risky code. (Eg deleting files, updating databases, registry changes etc)
Start playing with new sw-versions without messing up the existing dev.env.
Separate customers/projects according to their various needs for different third party tools, database solutions, report solutions etc
I installed Delphi 2010 after Delphi 2007 without any problems.
Just uninstalling gave me some problems (BDE had to be installed again).
My main suggestion would be to download the latest ISO for Delphi 2007 and Delphi 2010.
Don't rely on your installation DVD's if they aren't current. I used to have problems installing Delphi 2007...I bought my copy around the first month it was available...then I downloaded the latest ISO with all the updates and never had problems on Windows 7 Enterprise (32-bit).