David,
Please don't top post on the svn lists.
That's correct, it's only visible through the svn_fs.h API so you need
direct access to the repository. The node-ids are in all backends;
it's part of the Subversion API so needs to be supported in any backend.
Regards,
Blair
On Jul 31, 2009, at 9:17 AM, David Honey wrote:
>
> 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,
> Blai
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2377487
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-31 18:36:47 CEST