Source Control SVN Question

Use conditional compile directives.

#if TargetWin32 Then
    // Windows specific code here
#EndIf
#If TargetMacOS Then
   // Mac code here
#EndIf

No.

Thanks, Tim. Yes, I understand that. I just always thought it was easier to work on two separate files since I would be developing and testing on OSX and Windows independently of each other anyway…rather than creating the Mac version while on Windows and just going over to the Mac for testing. Especially because in my experience bugs appear using the exact same code and interface on one OS and not the other…because of the peculiar perks of each system. But from what I’ve heard so far from this thread I guess if you’re using source control then keeping the single project file would make more sense.

So in terms of the trunk and branches…let’s say we’re working on the first release on the main trunk and then on release day we add a tag 1.0.0 to that commit and then continue working on the main trunk…which will eventually become version 2.0.0. Then a bug comes in on the first release…I assume you can go back to the 1.0.0 tag and create a branch from that point or do you have to create it at the same time you tagged it? Also, once we fix the bug with some code, is there a way to just merge that particular fix back into the main trunk but continue the branch as a separate entity for 1.0.2 etc? And even if you can merge a specific fix…what if that fix conflicts with or dramatically changes some of the new code you’ve written on the main trunk?

Absolutely keep them in the same project. In 15 years of doing Xojo development I’ve only had to worry about keeping two separate files for the same thing…never.

Keeping separate codebases for Mac and Windows sounds like a nightmare, and is kind of violating the “prime directive” of Xojo.

Most of us do something like this:

  • Keep a single project per app
  • Inside the app, when needed, use #if TargetXXX to special case code.
  • In some cases, where the OS-specific behavior is just completely different, I will make separate modules or methods, e.g. FoobarMac() and FoobarWin().

For debugging, I do 100% of code development on Mac, and then test using

  • Remote Debugger to a Windows VM
  • Actual builds that are moved to a Windows box (either VM or real metal)

I’ve never used the Windows IDE at all.

I have. It’s a painful experience, IMO, when you’re used to the Mac version. I have pretty much decided that it’s worth the pain of doing remote debuting rather than using the Windows IDE.

Thanks, Michael. The idea of creating separate modules for OS specific stuff if absolutely necessary is a really good one.

I’ve always been a “Windows” person but that’s just because I started out on PCs and MS-DOS. That said, I love the Mac and my Mac devices and basically do my every day work on the PC side and just switch over to the Mac side to develop and test the Mac stuff. But going by what you and Bob say it may be worth switching it around since I do already have Parallels VM.

Would still be helpful to get a few more pointers on the above.

And I slightly disagree with Tim’s comment about not creating a separate branch for when updating a project to a new Xojo Release. So long as you can merge it back into the main trunk I don’t see the disadvantage. Unless I’m missing something?

It just shouldn’t be necessary. Remember, source control will keep a full history of all changes to your project. So definitely get your code checked in before upgrading to a new Xojo version, but don’t bother with anything more. Once you open your project in the new Xojo version, just keep working as usual. Files that need to be changed will be changed, and you can see exactly what did change, line-by-line. If something goes wrong, you can not only see exactly what it is, but you can fall back to the previous version.

The branch is just unnecessary, it doesn’t get you anything you wouldn’t already have anyway.

Thanks Thom. I have another question about repositories…

I am currently starting out with Beanstalk on their free 100MB plan but it seems without doing hardly anything I’ve already used up about 56% of allocated space (probably mainly images and resources files) and if I needed more down the line their cheapest plan is $15 per month.

I’ve found CloudForge which gives 2GB for only $2 month and wanted to know how easy is it to migrate from one repo to another and if I think I might need more room would it be wise to do so now at the start rather than further down the line?

And if anyone has any other recommendations for cheap and good SVN repos I’m all ears!

Migrating between repos may or may not be a pain. Depends on the export/import capabilities of the services. Personally, I’d try to avoid the hassle.

Assembla has free SVN repos with 1GB of space.

And if you want to consider Git instead of SVN, BitBucket is quite nice.

You can always have your own server like we do with about 2TB of available space… But, the “down side” of that is you’ll have to manage all off-site backups and whatnot.
It’s a preference :slight_smile:

I have been using RepositoryHosting now for about two years with no issues. You can use SVN, Git or Hg repos. For SVN only I have found RiouxSVN where once of donations get you extra space.

It really depends on what you mean by migrate… Simply moving the current trunk to another SVN involves exporting the working copy and copying it to the new working copy for the other SVN then checking it in. But you loose all the history.

I’ve never come across anyone moving an entire repository plus history. But I doubt any of the online repo vendors would support it, as it would be a very time consuming exercise.

[quote=253739:@Denise Adams]Thanks Thom. I have another question about repositories…

I am currently starting out with Beanstalk on their free 100MB plan but it seems without doing hardly anything I’ve already used up about 56% of allocated space (probably mainly images and resources files) and if I needed more down the line their cheapest plan is $15 per month.

I’ve found CloudForge which gives 2GB for only $2 month and wanted to know how easy is it to migrate from one repo to another and if I think I might need more room would it be wise to do so now at the start rather than further down the line?

And if anyone has any other recommendations for cheap and good SVN repos I’m all ears![/quote]
You are early enough that you probably don’t have a history to preserve, so simply getting a new repository and adding your content to it should be fine.

It is easy to migrate histories with Git, but Subversion… I can’t think of how it would be done without access to the files on disk. Not saying it can’t be done, I just can’t think of it.

Thanks guys. Very helpful. Assembla looks promising. I need to check all these out. I have a Synology NAS but as Albin states I’d stll need to manage backups and would prefer to know everything is safely off-site somewhere.

I think that right now would be the best time to move since I’m still just starting out and haven’t really committed anything major yet.

Last issue I need some advice with and then I promise I’ll leave you all alone…for a while :wink:

For newbies like me just starting out with SCM here’s a link I found very helpful:

http://weblogs.asp.net/bsimser/day-to-day-with-subversion

This article proposes keeping the trunk clean and doing most of your work on the branch, then bug fixing on the trunk, merging those fixes into the branch and then later merging the branch back into the trunk for the next release.

While the logic and methodology makes sense I think I would rather do most of my work on the trunk, tag releases and probably only create branches for releases and “major” features and then merge back into the trunk.

I am using sourcetree with my own vps with git
I have same project run linux, windows, mac

All is perfect

What is the best practice when working with “branches” and your local working copy?

If you need to make a change in a branch should you just “switch” your local working copy “trunk” to that branch…make the change…commit and then switch back to your trunk?

Or should you “check out” the branch in a new directory so you effectively have two local working copies on your machine… the trunk and the branch?

Do developers sometimes keep two local copies in this way if they are continually making changes to their trunk and a release update branch for example?

You can check out only one copy of a Xojo project for the simple reason that Xojo paths are absolute. If you try with 2 checked out copies Xojo gets completely confused. Even checking out to a different computer it doesn’t work because of these absolute paths. This is such a PITA.

What?
I work on three different computers and there’s no problem.

Can’t verify this atm. Are you sure about this?