On Feb 24, 2005, at 10:28 AM, Steve Greenland wrote:
> On Thu, Feb 24, 2005 at 03:38:20PM +0100, Ryan Schmidt wrote:
>> This wouldn't help our case. We are a web design shop, creating web
>> sites for many different clients. Often PDFs or other content which is
>> supposed to appear on the web site will come directly from the client
>> by email.
> Then you've already lost the modtime. All you have is when you
> from the e-mail message.
Ryan didn't have a perfect example, but that isn't the point.
> (Shouldn't documents like this have embedded
> version numbers or timestamps anyway?)
No. You can't dictate the required contents of the files we store in
the repository. E.g. the video file for my video game cut-scene does
not have anything but raw data for the video and audio codecs. ** The
version information for that file is stored as metadata in the
filesystem. ** (As used by the group that is responsible for changing
that file, not part of my group, and of which I have no control over
their development practices.) It looks like this "Modified on:
2005-02-24 16:26" :).
> In previous discussions I argued that using modtimes as any indication
> of version is inherently unreliable and therefore useless.
The reasoning is circular. We don't need to preserve the time in our
tool, because we can't rely on the time being preserved in some other
(broken) tool. That's precisely the problem we are trying to FIX. The
argument for not fixing the bug is that the bug exists in some other
tools???? Well I'm not using those other, broken, tools, so that logic
does not apply.
My work process preserves timestamps everywhere, subversion is the only
I really don't understand, why argue against preserving valuable data?
This would be an option for use when it is needed, and clearly many
people would like to have the option. We aren't talking about
prioritizing it or anything like that. I just want to first get to the
stage where it is acknowledged as something that needs to be fixed.
> So preserving modtimes, at least on the import->checkout sequence,
> be useful.
Which side are you on? :)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Feb 24 22:39:13 2005