Hi All,
this is my first post in the development section. Hopefully its not inappropriate, since I do not think I am ready to really
join in developing for C::B. I downloaded the code, searched all posts about development documentation and read whats
in the Wiki. But beside the understanding why the major workings are in a DLL I did not succeed in much more than gaining
great respect to all of you who are able to work with that information in this code base. Maybe I overlooked something but
I saw a huge class list and code with almost no comments. I had no idea where to start and what the basic concepts are.
I guess a full time pro can read all this from the pure code, I just can't. Helps to gound oneselfs
.
Anyway, thats not what the post should be about. Its about how I work with profiles.
I am using C::B on multiple PCs and Laptops. I have a need to be able to install a working environment on a new system
quickly. Also I need to stop development on one PC, move into another room to a PC at the target hardware and continue
development/debugging/testing. I am sure I am not the only one with that requirements.
Beside using a centralized SVN/Git server I found its crucial to have C::B on all PCs looking the same.
For this I experimented a bit with different ways and have found a best way to do it. Since the forum gave me so
much help in the past, I feel this might be useful enough to share.
The basic idea is to use a file store to keep the master profile for C::B. Every PC is still using a local profile, however.
In very CB installation directory is a tool I call "Profile Manager". Its a simple batch tool, but could also be a plugin or exe.
It provides you with the following options:
1. Get Profile Update from Server (with backup)
2. Write Local Profile to Server (with backup)
3. Open Local or server Profile directory
4. View Server Log
Use cases:
- On a new installation I just open the tool, press "1", <Escape> and I can start working. It backs up the current profile
with date and time and overwrites the local profile with the server settings. A central log file on the server notes when
from which PC the update was done.
- Should I need to change something, say change Compiler Settings I do that locally, open the tool, press "2", are your sure "y",
Enter Comment <note what I changed>, <ESC>. The server profile has been backuped and then overwritten by the local
profile. The log entry tells me when I have done the change and what has been changed. With a link on the desktop the tool
almost as comfortable to use as with a plugin entry.
The log is very important, because it could happen that the server profile had been changed from another PC before and
this has not been downloaded to the local PC prior to the change. If I see the master profile is newer I can either download
and redo my change or see in the log what was done and just add that change and overwrite. It would be easy to build a
mechanism for checking that, but I can live well with that procedure.
Its pretty much the same way you work with SVN which makes it easy to adapt the processes.
Additionally I have a maintenance mechanism to keep a custom "Default" profile elsewhere on the server, so I could reset a screwed
Master profile in a similar way, but I did not need that yet.
I worked with that setup for a while and its working great. Over other solutions I see the following benefits
- works offline e.g. with Laptops
- works with multiple users
- no need to change the file associations, i.e if I double click a *.cpp or *.cbt C::B opens with the right profile. The suggested
way of using a central profile by command line option would fail here or require to manually set all file assocuations
on every pc used...
- logging and backups give you history and rollback
- the place where C::B is installed does not matter, because the profile directory this the same for a standard install and access
to the C::B directory is not required. Of course if you reference help documents one the drives, it would require to
standardize at least the place where to store those.
Since I use automated installation, my setups are identical on every computer.
- Works cross-platform, since the tool pulling is local and knows the rules on the local platform and can do any conversions
to the agreed server platform where required
I shortly thought about making this a C::B plugin, but as explained above I'm afaid its above my abilities and I needed a
production proof solution in a short time frame. However a plugin would have a lot more possibilities to recognize setup
changes and automate things, including rollbacks. But for a basic transfer of the my procedure to a plugin I think the most
complex is to provide the GUI for setting up the server path. For some it might be easier that setting up a batch file :-)
Hope someone finds this useful,
cheers,
Tiger
