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

RE: svn commit: r1431633 - in /subversion/trunk/subversion: libsvn_wc/cleanup.c libsvn_wc/wc_db.c libsvn_wc/wc_db.h tests/cmdline/wc_tests.py

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 11 Jan 2013 14:12:26 +0100

> -----Original Message-----
> From: brane_at_apache.org [mailto:brane_at_apache.org]
> Sent: donderdag 10 januari 2013 21:55
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1431633 - in /subversion/trunk/subversion:
> libsvn_wc/cleanup.c libsvn_wc/wc_db.c libsvn_wc/wc_db.h
> tests/cmdline/wc_tests.py
>
> Author: brane
> Date: Thu Jan 10 20:54:40 2013
> New Revision: 1431633
>
> URL: http://svn.apache.org/viewvc?rev=1431633&view=rev
> Log:
> Fix issue #4267 (better message when cleanup not run on lock root); but
> instead
> of concocting a better error message, just always run cleanup on the lock
> root.

During WC-NG development we explicitly decided not to do this, because some users run operations on different parts of their working copy at once.

$ svn up wc/branches/subdir
$ svn up wc/tags/subdir

These can run simultaneously.

This was an explicitly supported scenario in 1.6 and earlier.

If one of these commands would break down, you would call 'svn cleanup' on just that target. For 1.7 this still removes the working copy lock and runs the workqueue.

For WC-NG there are certain operations you can't do without a full working copy lock: e.g. cleaning pristines while somebody else has a lock (or when there are wq items)

Your change made it much easier to perform these very dangerous operations, breaking the lock of the second process, while the normal cleanup probably already worked.
(Any process is allowed to run the workqueue at any time)

        Bert
Received on 2013-01-11 14:13:04 CET

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.