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

Re: Import and Commit and file modification times

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-08-19 18:38:25 CEST

"Svante Seleborg" <svante@axantum.com> writes:

>> Merge is likely to cause conflicts in the new properties, is
>> that acceptable? Should Subversion automatically "resolve"
>> such conflicts?
> Conflict is naturally resolved by having the latest win.

I suspect the conflicts should be resolved, I'm not sure that the
latest is the natural choice.

>> If the user changes a file's timestamp but doesn't change the
>> text or any properties, should Subversion detect that?
> Yes. In fact that's what it does today, no? It uses the file-times on the
> client to detect any change, it does not run any diffs or hashes on the
> sources to detect changes.

No, as I understand it, the current code does not detect such
timestamp changes, they do not show up in the status output, and the
only way to commit a timestamp change is to explicitly propset.

>> On Unix only the owner of a file can change it's timestamp to
>> anything other than the current time. To allow multiple
>> users to share working copies it might be necessary to do the
>> "move-copy-delete" dance to get ownership. (I wonder if this
>> affects the existing use-commit-times
>> code?)
> As you say, this issue must already exist/be solved with use-commit-times.

"Must" is optimistic on your part :)

> Anyone know how that is handled there?

If you compare the code that sets the permissions with the code that
sets the timestamp then the permissions code does "move-copy-delete"
to gain ownership and the timestamp code does not. I suspect that at
present we usually set timestamps when creating files and so nothing
goes wrong, but if we start setting timestamps more often then we
might need to do something more. It's not hard to do, we know how to
solve the problem, I'm just pointing out that there are corner cases
to consider.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 18:41:16 2005

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.