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

RE: Re: Communication of CHANGES

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-11-28 20:19:49 CET

> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Giulio Troccoli wrote:
> >> A real user quote: "How can I trust Subversion if it can't even
> >> consistently show status information between clients?"
> >>
> >
> > Answer: exactly because of that. The only way to know something for
> > sure is to use Subversion not a client, IMHO.
> Better answer: cached status information is never reliable.

Neither is a road map published five years ago, but it is close enough
to be useful.

> If you want to know about the state of concurrent operations
> you have to ask the server since it is the only thing that
> knows. But I think the discussion has moved on to whether

That is true, but reasonably intelligent human beings understand that
information retrieved two hours ago might not be the same information
that would be retrieved right now. They can still act upon it within
reasonable parameters.

> there should be an official api to store this unreliable
> information. If you expect multiple GUI clients to be
> concurrently running and always display the same info you are
> going to need a lot of synchronization and locking gunk that
> doesn't seem to belong in a core api - and if it doesn't do

Why does having two clients to a file automatically mean concurrency
problems? There's only a problem if they try to write to it at the same
time. That's not going to happen, since users have to request an update
manually. I think the effort necessary to cause a concurrent write is
greater than the desire to do it just to break it. Worse case scenario,
a simple blocking lock serializes the access, so the file is updated

> that, what's the point of adding more than you'd get with
> 'svn -u status >file'?

As stated repeatedly, and emphatically, by multiple people, the point is
a standard format, a single point of creation, and a unified interface
to get it. I'm sure I'll repeat it again later this week.

> --
> Les Mikesell
> lesmikesell@gmail.com

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
Received on Wed Nov 28 20:20:33 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.