Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Thu, 29 May 2008 16:56:55 -0700

Ben Franksen wrote:

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.

Currently, we use CVS. There are some also so experimenting with

subversion as well.

However, should we take a serious look at Git?:
=================================================================================

Git is distributed version control system focused on speed, effectivity

and real-world usability on large projects.

=================================================================================

http://git.or.cz/

The linux kernel project uses Git.

Thanks,
Ernest

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System