(Skip to the end: I've just discovered issue #3630 "Rename tracking" and
its dependants, and will read them. I think "Rename tracking" is a good
name. The rest of this reply is now mostly a curiosity.)
C. Michael Pilato wrote:
> C. Michael Pilato wrote:
> > 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
Ah, you see, I had somehow formed the impression that the phrase is now
used to mean "Handle renames in such a way that the end result is what
the users expect, regardless of how it's implemented".
What the users expect has little connection with node-ids and such like,
and most of the important user-level requirement is summed up by saying
"When merging a rename from a source branch to a target branch,
Subversion should perform a rename within the target branch,
not copy something from the source branch."
Certainly a better name for it would be ... better. "Branch-relative
renames"?
> > - 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.
Yup, I agree.
> And:
>
> - before you start telling business users that Subversion needs to
> support true renames before it can meet their needs, prove it.
Heh. I rather approached it from the other direction: you business
users are desperate for renames to be handled differently from today;
let's talk about what you need, and call the topic under discussion
"true renames", for want of a better title.
I will try to avoid that phrase and invent something like
"branch-relative renames" instead (or such other phrase as we think
best), but I'm afraid the wider use of "true renames" to mean "just make
merges handle renames the way we expect" is already out there.
> > 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.
You know what, I somehow missed that "Instead ..." sentence when
skimming the issue. Sorry.
> > 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).
Ah... what the author means, versus what the reader understands ... :-)
Right, what this topic needs is
(a) a title, and
(b) an overview
I'll see if I can prepare an overview...
AHA! I have just discovered that you (Mike) on 6 May this year filed a
set of issues (3630 to 3634) covering this stuff. I will now read them.
Thanks!
- Julian
Received on 2010-05-28 13:14:56 CEST