[Info-vax] Where to locate software

Kerry Main kerry.main at backtothefutureit.com
Tue Jun 14 16:14:35 EDT 2016


> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 14-Jun-16 2:27 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Where to locate software
> 
> On 2016-06-14 16:11:10 +0000, David Froble said:
> 
> > This whole discussion about locking code seems to be unhelpful, if one
> > considers it must be one or another.
> >
> > As an example, in RMS one can read and lock a record for later update,
> > and one can read regardless and cannot update.  Should not both of
> > those concepts be in a code management system?
> >
> > Or, am I not understanding the problem at all?
> 
> What the folks are referring to as "locking" is also commonly called
> "checking out" or "reserving", and "checking in" or "replacing" or
> "adding" or "committing" or "pushing" source code modules back into
> the
> source pool.
> 
> Different packages have different sequences.
> 
> The RMS record-level analog of some is a read-regardless, followed by a
> read-compare and either an update or a merge and update.   Sequences
> which lock the record then force other threads to deal with the lock,
> or to override it and read the lock, or to include some sort of
> revocation and release on specified criteria; lock has aged out, the
> requestor being on holiday, whatever.   And I'd suggest not trying to
> map RMS records to source control, as there's far more to this around
> both transactional operations, and the folks that expect to identify
> specific source code releases and change propagation and other details
> — this is akin to tracking individual records over the lifetime of the
> file, often with branching and merging for side-projects, testing or
> trial projects, and extended development efforts.
> 
> Some folks centralize all code operations on one host or one cluster,
> and prefer to copy and resynchronize and differentiate source code
> modules located on any other hosts using locally-written tools when
> working off of the source pool host.  Or — as often happens — migrating
> from this to a more distributed approach is non-trivial.
> 
> A distributed approach using a DVCS package has either entirely private
> or shared or externally hosted source pools, and have a canonical core
> source pool (private to the organization or shared), but also have
> local-to-the-developer source pools, with remote access and offline
> access and easy updates of the local-to-the-developer pools based on
> the most current pool contents of the shared pool.
> 
> Both centralized/VCS  packages and distributed/DVCS packages can and
> variously do provide reservations, merges, code reviews and other
> features.   The features and commands and sequences for these VCS
> and
> DVCS packages varies.
> 
> Examples of DVCS packages include git and Mercurial as have been
> discussed, and others.   Fossil is one of the others and tends to get
> rather less coverage, but is quite interesting.
> http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
> 

Although it is UNIX focused, the link posted earlier by Lawrence is pretty 
good at explaining VCS theory and the various options-
http://www.catb.org/esr/writings/version-control/version-control.html#why_vcs

As an example - Extract: comparing DVCS vs. CVCS
"One is that a single repository is a single point of failure — if the repository 
server is down all work stops. The other is that you need to be connected 
live to the server to do checkins and checkouts; if you're offline, you can't 
work."

In the OpenVMS world, you would simply configure a central dev cluster 
(or multi-site cluster if DR needed), so the "server" being down is much 
less of an issue than in the past. Additional servers are still seen as a single 
server to the developers and adds additional capacity for compiles etc.

The justification of needing to work while being offline is getting harder 
to justify because of all the connectivity and WIFI options available today.
Some airlines even offer Internet on flights now. Railways have been 
offering Internet for years.

Course, you could state you need to work offline while riding in a google
driverless car, but then they will likely have connectivity in the car as well.

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com





More information about the Info-vax mailing list