On Saturday 16 September 2006 15:03, 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.
>
> All requests had the common denominator that recording of the mtime
> property was required. So here it goes:
Thank you for resurrecting this thing.
> 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.
True.
> 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.
True, but to keep consistent with existing repositories (yes, there are some)
I'd suggest keeping the already defined names.
> 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.
-1 on that. That's the same discussion as before, when it was proposed
that "the property can be set by simple wrappers before commit".
If the property is understood on commit, use it on update, thank you so much.
> 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.
Ok.
> Checkout, Update, Switch
> Any changes to the MTIME_RECORD will be integrated into the working copy.
Ok. See, you use the data on update yourself!
> Add
> Add won't set the MTIME_RECORD property; commit will add it when the
> file is committed.
Ok.
> Copy, Move
> Copy and Move won't preserve the MTIME_RECORD propetry unless
> explicitly instructed otherwise (just like *nix cp).
-1 on that. "mv" keeps timestamps.
And because it's stored as a property, it would have to be hard-coded to get
deleted on copy. Please, keep it. I remember no usage of "cp" or "rsync"
without "-a"!
> 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.
So you keep the property across copies? That's not what I understood in the
last paragraph.
Or are you making a distinction between wc and remote copies?
> Merge
> This command will actively ignore any changes to the MTIME_RECORD property.
-0, I'd suggest taking the newer of the two, to have no timestamps going back
on update.
> Export, Resolved, Revert, Switch --relocate, Cleanup, Lock, Unlock, Diff,
> Log These commands are not affected.
Ok.
> Storage
> =====
>
> The MTIME_RECORD property will be stored in the same format as the
> svn:date format.
Ok.
> 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.
Ok :-)
Erik, thank you very much for trying to get that back to life.
I hope my sparse comments are enough for this time; if there are any
questions, please don't hesitate to ask.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 25 07:31:46 2006