> -----Original Message----- > From: David Sandberg [mailto:david.sandb...@hickorytech.com] > Sent: Wednesday, March 20, 2013 2:52 PM > > Thank you for that crystal clear explanation, which accounts perfectly > for the observed behavior. I will add that I am not sure I agree with > the correctness of that behavior, but that's only because it doesn't > happen to fit our operational model, in which we cherry-pick revisions > from the trunk into our release branch and then build archives for > deployment to customers. The problem is that the resulting deployed > files need to reflect the revision numbers that were committed into the > trunk ... or at least some newer revision number than in previous > builds. From what you've described, we could perhaps achieve that by > committing the merged set of files to our release branch before we > begin a build, but that seems like a backwards way to go about things > when we may find ourselves still needing to make updates as part of > completing the build, so we would be committing potentially broken > revisions in order to get these keyword substitutions to update before > the build process runs.
That's why we grab the 'Last Changed Rev:" of the root directory of the release tree and use that as the release number. The root revision is guaranteed to change if there's a change anywhere in its subtree. In my experience, trying to manipulate meta-data inside of the files is just not worth the effort except in one-off script files. Meaning, why are you storing information *about* the file *inside* of the file? (And even in the case of one-off files, I'm more interested in the svn URL than the actual revision number.) IMO, you would skip a lot of angst if you just update the keywords during your release packaging process, i.e. have your build/packaging script walk the files and update the "keywords" manually. Even so, keywords don't really provide much value, in that they don't tell you what the correct revision should be (i.e. is the correct release installed?) nor do they reveal file tampering (i.e. production changes.) IMO, you need to adopt a proper installer script and create an audit script. (Gnu tar has a --diff option, which gives you quick and dirty packaging, deployment, and auditing functionality.) Once you have those in place, the "need" for revision keywords goes away.
