Re: adding on branch

[Paul Edwards]

"Mark D. Baushke" <mdb@cvshome.org> wrote in message 
news:mailman.6920.1054141922.21513.bug-cvs@gnu.org...
> Stefan Monnier <monnier+gnu.cvs.bug/news/@rum.cs.yale.edu> writes:
>
> > I think the first problem is to get things working as I think they
> > should.
>
> It makes no sense to me to alter the behavior of cvs unless we
> understand the implications of the change and agree that it is in the
> right direction and does not break existing user expectations.

I don't see any ramifications for development on a branch no
longer affecting natural and expected import operation.

> Other folks have mentioned it before. cvs development needs a vision and
> a goal. Well, you have the start of a short term goal. Is it so much to
> ask that we have a vision of how that short term goal impacts the general
> operation of cvs?

It's actually a long term goal.  To have CVS work as a logically
foolproof source control system.  It very nearly meets that
criteria.  I work on a large source code base with multiple
branches and so I give CVS more of an "exercise" than most,
which is how I know that there are still deficiencies.

The deficiencies I know of are:

1. Import as discussed being handled differently when branch exists.
2. Merge not creating a conflict when branch exists.
3. diff and rdiff -s not coping with different branches having
different version numbers while still being identical. (patch provided).
4. diff between two labels, first missing, second dead produces an
error instead of silence.
5. diff and rdiff are not mirrors.
6. (still need to verify) diff -c8 produced "!" for added lines in cvs 1.11.5

(2) is the one with an integrity problem.  The others failsafe,
although I guess (1) would be an integrity problem for some
people, but in that case it is an entire file missing rather than
some lines of code, not nearly as serious.

> > The merging case comes afterwards.
>
> Not really.
>
> I would rather have a design and work to implement the change than go at
> a change in an ad hoc manner.

The merging problem I have has nothing to do with the fact that
the head is dead.  I don't use the head anyway.  The problem I
have is that a conflict due to a file being added, that has already
been added, doesn't failsafe and produce a conflict.  If nothing
else, it should do this.

> > And honestly, CVS is not good at finding the ancestor on its own
> > anyway, so it wouldn't be the first time that the ancestor needs to be
> > given explicitly in order to get a good merge.
>
> Hmmm... if you say so then you probably have explicit examples in mind,
> but it actually it seems to work for me. Of course, it does not keep a
> good 'memory' of previous merge operations, but that is a bit outside of
> the current problem statement.

The problems I am describing have nothing to do with finding
a common ancestor.  I always provide an explicit ancestor.

> > > Sure. Actually, there has been some talk of just removing the Attic
> > > optimization for the mainline. It was needed before cvs was taught about
> > > the dead state, but it is not really needed these days.
> >
> > Whatever works...  The main question is: do you now agree that the current
> > behavior is conceptually wrong (regarding the timing-sensitivity for steps
> > 2 and 3 of my example) ?
>
> I am willing to entertain the idea that a change in behavior could be
> beneficial to users of cvs. I want to make sure that the change will
> not have any negative impact on existing users.
>
> So, what are the things that need to change in how cvs does its import
> operation to keep the current way in which the vendor branch is treated
> with regard to subsequent imports and what happens when a local change
> is made and still give you the ability to have your order independent
> view of the file?

I have no idea how it should be implemented on the RCS files.
Delete all tags from version 1.1 and make it non-dead and move
it out of the Attic?  So that it looks identical to if it had been
created in the other order, ie import first.

BFN.  Paul.