On Sun, Feb 25, 2018 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org> wrote:
> > Date: Sun, 25 Feb 2018 04:37:38 -0500 > From: Ron W <ronw.m...@gmail.com> > Subject: Re: [fossil-users] Minor Issues with Fossil 2.5 > > > Date: Sun, 25 Feb 2018 10:11:04 +0100 > > From: Florian Balmer <florian.bal...@gmail.com > > Subject: Re: [fossil-users] Minor Issues with Fossil 2.5 > > > > I think that the "Last-Modified" header is much easier to handle, as > > it boils down to parsing a GMT date/time string. And, as already > > mentioned, clobbering of locally-modified files can be avoided with > > the timestamp mechanism, this is not possible with an ETag alone. > Sorry, I missed the locally modified part. But, it sounds like you expect it to be overwritten by a newer "version" from the remote resource. ETag can handle that case as well. In the wget.pl wrapper I linked, an ETag "jar" is maintained. So, wget.pl doesn't care about any local changes. It will only fetch the remote resource when the resource's ETag value has changed. Another suggestion: Treat unversioned files like 3rd party "vendor releases" and keep locally modified copies in a separate location. That way, the newly fetched copy can't accidently overwrite your local changes. The ETag is supposed to only change when the content changes Therefore, if > the Etag you have is not the same as the current ETag on the server - for > the same resource - then the content is different. > > Admittedly, if the server's copy of the resource is changed to an older > version, the ETag will be different, as well. > > So, if you always need the newest version, then modification time is > needed. But if different is acceptable, then Etag will do that. >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
