> Perhaps the most non-obvious-yet-useful thing folks need to understand about
> Subversion and keywords is this: the Subversion server knows *nothing* about
> keywords or the substitution thereof.
>
> When keyword substitution is enabled, the Subversion client will substitute
> keyword values into placeholder locations embedded the file when copying
> the working file out of the "pristines" area of the working copy administrative
> subdirectory. When you commit changes to such a file, the client first
> un-substitutes the keywords found therein -- leaving only the keyword
> placeholders -- before transmitting those file changes up to the server.
> If the commit is successful, the Subversion client will again re-substitute
> your keywords into the working file, this time with an updated revision and
> last-modified stuffs. Likewise, when you update the file to receive someone
> else's changes, the client re-substitutes the keywords in the working file
> with the updated metadata.
>
> This is why your user isn't seeing updated revisions in his keywords after
> performing a merge -- because the line which contains those keywords in the
> file didn't *really* change from the server's point of view. It only appears
> to change on the client side because the client keeps refreshing that line
> of the file when required by changes to the file's local version.
>
> You should find that after accepting the merge from the server, the keyword
> remains unchanged in your working copy, but that after committing the merged
> changes, the working copy file is updated to reflect the new version you've
> just committed.
Michael,
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.
Anyway, at least now we know what is going on here, and can explore process
Changes or workarounds for our needs. Thanks again!
- David Sandberg
Received on 2013-03-20 19:51:49 CET