Erik Huelsmann wrote:
> 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.
Thanks, Erik. This is very useful. Could you add some details:
What are the semantics of the MTIME_RECORD property's life time - under what
conditions does it get created/updated/deleted? For example, you implied it
gets created at commit time rather than earlier, so is there any way for the
user to remove it? If it exists but, at the time of a commit, the
configuration says it shouldn't exist on that item, what happens?
What sort of configuration do you envisage for controlling which items have
their mtime stored (and when) and which have their stored mtime used (and
when)? I think a per-user setting that applies across all the user's versioned
items is insufficiently fine-grained, but at least that would be a starting
point for discussion.
Can you demonstrate this proposal in a couple of use cases? A simple one could
go something like this:
"Joe keeps some notes "doc/*.txt" in his personal Subversion repository and
relies on the mtime to know when he last edited them. He edits "doc/a.txt" on
1st May, commits on 2nd, edits on 3rd, commits on 4th. After these actions:
(a) "svn up -r{2nd May}; svn up"; (b) "rm a.txt; svn up"; (c) [...], the actual
results he sees are [...] which, as we can see, are what he expects."
> 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.
To expand this into a concise but accurate statement of what the proposal
achieves in its entirety, you need also to mention transferring the recorded
mtime back on to items on disk.
>
>
> * 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.
I don't really understand what you're saying. Could you clarify the
differences between the type of proposal this isn't and what it is?
>
>
> 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).
This needs more detail. As Ph. Ma. pointed out, unix "mv" does preserve the
time by default. It is probably worth explicitly considering the various
combinations of WC/repos to/from WC/repos. Is Subversion expected to remove
this property in some cases?
> 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.
I would expect "export" and "revert" to set the mtime from the property.
Hope this helps.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 26 23:32:41 2006