How can VCS improve my workflow?

I’m trying to wrap my head around VCS. I have to manage several of my projects and use three different computers in different locations (home office, office office, laptop (on the couch office). I have been using Drop box but it isn’t cutting it for the following reasons: 1. Security, 2. Not super easy to access historic copies of projects, 3. No way to log reasons for changing files (commit messages?) 4. I want to make my workflow “flow” better.

I have read a couple threads here about what systems people are using and I have installed git, mercurial and SourceTree as well as MacHG to test them out to see which one is a fit. They seem to have a bunch of features that I think would be overkill for me and I find the interface to be a little overwhelming. Also it seems like the systems are more adapted to other languages and not so much Xojo. Maybe I’m wrong.

For now, I’m the only one who works on my projects and don’t need all the features those systems offer… Or do I? To put the question differently, if you are using one of these systems, what features are you all utilizing for your Xojo projects? Ie. Branching, Update, Commit, Tag etc… How would these things apply?

Yes, source control looks overwhelming to the beginner. Especially so for a command line challenged user like me.

The other features like Branching etc are nice but not essential. The best client for a CVS on the Mac is Cornerstone.

The basic terminology is:

  • Repository: your bag of code, current and historical
  • Working copy: the checked out current code.
  • Commit: you worked a bit on your code like fixed a bug and want to save this in your repository.
  • Update: you need to update something from your repository to your working copy (basically the other way than the commit).
  • Tag: you finished a release
  • Branching: you need to work on 2 versions at once.

HTH

Beatrix, thank you. I looked at the screen shots for Cornerstone. Things look a little simpler than what I’ve been reviewing.

[quote=54633:@Beatrix Willius]Update: you need to update something from your repository to your working copy (basically the other way than the commit).
[/quote]

Do you mean it’s the opposite of commit? So “Update” is like reverting ?

Also check out User Guide Book 4: Development, Chapter: 5: Code Management, Section 2: Using Source Control for steps on how to get started.

You can benefit from source control even if you never use more advanced features such as branching or merging.

Terms can very by the source control system being used. For Subversion, “Update” means to refresh your local copy with what is currently in the online repository, possibly auto-merging if you had local changes. “Revert” means to replace your local copy with what is on the online repository.

Thanks Paul. I will have a look at the guide book to see if I can learn some about it.

If you decide to take the Git route, check this Book. It’s available online and as a freely downloadable PDF.

And should you decide on SVN the book is here

Hi Joseph,

I actually put all my project artifacts under source control - design documents, agreements, research, test data and of course source code. And while it is true that such systems work best for plain text type files when it comes to file comparisons and text search, you still get the benefit of versioning etc for other file types etc… Being able to pull up multiple versions your code at the same time is very cool.

On a daily basis the most common activity is committing work to the repository. When working on some thing complex, I tend to commit about every half hour or so and of course at the end of the day. That makes it easy to go back and look at your changes over time or revert to an older copy if required.

I also work on several machines, so ensuring that I have an up to date copy of my project is essential. Therefore the first step in my workflow every time I sit down at a machine is to do an update from the repository.

Tags, I use a couple of times a month, either to mark a version I’m handing over for testing or releasing to the client. That way it is easy to see exactly what version of your code was being tested when the bug reports start coming in :wink:

I don’t use branches very often, the most common case is if I need to do a hot fix for a client, in such cases I’ll create a branch from the release tag, do the hot fix, release it to the client and merge the changes into the trunk later if necessary.

I use SVN most of the time, simply because it is commonly used in my business area and many applications have over 10 years of history stored there, so it is not so easy switch.

Hi everyone,

I have checked out svn, git and mercurial. After all that, I have decided to make my own solution that should be simpler for me to use. I think I can use individual sqlite files to store repositories. And a master sqlite file to track all the repositories. I can save the repositories anywhere on disk and the master in a static location (SpecialFolder.ApplicationData?).

By the way James, the way you explained your workflow seems to match very closely to what I’m trying to accomplish.

So, any thoughts about trouble I might run in to when setting up my own little system?

I should also ask has anyone else made their own in-house system for this?

Yes. It’s tedious. And in retrospect, not worth the work. I’m working on scrapping it and moving to one of the standard svn solutions. Don’t get me wrong, there are a few things that you can do with a custom solution that are really slick. But you can also integrate some of that into the off-the-shelf stuff, too.

PLEASE, PLEASE, for your own sanity, rethink this. VCS is already there, just waiting to be used, right off the shelf with many cheap or free implementations. Just start simple, put your code in a repository and use it initially as a simple way to rewind back to a past version when needed or to do a diff. Make some changes and commit, etc… Then when you get past the initially hesitance, then start branching / merging and tagging.

There are a couple other similar threads here on this topic, but you can sum up most people’s thoughts on this subject with: “I can’t see how in the world I got along without VCS and when I think back on what I was doing in place of it, it seems comical.”

[quote=55093:@Joseph Morgan]I have checked out svn, git and mercurial. After all that, I have decided to make my own solution that should be simpler for me to use. I think I can use individual sqlite files to store repositories. And a master sqlite file to track all the repositories. I can save the repositories anywhere on disk and the master in a static location (SpecialFolder.ApplicationData?).
[/quote]

Systems like SVN, GIT and so on are used by hundreds of thousands of developers all over the world. They are feature rich and very stable, so why would you go wasting your time trying to reinvent the wheel? Spend a couple of days learning SVN or GIT and then you are there. Unlike most other applications, VCS does not change very much over time.

I’d suggest you sign up for the trial membership over at pluralsight and work your way through one of their intro courses to either SVN or GIT. That should more that get you up and running.

At this point in time understanding and using VCS is a standard software engineering skill, so unless you are working in a vacuum you are going to have to deal with it sooner or later.

If you go with something standard, you can use ready-to-go hosts for it as well so your stuff is off-site. If you roll your own, it’s up to you to host it.

Bitbucket is free and supports mercurial and git, with private repositories. Their software (Sourcetree) is fine as well, although reading the git book mentioned before helps.

Bill

I ummed and arrghhed for so long on VCS and made the the move a couple of years ago. I started with SVN, but migrated to GiT three months ago. Primarily as I have free GiT hosting and my SVN host increased price (although grandfathered in!, I too a long term view). I have no preference on either.

The real payoff for me was three weeks ago, I had released a prog into a wider beta, committed it and then after a short while, I “branched” off to convert some stuff to a database. Then in came a serious bug report that needed a quick fix. With simple clicks of a mouse I had the released beta source code, made the fix, committed it, then merged into the branch and I was good. That workflow was more than the price of admission for me. Call me a VCS convert from now on.

Whether you pick SVN, GIT or Mercurial will be a personal decision.

The only real difference between the offerings is that systems like GIT are distributed, which is useful if you often work offline - you have a local repository to work with, so you can still make use of the features provided with needing a connection.

However having said that, if you have a large number of developers working off line, it can be a bit time consuming to get it all back together again

Yikes! That escalated quickly!

If I were starting from scratch, I’d probably choose Git over Subversion. Don’t create your own!

Well, call it boredom. I recently had abdomen surgery so I’m grounded for a couple more weeks and going stir crazy for some gym time. Sooo… until then this will occupy some of my time. :stuck_out_tongue:

I actually have a lot of it put together already. I will keep ya’ll updated.