"Georg-W. Koltermann" <Georg.Koltermann@mscsoftware.com> wrote on
09/26/2006 11:03:53 AM:
> my first kind of real life test with Subclipse let me run into multiple
> problems.
>
> The configuration is Ubuntu 6.06, Eclipse 3.2, subclipse 1.1.6, svn 1.4
> (javahl). This is what I observed:
>
> 1. I checked out a label from a readonly mirror svn repository.
> Modified a file, tried commit, observed the exception due to the fact
> the repository is readonly. Fine.
>
> 2. I relocated the repository to point to the master r/w repository.
> Tried to commit again, observed another exception because the source
> location was a label that is configured as readonly in the dav_svn
> adapter. Fine.
>
> 3. I branched off to a r/w location, using team branch/tag on the
> project node in the Java perspective. Fine.
OK, so up to here, none of this has had anything to do with Subclipse.
> 4. Now I wanted to switch my checkout to the newly created branch.
> Called team switch, clicked browse for the branch and --- didn't find
> the new branch. Oops?
>
> I hit refresh (F5) on the project node and also on the repository node
> in the SVN exploring perspective, and then on a second try I could
> successfully switch to the new branch.
Subclipse caches the tree within your session for performance. If you
have already expanded the tree in some view then it will be cached and
need to be refreshed.
> 6. Got adventurous and tried a merge from another branch. It ran for a
> while, I saw a couple conflicts scroll by in the console. I then opened
> the synchronize view and -- oops -- found no conflicts. There were only
> outgoing changes. Surprisingly I also found files like
> "foo.linke-version-1234" and "foo.rechte-version-1234" for files that
> apparently had a conflict. (I don't recall the exact names, but the file
> names apparently were German translations of "left-version" and
> "right-version" or some such. Yes I am using a German locale in Eclipse
:-(
Conflicts produced by a Subversion merge in your working copy have nothing
to do with the Synchronize view and would not show as conflicts in that
view. They are decorated as conflicts in the standard views and there are
also Problem markers added to the Problems view, including Quick Fix
resolution actions. The normal procedure to fix a conflict produced by
Subversion are to resolve the conflicts in the file using either an editor
or the Edit Conflicts action that we supply. Once they are fixed, you
then have to take the Mark Resolved action to tell Subversion that you
have dealt with the conflicts. This action will get rid of the left,
right versions that Subversion created when it produced the conflict.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Sep 26 18:51:02 2006