Exiv2

Hi,

Robin Mills wrote:

svn_version.h is dynamically created by the build (using the svn command). There is a script svn_version.sh which is run to generate the file.

Try: $ make distclean ; make config ; ./configure ; make and everything should be OK. I think make rebuild is about the same.

I saw this script and the header is indeed created. I checked that I could find it in the repo with a `find` as soon as I encountered a compilation error (when I was compiling gexiv2). So it is created when I `make` BUT not installed when I `make install`.
The "not installed" part is the bug I was reporting.

I did submit a fix last week to the CMakeLists.txt to execute svn_version.sh (r3278 2014-07-17) - perhaps you need to sync and run cmake again to get that change.

No I checked out a brand new locale copy just like 1 hour before I wrote this report. So I believe I have the last version.

The team hasn't discussed changing the version control system. I recently started contributing to another project in which git is being used. When I'm more confident of my understanding of git, I'll give this more thought. I'm reluctant to change without a git guru on the team to keep us out of trouble. I'm sure that we'll move in time, For the moment, SVN seems OK to me. You are welcome to persuade me that we should adopt this in 2015.

I see many advantages to git: branches (which are not copy-paste of the whole tree, annoying to merge back to the main tree when it diverged a lot, etc.), working out of the network (it depends on people. Some are always connected. But I have regular occasions when I code without a connection. Not being able to check the logs, make diffs, checkout old commits, etc. makes life very complicated when working on a project with svn), very neat commit management, and so on.
Also I am always checking the right syntax to make and apply patches with svn. Do I have to patch p0? -p1? It depends on how the contributor made the patch. Etc. On git, you ask the contributor to `git format-patch origin/master` and you `git am the-contributed-patch.patch`, you check, optionally ammend the commit and you push. You even keep the commit description and the authorship of the commit (the contributor, not yours!), which is very appealing to contributors. I have contributed many patches to many svn projects, and except the ones where I had my own svn account, I don't have my name in the logs (it can be in a commit message, or in a README or CONTRIBUTORS or AUTHORS sometimes, if the project people don't forget to add it which don't happen that often actually, but not in the logical place: the commit author). I still contribute but you could say that's not as welcoming (so potentially less contributions). Which is also good for you, to efficiently manage your contributions (who wrote what?), etc.
And last but not least, I find git a lot easier. But this one may be because I have mainly coded on git projects in the last years, and have not come around many svn projects lately. So I kind of forgot most of what I used to know about svn. :)

Anyway I was just saying. I don't really plan on persuading you. Better managing your own project the way you like it. :-) I just had a few annoyances on your repo today and I was thinking that if it had been a git repo, I would have spent half the time I spent on it.

Oups did not see the next answer. Just ignore my last message.

Thanks for all of this, Jehan. I'm sorry to have inconvenienced you with both this issue and difficulties with svn. I really appreciate you letting us know. We aim to please and sometimes don't!

For sure, we have to consider git. Everybody who has adopted it, reports great happiness. It's not the pain of change that causes me to hesitate. It's the possibility of getting into trouble as we learn "the ways of the force.". I'll put this on the agenda for the next team meeting which will probably be to plan the v0.26 release. Currently we have a plan to release v0.25 in November.