info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coflict marker detection proposal


From: Noel L Yap
Subject: Re: Coflict marker detection proposal
Date: Thu, 19 Jul 2001 15:04:13 -0400

>[ On Wednesday, July 18, 2001 at 00:51:31 (-0700), Paul Sander wrote: ]
>> Subject: Re: Coflict marker detection proposal
>>
>> "Probably" does not cut it.  The user has the final responsibility to
>> decide what is acceptable to be committed, not CVS.
>
>The user always has the final responsibility.  That doesn't change what
>CVS is responsible for.  CVS is, like it or not, responsible for merge
>conflict detection.

CVS already has conflict marker detection.  It warns the user so that they know
about it.

>> I've had to resolve double-merges, and it's not pretty.  But on the
>> other hand, the users should be educated enough to know that they
>> really should not attempt multiple merges between commits.  This is
>> as much of a training issue as anything else.
>
>Do you know anything about the theory of use of technical controls Paul?

Let's not turn to a philosophical discussion on theory, please; CVS is a
practical product.

>I suspect not given your attitude here.....  NEVER leave the user to
>protect himself from his own actions when you can do better with
>automatically applied ("technical") controls.

If you really want this, then create a CVS wrapper.

>> Seriously, it's arrogant of the tool designer to think that they can
>> anticipate every possible use of the tool.
>
>BS.  That's the very nature of a tool designer!

So, either the tool designer's job is impossible, or the tool itself is trivial.

>A tool designer anticipates not every use of his tools, but rather the
>*best* uses of his tools.  A careful tool designer makes a tool easier
>to use for its designed purpose, and perhaps even harder to use for
>incorrect purposes (or at least for jobs where its use would be dangerous).

There is nothing dangerous with letting users update when conflict markers exist
since the repo is still intact.

CVS warns the user of existing conflict markers and that's enough.

>>  It is not reasonable to expect
>> that conflict markers can't be introduced into files by some mechanism
>> other than CVS.
>
>For CVS it sure as hell is!  CVS is not a generic filesystem!

I don't understand this reply.  Conflict markers can be introduced by anything.
CVS cannot know what introduced it.

>> But apparently it put up sufficient needless overhead to compel one of
>> the maintainers to make a change.
>
>You obviously know even less about what motivated Jim Kingdon than I do!

The only one who can say this for certain is Jim Kingdon himself.

>> You have to understand that allowing CVS restrict, however rarely, the
>> contents of a file given to it to be stored in the repository, is a
>> dangerous precedent.
>
>Duh.  CVS set that precedent when it was designed (i.e. before a line of
>code was written, back before CVS-I, when the very concept of writting a
>wrapper over RCS to implement a concurrent versioning system was first
>thought of).

Design docs aren't set in stone.  Designers aren't perfect gods.

>And just exactly what problem is there with that?  I'll tell you there
>is no problem with that.  That's an example of a tool becoming highly
>specialised to deal with the jobs it does best.  That's the way good
>tools evolve and become better tools.

Then please create your own specialized tool.

>On the other hand if you keep making a tool more generic and less
>specialised then you'll quickly slide down the slippery slope of
>creating something so generic it's of no use to anyone.

This is true, but I don't think that in the case of CVSs current conflict marker
detection.

>If you want more bells and whistles with less specialisation, may I
>please introduce you to the Unix fileystem.

Leaving conflict marker detection as warnings is less bells and whistles than
making them errors.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]