It seems like there is an issue with trying to version control Atmel Studio 7 projects...
The .cproj file is needed, without it the project won't be loadable when you open the solution in Atmel Studio. But this file contains some user specific settings like the selected debugger.
Am I missing something or is this an issue? Has anyone got a solution?
Am I missing something
No.
is this an issue?
Yes.
Sadly, it is an all-too-common issue with many GUI IDEs
You'd have thought the people who create IDEs - being programmers themselves - would understand this stuff.
<rolls-eyes>
But Microsoft do. It is usual to version manage the .vcxproj and .sln files in a project but not per user or intermediate binary settings files like .suo and so on.
Being modelled on VS2015 you would have thought Atmel would follow this pattern and keep the "fixed stuff" in files for version control and the "dynamic" stuff in other files to be added to your .gitignore (or whatever).
It is a shame if they have chosen to store something "dynamic" in the proj files!
(You can see a typical .gitignore for VS here: https://github.com/github/gitign... )
It is a shame if they have chosen to store something "dynamic" in the proj files!
One such thing they store is the serial number of the debugger that you last used!
I can't remember if it applies to AS/VS, but a trouble with Eclipse is that it may change the order of the data in its "project" files!!
I get irritated the other way around. In real Visual Studio the details you enter in a project for "Debugging" (exe to run, working directory, etc) get stored in the XXX.user file which does not get version managed. So every time I pull SLN/VCXPROJ files out of Git I find myself having to set things up again - quite tedious!
IMO the correct thing to do is to separate the the things that must stay the same for all developers from the things that are a specific developers preference, This caters for at least two scenarios:
In the first scenario the personal preferences file is not version-handled on the trunk or in "shared" branches. Nothing stops a user from versioning it in a personal/private branch. A bit of persuasive scripting will make the job of committing it, and merging it back to the developers working copy, relatively simple.
In the second scenario the personal preferences file is version-controlled.
Another alternative would be to rename the personal preferences file, e.g. to something with the user name in it, before commit - to make it unique. When checking out the project you'd get everyone's preferences, and rename your variant back to the generic name. Again, scripting could help here.
The last alternative I see would be to have an option in the generic project setup regarding where to store preferences (separate file or the generic project file). It could be done so that a personal preferences file would override anything in the generic file.
IMO, Microsoft got it largely right and Atmel less so.
[re]name the personal preferences file, e.g. to something with the user name in it
Isn't that what Cliff was talking about with the "XXX.user file" ?
But even that falls over with the debugger info for a single developer, who may have multiple debuggers; especially when the debugger is part of the board - as for XPlained-Pro ...
I don't mind having to set the debugger every time, what bothers me is that every time I work on the project on a different debugger and check it in I get a nice merge conflict to sort out.
what bothers me is that every time I work on the project on a different debugger and check it in I get a nice merge conflict to sort out.
Likewise.
Or your version-control client flags the project up as "dirty", so you have to go and look for what's changed - only to find that it's just that you used a different board/debugger.
Already a known issue (AVRSV-7844).
Is there a web site where that bug can be tracked? The old bugzilla seems to be abandoned.
It's been known for a loooooooooooooooooong time - I remember it back in 2015!
Already a known issue (AVRSV-7844).
awneil wrote:It's been known for a loooooooooooooooooong time - I remember it back in 2015!
and it's just come up again: https://community.atmel.com/foru...
