I have been using SourceTree for about a year now and have suffered from a few errors that have been difficult to recover from - the latest being the entire history for the last 6 months going down the pan - even trying to recover from old versions via TimeMachine and Crashplan have not resolved it. The errors have usually occurred when trying to check out an earlier version (e.g. to get some old code) and then reverting back to the current version. Which raises a few questions about how other’s use their GITs to both enable workflow whilst not exposing yourself to catastrophe.
For example - do you keep one GIT log for all time, or do you chunk it up so that you start a new repository for each major new version?
On a not unrelated question, I have noticed that Sourcetree keeps on including new versions of all the dylib files in each commit. This results in a massive blooming of the size of the repository (e.g. over 1G for an app of less than 100M) - which might well have contributed to my crashing problems. I know I could use gitIgnore but this would then prevent those dylibs being recorded when they do actually change (e.g. when upgrading plugins etc).
I wouldn’t expect to see the dylibs included in each commit, as they are not actually changing. Is there a setting I need to change somewhere to prevent this happening?
My Global ignore file looks like this
*~
.DS_Store
.xojo_uistate
Builds.xojo_project
Sourcetree/Preferences/Git/Global Ignore List
As far as the rest of it. I use it but am still struggling with the same things you bring up.
Our git history goes back to the beginning of the project and we have not had any issues that we haven’t been able to recover from. We use the GitFlow workflow (subject of a recenter conversation here and a Xojo blog post) and do all work in branches, so perhaps that’s the difference.
As for the problem of changing binaries, we encounter the same with encrypted classes. I deal with it by “resetting” these changes when I know the item hasn’t really changed. Another way might be to put them into a submodule and reset or commit them there.
Git recently introduced tools for dealing with binaries and I expect that will make its way into SourceTree soon, or soon-ish.
Thanks Kem - I’ll try gitflow again - though I think that was actually the cause of my earlier problems with SourceTree.
In general I feel very vulnerable using git as all my changes and history are logged in one log file - any corruption (which I’ve had a couple of times) puts all my history down the pan. I am working for the most part as a single user - so no need for online copies of anything - so breaking the repositories down a bit into different versions gives me a little more confidence and smaller repo files.
Peter - thanks for the gitIgnore - useful.
GitFlow handles the versions for you too via tags.
I can’t speak to your experience, naturally, but I haven’t had any of these issues either in the larger, team projects or my personal projects. If you are experiencing constant corruption, perhaps there is another, system-related cause? Are you saving the project to a Dropbox folder or the like?
Kem - no I’m just saving the files in a folder on my hard disk. I wouldn’t call it constant corruption - but about 2 significant events in the last year - just enough to make the knees wobble.
The errors seem to occur when I check out an earlier version, then re-check back to the current version. I close the project in Xojo before checking out each time, but was wondering if perhaps there is a time lag or something as the old version is restored that might cause problems if re-open the files too quickly.
I haven’t noticed that, but the worst that should happen is that the project doesn’t open (or open properly) on the first pass. If it does open, and you save, you will see all sorts of changes in SourceTree that could be reverted.
Perhaps it would help to define the events you experienced in more detail?
I’ll post a more detailed experience next time it happens - hopefully never - as certainly get more information back on this forum than on SourceTree’s own.