> Suppose that I'd like to have the file deleted, what should I do
> in subclipse?
Probably just do an Update. I *think* this will leave the file coming from
the server as unversioned. You could always do Revert, Update, Delete,
> If I'd like to get the new version instead, what
> should I do?
In this case, you definitely want to do Revert and then Update.
> Using the command line, I can perform an update without any
> error. A local Bar.java is created but it is unversioned.
That is what I thought (see above).
> I try to commit, it tells me there is a conflict. To resolve
> the conflict, I can perform a "resolved". Then I can commit
> (Bar.java is still unversioned). I'm not sure if this is a
> natural behavior, but it at least tells me there is a conflict
> and allows me to resolve it.
Provide a transcript showing what the command line tells you. Toss a few
svn status commands in to show what Subversion is saying about your working
copy. I think Subclipse was mostly trying to tell you the same thing, the
decorators were just confusing you. For example, the conflict icon in the
Synch view is not the same as a Subversion conflict. A Synch conflict
simply means there is both a local change and a server change to the same
file. It is possible that a Subversion update will handle it fine.
Personally, I would just use the Synch view for status info and compares,
but then stick with update and commit for the actions. Worst case is that
update creates a local conflict that you then can resolve using the same
technique you would have used from the Synch view.
I am not saying there aren't any problems here I just do not think it is
entirely clear what they are and what the correct behavior would be.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Wed Nov 9 13:05:10 2005