RE: RE: RE: Communication of LOCKS and CHANGES

> -----Original Message-----
> From: Harvey, Edward [mailto:Edward.Harvey@patni.com]
>
> > From: Brian Erickson [mailto:erickson@BAUERCONTROLS.com]
> > 1) pcs42xx D:\junk>svn status
> > M trunk\test.txt
> >
> > 2) pcs42xx D:\junk>svn status -u
> > M * 63 trunk\test.txt
> > Status against revision: 64
> >
> > 3) pcs42xx D:\junk>svn status
> > M trunk\test.txt
> >
> > be a large change (I'm guessing) to the code. However, and more
> > importantly, it's a large change to the meaning of the
> status command.
>
> This is a very good point, and I'm inclined to agree. If a
> new feature were implemented for caching of previously
> retrieved information about the repository, it must not
> change the existing behavior of existing commands/functions/features.

One last time: I am not advocating changing the output of any existing
operation, I am advocating that information _already_ available be
cacheable in a standard format on the client workspace. The points made
here are valid, but irrelevant to the issue.

> If something new were created, I think it would really have
> to be something new. If it creates a new line for some files
> like "repository-rev" in the entries file, then the new line
> could safely be ignored by existing commands such as "svn status"

That makes sense. So, have a new interface that does both an "update"
and a check for locks, then caches the locks with the updates, thus
making that information available to GUI plugins, etc., in a standard
format.

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org