Re: Up-to-date-check on commit.

On Wed, Jun 19, 2002 at 03:03:42PM -0500, Ben Collins-Sussman wrote:

> > On commit svn makes up-to-date-checks only to locally modified
> > files/properties. What is the rationale for this?
>
> Josef, you're calling into question the core model of how CVS and
> Subversion both work... the so-called "concurrent" versioning model.
>
> This system is the natural result of not having a "lock-modify-unlock"
> model. It depends on developers *communicating* with one another.

I dont see why I would call concurrency into question. Bob and Joe
have done their work concurrently. The only thing I am calling for is
a warning to Joe that his wc is not up to date. Joe could go ahead and
use the --force flag, so he get the current behavior. But he would
have the option to abort the commit and check whether Joe's change
interfere with his change.

> > 1. Bob$ svn co ; cd wc
> > 2. Joe$ svn co ; cd wc
> > 3. Bob$ emacs foo.c ; make regression-tests ; svn ci
> > 4. Joe$ emacs bar.c ; make regression-tests ; svn ci
> > 5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
>
> If Sam releases a tarball without telling Joe, this is problem with
> programmers, not with Subversion. :-)

Telling Joe about the release would actually not help. Joe would
say "I've run the regression tests and they passed. I can give my OK
to make the release." Hey, Joe "broke the build!" The problem is that
Joe is not aware about the fact that his WC is not up to date.

> I'd suggest you read this part of the Design document:
> http://subversion.tigris.org/files/documents/15/17/svn-design.html
> Take a look at the section labeled "Subversion Does Not Lock Files".

I've read this and I dont see the point. I like the concurrency. I am
using CVS for 10 years now and I have _never_ used locks. But again:
my proposal has nothing to do with locks. It's more like:

  "foo.c not up to date. Are you sure you want to proceed (yes/no)?"

-- 
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org