Thomas Hallgren wrote:
> Brock Janiczak wrote:
>> Eclipse already uses natives for things other than SWT, for instance
>> the filesystem plugin.
>
> The filesystem platform native plugin is optional and only needed when
> you want automatic workspace refresh (since Java has no API for file
> system events ... yet). I assure you, we really do create platform
> agnostic distributions based on Eclipse.
I was referring to the new filesystem plugin
(org.eclipse.core.filesystem) added in 3.2 that provides access to file
attributes (including execute bit) and is used by the Eclipse Filesystem
(EFS)
My point was that you can create platform agnostic distributions when
you have natives, so long as you provide natives for all platforms, or a
fallback java solution. We *can* provide natives for all platforms, but
they won't always work due to their reliance on third party natives.
>
>> The short answer is: "very hard". You would need to support the SVN
>> working copy format (not so hard) as well as the FSFS repository type
>> (really hard). Maintenance would be a major issue. The Subversion
>> team does a great job of adding new features, which is great for
>> users, but not so great if you have to maintain your own client
>> implementation.
>
> OK, my mistake then. I though the JavaHL and JavaSVN where API's on
> top of a protocol only and that only the server side was concerned
> with FSFS. Just out of curiosity, why is the client concerned with that?
There you go. Alex answered for me :)
It would be much easier if you only wanted to support the svnserve or
webdav protocols as these are just transport protocols, but quite a few
people use the 'file'.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Jul 6 12:13:20 2006