You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ra...@etas.de on 2004/03/28 15:26:43 UTC
Checkout dates
Hi,
when I do a 'svn co' the creation date of all files of the repository are
set to the actual date in the working copy. I would have expected the
original creation date before checkin or at least the checkin date of the
file.
This is very annoying, especially if another person checks out my
repository all of the file dates have gone and set to that new checkout
date on his/her computer.
Is there anything wrong with the installation / server settings ?
Kind regards
Ralf Bauer-Malz
Re: Checkout dates
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-03-28 at 10:26, Ralf.Bauer-Malz@etas.de wrote:
> when I do a 'svn co' the creation date of all files of the repository
> are set to the actual date in the working copy. I would have expected
> the original creation date before checkin or at least the checkin date
> of the file.
Why would you have expected that? (Genuine question.)
> This is very annoying, especially if another person checks out my
> repository all of the file dates have gone and set to that new
> checkout date on his/her computer.
Why is this annoying? (Also genuine question.)
The current behavior is motivated by a desire to make "update"
consistent with "checkout". We could set the file dates to the commit
time for a checkout, but "update" would have to use the current time for
changed files, or we would risk causing failures in "make".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Checkout dates
Posted by Evan Easton <ev...@eeaston.com>.
Ben Collins-Sussman wrote:
> Ralf.Bauer-Malz@etas.de wrote:
>
>> This is very annoying
>
>
> No, actually, the current default is optimized for people writing
> software. If I run 'svn up' and 5 files change, they all get a
> timestamp of "right now", which means tools like 'make' know exactly
> what to compile.
There are merits on both sides of this issue. I work on a large product
however, where I spend more time than I'd like digging through views
figuring out what happened when and why. Having views that reflect the
change time of files outweighs the benefit Ben mentioned in 80-90% of
cases for me because invariably, due to high complexity, my build tool
will get stymied by non-obvious intermodule/interdirectory dependencies
that are virutally impossible to specify properly and efficiently
[remember large overly complex product] at the same time, and it will
not know *exactly* what to compile even with the update timestamps
(BTW, if you think you know how to resolve all complex build recipe
problems, then please let me know, we've got a job for you that
aparently we're to imcompetent too solve ourselves :-).
My point? For Ralf the default behavior probably is indeed annoying
... for his needs, even if others can't fathom that and think that their
needs are identical to everyone's :-) At least he can change it to do
what he wants.
Evan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Checkout dates
Posted by Ben Collins-Sussman <su...@collab.net>.
Ralf.Bauer-Malz@etas.de wrote:
>
> Hi,
>
> when I do a 'svn co' the creation date of all files of the repository
> are set to the actual date in the working copy. I would have expected
> the original creation date before checkin or at least the checkin date
> of the file.
Set "use-commit-times = yes" in your run-time 'config' file. Then each
file will have the datestamp of the last time in changed in the repository.
>
> This is very annoying
No, actually, the current default is optimized for people writing
software. If I run 'svn up' and 5 files change, they all get a
timestamp of "right now", which means tools like 'make' know exactly
what to compile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org