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

Paranoia commit (Was: Re: Need ammo against those who say "lock everything")

From: Josef Wolf <jw_at_raven.inka.de>
Date: 2004-04-08 00:16:24 CEST

On Fri, Apr 02, 2004 at 02:06:58PM -0800, andy.glew@amd.com wrote:

> When you've made a change C in your workspace,
> you need to integrate it via an algorithm that
> looks something like the following:
>
> checkout tree
> make change C
> loop
> test it
> if tests pass, break loop
> fix
> end loop
> loop
> update from mainline
> test it
> if tests pass
> if there has not been a change
> checkin
> break loop
> fi
> fi
> end loop
>
> You can short-circuit some of these steps,
> but the above is pretty much what you want to do
> if you want to guarantee that only code that
> passes all tests is checked in.
>
> Unfortunately, the above process is NOT guaranteed to terminate.

It not only don't guqrantee to terminate.

Even worse: (in the current implementation of CVS and svn) it also can't
guarantee that the committed code passes the tests. This is because there
is no way to make sure that your _whole_ WC is on HEAD when committing.
Assume following scenario:

   usera$ svn co $PROJ/trunk WC && cd WC && vi bar.c
   userb$ svn co $PROJ/trunk WC && cd WC && vi foo.c
   usera$ svn up && make test
   userb$ svn up && make test
   usera$ svn up # no new changes received
   userb$ svn up # no new changes received
   usera$ svn ci
   userb$ svn ci

In this scenario, while both "make test" will succeed, userb can still
break the build if the changes made to foo.c and bar.c are incompatible.

What is needed here is an option to "svn ci" that forces the commit to
fail unless _all_ the files in your directory are at HEAD. The current
implementation checks only modified files. (I would even argue that such
an option should be the default and an option would be needed to request
the current behavior).

I forward this to the dev list because we already discussed this about two
years ago and I promised Karl to bring it up again as soon as 1.0 is out of
the door. So I think time has come to mention it again ;)

-- 
-- 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
Received on Thu Apr 8 00:30:39 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.