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

Re: dates, checksums, and so

From: solo turn <soloturn99_at_yahoo.com>
Date: 2003-05-05 17:30:05 CEST

uh, yes, brane and philip are right ... the best way then would be
having properties set for the client, like it is done in visual
source safe:

set datetime on local files:
- current
- modification
- check in

compare files by:
- checksum
- contents
- time

this leaves it to the user and to the use case. should we make an
issue for this (or two, cause greg is also right by saying the two
are independent)?

-s.

------------------------------------------------------
Date: Mon, 05 May 2003 08:46:48 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
Subject: Re: dates, checksums, and so
Content-Type: text/plain; charset=UTF-8

Olaf Hering wrote:

> On Sun, May 04, Philip Martin wrote:
>>There is no single "correct" behaviour. Propagating the
transaction
>>timestamp onto checked out files is a valid alternative to the
current
>>approach, essentially that is the way ClearCase behaves, but keep
in
>>mind that doing this will interact in "interesting" ways with the
>>traditional make approach to building derived objects (e.g. I could
do
>>an update, have the modified files move backwards in time, and not
get
>>anything rebuilt).
>>
>How can this happen? If you did not touch the file then it will have
a
>newer timestamp after the 'svn up'. The timestamp of a file that has
>local changes must get a new timestamp.

Not if you update to a previous version, or switch to a branch.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 5 17:31:04 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.