[Top][All Lists]

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

Re: How well does CVS handle other types of data?

From: Greg A. Woods
Subject: Re: How well does CVS handle other types of data?
Date: Fri, 13 Jul 2001 14:42:23 -0400 (EDT)

[ On Friday, July 13, 2001 at 12:39:29 (-0400), Steven Rosenstein wrote: ]
> Subject: Re: How well does CVS handle other types of data?
> Given all that you've stated below, it seems that the crux of your argument
> turns on the ability of a file to be "mergable".  In my unadorned, pooh-like
> brain, I ask the simple (and rhetorical) question, "why?"  Why can't I have a
> simple switch which tells CVS that for this file or this directory or this
> repository, I simply want to turn merging (and all CVS file manipulations)
> *off*.  Period.  Nothing more.

Well, if you just want to turn off merging completely then you have to
come up with some way to tell CVS that you've done the merge manually
and that there are no more conflicts so it's safe for "cvs commit" to

I.e. if you tell CVS not to merge something when it thinks it has to
then you've got to let it keep track of the fact that a manual merge is
necessary and thus you've got to have a way of telling it that you've
done the manual merge.

With automated merges the assumption is that if there are no conflicts
then the merge was successfull and beyond whatever external criteria are
placed on your development process, CVS is happy to commit the merged
result unhindered.  You don't want that to happen though if you've
disabled automated merges because then you would be allowed to do a
commit without resolving the implied conflits in the un-merged files.

I don't know exactly how best to indicate that the manual merge has
successfully completed without conflicts though -- perhaps if a new
subcommand were added "cvs merged", or a new option to "cvs update",
which would change the string in the third field in CVS/Entries to
something like "manual merge OK" and then "cvs commit" would look for
that as the indicator that the ``conflict'' had been resolved....

In the case for merges of branches I think the only thing you have to
watch out for in addition is that CVS doesn't think the file still
contains unresolved conflicts (I'm not sure of the status of this
feature in CVS currently though).  Perhaps if your "switch" also turned
off conflict detection that would be all that's needed.

In the case of merges needed for concurrent edits the trick would be to
just not ever do the "update" (i.e. not update the ancestor revision in
the CVS/Entries file) and the user would then manually merge into a
temporary file, remove the file and "cvs update" it (thus making CVS
believe that the ancestor is the current head and that no merge was
necessary), then move the merged copy into its place (thus making CVS
think that there's only local changes to the file and no merge is

Note that you'd have to do this on a per-file basis.  CVS doesn't manage
directories, only the files within them.  (I suppose you could have your
switch enabled as a sticky flag such that it's turned on for all files
when you checkout or update a directory tree, but I'm not sure that
would be sane except in a very narrow range of circumstances.)

I'm not sure if '-kb' is the right "switch" to use here though.  The
problem is that it would then have an even more over-loaded purpose that
might at times be at cross purposes to this handling of manual merges.
It would probably be better to add a new feature, and preferrably one
that could be changed on a per-revision basis.  Perhaps a new "nomerge"
state would be better.   I think this is one case where using a new
state would not ever conflict with the "dead" state too....

This is, I think, very much different than Paul's strange '-kb' merge
hint proposal.  In my proposal above the user simply always has to
manually resolve the implied conflict of merge of a non-mergable file
and there's no silly default to cause accidents and confusion.

> I have a web application where 95% of the files (mergable and non-mergable) 
> are
> provided by a third-party vendor.  I am using CVS for mainly audit purposes to
> keep track of the new versions of the files as we receive them from the vendor
> and **WHERE POSSIBLE** display the differences between the various versions of
> the mergable files.  Whenever we receive updates I import them into the
> repository (applying copious comments), and I'm developing quite a meaningful
> history of vendor modifications.  When one of my developers makes a change to 
> a
> vendor-supplied, mergable file, CVS handles tracking and integrating those
> changes admirably.

Are you using "cvs import" and thus vendor-branched modules in CVS?

If so then you might not have any problem provided that you never ever
EVER make any local changes to non-mergable files (because there are no
other circumstances in vendor-branched files

Do non-mergable files ever get removed and re-added by the vendor?

If so then you might still have a problem, but it might not be
insurmountable if you use an improved version of the import cleanup
script that was posted here the other day (so that "dead" revisions get
put on the vendor branch and that the default branch is set to the
vendor branch for all files added and removed by the vendor).

Just be sure to manually add the '-kb' flag in the repository ,v file to
every such non-mergable file (eg. with "cvs admin -kb file; rm file; cvs
update file" in every working directory).

> CVS is an extraordinarily serendipitous tool.  To me, it *is* the best
> application for my needs, and the cost (both $$$ and intellectual) is very
> reasonable.  Please be understanding and accepting of my and other folks ways 
> of
> using CVS.  IMHO, confining CVS to simply being an easy and automatic means to
> perform three-way merges between revisions is to do a dis-service to all of 
> the
> time an effort obviously spent on developing the rich set of features 
> available
> in system.

The problem is that _you_ need to understand the requirements and
limitations of CVS too!  If you don't deeply understand these things
then you're liable to get into trouble and then blame the tool for
hitting you in the thumb instead of blaming the operator.

                                                        Greg A. Woods

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

reply via email to

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