Re: Coflict marker detection proposal

[Greg A. Woods]

[ 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.

>  BTW, does anyone
> commit the raw results of a merge, before resolving conflicts and
> re-committing?

What a stupid itiotic thing to even think of!  Go find some
non-concurrent versioning system Paul.  You'll be much happier.

> 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?

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.

> 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!

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).

A semi-intelligent tool user chooses his tools for the job at hand.  A
highly intelligent tool user has several similar but specialised tools
so that each job can be done with the most appropriate tools.  Please
learn to use the right tool for the job.  Are you a weekend software
mechanic, or do you work overtime with your tools because you love your
job so much?  Do you have one crescent wrench, or many sets of
single-sized wrenches?  Do you have one flat-head screwdriver, or a half
dozen of varying sizes?  Do you have on pair of household pliers, or do
you have dozens of varying size, shape, and form?  Do you have one basic
all-purpose wood saw, or do you have several of different sizes, with
different tooth shapes and even different blade thicknesses and widths?
Do you have one pair of those stupid plastic-handled bar-clamps, or do
you have dozens and dozens of bar clamps, with more than four of every
size?

>  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!

> 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!

> I don't believe that using the RCS "state" clause in a delta phrase is
> the right way to go.  Once a file has been been "Dead" and brought back,
> its "mergable-ness" is lost.  As additional RCS states are used (and
> there have been proposals to use them) then using it for this purpose
> becomes impossible.

Once a file has been dead and revived it is a new file.  Whether the new
file is mergable or not is not something CVS can decide unilaterally
based on the prior state of the dead file.  However the user can easily
choose whether the new file is to be treated as a mergable file or not,
at their discretion.  This is in fact why an RCS "state" is perfect for
this purpose -- it explicitly requires the user to choose the new state
of a new file.

> It's better to put it in a newphrase at the admin level.  That way, the
> condition is set once and requires no maintenance.  (Well, unless the
> type of the file's content is changed, but that introduces another flaw
> in CVS' design.)

Exactly -- that's yet another reason why any per-RCS file flag is
inappropriate for any per-revision information whatsoever (and yet
another reason why '-k' flags set in the RCS file should not be honoured
by CVS -- it should always ignore them since they cannot ever have the
right meaning w.r.t. to how CVS works, and they were a bad idea even for
RCS.)

Conveniently a "nomerge" state will also eliminate at least most of the
need for using '-kb' in the way some people use it with CVS today.  (It
doesn't do anything for people misusing CVS on systems so antiquated
they make a distinction between binary and non-binary files in their
filesystems, but that's their loss anyway -- I have no desire to cater
to such brain-damaged systems....)

> 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).

>  By limiting the contents of some files, someone
> later will decide that they can be limited a little more.  And a little
> more, and a little more.  After a while, the limitations aren't so rare
> anymore.

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.

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.

If you want more bells and whistles with less specialisation, may I
please introduce you to the Unix fileystem.  It's perfect for your
needs.  It handles all types of files.  It has the most flexible
versioning schemes.  It has the most flexible file naming schemes.  It
has the most flexible hierarchical schemes practically possible.  There
are already a plethora of tools that handle groups of files in
hierarchies, so in effect it has wonderful modules support.  Modern
versions have symbolic links which make it easy to mix files between
modules too.  You can even keep many versions of directories with it.
PLEASE go buy a few hundred gigabytes of disk and you'll never have need
for anything else like CVS again!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>