On Wed, 2011-03-09, Greg Stein wrote:
> 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.
Thanks. Glad I asked. r1080172.
- Julian
> 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. */
Received on 2011-03-10 11:25:18 CET