Possible way to support $Log$

I was thinking the other day about $Log$, which some people have complained
about missing. AFAIK, there are three things that prevent $Log$ from being
easily supported in Subversion:

1) All keyword processing (expansion) is line oriented (i.e. both $ delimiters
must be on a single line;

2) The contents of $Log$ cannot include the $ delimeter;

3) Causes difficulties with merging (this is from CVS' experience).

What if there were a way to store some information about the length of the $Log$
entry, which would deal nicely with both #1 & #2? And also specify that the
contents of the $Log$ entry are considered read-only (i.e. you could edit them
as expanded in the file, but the system wouldn't keep the edits, which AFAICT is
why CVS has historically had some problems with the tag). Also require that
$Log$ be located on a line by itself in order to enable expansion.

There are two scenarios that I was considering that could be supported with a
limited amount of difficulty (he said waving his hands rapidly ;):

A) Unlimited log - the full history entries for the file containing the $Log$
would always be expanded every time the file were updated;

B) Limited log - the user could specify how many logs (newest to oldest) would
be expanded, either as a size or as a number of history "records".

The way I was thinking this could be done is to have this appear _in the
repository_:

A) $Log$ means unlimited log expansion;
B1) $Log[4]$ means include the last 4 history records;
B2) $Log(4k)$ means include most recent 4k bytes of history records (possibly
broken only at history record boundaries, so that complete records would be
preserved as long as they fit in the allocated "buffer").

In the expanded WC representation of those file, it would appear this way:

A)

   $Log: (2836) This is the log entry which is exactly
   2836 bytes long...$

B1)

   $Log[4]: (1054) This is the last 4 history entries which total
   1054 bytes...$

B2)

   $Log(4k): (4004) This is as much history entries which will fit
   completely into 4k bytes...$

Of course, the complicating factors are that the log entries are stored
internally as Unicode with LF's so each client would have to do the calculation
of the size (rather than having the server do it). I also haven't looked the
code to see if there was a way within the current line-oriented handling to
reach back and grab all of the lines of the expanded $Log$ entry in the WC.

Just a thought...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org