Re: timestamp preservation design (issue 1256)

kfogel@collab.net wrote:
> Ben Collins-Sussman writes:
>
>>So for these reasons, I think {Ben, Karl, Justin} are of the opinion
>>that if we have a timestamp feature at all, the CVS behavior is
>>probably the least evil of all options, and most useful.
>
>
> Yah. Plus the no-surprises factor if we just do what CVS does.

I've been following this discussion and trying to put into words what my
expectations would be. The method that would suprise _me_ the least is if I
commit a project, then check it back out in a different location and all the of
timestamps matched (except possibly directories). And that would be true for
any historical version, so I could recreate a given project at any point,
exactly as if I had tar'd it up. And yes, I do realize that means a versioned
commit time for each file.

If there was a way to override that for generated files (since that came up) to
have their time be different (to force their regeneration), that would be nice,
but hardly essential. Say, an attribute that this file should be forced to be
just a little older than some other specified file.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org