You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andreas Kreß <an...@HOOD-Group.com> on 2009/08/07 08:28:57 UTC

Re: File UUIDs and equivalence

<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><div><br>Hi David,<br><br>the same question kept me going round some time ago. We both know the reason why :)<br>But the concept of svn is basically fixed to the idea of a logical "change" entity what is represented to us as an "commit".<br>This idea seems having influenced implementation in a way what makes it no more easy to identify single object entities. <br>One of the side effects is that building history of files is bound to traversals through log entries.<br><br>I assume that a tremendous architectural change would be necessary to satisfy the demand to have single object entity identification.<br>Ask Greg Stein, he should know it the best.<br><br>cu,<br><br>Andreas<br><br><br>PS: nice to hear from you after this many years<br><br><br><br><br><br><br><div>Andreas&nbsp;Kreß<br>HOOD&nbsp;Group<br>Office&nbsp;München<br>Keltenring&nbsp;7<br>D-82041&nbsp;Oberhaching<br>phone:&nbsp;&nbsp;00&nbsp;49&nbsp;&nbsp;&nbsp;89&nbsp;&nbsp;4512530<br>mobile:&nbsp;00&nbsp;49&nbsp;173&nbsp;676&nbsp;8370<br>fax:&nbsp;00&nbsp;49&nbsp;89&nbsp;45125319<br><br><br><a href="mailto:Andreas.Kress@HOOD-Group.com">Andreas.Kress@HOOD-Group.com</a><br><a href="http://www.HOOD-Group.com">http://www.HOOD-Group.com</a><br>PGP&nbsp;Hash&nbsp;:6884BF8D77EAAE600510C4DD12E7A269FEE8B1E3<br><div><br></div><font color="#990099">-----David Honey &lt;david.honey@uk.ibm.com&gt; wrote: -----<br><br></font><blockquote style="border-left: 2px solid #000000; padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">To: users@subversion.tigris.org<br>From: David Honey &lt;david.honey@uk.ibm.com&gt;<br>Date: 07/30/2009 05:52PM<br>Subject: File UUIDs and equivalence<br><br><br><font size="2" face="sans-serif">When a user performs an 
<i>svn copy
</i>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.
</font><br><br><font size="2" face="sans-serif">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:
</font><br><br><tt><font size="2" face="Courier New,Courier,monospace">cd &lt;workingcopy&gt;/trunk
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn mkdir xxx
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn mkdir xxx/a
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">touch xxx/a/xxx.txt
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn add xxx/a/xxx.txt
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn mkdir xxx/b
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">touch xxx/b/xxx.txt
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn add xxx/b/xxx.txt
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn commit -m "setup example start"
</font></tt><br><br><tt><font size="2" face="Courier New,Courier,monospace">svn mkdir yyy
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn copy xxx/a yyy
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn commit -m "copy dir"
</font></tt><br><br><tt><font size="2" face="Courier New,Courier,monospace">svn rename yyy zzz
</font></tt><br><tt><font size="2" face="Courier New,Courier,monospace">svn commit -m "rename dir"
</font></tt><br><br><font size="2" face="sans-serif">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:
</font><br><tt><font size="2" face="Courier New,Courier,monospace">svn log zzz/a/xxx.txt
</font></tt><br><font size="2" face="sans-serif">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 
<i>zzz/a
</i>. 
</font><br><br><font size="2" face="sans-serif">Is there an easy way of doing this?
</font><br><font size="2" face="sans-serif">For example, if there was a UUID for
files and directories, it would be trivial. But I cannot find anything
equivalent.
</font><br><br><font size="2" face="sans-serif">Or is it as brutal as having to traverse
not only the logs but also the parents and their logs?
</font><br><br><font size="2" face="sans-serif">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.
</font><br><br><font size="2" face="sans-serif">Thanks,
</font><br><font size="2" face="sans-serif">David.
</font><br><br><font size="2" face="sans-serif"><br></font><br><font size="2" face="sans-serif"><br></font><hr><font size="2" face="sans-serif"><br><i><br></i></font><br><font size="2" face="sans-serif"><i>Unless stated otherwise above:<br>IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
</i></font><br><font size="2" face="sans-serif"><br><br></font><br><br><font size="2" face="sans-serif"><br></font><br></blockquote><br></div></div></FONT>__________________________________________________________<BR>
<BR>
Mehr als 20 Jahre Erfahrung in RM&amp;E - <BR>
Requirements Management &amp; Engineering <BR>
<BR>
******* Veranstaltungen und Trainings ************<BR>
REConf Schweiz - 22. - 24. Sept. 2009 in Zürich<BR>
http://www.reconf.ch<BR>
<BR>
Termine zu aktuellen Trainings im RM&amp;E unter <BR>
http://Schulungsprogramm.HOOD-Group.com/ <BR>
<BR>
The information in this e-mail (which may include files transmitted with it) <BR>
is confidential and is intended for the addressee(s) named above only. If you <BR>
are not named as an addressee you are to maintain confidentiality and must notify <BR>
the author immediately, destroy any copies and delete the e-mail from your computer.<BR>
<BR>
The information in this e-mail is not to be relied upon by any person other than <BR>
the addressee(s) except with prior written approval. If no such approval is given <BR>
the author will not accept any liability (in negligence or otherwise) arising from <BR>
any third party acting on such information.<BR>
<BR>
HOOD GmbH<BR>
Amtsgericht München<BR>
HRB 139 127<BR>
Geschäftsführer: Colin Hood, Rupert Wiebel <BR>

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].


Re: File UUIDs and equivalence

Posted by David Honey <da...@uk.ibm.com>.
Hi Andreas,

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.

Kind regards,
David. 



From:
Andreas.Kress@HOOD-Group.com
To:
David Honey/UK/IBM@IBMGB
Cc:
users@subversion.tigris.org, dev@subversion.org
Date:
07/08/2009 09:29
Subject:
Re: File UUIDs and equivalence




Hi David,

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 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].