> Martin,
>
> Please read below.
>
> Assuming we are going to need to keep the current approach of
> calling svn info, this is what I propose we do. I will add a
> new method to svnClientAdapter that looks like this:
>
> public boolean statusReturnsRemoteInfo() { }
>
> The JavaSVN adapter will return true, the other two will
> return false.
> Within Subclipse, you could then condition the usage of svn
> info to when this method is false. In the case of JavaSVN,
> all of the info you need should exist in the call to svn
> status. Of course I will also need to commit the latest
> version of JavaSVN, which actually does this.
>
> Assuming we can get JavaHL enhanced for Subversion 1.3, we
> would just need to change the boolean to true in the JavaHL adapter.
>
> What do you think?
>
> Mark
I agree.
I'll adapt the statusCommand code accordingly.
What about that "mixed" mode ?
For this single synchornization status call only - we will force to JavaSVN
(ignoring eclipse svnClientAdapter preference) ?
Since we are going to ship JavaSVN within Subclipse distribution it could
work ? Or did I miss something ?
(I vaguelly remember there was some comment there that we even do not need
user credentials for that. Or was it somewhere else ?)
Not that I like such sort of approaches, but as a workaround until fixed svn
1.3 is out it might save us from calling these expensive infos ...
> PS - In debug, I noticed that svn info is being called on
> locally modified files. Is this necessary? Does the status
> call not tell us that it is an outgoing change only?
I'm not sure now. I need to see the code.
But you're probably right, for outgoing changes the (repository)
text/propStatus should be "normal",
the WC should be changed. I'll check it.
Martin
Received on Tue Aug 9 01:19:11 2005