Appion

OK, there are about 5 different ways that we are storing and retrieving the revision information. Myamiweb uses the XML file located under myamiweb/xml, and so does dbschema updates. This revision number is added to the project database install table. Appion looks up the information in the svn files, and uses that to create a version.txt file stored under appionlib which is used to add the revision number being used for processing runs to the ap databases. Leginon also has its own functions for getting version information.

To fix the current bug, I added the version.txt file to source control, which will be manually edited prior to release. If svn information is available at the time the file is being used, the current svn revision is appended to one already available in the text file.

This is really not an ideal fix. I would like the whole process to be automated to eliminate user error during release packaging, and I would like to simplify the way that we are handling tracking the current revision. It seems silly to use so many different mechanisms. Perhaps we could create a versioning library in pyami that all the projects could use.

1. do a fresh install using the svn trunk.
   

   svn co http://emg.nysbc.org/svn/myami/trunk myami/
   

2. ensure the proper revision is stored in appionlib/version.txt
3. get the code from svn using the export function which removes svn files.
   

   svn export http://emg.nysbc.org/svn/myami/trunk myami/
   

4. do a fresh install the svn-less version
5. ensure the proper revision is stored in appionlib/version.txt
6. remove the version.txt file and ensure an exception is thrown.

You can follow the appion upgrade directions to install appion.

Tested, was not updating file for svn checkout due to logic error. Updated code for simplicity:

def getVersion():
    verfile = 'appionlib/version.txt'

    # Get the revision from any available svn file first
    version = getSubversionRevision()
    if version is not None:
        # write version to file
        f = open(verfile, "w")
        f.write("%s\n"%(version))
        f.close()
    else:
        # Check the version in version.txt
        if os.path.isfile(verfile):
            f = open(verfile, "r")
            line = f.readline()
            f.close()
            version = line.strip()

    if version is None:
        raise VersionError, "Could not find Appion version number while checking svn info and appionlib/version.txt." 

    return version

This changes the behavior a little. Instead of logging the version in distutils.core.setup() as r123245-r12346 in the case that there is an svn revision AND a revision stored in the text file, it will only log the svn revision (ex. r12346). I don't see an issue with this, let me know if you do.

This also needs to be merged to the 2.1 branch.

Please see Bug #469 for the version.txt file. This was my solution to have a 2.0, 2.1 version rather than just the subversion version.

Aha, so it looks like we always needed to put a version.txt file (with 2.x.x versions) into the release packages, but that bit never made it into the release process before. And it looks like we have some version functions in pyami as well as everywhere else :) Definitely need to do some consolidation if it is at all possible.

So, I'm thinking we can leave the version.txt file code as is, with my recent changes, but maybe there is a question about whether we should use 2.x.x versions for releases, or add the svn revision number to the file. Since we need to do it manually, it seems it would be just as easy to do either one. I like using the svn revision...not sure there is any specific benefit to it though.

Thoughts?

The svn revision is not enough, because it does not tell you which branch you are using. So, IIRC, the program grabs both the version.txt and svn revision and inserts them into the database. So, we know the branch and the last checkout. We did not have a version.txt in the trunk, because it did not have a version associated with it.