B. W. Fitzpatrick wrote:
>>Regardless of how the backend is implemented, the frontend should have an
>>atomic "mv".
>>
>
>>From the info pages for ``mv'':
>
> ...It first uses some of the same code that's used by `cp -a'
> to copy the requested directories and files, then (assuming the copy
> succeeded) it removes the originals. If the copy fails, then the part
> that was copied to the destination partition is removed. If you were
> to copy three directories from one partition to another and the copy of
> the first directory succeeded, but the second didn't, the first would
> be left on the destination partion and the second and third would be
> left on the original partition.
>
>So it's basically cp && rm with a failsafe mode.
>
>So, unless ``svn mv'' commits immediately, it *is* going to be
>different. I think it should be. Subversion is a revision control
>system, thus it has one more dimension to it than a standard OS
>filesystem: time.
>
Having written a filesystem before, I can both agree and not agree with
this. Yes, the semantics of "mv" is the same as for atomic "cp & rm",
*if* you operate on directory entries, not i-nodes. Which is not what
happens in the svn filesystem.
However, this distinction is mostly academic, because svn's fs nodes are
not i-nodes -- they remember their history. In the end, the effect is
the same. The only difference is an extra indirection deep within the
svn_fs DAG, but that's not visible outside the filesystem.
Once we implement "svn ln" (which means a third kind of node, a
"reference", will appear in the filesystem), we'll have to be careful to
preserve the semantics of reference nodes within a copy. But that's
trivial -- reference nodes will behave exactly like C pointers: a copy
creates a new node, but its value (the node it refers to) remains the same.
P.S.: Propagating changes to the target back to the reference will be
interesting, to say the least. But it's doable. :-)
--
Brane �ibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006