[Info-vax] Where to locate software

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Craig A. Berry via Info-vax
> Sent: 13-Jun-16 10:06 PM
> To: info-vax at info-vax.com
> Cc: Craig A. Berry <craigberry at nospam.mac.com>
> Subject: Re: [New Info-vax] Where to locate software
> 
> On 6/13/16 8:08 AM, Bob Koehler wrote:
> > In article <e2e9f10d-69c0-45b2-9e10-
> 20d111b55592 at googlegroups.com>, lawrencedo99 at gmail.com writes:
> >> On Monday, June 13, 2016 at 8:30:04 AM UTC+12, Kerry Main wrote:
> >>> Q - perhaps I am really old school, but should not VCS systems have
> the
> >>> capability to prevent code from being updated (read-only) when it is
> >>> checked out for update by someone else i.e. similar to document
> mgmt.
> >>> strategies?
> >>
> >> After many years of experience with this in the real world, it was
> discovered to a be a very, very bad idea.
> >
> >    After many years of experience with this in the real world, we found
> >    the problems with it were created by inmprper practices put in place
> >    by folks who don't know why we have electronic CM tools.
> 
> The "D" in DVCS stands for distributed. If you have to wait for someone
> else to finish with a file before you can work on it, you're doing the
> opposite of distributed development and are defeating concurrency in
> your development process. Too much locking increases contention in
> human
> systems as well as software systems. Or, put differently, blocking
> people from getting work done isn't such a great idea when getting work
> done is important to you.
> 
> Not all merges are trivial but many are. Big changes that are likely to
> be difficult to merge do need discussion and planning, but better to
> communicate by, well, communicating than by locking up the source so
> no
> one else can do anything.
> 

There is a place for locking code e.g. large binary assets like images etc.
so the VCS system needs to have the capability to do locking.

Well planned, modular code (not monster modules) and defined workflow 
processes with structured teams, can help to minimize these locking issues
- especially with smaller teams.

While there is obviously a case for both strategies, one should not simply
dismiss potential locking issues as a non-starter for a centralized VCS (CVCS). 

The other potential issues with a CVCS are also not big issues for OpenVMS:
- what happens if server is down? A - use a dev cluster which is a no-brainer
In the OpenVMS world. Hence, need a VCS that is cluster aware. Also adds
scalability as nodes can be added transparently to developers.
- what happens if network is not available? A - much smaller issue today
than in the past. Laptops with aircards / built-in are cheap and available,
wifi is widespread.
- working on code disconnected on planes? A - ok, but for security reasons, 
this is not a great idea if there is any sensitivity and/or confidentiality 
involved.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com