Re: Incorrect LastChangedRev in working copy after committing directory move + modified file in subdir

On 07/04/2012 07:51 AM, Philip Martin wrote:
> If you are saying that a move should update the LastChangedRev of every
> file (and dir?) in the destination then that would break the cheap copy
> feature of Subversion's copy-on-write filesystem.

Guys, let's clarify some things.

First, this whole concept of a last-changed-rev (LCR) originates *outside*
the versioned filesystem (FS). The FS has a low-level construct known as a
created-rev, but while that information is used by the server to reveal the
LCR to the client, they are not identical constructs, nor were they intended
to be.

LCR exists solely for keyword expansion, and that only so folks can compare
two versions of a working file and know that they aren't the same revision.

Finally, (LCR, URL) was never intended to be used a unique coordinate pair
for identifying resources. That it work out as such most of the time might
be a benefit, but was not a feature designed into the system.

So, no, for the purposes of this discussion, moves should continue to employ
cheap copies in the FS, because the FS created-rev is entirely outside the
scope of this LCR business. And if we're going to actively chase the goal
of using (LCR, URL) as a valid coordinate pair, that's fine, but it needs to
happen as part of an overall effort to clarify the historically shady
definitions of these keyword expansion values.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development