There was a requirements discussion a little while ago.
http://svn.haxx.se/users/archive-2005-11/1101.shtml
More comments below....
> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: 16 September 2006 14:03
> To: SVN Dev; Ph. Marek
> Subject: [PROPOSAL] Versioning mtime
>
> 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.
>
Seems to hit the nail on the head.
>
> 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.
>
Default to store the information because new subversion users will not
consider that this sort of information is not stored and by the time
that they come to look for it is will almost definitely be too late.
>
> * 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).
Another config option for this would be preferable, doesn't matter which
way it defaults, but my personal preference (from more of a windows
background) is that Copy and Move DO NOT change the modified date time
as the file contents has not changed (That is what the file creation
timestamp is for!)
>
> 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
>
>
> ______________________________________________________________________
> CAUTION: This message was sent via the Public Internet and
> its authenticity cannot be guaranteed.
>
> ______________________________________________________
>
******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 3 15:49:30 2006