Subclipse plugin problems and solutions by iht11609

VIEWS: 0 PAGES: 8

									                              Poznań Supercomputing and Networking Center
                                                  http://www.man.poznan.pl/



      Difficulties encountered using Subclipse plug-in
           Michał Balcerkiewicz <michal.balcerkiewicz@man.poznan.pl>,
                Michał Giertych <michal.giertych@man.poznan.pl>,
                     Jacek Łukasik <jaxlucas@man.poznan.pl>,
                  Błażej Pietrzak <blazej.pietrzak@man.poznan.pl>

1 Introduction
           Version Control Systems (VCS) are used to track modifications of the program
source code. They record the reasons for each code change, details of the change, and
components affected. As a result it is possible to recreate snapshots of the software at
different points in time.
            Subversion is an open source version control system. It operates on directories
and files typically stored in a place called central repository. The repository is like an
ordinary file server, except that it remembers every change ever made to all files and
directories. Programmers exchange contents between a remote repository and local
working copies. This feature allows various people to modify and manage concurrently the
same set of data from their respective (distributed) locations which fosters collaboration.
Some of Subversion features like atomic commits, directory versioning, true versioning of
renamed files, possibility of adding and versioning meta-data distinguish it among other
popular versioning systems (e. g. CVS).
          Subclipse plug-in extends Eclipse IDE functionality by adding integration with
Subversion. The plug-in provides a comfortable and robust user interface within Eclipse
IDE similar to the built-in CVS client. Subclipse was initially evaluated to check whether it
can be successfully used as a stable Subversion client. This brief report describes
problems that we encountered during plug-in usage.

2 Evaluation
         Version 0.9.106 of Subclipse plug-in was tested. Below there is a list of
encountered problems and solutions if a workaround was found for a given issue.

2.1 Conflict editor

Problem description
          When two programmers modify simultaneously the same file and then try to
commit the changes in the version control system a conflict may occur. The version control
system does not commit a change and gives information to the programmer that he has
created a conflict on a given file. The programmer has to solve the conflict – decide what
content should have the conflicting file. Since it happens very often and invalid conflict



                                             1
                                Poznań Supercomputing and Networking Center
                                                    http://www.man.poznan.pl/


resolution could lead to hard to find problems there is a strong need for a tool that could
help the programmer to cope with this task.
           The tool should display a conflict in two windows: one window would show the
file contents from the remote repository, while the latter would show the file from the local
working copy. It should also highlight lines which are different in those files and give ability
to move those lines of text from the remote repository to the working copy, and of course it
should enable editing the file from the local working copy.
           Although Subclipse supports a Conflict Editor, it gives different behavior
depending on which perspective is used. When the Synchronize perspective is used it
behaves just the same way as Eclipse's CVS client which is a desired behavior. When
used in the Java Perspective it does not provide Conflict Editor, but writes the differences
between two files directly to the local working copy in the following form:
<<<<<<< .mine
Conflicting line in local working copy
=======
Conflicting line in remote repository under the revision 1393
>>>>>>> .r1393
             For this conflict it creates the following files: FileName.java.mine – version of
the file in the local working copy, FileName.java.r1392 – previous revision of the conflicting
file, and FileName.java.r1393 – current revision from the remote repository. Of course
numbers after rXXX depend on the revision number. These where given as examples.
            The conflict editor can be run manually. To do that, one must right-click the
conflicting file and choose from the pop-up menu “Team/Edit conflict...” option. After the
conflict has been edited successfully, the SVN client must be explicitly noted that the
problem has been resolved. One must choose from the conflicting file's context menu
“Team/Mark Resolved” option. Then additional conflict files (*.mine, *.rXXXX) are also
removed from the repository.

Solution
            Such form of conflict resolution is error prone and inconvenient. It is easy to
forget e. g. to mark resolved conflicts explicitly. So, the best way to cope with conflicts is to
use Team Synchronizing perspective.

2.2 Branching/Tagging a project

Problem description
            Although Subclipse supports branching/tagging for HEAD and specified
revisions, only creating a branch/tag from the working copy works. When one tries to
create it in a different way, Subclipse ends up with an error. Creating a branch/tag on a
given directory (or project) implies adding all files that are in a given directory. It means



                                               2
                              Poznań Supercomputing and Networking Center
                                                  http://www.man.poznan.pl/


that files which were not added to the trunk, but exist in the working copy will be added to
the branch/tag. Unfortunately Subclipse plug-in does not warn users about this “feature”.

Solution
          There are two solutions to this problem. The first one is to commit all changes to
the trunk before making a branch/tag. Files that the user does not want to add to the
branch/tag should be removed or added to svn ignore. After that user can create a
branch/tag.
          The latter solution is to checkout the trunk to the new directory and then create
a branch/tag from the clean working copy.

2.3 Switching to the branch/tag and reverse

Problem description
          “Team/Switch” option is used for switching between different revisions of the
project. Unfortunately it sometimes provides unpredictable errors like destroying project
contents of the working copy. The other scenario that could occur is a situation where after
performing a switch there is no revision information for the files in the Package Explorer
view.

Solution
          If switching has destroyed a user’s project, he should checkout the project from
the remote repository. If switching does not display revision numbers for files, the project
should be refreshed. This may not work in most situations, so it remains only re-running of
Eclipse IDE if everything else fails.

2.4 Merging a trunk with a branch

Problem description
           We tried to merge a trunk of the project with a branch. Subclipse gave us invalid
results. Below is what we tried to do:
   1. The project contained only empty CHECKTHIS.OUT file. The project was under
      Subversion revision control system.
   2. A branch was created.
   2. In the branch CHECKTHIS.OUT file was changed and contained “This is a branch”
      line. Also a new file NewFile.txt was added to this branch.
   3. CHECKTHIS.OUT file from the trunk was modified after the branch was created. It
      now contains a line “Modified TRUNK”.



                                             3
                              Poznań Supercomputing and Networking Center
                                                  http://www.man.poznan.pl/


   4. The branch was merged with the trunk by clicking “Team/Merge...” option. It should
      add the NewFile.txt to the project trunk and should show a conflict on
      CHECKTHIS.OUT file (file was changed after the branch had been created).
          Unfortunately, merge automatically updated the CHECKTHIS.OUT file with the
contents from the branch. It even did not provide information about a conflict.
CHECKTHIS.OUT file contained only the line from the branch. Also file NewFile.txt has not
been added to the trunk. We tried many combinations of the merge parameters, but none
gave the expected behavior.

Solution
           Unknown.

2.5 Renaming a file

Problem description
          There is a problem with renaming files and tracking those changes by
Subclipse. We added a BeforeRename.java file to the trunk. Then we changed the file
name to AfterRename.java and committed it to the SVN repository. The revision history for
the AfterRename.java file is correct, but project checkout gives both files:
BeforeRename.java, and AfterRename.java. Everything was done in Java perspective.
          Careful look at SVN console gave information why this happened. Only
renamed file was committed to the remote repository. To make changes visible one must
commit on the package/project or use “Synchronize with Repository” command. This will
invoke BeforeRename.java file removal. The latter provides “Synchronize” view which
shows that the file is to be removed and a renamed file introduced.

Solution
           Do not commit a single file. Use “Synchronize with repository” command.

2.6 Adding new files with the same name in the same place by different
    users

Problem description
          Assume that two users wanted to add a new file with the same name in the
same place to the remote repository. Only the first one will add the file without problems.
However when the second one will want to perform similar action he will get errors.
          When doing „Update” command on a package containing this file, Subclipse will
not show any changes in this package even if there are some (in other files in this
package). There will be only an error information visible in the SVN console view and a
message box saying that the file already exists in the repository will be shown.
          ”Synchronize with Repository” on this package will not show that this file is


                                            4
                               Poznań Supercomputing and Networking Center
                                                   http://www.man.poznan.pl/


already in the remote repository. This file will be marked as ”outgoing/to be added”, but not
”conflict”.
            This behavior leads to a situation where developer who has been given the
error – “File already exists” is unable to update a package correctly. Files added by other
developers to the SVN Repository are not fetched to the local repository. “Updated”
package is considered by Subclipse as if all went correctly, and none incoming changes
are available.

Solution
           Always choose to ”Team/Synchronize with Repository” on the whole project, not
on a single component of the project. Always look at SVN console view when using SVN,
because sometimes Subclipse does not show any warnings or errors in pop-up windows.

2.7 Synchronization

Problem description
           When a conflict has appeared due to the previous bug and synchronization with
the repository was done on the directory containing this conflict, then no changes were
reported. Only synchronization on the whole project worked.

Solution
           Use “Synchronize with repository” on the whole project.


2.8 “Get Revision” option does not work with revisions imported from
    CVS

Problem description
           There are several places where it is possible to use “Get Revision” option (e. g.
in “Replace With/Revision...” or ”Compare With/Revision...” in the Package Explorer in
Java perspective). This feature allows to replace a local file with its other version from the
SVN repository.
           Unfortunately this works only with revisions committed using SVN clients but not
with those which were imported and converted from CVS repository.

Solution
           Use “Get Contents” instead of “Get Revision”.




                                              5
                               Poznań Supercomputing and Networking Center
                                                   http://www.man.poznan.pl/


2.9 ”Get Revision” option does not work with renamed files

Problem description
            Renamed files cannot be retrieved using “Get Revision” option. We created a
file BeforeRename.java and added it to the SVN repository. Then we renamed this file to
AfterRename.java and synchronized changes with repository. After that, we tried to
retrieve a revision of the file prior to its renaming (BeforeRename.java). Subclipse only
removed the file AfterRename.java from the working copy and did not retrieved the
revision from the remote repository.

Solution
           Try to use “Get Contents” instead of “Get Revision”.and change the file name.


2.10 Updating deleted package in “Team synchronizing” perspective

Problem description
           When a package is deleted from the remote repository the other developer
(after performing ”Team/Synchronize with Repository” on the project) will see only
information about deleted package in “Synchronize” view, while it should contain all
files/packages within that package that has to be removed due to the removal. Despite this
deficiency project synchronizing works fine.

Solution
           Unknown.


2.11 Reverting a file containing a conflict does not work properly

Problem description
             Revert is a mechanism for undoing modification in a local working copy. It is not
the equivalent for ”Override and Update” in Eclipse’s CVS client. Revert replaces the
modified file with the file's base revision.
             Unfortunately when we tried to revert a file containing a conflict it did not work
properly. All actions were performed in the Java perspective where we had the conflict file
(with additional files like *.mine, *.rXXXX, *.rYYYY).
             We updated a package containing the file that should cause a conflict. This file
had revision 2 in the local working copy, while in the remote repository it had revision 3.
After performing update the working copy contained the following files:
   the file that caused the conflict (modified base revision 2),
   revision 3 of the file,
   revision 2 of the file with conflict added to its content.


                                              6
                              Poznań Supercomputing and Networking Center
                                                  http://www.man.poznan.pl/


           When we wanted to perform revert on the conflicting file, Subclipse changed to
revision 3, instead of changing to the base revision 2. We think this behavior is improper.
Of course all local modifications done on revision 2 evaporated.

Solution
          Use Team synchronizing perspective instead of Java perspective for updates,
commits, etc.

2.12 Invalid information about packages/directories to update in Team
    Synchronizing perspective

Problem description
      Sometimes Subclipse shows in Synchronize view packages that were already
updated. The problem disappears when Eclipse is re-run.
It is a case when one invokes the “Get Revision” problem. Then when updating a project in
“Synchronize” view a removed file is shown. This is of course a desired behavior since the
working copy does not contain a file that the remote repository contains. The package
containing the removed file will be shown in every project synchronization, even when the
package has been successfully updated and no changes have been introduced.

Solution
           Re-running Eclipse removes the package from the “Synchronize” view.

3 Conclusions
          While using Subclipse plug-in we encountered several problems. Fortunately,
there are workarounds for most of them. The key issue is to remember that the project
synchronization can be done safely (in most situations) from the Team Synchronizing
perspective only. Other perspectives such as e. g. Java perspective may lead to the
inconsistent working copy. Subclipse should provide an unified access to Subversion no
matter which perspective is used.
           Renaming a file feature can be safely used only when the whole project is
synchronized. Committing the file that was renamed stores it with the revision history in the
remote repository which is correct. However in the remote repository there is still the file
before renaming. It should be deleted from the repository. It is not performed by Subclipse.
The plug-in should at least inform a programmer. When synchronizing the whole project
changes for it are shown, including the file to be removed. Then the programmer can
commit both the file renaming and the old file removal. Revert feature works properly in
most situations except when reverting a file containing a conflict.
          Getting a revision can only be performed on revisions that were committed by
SVN clients. It cannot be used on revisions imported from CVS. Additionally, getting a



                                             7
                                Poznań Supercomputing and Networking Center
                                                    http://www.man.poznan.pl/


revision does not work for renamed files.
          Subclipse probably does not correctly support merging of branches/tags.
Although, we tried many combinations of merge parameters, we could not perform
merging a branch with a trunk correctly. We do not know whether it is Subclipse's or SVN
problem.

References:
http://subversion.tigris.org/
http://subclipse.tigris.org/
http://www.eclipse.org/




                                            8

								
To top