RE: Future CVS Development

[Noel L Yap]

CVS only requires files to be mergable.  This has a different meaning from
requiring files to be non-binary.

One thing that may be done is to add a hook for pluggable diffing/merging
engines.

Noel






> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Monday, June 18, 2001 5:32 PM
> To: Kostur, Andre
> Cc: address@hidden
> Subject: RE: Future CVS Development
>
>
> [ On Monday, June 18, 2001 at 14:39:53 (-0700), Kostur, Andre wrote: ]
> > Subject: RE: Future CVS Development
> >
> > Granted, if the user chooses to circumvent the source code
> control system,
> > you're in trouble, and that's where merge becomes useful as
> a safety net.
> > But if CVS could enforce that a user declares their edits
> before allowing
> > them to commit to the repository (OK, for files declared as
> COPY, and -kb
> > files.  Ones where CVS cannot automatically handle
> conflicts), this would
> > allow people to checkout a copy of the repository without
> blocking anybody,
> > but not allowing them to edit the binary files without notifying the
> > repository.
>
> But CVS doesn't WANT such a capability!  It's contrary to the
> core design!
>
> If you can't handle concurrent editing of non-text/non-mergable files
> then DON'T USE CVS!!!!!

Mr. Woods, If you read back in the topic, you'll see at the end of my
original message I distinctly mentioned calm, reasoned debate.  So far I've
seen mostly knee-jerk reactions.  One example is the last two lines above.
Another is:

<quote>
People make stupid and idiotic requests of all kinds of things all the
time.  Only marketing departments ever seem to see any need to satisfy
them.  There's nothing "wrong" with telling someone that their request
is "wrong"/inappropriate/out-of-place if that's the case.

I thought most of us in the software world were supposed to be more in
tune with doing careful requirements analysis and such.
</quote>

or:

<quote>
No, you do not.  You do not want to see ANY kind of authentication or
authorisation support in CVS, EVER.

CVS is NOT a security tool and it was not designed to be secure.
</quote>

But... since you mention "careful requirements analysis and such", let's
look at the core design of CVS and see how the requirements analysis pans
out.

As far as I can see the core design philosophy of CVS is that having
multiple people modifying the same file at the same time is not a problem.
CVS can go in later at commit time and manage to merge the changes between
the diseparate versions of the multiple developers, resulting in a final,
cohesive file representing the combination of all of the changes made to the
file.  Granted, this assumes that there are other channels of communication
between the developers so that basic structure of stuff doesn't change, such
as the number of parameters to a function.  Also assumes that with the same
lines of communication, changes from two developers aren't too close
together.  At which point CVS stops and calmly asks the user to sort it out.

Note that the core philosophy is that multiple edits is fine since merging
is reliable.  In general, this philosophy does not hold up in the case of
binary, non-mergeable files.  (Wait, since it doesn't fit the "core desgin",
shouldn't it be removed from CVS?)

I'm not saying that my suggested course of action will solve all problems
either, but that's why I've presented it to the CVS group at large, to
gather feedback ("Well, nice idea, but it won't work for the majority of
cases because of X, Y, and Z.  Also, if Q happens, you lose all contents of
the file.", and not "NO! It's Bad!".  One is constructive criticism, one is
a flat denial solving nothing), and possibly further refinement to the
suggested design ("Cool, but it doesn't work for X and Y.  But if you do Q,
then X and Y aren't problems anymore.").

One thing I hope everyone can agree on is that the fossilization of the
design of any program is generally not a good thing.  It will lead to the
program no longer being used for the task as other, more capable programs
take over for it.  If a program's destined to fail in this manner, why
should users/developers invest any time in the program if it's destined to
fail?

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs




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.