Thanks, and nice to hear from you. I have managed to figure out a way to
construct the equivalent of a file UUID from client available info by
analysing the logs and constructing where files came from, including
copies or renames of parent directories. A file UUID isn't of much direct
benefit for most svn users. However, for any tool that is trying to
synchronize or connect data with svn, it can be very important. So I see
this more as a requirement or enabler for svn integrations rather than svn
directly. Since an svn copy is used often, and regarded as analogous to a
*Nix hard link, you'd expect to be able to see the equivalent of the
inode. Anyway, I can manufacture a file/dir UUID that seems to work for
my purposes. I was just surprised that there wasn't a client accessible
one built in.
Re: File UUIDs and equivalence
the same question kept me going round some time ago. We both know the
reason why :)
But the concept of svn is basically fixed to the idea of a logical
"change" entity what is represented to us as an "commit".
This idea seems having influenced implementation in a way what makes it no
more easy to identify single object entities.
One of the side effects is that building history of files is bound to
traversals through log entries.
I assume that a tremendous architectural change would be necessary to
satisfy the demand to have single object entity identification.
Ask Greg Stein, he should know it the best.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-07 12:06:29 CEST