On 2/17/20 5:00 AM, [email protected] 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
_______________________________________________
Interest mailing list
[email protected]
https://lists.qt-project.org/listinfo/interest
