[Interest] Editor history (was: Re: Signal/Slot connection, fails, ...)

[Roland Hughes]

On 2/17/20 5:00 AM, interest-request at qt-project.org wrote:
> One of the only two(*) things I miss about using Eclipse is that it
> automatically kept a history of file changes every time you saved (up to
> some configurable time period). And a built-in diff viewer where it was
> easy to compare revisions, revert all or parts, etc. Would be great to
> have that option in QtCreator.

I believe UltraEdit had something like this as well. It just had a 
wretched K&R type coding style it forced on you.

https://www.ultraedit.com/support/tutorials-power-tips/ultraedit/version-backup.html

On OpenVMS we never had to worry about this because RMS (Record 
Management System) (one of those pesky things "not needed" by Linux or 
other PC based operating systems) created a new version of the file 
right where it was every time you saved. Ascending version numbers from 
1 - 32767. You got rid of the lower version numbers via the PURGE 
command and if you were really worried you could rename the current 
version to version 1 after that.

The still high priced highly restrictive licensed SlickEdit also has the 
feature you request. They call it Backup History. 
https://www.slickedit.com/products/slickedit/cool-features#h-files-editing

Sublime Text has a plugin for this. 
https://packagecontrol.io/packages/Automatic%20Backups

Within QtCreator and KDevelop such a feature is wonderful. I tend to use 
Sublime for lots of general editing, not just code. My "history" could 
get massive.

I seem to remember vEdit having this feature back in the days of DOS. 
https://www.vedit.com/

Seem to remember the Watcom IDE having this feature under OS/2, perhaps 
all platforms, back in the day

> I know we can manually commit from QtC, but it's not as simple or
> foolproof (even an automated commit message like "version from 1/1/2000
> 13:05:15" would be helpful). And if the project is already under a VCS
> like git which will be published publicly, I don't want all my interim
> saves clogging it up. (Make a branch, yeah... then remember to not push
> it, and to switch branches before any "real" commits..., and clean it
> out regularly so the index doesn't get out of hand. I already try to do
> that to some extent ("WIP" branch) but it's not ideal.) Would love to
> know about a better way.

It's a culture shift you won't find in the AGILE universe which is why 
it is so poorly supported via PC tools. In the midrange and mainframe 
world where software engineering actually exists and any attempt at 
bringing in AGILE will ensure you spend the rest of your career saying 
"Hi, welcome to Walmart", it's a completely different story.

I had a long section about it in this book: 
http://www.theminimumyouneedtoknow.com/app_book.html

Code management in these environments is all about capturing _relevant_ 
changes while protecting the developer from themselves. That particular 
concept has not translated down to the small machines. Maybe with 
GitKraken or something like that you can push from tip without bringing 
the baggage, but I haven't dug into it. I have a professional license 
for GitKraken, just don't have it installed anywhere because nobody uses 
Git in the medical device world. Mostly Perforce family of products.

Each developer assigned a new project is given their copy of The Four 
Holy Documents and assigned a development area. These number from D01 to 
D99. They are full environments with some snapshot of production data.

The developer deletes the code management system creating a shiny new 
one with a copy of the very tip of the production CMS. The build 
procedures all build from the CMS. You can single compile a file from 
the command line or within your editor, but you cannot build & debug ala 
PC IDE because all changes must be checked in.

When the developer believes they have a fully functioning project 
solution that matches the actual specs without violating the SAD (System 
Architecture Document) and which doesn't introduce any new 
tool/library/whatever that has not been signed off on and approved for 
use by project management, they create a CMS Class. This includes 
whatever specific version of whatever specific source files the 
developer believes should be promoted for integration testing. They then 
are assigned an integration test environment T01 - T99. They wait for 
the test team to inform them the environment is ready for their 
promotion. After that they run the promotion script where only the files 
in the class, and not the 10 billion check-ins required to make it work, 
are promoted into test.

Once it passes integration testing others are responsible for scheduling 
a promotion into the production CMS as well as a full production turn. 
Immediately in front of the production promotion and full production 
turn the current production will be snapped to the support CMS and build 
area. Yes, one could fall/roll back, but this is faster and the support 
area allows production issues to be verify on the development system. In 
a real production world, at the first sign of trouble, you scramble 
backwards, you don't file a ticket in JIRA and let it rot until it can 
be closed via "unsupported version."

There are most likely tools which could force a Git world to operate 
like this:

=====

local developer cms

promote without including any of the local change history

separate git repositories for integration testing, production, and 
support with ability to promote/push between without bringing the change 
history baggage along.

=====

As I said, it is a complete cultural change from the PC based tools.

I feel your pain man. I've worked at shops trying to force AGILE on 
developers who also force a remote centrally hosted repo on them so 
Jenkins or whatever can perform continuous integration. (Mainframe bad, 
forces everything to be in one place, PC good because decentralized 
power to the people, so what is centrally hosted Git? A fake mainframe 
running on a yippy-yappy dog chip.)

I feel your pain man. Branches just plain suck. Pushes that bring along 
development history (not ready for testing history, saving before test 
building history) beyond suck. I was at a place that baptized itself in 
AGILE, remotely hosted Git, and continuous integration via Jenkins, 
(Satan's trinity) and a clean clone from the Git repo took 45+ minutes. 
This repo wasn't 5 years old. If you did a clean clone without the 
incantations to abandon all history you went out to lunch at a nice sit 
down place.

A true software engineering shop requires you to perform a scorched 
earth pull and build after a check-in. Rename the tree you checked in 
from, create a shiny new test build directory, clean pull from the tip 
of tip, followed by a full build. As you can guess, this wasn't 
happening there.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog