Judging from some of your reactions, the title of the proposal
probably should have been 'Recording mtime'.
Below I have collected your responses with my comments.
On 9/16/06, Erik Huelsmann <ehuels@gmail.com> 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:
>
> 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.
Graeme Thompson comments:
"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."
Yes, that's true. OTOH, with 1.4 working copies have been made a lot
more efficient (inode-wise) by eliminating a lot of property files. If
Subversion were to record mtimes by default, all those property files
would re-appear, because the standard wouldn't be 'not to have
properties', but it would be 'to have properties'.
> * 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.
Philip Marek comments:
"-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."
Well, not entirely. The discussion last time was that the svn client
doesn't need this, but that all of it can be arranged in a wrapper
script. But that would mean the wrapper script needs to implement all
of 'svn import' (because that doesn't have a working copy to
manipulate), which is exactly one of the many ways used to populate a
new repository with an old project. So, the discussion is now (IMO):
svn should do the recording - which is what all requests were about -
but actual use of the recorded information is really very different
per usecase. The last bit means that without a whole slew of new
options, svn can't satisfy that part of the problem (until decided
otherwise).
Julian Foad comments:
"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."
and:
"Could you clarify the differences between the type of proposal this
isn't and what it is?"
Actually, I expressly didn't add the mtime-using part in this
proposal, because the use-cases are so widely varying: This proposal
is *not* about transferring the mtimes received from the repository
back onto the nodes in the working copy.
I hope the updating/creation/deletion part is sufficiently addressed
in the extended proposal (see below).
> 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 stored the
> MTIME_RECORD property value in the working copy.
> Add
> Add won't set the MTIME_RECORD property; commit will add or update it
> when the file is committed.
Philip Martin comments:
"What happens when something like svn:eol-style causes a file to get
rewritten after a commit completes? Does the mtime get set back even
though the content may have changed?"
No, the mtime doesn't get set back, ever. So, that problem should not occur.
> Copy, Move
> Copy and Move won't preserve the MTIME_RECORD property unless
> explicitly instructed otherwise (just like *nix cp).
Both Julian Foad and Philip Marek point out that copy and move aren't
so similar, so, I decided to split this one up in Copy and Move.
Copy
Copy does not maintain the old value of the MTIME_RECORD: as soon as
the copy is committed (or it is a wc->repos copy), a new value (the
time of the copy) is stored in the MTIME_RECORD.
Move
Move will preserve the old value of the MTIME_RECORD: when a moved
item is committed, the value found in the working copy is used instead
of overwritten with the one found on the node in the working copy
itself.
> 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.
Philip Martin comments:
"Even if the merge effectively causes local mods to disappear?
$ svn merge -cN
$ svn merge -c-N
What about a the merge only affects the MTIME_RECORD property -- should
such a merge update the mtime, update the property and so make the
item committable?"
Given that I'm working out a proposal for recording (but not setting)
of mtimes, I think it should even work that way if the local mods
disappear, yes. Because, in your comment, it looks to me like you
think the mtime should be a 'maintained' value: just like we do with
'use-commit-times'.
> 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.
>
Julian Foad comments:
"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?"
You're completely right. I totally forgot to work out the deletion part :-)
Below, I extend the proposal to include creation and deletion of the
MTIME_RECORD property. Updating has been described - I hope - in the
paragraphs above.
Creation/Updating* of the MTIME_RECORD property on a node
===================================
The client will add an MTIME_RECORD to all nodes in the current
commit, when the command line option --record-mtime is specified.
Next to that, the client will update the MTIME_RECORD on all nodes in
the current commit which already have a MTIME_RECORD property set,
even without the aforementioned --record-mtime option.
The client will also start maintaining the MTIME_RECORD when such a
property has been added on a single node with the appropriate command
(ie 'svn propset MTIME_RECORD '*' <node_path>').
* Updating in the context of this paragraph means sending a new value
into the repository.
Deletion of the MTIME_RECORD property on a node
==============================
If the MTIME_RECORD property has been deleted from a node (for example
using svn propdel MTIME_RECORD <node_path>), the client will stop
maintaining the MTIME_RECORD for that node.
If the MTIME_RECORD property has been deleted from a node, but in the
commit the --record-mtime option *is* specified, the latter wins: the
client will re-add the MTIME_RECORD.
Philip Martin comments:
"What happens if the user provokes an MTIME_RECORD property conflict?"
Hmm. I hadn't thought about that one. Since the proposal actually only
is about recording mtimes, the actual value in a working copy with
lots of mods may not be as important as the value in a clean and new
working copy. Conflicts are not really relevant to this property:
anybody who changes the property will cause a commit which overwrites
the value with the latest found in the working copy. Thereby, I think
we should ignore conflicts and pick the working copy value as the
'right' one.
Philip Martin comments even more:
"What happens if the only local mod is an MTIME_RECORD property mod?
Is that a way of getting an mtime change committed?"
Yes, it would be the way to get an mtime change committed without any
other changes being present.
Sorry for the late reaction, but I was busy having a cold last week.
I hope that clarifies most of it.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 9 00:04:09 2006