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

Re: svn commit: rev 7565 - in trunk/subversion: include libsvn_wc tests/clients/cmdline

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-10-30 03:18:35 CET

philip@tigris.org writes:

> Author: philip
> Date: Wed Oct 29 19:38:13 2003
> New Revision: 7565

> Log:
> Add a mechanism that "repairs" the text-time and prop-time in the
> entries file if they differ from the time of the working copy files
> even though there are no text/property differences. This addresses
> issue 791.

A "broken" text-time can be obtained by editing a file, saving it,
then undoing the edit in the editor and saving it again. A "broken"
prop-time can be obtained by using "svn propset" twice, first to
modify a property and again to restore the original value. In the
past we had bugs that caused broken timestamps during updates. If you
have a working copy with lots of "broken" timestamps then operations
that use them, like "svn status", will take longer than necessary.

The new "repair" code runs automatically whenever Subversion checks
for changes while holding a write lock. Ideally one would be able to
trigger the repair of an entire working copy, at present I know of two
ways to ways to do it:

 1) run "svn revert --recursive"
 2) run "svn commit"

Neither of these is ideal. Using 1) has the obvious disadvantage that
it destroys any local modifications. Using 2) doesn't require one to
complete the commit, quitting the log message editor without saving
and aborting the commit will do the job, but it's hardly the interface
one would choose.

Do we need a more intuitive interface this repair? There are a number
of things we could do: 1) add a new option to "svn status" to cause it
to take a write lock, 2) make "svn cleanup" run the check for changes
on every entry, 3) add a new "svn repair" command, etc. I'm not
overly keen on any of those, "svn cleanup" is the one I dislike least,
so I'd choose to leave things as they are. Thoughts?

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 03:19:17 2003

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.