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

Re: repair timestamps of unchanged files

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2004-11-24 22:19:48 CET

On Nov 24, 2004, at 8:27 AM, Branko Čibej wrote:

> Philip Martin wrote:
>
>> Julian Foad <julianfoad@btopenworld.com> writes:
>>
>>
>>> Justin Erenkrantz wrote:
>>>
>>>>> - svn cleanup --repair, a new flag
>>>>> - svn cleanup, could be made to do it unconditionally
>>>>> - svn status --repair, a new flag
>>>>> - svn repair, a new function
>>>>>
>>>> I think 'svn cleanup' should do it unconditionally. -- justin
>>>>
>>> But of these four options, I agree that "svn cleanup" is the best,
>>>
>>
>> It's not as good as a fully automatic system, but it's the one I
>> dislike least. I've committed a first attempt at making it happen.
>>
> I still think this is a mistake, that we should serialise all WC
> accesses and repair the timestamps as soon as the difference is
> noticed.

Re: serializing

When I'm committing and want to look at a diff, it's nice to be able to
'svn diff' in another terminal. I'd guess I'm not the only one that
likes to do this. I assuming Serializing would not allow this. Also,
some people might be doing this under-the-covers, for example, using a
script like Julian's (
http://svn.haxx.se/dev/archive-2004-10/0577.shtml ) and unlike him,
using status and/or diff used to generate a default log message within
the commit process as part of their editor invocation (rather than
prior to commit is as Julian mentions is his habit).

As an alternative: maybe an operation can reserve the right to repair
timestamps and other processes would then proceed without bothering if
that reservation were not available?

-Travis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 24 22:21:47 2004

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.