> Yeah, so you've cherry-picked changes and applied them to some base revision.
> I think that, given some thought, you would agree that it would be incorrect
> for Subversion to claim that your working file is now "at" the revision you
> cherry-picked. I mean, to be "at" revision N implies that a file's history
> contains every change N, N-1, N-2 ... all the back to the file's origin.
That's a very good point. We have never done cherry-picking of these particular
files, so the revision # could be trusted a bit more, but if we did, I can see
how issues could result, and I'll be bringing that up with the other stakeholders
in this issue. Thanks much for that.
> It seems to me you're placing far too much stock in the revision number,
> attributing descriptive powers to it for which it was never designed and is
> ill-suited to provide.
>
> Revision numbers alone cannot uniquely describe anything. You can have 15 files,
> each in one of 15 branches, each of which has slightly different file contents
> from the next ... and yet all 15 variations could carry the same $Revision$
> keyword value (perhaps because all 15 copies were modified in the same revision).
> In such a scenario it becomes obvious that a revision number alone is
> insufficiently as a unique representation of that any one of those files.
In our case, that level of descriptiveness is not really vital ... all we need is
to know the filename we are working on (during the deploy) and a revision number
that we can compare to other revision numbers from that same file, in order to
determine if the file is newer that anything that had previously been deployed to
the server in question (because we store those earlier revision numbers on a file
by file basis). Including the path wouldn't seem to help with making that
determination. But returning to your earlier point, if we had ever had a
scenario where we had cherry-picked revisions 1 and 3 for one of these files,
and then later brought in revision 2, the fact that (in our presumption) the
revision # in the earlier deployed file would already have been #3 would have
caused our scheme to break down. It is a great point, as I said, and might be
sufficient to motivate us to do something different.
I appreciate all of the very useful input.
- David Sandberg
Received on 2013-03-20 20:19:22 CET