Hey all,
I’ve suddenly found myself in a position where I’m going to be working with several other people on my software. Up until now it’s just been me and I’ve just been saving my code in the default project format. Now I need to need start sharing my projects with my colleagues who are using BitBucket.
Having never used repositories, etc. I’m lost. So new learning curve. Can anyone point me where to go, what to do, etc?
First check YouTube for XDC talks. You should be able to find the excellent ones by @Justin_Elliott .
Get a copy of SourceTree rather than using the command line. It’s not the greatest interface, but you’ll see what’s going on better than if you use the command line.
If you want a few minutes tutorial via Zoom, I’d be happy to help.
And then start using version control for your own projects too. It will change your life for the better.
You will need to save in the text format to use source control.
My favorite git desktop application is Fork, I would recommend it if your colleagues are going to be using git on BitBucket.
Take Kem up on that Zoom offer. I find it much easier to learn source control when someone can answer your immediate questions.
Thank you for the zoom offer. I might just take you up on that. Let me at least get my account created on BitBucket and start getting some things set up initially.
When I first got into version control, I was hesitant to commit stuff. I was treating that kind of like a build, where I had decided the code was ready to ship so it’s time to call the version done. It’s not like that at all, so don’t be afraid to make commits. Something committed is permanent, so it’s a great way to make checkpoints. You can undo a commit, but it does that by making a new commit to reverse the changes. You can’t lose code you’ve committed, so do it, and do it often.
The other feature that will probably scare you at first is branching. When I started versioning with SVN, branching was (and I believe still is) a total pain in the ■■■. That’s not true under Git. Minor changes don’t really need a branch, but if you’re going to be working on a new feature, create a branch for it. This keeps the code out of your production main/master branch until it’s finished and ready. Then you can merge the code real easily. You can branch from a branch even. My master branch is for production, then I keep branches for the major versions that only get merged into master when they ship.
Get into these habits, and git will change your life.
Definetly a +1 from me. Easy to handle, easy to learn.
Yeah. Don’t be affraid of it. Once you are familliar with it you will never want to go back. 
Hi all -
The Git webinars that I did a few years ago are linked to here, which are still very relevant:
https://documentation.xojo.com/resources/videos/webinars.html
Getting to know Git, Part 1: Getting to know Git, Part 1 - YouTube
Getting to Know Git, Part 2: Getting to Know Git, Part 2 - YouTube
If you subscribe to XDev Magazine I recently wrote 2 articles on using Git with Xojo, which starts with the essentials and covers a bit of advanced topics too:
Get Ready for Git (Part 1): Article 18604: : Get Ready for Git (Part 1)
Get Ready for Git (Part 2): Article 19105: : Get Ready for Git (Part 2)
Hope this helps!
Other topics you might find useful:
Do yourself a favour and use one of the other recommended clients. This one has fundamental issues that’ll end up tying your project in knots and you’ll drop hours and hours trying to fix it then discover an issue thread going back 5 or 6 years relating to it. Still not fixed AFAIK.
Atlassian should kill or fix it.
For the record, I’ve been using it for years without issue, but it does take a certain level of understanding of what’s going on in the background, and the “right” way to do things.
Having said that, Fork looks promising.
I see them active:
Windows:
https://product-downloads.atlassian.com/software/sourcetree/windows/ga/ReleaseNotes_3.4.5.html
Mac even more:
https://product-downloads.atlassian.com/software/sourcetree/ReleaseNotes/Sourcetree_4.1.2.html
Thanks, everyone. We managed to get my project into the repo today and so we’ve made progress! Fortunately, one of my new project colleagues has been working with git for a while.
This was totally unexpected, but when the owner of the company who’s product your software is designed to work with says, “We are going to make your software the default platform for controlling our product. We want to give away a version of it to whoever wants it, but we will pay you for every copy. You and my team can work together to make it an even better product…”, it changes your world a bit…
Now I still have my own company and product but it’s not just me any more. Now they get to learn Xojo and Xojo has a new customer…
OK…Now a new question…
I have a bunch of PNG or JPEG files in my app. These have literally been scattered throughout my computer. Prior to creating my repository, I did a “gather project items” and saved everything to a single folder. But the image files didn’t get saved to the repository location. How does one handle those? I suppose it’s covered in some documentation somewhere… I can see a “pictures” folder in the folder where I did the “gathering” and the pics are all there. But they did not make it to the repository for some reason. I suppose copy them there and commit and push will do?
And then this brings up another one. I have several external objects in my project that are shared with other projects. But now those external classes are not in the repository either. I would have thought that “gather project items” would put them all in the folder, but it did not. So how does one deal with external objects that are shared between multiple projects, especially when not all my projects are in the repository yet?
Create a separate repo just for the External objects.
It’s not unusual for a large project to be managed in more than one repo, regardless of the language or development platform.
Thanks, Scott. I was wondering if that was what needed to be done. Guess I just need to break the links between all the “old” file locations and then force Xojo to locate them in the new places…
External items in Xojo’s version control suck. Combined with git submodules also sucking, you’ve got a perfect storm of awful. I’ve tried many different options, including a package manager that would edit the Xojo project automatically. In my opinion, the option that sucks the least is just copying project items between projects. It feels dirty saying that.
It does feel dirty but I was wondering if that’s what I needed to do. But it seems like it makes the use of repositories useless or hard to track. Then I have to remember to manually copy any commits that made changes in one project into all my other projects…
And Ugh! I have a ton. I have to now go through and convert every single one to a text based format…
And looking at this all, I think it just might be easier to be “dirty” as you suggest, Tom…
That’e the situation where using external xml items really works so much easier than using the text based project format. And xml is much faster. You just get a bit wonky when editing external windows .