Revision Control

[Brian K. White]

On 8/9/2017 11:28 AM, Jay R. Ashworth via Filepro-list wrote:
> Assuming I don't pop an aneurysm first, I'm considering cleaning up a long
> standing software package for further development (parts of it are over 20
> years old), and I can't fathom doing that without revision control (which
> will probably be bzr, cause I think git was designed for gits, by gits, and
> I refuse to pick tools that purposely make me do all the work).
>
> Is anyone anywhere using an RCS for filepro code?  How's that workin' out for
> you?
>
> Cheers,
> -- jra
>

We're using git. It works as well as any other use of git, if you ignore 
the large factor that so far, we simply ignore the entire problem of 
indexes and key & data via .gitignore.

In theory, the facilities exist to write a few fancy scripts to extract 
index headers and diff *those*, and reapply those headers and rebuild 
those indexes on a receiving box all on the fly during git operations. I 
haven't actually done any of that.

We have a repo on a separate gitlab server, and a dedicated "release" 
vm, where, developers hack on their own copies on their own vms, push 
those to a gitlab server, and a release manager merges those in to 
master/HEAD, pulls that onto the release vm, does any necessary fix-ups 
like file ownerships/permissions, building toks from prcs etc, and then 
clones it out to production machines after it's manually massaged back 
into actually valid runnable state.

Mostly, we just don't happen to be changing existing index definitions 
these days, just adding new ones, and usually just as parts of new whole 
files. So we're not really tracking everything, but we are tracking all 
the prcs and other "code" kinds of files, and scripts and things 
elsewhere in the system. If we do have to change an index, we have to do 
it outside of git, same as if we had to restructure a file. (we can 
still track map files in git, and even allow git to update them, 
*sometimes if you're reeeely careful* not to change the structure, only 
the labels or edits)

Of course, viewing diffs of prc tables is not as good as it is for any 
other kind of file, but still better than nothing.

We are dealing with permissions by a kind of continuous brute force.
We have a script that applies group "programmer" ownership and write 
permissions on all files & dirs under a given directory, and we use that 
on a few dirs where we made sure that wouldn't break anything. Like, 
/u/foo/appl, /u/foo/bin, /srv/www/htdocs etc, but like, not just 
anywhere, not /etc for example. A given developer will have to run the 
regular setperms followed by the programmer group perms setter every 
once in a while. If you're careful, it can be infrequent.

In theory, git shouldn't be breaking any perms, at least on files that 
already exist, but any time git creates a new file locally, that file 
ends up having the ownership & perms dictated by the users ordinary 
login name & umask setting.

It was a rocky start for several weeks, only started a few months ago. 
But I have been having pretty good luck on my own vm the last few weeks. 
I haven't had to run the perms fixup scripts in a while.

We do also have a service called watcher.py that is supposed to be using 
intotify to watch for file creations and setting the special perms 
automatically any time something is created in one of the watched trees, 
but I don't think it's working, or maybe just isn't configured right. Or 
maybe it is working now and that's why I've had good luck lately.

-- 
bkw