Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Fri, 30 May 2008 00:09:47 +0200

On Donnerstag, 29. Mai 2008, Andrew Johnson wrote:
> Unfortunately if I commit these changes (which provide a comprehensive
> solution) this will probably require *some* out-of-tree device and
> record support changes to match, as in the above warnings from asyn
> which are from pointers to the DBF_LONG state value fields (ZRVL etc) of
> the MBB* record types.
>
> It might be possible to reduce the impact of the fix while still getting
> the IOC to work properly on 64-bit CPUs by not making DBF_LONG fields
> become an epicsInt32 type.  In this case, my current changes would move
> to the main trunk for the R3.15 release.

Sorry for sidetracking but these sort of problems would barely exist if we 
could decide on using a modern distributed version control system, like the 
one we are now routinely using at BESSY, namely Darcs. Just set up an 
experimental branch with full 64-bit compatibility. Everyone could 
contribute fixes or add necessary changes as they find them. When the 
branch stabilizes, merge the changes to the trunk and produce a new 
release. Keeping the branch up-to-date w.r.t. changes on the trunk is easy, 
fail-safe, and mostly automatic.(*)

The main disadvantage of CVS, Subversion, and other centralized VCSes is 
that (1) every form of effective collaboration has to go through the 
central repository and (2) merging changes from a branch to the main trunk 
(or another branch) is tedious and error-prone.

This is especially a problem when facing the need to make invasive changes 
that must be carried out uniformly in many different places unless the 
product become unstable or buggy /and/ which cannot easily be carried out 
by a single person.

There are many modern VCSes with characteristics similar to Darcs (mercurial 
seems to be quite popular these days), however, we have had very good 
experience with Darcs and since version 2.0 has been released, there is no 
longer need to fear exponential blow-up on nested conflicts (if one uses 
the new darcs-2 repository format, that is).

There are of course many more advantages in modern distributed VCSes 
(specially over the outdated CVS) but I didn't want this message to grow 
into a full-sized paper, so I'll just stop here. ;-)

Cheers
Ben

(*) The "mostly automatic" part depends to a certain extent on a reasonably 
responsible and collaborative attitude of the developers, to help avoid 
unnecessary conflicts. Specifically, changes should be recorded in small, 
ideally localized, steps; larger redesigns or merely reformattings -- even 
if limited to a subsystem -- should be carried out on separate branches 
until stabilized, and communicated to other developers before merging, etc. 
In our experience such behaviour is greatly encouraged by tools such as 
Darcs, due to the simple fact that it (a) automatically decomposes your 
changes into 'hunks' (blocks of changes on adjacent lines) and presents you 
each such hunk separately for inclusion to a patch, and (b) that there is 
the option of adding more changes to a patch after recording it. These 
points make it extremely easy to separate changes into logically (but not 
necessarily textually) connected groups for separate recording. A nice 
side-effect is that patch descriptions tend to actually reflect what's been 
done -- if you have the feeling it doesn't, there is a good chance you have 
been mixing too many unrelated changes into your patch and should consider 
re-recording in smaller steps (which is no problem at all if the patches 
haven't been published yet). As a last point let me mention the possibility 
to actually /try out/ whether (and where/why) conflicts appear w/o touching 
the main repository.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System