Mark Phippard wrote:
> I think you are way off base here. The problem this error is reporting is
> serious, and that is why we are displaying it so prominently. I have only
> seen one instance where the message is a red-herring, and that is the case
> where your entire workspace is a Subversion WC. In that scenario, you can
> get rid of the error message by storing your projects outside the
> workspace and importing them in.
Aha! This is the case I'm seeing. I routinely place each workspace in a
subversion WC as its the only way to commit across multiple projects in
a single revision IFAIK. Would it be reasonable / feasible to detect
the "workspace is wc" case and not display the message? I'd be happy to
look into submitting a patch but haven't worked on subclipse previously
so may need some guidance.
The suggested work around seems a reasonable short term solution but
forever maintaining 2 directories per workspace seems an awkward long
term solution. (I routinely switch between several workspaces in my day
and maintain at least one workspace on two other machines)
>
> We have a String point to a file, and that is it. To do anything with it
> in Eclipse we need an IResource. Eclipse provides a method that lets us
> get an IResource based on the string. When the call to that method comes
> back null, we display this errorm, but only once per session as you will
> typically get it for every file. This null causes Subclipse to not be
> able to function correctly.
Having read this, the error message and the faq entry I think I have a
handle on what's happening. I can believe these null references would
cause a problem but why are they a non-issue in the workspace is wc case?
>
> We had lots and lots and lots of users getting this problem before we
> figured it out and the symptoms were very hard to interpret. The fix is
> generally easy to resolve.
That's fair enough but I stand by the claims that the error message is
difficult to take in and interpret. IMHO, a 7 sentence paragraph is too
much to expect a user to digest and act upon accordingly. Users are
likely most interested in the resolutions and not the the causes or the
frequency of the error message, especially given that there is a url
available that can explain these in appropriate depth. Given that the
message is displayed once per session then it seems reasonable to do the
extra work necessary to identify the paths involved. I'd suggest a
simpler bullet based message:
An error was encountered retrieving the Eclipse resource for:
'F:\workspace\Project'.
Possible resolutions:
* Reload project as 'f:\WORKSPACE\Project' rather than
'F:\workspace\Project'
* Use JavaSVN interface
See: http://subclipse.tigris.org/faq.html#path-case for background
information.
Again, if you think something like this is reasonable I'll try and work
out a patch.
>
> I have no plans to remove the error message. I already added code to make
> sure it only displays one time per Eclipse session.
>
> Mark
Understood. Removal doesn't seem appropriate given my case is the one
known exception to the problem. I think improving the message would be
reasonable though.
Rob
>
>
>
> Rob Oxspring <roxspring@imapmail.org> wrote on 03/31/2006 06:53:44 AM:
>
>> I've seen the path-case error message cropping up in eclipse and have
>> pretty much learned to ignore it as there is no discernible problem
>> caused. FWIW my workspace path matches the canonical path and the same
>> holds for the files created within - and eclipse seems happy whether the
>
>> workspace path matches or not anyway. IMHO the message is annoying,
>> confusing and infuriating so here are some suggestions to improve it:
>>
>> Shorten the message. The error message is long winded and by the end
>> appears to offer hypotheses of why it may or may not be the case. This
>> information is great for a FAQ but just detracts from the point of the
>> original error. Keep the error message concise and meaningful.
>>
>> Display both expected and actual values. At present one version of the
>> value is displayed and it is unclear whether this is the one eclipse is
>> expecting or the one causing the problem. From the sounds of it you
>> should be able to get the before and after since its just about the
>> inputs / outputs to the javahl layer. Displaying both will make the the
>
>> error message less ambiguous.
>>
>> Allow the warning to be disabled. Unless you are certain that there
>> will be a problem ultimately caused by this mismatch then the message
>> will simply be displayed daily and slowly ignored subclipse's error
>> messages altogether. Stop the rot and allow people to disable the
>> message so that they really do see important errors in the future.
>>
>> Offer some advice. Maybe the advice is complicated enough that it
>> should go in the FAQ but please offer something. At the moment there
>> seems to be nothing that I can do to reproduce the effect of issue 285
>> so I'm left with no clues as to what I have to do to stop the warning
>> from appearing and I'm offered no real reasons to do so either, other
>> than the daily indecipherable error message from subclipse.
>>
>> I'm trying not to be too grumpy here guys, subclipse is generally really
>
>> good and I appreciate the effort but this message just leaves me baffled
>
>> and frustrated every time I pay attention to it.
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sun Apr 2 00:31:26 2006