"Greg A. Woods" wrote:
>
> [ On Wednesday, February 16, 2000 at 09:51:44 (-0600), David Thornley wrote: ]
> > Subject: Re: CVS File Locking
> >
> > There are files which cannot be merged. Feel free to curse the
> > people who made some of them so recalcitrant, if you like. However,
> > I know of no shop where developer work is considered so freely
> > disposable as to say "OK, Jack and Jill have conflicting changes to
> > the VB program. <flips coin> We're keeping Jill's changes. Sorry,
> > Jack, good work, but we'll just have to tell the customer we're not
> > going to fulfil that requirement."
>
> Anyone who has ever spent any time working in a shop where serialised
> development is the soup du jour will know that incidents of accidental
> "concurrent" development happen all the time (through errors, usually
> human in nature) and when merging isn't possible (or isn't thought of),
> someone has to re-do their changes using the other's as a new baseline.
> Sometimes this happens without anyone but the second developer knowing
> that it happened.
>
Yes, it happens. I've been in that position often enough. That's
what CVS was designed to avoid.
> Such recreation of changes is a perfectly valid solution. Nothing needs
> to be lost of given up.
>
I suddenly feel like I'm in an alien universe. Certainly you're aware
that this is the standard solution in (say) a SCCS or RCS conflict
that's not caught in time. If you think this is a perfectly valuable
solution, then why do you like CVS? You can do concurrent development
with no tools at all, if you don't mind this sort of "merge". I did
it for quite a few years. I hated it when it went wrong.
> > > CVS was designed only with the copy-edit-merge paradigm in mind.
> >
> > Your first sentence is at least close to true, although it doesn't
> > seem to account for the first "to-do" item at the end of the paper.
>
> Ah, the first item has already been done, a long long ago in fact. The
> resulting feature is called "cvs history".
>
So you think that "cvs history" is the ideal way of learning "who might
be
working on the same module that you are"? That seems odd. I don't
think "cvs history" is the ideal way of learning anything, the way
the output is formatted.
And, if you're working to a strict copy-edit-merge paradigm, what do
you care about what other developers are doing? The only reason
you'd want to know is if you wanted to coordinate changes with them
- in other words, if you wanted to add some serialization to the
development.
> > I'm saying that, to me, the paper reads like "Look at this neat new
> > development system we've devised!", and seems to be devoted to showing
> > that concurrent development works.
>
> You're right, it does. However there's also a fairly obvious underlying
> agenda.
>
The obvious agenda is to push copy-edit-merge. It seems that there is
no obvious agenda to prevent serialized development, since I and some
other people don't seem to find it in the paper. It may have been
Berliner's intent, but it is not clearly manifest in the paper.
> > After all, we still have trouble
> > convincing people that it works, and this is some years later. It
> > looks to me like it is advancing a new method to deal with known
> > problems with the old, and I don't see anything doctrinaire in it.
>
> There will always be issues convincing people that concurrent
> development works (be it in copy-edit-merge systems, or in two-stage
> commit systems, or whatever). It's not intuitive and unless we somehow
> manage to wipe out existance of all serialised version control tools
> there will always be people who have tunnel vision about them.
>
Right. We are in complete agreement here.
Now, since there is always a fight to push copy-edit-merge, it makes
sense that Berliner was pushing for it. He didn't have to advocate
serialized development, since there were, and are, enough people who
don't believe concurrent works. He had to bring up its flaws, so that
he could push for an improved alternative.
In other words, he would have written the paper in much the same manner
if he had thought serialized development was bad, or if he had thought
it was merely unnecessary. There is no way to tell which from the
paper itself. It is not evidence for the claim that CVS was designed
to force copy-edit-merge.
Now, CVS was certainly designed to facilitate copy-edit-merge, and
initially had no support for serialization. This is at best negative
evidence to show that it was designed to force copy-edit-merge.
> > The issue is that there are files for which copy-edit-merge doesn't
> > work, generally because "merge" doesn't work. Some of these can
>
> Thinking in this way misses the larger issue of what it really means to
> be merging changes.
>
The larger issue? I'm trying to deal with practicalities here.
> The mere concept of merging changes is not what's at issue. The problem
> is how to automate it in a general enough way that it can be used in an
> effective and pragmatic version control tool.
>
Merging changes is obviously desirable, if it works. The issue is
whether it can be practical. CVS shows that, for a limited but very
important class of files, that it is practical. CVS is therefore
an effective tool for those files.
> CVS doesn't have to do any merging ever -- it could resort to forcing
> the developer to always merge changes by hand. That wouldn't change the
> concept of it being a concurrent development tool. It would just make
> it so unpalatable that normal people would never use it.
>
Right. In fact, at this point it becomes indistinguishable from the
old source libraries, with no controls whatsoever, I worked on for a
long time. The ones that RCS and SCCS were considered to be great
improvements over.
> Indeed when I tell people to re-do changes when binary files conflict
> they are likely to feel this is unpalatable too. However it is not I
> who can decide for them whether a few cases of manual conflict detection
> are easier to deal with than switching to some other version control
> tool -- they must decide that on their own.
>
And the question arises of why CVS shouldn't handle some sort of
lock. It isn't a tremendously difficult thing to implement, and
would not significantly increase code size and complexity.
Let me put it this way. What I completely fail to understand is why
it has to be one way or the other. Locking is fairly easy and
economical
to implement. It is an easy way to control serialized development,
and with some files there is no alternative to serialized changes.
I have been trying to find out why you think CVS is, and must be in
the future, used for copy-edit-merge development and nothing else.
Such strictness would make CVS undesirable in some situations where
it could otherwise be used very effectively. Relaxing the strictness
would not cause noticeable code bloat. It would have the evangelical
advantage of getting CVS used by shops that otherwise would go to
a strictly locking system, and opening up the possibility that the
users will find that they can get more work done with concurrent
development.
> > The question is whether it is worthwhile to allow CVS to be used in
> > these shops, which (I think) are going to become increasingly
> > important. If CVS is copy-edit-merge only, shops with mixed files
> > will find it impractical for some of their files, and will adopt
> > a system that works for all of their files. It is likely to not
> > support concurrency nearly as well as CVS.
>
> The issue in my mind isn't one of a conflict between concurrent
> and serialised development. That's already been decided in favour of
> the former as far as I'm concerned.
When it works. It doesn't always.
What's at issue is how well
> computer language developers respond to the issues of change management
> and whether or not they make their source file formats mergable with
> common tool, or whether or not they supply delta and merging tools for
> their files that can be integrated into common versioning tools.
>
And the cold fact is that some of them won't, for various reasons.
I think we feel the same way about the people who don't do that
for no good reason.
However, since a development team works in a substandard language
implementation, should we punish that team by preventing them from
using an excellent tool? A tool that can allow concurrent changes
on some files but not others?
There are a lot of reasons for working in technically deficient
environments. You may well refuse to work in such, and you may well
get away from it. There are a lot of people who have the independence
to work only in the environments that please them. There are also
a lot of people who work in environments that don't, because that's
where the paycheck is and there are people besides them depending on
that paycheck. I've been in that position, and I have a great deal
of sympathy for those who are.
> > CVS is a good piece of software. I would hate to see it become
> > marginalized, and in order to avoid that it does need to support
> > serialized development, preferably on a file-by-file basis.
>
> Who cares if CVS marginalised in those scenarios where people are
> forced to use unmergable files? I certainly do not. CVS will never be
> marginalised in places I will work at until someone develops an even
> more wonderful *source* code control tool (and Aegis is close on CVS'
> heels in this respect already! ;-).
This strikes me as an extremely selfish point of view. CVS, as it is,
works for you in all environments you can be reasonably forced into
working in. It doesn't work for other people, but you don't care,
and argue vehemently to prevent the tool from being modified slightly
to allow those people to use it.
If somebody were to add locks to CVS, how would it affect you?
You certainly wouldn't work at a place that used them, and that's
fine with me. It would be a bit of added functionality that you'd
never use.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (612)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
