On Thu, 2010-05-27 at 09:05 -0400, C. Michael Pilato wrote:
> Julian Foad wrote:
> > julianf is trying to prepare a presentation to business users of svn,
> > with the title "The future of merging", for the svn conference in Berlin
> > on 10-13 June.
> >
> > /me wonders what are the main issues, concerns and developments for svn
> > merging.
> >
> > * "True Renames" - properly merging renames. This is the Big One.
>
> Be very careful about the terminology you use around the topic of renames.
> "True Renames" has for some time been used to refer to a fundamental storage
> layer change whereby a rename doesn't create a new node revision of the
> renamed thing, only new revs of the parent directory(s) with revision
> entries lists. This is *not* a direction we as a developer community have
> committed to taking (and is specifically one that I don't believe to be
> necessary to get the functionality that customers want).
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. Issue
#898 <http://subversion.tigris.org/issues/show_bug.cgi?id=898> and The
Book
<http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.moves>, and this email <http://svn.haxx.se/dev/archive-2005-05/1002.shtml> all use "true renames" for the whole concept from user's mind through to repository storage.
- Julian
> "Atomic Renames" is another term that gets tossed around, and speaks to
> Subversion's enforcing the simultaneous commit of both "sides" of a rename
> operation.
>
> You're safer saying something buzzword-free, though, such as "properly
> merging renames".
Received on 2010-05-27 19:11:15 CEST