On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> Ph. Marek wrote:
> >Regarding the way resource forks and xattrs could be done in the
> > repository I'd like to present an idea.
> >
> >First I assume the standard layout in the repository -
> > /trunk
> > /tags
> > /branches
> >
> >Then there is some file, say
> > /trunk/dir/file
> >
> >When this gets committed from a resource-fork-aware machine, the pathname
> > in the repository gets hashed to a md5-sum:
> > $ echo -n "/trunk/dir/file" | md5sum
> > 71523811009e11f8674bda76bfe2bc93
> >
> >So a complete tree of forks/attributes can be stored in eg.
> > /macos-resource-forks/71/52/3811009e11f8674bda76bfe2bc93/
>
> This is a terrible idea.
>
> * There's no guarantee that the names will be unique.
You're right. But there are people relying on hashes being unique (apart from
really _searching_ for duplicates). If you need more security, append a
SHA-512 to the MD5 :-) [1] [2]
> * What happens when I "svn cp REPOS_URL/trunk
> REPOS_URL/branches/fubar"? Right, you mention that the client does
> the necessary magic (a *lot* of magic, so "only client changes
> required" is an undernstatement)
The tree is simply copied (as usual), with attributes pointing to the *old*
resource-forks. That's ok, since they didn't change.
Only if a client *changes* data, it has to create a new directory
in /resource-forks/.
> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
> not aware of the convention?
As you only change the *name* of something, the attributes describing where to
find the resource-forks stay the same.
If a client gets this via an update, changes something, and commits later, the
client notices that the path hashes to another value and creates a new
directory in /resource-forks, with copyfrom-path from the attribute.
So everything ok, everything versioned :-)
Regards,
Phil
[1]: see 4 in www.soe.ucsc.edu/~hongbo/publications/dde-msst04.pdf
[2]: see 3.2 in is.rice.edu/~pshuff/tamu/Hash%20Addressing%20-%20short.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 17 12:09:56 2005