Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 311808 - Native JavaHL connector reexpands keywords on move, causing refactoring to break
Summary: Native JavaHL connector reexpands keywords on move, causing refactoring to break
Status: RESOLVED DUPLICATE of bug 315279
Alias: None
Product: Subversive
Classification: Technology
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Igor Burilo CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-05 19:20 EDT by Max Bowsher CLA
Modified: 2011-07-10 03:56 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Max Bowsher CLA 2010-05-05 19:20:29 EDT
Build Identifier: M20100211-1343

There is a problem when using the Native JavaHL connector and doing refactoring involving moving files (e.g. moving classes to a different package), when there are Subversion keywords in the file.

Specifically, it appears that the following sequence of events occurs:
1. Eclipse calculates file offsets of substrings which need to be amended for the refactoring (e.g. the package foo.bar.baz; statement)
2. Eclipse moves the file.
3. When using the Native JavaHL connector, the native Subversion code is triggered in such a way that it re-evaluates keywords such as $Id$.
4. Eclipse applies the refactoring, but because of the keyword re-expansion, the file offsets are incorrect, and it produces broken syntax.

Reproducible: Always

Steps to Reproduce:
1. Have a java file which has // $Id$ on the first line, and is checked into svn.
2. Be using the Native JavaHL connector.
3. Move this java file into a sub-package.
4. Observe that Eclipse has written the refactoring changes at incorrect file offsets.
Comment 1 Jens Meiss CLA 2010-08-26 11:24:37 EDT
Hi i have the same Problem with Refactor->Rename under Windows XP

If i rename the Class "RefactorTest" to "RefactorTest123" it renames the File but not the Classname and the syntax gets destroyed

----------------------------------
-- File before Refactor->Rename --
-- Filename: RefactorTest.java  --
----------------------------------

package de.test.subversive;

import org.apache.log4j.Logger;

/**
 * TODO insert comment here
 * 
 * @author Jens Meiß, $Author: MEISSJ $
 * @version $Revision: 7405 $
 * @since 26.08.2010, $Date: 2010-08-26 17:00:52 +0200 (Do, 26 Aug 2010) $
 */
public class RefactorTest {

  /**
   * Logger
   */
  @SuppressWarnings("unused")
  private static final Logger logger = Logger.getLogger(RefactorTest.class);
}

---------------------------------------
-- Result after the Refactor->Rename --
-- Filename: RefactorTest123.java    --
---------------------------------------

package de.test.subversive;

import org.apache.log4j.Logger;

/**
 * TODO insert comment here
 * 
 * @author Jens Meiß, $Author: $
 * @version $Revision: -1 $
 * @since 26.08.2010, $Date: $
 */
public class RefactorTest {

  /**
   * Logger
   */
  @SuppreRefactorTest123unused")
  private static final Logger logger = Logger.getLogger(RefactorTest123.class);
}

What you can see in this example:

* the Classname wasn't renamed, but the Filename was
* the Classname in the Logger-Statement was renamed
* @SuppressWarnings("unused") was renamed to @SuppreRefactorTest123unused")
* the SVN-Keywords are empty

and it only happens if one of the $Author: $, $Revision: $ and $Date: $ SVN Keywords are in the Class-Comment
Comment 2 Jorg Heymans CLA 2011-03-03 06:04:13 EST
A class like this causes equal breakage:


/* 
 *  $Id: MyClass.java 13242 2011-03-02 15:37:08Z jorg $
 */
package my.app.package;

public class MyClass {
}

javahl version : 1.6.12 r955767, eclipse helios sr1

When i select the generic svnkit connector the problem is solved.


Maybe this should be reported on the subversive website instead ??
Comment 3 Alexander Gurov CLA 2011-07-10 03:56:26 EDT
Already fixed. Duplicate of bug #315279.

*** This bug has been marked as a duplicate of bug 315279 ***