On Wed, Jun 19, 2002 at 05:07:45PM -0500, Ben Collins-Sussman wrote:
> 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.
So now you have to tell me why you want to stop this detection on
file border. Why abort a commit when a _modified_ file fails the
UTD-Test. Your main argument is that my management is broken. OK, I
can't convince you about the opposite, because you are right ;-) But
to some degree your management must be broken, too. Trying to commit a
modified file which is not up-to-date is a clear sign that there was
some failure at communications between developers. So why dont you say
"fix your management instead the tool" in _that_ case? Following your
philosophy to the bitter end would mean to do automatic merges when
modified files are not up-to-date because you _called_ for trouble
instead of fixing your management problems.
Following your philosophy, we could even go a step further and say
that commits with automated merges (which would happen because you are
not Up-to-date, see above) should succeed even though there were
conflicts while merging. Hey, you should fix your management instead
the tool...
Please tell me why do you want commits to abort when _your_ type of
communication failure happen (resulting in a commit of a non-UTD
file). OTOH you want not even a warning if my type of communication
failure (resulting in a non-UTD file which is not modified) happen.
I dont see any reason for this distinction. As long as we deal with
textual files (this are 100% of the files in my case, for example),
there is no reason to assume that two changes in a single file are
more dependant than two changes in two different files. I think you
agree with me that the contents of foo.c and foo.h are very close
related.
> 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 problem is that "svn [status|update]; svn ci" is _not_ atomic. So
you have no guaranty that you are _really_ at HEAD when committing.
You are "close, but no cigar" ;)
> The truth is, this isn't how CVS works,
This is true and this annoyed me the last 10 years... I had no
problems with this because I assumed that CVS _could_ not do
better. And now you say you dont _want_ svn to do better...
> and there's no need to make it Subversion work this way.
OK, you dont see the need. But would it do a harm?
> The rule is just too restrictive: "you can
> only commit if you're at HEAD."
But you agree to this rule when it is about modified files? Why want
you to force people to end their horizon at file-border?
> 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.
This could be a configuration option. Best would be if it were on a
repository basis. This way the repos-admin could decide which policy
he wants to run.
> 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.
OK, so just put "--force-commits" into your config file. Where is the
problem? Or (depending of what the default is) just let the
--i-want-paranoia-commits option out of the config file. It is _your_
decision if you dont want to see the warning. Why do you want to
extend _your_ decision to all users of svn?
> (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.))
Hey, this is _my_ point! I dont know about the number, but _you_
brought the 90% into the game ;-). 90% of the time CVS users
do "cvs up" because 90% of the time they want to be sure they are at
HEAD when committing. The trouble is that "cvs up" dont give them
any guaranty that they are really at HEAD when committing. Remember
"cvs up; cvs ci" is not atomic. And "svn up; svn ci" is not atomic, too.
> The design of CVS and Subversion is: the tool prevents syntactic
> conflicts (i.e. overlapping sections of code.) It doesn't prevent
> semantic problems.
But it still aborts the commit when no overlapping (that is modified
files without conflicts) occures. So where is the difference?
> It allows mixed-revision working copies...
Which can as well be good as bad.
> which might be semantically wrong.
I think mixed revs are very likely to be semantically wrong. But this
is just my opinion. Please let us remain on one issue at a time. Will
go back to the MixRevIssue when the most annoying issues are resolved
(OK, just kidding (for now ;-])
> It allows HEAD on the server to be a made of mixed file revisions
> too... which might be semantically wrong.
This can be good or can be bad. Depending on your policies and on your
management (sigh). You cant judge without knowing the details.
> It's up to the developers to coordinate, test, and tag the correct
> combinations.
OK, so let us assume all developers agreed to "commit only at HEAD"
> It's philosophically inconsistent to make Subversion
> behave as though it's "dangerous" to build a mixed, untested HEAD
> revision.
OTOH it is philosophically inconsistent to make such drastical
distinctions between file-based and project-based conflicts (note
that I explicitly avoid the word "module" in this context.
PS: Please excuse me when some of my statements sound rude. It is not
meant this way. This is mostly because english is not my native
language, so my vocabulary is somewhat restricted :-8.
--
-- 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 Sat Jun 22 23:20:17 2002