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

RE: RE: RE: RE: RE: RE: Communication of LOCKS and CHANGES

From: Reedick, Andrew <jr9445_at_ATT.COM>
Date: 2007-11-21 22:09:24 CET

 

> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Wednesday, November 21, 2007 2:24 PM
> To: Reedick, Andrew; Harvey, Edward; users@subversion.tigris.org
> Subject: RE: RE: RE: RE: RE: RE: Communication of LOCKS and CHANGES
>
>
> With that assertion, it falls on each GUI client to
> unilaterally create their own means to cache and display the
> data.

Well... GUI clients are already unilaterally deciding how to present SVN
data in their respective GUIs. ;-) TortoiseSVN has a version tree that
SVN doesn't have.

> It also means they have to use two separate operations
> behind the scene to get the data (two calls to the server,
> twice the chattiness). Worse, developers using two clients
> together have two caches to update. Not a good idea, so no,
> it is not better handled by clients like TortoiseSVN. That
> is exactly who should NOT handle it. Tortoise should make
> use of the cached data available to it.

I disagree. The operations/api to get the desired data appear trivial.
The is no good business reason (cost justification) for SVN to implement
an even more convenient data cache for 3rd party clients to read from.

The hard part isn't getting the data, it's presenting the data to the
user. Obviously, presenting the data should be left up to the client.
Also, since SVN is a command line app, and what you're asking for can be
scripted, it's going to be a hard sell to get the devs to take the time
to code a special script into the client for data that can't be easily
presented via the command line.

Again, I think you should bounce this idea off of the TortoiseSVN
mailing list. They should be able to tell you how easy/hard it would be
to implement this idea using current versions of SVN. If they're
interested, and consider it easy to implement, you win. If they're
interested, but it is difficult to implement, then they can probably put
their backing/weight/technical knowledge behind 'standardized convenient
caching' and push to get it implemented in SVN so that GUIs can use it.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 22:11:09 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.