[Info-vax] Is there a way to enabling versioning in Samba

[Arne Vajhøj]

On 7/25/2017 11:13 AM, Stephen Hoffman wrote:
> On 2017-07-25 02:40:03 +0000, Arne Vajhj said:
>> On 7/24/2017 4:28 PM, Stephen Hoffman wrote:
>>> On 2017-07-24 19:56:26 +0000, Jan-Erik Soderholm said:
>>>> Den 2017-07-24 kl. 21:41, skrev Stephen Hoffman:
>>>>>> don.zong at gmail.com wrote:
>>>>>>> ...so that whenever there is a change in the file, it will create 
>>>>>>> a new file with a new version....
>>>>>> ...
>>>>> My impression is that the file system is the wrong tool for most 
>>>>> sorts of version control.
>>>>
>>>> Of course. And the file version in VMS has little to do with version 
>>>> *control*, of course.
>>>
>>> I've worked with a number of folks that do use file versions for 
>>> exactly that; for source control.   It's fairly common usage on 
>>> smaller projects on OpenVMS.   Many of the developers have been very 
>>> experienced and long-time OpenVMS folks, too.    What was asked by 
>>> the OP has been a fairly common reason why folks have asked similar 
>>> questions about OpenVMS file version creation and overwrites, too. 
>>> Hence my DVCS-related comments.  Also why I'd commented on different 
>>> potential goals that might be in play here.   Different folks use 
>>> OpenVMS for different reasons, and sometimes in vastly different ways,
>>
>> Using VMS file versions for VCS is utterly insane.
> 
> I'm not going to argue that.   But I've encountered exactly this usage, 
> and across organizations and developers.   Combinations of versions and 
> directories, most commonly.  Getting back to a particular build is... 
> interesting.   Reproducable builds are also seldom available.

I am sure that it has happened.

But it is still insane.

There are better solution available than using VMS version numbers
even without using a VCS.

> But rather than blaming the users, I'd prefer to look for ways out of 
> this usage.   Ways to make this easier and faster and better.  Source 
> code management and development tooling has been problematic for a while 
> on OpenVMS, as compared with what's increasingly available on other 
> platforms; differences in IDEs and tool chains.  LSEDIT is somewhat 
> integrated with source code management, and anything else involves 
> acquiring or integrating third-party and/or open source.   And more than 
> a few OpenVMS developers are using tools that are less integrated and 
> more limited than what LSEDIT and such provide.   Which works for them, 
> but won't particularly attract new users.

I am leaning towards that:
* command line tools on VMS
* GUI tools for desktop OS'es that integrates with VMS
is the way to go.

Arne