• 4
  • 13
  • 5
  • 1
  • 2
Der MEVA - Blog
Albrecht Weinert


a-weinert.de,  meva-lab.de
|< < > >|


blog... /subversion-bug-repair/   [en]
Albrecht Weinert

Subversion’s big bug – a repair

Being a good versioning system and "the" standard Subversion (SVN) nevertheless has some deficiencies mentioned in the (German) Tutorial

Subversion — on Windows with Active Directory

Download: http://a-weinert.de/pub/svn-win-de.pdf

One of the worst bugs: SVN ignores and forgets the file modification time (mTime) on first commit. It’s clear, of course, that a file modified and re-committed has to get a new mTime. (That might be the commit time, as well, as that can be kept close enough to modification time in most cases.)

The point is: for a file first committed respectively added its mTime must be kept intact. That’s true for a big bundle of use cases (and does no harm for almost all others). Not doing so constitutes a hard bug (not present in at least one very early SVN version). Making hundreds of files, may be collected over years, all the same age when put under version control is a behaviour so counter-intuitive that it managed to break people’s projects before they noticed the damage.

The thing gets harder as the persons responsible for this bug are very obstinately seeing and selling it as a feature. Cause, doing otherwise might provoke a make (= ANT’s pedecessor) bug in some situations. Reading the blogs and discussions on that point, now running over years, and seeing the best arguments and long lists of (until now no go) use cases of SVN ignored, is at least just fatiguing.

Hence Frame4J‘s tool FS was augmented to have a repair available and to rescue some of SVN’s use cases. As long as you still have any directories with the original intact files to be put or already put under SVN, this tool FS may now generate an ANT target to repair the mDates after checkout.

See also Frame4J, FS (docu), FS.properties (for ref.), CVSkeys (docu).

Handling:
As long as you still have a tree with the original file dates, go to its root and run
    java FS -repairSVN
there (as the simplest case). This will generate an ANT build.xml with content like the following example extract:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <project name="repair SVN's file modification time bug"
      default="repairDates4SVN" basedir=".">
 
 <!-- Conditional touches to repair the SVN forget mTime bug
      Generated at 26.10.2009 12:20:32
      by de.frame4j.FS  V.161  (26.10.2009)
      Copyright (c) 2009  A. Weinert  (a-weinert.de, frame4j.de)
 -->
   <target name="repairDates4SVN">

     <property name="firstCommit" value="10/26/2009 12:30 am"/>

     <touch datetime="08/02/1998  05:43:18 pm">
       <fileset  erroronmissingdir="false"
           file= "louv-p-1320.jpg">
         <date datetime="${firstCommit}" when="before" />
       </fileset>
     </touch>

     <touch datetime="01/08/2009 02:16:28 pm">
       <fileset  erroronmissingdir="false"
           file= "extra/solar-we-39-x360.jpg">
         <date datetime="${firstCommit}" when="before" />
       </fileset>
     </touch>

   </target>
 </project>

If you supply more than one directory to FS like
    java FS -repairSVN dir1 C:ArchallFiles Z:backup dir4
FS takes the first one as the "tree image root" whereto (relatively) the SVN repair task will be generated. In all the other directories FS searches for equal files. Equal means same name and size here. Of all equal files the oldest modification time is used as time for the SVN bug repair. In that usage of FS the "dir1" in above example might be the tree with modification times already spoiled by SVN.

This generated build.xml (or the target contained) has to go — best version controlled — to the respective root in the check-out respectively pre-deployment tree. Running it by ANT there (best as part of your build / deploy batch script) reconstitutes the the original mTimes. But (that’s the trick as, of course, you noticed) it’s done only if the mTime is (still) before the time condition stored in the property (firstCommit in the example).

This time condition is to be set slightly after the add respectively first commit of the particular (files). Frame4J‘s tool FS makes it ten minutes after its own run, if not told otherwise. So the mTime is repaired only if no later modifications were committed. That in sum gives you the expected and intuitive behaviour.

Hint 1: You must have at least ANT 1.7.1 as a bug of all older versions will crash on empty file sets due to files or directories deleted in between. As ANT (alas, they too!) keep this bug as a compatibility feature, we are very grateful that it can be switched off now (as could have been now ANT’s ugly 12h standard time format).

Hint 2: ANT, Frame4J and FS are all Java based. Insofar, under Windows, both ANT and FS suffer from the same ever recurring Java bug, that renders the mTime one hour wrong if it falls in summer time and Windows’ summer time automatic is on. As this bug (considered closed by SUN but recurring in 1.6_1x) hits both mTime reading and setting, the effect might be compensated here. Anyway, it will be better to switch of the (innocent!) Windows automatism before doing the work described above.

Feed für Kommentare zum Beitrag

Ihr Kommentar

Bitte loggen Sie sich zum Kommentieren ein beziehungsweise registrieren Sie sich so als willkommener neuer Nutzer des Blogs.

Copyright   ©   2013   Albrecht Weinert,       E-Mail (webmaster)
Feed on RSS: Post Feed RSS   Beitrags-Feed,   Comments Feed RSS   Kommentar-Feed