1. Augie Fackler
  2. hgsubversion
  3. Issues
Issue #419 new

Initial file delta corruption

Brian
created an issue

Synopsis: A hgSubversion-converted repository shows an incorrect different initial revision for a file in Mercurial than it does in Subversion.

I have successfully used hgSubversion before on a much larger project, so this surprises me.

Detail: In this repository, more than one file has an issue post conversion, but this is the first file I'm troubleshooting. In this case, a Visual Studio project file is corrupted, and I've traced the issue back to the first delta applied to the original added version of the file:

Subversion's diff for the first revision:

Index: C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj
===================================================================
--- C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj    (revision 7910)
+++ C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj    (revision 7941)
@@ -62,6 +62,7 @@
   </Target>
   -->
   <PropertyGroup>
-    <PostBuildEvent>copy /Y XmlSpreadsheetLib.dll "C:\Dev\2009.06.08 SMART Reporting\DynamicReportEngineLib"</PostBuildEvent>
+    <PostBuildEvent>
+    </PostBuildEvent>
   </PropertyGroup>
 </Project>

Mercurial's diff for the first revision:

@@ -49,6 +49,7 @@
     </Reference>
   </ItemGroup>
   <ItemGroup>
+    <Compile Include="XmlFont.cs" />
     <Compile Include="XmlPackage.cs" />
     <Compile Include="Properties\AssemblyInfo.cs" />
     <Compile Include="XmlWorksheet.cs" />
@@ -62,6 +63,4 @@
   </Target>
   -->
   <PropertyGroup>
-    <PostBuildEvent>copy /Y XmlSpreadsheetLib.dll "C:\Dev\2009.06.08 SMART Reporting\DynamicReportEngineLib"</PostBuildEvent>
-  </PropertyGroup>
-</Project>

Another oddity is that in the diff shown for the Mercurial version, the added line for the XmlFont.cs include is from the next revision in the source Subversion repository:

Index: C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj
===================================================================
--- C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj    (revision 7941)
+++ C:/projects/NexusReportingSvn/XmlSpreadsheetLib/XmlSpreadsheetLib.csproj    (revision 8019)
@@ -49,6 +49,7 @@
     </Reference>
   </ItemGroup>
   <ItemGroup>
+    <Compile Include="XmlFont.cs" />
     <Compile Include="XmlPackage.cs" />
     <Compile Include="Properties\AssemblyInfo.cs" />
     <Compile Include="XmlWorksheet.cs" />

I don't need this particular project to be moved to Mercurial today, but this is a major concern. If it could be due to a setting change on my end, please educate me.

Comments (6)

  1. Brian reporter

    Right you are, this is a private repo. I am however thinking of taking this individual file and isolating it, recreating all of the revisions (there aren't many total) and seeing if it fails to convert properly by itself. It would make for a much easier investigation.

    I'm not sure what qualifies as exotic, but nothing I can think of. The file's project wasn't converted from some other VCS to Subversion, it began in Subversion.

    I've checked and the version of the Subversion client is 1.7.10 (6/1/13) and the server is running 1.7.2-2773.84. (Running as part of a Collabnet package) These are both pretty old, do you feel that solving the problem could be as easy as updating them?

  2. Augie Fackler repo owner

    Hm, no, 1.7.x is pretty modern - I was hoping for something ancient like 1.3.x.

    OOC, does the problem manifest if you provide --stupid to the clone operation?

  3. Brian reporter

    Using the --stupid switch, there were a slew of "Hunk #x FAILED at xxx" messages pumped to std err. during the clone, but oddly enough the deltas applied correctly on this file that I've been looking at. I then opened the entire solution to check it, and it builds to completion - so if there was any corruption, it wasn't enough to cause a compile error. Thanks!

  4. Brian reporter

    Tonight I'll create a fresh Subversion repository add that same project file (at v1) and make a series of changes to it mimicking the history of the original repo. If I can then recreate the problematic conversion I'll move the Subversion repo somewhere public and post a link up for you so that you can use it for testing, otherwise I'll just mark the ticket as resolved.

  5. Log in to comment