Bug #974

svn_version.h not installed, but included in installed version.hpp

Added by Jehan Pagès about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:24 Jul 2014
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:build
Target version:0.25

Description

Hi,

I'm a GIMP dev and I was updating some of the dependencies on my locale environment.
I noticed that the header version.hpp would #include "svn_version.h", but that "svn_version.h" is not amongst the installed headers. Well as you guess, that breaks when a third party uses Exiv2. :-)
Easily fixed by adding svn_version.h in the installed files (just adding it in the LIBEXIV2_HDR list in src/CMakeLists.txt seems to do the trick).

Thanks!

Jehan

P.S.: does Exiv2 plan to ever pass to git or any other decentralized versionning system?

History

#1 Updated by Robin Mills about 3 years ago

  • Category set to build
  • Status changed from New to Assigned
  • Assignee set to Robin Mills

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 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.

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.

#2 Updated by Robin Mills about 3 years ago

  • Target version set to 0.25

Ah, Jehan

Thanks very much for reporting this - and for providing the fix! I've just understood what you've said about LIBEXIV2_HDR. Quite so, I didn't think of that. I've added a fix. r3284

As you requested, I deleted your message on the Forum about this matter. If you wish to start a team discussion about adopting git, can you kick that off on the Forum.

Robin

#3 Updated by Robin Mills about 3 years ago

  • Status changed from Assigned to Resolved

#4 Updated by Jehan Pagès about 3 years ago

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.

#5 Updated by Jehan Pagès about 3 years ago

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

#6 Updated by Robin Mills about 3 years ago

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.

#7 Updated by Robin Mills over 2 years ago

  • % Done changed from 0 to 100

#8 Updated by Andreas Huggel over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux