|Re: [cdt-dev] What exactly is CDT core build?|
On 21 Aug 2020, at 14:59, Jan Baeyens <jan@xxxxxxxxxx> wrote: generated unique numbers and version control just don't mix nice.I can't talk for all plug-ins, but sane plug-ins generate these long and frightening IDs only once and do not change them later, so they can be safely stored in version control or local preference files. Since I had a chance to play with them while writing exporters from mBed and xPack Build to CDT, most of these IDs are just strings, that's nothing special with their content except their uniqueness within a domain.
The problem with this generated content I think of now are
1) they do not add value
-They are not user input so they should not appear in user input data storage.
2)They can and will cause confusion
- readability of the files is reduced. Users wander what these numbers are.
-Just suppose my system and your system use a different ID. We think we have the same data set but we do not.
3)consistency solutions will be hard
-If something goes wrong a new data set is generated (with the new id) and the old data just lingers on. Spreading via version control to all other systems
How would you get a different ID?
On way I can think of: Things don't work anymore so I create a new project and overwrite my local git repository files.
Then do a rebase and I'll have 2 sets.
But I'm sure there are other creative ways.
FYI consistency solutions are hard
Sloeber uses the eclipse/CDT API to create environment variables
and I see that I have already 3 ID's in org.eclipse.cdt.core.prefs
and it is not even under version control
This proof that the ID is not created once. That cleanup of
"outdated data" is not implemented.
Please check some prefs of your long running projects to see/report if this is common or not?
Regards, Liviu _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Back to the top