On Friday, January 11, 2013 5:41:57 PM UTC-5, Konstantin Khomoutov wrote:
> You seem to misunderstand the concept a bit. 
> The blobs kept in the repo should have some neutral placeholder, such as 
> to read something like "Last modified $Timestamp$" in them. 
> Then, in the smudge filter, which is run after checking out the blob 
> into a file in the work tree, you replace that $Timestamp$ with 
> something appropriate for your work tree. 
> Then, in the clean filter, which is run before the new blob is written 
> to the repository, your task is to *revert* that local change, that is, 
> to change whatever your smudge filter did back to $Timestamp$. 
> That way your repository always keeps "normalized" blobs. 
I agree that this is exactly what I would do to mimic RCS behaviour. But I 
am deliberately trying not to for the reason described below:

Unfortunately using this method seems to create a certain ambiguity when 
creating a formal release (perhaps my understanding is faulty, so I would 
appreciate clarification if so). Suppose that I do all my final commits and 
am now ready for release. For release suppose that I do a fresh git clone. 
Using the RCS method every file will now be smudged to have the same "last 
modified" date equal to the date I cloned. This is technically not correct, 
although perhaps it is close enough.

Alternatively I could not do a fresh clone for release and use my working 
directory so that files not changed for some time might not be freshened by 
a pull and thus will have an older "last modified" date. The problem now is 
that if I do the release this time, and the next time my colleague does a 
release from her working directory the files will likely have completely 
different "last modified" dates depending on what sets of files have been 
changed between us and when the original clones of the working directories 
was done. In my opinion this is not viable since there is now no 
consistency at all in the "last modified" dates between releases.

Perhaps this RCS method is "close enough" for most purposes, but I am 
trying to get a last modified date that is somewhat more realistic and 
probably more defensible in the eyes of the law if it was ever needed.


Reply via email to