Josef,
We long ago decided to behave like CVS in this matter. Period.
Your points are not without merit, but this purely philosophical
discussion is going nowhere as far as Subversion development is
concerned. Please excuse me for not answering the rest of your mail
in detail; it's just not a discussion worth having as we enter Alpha.
-K
Josef Wolf <jw@raven.inka.de> writes:
> On Wed, Jun 19, 2002 at 05:07:45PM -0500, Ben Collins-Sussman wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 23 00:44:35 2002