[ On Wednesday, February 16, 2000 at 09:51:44 (-0600), David Thornley wrote: ]
> Subject: Re: CVS File Locking
>
> Which is sufficiently close to false to not be worth dealing with.
On the contrary....
> 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.
Such recreation of changes is a perfectly valid solution. Nothing needs
to be lost of given up.
> > CVS was designed only with the copy-edit-merge paradigm in mind.
> > Clearly it doesn't force programmers to always make simultaneous changes
> > to the same files and I certainly didn't mean to imply that it does.
> > Indeed good project management outside of CVS is often focused on how to
> > reduce conflicts and the need for merges and there's nothing wrong with
> > this.
>
> 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".
> 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.
> 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.
> 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
> probably be dealt with by adding additional merges, but it seems
> to me that there's always going to be a good deal of catchup going
> on, so a shop that works on a variety of systems is likely to
> always have files that can't be merged.
Thinking in this way misses the larger issue of what it really means to
be merging changes.
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.
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.
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.
> 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. 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.
> 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! ;-).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
