I think it is okay, but it *is* a change from 1.6. In a working copy
with two copies of a given repos_relpath, one could be annotated as
"locked" and the other not. Then, running "svn status -u" would give
two different status values for these local nodes (one locked, one
"locked by somebody else"). In 1.7, both will be reported the same.
That seems totally fine to me, but is a difference. And I think the
model (as you comment in this patch) is the correct model: we cache
what we know and report on that. I don't think we need to strongly
associate repos-lock information with paths like 1.6 would do.
Cheers,
-g
On Wed, Mar 9, 2011 at 12:50, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Bert & Greg - OK?
>
> Index: subversion/libsvn_wc/wc-metadata.sql
> ===================================================================
> --- subversion/libsvn_wc/wc-metadata.sql (revision 1079778)
> +++ subversion/libsvn_wc/wc-metadata.sql (working copy)
> @@ -184,15 +184,11 @@
>
> /* ------------------------------------------------------------------------- */
>
> +/* This table is a cache of information about repository locks. */
> CREATE TABLE LOCK (
> /* what repository location is locked */
> repos_id INTEGER NOT NULL REFERENCES REPOSITORY (id),
> repos_relpath TEXT NOT NULL,
> - /* ### BH: Shouldn't this refer to an working copy location? You can have a
> - single relpath checked out multiple times in one (switch) or more
> - working copies. */
> - /* ### HKW: No, afaik. This table is just a cache of what's in the
> - repository, so these should be repos_relpaths. */
>
> /* Information about the lock. Note: these values are just caches from
> the server, and are not authoritative. */
>
>
> - Julian
>
>
>
Received on 2011-03-10 03:45:41 CET