I recently updated one of my long-term projects from 2017 LTS to 2019. Instead of updating the original project, I made a copy of the project folder, adding “2019” to he name.
That worked out pretty good because I ended-up having to delete my new project folder and start over a few times. I totally screwed up all of Text Mesh Pro stuff trying to convert to the new Package Manager version. Also discovered the the LWRP was not going to work for my project (delete and start over again!).
Still, it only took a few hours to successfully update my project and I still have the original 2017 LTS version in case I find any more trouble down the line.
I hope you use GIT for full control. Though even with git you need to have each version in its own folder. Becasue rebuilding the Library each time you switch branch is a pain
I might be old fashioned, but using GIT or other similar services like BitBucket for source control is really great if you work in a large team, or are extremely careful about losing progress, but I tend to just make .RAR file backups every few days or so, upload those to somewhere online like google drive or dropbox, and if something goes terribly wrong, just go back to those archives and manually switch things back over.
I get the advantages of source control and how you can compare diff of updated files, and all sorts of awesome features - but is that really necessary if your a small team or an individual working on a project? Not really… in my case. I’d say just use whatever works for you, but make sure to keep a backup, on multiple hard drives, flash drives, cloud services… somewhere.
Anything is better than nothing. But a proper version control system is the best. You can just push and pull the whole project if you want (like you do with the RAR files), but you can have fine grain control if you need it and merging by hand is nearly impossible in majority of the time, but usually not with a version control. And that’s actually time saver. (Most of the time… there were times when I wasted long hours on a merge… but it’s not the norm)
I also do the same, except that I don’t trust cloud services that much. I use one though, Mega (so far, so good). Also, all my projects are installed on an external drive, and I use Windows backup everyday. Windows backup saved my life a lot of times in the past.
I didn’t use real version control, just backup copies of the whole folder, until I was working as part of a team. Then I wanted to go back in time and slap myself, because it’s such a big improvement to my workflow, even for solo projects.
I’d say the largest advantage is for code - refactoring becomes much more painless, it’s no longer necessary to keep commented-out code around “just in case”, and when something breaks but not immediately, you have a history record to track down where exactly it was introduced.
For non-mergeable assets like art, the advantages aren’t as great, but I’d say it’s still better than manual backups, and not difficult to set up.
It took forever when I was still doing it (eventually I just set up an automated process for git instead) because Unity projects are full of loads of small files, which are kind of a nightmare when dealing with in volume. At this point though, even for local solutions, there’s no reason not to use some form of version control.
I get how doing the backup thing may seem easier on the surface, if you haven’t used version control before, but it really isn’t, especially when you need to back out or revert something. Pulling one (or a few) files out of an archive can be messy and super slow. If you are creating multiple archives, simply finding the changes is going to be a pain. If you are using it as more of backup than version control and replacing your archives, finding an old change may not be an option. Backing up is, as said by others, better than nothing, but using actual VCS is more efficient, robust and a practical skill set. There is literally no reason not to do it on any project that are planning on putting more than a few hours into.
I wholeheartedly believe in version control. Don’t get me wrong. But I think the “make a flat backup, try upgrading the major tool system, experiment a bit including fixing quick errors, and if it’s gonna be hell to accept the upgraded major tool system, just go back to the backup” approach is a fine approach. In fact, if a second machine or a second user account on the same machine is available, I would use that as my trial area. I feel there’s not enough good reasons to risk polluting the original version control repo with a bunch of little migration experimental changes.
But in any case, do not upgrade major tools on your only copy of a project. Or as they said in the 80s, “always mount a scratch monkey.”
Or better yet just make a copy of the project folder, delete the library cache in the copy, and open it in the new release you want to try out. Worst case if anything goes wrong you’re only out the time to create the cache for the new version, but if you tried it on your working copy you’d be out the time to make the cache for the new version and the old one.
If you know what you’re doing there is zero risk of polluting anything.
If you’re using branches, then just make a branch and only commit new version stuff to that. If you decide not to carry on, stop using that branch… and that’s it.
If you’re not using branching (which I think is fair enough in plenty of circumstances, particularly for newbies) then simply don’t push any commits back to the repo until you’re happy with that new version. Locally, you can still commit / revert / whatever as much as you like, and it will do nothing to the contents of your repo.
Indeed.
For me, doing a commit and push typically takes in the vicinity of 30 seconds, and that includes writing a comment and double-checking the contents of the file list. That logs my work locally and pushes it to a remote server (thus doubling as a remote backup) in less than the duration that most computers will spend just locating files to put in the archive.
If I ever have to go back and get something from an old version then the productivity boost of version control is even bigger. I can right click on any text-based file and pull up a log of all changes to it, ever, by anyone. If I want to go back to an old version I pick one from the list and click a button. If I just want to look at its contents I double click it and it pops up in an editor with the differences highlighted. I can also easily see what other files were changed at the same time, and the changes made in those. And through all of that I don’t have to navigate through archives or find files or extract anything.
Also, because version control only saves the changes it usually takes up very little disk space. Archives re-compress the whole project every time you make one. Version control identifies only what you’ve changed, and saves (with compression) just that. My entire version control history for a project is usually less than the size of the project itself.
Working locally you get all of that except for the remote backup. The tools are free.
My favorite advantage is things that you don’t commit. (Or at least don’t commit to the main branch). You can have a lot of stuff in a half done, broken state, and yet still have a project that will compile and release.
I sometimes use it to revert everything but the actual stuff i’m interested to commit. I use this all the time for code, remove noise changes like blank rows etc, its very nice to look at a git commit that actually only consist of lines that have changed. Most devs dont care, I always give my developers a hard time at work if they commit noise. Anyway, some times I extend this to scene files etc. For example, I ony want to change the rotation of a transform in the commmit but something else have changed too my mistake.
Btw, never refactor and commit new domain code in the same commit. Make two commits
@angrypenguin Have already touched it, but use branches, since git is distrubuted its super easy. You can even create a branch mid through a story and move to that branch before committing. You can even kit bash a custom branch by cherry picking commits from several branches. I use this sometimes when I want to let our testers test something in beta (usallyt a POC that I want feedback on).
I usually wait until I’ve made some major change, like refactor or rewrite of a large script, then just RAR up the whole project file (although, the library and stuff doesn’t need to go usually, it could just be the assets folder).
Then I’ll distract myself with some other work a while, and if the project isn’t huge (mobile projects of mine don’t usually end up over a couple gigs) it only takes a good 10 minutes or so, and finally I upload usually to at least one cloud service for my own sanity, in case I drop my laptop bag and destroy my external and my solid state in my laptop through some gifted moment of drunken-ness or something
Oh and another thing, is if unity is open while you do it, winRar complains about the unity lock file, but its safe to ignore it and just let it go through without including the locked files.
And for the record I’ve also used the source control stuff before, and yeah it is solid, and really awesome for comparing code when you have suddenly broken something that seemed to work fine before. I just don’t think it is necessary if your a solo act most of the time…
The only folders you need to backup are /Assets/, /Packages/, and /ProjectSettings/.
If you have a total loss, you can still recover completely by opening a project with these folders in it. You don’t need Library, unity just rebuilds it when you open a project that doesn’t have it.
Collaborate is hella easy too for super basic versioning. Just click the button and everything is backed up.
