[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn feature request: RevisionAdded keyword

From: Bret Mogilefsky <mogul_at_gelatinous.com>
Date: 2003-11-06 14:02:59 CET


So I'm collaborating on code for a db-backed website. When someone does
an update in their sandbox or even just copies the new version of the
code over a live installation, out-of-date databases in use
automatically have their schema updated to reflect changes required by
the new code. (This is triggered during the first page hit, not during
the update from the repository.)

The convention we use to implement this is simple: If you change the
database schema, you must increment the version number, n, that the code
expects to find in the database, and add an update script that registers
a function to transform an existing instance of db n-1 up to db n, ie:
        updates[_n_]=function () {...}

On any page view, a mismatch between the version in the database and the
version in the code triggers a process where
        1) all of the update scripts are read in so the update functions are
indexed, and
        2) those update functions stored at an index higher than the n actually
in the database are executed in numeric order.

Works great...

Unfortunately, there's a problem. When multiple people are making db
schema changes at the same time, whether on the same branch or not, they
both increment the expected version number and use it as the index at
which their update function will be stored. Inevitably there will be a
collision or the two numbers will be end up out of sync (either by
interleaving half-complete changesets or by a screwup during a merge).

Say there was a keyword "RevisionAdded" which would be substituted by
the revision number where the file containing it was first added to the
repository. Then you could write your update script as:
        updates[revnumber('$RevisionAdded$')]=function () {...}
...where function revnumber() just returns what's after the colon.

Then by virtue of the way svn numbers revisions (monotonically
increasing no matter what parts of the tree or its branches they
affected), each update function will get a unique index, and when merges
happen, the merged code will still execute update functions in the order
that they were committed. This way humans are removed from the process
and we can sure it won't generate a collision.

I searched all the svn docs I could find and looked in the issue tracker
for similar requests. This was the closest I found:
("keywords that expand just once, on commit")

However, this request is different as subsitution does not need to be
done before the commit is finalized.

I'm sure there would be some similarly useful ways to use this
keyword... Please consider adding it in a future version.


Bret Mogilefsky <mogul@gelatinous.com>
International House of Mojo
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 6 15:35:06 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.