On 03/20/2013 02:52 PM, David Sandberg wrote:
> 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.
Yeah, so you've cherry-picked changes and applied them to some base
revision. I think that, given some thought, you would agree that it would
be incorrect for Subversion to claim that your working file is now "at" the
revision you cherry-picked. I mean, to be "at" revision N implies that a
file's history contains every change N, N-1, N-2 ... all the back to the
file's origin.
> 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.
Hrm. It seems to me you're placing far too much stock in the revision
number, attributing descriptive powers to it for which it was never designed
and is ill-suited to provide.
Revision numbers alone cannot uniquely describe anything. You can have 15
files, each in one of 15 branches, each of which has slightly different file
contents from the next ... and yet all 15 variations could carry the same
$Revision$ keyword value (perhaps because all 15 copies were modified in the
same revision). In such a scenario it becomes obvious that a revision
number alone is insufficiently as a unique representation of that any one of
those files.
Rather, I would suggest that any attempt to uniquely identify a file's
version include not just its revision number but also its path in the
repository. path_at_rev is a truly unique coordinate in the Subversion
repository. That might mean employing unique tags for your deployed
configurations which are created directly from your cherry-pick-carrying
branch working copies.
$ svn checkout BRANCH_URL branch-wc
$ svn merge [WHATEVER] SOURCE_URL branch-wc
$ svn copy branch-wc ^/tags/MY_CUSTOM_TAG \
-m "Tag baseline XYZ + cherry-picked revisions N, M, P, and Q"
Given such tags and the use therein of, say, the $URL$ keyword (instead of,
or in addition to, the $Revision$ one), uniqueness can be achieved.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-03-20 20:08:03 CET