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

Re: Exclusive Locking: design in a nutshell

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-05-20 03:18:16 CEST

On Wed, 2004-05-19 at 19:29, Ben Collins-Sussman wrote:

> Subversion then has the choice of (1) making every PUT into a commit,
> which can get very messy and annoying with most auto-saving DAV clients,
> or (2) violate DAV, and make a lock-holder's GET show something
> different than what the general public sees.

Let me follow up to myself, and repeat a point ghudson has made on IRC.

"Auto-saving" isn't the real problem here. We're talking about a user
that opens a file directly from a repository with MS-Word (LOCK), then
deliberately hits Control-S every few minutes to save progress (PUT),
then ultimately closes the document (UNLOCK).

Perhaps the "lots of revisions" issue really isn't an issue at all.
Here's the IRC excerpt:

<ghudson> Anyway, if a user is compulsively hitting save, then it seems
like the user has asked to commit whatever changes have been made. It
would be weird for us to toss the history of save events just because
they were all done during the possession of a single lock.
<ghudson> It would be like if a user repeatedly ran C-x C-q to check in
an emacs file after making small changes, and we somehow detected that
it was all done within a single emacs session and tossed all but the
last commit.
<sussman> hm
<sussman> I can buy that argument.
<ghudson> I can understand wanting a versioning filesystem, where every
change is made with history and nothing is lost. I can understand
wanting a version-control client, where you make a conscious decision to
commit a related set of changes all at once. I don't get this idea of
trying to heuristically guess at the right granularity of changes to
automatically save.
<sussman> it's pretty hard to make that guess.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 20 03:22:57 2004

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

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