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

Re: [Issue 2746] New - update overwrites w/o warning local modification if local timestamp did not change

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-03-20 00:33:06 CET

"Erik Huelsmann" <ehuels@gmail.com> writes:
> On 3/19/07, Karl Fogel <kfogel@red-bean.com> wrote:
>> "Erik Huelsmann" <ehuels@gmail.com> writes:
>> > Ok. Well, I discussed this a bit more on IRC with both markphip,
>> > sussman, maxb and dlr. They all think there are limits too and that
>> > we're stretching our end of the deal by taking the file size into
>> > account too (on trunk, ofcourse).
>> I'm not sure what that last sentence means. I don't feel we're
>> "stretching" anything, in that working-size is 100% reliable for
>> positives, it's just that if you get get a negative (i.e., file size
>> hasn't changed), you can't assume that the file hasn't changed.
>> That's how we use it, right?
> No. In the case of update, we *replace* a file for which status
> reports not-changed. Effectively, this means that we are not 100%
> reliable at knowing whether or not we are destroying unversioned user
> data.

What I mean is, we're not making that decision *solely* on the basis
of working-size. We're also taking into account that the timestamps
haven't changed. In other words, working-size isn't "stretching"
anything farther than it was stretched before, right?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 00:33:17 2007

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.