I will ask this in a more appropriate forum if needed, but it is related to git so I felt it OK to ask here.
I use EaseUS Todo Backup 2022 for creating backups of folders on my HDD to another HDD for disaster recovering. Should I include the .git folder(s) of my various projects as part of the backup?
Related
I use git to keep track of certain directories modifications, and to avoid file duplication or file inconsistencies. For backup, I store these directories on Github. Now, these directories are over 1GB, and I am thinking of taking them out of Github, but I don't know what is the best way to back up these files and still keep track of file duplication or file inconsistency.
I thought of creating a git server where I store all my repos. I thought of using complex scripts for rsync, or even using borg.
Do you have any suggestions?
I was working on a project in IntelliJ, where I put in some code to delete some files from my project. This accidentally deleted the whole project from the filesystem (Windows 10). The only file left is the .idea directory that probably stores some IntelliJ configuration. The Local History option in IntelliJ has been disabled ever since (which means it wiped the Local History of this project), so there is no way of recovering the project via Local History either.
I used recovery programs like Recuva and EaseUS which for some reason didn't recover the lost files (EaseUS in particular shows files from 2 or 3 days ago instead of today).
I also doubt I can recover these files via Git since Git does not use a single file to store its history.
Any suggestions?
I am attempting to share a file that builds and populates an SQL database through git, but it won't create the DB on my team members' machines because the .mdf and .ldf files are located on my machine. How can I rectify this?
If you want to share a SQL script, you don't have to share the database with it!
What is generally done (best practice) is that you have the script needed to create the database (and eventually populate it with static/test data) in git, and then the user will launch that script to build the database.
git is here to keep track of your source code and the changes made to it, you shouldn't put in it any generated file, and .mdf / .ldf files are typically part of what should not be in your git. For generated files within your folder, there are ways to configure git to ignore them.
The value of git is to record differences between files, if you want to share your software, git is definitely not the good tool. Put those file on a shared folder (NAS), on dropbox, give them through an USB key or whatever.
However, if you really want to do this (bad idea), I guess you can add your files in your repository and either configure SQL Server to find them here or create a symbolic link.
I'm using Trac 0.12.2 that came as a part of Bitnami Trac Stac.
I am very new to Trac & just started with Trac, working with a local repository on a desktop a few weeks ago & created some issues. Now I wanted to transfer the all those issues onto my new Trac installation on another desktop. So I simply tried replacing the empty(I believed) database folder of new installation with my old Trac DB folder.
Specifically this folder:
C:\BitNamiTracStack\repository\db\
When I tried doing so, the admin tab on the trac interface disappeared.
Also I got a message:
Warning: Can't synchronize with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information.
How do I successfully transfer my issues from one desktop to another ?
Check your installation and find the correct directory called 'Trac environment' as per Remy's advice.
While his answer is the safe road and general advice without doubt, you may still succeed with a less complete transfer, depending on what you already put into the Trac environment in question. Assuming you do use BitNami's default Trac db backend (SQLite) you'll need at least
the latest db named trac.db from the db folder
the configuration file conf/trac.ini
If you've worked with attachments to tickets or wiki pages, the whole directory structure below attachements is needed as well.
Other things might not have been touched by a self-declared "very new" Trac user within the first weeks. Of course a diff -Nur <path_to_old_dir> <path_to_new_dir> | <your_favorite_editor> will remind you of anything you may have already forgotten.
You shouldn't copy the database alone, but the complete Trac environment. That's the directory containing the attachments, conf, db, htdocs, log, plugins and templates directories. In your case, this seems to be the directory:
C:\BitNameTracStack\repository
(I'm not familiar with the BitNami stack, but the name "repository" sounds suspect. I hope they don't put the Trac environment below the Subversion repository.)
See the official Trac documentation on backing up a Trac environment and restoring it. You should be able to use this to migrate your config to another server.
I've started using git-svn for an SVN-based project, so that I can make local commits.
However, the SVN repository contains a lot of directories that I don't need to work with. When I solely used SVN, I was able to partly check-out stuff with:
svn co <repos-url> --depth empty
and then update the needed directories:
svn up <repos-dir>/<subdir>
As far as I've understood, partly checking out a project isn't an option with Git, so I'm looking for alternative way of saving some space. Any suggestions?
Edit: what I am thinking myself is something in the lines of creating a branch thatonly contains the files I need. I'd then want to be able to push the changes to these files without pushing any removal of the files I don't need. But I am not too deply into the way Git works to figure out if this is possible?
Are the extra directories really that big? One advantage of Git is that you do most of your work from your local harddrive (you commit to your own branch, not to the server) so it's fast even when there are many files.