I've seen regular requests for versioning 'mtime's in the users list,
so, given that we still have the metadata versioning branches living
in our tree, I thought I'd try to flesh out a proposal for versioning
this kind of metadata.
All requests had the common denominator that recording of the mtime
property was required. So here it goes:
The problem
=========
For various reasons people assign certain value to knowing the mtime
value of files. Most of them know it's not the most exact indication
of file modification you can get, but often times there are no other -
quick - alternatives. In many situations, a habit like this has grown
when shops come from a situation where there was complete lack of
version control (other than the copy/paste kind).
Subversion doesn't keep records of the mtime of a committed item at
the time of committing, breaking the relation with historical methods
of versioning.
The proposed solution
================
Recording of mtime values for all node types (when applicable - but
currently, we only have node types for which this is applicable) in a
MTIME_RECORD* property upon request in the ~/.subversion/config file.
* the real name of the property can be chosen later.
What this proposal isn't
=================
This is not a proposal to add yet another
set-the-file's-mtime-at-update option: simple wrappers can do that
based on the infrastructure laid out in this proposal. That
functionality may be an extention of this proposal, but it's not under
discussion now.
Behaviour of the client
================
Import
The import command sets the MTIME_RECORD property for all committed
items to the value found in the source directory at the time of
import.
Checkout, Update, Switch
Any changes to the MTIME_RECORD will be integrated into the working copy.
Add
Add won't set the MTIME_RECORD property; commit will add it when the
file is committed.
Copy, Move
Copy and Move won't preserve the MTIME_RECORD propetry unless
explicitly instructed otherwise (just like *nix cp).
Commit
* Items without tree structure changes
In this case, commit will bahave as Import, with the remark that merely a
changed mtime itself is no reason for a node to end up in the list
of committable items.
* Tree changes through Add (without history)
In this case, commit will behave as Import.
* Tree changes through Copy and Move (Add with history)
If an add-with-history item has an MTIME_RECORD property AND is
content as well as property wise unmodified, the MTIME_RECORD property
is unmodified and committed.
In all other cases, the MTIME_RECORD property is set to the value
found in the working copy.
Merge
This command will actively ignore any changes to the MTIME_RECORD property.
Export, Resolved, Revert, Switch --relocate, Cleanup, Lock, Unlock, Diff, Log
These commands are not affected.
Storage
=====
The MTIME_RECORD property will be stored in the same format as the
svn:date format.
So...
I'd like some comments to this proposal. Later, if this proposal is
agreed upon to be a good document to work from, I hope to get some
feedback on wether this is what is currently in the text-time branch.
Please don't put that in this thread.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 16 15:03:42 2006