Ben Collins-Sussman <sussman@collab.net> writes:
> Philip Martin <philip@codematters.co.uk> writes:
>
>> > If you're going to do something truly awful in order to make something
>> > else work, it should be a 100% solution, not a 90% solution.
>>
>> I tend to agree with Greg here, I don't really like the CVS behaviour
>> (but then I'm not a CVS user). If we are going to go to all the
>> trouble of storing and retrieving commit times it seems odd to do it
>> only for CVS compatibility.
>
> None of my proposals have been about storing any new information. I
> don't want to implement any new systems to save/restore timestamps.
>
> We already have commit-times coming back from the server, and embedded
> in entries files. My proposals have simply been a matter of "hey, why
> not use them once in a while, for something other than keyword
> expansion." Very, very simple.
Commit times are OK (ClearCase uses commit times) but it does make my
full timestamp behaviour a little more complicated.
In essence I would like the timestamp behaviour to mean that the
timestamps in a working copy do not depend on how the working copy was
obtained, whether by checkout, update or modify-commit the timestamps
are the same. If commit times are used it means that the commit
process needs to update the timestamps on the committed files.
(ClearCase uses commit time and commit does change the timestamp on
committed files. Hmm, I guess that means I'm arguing for "ClearCase
emulation" rather than "CVS emulation". Since I don't intend to
implement it I think I'll just shut up!)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 22:39:38 2003