Will a merge always update the revision number of a file?

Lets say that I'm merging a directory from branch-alpha into trunk. There is a new file called phi.txt in branch-alpha that will be merged into trunk. Will the revision of phi.txt change?

I sense terminological/conceptual problem ;-)

In Subversion, files do not have revision numbers (as opposed to, say, CVS). Revision number is a property of a commit.

But, any given file might be present or absent in a particular revision, and have a particular state in it.

Say, given a series of revisions …→@10→@11→@12…, a particular file might have been changed in the @11th revision, but you still are able to refer to the contents of that file using any of these revision numbers, just referring to that via @10 will give the "old" contents, and via @11 and @12 will give the "new" (and the same) contents—that is, until some future revision, @N in which that file will be changed again. And then referring to it via some past revision @P P<N will refer to the file's contents as found in rev. @11, and using future revision numbers @F F>N will refer to its contents as recorded in @N.

Answering the question directly now:

• The contents of the file may change if and only if it will be updated by that merge.
• The merge will definitely create a new revision, but that will be the repository-wide revision, not a revision of that particular file (or any other file in the repositry).
• After the merge, if the file's contents was updated, referring to it via the merge commit's revision number will refer to the updated file's contents, and referring to it using, say, the revision number immediately preceding that of the merge commit will refer to the file's "previous" contents.

Just in case you didn't know, you can refer to the state of a particular file as found in a particular revision using path/to/the/file@rev like in app/js/foo.js@12345.

Is it clear now?