[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: File UUIDs and equivalence

From: David Honey <david.honey_at_uk.ibm.com>
Date: Fri, 31 Jul 2009 17:17:50 +0100

Thanks Blair.

However, if I understand correctly, you can only see this information on
the server, and not on the client.
Client users might not have any direct access to the file system on the
server hosting the SVN repository.

Is there no easy way for a client to determine such equivalence or get a
file UUID?
Also, are node IDs only applicable to repositories created on FSFS? Or are
they available with BDB as well?

Thanks,
David.

From:
Blair Zajac <blair_at_orcaware.com>
To:
David Honey/UK/IBM_at_IBMGB
Cc:
users_at_subversion.tigris.org
Date:
30/07/2009 18:42
Subject:
Re: File UUIDs and equivalence

David Honey wrote:
>
> When a user performs an /svn copy/ of a directory, exactly the same
> versions of children are copied to the destination directory. This means

> that the same file (or directory) version might be located under many
> different paths of the repository. What I'm looking for is a way to
> determine a UUID for a file or directory so that when viewed from any of

> the paths (and peg revisions) in the repository that use that same
> object, you would see the same UUID. However, I cannot see any easy way
> of doing this.
>
> SVN must be keeping track of this internally. If you show the log
> entries for the file under the copied directory, you can see the entries

> for the copied parent directory as well as the log where the file was
> originally created under its original path. However, connecting all of
> these up are non trivial. Let me give an example:
>
> cd <workingcopy>/trunk
> svn mkdir xxx
> svn mkdir xxx/a
> touch xxx/a/xxx.txt
> svn add xxx/a/xxx.txt
> svn mkdir xxx/b
> touch xxx/b/xxx.txt
> svn add xxx/b/xxx.txt
> svn commit -m "setup example start"
>
> svn mkdir yyy
> svn copy xxx/a yyy
> svn commit -m "copy dir"
>
> svn rename yyy zzz
> svn commit -m "rename dir"
>
> Now at this point, file at the repository path /trunk/zzz/a/xxx.txt is
> the same object as at /trunk/xxx/a/xxx.txt. However, determining this
> does not appear to be easy. If you do:
> svn log zzz/a/xxx.txt
> you can see the changes going back to the first revision. But it's not
> obvious which of the two files named xxx.txt in that log correspond to
> one under /zzz/a/.
>
> Is there an easy way of doing this?
> For example, if there was a UUID for files and directories, it would be
> trivial. But I cannot find anything equivalent.
>
> Or is it as brutal as having to traverse not only the logs but also the
> parents and their logs?
>
> The background behind the question is about exchanging data with other
> tools and avoiding creating duplicate objects in those tools for what
> are essentially the same object with the same set of SVN properties.
>
> Thanks,
> David.

The Subversion backend has a node-id for each file and directory in the
repository and when something is copied inside a directory than its
node-id does
not change. The node-id is not visible from the client.

$ rm -fr repos/
$ svnadmin create repos
$ svn co file://`pwd`/repos wc
$ cd wc/
$ svn mkdir trunk tags branches
$ svn ci -m ''
$ cp /etc/motd trunk/
$ svn add trunk/motd
$ svn ci -m ''
$ svn update
$ svn cp trunk branches/b1
$ svn ci -m ''

Then looking at the repository you can see that the motd file has a the
same
node-id in both trunk and the branch:

$ cd ..
$ svnlook tree --show-ids repos

Regards,
Blair

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2377479

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-31 18:33:17 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.