On Wednesday 15 September 2004 11:33, Folker Schamel wrote:
> If you upgrade svn, you would have to recompiler ALL applications
> using the svn lib.
Well, that's the beauty of the non-finalized API. ;-) I think the way they
solve it in Windows is by allowing each app using such an API to redistribute
the dll (assuming that the functionality is compatible of course). Not sure
whether this the best thing. I'd rather use the API versioning, where each
'public' data structure has a version associated with it which allows the API
implementation to handle the structures passed by the caller according to the
version of the structure. This is complicated and mostly used in the
client-server systems with multiple distributed clients that must withstand
server upgrades.
OK, you've convinced me that the way I implemented it is not good for 1.x.
Which kind of sucks - after all my change is supposed to be strictly
internal. Maybe this structure shouldn't be public in the first place?
Now, what are my options WRT getting this feature into SVN? IMHO, this feature
is useful enough to be implemented as enhancement (let alone for backward
compatibility). So far I see only four options:
- Wait till the post 1.x development and try my luck again.
- Implement the ugly svn_keywords2_t structure and a parallel set of the API
(blech) which according to the current rules would become a *public* API as
well, which scares the living shit our of me.
- Wait for the announced 'generic' way to expand keywords sometime in the
future.
- Stage a coup and get the aforementioned structure out of the public API
saving us a lot of headache in the future at the expense of some headache for
the current SVN-based app builders ;-) (how many such apps are there anyway?
How many of them use this data structure?)
Suggestions?
--
Alexander L. Belikoff
PGP/GPG fingerprint: 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701
(http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 15 18:00:49 2004