Important tip when using Xojo, version control, and macOS

If you use any VCP (git, svn, cvs, etc.), and try to track local changes where you use mv to rename your project folder in a terminal, be aware that Finder is tracking that move if you are using 10.12 or newer macOS. This means that if you are used to loading your project from the “New Project” Recent items pane, be sure that you verify the path of what Xojo loads.

I just spent 3 days tracking what I thought was an issue with SVN that was actually Xojo being provided with the “new” path of the renamed project folder - even though I’d renamed it 3 times >:( . I’d ‘mv’ the folder to “project_reset”, re-checkout the project to “project”, tell Xojo to revert to saved. Old revision loads. Quit Xojo, select the project from the Recent Items - old version loads. Rename “project_reset” to “project_bad”, checkout “project” again, quit Xojo, open from Recent Items - bad version…

Even though I was using “mv” from the Terminal instead of renaming in Finder, Finder was STILL tracking the old folder even though I’d replace the original folder with a folder of the same name.

Moral of the story - if you rename an existing project folder and replace it with a folder of the same original name, by sure to use “Open existing” instead of Recent Items to load the NEW version of your project.

If I could bill Apple for every lost hour that has been caused by their smarter-than-thou operating system, I could stop working.

[quote=437555:@Tim Jones]Moral of the story - if you rename an existing project folder and replace it with a folder of the same original name, by sure to use “Open existing” instead of Recent Items to load the NEW version of your project.

If I could bill Apple for every lost hour that has been caused by their smarter-than-thou operating system, I could stop working.[/quote]

I could be wrong, but isn’t that exactly how macOS is supposed to work?

If I imported pictures into PowerPoint on Windows and then moved the pictures folder, then the presentation lost all its pictures. Windows did not track the files.

On the Mac I could move the files or even rename them and they still display fine.

That goes back to even before the first OS X version.

If you are treating it as if it is Windows then you’ll run into problems of your own making.

I agree that IF I did this in “Finder” it would be expected and I do expect it; I don’t agree with it, but I know it happens - in Finder.

This is why I pointed out that I did this in the Terminal using the BSD command line tools (‘mv’ specifically). Finder did not previously track changes made in this manner (that were not made in Finder).

[quote=437560:@Tim Jones]I agree that IF I did this in “Finder” it would be expected and I do expect it; I don’t agree with it, but I know it happens - in Finder.

This is why I pointed out that I did this in the Terminal using the BSD command line tools (‘mv’ specifically). Finder did not previously track changes made in this manner (that were not made in Finder).[/quote]

And I would content that finder should have tracked it before even if moved in the terminal. That was likely a bug in terminal, and it is now consistent with what macOS does.

The question I have (not on my computer) is as moving and renaming the file is not what you want to achieve whether there is a duplicate file command in terminal (to again make it consistent with macOS)

I expect the terminal experience to be on par with other Unix experiences - and it was until 10.12. If you want to live in the GUI world, that’s great and it works well for the largest percentile of Apple’s customer base. However, there are some of us that live with the Apple dumbed-down GUI experience because business dictates, not because we appreciate it or need it. The fact that Apple provided the Terminal environment for those of us with a bit more system-level experience was a plus. Now, they are taking that away as well.

My point is to watch out if you’re NOT used to that dumbed-down, Finder experience. It can cause unnecessary frustration.

Tim, please don’t use “dumbed down”. It’s derogatory and doesn’t reflect well.

Furthermore the problem is not with the terminal. It is with the Git app which is after all a GUI app. The Git app could have been programmed to NOT use the file tracking way (and for example my original RecentItems menu did just that), but that again causes all kinds of other problems (like when a RecentItem was moved or renamed, so I quickly learned how to do it properly).

So your complaint is that you use the terminal but the Git app on a Mac supports the macOS file tracking.

If you want to muck around with the terminal and ignore what the Git app is doing then that is your prerogative. But then you run into the problems you describe.

isn’t that what FolderItem.GetSaveInfo supposed to do? In my understanding it’s not the Finder oder mv that is doing anything special here, but the Application that is referencing the Recent Item by other means then the absolute path. At least on HFS there are quite powerful ways to do this and I’d count that rather as a Feature then a Bug and expected behaviour for Mac Applications.

What? I do not mention git in anything above. In this case I’m using the Terminal and svn, not git - and definitely NOT a git GUI app.

No, my complaint here is that I used a function of the command line environment that used to ignore the Finder oddities (and I don’t care WHAT the Mac is “supposed” to do, just what it did for many years).

Since I don’t write the Xojo IDE, I don’t have control over what they call. As I mentioned, I’m comparing what happened recently (and cost 3 days of troubleshooting) against what used to happen when I manipulated file locations outside of Finder. Additionally, even Apple’s own tools get hit by this. If a customer moves your app to the Trash and doesn’t empty the Trash, when they install the update for your app, Apple’s installer happily installs your new app version into the Trash instead of Applications. The user uses your app and then empties their Trash to find that your application is no longer installed. Guess who gets blamed? I’ll give you a hint - it’s NOT Apple.

Guys, I’m not asking for an explanation as to what is happening. I know what is happening. It’s just another example of Apple’s inconsistent platform and Apple’s disregard for common sense documentation practices. Regardless of which way is correct, they made a change and, in normal Apple style, did not document the change in a useful and obvious manner.

Oh, and my point was to be derogatory in my dumbed-down comment. I don’t find my wasted time to be simply “oh well”. I’m also definitely NOT happy with the way that Apple treats developers in situations like I describe.

Apple likes to make changes as confusing as possible. I also had fun with the installer and think that installing into the trash is a wonderful wonderful idea. Especially, when I’m writing an installer myself that needs to install into the Library folder anyways.