Querying a couple of your points please.
On 30/08/2007, Ryan Schmidt <email@example.com> wrote:
> >> 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 was:
Thanks. Karl makes a good point about the other operations
which would need the date time retaining.
1) Preserving file timestamps on import and add, so when
the file is checked out again, the working file gets the
same timestamp as when it was imported/added.
2) Setting working file timestamps according to last commit
I support this as a part of the feature request.
> > 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.
So it wouldn't mess with subversion to find mtimes which were earlier?
So perhaps a simple solution would be:
Obtain a full list of mtimes for the directory going into the repo.
import into repo
checkout data back into directory.
using data obtained, touch the newly loaded directory.
Thereafter, after the next commit, would the mtimes be correct?
I guess the only real case is that of losing the data,
then updating from the repo? Would the mtimes be correct in this case?
> 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
Thanks for the pointers.
XSLT XSL-FO FAQ.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Aug 30 09:24:37 2007