[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Versioning mtime

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2006-09-28 00:35:37 CEST

"Erik Huelsmann" <ehuels@gmail.com> writes:

> 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.

I know it's really a separate issue, but this is yet another feature
that really needs to be enabled per-wc, or per-URL, not per-config.
We will probably get requests for it to be per-file as well.

> 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.

How are files with local mods handled during switch/update? Does it
make a difference if the 3-way merge effectively causes the local mods
to disappear? Or causes a conflict?

What happens if the user provokes an MTIME_RECORD property conflict?

> 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.

In past discussions I recall people assuming that mtime changes alone
would show up in status and cause a commit. Doing it the way you
propose is certainly simpler as it avoids all the questions about
timestamp resolution, status, etc., but I assume some users will be

What happens if the only local mod is an MTIME_RECORD property mod?
Is that a way of getting an mtime change committed?

> * Tree changes through Add (without history)
> In this case, commit will behave as Import.

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?

> * 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.

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?

> Export, Resolved, Revert, Switch --relocate, Cleanup, Lock, Unlock, Diff, Log
> These commands are not affected.

Export currently sets mtime to commit time, why would it not use the

Why would revert not reset the mtime?

Lock/unlock will sometimes do mv/cp/rm in order to change permissions,
should they also set the mtime when doing that?

> I'd like some comments to this proposal. Later, if this proposal is

Overall it looks like you are proposing a "fragile" mtime in the
working copy, it is easy to "break" the mtime and there is little that
can be done to restore the versioned mtime short of an rm/up sequence.
That's merely an observation, I'm not claiming your proposed behaviour
is wrong.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 28 00:35:54 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.