Re: Presentation for Berlin 10-13 June - "The future of merging with Subversion"

Julian Foad wrote:
> Did you mean to imply that use of the phrase "true renames" should be
> limited to this storage layer? That's not the impression I have.

I'm not trying to say that the term has no meaning outside of discussions
related to the storage layer. Just that:

  - any conversation about supporting the "true rename" idea in Subversion
    thoroughly hinges on fundamentally different treatment of renamed
    objects in that filesystem layer, and

  - the only place we've ever attempted to implement true renames is in
    that filesystem layer.

  - it remains to be demonstrated that "true renames" are required for
    Subversion to work as users expect. I am fully convinced that if
    Subversion would properly handle what it offers today (deletes, copies,
    and their conjugation under the rename umbrella) we wouldn't be
    having any conversations about "true renames" at all. Nobody really
    cares how we model our renames as long as common stuff like updates
    and merges just work.

> Issue #898 <http://subversion.tigris.org/issues/show_bug.cgi?id=898>

The very first statement in this issue is:

   Rename should not be implemented as "copy + delete", because that
   creates a new revision of the renamed file. Instead, a rename should
   only change the (old and new) parent directory, not the file itself.

Those details (which things get new revisions) are artifacts of the storage
layer.

> and The Book

The book says only that Subversion lacks "true renames", by which it means
renames as defined by the first comment in issue #828 (quoted above).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand