Paul Lorenz <plorenz@gmail.com> wrote on 01/27/2006 01:35:41 PM:
> Ok, I missed that. We have a couple thousand warnings in our project
> (working on cleaning them up, buts it's a slow process), so they were
> easy to miss. I'm still going to look at having those show up in the
> conflicts view, because they are conflicts, and it's (IMO) the natural
> place to look for them :) Actually right now, I'm not sure how
> anything ever shows up in the conflicts view for subclipse.
If you want to pursue that, go ahead, but I think it is a big mistake.
There is very little, if any, relationship between a Subversion conflict
and a Synchronize view conflict. I do not see how you can reconcile the
two.
A Subversion conflict exists in your working copy after a merge or update
and needs to be resolved locally in the working copy and then likely
committed to the repository. The Edit Conflicts action provides a
graphical ability to see and resolve the conflicts.
A Synchronize view conflict simply means that you have local changes in a
file, and there is also a newer version of the file in the repository.
These changes may or may not conflict with one another. Typically they
will not, and a Subversion update would be able to auto-merge the remote
changes into the local file, at which point it is now just an outgoing
change.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Jan 27 19:49:21 2006