Hello,
has anybody a good solution how to put the uVision project files under source control? We only want to store the information that is absolutely neccessary to rebuild the objects. We do not need informations how windows are placed - since this may be different from developer to developer and every time one checks in the project files get also checked in though nothing really has changed ...
We only want to store the information that is absolutely neccessary to rebuild the objects.
That would be source code files themselves and build instructions. The uVision project file stores more information than this. Perhaps you should not place uVision files under version control. Instead, write a Makefile. The only thing is, if you want to run a debugger you must have a project file.
Not sure if it is a good idea, but I store the *.Opt and *.Uv2 file in the repository.
When changing project options or adding/removing/rearranging source files, I retrieve the current version from the repository. Then I make the changes, saves the project and commit the changed files.
The *.Opt file contains a huge amount of noise, so I don't normally commit any changes.
Keil should have considered a separate desktop file for information about open source files or the current location/size of the windows.
The .opt file is supposed to be the one that contains just the "user" settings - but this is broken.
:-(
IIRC, the 8051 tools stored the XTAL value in the .opt file - though it should be a "Project" setting in the .uv2 file.
I've also found that keeping just the .uv2 file doesn't work entirely properly for ARM projects; eg, I think (but haven't bothered to confirm) that (some of) the debug settings are in the .opt file that should be in the .uv2 file - which means that debugging doesn't work properly after keeping only the .uv2 file.
My solution is just to ensure that all windows are closed before a check-in...
"We only want to store the information that is absolutely neccessary"
Why?
If you store a bit of extra information (eg, from the .opt file) that isn't strictly necessary, what's the problem?
On the other hand, if you omit something that later does turn out to be important - then it's too late!
Once it's gone, it's gone - so always better to store too much than too little!
Yes, this is the most annoying "feature"! sometimes I add files to a project and forget to close uv3 before the check-in. result? somebody else cannot build...!
Trying to normalize the *.Opt file before the commit will allow a diff to give at least some indication of what was changed.
UV2 & UV3 were the same; UV4 is different...
See: http://www.keil.com/support/man/docs/uv4/uv4_b_filetypes.htm
I seem to recall the promise that the new uVision project file format would be "Open" - but I see no evidence of that as yet...
No, this has nothing to do with building!
The .opt file records what files were open, and the positions of their windows.
The .uv2 file can use relative paths, so the project doesn't have to be always checked-out to an identical path, but the .opt file uses fully-qualified paths - so if someone checks the project out to a different path, you get a "cannot find file" message for each window it tries tp re-open. But this doesn't affect building - only the attempt to "re-open" the files that were last open.
Hence, of course, if there are no files open when you check-in, the problem doesn't arise!
Note that I never use the "integrated" source control - I always keep it separate. Dunno if that has any effect...?
True, but that is not what I meant: I was under the impression that project files are saved only after closing a project. thus, if one creates dependencies into C modules that are not part of the project files when the check-in is done, there is a problem.
No, that is not the case!
The project files are updated immediately the change is made.
IMO, this is a very BAD feature - because it means that there is no way to discard changes made to the project!!