If your client is showing the revisions for all of those files then the "first" was created using "svn add" but the others were created using "svn copy".
[QUOTE=DougR;n80670]If your client is showing the revisions for all of those files then the "first" was created using "svn add" but the others were created using "svn copy".[/QUOTE]
Yes, this is actually the case.
Instead, I expect that, if I used "svn add" first in the trunk, then in a branch (a branch created before adding the file to the trunk) I would create 2 "evil twins", a well known scenario in source control management, i.e., 2 files with the same name, but with different internal identifiers.
How can I distinguish between the 2 scenarios without opening the revision graph? Is there a svn, svnlook, svnadmin command that proves that file.txt under the trunk and file.txt under a branch are actually 2 different files, and not 2 revisions of the same file?
While you may create an "evil twin", as long as the contents are identical and the rep-cache is turned on then you should add another "copy" of those bits to the repository.
In terms of "evil twin", the problem is always more complicated than 1st considered. For instance, adding another copy of the same file by another name (the rep-cache will still catch this). And then there's the case of *needing* multiple files with the same name (e.g. "Makefile").
As far as I know, there's no externally visible "unique" ID available for each file/directory other than the Revision - at least not via the command-line tooling.