[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-20 01:03:08 CET

On 3/20/07, Karl Fogel <kfogel@red-bean.com> wrote:
> "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?

No, we're using the timestamp too. But Ben took a position where he
says 'timestamps should have been enough', so in effect we're giving
over-service (we're doing more than we should be expected). That's why
I say we're stretching it.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 01:03:23 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.