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

Re: timestamp preservation design (issue 1256)

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-06-24 21:48:32 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

>> > Ew, no, no, no, no, no. -1 on the CVS behavior.
>> >
>> > It's surprising,
>> To whom?
> It was highly surprising to me when I found out about it as a CVS user.
>> > it has no interesting properties (it doesn't satisfy make, and a
>> > directory which has been updated even once has a mismash of checkout
>> > dates and current dates),
>> For developers, it *does* satisfy make 90% of the time.
> 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.

Assuming someone gets as far as implementing a system to save/restore
timestamps, then I'd much rather see a config/option setting that
controls the behaviour. I'd like to be able to select the current
behaviour, and I also like to be able to select full timestamps. Full
timestamp behaviour would set the timestamps to the stored timestamps
for checkout, update, revert, export, URL->wc copy (WC->WC copy as
well?) and merge, with the proviso that an update that modifies a
file with local modifications, and a merge that modifies existing
files, should use now rather than the stored timestamp.

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 21:49:36 2003

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.