Okay, it's been a while since the last discussion - and I've been
thinking about the matter and browsing around the code.
As a result, I've gotten a few Profound Revelations, from which the
most important one is this:
Special file storage is just another case of working copy file
translation.
First of all it's completely client side. It doesn't affect the
text-base at all. To find the differences in a file, one has to first
de-translate the file and then compare that to the working copy
base. Everything fits. So, newline translation, keyword substitution
and special file handling should all be done mostly at the same places
- everything else is just edge-cases.
So - good - how to do it then? Again, I have two options in how to
proceed. The first is the straightforward one - and the second
is... well you'll see. So, on to the first choice.
* Straightforward extension for special files
Add a new argument to svn_wc_copy_and_translate, which controls the
translation of the text form to the actual special file and back. Then
specify a single property, which tells if a file is a special file or
not.
After that, it's a simple case of fixing up all callers of
svn_wc_copy_and_translate - and fixing up snv_wc_translated_file,
svn_wc_text_modified_p and such special functions.
And then finally just testing it around in several situations and fix
up the edge-cases that pop up.
This sounds straightforward, not too cumbersome - but not too elegant
either. In the worst places right now, there's checks of
svn:executable, svn:keywords and svn:line-style - after this, there'd
be one more again.
* Visions of grandeur - pluggable translation
Instead of adding a yet another parameter to the translation functions
- abstract them more. Decide the forms a file can appear in - I've
been initially thinking about: untranslated (eg. text-base form),
fully translated (normal working copy form), merge form (eg. used in
conflicted files). Then start separating the hard-coded keyword and
newline parameters and instead use a generic translation
interface. Once there's just simple functions for translating and
de-translating files, separate newline translation and keyword
substitution into separate files.
After that, make the translations pluggable - come up with a dynamic
loading scheme for pluggable translations, like the ra-interface. And
then, finally, implement the special file storage.
Obviously, special properties, such as svn:executable, should be tied
in at some point as well, even though they do not consist of
translation as such.
***
So. Thoughts? :-)
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 23 22:06:12 2002