Exiv2

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.

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.

There already is a working read-only git mirror at GitHub.

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.

Andreas said:

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.

Gilles said:

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.

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.