Yeah, I just read the issue report.
I've never been happy with using the commands to retrieve the log
information this way. Historically, this type of file has been kept and,
I prefer it. It's far, far easier to access. But this is oppinion. I'd
prefer to support both so people have the choice.
As for generating it, that may be the way it goes. Its certainly less
work than certain other alternatives.
More comments on the tag expansions (aka chicken and the egg):
Notice that in keyword substitution, it is substitutded at checkout.
Furthermore, it must be substituted based upon the last/latest/youngest
transaction of the file anyway. Now, lets assume, for the moment, that
this is an ordinary keyword. When I checkout version n, I'll see the tag
evaluated to n. As much as I hate suggesting 'hacks', as an interim, when
its expanded, expand it without the $keyword: $ type notation. When its
committed *next*, it will commit as desired in the previous commit --
because it was expanded as desired.
One step shorter in the direction of a hack would be to have the tag
always refer to the transaction in which it belongs in the database.
Whenever you evaluate the keywords in writing out the file, you'd evaluate
*each* tag to the transaction you're displaying when you output the line.
But, this means reevaluating EACH tag at each checkout. Our log file
currently has 1650 commits recorded -- that would get nasty. However, now
and again, we could simply strip the keyword notations and then store it
outright. This alleviates this downfall.
Another alternative, atleast for my purpose, not the others listed, would
be to literally generate this file on all checkouts. That is, add a
keyword RepositoryHistory. You put whatever header you want, then this
keyword. Upon checkout, when it finds this keyword, it evaluates. Like
reading any other file, it would read the text from each transaction --
with a notable difference that this would be exclusively 'format line,
write to file; read history from transaction, write to file' with
(hopefully!) a format stored in the repository. Further, it would
actually be nice if the commit message were altered in this file, it could
update the necessary transaction's non-revision controlled log property,
svn:log (I think thats it :-)
Just a few more ideas to pepper the thoughts.
jon smith
On 13 May 2003 kfogel@collab.net wrote:
> 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
Received on Tue May 13 19:07:03 2003