"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
disappointed.
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
MTIME_RECORD?
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