Jump to: navigation, search

Difference between revisions of "Subversive New and Noteworthy"

Line 1: Line 1:
'''Also see the New & Noteworthy for:''' [[Subversive New and Noteworthy for Kepler|Kepler]], [[Subversive New and Noteworthy for Juno|Juno]], [[Subversive New and Noteworthy for Indigo|Indigo]], [[Subversive New and Noteworthy for Helios|Helios]], [[Subversive New and Noteworthy for Galileo|Galileo]]
+
'''Also see the New & Noteworthy for:''' [[Subversive New and Noteworthy for Luna|Luna]], [[Subversive New and Noteworthy for Kepler|Kepler]], [[Subversive New and Noteworthy for Juno|Juno]], [[Subversive New and Noteworthy for Indigo|Indigo]], [[Subversive New and Noteworthy for Helios|Helios]], [[Subversive New and Noteworthy for Galileo|Galileo]]
  
 
== Introduction  ==
 
== Introduction  ==
  
In this release we spent a great deal of effort in order to improve plug-in's stability and usability, but the main point was to rework SVN integration API, introduce SVN 1.8 support and provide access to repository administration API.  
+
Main target of this release is not just a stability improvement, but improvement in code quality of the main plug-in and its integrations.
  
 
== SVN 1.8 support  ==
 
== SVN 1.8 support  ==
  
Bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=416782 416782], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=416783 416783], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=416784 416784], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=416796 416796], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=417768 417768] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=423701 423701]. SVN 1.8 support is a feature that is widely requested by community, since there are not just some new features were introduced, but the working copy format was made incompatible with the previous one yet again, which in turn breaks your work when you're trying to mix SVN 1.7 and SVN 1.8 clients usage.  
+
There is a change to SVN 1.8 support in SVN integration API regarding naming of one of the constants and there is an improvement regarding SVN errors handling (please check details in the API section).  
  
 
== Rework of SVN integration API  ==
 
== Rework of SVN integration API  ==
  
Since there was a long history of changes in SVN integration API dictated by the changes in SVN functionality, there were inevitably a few of odd things that could make its usage somewhat annoying. So, while working on bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=417768 417768] we've made a lot of changes in order to make SVN API look more uniform, easy to understand and use.
+
Long history of development leads to some consequences, in our case it is a baggage of supporting older Java versions, which could lead to a drop in code quality and so on. So, we analyzed the code and found some critical points, which if reworked would bring great improvement in code quality to the plug-in itself and some of the related integrations.
What was changed:
+
Also there is always a need to provide more facilities to the integrators and to improve user experience. And so we decided to concentrate on the following matters:
* ISVNConnector.Depth was moved level up and renamed to SVNDepth
+
* mistake in semantic of constant's naming
* repository administration-related APIs were moved to the separate interface ISVNManager
+
* heavy usage of integer constants were enumerations could be used inherited from Java 1.4 compatible plug-in version, that could cause (and actually causes) misuse of a constant
* ISVNConnector.commit now returns revisions of successfull commits through ISVNProgressMonitor
+
* introduction of new ways to handle SVN errors.
* in order to make naming conventions uniform, some methods were renamed:
+
** doImport -> importTo
+
** doExport -> exportTo
+
** logEntries -> listHistoryLog
+
** info -> getInfo
+
** list -> listEntries
+
** getProperties -> listProperties
+
** getRevisionProperties -> listRevisionProperties
+
* some methods were renamed/deleted due to changes in SVN API in order to better reflect their functions:
+
** removeProperty and setProperty were replaced with setPropertyLocal and setPropertyRemote
+
** remove was split to removeRemote and removeLocal
+
** copy was split to copyRemote and copyLocal
+
** move was split to moveRemote and moveLocal
+
** merge, diff and diffStatus methods that were receiving two different URLs as their arguments were renamed to mergeTwo, diffTwo and diffStatusTwo accordingly.
+
* SVNNotification.NodeLock.isKnownStatus was renamed to SVNNotification.NodeLock.isStatusKnown
+
* SVNNotification.NodeStatus.isKnownStatus was renamed to SVNNotification.NodeStatus.isStatusKnown
+
* SVNNotification.PerformedAction.isActionKnown was renamed to SVNNotification.PerformedAction.isKnownAction
+
  
== SVN repository management API support  ==
+
As a result of our work there are 3 major points to the API changes in this release:
 +
* The masked constant ISVNConnector.Options.DISALLOW_MIXED_REVISIONS of 2.x version was removed and the constant ISVNConnector.Options.ALLOW_MIXED_REVISIONS with the same value was added, since there was a semantic error in its naming
 +
* All the untyped constants which were defined in version 2.x just as plain integer values, now are defined using Java enumerations. Which automatically means changing the API methods signatures. For example the signature:
 +
    public void add(String path, int depth, long options, ISVNProgressMonitor monitor) throws SVNConnectorException;
  
Bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=417769 417769]. For a long time we've been using one of repository management functions in order to support UI functionality (see bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=333202 333202]). So, is there a reason why we shouldn't provide access to all the other features? Definitely not! Now there is ISVNManager interface which provides support for all the repository management functions.
+
    was changed with the following one:
 +
 
 +
    public void add(String path, SVNDepth depth, long options, ISVNProgressMonitor monitor) throws SVNConnectorException;
 +
 
 +
    and so on.
 +
* SVN error categories are introduced and so are the methods to detect to which category the error belongs to. There're 2 such methods in SVNErrorCodes class (and a set of corresponding constants, of course):
 +
 
 +
    public static boolean belongsTo(int errorCode, int errorCategory);
 +
    public static int categoryOf(int errorCode);
  
 
== Latest SVN client libraries included  ==
 
== Latest SVN client libraries included  ==
  
Bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=434041 434041], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=434042 434042], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=430498 430498] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=430499 430499]. There were many issues fixed recently in the SVN support libraries and so, it's reasonable to update Subversive SVN Connectors with the most recent ones.  
+
Bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=465831 465831], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=465830 465830], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=465795 465795] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=465801 465801]. The most important is update of SVN Kit 1.8.x based connector to the SVN Kit 1.8.9 version, since we're receiving a lot of reports regarding issues with this one.  
  
 
== Usability improvements ==
 
== Usability improvements ==
  
Bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=419850 419850]. Since SVN provides versioning not just for the data in files but for the directory structure itself too, there is such a state as "replaced file" - it happens when you not just change the file content, but replace it as a whole. It is nice to know that a replacement took place, but it may be not so nice when you understand that you wanted to to change the file content by overwriting it, but instead lost the history of all the changes of the original file. So, while it is important to preserve SVN functionality there are some usability issues that should be solved and it is the reason why we've implemented the "Treat replacement as Edit" option which is present in commit dialog and preferences and allows you to override the default SVN behaviour.
+
Since m2e is now a project under Eclipse.org umbrella, we too moved Subversive-m2e integration to Eclipse (bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=455407 455407]). This way it'll be much easier to install to the ones who need this integration.
 +
 
 +
Since there're conflicts in key binding schemes (due to global key bindings in the operating environment or with other plug-ins in Eclipse IDE) we have created our own predefined schemes "Default + Subversive" and "Default + Subversive (Ubuntu)". Each of them introduces a slight changes in key combinations in order to provide access to all the important features through keyboard accelerators (bugs [https://bugs.eclipse.org/bugs/show_bug.cgi?id=456139 456139] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=309074 309074]).
 +
 
 +
[[Image:Svn-key-bindings.png]]
 +
 
 +
There are some cases when user do not want to go along with the connectors installation procedure the moment it is proposed automatically by the connectors discovery feature. The decision is saved and there is no way to call discovery feature second time. If such a case happens, there is a lot of work to install connectors later, since the user must find the URL to the correct version of the connectors updates site, then add it in Eclipse Installation Manager before installing connectors themselves. In order to resolve the situation we have added the fast access button in the connectors selection page of plug-in preferences (bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=442249 442249]).
 +
 
 +
[[Image:Svn-get-connectors-button.png]]
 +
 
 +
SVN supports multiline properties, while the automatic properties configuration page doesn't, since the new line separates properties from each other. This prevents using automatic properties in case a multiline one is needed. In order to solve the issue we have introduced a new syntax of defining a property in Automatic Properties dialog. In order to define a multiline one you just need to separate supposed lines with the \n character sequence. In case you actually need to define a \n character sequence in your property, then just use the masked one: \\n (bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=445999 445999]).
  
Bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=427577 427577]. We've always concentrated on protecting users from entering invalid data were it is possible, so that there won't be any misunderstanding on how the SVN works and so on. But there are always exceptions from the general rule. Many users have found a way to benefit from a little missuse of svn:ignore property. When you're using an invalid character at the start of the line the whole line is ignored by SVN client and so, you may use it as a comment. That is why we've added the option "Allow svn:ignore's mask validation".
+
Also there are typical SVN errors requiring user to perform some actions over the working copy. It is nothing strange when you know what to expect, but may confuse a beginner. So, we made a special page in the Subversive's help, that describes those typical errors and possible solutions. The help page could be summoned directly from the error notification dialog, which should enhance beginners experience with SVN (bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=457516 457516]).
  
 
[[Category:Subversive]]
 
[[Category:Subversive]]

Revision as of 09:29, 5 May 2015

Also see the New & Noteworthy for: Luna, Kepler, Juno, Indigo, Helios, Galileo

Introduction

Main target of this release is not just a stability improvement, but improvement in code quality of the main plug-in and its integrations.

SVN 1.8 support

There is a change to SVN 1.8 support in SVN integration API regarding naming of one of the constants and there is an improvement regarding SVN errors handling (please check details in the API section).

Rework of SVN integration API

Long history of development leads to some consequences, in our case it is a baggage of supporting older Java versions, which could lead to a drop in code quality and so on. So, we analyzed the code and found some critical points, which if reworked would bring great improvement in code quality to the plug-in itself and some of the related integrations. Also there is always a need to provide more facilities to the integrators and to improve user experience. And so we decided to concentrate on the following matters:

  • mistake in semantic of constant's naming
  • heavy usage of integer constants were enumerations could be used inherited from Java 1.4 compatible plug-in version, that could cause (and actually causes) misuse of a constant
  • introduction of new ways to handle SVN errors.

As a result of our work there are 3 major points to the API changes in this release:

  • The masked constant ISVNConnector.Options.DISALLOW_MIXED_REVISIONS of 2.x version was removed and the constant ISVNConnector.Options.ALLOW_MIXED_REVISIONS with the same value was added, since there was a semantic error in its naming
  • All the untyped constants which were defined in version 2.x just as plain integer values, now are defined using Java enumerations. Which automatically means changing the API methods signatures. For example the signature:
   public void add(String path, int depth, long options, ISVNProgressMonitor monitor) throws SVNConnectorException;
   was changed with the following one:
   public void add(String path, SVNDepth depth, long options, ISVNProgressMonitor monitor) throws SVNConnectorException;
   and so on.
  • SVN error categories are introduced and so are the methods to detect to which category the error belongs to. There're 2 such methods in SVNErrorCodes class (and a set of corresponding constants, of course):
   public static boolean belongsTo(int errorCode, int errorCategory);
   public static int categoryOf(int errorCode);

Latest SVN client libraries included

Bugs 465831, 465830, 465795 and 465801. The most important is update of SVN Kit 1.8.x based connector to the SVN Kit 1.8.9 version, since we're receiving a lot of reports regarding issues with this one.

Usability improvements

Since m2e is now a project under Eclipse.org umbrella, we too moved Subversive-m2e integration to Eclipse (bug 455407). This way it'll be much easier to install to the ones who need this integration.

Since there're conflicts in key binding schemes (due to global key bindings in the operating environment or with other plug-ins in Eclipse IDE) we have created our own predefined schemes "Default + Subversive" and "Default + Subversive (Ubuntu)". Each of them introduces a slight changes in key combinations in order to provide access to all the important features through keyboard accelerators (bugs 456139 and 309074).

Svn-key-bindings.png

There are some cases when user do not want to go along with the connectors installation procedure the moment it is proposed automatically by the connectors discovery feature. The decision is saved and there is no way to call discovery feature second time. If such a case happens, there is a lot of work to install connectors later, since the user must find the URL to the correct version of the connectors updates site, then add it in Eclipse Installation Manager before installing connectors themselves. In order to resolve the situation we have added the fast access button in the connectors selection page of plug-in preferences (bug 442249).

Svn-get-connectors-button.png

SVN supports multiline properties, while the automatic properties configuration page doesn't, since the new line separates properties from each other. This prevents using automatic properties in case a multiline one is needed. In order to solve the issue we have introduced a new syntax of defining a property in Automatic Properties dialog. In order to define a multiline one you just need to separate supposed lines with the \n character sequence. In case you actually need to define a \n character sequence in your property, then just use the masked one: \\n (bug 445999).

Also there are typical SVN errors requiring user to perform some actions over the working copy. It is nothing strange when you know what to expect, but may confuse a beginner. So, we made a special page in the Subversive's help, that describes those typical errors and possible solutions. The help page could be summoned directly from the error notification dialog, which should enhance beginners experience with SVN (bug 457516).