Josef Wolf <jw@raven.inka.de> writes:
> > 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.
We already have conflict detection to some degree. If Joe's commit
tries to modify the same file that Bob already committed, then the
server *does* abort the commit, and tells Joe that he needs to update
first.
But you're essentially suggesting a dry-run update to execute before
each commit, just like 'svn status -u'... and the server gives a
warning if your working copy isn't perfectly at HEAD.
The truth is, this isn't how CVS works, and there's no need to make it
Subversion work this way. The rule is just too restrictive: "you can
only commit if you're at HEAD." Yes, a --force flag could override,
but the issue at stake here is about choosing sensible defaults, and
it seems too big a burden to have such a restrictive default behavior.
I don't want the default behavior to bounce me out or display
warnings, because oftentimes there's *nothing* wrong with committing
from an out-of-date working copy. (And the situation is rare anyway:
90% of the time, CVS users will 'cvs up' right before they commit, to
manually find direct collisions (before the server points them out.))
The design of CVS and Subversion is: the tool prevents syntactic
conflicts (i.e. overlapping sections of code.) It doesn't prevent
semantic problems. It allows mixed-revision working copies... which
might be semantically wrong. It allows HEAD on the server to be a
made of mixed file revisions too... which might be semantically wrong.
It's up to the developers to coordinate, test, and tag the correct
combinations. It's philosophically inconsistent to make Subversion
behave as though it's "dangerous" to build a mixed, untested HEAD
revision.
> > > 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!"
There are still communication errors.
Bob commits r21.
Joe commits r22. (The two commits do not overlap.)
Bob tells Joe that he wants to roll a tarball.
Joe says "the regression tests passed, go ahead."
What revision are they rolling? Would Bob not notice that HEAD is now
22, instead of 21, when he does a checkout for the tarball? Why
didn't they agree on the revision to roll when they talked?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 20 00:10:11 2002