Please explain the RCSID macro at the start of every .cpp file.
|Status:||Closed||Start date:||25 Oct 2015|
|Assignee:||Andreas Huggel||% Done:|
|Category:||miscellaneous||Estimated time:||2.00 hours|
Currently a lot of .cpp files have some EXIV2_RCSID include/macro at the very top. It's fine if those lines are needed.
But: Do we really need to include that Id in its expanded form into the repository?
#include "rcsid_int.hpp" EXIV2_RCSID("@(#) $Id: basicio.cpp 3991 2015-10-13 21:19:25Z robinwmills $")
#include "rcsid_int.hpp" EXIV2_RCSID("@(#) $Id: error.cpp 3777 2015-05-02 11:55:40Z ahuggel $")
Configure scripts / CMAke should be used instead
#1 Updated by Robin Mills about 2 years ago
- Status changed from New to Feedback
- Assignee set to Andreas Huggel
The EXIV2_RCSID stuff has been there since before I joined the project. I believe it has some magically version control property when compiled by GCC. You'll see I added something to neuter it for Clang and Visual Studio.
Andreas has strongly defended this in the past. So, I'll ask Andreas for feedback concerning this.
#3 Updated by Andreas Huggel about 2 years ago
This is just an old convention to 'stamp' each file that is compiled with some versioning info. It allows you to do something like
$ strings /usr/local/lib/libexiv2.so | grep '@(#)'
to get a list of all the compilation modules with their revisions that make up the particular library you're using. Some kind of inventory if you like, which can be useful for debugging when you're not sure what version of the software you're looking at. I added that originally because it had proven crucial in some other projects I worked on in my early days as a developer. Those were much bigger projects than Exiv2 and it was not so simple to just ask clients to compile the trunk and try with that instead. I don't think I ever actually needed to use it with Exiv2.
There is no magic involved, other than some contortions to avoid duplicate symbol errors and compiler warnings about an unused variable while still making sure it actually compiles. It just adds a variable with that string to the code. That is independent of the compiler. It only depends on the version control system (SVN) to expand the $Id$ tag.
That macro has generally not resulted in any problems as far as I know and it doesn't do any harm, although Robin's experience may be different, and although I don't feel as strongly about these strings as I used to, I also don't see why we should remove them. The argument given in this issue seems vague. Repository files only contain the string '$Id$', not in its expanded form as claimed, and SVN only expands it when you check it out from the repository. You may also want to explain 'Configure scripts / CMAke should be used instead' and show what you have in mind.
#4 Updated by Robin Mills about 2 years ago
- Subject changed from Please explain the RCSID at the start of very .cpp file. to Please explain the RCSID macro at the start of very .cpp file.
- Category set to miscellaneous
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
- Estimated time set to 2.00
Thanks for the explanation, Andreas.
I wrote a utility 'vercheck' that was used by many projects at Adobe to test version strings in all manner of files. It was a kind of 'strings on steroids'. The utility read vercheck.txt in any/ever directory of a project and searched for the string
@ in every file listed. It's remarkable some of the stuff it discovered. You need something like this to manage a monster like Acrobat with 25 million lines of code, 10,000 .cpp files and probably another 10,000-20,000 files of localisation, installers and stuff. There is no way for anybody to understand or know all about the beast.
I'm closing this issue. No further discussion of this matter is constructive.
#6 Updated by Andreas Huggel about 2 years ago
Just a last comment: The entire concept of each file having a version number is an old-fashioned notion from the SCCS and RCS days. It doesn't make sense with today's distributed source code management systems. So this macro will become obsolete latest when we move from SVN to such a tool.
#8 Updated by Robin Mills about 2 years ago
We have no plan to move to GIT at this time. This matter was discussed about a year ago. http://dev.exiv2.org/boards/3/topics/1786?r=1792#message-1792
I will admit that I don't know GIT and believe it has a considerable learning curve. I'm happy with SVN. As the main contributor to exiv2, I don't want to use such a complex tool without support from another team member.
I agree with Gilles: Git is not a simple tool, and I have no problem getting myself into a situation where I don't know what to do anymore after issuing just a few git commands.
As KDE developer who has follow svn to git transition, i can said, that git, is powerful, but too powerful. It's a bulldozer to make a small hole (if i talk about Exiv2 project). This tool is perfect to manage huge projects, with a large amount of developers / contributors (as Linux), but for medium and small projects, git is not very well adapted.
#10 Updated by Robin Mills about 2 years ago
Thanks for the cartoon, Thomas. That just about sums up GIT.
I've been developing software for a living for 30+ years and have heard many stories about how the world would be a better place if I used ... Pascal, C, UNIX, X-Windows, C++, OO, Windows, Obj-C, Perl, Java, Python, Ant, CMake, RCS, CVS, SVN, GIT, vi, Emacs, Visual Studio, Eclipse, Xcode and on and on and on. I know the pain involved in adopting new tools. I've seldom seen much gain. In the case of moving from SVN to GIT, I'm sure one day Exiv2 will use GIT. However, while the number of contributors is (1-4 contributors/month making about 25 commits month), I don't see any gain. There's a lot of work to be done for v0.26 and learning GIT isn't on my list.
My open source buddies on CopperSpice (an amazing rewrite of Qt in C++11) say "you have months of bewilderment with GIT and one day you just get it". I have no desire to be bewildered by the tools for months.
This sales pitch about "you won't believe how good the new tools are" is never true. It is a move from one bed of nails to a different bed of nails.