I’m starting out using SVN for my current project using Xojo 2013 R3.3.
I will compile on both Mac and Windows so decided on SmartSVN because it’s cross-platform.
My first question is: do I need to use the same desktop SVN client on Mac and WIndows or just connect to the same repository? Like Beanstalk? And since the Mac version will need to change control positioning and windows dimensions for HIG etc should I create a completely new file/repo or just a new branch?
Secondly…Even if using a remote repo does the client SVN still store the same data in a local repo?
Thirdly…
I intend to update to the latest version of Xojo (when I’ve got everything working in the current version) and am holding off because I know upgrading versions always requires a lot of work and sometimes breaks your code and takes time trying to modify it all. Especially for new methodology and framework like the new way of handling grahics drawing ONLY in the Paint event etc.
So when I do upgrade to the latest version of Xojo, what’s the best way to handle it through SVN?
Do I create a tag/label for the exisiting version and then the new version or create a new branch?
And would the chosen solution be the same for when releasing minor updates and/or major new version releases of my own app?
I can only tell you my workflow, perhaps it will give you some ideas:
For me the version number is the driver, I have three number groups as in 8.172.3489 or Major, Minor and Release. To work together the application and the database must have the same Major and Minor version numbers. Thus the Release number can represent bug fixes in either the application or the database, where as a new Minor number represents a change to both.
This then gives me a Current branch, which represents the next Major release and where most of the work is done, plus a series of Major/Minor branches such as 8.172 which represents the product shipped to clients and tags representing Releases on those branches.
When a bug is reported I fix it in the Current branch, merge the fix back to the branch on which the bug was reported, tag it and ship it. Once all customers have migrated of the branch I delete it.
In addition to this I have a number of feature branches including branches for testing upgrades to the most recent release of XOJO and the betas.
Thanks, James. Interesting to know your workflow but I’m still a little confused and need a little more clarification.
Firstly, let’s say you start with 8.001.0000 as the first project saved in your trunk.
Then you work on it for a week and commit each save…8.001.0001, 8.001.0002 for each save etc?
This all falls under the same working branch and same filename…or do you actually change the local filename too?
And then say a customer reports a bug and you fix it in 8.001.0011 (for example) I assume you tag that? What would you name tag it? Bug fix and date? And then you continue working on that same (single) current working branch.
But then you decide to implement a new feature … do you create a new branch for that feature and then start working on that branch or do you just tag the new feature and continue on the original branch?
So lets say you create a new branch for the new feature and continue working on that second branch for a week…I assume you increment as you did before so no we’re at 8.001.0030? Or do you change the minor and build version number for the new branch?
And where do you name the version number? Does the SVN client handle that or do you do it manually outside of the client?
And so finally, you’re now working on the new feature second branch and another bug comes in…where do you fix the bug … in branch one or two? And when you’re done with the new feature, do you stay on the second branch or merge it back to the original one?
Sorry if this all sounds stupid but source control is all new to me and I’m used to pad and pen and just re-naming my binary project file.
You create your repository in SVN, check out a local copy - empty folder
You create your project, save it the folder, check it in etc
You work on the project for sometime checking in as you go along.
You have done enough to ship as version 1
You create a new branch from trunk as 1.0
You create a new tag on branch 1.0 as 1.0.0 and ship it to your customers
Someone reports a bug, you confirm it on trunk and fix it
You merge the change back to branch 1.0, tag it as 1.0.1 and ship it
While working on version 2.0 of your product (trunk) you identify a flaw in the product which involves a both Db and App changes and should have been part of version 1.0
You make the changes in trunk
Now you create an new branch from 1.0 (not trunk) and call it 1.1
You merge back the changes from trunk to 1.1 needed to fix the flaw, tag it as 1.1.0 and ship it as an upgrade
Now lets assume you need to upgrade to a new version of XOJO:
You create a new feature branch from trunk
Do the upgrade work on feature branch
Once tested etc… you tag trunk before applying the upgrade code and merge back the feature branch to trunk
If work has continued on trunk while the upgrade was going on then it can be come a bit of a challenge, but that is life
I don’t normally upgrade old branches but if for instance you needed to upgrade say branch 1.1 then I would create a new branch as 1.2 from branch 1.1 (not trunk), do the upgrade, tag it as 1.2.0 and ship it as an upgrade.
Note that this has nothing to do with the revision numbers etc… in SVN. It is just how I have chosen to use SVN.
And in terms of naming the build/version number (8.001.5467 etc) how can I do that and view it within SVN client or repo browser?
Because I’m saving over the original project file every time the file name stays the same and all I see in the SVN client and repo log is its own revision number.
You do not need to use the same client software. You only have to connect to the same repo.
I’m not sure I follow here, but if this is the same project then it would be the same repo. If you need to adjust your UI specifically by platform, then considering doing that in code or having alternate layouts (ContainerControls?) in the project. Having separate projects/repos sounds like a nightmare to me.
Subversion stores all changes in the remote repo when you commit, so I’m not sure what you mean. You’ll need to Update from each repo regularly to pull down the latest changes from the repo server to each local repo.
[quote=253040:@Denise Adams]So when I do upgrade to the latest version of Xojo, what’s the best way to handle it through SVN?
Do I create a tag/label for the existing version and then the new version or create a new branch?[/quote]
You could tag the stable version and then do your upgrade. This allows you to pull out the tagged version easily if you need it.
You could also create a branch for the stable version and use the trunk for current development, including doing an upgrade. I think this is probably more common as it would enable you to still do updates to the old version. In general, upgrading to a newer version of Xojo is not usually a big deal (unless you wait several years between releases, of course).
Subversion can be used any number of different ways, so you’ll have to decide what will work best for you.
I can highly recommend to use an advanced GUI Driven Client for all this, if you are not familiar with SVN/Git. I do not have the time to dive deep into this SVN/Git stuff and use Tower 2 for Git and Cornerstone for SVN. Both are well worth the money. Both saved me a lot of time (and trouble)
[quote=253095:@Denise Adams]
And in terms of naming the build/version number (8.001.5467 etc) how can I do that and view it within SVN client or repo browser?
Because I’m saving over the original project file every time the file name stays the same and all I see in the SVN client and repo log is its own revision number.[/quote]
Well like I said I operate my version numbers completely away from what either XOJO or SVN offer as default, so I don’t really care about this. When checking in changes I use the message field as follows:
Issue-No: Short Description / Changes made
So for example a check in message might look like
“102: Additional email field for Customer / Changed Customer table DDL by adding additional email field to table”
That way when in look in the Repo browser I can see what was done on each check in and which feature or bug it relates to. I suppose if you wanted you could add the version number in the message if you wanted.
Thanks, Paul. That’s a helpful POV. With regard to having two separate project files for Mac and Windows I just found this the easier route when I started with Xojo because I could visually see all the UI differences between platforms and could easily handle things like moving the “Pereferences” menu from an Options menu item in WIndows to the Application menu item on Mac etc.
I’d be interested to hear how other developers handle this scenario…two files or one?
I guess in terms of cource control and then making changes between two projects it could be more difficult. Maybe I could create a Mac branch from my main Windows trunk project perhaps? And then would it be easy to apply the same bug fix to both branches via a merge feature or would I have to hard code/copy from branches etc?
Can I ask why you guys prefer Cornerstone over Versions?
The reviews on MacUpdate favor Versions, citing crashes and slowness for Cornerstone’s poor ratings. I’m trying out Versions now and haven’t had any issues.
[quote=253110:@Tim Parnell]Can I ask why you guys prefer Cornerstone over Versions?
The reviews on MacUpdate favor Versions, citing crashes and slowness for Cornerstone’s poor ratings. I’m trying out Versions now and haven’t had any issues.[/quote]
I started with SVN and Cornerstone because SVN was easy to Setup on my Sinology NAS and Cornerstone looked nice and easy to handle. NEVER had ANY issues with Cornerstone. Never!
Then i discovered Tower 2 and felt in love with it’s Design. Plus, i can now handle Open GitHub Projects and my Local Projects (still hosted on my Synology, but now in Git Repos) in 1 App.
Sascha: Interesting because I also have a Synology NAS but didn’t consider using it for repo since I thought having a cloud repo might be more handy. So do you have a clone of the hosted repo on that too?
[quote=253110:@Tim Parnell]Can I ask why you guys prefer Cornerstone over Versions?
The reviews on MacUpdate favor Versions, citing crashes and slowness for Cornerstone’s poor ratings. I’m trying out Versions now and haven’t had any issues.[/quote]
I don’t have an opinion on Versions, because I have not used it nor even tried it out. I’ve been using Cornerstone for a long time and I have never had any issues with it, so no reason to change.
I’ve used Versions for years and like it well enough and have not had a reason to change. I believe Cornerstone has a built-in diff tool, which Versions does not have.
Thanks, Paul. I know it’s slightly off the original topic but I would also love to know how other developers handle converting their code for Mac builds (assuming they start first on Windows target) and any tips and things to watch out for. As mentioned, I expect keeping a single project file has its advantages…especialy with regard to source control. And I guess you would create a new branch for the Mac version even if it’s in the same project file?