I am developing an application for the Mac as a small team (me + another person) effort. We are located in different cities, and have started to see the need for solid source control management.
None of us have any experience with this, and both of us are relatively new to Cocoa/Obj-C/Xcode (but do have C knowledge).
Does anyone have any recommendations as to which SCM system to choose? I understand that a lot of people are using Subversion, which is also supported in Xcode 3.1. Does anyone have experience with using Subversion through Xcode? Or is it a better option to chose a stand alone GUI alternative, such as Versions?
Grateful for any input on this.
Gregor Tomasevic,
Sweden
Update/personal experiences:
Since this post, we have tried Versions and Cornerstone (both of which are SVN GUI-clients), as well as Xcodes built-in support for SVN. We were not particularly pleased with Versions, which seemed to have some problems with committing unversioned files/build files. The built-in SVN support in Xcode works quite well, although it probably has limitations that we have still not run into. Cornerstone is both simple to use and powerful, and does not seem to suffer from the problems we encountered with Versions.
So far, we have just tried committing, updating repo, checking out latest/previous versions of our files and worked some with file comparison. It might be a whole different ball game once you start working extensively with branching, an area which we have been told both these GUI clients might have some weaknesses in.
For what it's worth (and with only days of evaluation) Cornerstone seems to be a somewhat better alternative, although for simpler SCM, Xcode works well too.
Thanks for all the comments.
Xcode only supports Subversion, Perforce, and CVS. However, there are also distributed version control systems out there, such as Mercurial, Bazaar, and Git. These have no Mac-native GUIs, but you should still consider them. Personally, I love managing my projects in Mercurial repositories.
[Added 2011-03-10] Xcode 4 adds support for Git. Several of us have filed requests for Mercurial support; you should, too, if you want it.
There is a nice GUI frontend for Mercurial on Mac called MacHG: http://jasonfharris.com/machg/
It is free and very nice IMHO.
You can't really go wrong with using Subversion.
If, like me, you don't like Xcode's SVN integration too much you can always choose to use the command-line tools, or one of the several GUI apps like Versions, CornerStone or SvnX. Most of these tools work together pretty well, so you're not necessarily tied in to the tool you start out with.
I personally do most of my work with Versions, and use the command-line tools with the same working copies every once in a while.
If you're comfortable working with command-line tools exclusively until someone creates a good GUI app around it, git is a pretty viable option too.
disclosure: I'm one of the people who work on Versions, so I might be slightly biased ;)
Xcode's Subversion support is pretty good. 90% of the SVN activities I perform are easily doable from Xcode. For the other few things I just fire up Terminal.
There are a couple things in their SVN client implementation that are annoying:
The code that checks to see which local files have been modified seems to run on a background timer, and its pretty latent. Sometime it takes 5 minutes for Xcode to show a file as modified. The same thing is even more exaggerated w/r/t remote modifications.
Sometimes when you rename or delete a file that isn't under source control, a dialog will appear, asking "Do you wish to [rename/delete] this file in SVN as well?" And the options are "Yes" or "Cancel." You choose Yes out of desperation only to be presented with a well-deserved SVN error.
Overall, I'd recommend it.
Caveat: If you simply tell XCode to add a project to a repository by giving it the top-level dir, it WILL add the build directory to the repository, which of course is a terrible thing to do.
In order to get around this you have to move the build dir to another location so that XCode won't try to import it, or manually add the discrete folders of a project one by one.
Subversion is the traditional OS X source control solution, in Leopard it's supported in Xcode and OS X, not to mention the third party GUI apps (a few of which look very slick). Despite all of this though, a lot of the independent OS X developers have switched to Git over the past year or two. As a single developer I can tell you Git has turned out to be a very good solution for me, and along with Github it makes a great solution for a small team effort.
If you're interested in using Mercurial on OS X, try SourceTree, it's not free but it's competitively priced and has a very polished Mac OS feel. I've been using it for personal projects for the last few months on and off and find it intuitive and reasonably robust.
It's available through the Mac App Store and supports Git and Mercurial. They have a website at http://www.sourcetreeapp.com/ with more information.
If your going for subversion, I've heard good things said about Springloops. I code together with some friends too in a similar fashion and we use Github. Git is such a wonderful experience. I don't use any GUI for it since I'm much more efficient with a shell prompt. But of course, I'd welcome if Xcode had support for Git repos.
Mercurial (like git) is "distributed" and perhaps regarded as more modern and up-and-coming than svn (but less established). If you want to auto-checkin using mercurial, you can add the line:
hg commit -m "Xcode auto commit"
as part of a "Run Script" stage of the XCode build, as found in:
Project > New Build Phase > New Run Script BUild Phase
I use : https://bitbucket.org/hsivank/xcode4-with-mercurial/wiki/Home
Related
Our dev team uses VS.NET for app development and TortoiseSVN/VisualSVN for version control. It seems that almost every day issues arise with the working copy or the repository getting screwed up, and folks just throw up their hands and call me when it happens. There are definitely human factors at work (SVN works as it should) but I'm tired of playing SVN helpdesk to the dev team. Can anyone recommend a better/more intuitive setup for version control?
Agent SVN works well for me. It integrates nicely with Visual Studio.
SVN is about as simple as version control systems get. Problems should only arise when dealing with merging operations...those can be tricky.
If you don't address the "human factors" it won't matter which version control system you use, you will always be the helpdesk. To address these kinds of problems, you typically need to:
Set up a wiki with common "recipes" for version control tasks.
Include a workflow diagram for how changes are made to your code (for those who don't like to read).
Host a training session that is specifically
designed for your users (use the wiki
material).
When helping someone with a problem, be sure to make them perform the actual fix. Don't just do it for them, talk them through it instead.
Make a point of directing users to product documentation when helping them.
Introducing a new version control system into any organization should include the items I listed. I realize it is extra work for those who get it done, but it does save you from long "support" hours down the road.
Can anyone recommend a better/more intuitive setup for version control?
Better? Yes. More intuitive? That's debatable. Look into distributed version control software, namely Mercurial or Git. Both have freely available plugins to integrate with Visual Studio. And if you can manage spending a little money, I've heard very good things about Fog Creek's Kiln.
As for your issues with SVN, I have a couple tips. The first is to make sure you keep everyone synced on the same version of the product. It tends to update frequently, and so this can be tricky, as you also don't want to fall too far behind the current version. The second is that we used to have big problems with Tortoise trying to cache icon overlays on mapped network drives. There is an option you can turn off somewhere that suddenly made things way more stable. But that was at my last job, and I don't remember the exact setting any more.
I think you already gave the answer in your question - sort out the "human factors" by providing appropriate training. Version control for software development doesn't get much simpler than SVN, so from the way your question is phrased, my guess would be that said human factors are just going to find other ways of making your life interesting.
if you have issues with your repository getting screwed (like committing on tags, wrong commit messages...), one of the easiest way is to play it the hard way : put hooks on the server to enforce policies. You can have a look in official documentation.
Basically, this is an easy way to enforce naming / formatting and avoid a lot of human issues (committing on tags, messing with externals...)
I still can't really figure out if I should go with Mercurial or Git. Git is directly supported by Xcode, and Mercurial isn't. So it might be clever to stay with Apple and use what they prefer.
Since Git and Mercurial are pretty much the same thing though, I see no big reason why to use Mercurial anyways.
But now the problem is: How to set up Git so that 5 devs can work on the same project, everyone having a full working copy locally on their machine, and then pushing their results back to an central repo where everyone else can pull the final super-merge back in?
I guess there is a good tutorial somewhere? The other devs in the team don't want to mess around in the command line since coding is hard enough. Are there any GUIs for Git that make creating and maintaining the repository an easy thing?
Snow Leopard, btw... I've found this Git Installer for Mac OS X, but it doesn't mention if this runs on Snow Leopard. Not sure if this is the original good thing:
http://code.google.com/p/git-osx-installer/downloads/list?can=3&q=&sort=-uploaded&colspec=Filename+Summary+Uploaded+Size+DownloadCount
Edit: Confusing! Someone told me Xcode has Git integration, but it only has SVN! OK so even if I still stick with Git, how can I get started with a GUI at least?
Xcode 4 will have git support built-in.
http://developer.apple.com/technologies/tools/whats-new.html#version-editor
So I've decided it's probably best if I get some Source Control solution going to keep my hard work safe, and to help eradicate bugs between versions.
I'm familiar with SVN as far as checking stuff out, but I have NFI about the committing side of things.
What is a good Source Control solution, keeping in mind that I develop in Visual Studio on Windows? Should I get a hosted solution, or host it myself on my own server (running Windows Server '03)
I'd suggest using git and get Git Extensions for better Windows integration.
If you're just getting started and are looking to self-host, I suggest VisualSVN. It's a lightweight, extremely easy-to-use SVN server, and free. I've used it for small projects at work and home. It includes security, with folder- and file-level ACLs based on local or Windows users.
You may decide later to move to more powerful servers or an externally-hosted solution; you can just dump the repository from VisualSVN with the standard svnadmin tools and load it into something else very easily.
For the client side of things, I use TortoiseSVN and love it, and I understand Ankh has gotten better since last I used it.
Use git.
One workflow that git does really well:
Have an idea for some feature you want to implement
Create a new branch for that feature
Write code, commit like crazy
When you're done implementing, squeeze all the crazy commits into one big patch
Commit that patch against your main branch
Delete the for-that-one-feature branch.
This is wonderful to have. You can have multiple parallel branches for this, and it's really easy.
As an additional feature, if your project goes public and you use git, people who check out your code will have an easy time making their own changes to (their copy of) your code, version-controlled and all, and it'll easy to track upstream at the same time.
If not git, try some other distributed source control system and see if it does good branching and local commits as well.
We are a small team (seven people) we have been using a hosted solution (hosted-projects.com) for more than one year. It's cheap and has worked very well for us. We use tortoiseSVN for the clients.
The main advantages of a hosted solution are:
no need to worry about server setup and maintenance
remote hosting means we have a complete and up to date backup of our code on a remote location
very fast
I recently did a team development thing and we just hosted subversion on one of our workstations and it worked... passably. We used visual svn on the server, and tortoiseSVN on all of the clients (and I occasionally connected my macbook using Versions, SVNX, or the command line). Merging is the really hard part... we had a lot of trouble with that (resolved, once again, with some command line skill). I also set up my own subversion server on my linux workstation for personal use, which worked better (merges were smoother, only one developer). Overall, it has been fairly easy and merging is probably the largest problem you'll face.
If your new to source code then I would recommend you read Eric Sink's series on Source Control. It doesn't really cover distributed source control but it's still a very good primer.
I personally use Perforce. They allow up to two uses for free for home and small business use. It is a little expensive compared to others but there is reasons why companies like Google and Symantec use it. It has ok to good Visual Studio support.
I really like hosted solution because often comes with other tools like trac to manage your project timeline and bugs control.
I recommend projectlocker or codespaces
At work I use ClearCase and SourceSafe, but have found some time to do some time to code for myself enroute thanks to a disposable laptop.
However, I wish I had a lightweight VCS on my system using which I would be able to make changes to my code during the commute and then push/grab them from my Linux systems.
I use git on my home system, but I can't really get it working on Windows. I don't want all that cygwin hack.
If it does not run natively on Windows, it just won't do.
What have you guys tried on your Windows system? Something that YOU use.
The big player at the moment seems to be Mercurial?
What would be best for a one (or maybe two) man team?
I just need to maintain :
Versioned copies of source code.
Checking in and out should be as less obtrusive as possible.
I am looking forward to a multiple Undo kind of feature (like that in an EMacs buffer) but persistent.
I really like the way git keeps track of lines moving between files in a source code set
I should be able to move part(s)/sub tree(s) of the source tree (each sub tree implies a module/plugin to my the main software I am building) to an archival system either completly or partially and restore them back from the archive as and when required and the system should track any changes to this tree as well.
I actually want to experiment with my code as much as possible without me manually keeping track of what I modified and what I need to undo once I try out some idea, so that I am back to where I want to continue from.
Notes : A similar topic came up a year ago : DVCS Choices - What's good for Windows?
I hope things have changed, and I really want people to share their own, real life experiences. Not something they recommend without using it or they think will work.
Bazaar and Mercurial both work very well on Windows. I posted in the question you linked, and since then, both have improved their Windows support even more. Using them is easy and flawless, and they even have GUIs if you swing that way.
I for one have switched from bazaar to git, and I've been pleased.
If you've a Clearcase background, why don't you take a look at Plastic SCM? Check this link, it will show you how it works on a distributed setup (and of course all the basic operations) http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html.
You won't miss any of the "good" clearcase features but all the shortcomings are simply gone (faster, installs on 45seconds, no cumbersome setup to use on a mixed Win/Linux scenario, built-in ACLs, excellent branching and merging, much better common ancestor algorithm, visualizations, better GUI, and you still have "selectors" in case you miss config_specs, but not being mandatory)
Assuming that I'm starting a new web project at home using Visual Studio, which version control system, viz. Git or Subversion will be better to use? Which one will have the least setup complexity?
Since this is for your own personal playing around, my question is simple: Do you know Subversion or Git already?
If you know SVN - use Git.
If you know Git - use SVN.
If you don't know either - use SVN. It's a better introduction.
I'd go with Git. It's not that bad getting up to speed on the basics (there are now a ton of good resources, including learn.github.com) and it'll pay off in spades. And I've been using it on Vista with no probs.
Subversion is far more Windows-friendly in my experience and also more immediately useful for the solo developer.
Another possibility is Perforce, which is slightly less Windows-friendly, but full featured and fairly easy to use, not to mention free for up to two users.
Git is a distributed source control setup and as you are the only user I can't imagine that you would benefit much from its features. Subversion is (in my opinion) easier to set up so I would recommend you go with it.
If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent.
On the other hand, Git is much more promising than SVN. I'll check it during this year, but third party tools are not on par yet.
I'd go with Mercurial instead. It's supposed to be similar to Git (which I never could get running because of the Windows issue) and is really easy to setup in Windows & very nice for "personal" version control systems.
Which one you decide to use depends a lot on what your needs are now and going forward. Git has a very nice community built a round it with GitHub which is great for sharing code and projects. SVN is pretty simple to setup and get going, but in large teams Git has it beat hands down with it's branching and merging. This is ideal in cases where you have multiple people working on the same project, either in an office setting or an OSS sense where the team is spread out.
If all you need is something quick and simple to setup and get going so you can start your project, SVN should be fine. SVN is also integrated into many editors and IDE's as well as many bug tracking and continuous integration systems.
If you plan on having a team, or already do, Git is worth looking at for its branching and merging setup. Git however, due largely to still being kind of young, doesn't have nearly as much support available
If you want Visual Studio integration there is no question. Only Subversion has Visual Studio integrations (AnkhSVN, VisualSVN and several scripts that allow access to TortoiseSVN).
One of the most important reasons that Subversion has such a large amount of tools written for it is that it was designed as a stable library for use by multiple clients.
It's unlikely that Git gets the same level of integration in Visual Studio before git support is available as some kind of reusable library. (There are plans for a libgit2 that could make this a reality).
Let's my ride-in on your question and ask:
Does Git work on Windows?
Does it have something that's equivalent to Tortoise? (otherwise I don't see how it could compete with SVN in terms of ease-of-use)
On a side note: If it's really a one man home project, you don't really need any source control tool. Just put your project in a DropBox folder and you're done (auto-commits, infinite revisions, undelete).
Unless you really think you're going to need tags and branches and stuff. But for personal home projects... do ya?
You can make your own opinion after reading this : http://whygitisbetterthanx.com
Git................................(these dots are there because SO wont accept a 3 lettered answered).
A great answer to this question was recenting written about by Jack Repenning here:
If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree)
Neither of those? Take your pick, you should be fine with either tool.*
Full Blog Post here: http://blog.codesion.com/post/15692788883/subversion-or-git-decisions-decisions
With SVN you will have to set up a server, create a repository there, check out the (empty) repository, add your files, and then commit.
With Git, all you need is git init in your project's root directory. Then you can add and commit files as you see fit.
There's not really any idea in setting up a Subversion server, since you're the only one working on the source. Contrary to what many people think, solo projects is a perfect match for distributed version control tools. It's also very easy to grow your project later on.
In my experience, Subversion is easier to "grok", but Git is faster and easier to engage in software development best practices. As a former CVS user, Subversion made immediate sense to me when I started using it. Git took some study and I still have to refer to the manual from time to time, but I love how easy it is to branch and merge code when I've got to maintain a release process.
If you are already familiar with CVS and just need something to keep your history and diffs, Subversion will be easier to get started with. If you are new to version control, the tide is shifting toward DVCS in general and Git in particular, so you may get more mileage out of that in general.
I do recommend you look at a hosted provider so you don't have to worry about setting up a Subversion server or so you can have a backup location for your Git data. You can Google for "subversion hosting" or "git hosting" to see the premier providers in the space.
If you plan to take your project along on an USB stick, use Subversion. Windows XP it really, really, really bad at caching lots of small files on an USB stick. Git writes many small files for commit operations and that takes ages on Windows.
[EDIT] The problem with Windows XP and files on an USB stick is caching (or the lack thereof). To prevent data loss, XP will always write files synchonously on an USB stick (so any write will come back only after the FS has reported that all blocks have been written to the stick). Add that to the fact that USB sticks are slow when handling small files (they have a lot of overhead initializing their wear level management) which leads to very poor performance for any kind of application which writes lots of small files.
[EDIT2] If you put a SVN checkout on the USB stick, you will also have a lot of small files (especially in the .svn directories). So the solution in this case is to put the Subversion repository (the "server") on the USB drive. The repository uses only a bunch of big files (if you use the database option instead of the file based one: svnadmin create --fs-type bdb). This avoids the "many little files problem". There is no way to achieve the same thing with current versions of Git.