On Aug 29, 2007, at 09:44, Dave Pawson wrote:
> On 29/08/2007, Greg Rundlett wrote:
>
>>>>> There was a set of patches (not part of the official project)
>>>>> that
>>>>> adds what you're asking for, but I don't know if it's kept pace
>>>>> with
>>>>> Subversion itself.
>
>> I totally agree with you that the mtime feature is needed in
>> Subversion.
>> Hopefully the issue doesn't get sidetracked yet again. I've got
>> my fingers
>> crossed that issue 1256 gets attention.
>
> Any url please?
The URL to the issue was posted between those two quoted sections
above, and must've gotten snipped somewhere. The URL was:
http://subversion.tigris.org/issues/show_bug.cgi?id=1256
>> The hack we've implemented as a work-around is to set a file
>> property called
>> mtime on each of the imported files. (At the time when you do an
>> initial
>> import, you presumably have a copy of the original files with their
>> historical modification times, outside of subversion.)
[snip]
>> run a script that 'touches' the local working copy to use 'mtime'.
[snip]
>> Now you
>> have a local working copy of files that are version-controlled and
>> reside on
>> the local file system displaying timestamps that reflect their
>> 'mtime'
>> property. You could combine this with a post_commit hook so that
>> mtime (the
>> property) gets updated on any subsequent file modification.
I don't see any way that you could accomplish this using a post-
commit hook (or any other hook). The hooks run on the server, but the
files with their original mtimes are on the client. By the time the
files get to the server, they've already lost their original mtimes.
So, just like you have to run a script on the client after checking
out or updating (the script that's below) to fix the mtimes so they
match the properties, you'd have to do the same for committing: you'd
have to run a different script before each commit which would set the
custom mtime property of each file. Then you could commit.
> I've not used any hooks.
> I guess the mess is that the mtime of the file is now n days prior
> to the time of revision 1?
> Starts to get a bit messy now :-)
I don't think there's any particular problem with that, since the
mtimes of the files are just stored in custom file properties about
which Subversion knows nothing.
>> #!/bin/bash
>> pushd /home/user/work/project-working-directory
>> for FILE in `find . -mindepth 1|grep -v '.svn'`
>> do
>> echo Setting custom mtime on $FILE
>> svn proplist "$FILE"|grep 'svn:mtime' >/dev/null
>> if [ "$?" -eq 0 ]
>> then
>> MTIME=`svn propget svn:mtime "$FILE"`
>> touch -d "$MTIME" "$FILE"
>> fi
>> done
>> popd >/dev/null
>
> Sorry to sound so ignorant Greg, is this post commit hook?
No, a post-commit hook (and all other hooks) would run on the server;
this looks like a script that you would run on your working copy
after checking it out or updating it, so that the mtimes get set
correctly as recorded in the properties.
If you'd like to know more about hooks you can read up on them in the
book
http://svnbook.red-bean.com/en/1.4/
svn.reposadmin.create.html#svn.reposadmin.create.hooks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 30 02:53:24 2007