> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Wednesday, November 21, 2007 10:55 AM
> To: Harvey, Edward; users@subversion.tigris.org
> Subject: RE: RE: RE: Communication of LOCKS and CHANGES
>
>
> 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.
>
Are you asking for the info to be cached, as in made available
offline? Or do you just want a better or clearer interface for getting
lock information?
If the latter, then this can currently be done by having a
script parse the output of status/update and then running 'svn info' on
files in K, O, T, or B status. A custom window based client (such as
TortoiseSVN) would obviously benefit from having a GUI and/or could run
as a persistent process to flag new locks.
As for caching the lock information, that seems both useful and useless:
-useful when you want to avoid working on locked files while
offline. (And you're aware that the lock information is "old.")
-useless since you cannot work on any 'unlocked' file while
offline because you cannot be sure that someone else has locked the file
since your last 'update' or 'status -u.'
-useless since if you can run 'status -u' at will or often
enough to have accurate lock information while "offline" then you have
enough server connectivity to just lock the file in the first place (or
to use svn:needs-lock.)
The idea of caching the lock information doesn't appear to fix
the problem (because it's an incomplete solution to the problem.) Plus,
explicitly locking the file and/or using "svn:needs-lock" appears to be
a better and more complete solution than caching the lock info.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 17:31:28 2007