On 9/10/2015 1:03 PM, Ron W wrote:
On Thu, Sep 10, 2015 at 2:30 PM, Ross Berteig <[email protected]
<mailto:[email protected]>> wrote:
....
(Rant: Just when will IDE authors learn to prominently document
their project databases to make interoperation with any VCS easier?)
You mean so you more easily ignore or mark them as "binary"?
Yes, both, as needed.
This chip vendor supplied IDE is typical in my experience. It has a
project description file in some arbitrary textual format. It lists all
the source files, build parameters, and everything else needed to
actually build the HEX file you program into the embedded system.
Because it must have made the IDE developer's life easier, it also
creates a pile of undocumented binary and XML files. Those should not be
checked in as they are rewritten frequently while using the IDE and
don't control the actual build.
When you create a new project in the IDE, you get all of these files and
no description of which ones are original source code and which are
build products so that you can know that the repository really contains
everything needed to reproduce the build, and nothing that is going to
change just because someone sneezed.
(For example, this particular project builds three libraries and an
application. Of the 13 files belonging to the IDE, 5 hold lists of build
products, source files, build steps, and project options and clearly
belong in the repository. The remaining 8 include one INI file, 3 XML
files, and 4 SQLite databases. All those remaining 8 files are modified
just by opening the project in the IDE even if nothing else is done. All
appear to be recreated if missing, and hence need not be checked in.)
(Another rant: at least this IDE doesn't re-write the real project
description file in a fresh and arbitrary order every time you launch
the IDE. I worked with one that did that and also insisted on writing
all file names as fully qualified path names. It created extra chaff on
every checkin, and made it impossible to have multiple open checkouts on
the same PC without every checkin having guaranteed merge conflicts.
This added a lot of friction to my customer, and made it more difficult
than needed to deliver source code snapshots to my customer that could
be built by anyone other than me.)
IDE makers really should clearly document what files make up their
project metadata, and be careful to keep cosmetic parameters and caches
in separate files from the core project description.
Fossil itself has no IDE integration features.
Nope. And it really shouldn't need them.
The only thing the fossil community could do is keep some wiki pages
documenting what files are source code for various use cases so we had a
place to go look when forced to deal with a new and "wonderful" IDE.
Other notes that might be helpful would include ideas for things to put
in the *-glob settings, any other settings that prove helpful, ideas for
forcing the IDE to a sane(r) directory layout, notes on how to make it
cooperate with other build systems if possible, etc.
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
