With regard to have a more clean backup process I'd like to have a projects bin directory outside the project folder, is that possible? Now a lot of junk is copied all the time when I just want to backup the project folder.
With regard to have a more clean backup process I'd like to have a projects bin directory outside the project folder, is that possible? Now a lot of junk is copied all the time when I just want to backup the project folder.
It might be possible with the jungle file, but even if not, then you can just make the bin folder a softlink to some folder outside of the project.
But I'd argue that you're doing something wrong. What I do is have a .gitignore with:
I'm camp Jim on github. I just want to make scheduled backups without having to customize things because temporary files are stored in the wrong place. Also when I use search and replace from within VSC, I don't want them in my results.
With regard to have a more clean backup process I'd like to have a projects bin directory outside the project folder, is that possible? Now a lot of junk is copied all the time when I just want to backup the project folder.
I am on Team GitHub as well and use a .gitignore.
I tried changing it, but that does not seem to be possible. The output directory is defined through the compiler option -o. I could not find any project-specific compiler setting for this. The jungle file only controls type checking and optimization.
You can add compiler options in the VS Code Monkey C extension settings, but you cannot override the -o option that is added automatically by the build command. If you try, the compiler fails with an error because the command line option is specified twice.
I'm camp Jim on github
I find it pretty interesting that people tend to conflate git and github. Git is a source control system, github is just one git cloud provider. There are other cloud providers (like gitlab), but you don't have to use a cloud provider at all.
It's certainly possible to run your own local git server so you can reap the benefits of source control without sharing your source code with a corporation you might not trust.
That's exactly what I do.
In fact when I started out coding CIQ for fun, I simply did manual backups just like you, but I soon found that to be inconvenient and unwieldy. (In my day job as a software dev, I have always used source control).
Once my CIQ projects grew to a certain size and existed for a certain amount of time, using source control was almost unavoidable.
I find it very interesting that Jim always brags that he's been coding since 1970s (as if this is a flex), yet he disdains source control. Source control has been around since the 1970s, and I think even most coders who are far older than most of us swear by it (including those who are near retirement).
As an example of how not using source control has practical disadvantages, Jim often says that it would be pointless for Garmin to keep around ERA reports for old versions of apps (as many devs have requested), because "the source code could have changed since then" (his words, paraphrased).
The first time I read this, I was gobsmacked. Is he really suggesting that he personally has no record of old source code, no ability to build old versions of software or look at old source, and that he expects nobody else does either?
He's really worked in the industry for 40-50 years and he thinks this normal? How can you work in software for so long and not learn this one simple lesson which almost everyone else has learned.
I know people who've been working since the 1980s or 1990s who would be absolutely shocked at this attitude. Some of these people cling to tools which haven't been updated since the 90s, but at least they still use source control.
Anyway, it's up to you whether you want to use source control or not, but there's a reason that almost every professional in software development uses some form of source control.
I want to be in full control of my source control without any overhead. I can't remember using source control systems in the old days, other than shared Novell network drives and some agreements within the team on how to structure and use them.
Now I just don't want to learn new tools, I even don't like the popups etc in VSC that always seem to popup when I don't want them, replacing code when I try to get rid of them. Aids but no aids. Even Notepad++ went sideways and got over complicated over the years :D . So I just have my own way of managing my versions, bases, updates and backups.
The only thing not working is that somehow Garmin decided to break my old team rules, I lost my developer key in the past because the suggested directory is the worst thinkable to store non reproduceable files, and the temporary files are stored where I'd suggest to store the developer key.
At least I got rid of the overhead of Onedrive, so I'm getting somewhere, but indeed I don't have exciting projects, so for me it probably just is overkill.
Now I just don't want to learn new tools
I get that you mean specific tools that are new to you, but source control itself is not new at all.
Source control has been around since the 1970s. The original source control system for Unix - RCS - was released in 1982. Most people who were working in 1982 are now retired.
Git can be complex, but the basic concepts of source control have been around for decades.
The development of linux, which powers over 90% of websites and cloud infrastructure, would've been impossible without source control.
As matter of fact, Linus Torvalds developed git in 2005 as a response to the inadequacies of existing source control systems.
Can you imagine a huge collaborative project like Linux being worked on via devs just writing to a single shared drive with a few handshake agreements?
I want to be in full control of my source control without any overhead.
Use your own local source control server (such as git) and you are in full control. The overhead is negligible. You can use git through a UI (integrated into VS Code via an extension) or via the command line. Personally I use both (although I like the command line because it's more efficient and gives you more control).
You can back up the git repo and retain all the benefits of both backups and source control.
So I just have my own way of managing my versions, bases, updates and backups.
That's fine, it's your choice. You miss out on a lot of conveniences of source control that have been around for longer than many devs have been alive, like the ability to instantly revert uncommitted changes, easily see what was changed between any 2 versions, quickly switch between versions, annotate a file to see which lines were changed in which versions, etc.
With the use of source control, it's very easy to try out changes to your code, then revert them if they don't work out. You can even stash changes locally so you can bring them back later on.
Some of those things would not be possible or practical without using a version control system.
Once your team size increases beyond 1, source control is basically mandatory.
If you are managing your own versions somehow, I'd argue you're probably unnecessarily reinventing the wheel.
I can't remember using source control systems in the old days, other than shared Novell network drives and some agreements within the team on how to structure and use them.
Yet source control has been in common use all the way back to at least the 90s. Before git took over around 2010, some devs were still using CVS, which was released in 1986. The main successor to CVS was SVN, which was released in 2000, which again is before many of today's current devs were even born.
It's totally up to you what you want to do with your own personal projects of course.
Nobody working in a professional team environment would forgo source control today. Even 20 years ago, I think it would've been considered very bad practice to forgo source control in a professional team setting.
You think all of these ancient source control systems going back to the 2000s, 1990s, 1980s, and 1970s just existed for no reason, with 0 devs using them?
You think Microsoft acquired the product which became Visual SourceSafe in 1994, which they heavily integrated into Visual Studio, for no reason at all?
I even don't like the popups etc in VSC that always seem to popup when I don't want them, replacing code when I try to get rid of them.
You mean CodeLens, the inline (not popped up) annotations in VS Code?
You can disable those:
https://stackoverflow.com/questions/34356510/how-to-disable-codelens-in-vs-code
If you mean the literal popups, you can probably press ESC or disable them in settings:
stackoverflow.com/.../how-to-remove-popup-window-showing-function-definition-in-vscode
Even Notepad++ went sideways and got over complicated over the years :D
Can you ignore the new stuff that you don't like?
Maybe you could use Sublime Text instead, if you are looking for a simple, fast and powerful text editor. Both Sublime Text and Notepad++ are native apps (as opposed to being Electron bloatware, like VS Code and so many other modern apps). If I have to open a gigantic / unwieldy text file (like 100 MB with no line breaks), I def use Sublime instead of VS Code, as I know VS Code will probably hang for several minutes if I open it there.
Also, you can probably still use .gitignore even if you don't use git itself, in case it's somehow easier or more convenient than changing the setting that flocsy suggested.
It says a lot that VS Code looks at the content of .gitignore to determine which files to exclude from search (and from the explorer pane). It suggests that the use of git is a very widespread / standard practice.
Since you use notepad++, you must be on Windows. Here's a simple, self-hosted git server that I use on Windows (on an old gaming PC that I now use as a server).
