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

RE: Re: [PROPOSAL] Versioning mtime

From: Thompson, Graeme (AELE) <Graeme.Thompson_at_smiths-aerospace.com>
Date: 2006-10-03 17:34:20 CEST

> >
> > 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?
The one thing that seems to have been agreed upon is that the mtime is
fairly unreliable due to programs that change the mtime without changing
the contents (i.e. Subversion, cp, etc.), They also agree that they use
the mtime to quickly determine whether a file has changes - thus I would
agree with Erik that the mtime should be ignored when building a list of
changed files.

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

This case would cause an mtime update - as the contents of the file have
changed (Although is a lot of peoples eyes this is a BAD thing for a
version control system to do as you should always be able to get out
*EXACTLY* what was put in, but that is another topic entirly...)

> > * 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?
Simply take the earliest mtime.

The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 3 17:37:49 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.