Ben Collins-Sussman <sussman@collab.net> writes:
> ghudson has two (IMO) very interesting responses to this.
>
> 1. Who cares, this isn't a real problem.
>
> In the concurrent copy-modify-merge paradigm, it's actually
> somewhat common for users to attempt to commit out-of-date files.
> So it's a good thing that the commit-process catches the conflicts
> early on. But in the lock-modify-unlock paradigm, it's going to be
> extremely rare for someone to try to commit a file locked by
> somebody else. It's not worth massively complexifying our commit
> process for this rare situation.
>
> (Background: to understand why this situation is rare, look at the
> locking-design.txt document... the current client UI model being
> floated by branko, jpieper, and others involves unmergeable files
> having a 'lockable' property attached and being read-only most of
> the time. To make a file editable, users run 'svn lock' -- and
> discover existing locks before starting real work. In other words,
> the client UI will "bounce" the attempt to change a locked file
> before the work even begins. It would be very hard for someone to
> edit a file, ignorant that it's locked by someone else.)
Even if this client UI theory turns out to be wrong, we can wait for
that discovery. Adding the early protections on the server side is a
totally backwards-compatible improvement. In other words, we can just
stick with the svn_repos_commit_txn() wrapper for now, do the best we
can with the client UI, and if there's still a problem with wasted
transmission time -- why then, we start looking at wrapping more of
the svn_fs code, or using Greg's alternate strategy of calling new
repos functions from the editors.
But we don't even have to worry about that right now, since the client
UI might solve the problem for us. So +1 on the single point of
wrapping until we learn we need more.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 25 01:42:48 2004