[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 5 Jul 2012 09:55:11 -0400

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

Received on 2012-07-05 15:55:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.