Tracking base revision for files distributed without a repo

[Benjamin Fritz]

On Fri, Jan 24, 2014 at 3:47 AM, Dirk Heinrichs <dhs at recommind.com> wrote:
>
> Am 23.01.2014 06:47, schrieb Benjamin Fritz:
>
> Are there better solutions than just embedding the revision in the
> file using KeywordExtension? Solutions that allow my coworkers to
> continue being lazy but allowing me to benefit from knowing which
> version they base any changes off, what to tell them I've changed
> since the last time I sent them updates, etc.?
>
>
> Use branches. One for each of your co-workers. Merge your work to a co-workers branch before you hand it over to him, commit what you get back to the same branch.
>

That might work, but not everybody takes my updates when I send them
out. Once upon a time I actually used local tags to mark the
repository state whenever I sent something out. But I occasionally
forgot to do that, or people would skip an update from me if they
weren't actively working a problem that required the scripts, or they
would find a copy laying around somewhere, or they would forward my
email to somebody else. Basically keeping track of it in my own
repository depends on other people only ever using exactly what I sent
out last. And this is not always the case. I actually found a full
copy of my repository out on a lab machine that had been disconnected
from the network for the last two years, once! I really need to be
able to determine from the files themselves where the changes started,
and I'd prefer an automated or semi-automated way to do this.

So far the best ideas are Matt's for comparing actual file contents at
each revision, or embedding the last changed revision in the code,
easily accomplished with the KeywordExtension.