Karl asked me to log my suggestion in the issue tracker (#958), but before I
do, I've expanded it and want to pass it by the list to see if it is worthy
first. :) And to see if I am even close to understanding the issue...
My scenario is thinking of the revision keyword specifically. It might not
work for all keywords depending on how extensive they are.
Can the keywords be collapsed on check in to the base keyword? For example:
$who: username$ would get condensed to $who:$
$revision: r1234$ would get condensed to $revision:$
Then on checkout, the keywords would get expanded through whatever the
substitution policy is.
That way, the file doesn't change with every commit because the keyword
expands differently. Is what we really want to revision, the keywords, not
the meta data defined by the keywords?
This does require parsing the file on both check in and checkout. If this
isn't already being done, that can be (will be :) ) a huge performance
issue. Maybe a solution is to limit keywords to the 1st line of a file, or
first N lines of a file.
I would think that the keywords would want to be condensed on the client
before the diff is applied. And for symmetry, this would mean that the
keywords would be expanded after the diff was "patched" on update/checkout,
so maybe the processing being done on the client isn't that much of a
performance issue after all. If keywords were expanded at these phases,
they basically wrap the repository operations, so should have minimal impact
on the core. It becomes more of a client operation than a server operation?
Thanks,
Brian S.
-----Original Message-----
From: kfogel@collab.net [mailto:kfogel@collab.net]
Sent: Tuesday, May 13, 2003 8:26 AM
To: mark benedetto king
Cc: Jonathan Smith; dev@subversion.tigris.org
Subject: Re: Commit Log File
mark benedetto king <mbk@boredom.org> writes:
> This is covered in:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=958
I have since realized that this would be *very* hard to implement.
For repository specialists, here is the explanation:
The problem is that the file in the txn needs to know its contents
before the txn can be finalized. For normal keywords, this is no
problem -- the keywords are stored contracted anyway. But for the
proposed one-time-only revision keyword, we'd need to know the
revision number of the commit *before* the commit is done. That
effectively means locking up the revision number, then going back and
modifying all the files in the txn that have this special keyword,
then finishing the commit. Yuck.
So I doubt issue #958 is going to be resolved anytime soon (I'll add
these comments to the issue).
Jonathan, I'd recommend that you not store your logfile statically
anymore. Instead, have a script that can generate the file
automatically, for example by running 'svn log -v' and massaging the
output.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 21:55:53 2003