Greg Hudson <ghudson@mit.edu> writes:
> My keyword translation scheme is very similar to my newline translation
> scheme, with one difference: on commit, AFTER the commit has succeeded,
> we do a keyword substitution on the working copy, as if we had just
> checked out the file at the new revision.
Greg, in the current commit system, the RA layer finishes the commit,
receives a new revision number from the repository, and then calls a
'bump_func' callback on each committed target; this is now revisions
are bumped. I was already planning to expand the parameters to the
bump func, so that other keyword-data could be substituted on targets
following a successful commit. So this idea isn't new.
But I'm still confused about your keyword-substitution system. I'm
assuming that your central axiom is still: "the working file is
-exactly- what gets committed." This means that the repository will
always contain expanded keywords, as will the text-base. Therefore,
it seems that an unexpanded keyword will *never* exist anywhere! The
client will always be substituting new values into an already-expanded
keyword, right?
My confusion is in the bootstrapping of this process. How does one
create and add a file that contains keywords? If we expanded the
keywords in the working file after the very first commit, then as soon
as the commit was over, the file would have a local mod (because it
would no longer match text-base, which still has the unexpanded
keyword.) Is this ok? Would the user have to commit *again*?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:52 2006