[Top][All Lists]

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

Re: merging changes....

From: Greg A. Woods
Subject: Re: merging changes....
Date: Wed, 28 May 2003 18:50:00 -0400 (EDT)

[ On Wednesday, May 28, 2003 at 12:27:31 (-0700), Kaz Kylheku wrote: ]
> Subject: Re: merging changes....
> Laziness, not stupidity, is the psychological barrier---the natural
> resistance against doing something tedious that ought to be done by the
> machine.

If you are that lazy then you should go back to writing COBOL on
programming forms, or FORTRAN on punch cards, so that you can learn to
appreciate just how good your modern tools are already!

Rewriting code on paper, or re-using cards by merging, should give
anyone a really good idea of what it means to copy and/or merge changes!

FORTRAN (or old-style BASIC) is a great example to use when discussing
merging of changes because each logical statement is (supposed to be) on
a separate card.  Even newbie programmers can visualize physical cards
and imagine how one might merge the "extra" cards from deck with another
deck, and also remove those that were removed from that first deck in
comparison with some ancestor deck.

> I enjoy doing something manually only as a means to discover the
> algorithm. Once I have a ``script'' for doing it, I'm no longer
> interested in serving as the machine for executing that script.

Yes but the point is that the scripting is the very smallest part of
doing the job right and it only helps once you deeply understand what
you are doing.

Here's an example commit message from the NetBSD source-changes list:

 Module Name:    src                                                            
 Committed By:   perseant                                                       
 Date:           Fri May  2 01:47:41 UTC 2003                                   
 Modified Files:                                                                
         src/sys/ufs/lfs: lfs_vnops.c                                           
 Log Message:                                                                   
 Correct arguments to check_dirty, ensuring that all pages in a block are       
 written if any of them are dirty.  Pointed out by yamt.                        
 To generate a diff of this commit:                                             
 cvs rdiff -r1.104 -r1.105 src/sys/ufs/lfs/lfs_vnops.c                          

and another much larger example:


Someone who knows what "merging changes" means will immediately
understand the significance of the hints given in these log messages and
will quickly be able to generate a "change set" (aka a patch file) by
cutting and pasting the "cvs rdiff" commands from any one of those log
messages and then to apply those changes, either manually, or with
'patch', or with some other diff-merging tool, to any other copy of the
sources.  A very simple 'sed' script can also be used to translate those
commands into in-place merge commands using "cvs update -j", though
using patch only requires typing 10 additional characters to the

Any additional automation beyond this is really just a matter of
personal preferences and personal work habits.  Nothing over and above
this level gives the programmer any fundamental advantage at merging
changes, even on a rather large project like NetBSD.

I've also found that even more importantly any attempts to try to make
merging too much more automatic than this can quickly lead to
drastically confusing people who don't deeply understand what it means
to copy changes from one set of sources to another.

(note that I'm not talking about whole-branch merging, but rather just
merging selected changes ("change sets") from one branch to another or
from one repository to anotehr)

(note also that, as I hinted above, one of the key things to understand
is that 'diff' and 'patch' (or 'ed') really are not doing anything
different than someone would do when merging changes from three versions
of a FORTRAN program on three sets of punch cards -- you can't tear
cards in half automatically, especially not with a sorting machine, but
rather the programmer has to re-punch cards that collide and/or add new

If you really want to do something to make merging of changes easier and
more reliable then I'd suggest working on merge tools that can identify
and copy changes at the syntactical level instead of on the "card"
(line) level.

                                                                Greg A. Woods

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

reply via email to

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