Jani Averbach wrote:
> On 2004-10-14 18:44+0100, Tom Molesworth wrote:
>>I'd recommend "$Keyword:: " as a minimum, and leave all characters after
>>the initial space for filler.
> I think we have a consensus, the syntax is following at the moment:
> "$keyword:: " <value> (" $" | "#$")
> where <value> is at least one character, value could contain anything
> except '$' chars, and "#$" indicates that the value is truncated.
>>The fixed-size keyword code does not differentiate between original text
>>and "expanded" (substituted) text - the text will be replaced every time
>>no matter what.
> Well, in fact it must be different, think about following recipe:
> If someone handles these keywords with old client, it is possible to
> inject to the server "dirty" keywords (keyword strings with value data).
> This causes that these fixed length keywords show up on diffs when
> they shouldn't. How bad is that? I think we can live with it, but
> could we?
Is anyone likely to be using this for text files? The primary reason for
implementing this feature (from my point of view, at least) is to allow
binary files to have version information - therefore "svn diff" is
pretty much a meaningless operation.
I do see your point, and perhaps it would make sense to add code to
handle this... but it would seem that, if the client does not support
the fixed-size keyword format, it will simply return whatever's been
written to the database. If we put in a patch to fill with spaces on
commit, this shouldn't be a problem... even without the patch, older
clients will blindly write this as a standard string without any
conversions, so after the first commit it wouldn't change anyway, thus
keeping the diffs clean. I must confess: I don't know where this code is
linked in (server or client, I'm assuming both?) so there's a good
chance I'm missing something here.
Either way, I don't think the old-client compatibility should be a
problem at all, and "svn diff" is an unlikely operation to be needed
with this format.
> I have planned to commit this sometime next week, if nobody objects.
All looks good, I'll apply your latest versions and run some tests on
the binary files I've been trying it with so far.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 16 05:24:57 2004