[Info-vax] Where to locate software

[Stephen Hoffman]

On 2016-06-13 13:02:02 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
>> lawrencedo99--- via Info-vax
>> Sent: 12-Jun-16 8:50 PM
>> To: info-vax at info-vax.com
>> Cc: lawrencedo99 at gmail.com
>> Subject: Re: [New Info-vax] Where to locate software
>> 
>> 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.
>> 
> 
> Can you share some of these experiences and what the challenges were?
> 
> I can see using VCS systems like Git when you have to deal with 
> external code updates like the VSI folks, but when you have a closed 
> system that uses mostly custom code, I just do not see the logic.

Trivial replication, distributed access from client systems.   In the 
case of Stark, the canonical source server somewhere, and local copies 
on various clients doing local development and testing, trivially 
synchronized with updates.  When you're done, push the changes to the 
repositories, and get the build and test bots — those are part of newer 
tooling, and not something typically found on OpenVMS — these are 
somewhat akin to "database triggers" with a relational database, but 
that perform automatic source formatting on checkin, and code 
integration and testing at checkin — and made available to the rest of 
the team.   Having to haul files around even inside an organization — 
check out the files, haul them somewhere, get the environment set up, 
then keep that environment updated as files are changed by other 
developers — is both more work and more fodder for introducing errors 
and regressions.    A DVCS also means you can be developing locally, 
even when the main source server is offline or inaccessible for some 
reason.   Subversion and DECset CMS assume you're all working on the 
same cluster, and that the pool is always accessible.

Seriously.  Go use the tools.   You're the CIO.   That means you're 
making technical decisions for the infrastructure, and that means you 
get to use and learn about new tools.

> Certainly willing to have my eyes opened for the right reasons, but 
> notjust to become politically correct in the developer world.

You seem to fight against change.   That's laudable — when it's done 
for the right reasons.  But unfamiliarity with tools or — worse — 
picking the wrong tools, or resisting better tools, is a serious 
problem for any organization.   These decisions and the fallout from 
these situations you've certainly experienced while working with 
enterprise organizations, too.   Senior folks that pick the tools in 
isolation and based on {some mandate, something heard at the executive 
golf game, whatever} and leave the staff to deal with the fallout from 
that decision.  Learn the tools, do your due diligence, ask your own 
folks questions, test the tools yourself or get folks you trust to test 
the tools.  Don't get stuck on what was, and completely miss what will 
be.    In this case, your phrasing and your whole approach certainly 
implies you've already made your decision here, too.   Without having 
any personal experience with the tools.   Please.   Don't be that 
manager.

-- 
Pure Personal Opinion | HoffmanLabs LLC