-1

I write Android stuff using Eclipse+the ADT plugin. For VCS I use SVN.

What I am trying to accomplish: have my program, in its 'About' screen, display the SVN revision number it was built from. Obviously, this better be automatic. We cannot assume the program will have network access when run so this info has to be known at compile time.

Today I've been researching this topic and seems like this seemingly common scenario is actually not so easy to do or I am missing something. Lets see:

1) first approach: write a 'pre-commit' SVN script that, on each commit, would update a little file, that would be named 'revision' and would be located in the root of my project. Then writing a function that would open this file, read the revision number and put it in the 'About' screen would be trivial.

This doesn't quite work as the file would be updated server-side. So imagine this scenario: I check out rev. 3708, modify, commit, pre-commit creates 'revision' with '3709' in it. I build - and my local 'revision' still contains '3708'. Not good.

2) I hear ( Getting SVN revision number into a program automatically ) that SVN has this clever feature that it is able to replace various magic strings in your files, one of then being 'Revision', if one sets appropriate SVN metadata on all files in a project under SVN control.

This does not quite work again, because of the problem mentioned by user 'Smashery' in the link above - namely, SVN will only replace the 'Revision' magic string in files that got changed during the last commit.

3) Write a 'pre-build' Eclipse script, and have it run 'svnversion /path/to/your/project' and save output of this in /path/to/your/project/revision.

This does not quite work again - I mean, I have tried and writing such script is actually surprisingly easy. If I were working on a single computer, it would have worked for me - but unfortunately I work on two computers, one Linux machine in home and another Windows machine at work. I keep switching machines every day (during the day Windows, in the evenings Linux at home).

The problem here is with Eclipse: as soon as you add a 'pre-build' script, it creates a new hidden directory in your project folder ( .externalToolBuilders ) , which, among other things, contains the absolute path to the script to run (obviously). This path cannot be the same on both of my machines (being Linux and Windows). In order for things to be automatic, I need to check this in to SVN, and as soon as I do, things will work only on one of my machines unless I keep manually correcting the path every day!

Any ideas?

Community
  • 1
  • 1
Leszek
  • 1,181
  • 1
  • 10
  • 21
  • 1
    Use search!!! Inspect [this](http://stackoverflow.com/search?q=[svn]+subwcrev+svnrev) search-query at least here, on SO – Lazy Badger Oct 02 '15 at 09:06
  • 1
    JFYI http://stackoverflow.com/questions/23602145/maintain-and-automatically-update-a-file-containing-current-revision – Lazy Badger Oct 02 '15 at 09:27
  • Badger, if you actually read my post, you would have noticed that I did several hours worth of searching, and I read most of the posts from your search query. – Leszek Oct 02 '15 at 14:45

1 Answers1

0

Third way (slightly polished) can be and will be The Right Way, if you'll grok some things

  • Workplace specific settings must not be shared and stored in repository: ignore .externalToolBuilders on both locations but configure Eclipse differently according to your needs and settings
  • Except identical for all OSes svnversion (and don't forget ignore also /path/to/your/project/revision, because build-artifacts must not be part of repository) you may want to use more powerful somehow subwcrev (on Win-box) and svnrev (on Linux-box) in pre-build event - svnrev also contain some useful reading
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Ok, indeed you're right - .externalToolBuilders should not get checked in. This looks like the best option so far, although - to be quite honest, I still don't like it. The problem? It doesn't scale - you have to do it anew on each machine you use, so it is O(N) with N=number of developers (worse-number of machines the developers use). It would be better if one could come up with an O(1) (i.e. server-side or entirely hidden in the code) solution.... – Leszek Oct 02 '15 at 14:47
  • Hmm, the more I think about it, the less I like it. We don't have that many devs, but people come and go, change machines - and if getting the SVN revision in our 'About' dialog depends on all of them doing the right thing on all of their machines, I know this won't really work. How about 'automatically display SVN revision in 'About' dialog, in a O(1) way that does not depend on devs doing the right thing?' – Leszek Oct 02 '15 at 14:54
  • @Leszek - *Continuous integration* is answer, and|or transferring of build process from DEVs to single central point. Hand-made post-commit hook (always fire or on-demand) as initial temporary solution for the beggars – Lazy Badger Oct 02 '15 at 15:06