Real Simple Version Control

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on a project involving identical code on multiple, networked processors. I could use some sort of version info to keep track of how up to date the code is in each processor.

What I'd like is is a variable generated by the compiler that can be inserted in the code (as a constant) then read and displayed by the processor. Said variable would be incremented every time there is a successful compile.

I'm not interested in a full RCS.

I'm developing on a Mac using CrossPack-AVR, gcc 4.3.3 and make, from the command line.

TIA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cmartin wrote:
I'm not interested in a full RCS.

This makes me sad. Subversion is so simple, even our non-engineers use it. There is a mac, windows and linux port. Setting a repository involves the following convoluted set of commands:

svnadmin create /path/to/repository_name

then working with it is easy....

svn co svn+ssh://username@host/path/to/repository_name

The solution we have to the software build number problem is to use a build server. In our case, we use TeamCity though there is a huge number of options to choose from.

Every time we check in code to svn, TeamCity builds it. Every time it builds it, it adds the following to the gcc -o line (or makefile, or whatever you setup):

-DAVR_SOFTWARE_VERSION="$BUILD_NUMBER"UL

That is, it is the equivalent of:

#define AVR_SOFTWARE_VERSION  "$BUILD_NUMBER"UL

Of course $BUILD_NUMBER has the build number being made by TeamCity. We make them whole numbers, though you can make them strings or whatever you choose.

We literally have dozens of projects using this method. It works... and we can trace the EXACT source code for EVERY build that we have out there. Released to customers, internal testing versions or unstable developer builds.

What's there not to like?

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I downloaded FatFs I thought it would be good to track changes so I installed Tortoise/SVN - it took about 15 minutes to set it up and get it working. But as Paddy says, if the only goal here is to get a unique ID into each build then __DATE__ and __TIME__ are probably all you need.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the RCS side, I tried TortoiseCVS but got all kind of problem creating a local repositery, I tracked it down to CVSNT which is a free GPL software that you have to buy for 426£, LOL?

Then I installed TortoiseSVN in Windows, so easy to use, in 30 minutes I had a repositery, commited files, tagged, etc. And it's free.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
When I downloaded FatFs I thought it would be good to track changes so I installed Tortoise/SVN - it took about 15 minutes to set it up and get it working. But as Paddy says, if the only goal here is to get a unique ID into each build then __DATE__ and __TIME__ are probably all you need.
It would be nice if each unique ID described a unique build, too. Unless I'm missing something, though, the suggested DATE/TIME approach will assign a different "unique ID" to each result of a "make clean; make" sequence, even though the object code will turn out exactly the same each time (except for the versioning information, of course).

I use an approach I described here recently that won't issue different IDs to identical builds. The one outlined by damien_d sounds better still, if it never relablels a version, but I couldn't quite tell if that was so; we use a different configuration management tool.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

to each result of a "make clean; make"

That's why you don't "make clean". With "make" alone it only rebuilds if something has changed. That's the whole point of using "make" in the first place.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

to each result of a "make clean; make"

That's why you don't "make clean". With "make" alone it only rebuilds if something has changed. That's the whole point of using "make" in the first place.
And you should never need to reboot your computer, and other wishful thoughts. But occasionally I find I do want the assurance of going back to the primary human-authored files, or a different developer is rebuilding the application in their own snapshot directory, or we tweaked something in either a library archive or the makefile itself. I don't remember all the (admittedly infrequent) circumstances in which I find it convenient to do a "from-clean" make, but I do occasionally find it so.

And if you never do a clean, then how do you arrange your code so the single file that contains the DATE/TIME representation is the only one that you need to maintain? If a change needs to be made in someComplexAlgorithm.c, but that isn't where the DATE/TIME strings are stored, what clues your "make" in that it should rebuild theDateStampedModule.o also? Do you routinely "touch" theDateStampedModule.c after any compilation of any other .c file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Do you routinely "touch" theDateStampedModule.c after any compilation of any other .c file?

That is what I've done in the past but I wasn't smart enough to make the rule only run if something else has actually changed so it was no better than your "make clean; make" suggestion ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Levenkay wrote:
If a change needs to be made in someComplexAlgorithm.c, but that isn't where the DATE/TIME strings are stored, what clues your "make" in that it should rebuild theDateStampedModule.o also?
I see multiple possibilities to achieve that. E.g.:
Don't put theDateStampedModule.c into SOURCES and don't put theDateStampedModule.o into OBJECTS. Instead put a compiling command of it into the linking target (the linking target normally depends on the OBJECTS).

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's another option, though it relies (once again) on subversion.

In my avr makefile, I have the following line:


# Build versions and build version types
BUILD_VERSION=$(shell scripts/set_avr_version.sh)
BUILD_VERSION_TYPE=$(shell scripts/set_avr_build_type.sh)

# 

# Version number definitions
CDEFS += -DBUILD_VERSION=$(BUILD_VERSION)UL
CDEFS += -DBUILD_VERSION_TYPE=$(BUILD_VERSION_TYPE)

The build type checks if it is a clean version, or if changes have been made, or it's been built by TeamCity.

The shell scripts can do whatever. It might be as simple as reading a file with a number, incrementing it, then writing the new number back into the file.

Hence, a new number for every compile.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in my Makefile I have this:

all: svnrev build sizeafter

svnrev:
	SubWCRev . version.tmpl version.h

version.tmpl is a simple

#define LSVNREV "$WCREV$"

and I include version.h in some .c, it works for me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Do you routinely "touch" theDateStampedModule.c after any compilation of any other .c file?

That is what I've done in the past but I wasn't smart enough to make the rule only run if something else has actually changed so it was no better than your "make clean; make" suggestion ;-)

fred.elf: $(FRED.Os)
avr-gcc -o $@ datetime.c $(FRED.Os) $(LD_FLAGS)

# IF it's worth it
greg.elf: $(GREG.Os)
cat $(GREG.SRCs) | md5sum | cut -d=\   -f=1 | sed -e s/^/char md5sum[]="/  -e s/$/";/ | avr-gcc -o $@ -x c - $(GREG.Os) $(LD_FLAGS)

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paddy wrote:
You know of the existence of __DATE__ and __TIME__ ?

Well I do now. I just tried it and that does just what I needed. Thanks.