Re: [Issue 3190] File modified immediately after checkout not shown as modified

On Tue, 2008-05-20 at 12:32 -0400, Karl Fogel wrote:
> But gosh, it would be so simple for us to support this by just waiting
> longer... Surely users would rather Subversion be a bit slower than not
> work at all.

I don't think we really understand this particular failure well enough
to know how long we'd need to wait.

We can avoid the need to sleep altogether by adopting a technique from
git. For this technique we consider *three* timestamps:

  1. The current timestamp of the file
  2. The timestamp recorded in .svn/entries
  3. The timestamp of .svn/entries itself

If all three timestamps are the same, we have the potential for a race,
so we treat the timestamp comparison as inconclusive and do a full
contents compare. However, if 1 == 2 but 2 != 3, there is no potential
for a race.

To avoid doing more file content comparisons than necessary, it is
helpful to touch .svn/entries whenever we detect a 1 == 2 == 3 case.
Because of Subversion's architecture we can only touch .svn/entries when
we have a write lock on the directory.

(We'd also need a way of recording in .svn/entries that we've done a
file contents comparison and know that the file is different even though
1 == 2.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-20 20:10:44 CEST