[Info-vax] Where to locate software

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 12-Jun-16 3:24 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-12 17:31:52 +0000, Kerry Main said:
> 
> >>
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> >> Stephen Hoffman via Info-vax
> >> Sent: 12-Jun-16 12:54 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-12 14:09:08 +0000, Kerry Main said:
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>>
> >>>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf
> Of
> >>>> lawrencedo99--- via Info-vax
> >>>>
> >>>> Certainly, centralized VCSes are seen as obsolete these days.
> >>>
> >>> "Certainly"???
> >>>
> >>> While this statement may bring the politicaly correct hype
> generators
> >>> of  the very distributed open source world down on me, this last
> >>> statement  is a pile of crap.
> >>
> >> Have you used a DVCS, Kerry?
> >
> > No.
> 
> So something you've never used and have no experience with is a "pile
> of crap"?
> 
> > I do not pretend to be a developer, but I do know best practices and
> > whatmakes sense from a big IT picture perspective.
> 
> Maybe do some development work, and get your operations scripts
> under
> source control and deployment control, and see what works?  And what
> doesn't work?  And what's more work?
> 
> > In parallel with this, I rely on the experience of others (like links I
> > posted)to further shape my opinions.
> 
> How about the bozo that maintained the OpenVMS development source
> code
> control system, and that finds that approach woefully inadequate in
> comparison to more modern DVCS tools?
> 
> Particularly if you're working remotely and with a development team
> actively making changes, a DVCS gets rid of more than a little of the
> drudge work of coordinating the source code pool.   Subversion (SVN)
> and DECset CMS and such are certainly good VCS tools, but they're a
> slog to use when you're doing parallel development work and
> particularly when you're working — as many projects do — off to the
> side and away from centralized build servers and mechanisms, or when
> you're trying to incorporate changes from others that are underway in
> parallel.
> 
> Maybe go try some of these tools?   Seriously.
> 

I never say never, but a few key requirements for the VCS system I have 
in mind are:
- HA (therefore solution must be clusterable), and 
- scalable (therefore must be able to add dev systems transparently to
the developers i.e. they "see" one dev system only)
- must be proven full solution (not client only) on OpenVMS (see previous 
bullets)

Here is a question for you regarding  CMS "reserve" equivalent.

Both DVCS and CVCS systems today seem to have a common "feature" 
whereby Developers are free to check code out for updates regardless of 
whether someone else also already has it checked out. Therefore, the same 
code is potentially being updated by multiple developers at the same time. 

This seems to be common to all current VCS systems today.

As I understand it, when the code is checked back in, the strategy is to let 
the VCS system figure out the best way to ensure code is consistent and 
logical. Alternatively, flag the developer that something is messed up.

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? 

I realize this takes some planning with more modular code and likely
more formality on the dev culture.

Thoughts?

Regards,

Kerry Main
Kerry dot main at starkgaming dot com