You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by solo turn <so...@yahoo.com> on 2003/05/03 16:50:22 UTC
dates, checksums, and so
> From: Mark Watts [mailto:mwatts3@stny.rr.com]
> Sent: Friday, May 02, 2003 4:45 PM
> * As a user I find it very annoying that a check out (svn co) into
a new
> working directory leaves all files with the current date time
stamp. As a
this is a clear subversion bug. svn does not conform to conventions
of treating time:
mtime tells when contents was modified last. this can NOT be the time
when the file is checked out, cause "svn co" does NOT modify the
contents. its nothing but a copy.
there is work-arounds with touching files, but this is neither
user-friendly nor correct from the mtime point of view.
because time always has been a problem in subversion, i recently
suggested the user should be able to decide what to use for deciding
"file has changed":
- datetime
- checksum (correct most of the time)
- file contents (for the paranoid)
- combination (if it makes any sense?)
a file is determined by its contents, and not by its timestamps.
"touch"ing a file does not make it new! so in 99.9% of the use cases,
i want to compare the files contents.
__________________________________
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
Re: dates, checksums, and so
Posted by Philip Martin <ph...@codematters.co.uk>.
Olaf Hering <ol...@suse.de> writes:
> > 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.
Perhaps I confused you, by "modified files" I meant the files changed
by the update, not files with a local change.
The problem I was pointing out is that if the commands checkout,
update, revert, and switch set the working copy timestamps to that of
the commit then it is possible for an update to generate timestamps
that are earlier than the timestamps of any object files derived from
the working copy. This can happen even if we ignore any clock
differences between client and server and simply update a working copy
to a newer revision on the same branch. I thought it was obvious, but
apparently not, so consider
- Checkout HEAD to get a wc with timestamp T1
- Build the wc to get objects with a variety of timestamps t1, t2, t3,
etc.
- Between the checkout and the end of the build a new revision is
committed.
- Update the working copy to get a wc timestamp T2. There is no
guarantee that T2 is later than t1, t2, t3, etc.
- Complain bitterly when the build doesn't realise that some objects
are invalid.
- Complain even more bitterly when told to run 'make clean' after
every update.
Now if Subversion produced timestamps like this it would be a useful
for some scenarios, anything where the versioned items are the final
product for instance. For projects that have some sort of traditional
make-like build to produce derived objects it doesn't work. ClearCase
has ClearMake that does more than simple timestamp comparisons, I
believe it uses the versioned filesystem to determine exactly which
versioned items contributed to any particular derived object.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Olaf Hering <ol...@suse.de>.
On Mon, May 05, Olaf Hering wrote:
> On Mon, May 05, Branko Čibej wrote:
>
> > Not if you update to a previous version, or switch to a branch.
>
> Then run make distclean. No idea how cvs behaves in this case, but I
> really wonder what happens to this world if all foo-1.2.3.tar.bz2
> project releases will suddenly have bogus timestamps.
After a short chat with sander and sussmann, it might be a good idea to
add such a feature to 'export', something like
svn export --maintain-timestamps
Gruss Olaf
--
USB is for mice, FireWire is for men!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Olaf Hering <ol...@suse.de>.
On Mon, May 05, Branko Čibej wrote:
> Not if you update to a previous version, or switch to a branch.
Then run make distclean. No idea how cvs behaves in this case, but I
really wonder what happens to this world if all foo-1.2.3.tar.bz2
project releases will suddenly have bogus timestamps.
Gruss Olaf
--
USB is for mice, FireWire is for men!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Branko Čibej <br...@xbc.nu>.
Olaf Hering wrote:
> On Sun, May 04, Philip Martin wrote:
>
>
>
>>Olaf Hering <ol...@suse.de> writes:
>>
>>
>>
>>>The current behaviour is broken.
>>>
>>>
>>No, it's not, the current behaviour is a valid way to behave.
>>
>>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.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Olaf Hering <ol...@suse.de>.
On Sun, May 04, Philip Martin wrote:
> Olaf Hering <ol...@suse.de> writes:
>
> > The current behaviour is broken.
>
> No, it's not, the current behaviour is a valid way to behave.
>
> 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.
Gruss Olaf
--
USB is for mice, FireWire is for men!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Philip Martin <ph...@codematters.co.uk>.
Olaf Hering <ol...@suse.de> writes:
> The current behaviour is broken.
No, it's not, the current behaviour is a valid way to behave.
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).
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Olaf Hering <ol...@suse.de>.
On Sat, May 03, Greg Hudson wrote:
> On Sat, 2003-05-03 at 14:16, Alan Shutko wrote:
> > What version are you using? Checkouts have been setting the
> > timestamp appropriately for a while, though I don't know when,
> > offhand. I just tried it on my machine....
>
> I'm not sure how Michael Price got his result; in my experience, for a
> checkout or update, CVS sets the timestamp to the checkin date for a new
> file (which is all of the files in a checkout) or to the current time
> for a modified file. This produces no particularly useful guarantees.
>
> (And people do jump on CVS for its timestamp behavior. But solo turn is
> confusing the issue by conflating the timestamp a file gets on
> checkout/update/switch with the algorithm used to find changed files in
> a working directory.)
Well, the main issue remains. subversion must maintain the timestamps.
Maybe I have missed that part in the documentation how to set timestamp
related properties.
Using the commit time is not a very bad idea because that is the time
when other users of the repository have a chance to see the new data.
I'm not sure if subversion could do it better and use the real
modification time of the given file, that would make sense when one
imports his old stuff via 'svn add *'.
The current behaviour is broken. If this remains unchanged, document it
and explain the reasons behind this decision.
Gruss Olaf
--
USB is for mice, FireWire is for men!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2003-05-03 at 14:16, Alan Shutko wrote:
> What version are you using? Checkouts have been setting the
> timestamp appropriately for a while, though I don't know when,
> offhand. I just tried it on my machine....
I'm not sure how Michael Price got his result; in my experience, for a
checkout or update, CVS sets the timestamp to the checkin date for a new
file (which is all of the files in a checkout) or to the current time
for a modified file. This produces no particularly useful guarantees.
(And people do jump on CVS for its timestamp behavior. But solo turn is
confusing the issue by conflating the timestamp a file gets on
checkout/update/switch with the algorithm used to find changed files in
a working directory.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Alan Shutko <at...@acm.org>.
Michael Price <mi...@acm.org> writes:
> Well CVS has the same "bug" :)
What version are you using? Checkouts have been setting the
timestamp appropriately for a while, though I don't know when,
offhand. I just tried it on my machine....
--
Alan Shutko <at...@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
Dragons again? I activate my +6 St. George S.A.M.'s
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: dates, checksums, and so
Posted by Michael Price <mi...@acm.org>.
solo turn wrote:
>>From: Mark Watts [mailto:mwatts3@stny.rr.com]
>>Sent: Friday, May 02, 2003 4:45 PM
>>* As a user I find it very annoying that a check out (svn co) into
>> a new
>> working directory leaves all files with the current date time
>> stamp. As a
>
> this is a clear subversion bug. svn does not conform to conventions
> of treating time:
Well CVS has the same "bug" :)
$ dir $CVSROOT
total 4
drwx------ 3 mixtim mixtim 1024 Dec 8 09:15 CVSROOT/
drwx------ 2 mixtim mixtim 512 Jul 4 2000 test/
$ dir $CVSROOT/test
total 2
-r--r--r-- 1 mixtim mixtim 176 Jul 4 2000 file,v
$ cvs co test
U test/file
$ dir test
total 4
drwx------ 2 mixtim mixtim 512 May 3 13:54 CVS/
-rw-r--r-- 1 mixtim mixtim 3 May 3 13:53 file
Do people forget CVS does the same thing? Why does everyone not care that CVS
does but jumps on subversion?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org