Holger Stratmann <tigris@finch.de> wrote on 01/09/2006 04:18:40 PM:
> Ah indeed, thanks for the answer :-)
> I had actually checked if "classes" was versioned and was "pretty sure"
> (tm) it wasn't *g*
>
> Well, anyway: I think Subclipse could handle that a bit "more
> gracefully". TortoiseSVN displayed the folder as "obstructed" and not
> selected for the commit, but did not cause any other problems. I just
> didn't commit this one.
>
> Subclipse shows an error popup as soon as I just switch to the
> Synchronize view.
> And, as I just proved: This irritates users and I did not know if I
> would be able to commit and if the information displayed in Synchronize
> was accurate.
>
> Maybe a little item on the todo list...
>
> Anyway: Thanks for the help, I'll "fix" this one.
TortoiseSVN does not have any option like the Synchronize view so it is
not necessarily an apt comparison. If you just use Team -> Commit and
Team -> Update etc... it might behave more like TortoiseSVN. I have not
tried it so I am not sure what it will do. Also, ultimately it is
Subversion that is failing so it isn't necessarily something we can just
fix in Subclipse. If we ask Subversion to tell us the changed items in
your workspace, and it throws an Exception instead of giving us an answer,
there is not a lot we can do to work around that.
If you use the Subversion command line and run "svn status --show-updates
--verbose" I suspect you will get the same error. In theory I think that
the TortoiseSVN "Check for Modifications" option with the Check Repository
option would be fairly equivalent.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Jan 10 08:39:56 2006