Errors with mtime-retaining import script: pre-revprop-change issue?
Hello, I'm using the svn import script by Oliver Betz to retain file mtime upon initial import (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but i'm getting some errors. I'm hoping someone might be able to help me out. when i run the script, i get the following error: $ perl importWithMtime.pl svn propset svn:date 2001-10-29T18:34:10.00Z --revprop -r HEAD svn: E175002: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent svn: E175008: At least one property change failed; repository is unchanged svn: E175002: Error setting property 'date': Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook I do have a pre-revprop-change.tmpl hook in the repository. It contains the code below. I'm using VisualSVN 2.5.2 on a Windows 7 x64 machine with Cygwin Perl and TortoiseSVN. Any help would be greatly appreciated! Thanks, Alex --- $ cat pre-revprop-change.tmpl #!/bin/sh # PRE-REVPROP-CHANGE HOOK # # The pre-revprop-change hook is invoked before a revision property # is added, modified or deleted. Subversion runs this hook by invoking # a program (script, executable, binary, etc.) named 'pre-revprop-change' # (for which this file is a template), with the following ordered # arguments: # # [1] REPOS-PATH (the path to this repository) # [2] REV (the revision being tweaked) # [3] USER (the username of the person tweaking the property) # [4] PROPNAME (the property being set on the revision) # [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted) # # [STDIN] PROPVAL ** the new property value is passed via STDIN. # # If the hook program exits with success, the propchange happens; but # if it exits with failure (non-zero), the propchange doesn't happen. # The hook program can use the 'svnlook' utility to examine the # existing value of the revision property. # # WARNING: unlike other hooks, this hook MUST exist for revision # properties to be changed. If the hook does not exist, Subversion # will behave as if the hook were present, but failed. The reason # for this is that revision properties are UNVERSIONED, meaning that # a successful propchange is destructive; the old value is gone # forever. We recommend the hook back up the old value somewhere. # # On a Unix system, the normal procedure is to have 'pre-revprop-change' # invoke other programs to do the real work, though it may do the # work itself too. # # Note that 'pre-revprop-change' must be executable by the user(s) who will # invoke it (typically the user httpd runs as), and that user must # have filesystem-level permission to access the repository. # # On a Windows system, you should name the hook program # 'pre-revprop-change.bat' or 'pre-revprop-change.exe', # but the basic idea is the same. # # The hook program typically does not inherit the environment of # its parent process. For example, a common problem is for the # PATH environment variable to not be set to its usual value, so # that subprograms fail to launch unless invoked via absolute path. # If you're having unexpected problems with a hook program, the # culprit may be unusual (or missing) environment variables. # # Here is an example hook script, for a Unix /bin/sh interpreter. # For more examples and pre-written hooks, see those in # the Subversion repository at # http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and # http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ REPOS="$1" REV="$2" USER="$3" PROPNAME="$4" ACTION="$5" if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi echo "Changing revision properties other than svn:log is prohibited" >&2 exit 1
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
Am 25.01.2012 16:09, schrieb Alexander Shenkin: I do have a pre-revprop-change.tmpl hook in the repository. It contains the code below.[...] This file is just a template, and the error message says what the problem is: There is no hook script to allow editing revision properties, and the default is that it is verboten. If it's just for some initial import, you just need a simple script that does nothing, but otherwise it is typically a bad idea to allow any change to revision properties. You need to make that decision, take a look at the documentation in order to make it an informed decision. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
Guten Tag Alexander Shenkin, am Mittwoch, 25. Januar 2012 um 16:09 schrieben Sie: > I do have a pre-revprop-change.tmpl hook in the repository. That's a template, you have to adjust it to work on windows and save it as something usable, for example as .cmd file. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Errors with mtime-retaining import script: pre-revprop-change issue?
Alex, the '.tmpl' scripts in the hooks directory are there for reference purposes only. If you want the script to be executed, it needs to be named 'pre-revprop-change' with no extension, and have execute permission. Tony. From: Alexander Shenkin [mailto:subvers...@shenkin.org] Sent: 25 January 2012 15:10 To: users@subversion.apache.org Subject: Errors with mtime-retaining import script: pre-revprop-change issue? Hello, I'm using the svn import script by Oliver Betz to retain file mtime upon initial import (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but i'm getting some errors. I'm hoping someone might be able to help me out. when i run the script, i get the following error: $ perl importWithMtime.pl svn propset svn:date 2001-10-29T18:34:10.00Z --revprop -r HEAD svn: E175002: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent svn: E175008: At least one property change failed; repository is unchanged svn: E175002: Error setting property 'date': Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook I do have a pre-revprop-change.tmpl hook in the repository. It contains the code below. I'm using VisualSVN 2.5.2 on a Windows 7 x64 machine with Cygwin Perl and TortoiseSVN. Any help would be greatly appreciated! Thanks, Alex --- $ cat pre-revprop-change.tmpl #!/bin/sh # PRE-REVPROP-CHANGE HOOK # # The pre-revprop-change hook is invoked before a revision property # is added, modified or deleted. Subversion runs this hook by invoking # a program (script, executable, binary, etc.) named 'pre-revprop-change' # (for which this file is a template), with the following ordered # arguments: # # [1] REPOS-PATH (the path to this repository) # [2] REV (the revision being tweaked) # [3] USER (the username of the person tweaking the property) # [4] PROPNAME (the property being set on the revision) # [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted) # # [STDIN] PROPVAL ** the new property value is passed via STDIN. # # If the hook program exits with success, the propchange happens; but # if it exits with failure (non-zero), the propchange doesn't happen. # The hook program can use the 'svnlook' utility to examine the # existing value of the revision property. # # WARNING: unlike other hooks, this hook MUST exist for revision # properties to be changed. If the hook does not exist, Subversion # will behave as if the hook were present, but failed. The reason # for this is that revision properties are UNVERSIONED, meaning that # a successful propchange is destructive; the old value is gone # forever. We recommend the hook back up the old value somewhere. # # On a Unix system, the normal procedure is to have 'pre-revprop-change' # invoke other programs to do the real work, though it may do the # work itself too. # # Note that 'pre-revprop-change' must be executable by the user(s) who will # invoke it (typically the user httpd runs as), and that user must # have filesystem-level permission to access the repository. # # On a Windows system, you should name the hook program # 'pre-revprop-change.bat' or 'pre-revprop-change.exe', # but the basic idea is the same. # # The hook program typically does not inherit the environment of # its parent process. For example, a common problem is for the # PATH environment variable to not be set to its usual value, so # that subprograms fail to launch unless invoked via absolute path. # If you're having unexpected problems with a hook program, the # culprit may be unusual (or missing) environment variables. # # Here is an example hook script, for a Unix /bin/sh interpreter. # For more examples and pre-written hooks, see those in # the Subversion repository at # http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and # http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ REPOS="$1" REV="$2" USER="$3" PROPNAME="$4" ACTION="$5" if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi echo "Changing revision properties other than svn:log is prohibited" >&2 exit 1 __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2012.0.1901 / Virus Database: 2109/4764 - Release Date: 01/24/12 __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
On 25/01/12 15:09, Alexander Shenkin wrote: Hello, I'm using the svn import script by Oliver Betz to retain file mtime upon initial import (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but i'm getting some errors. I'm hoping someone might be able to help me out. when i run the script, i get the following error: $ perl importWithMtime.pl svn propset svn:date 2001-10-29T18:34:10.00Z --revprop -r HEAD svn: E175002: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent svn: E175008: At least one property change failed; repository is unchanged svn: E175002: Error setting property 'date': Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook I do have a pre-revprop-change.tmpl hook in the repository. It contains the code below. I'm using VisualSVN 2.5.2 on a Windows 7 x64 machine with Cygwin Perl and TortoiseSVN. Any help would be greatly appreciated! Thanks, Alex --- $ cat pre-revprop-change.tmpl #!/bin/sh # PRE-REVPROP-CHANGE HOOK # # The pre-revprop-change hook is invoked before a revision property # is added, modified or deleted. Subversion runs this hook by invoking # a program (script, executable, binary, etc.) named 'pre-revprop-change' # (for which this file is a template), with the following ordered # arguments: # # [1] REPOS-PATH (the path to this repository) # [2] REV (the revision being tweaked) # [3] USER (the username of the person tweaking the property) # [4] PROPNAME (the property being set on the revision) # [5] ACTION (the property is being 'A'dded, 'M'odified, or 'D'eleted) # # [STDIN] PROPVAL ** the new property value is passed via STDIN. # # If the hook program exits with success, the propchange happens; but # if it exits with failure (non-zero), the propchange doesn't happen. # The hook program can use the 'svnlook' utility to examine the # existing value of the revision property. # # WARNING: unlike other hooks, this hook MUST exist for revision # properties to be changed. If the hook does not exist, Subversion # will behave as if the hook were present, but failed. The reason # for this is that revision properties are UNVERSIONED, meaning that # a successful propchange is destructive; the old value is gone # forever. We recommend the hook back up the old value somewhere. # # On a Unix system, the normal procedure is to have 'pre-revprop-change' # invoke other programs to do the real work, though it may do the # work itself too. # # Note that 'pre-revprop-change' must be executable by the user(s) who will # invoke it (typically the user httpd runs as), and that user must # have filesystem-level permission to access the repository. # # On a Windows system, you should name the hook program # 'pre-revprop-change.bat' or 'pre-revprop-change.exe', # but the basic idea is the same. # # The hook program typically does not inherit the environment of # its parent process. For example, a common problem is for the # PATH environment variable to not be set to its usual value, so # that subprograms fail to launch unless invoked via absolute path. # If you're having unexpected problems with a hook program, the # culprit may be unusual (or missing) environment variables. # # Here is an example hook script, for a Unix /bin/sh interpreter. # For more examples and pre-written hooks, see those in # the Subversion repository at # http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and # http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ REPOS="$1" REV="$2" USER="$3" PROPNAME="$4" ACTION="$5" if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi echo "Changing revision properties other than svn:log is prohibited" >&2 exit 1 The hook has to be called pre-revprop-change on *nix systems and be executable or pre-revprop-change.bat on Windows. So, no .tmpl extension.
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
Thanks everyone for your replies. I ended up finding a solution for a windows-executable pre-revprop-change.bat script here: http://stackoverflow.com/questions/6155/common-types-of-subversion-hooks/68850#68850 now to lobby the dev team to add mtime-handling options in future versions! Unfortunately, I don't see it in the plans for version 1.8, even though it was "1.8-consider" in the tigris bug tracker... alex On 1/25/2012 11:00 AM, Giulio Troccoli wrote: > > > On 25/01/12 15:09, Alexander Shenkin wrote: >> Hello, >> >> I'm using the svn import script by Oliver Betz to retain file mtime >> upon initial import >> (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but i'm >> getting some errors. I'm hoping someone might be able to help me out. >> >> when i run the script, i get the following error: >> >> $ perl importWithMtime.pl >> svn propset svn:date 2001-10-29T18:34:10.00Z --revprop -r HEAD >> svn: E175002: DAV request failed; it's possible that the >> repository's pre-revprop-change hook either failed or is >> non-existent >> svn: E175008: At least one property change failed; repository is >> unchanged >> svn: E175002: Error setting property 'date': >> Repository has not been enabled to accept revision propchanges; >> ask the administrator to create a pre-revprop-change hook >> >> I do have a pre-revprop-change.tmpl hook in the repository. It >> contains the code below. I'm using VisualSVN 2.5.2 on a Windows 7 >> x64 machine with Cygwin Perl and TortoiseSVN. Any help would be >> greatly appreciated! >> >> Thanks, >> Alex >> >> >> --- >> >> $ cat pre-revprop-change.tmpl >> #!/bin/sh >> >> # PRE-REVPROP-CHANGE HOOK >> # >> # The pre-revprop-change hook is invoked before a revision property >> # is added, modified or deleted. Subversion runs this hook by invoking >> # a program (script, executable, binary, etc.) named >> 'pre-revprop-change' >> # (for which this file is a template), with the following ordered >> # arguments: >> # >> # [1] REPOS-PATH (the path to this repository) >> # [2] REV (the revision being tweaked) >> # [3] USER (the username of the person tweaking the property) >> # [4] PROPNAME (the property being set on the revision) >> # [5] ACTION (the property is being 'A'dded, 'M'odified, or >> 'D'eleted) >> # >> # [STDIN] PROPVAL ** the new property value is passed via STDIN. >> # >> # If the hook program exits with success, the propchange happens; but >> # if it exits with failure (non-zero), the propchange doesn't happen. >> # The hook program can use the 'svnlook' utility to examine the >> # existing value of the revision property. >> # >> # WARNING: unlike other hooks, this hook MUST exist for revision >> # properties to be changed. If the hook does not exist, Subversion >> # will behave as if the hook were present, but failed. The reason >> # for this is that revision properties are UNVERSIONED, meaning that >> # a successful propchange is destructive; the old value is gone >> # forever. We recommend the hook back up the old value somewhere. >> # >> # On a Unix system, the normal procedure is to have 'pre-revprop-change' >> # invoke other programs to do the real work, though it may do the >> # work itself too. >> # >> # Note that 'pre-revprop-change' must be executable by the user(s) >> who will >> # invoke it (typically the user httpd runs as), and that user must >> # have filesystem-level permission to access the repository. >> # >> # On a Windows system, you should name the hook program >> # 'pre-revprop-change.bat' or 'pre-revprop-change.exe', >> # but the basic idea is the same. >> # >> # The hook program typically does not inherit the environment of >> # its parent process. For example, a common problem is for the >> # PATH environment variable to not be set to its usual value, so >> # that subprograms fail to launch unless invoked via absolute path. >> # If you're having unexpected problems with a hook program, the >> # culprit may be unusual (or missing) environment variables. >> # >> # Here is an example hook script, for a Unix /bin/sh interpreter. >> # For more examples and pre-written hooks, see those in >> # the Subversion repository at >> # >> http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/ and >> # http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ >> >> >> REPOS="$1" >> REV="$2" >> USER="$3" >> PROPNAME="$4" >> ACTION="$5" >> >> if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi >> >> echo "Changing revision properties other than svn:log is prohibited" >&2 >> exit 1 > > > The hook has to be called pre-revprop-change on *nix systems and be > executable or pre-revprop-change.bat on Windows. So, no .tmpl extension.
RE: Errors with mtime-retaining import script: pre-revprop-change issue?
> -Original Message- > From: Alexander Shenkin [mailto:subvers...@shenkin.org] > Sent: 25 January 2012 15:10 > To: users@subversion.apache.org > Subject: Errors with mtime-retaining import script: > pre-revprop-change issue? > > Hello, > > I'm using the svn import script by Oliver Betz to retain file > mtime upon initial import > (http://svn.haxx.se/users/archive-2006-10/1345.shtml), but > i'm getting some errors. I'm hoping someone might be able to > help me out. > > when i run the script, i get the following error: > > > $ perl importWithMtime.pl > svn propset svn:date 2001-10-29T18:34:10.00Z > --revprop -r HEAD > svn: E175002: DAV request failed; it's possible that > the repository's pre-revprop-change hook either failed or is > non-existent > svn: E175008: At least one property change failed; > repository is unchanged > svn: E175002: Error setting property 'date': > Repository has not been enabled to accept revision propchanges; > ask the administrator to create a pre-revprop-change hook > > > I do have a pre-revprop-change.tmpl hook in the repository. I believe that you need to remove the `.tmpl' ~ those templates are not executed, they are there to give you something to start from... ~ mark c > It contains the code below. I'm using VisualSVN 2.5.2 on a > Windows 7 x64 machine with Cygwin Perl and TortoiseSVN. Any > help would be greatly appreciated! > > Thanks, > Alex > > > --- > > $ cat pre-revprop-change.tmpl > #!/bin/sh > > # PRE-REVPROP-CHANGE HOOK > # > # The pre-revprop-change hook is invoked before a revision property > # is added, modified or deleted. Subversion runs this hook > by invoking > # a program (script, executable, binary, etc.) named > 'pre-revprop-change' > # (for which this file is a template), with the following ordered > # arguments: > # > # [1] REPOS-PATH (the path to this repository) > # [2] REV (the revision being tweaked) > # [3] USER (the username of the person tweaking the > property) > # [4] PROPNAME (the property being set on the revision) > # [5] ACTION (the property is being 'A'dded, > 'M'odified, or 'D'eleted) > # > # [STDIN] PROPVAL ** the new property value is passed via STDIN. > # > # If the hook program exits with success, the propchange happens; but > # if it exits with failure (non-zero), the propchange doesn't happen. > # The hook program can use the 'svnlook' utility to examine the > # existing value of the revision property. > # > # WARNING: unlike other hooks, this hook MUST exist for revision > # properties to be changed. If the hook does not exist, Subversion > # will behave as if the hook were present, but failed. The reason > # for this is that revision properties are UNVERSIONED, meaning that > # a successful propchange is destructive; the old value is gone > # forever. We recommend the hook back up the old value somewhere. > # > # On a Unix system, the normal procedure is to have > 'pre-revprop-change' > # invoke other programs to do the real work, though it may do the > # work itself too. > # > # Note that 'pre-revprop-change' must be executable by the > user(s) who will > # invoke it (typically the user httpd runs as), and that user must > # have filesystem-level permission to access the repository. > # > # On a Windows system, you should name the hook program > # 'pre-revprop-change.bat' or 'pre-revprop-change.exe', > # but the basic idea is the same. > # > # The hook program typically does not inherit the environment of > # its parent process. For example, a common problem is for the > # PATH environment variable to not be set to its usual value, so > # that subprograms fail to launch unless invoked via absolute path. > # If you're having unexpected problems with a hook program, the > # culprit may be unusual (or missing) environment variables. > # > # Here is an example hook script, for a Unix /bin/sh interpreter. > # For more examples and pre-written hooks, see those in > # the Subversion repository at > # > http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-sc > ripts/ and > # > http://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/ > > > REPOS="$1" > REV="$2" > USER="$3" > PROPNAME="$4" > ACTION="$5" > > if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; > then exit 0; fi > > echo "Changing revision properties other than svn:log is > prohibited" >&2 > exit 1 >
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
Hello again, So, I've left my computer running the script below all day long. My understanding is that it imports files one at a time, in chronological order, setting the svn:date revision property each time to the timestamp of the file. Thus, in my case, I end up with thousands of revisions (corresponding to my thousands of files), with a different svn:date revprop value for each revision. What I *thought* this was supposed to accomplish was that, if you were to checkout a new working version of the repository (and if you had TortoiseSVN "set file dates to the 'last commit time'", or perhaps ran svn checkout -r COMMITTED), your files would have their original last-modified dates (aka timestamps, aka mtimes). However, when I delete a file and do an svn update, the replaced file has the timestamp of the HEAD revision in the repository. That is, the most recent file imported. It does *not* have the timestamp of the original file. I hope this makes sense. I'm moving over from CVS, so perhaps I'm still stuck thinking about files instead of revisions, and perhaps that's messing me up. This script sets the svn:date revprop of the HEAD revision just prior to committing each file. Should that theoretically work to set the commit time of each file, or did something change in subversion between 2006 and now that would have made such logic not operate as expected? I can go into the repository and get the dates for each revision, and they are as expected. It's just that I would have to specifically check out each file at it's corresponding revision (i.e. not the HEAD revision) in order to get its timestamp set properly. Apologies if this is convoluted. Any help is *greatly* appreciated! Thanks again, Alex the script from http://svn.haxx.se/users/archive-2006-10/1345.shtml : #!/usr/bin/perl # import files to subversion one by one and adjust commit date to file's mtime # this method is rather slow! # directory timestamps are set to the mtime of the oldest file # 2005-07-15 Oliver Betz # instructions: # create an empty repository, make sure to have a "pre-revprop-change" hook # check out a working copy from the empty repository # copy the whole tree of files to the working copy # run this script from the WC root # caution: # - stat() fails on filenames with foreign characters. # maybe conflicting translations from svn and perl? # - (stat())->mtime reports wrong data using ActivePerl with NTFS. Cygwin works. use strict; use File::stat; # by-name access to mtime use File::Find; my $rev; # revision of committed file my $svnstat; # response of "svn stat" my %files; my $filename; # path to current file my $mtime; # mtime of current file $ENV{Lang}="C"; # else we might get localized responses find({wanted => \&getfile, no_chdir => 1}, '.'); # all files and directories in the tree $mtime = svntime((sort(values(%files)))[0]), "\n"; # oldest file print "svn propset svn:date $mtime --revprop -r HEAD\n"; print `svn propset svn:date $mtime --revprop -r HEAD\n`; # first add all directories, they receive the time of the oldest file foreach $filename (sort keys(%files)){ next unless (-d $filename); print "svn add -N \"$filename\"\n"; print `svn add -N "$filename"`; # put the file under svn control, print response } foreach $filename (sort { $files{$a} <=> $files{$b} } keys(%files)) { next if (-d $filename); # directories have already been added $svnstat = `svn stat "$filename"`; next unless $svnstat =~ m/^\?.\s+(\S.*)$/; # skip if ignored or already under version control print `svn add -N "$filename"`; # put the file under svn control $rev=`svn ci -m "mtime keeping add of $filename"`; # commit the file immediately print "$rev"; # show complete response (several lines) die "wrong response $rev" unless $rev =~ /Committed revision (\d+)\./; # this is rather restrictive - 'next' might be a good alternative $rev = $1; # numerical value -> $rev $mtime = svntime($files{$filename}); # special format of svn time: 2005-07-11T09:17:35.00Z print `svn propset svn:date $mtime --revprop -r $rev`; } print "ready\n"; # add file dates and file/dir types to hash sub getfile { return if $File::Find::name eq "."; # don't add "." return if $File::Find::name =~ m{/.svn}; # don't add svn directories $files{$File::Find::name} = (stat($File::Find::name))->mtime; # add file to hash } sub svntime { my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(@_[0]); return sprintf "%4d-%02d-%02dT%02d:%02d:%02d.00Z",1900+$year,$mon+1,$mday,$hour,$min,$sec; } __END__ On 1/25/2012 11:15 AM, Alexander Shenkin wrote: > Thanks everyone for your replies. I ended up finding a solution for a > windows-executable pre-revprop-change.bat script here: > > http://stackoverflow.com/questions/6155/common-types-of-subversion-hooks/68850#68850 > > now to lobby the dev team to add mtime-handling options in future > versions! Unfortunately, I don't see it in the plans for version 1.8, > e
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
On Jan 25, 2012, at 14:07, Alexander Shenkin wrote: > What I *thought* this was supposed to accomplish was that, if you were > to checkout a new working version of the repository (and if you had > TortoiseSVN "set file dates to the 'last commit time'", or perhaps ran > svn checkout -r COMMITTED), your files would have their original > last-modified dates (aka timestamps, aka mtimes). However, when I > delete a file and do an svn update, the replaced file has the timestamp > of the HEAD revision in the repository. That is, the most recent file > imported. It does *not* have the timestamp of the original file. Off the top of my head I can't think of a reason why this wouldn't be working correctly.
Re: Errors with mtime-retaining import script: pre-revprop-change issue?
Thanks for your reply, Ryan. I just ran some new tests: when I check out a new working copy (just a small subdirectory of the repo in this case), I get the right timestamps. And, when I delete a file in that newly-checked-out directory and do an svn update, I also get the right timestamp. However, the behavior is different in the original directory tree that I imported. That is, deleting a file and updating gives the updated file the (wrong) timestamp of the HEAD revision. Perhaps I should just check out a new working copy. Still, I'm perplexed. On 1/25/2012 3:30 PM, Ryan Schmidt wrote: > On Jan 25, 2012, at 14:07, Alexander Shenkin wrote: > >> What I *thought* this was supposed to accomplish was that, if you were >> to checkout a new working version of the repository (and if you had >> TortoiseSVN "set file dates to the 'last commit time'", or perhaps ran >> svn checkout -r COMMITTED), your files would have their original >> last-modified dates (aka timestamps, aka mtimes). However, when I >> delete a file and do an svn update, the replaced file has the timestamp >> of the HEAD revision in the repository. That is, the most recent file >> imported. It does *not* have the timestamp of the original file. > Off the top of my head I can't think of a reason why this wouldn't be working > correctly. > >