I know Xcode can be hooked up to an SCM. But how would I set this up from scratch? How to check out / commit files into that, after setting it up?
A great guide for setting up subversion repository & configuring with XCode - http://iphonedevelopment.blogspot.com/2009/03/version-control-is-your-friend.html
Other useful resources -
1) http://developer.apple.com/tools/subversionxcode.html
2) Which SCM system for Xcode?
3) http://www.covertapps.com/development/6-setting-up-your-xcode-scm-repositories
Thanks,
Sagar
Once it is set up, several new menu items appear in the SCM menu. You can right-click over specific filenames and perform some SCM operations that way.
You can also right-click over "Groups & Files" and enable "SCM" there, which will show which files are new or modified.
I never used Xcode's SCM features for anything more than to see what files I've modified, a feature that only helped me find the code I was currently fixing. For all the updates & commits, I would use the command line, but that's a personal preference. I'm a long-time command-line CVS and SVN user. It is faster for me on the command line.
I highly recommend starting with git - while I once preferred perforce I don't like paying for it and lack of Xcode integration makes it tedious. Git is supported in Xcode 4. Using it without integration for a month or two would be invaluable as you will then understand more of what is going on... SCM, like data backups, is only any good when you understand it and use it right.
I like git because it can be used as a local SCM with replication/sync with a central repository. It is widely used and actively maintained. It is free & open source, and I have used it as part of a team delivering a very complex and successful iPhone app.
I really like Git Tower as a GUI.
Related
We have been using Domino on a large project for years without any real source-control (other-than server backups). So, I was rather pleased when I noted the latest Designer 8.5.3 has potential integration with SVN.
I was unable get SVN working just by following the original instructions for as already noted on Stackoverflow the update sites have moved. The solution posted on OpenNTF, only half worked, with Domino still croaking at GEF, Mylyn and some other missing plugins. After finding and installing them, I still do not seem to have source-control integration.
What I have now is the ability to create on-disk projects but I do not seem to have any source-control features. I was expecting to see menu items for commit, update, revert …etc – is this how it works in Domino?
I can of course create a repository to commit the on-disk project to but I was hoping for integration inside of Domino. Whilst having years of experience in programming I’m a novice with Eclipse. I assume that I’ve done something wrong with installing the plugins? it was certainly a complicated process trying track down missing plugins.
Has anyone tried this recently and succeeded? What files do I need to install, setting tweak, …etc, to ensure this works? I’m happy to install my Designer fresh and follow a list of instructions.
Also, am I understanding how the integration works? Will I get command integration within Designer or do I have to work separately with the on-disk projects? I was really hoping for this be easy to integrate into normal workflow so I can convert the team to using it (adding too many extra or complicated steps is unlikely to create a conversion).
I posted a screenshot of my installed plugins in case this is helpful.
Mercurial? As an aside, has anyone used Mercurial instead of SVN with Designer? I would rather use Hg as I’m using this for related Dojo projects and will be easier for the team to use one system. However, I will settle for SVN as any source-control is better than non.
Update: This is answer is now out-of-date. It is useful in that it should point users in the right direction but it isn't really a working answer anymore. I no-longer develop on Lotus Notes so I cannot update it to a current solution.
I managed to figure this out eventually but will post the solution, just in case anyone else has the same trouble.
The answer by Per Henrik Lausten was very helpful as it showed me the route to follow through the menus. The main problem is that I'm not used to how Eclipse works so I didn't realise you had to go to the "Team" menu and "Share Project" after creating the on-disk project. When I did this I discovered that both SVN and CVS were already available.
I found that SVN did not like the file:// protocol (perhaps a windows issue?) Since, I could not arrange for an SVN server on our network, I decided to go down the Mercurial route. This was better for us as our other projects are stored in Mercurial.
Setting-up Mercurial with Lotus Designer 8.5.3:
In Domino preference (File -> Preferences), set: Enable Eclipse Plugins in the Domino Designer section to ticked.
Also in the preferences set: Use Binary DXL for source control operations to unticked (File -> Preferences, Domino Designer -> Source Control). Without this ticked I was not getting text for my Lotusscript agents and it would be difficult to compare changes.
Go to File -> Application -> Install:
Select Search for new features to install and click Next.
Click Add Remote Location button
Add the url: http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable/ and give it a suitable name
Once you've added this, ensure it is ticked in the location list and click Finish
Design will then search for updates and give you a list. Untick "Only show latest version of a feature per update site"
Tick MercurialEclipse 1.6 from MercurialEclipse Stable Releaes. I found that the latest version does not work, however a previous Stackoverflow conversation indicates that version 1.6 does work.
Click finish and allow it to install.
You will be asked to approve various plugins and then to restart.
MercurialEclipse, should now be installed!
To start using Mercurial with a Domino Application:
Right-click the application in the Applications tab, select: Team Development -> Set Up Source Control for this Application.
Give the project a name and choose a location for the project to be stored.
Designer will then do a DXL export of the database to your chosen location. A Navigator tab will appear next to Applications.
Right-click your new disk-project in the Navigator and select: Team -> Share Project...
Select Mercurial from the Repository types and allow Designer to create the repository.
You should now have access to various Mercurial functions via the Team menu. (You need to make your first commit.
When you make changes you want to commit to source-control, you need to:
Right-click the application and choose: Team Development -> Sync with on disk project...
Go to the Navigator tab and right-click your on-disk project, selecting team.
Most of the above steps should be obvious but decided to post full details in case anyone struggled like I did with Eclipse and how to use it properly. Once I figured it out, it really was quite easy.
Keith Strickland has created a series of blog posts on using source control with DDE. They might help you:
Keith Strickland: source control in DDE part
1: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=B236F39DEAF6C52F85257A72001157BF
Keith Strickland: source control in DDE part
2: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=B5D76A6DA163DCB585257A7C004802B6
Keith Strickland: source control in DDE part
3: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=C2C46D278948A24985257A7D0055D25E
I'm running an open source ecommerce store (nopcommerce) and have made a lot of customizations to the store.
Every time a new version of the software is released, I use winmerge to try to detect which files have changed, and then merge these changes into the project. This works OK but as my customization have grown, this task has become increasingly problematic.
What I'd really like to do is be able to get a diff from my current version to the new version, and then go through and apply the changes that I want.
If I use TFS for this, is there a standard way to accomplish this? Perhaps a 3-way merge app would do the job better?
To complicate things a bit further, I'm using the theming support to add my modified views in another location, so the changes from version to version need to be figured out and applied to the files in this additional folder as well.
In fact this is where the big headache comes in- determining which changed I made, and which ones are new changes from the new version.
nopCommerce hosts its source code in Mercurial via CodePlex. All you really need to do is clone their repository and make changes to your local clone. Then, you can either keep up with their modifications or wait until the next release comes out, then get an update from their repo and merge it with your changes. Mercurial, being a distributed version control system, just does merges well, and you will have fewer problems if you try to do something manually for yourself using Subversion, TFS, or anything but Mercurial. Go download TortoiseHg, which gives you both a nice GUI and the command-line tools for Mercurial. TortoiseHg comes with the KDiff3 merge tool, but I highly recommend Beyond Compare. It's not free, but I'd pay for this software a hundred times over.
As always, if you need help with using Mercurial, see the Hg Book.
I have used both TFS and Subversion and I strongly recommend Subversion (source repository) with TortoiseSVN (command line) and VisualSVN (integrated into Visual Studio).
With these tools, it is very, very easy to find out exactly what files have changed and, more importantly, rollback to a previous version in the event that something goes horribly wrong.
You can also add CruiseControl continuous integration to automatically build your solution and run unit tests on each checkin to ensure that you didn't inadvertently break something.
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.
I have an app in the iPhone app store and have released several minor updates to it. I want to begin work on some major feature additions and reorganization, but don't want to lose the source code of my most recent version in case everything goes horribly wrong.
Should I start a new Xcode project from scratch and copy my existing source in? If I do this will I be able to submit the build from this new project as an update or will Apple complain that the build comes from a different Xcode project?
I've seen (but not used) Xcode's "Snapshots" and "Source Control" features - are these what I'm looking for?
Any help or direction greatly appreciated.
I would suggest getting your project into some kind of Source Control. The popular ones these days are Subversion (Xcode has built-in support for it, but the support is pretty crappy), git, and Mercurial, all of which run great on the Mac.
You would add your project to a git/svn/hg/etc repository, and then "tag" the repository with something meaningful ("Shipping Version 1.3" or something) (alternatively you could just branch your project at its current state and give that a meaningful name). Then you can do your developments, add and commit the changes to your repository. If you need to revert back to your old shipping version, that's quite simple because you tagged it before you started work (think of a tag like a snapshot).
The other option is to start a fresh Xcode project and copy things over. I have personally done this and shipped just fine to the App Store (just make sure things like your app's bundle id "com.whatever.app" matches with the original one, and make sure you codesign properly) and you're good to go.
Having said that, unless you have a really great reason to start with a fresh project, you're probably better off using source control management with one of the aforementioned tools (git is my preference).
You are using some form of source control right? If not, stop what you are doing and make sure to set up an svn repository. Svn is bundled with your mac and integrates with Xcode.
You also may want to start thinking about doing backups...
I highly recommend you check out Git. There is great Git support built into XCode 4, and you can use Git just fine with XCode 3 as well.
One great thing about Git is that you do not need a server to take advantage of the source code management features. It is a lot easier for a solo developer to work with than SVN once you get your head wrapped around it.
I also highly recommend GitX - a free graphical UI for Git that is absolutely amazing.
One other recommendation it GitBox - a simple tool that allows using a Dropbox as a Git master repository. This is great for sharing code between multiple machines without needing to have or pay for Git hosting at GitHub or elsewhere.
You can either do what the people said before, and use svn git or the like, OR if you don't want to mess around with any of that you can simply create your own version control by copying and pasting the folder and name it "project name x.x" and modify the version without the version number on it
snapshots are the first step. when you are comfortable with them you can hook up to an SVN server for your offsite backup
just make a snapshot after your distribution build and label with the version number
The quickest, easiest, short-term solution is to select the Xcode project folder, and duplicate it. This will create a duplicate of everything in the project. Apple won't care that it comes from a duplicate project.
For the long term, look into setting up an SVN. This will help you save your previous versions every time you make changes.
Since you are new to source control management so might I suggest using Subversion.
Subversion has less features than Git, but you don't have the confusion between pushing and committing (locally vs remotely) and you will find there is more software that supports Subversion than Git or Mercurial.
If you need a quick backup, you can always zip the current working folder for your Xcode project, then name it something like:
MyApplication-Version-1.00.zip
I've recently taken on a project with no version control. I don't have any experience with version control myself. I feel it is the only way to go with this project (and probably any future projects now I think of it - I always trust myself too much..)
My question is - where do I begin with implementing version control on a project already in production? Bearing in mind I haven't used version control before so really it's two separate questions:
Starting out with version control
Implementing it on an already live
project
For background, the project is a php/mysql driven website using bits of javascript, I'm working on a (Windows) XAMPP server and I'm very keen to learn this new world of version control!
Congratulations, you are headed in the right direction!
You'll first need to choose a version control system. My current favorite is Git. Unfortunately, I don't think that Git is an easy introduction to version control. I have also used Subversion and Perforce.
Subversion (http://subversion.tigris.org/) works on many platforms, is used in a lot of projects, and has some nice GUI tools available (such as TortoiseSVN on Windows). Command-line tools are also available. It's also free. You can run it in "local filesystem" mode, meaning that you don't need to set up a separate server. It's come a long way from it's "better than CVS" roots.
Perforce (http://www.perforce.com/) is pretty nice. Its Windows implementation seems the best (last I checked, their cross-platform GUI was pretty lousy). You primarily use a GUI to interact with it, though again there are command-line tools. It's commercial software, but open source projects can get free licenses by contacting the company. The biggest drag is that you will need to set up a server. To get started, you could run the server on the same box that you develop on, but that's probably a bad idea in the long run. I found Perforce to be very good for 2-8 person teams; I don't know how well it would work with more.
The big advantage to Git (http://git-scm.com/) is that it requires virtually no set-up. Once installed, you can execute git init in any directory to create a new git repository. The revision history is kept inside the project's directory. You can start out with just local versioning, and you can scale up from there. If Git seems scary, you could also check out Mercurial (https://www.mercurial-scm.org/). I haven't used it, but I understand that it shares some of the same underlying principles as Git.
Avoid CVS. It's on its way out, and no new project should be using it unless they need to do so.
Adding source control to an existing project is easy. The hard part would be making sure that everybody is willing to use source control. If you're working alone, then it's just personal discipline. If you're part of a team, though, and some people have reservations, you will have problems. Try to get everybody on board, and be available to try to answer their questions. If people don't know how to use a tool, they simply won't use it.
Start here: http://svnbook.red-bean.com/
I've found SVN to be the easiest version control system to use, especially for beginners. It's pretty simple to start, the only real decision you have to make is where to host your stuff. There are a couple free svn servers available, but if you're really serious about your work you should host your own.
The first thing to do is to pick a version control paradigm (centralized versus distributed). To answer that, you'll need to take a look at your team and how you intend to handle check-in, check-out, merging, and branching. Once you pick a paradigm, you can choose a version control system. The mainstream systems are Subversion for centralized version control and Git and Mercurial for distributed version control.
If the project is live and working, then that should be your initial check-in to whatever version control you are using. You need a reliable baseline that you can revert to and have 0 work to deploy something that works. If your project is not functional...well, good luck. You might want to check in to start using version control and then decide how you want to proceed (either get the project to a stable and functioning state and then restart your repository or have your initial check-in be a broken system).
If the rest of the team doesn't see the benefit with version control, I would recommend installing your own system on your machine and, at the very least, use it for your own work.
Be prepared for some resistance from management and/or your co-workers. Management may not want to invest the resources for a repository machine -- these things need to be installed, maintained, backed-up, etc. Or they may object to you spending time on an "extra" like a RCS.
Your co-workers, especially if they're unfamiliar with any RCS, are likely to resist using it, or complain that it's too hard to use. There's a learning curve to any new tool, and source control systems are no exception. It's worth the time to learn, though.
My advice is to pick one -- any one that strikes your fancy -- and start using it. Don't worry about getting it 100% perfect the 1st time, it probably won't be any worse than what you have now, which is one misplaced keystroke away from oblivion.
Play with it. Check files out into a separate workspace and hack things up, knowing that it doesn't matter; you can always revert it. Learn how to use your new tool with some GUI frontends (I'm fond of 'svn diff --diff-cmd=kdiff3', myself). Get to the point where you know how to check in & out, tags things, branch, and merge. Then show your co-workers.
Personally, I'm fond of svn, but I didn't choose it; it chose me.
Step 1: Download Mercurial.
Step 2: In your favorite command line, go to the root of your source directory and type hg init.
Step 3: Do a make clean or equivalent (ie. all you want is source, no generated files).
Step 4: Type hg addremove.
Step 5: Type hg commit.
From this point on you can:
Examine the changes between your most recent commit and now: hg diff or hg status.
Make checkpoints in your code: hg commit.
Return to previous checkpoints: hg update -C -r 0
Congratulations, you are now using version control: It's really not that hard, and it's very, very useful (if for no other reason than you can look at the changes you've made to see if they make sense).
At some point you'll probably want to learn about branching (if only so that you have a backup copy of your repository on another machine) at which point you can turn to the documentation or the book.
I don't know if there is something similar for php etc, but an interesting resource here is "Brownfield Application Development in .NET". In many ways, this only uses .NET for the examples; most of the book is really about tackling policies exactly like you mention:
how to introduce source control
how to introduce unit testing
how to introduce continuous integration
etc
and all the concerns/consideration that go with them.
Partly relating to the code; but also relating to the "human" factor; colleagues, managers, etc. I highly recommend it; but you might decide the .NET background is inappropriate for you (it is a good fit for me ;-p).
You can look here: git-for-beginners-the-definitive-practical-guide
This one is a distributed version control system that currently has a good windows support with Git on Windows and a shell extension with TortoiseGit
An addition to other answers:
If the project you want to put under version control have had some releases, and if those versions are available for example as tarfiles (e.g. project-0.1.tar.gz, project-0.2.tar.gz, project-0.3.tar.gz, ...) you might want to consider importing those versions into your chosen version control system. Git for example has import-tars.perl and import-zips.py in contrib/fast-import/ directory, and writing support for other files in other programming languages for git fast-import should be easy.
Sidenote: my preferred version control system is Git.
See also: Good link or book for basics and theory of version control question.
I learned the concepts from the pragmatic series:
example for subversion, they also have books on GIT as well.
I only have experience with SourceSafe and SVN.
SourceSafe seems to have issues with corrupting it's own database, on a team of 5 we were repairing the db probably once a month. It's easy, but still something you shouldn't have to deal with. It's difficult to label code too and use that label for anything practical.
SVN is nice, it's simple to install on Linux or Windows. Most IDEs have a plugin for it, and if you're using Windows there is an Explorer extension (TortoiseSVN) that allows you to do all your operations right from Windows Explorer. There's a lot of SVN tools out there for every OS, it's very well supported. SVN also integrates with TRAC (a bug tracking system), and Bugzilla so you can tie your work tickets to code.
I will say that [HOW you use version control is probably just as, if not more important than which package you use][2]. Using it simply as a library is a very rudimentary application of it, but for a 1-2 man team making a website or an app where you won't be maintaining builds and versions, you'll be ok.
When it comes to version control, anything is better than nothing.
Wow, everyone is just boosting his favorite version control utility.
OK, to answer your question, how do you put a project under version control?
It's not that hard, once you pick a version control utility (be it, git, svn, hg, bzr .. whatever) there's usually a command or two to initialize a repository then add all the relevant files to it.
For instance, in git it might be something like:
$git init
$git add --all
$git commit -m"First commit"
Now, about choosing a version control utility, that's a tough question and highly depends on what you want. You might want to have a look at this question:
Popularity of Git/Mercurial/Bazaar vs. which to recommend
The only tools you should consider choosing among are:
git
svn (Subversion)
hg (Merculiar)
bzr (Bazaar)
mtn (Monotone)
Everything else is either old or commercial.
svn follows a server-client model; there's a central repository. If you're a one-man team then the only thing this means to you is that you have to setup a server and make sure it starts with the computer. Though I heard that you can do away with the server. A bit of googling turns up this guide for using svn without a server
All other tools follow a distributed model, again, if you're a one-man team, the only thing this means to you is that there's no server to setup.
The advantage of svn is that it's been there for a while and has many gui front-ends and better IDE integration.
I can't compare git to hg (merculiar) since I haven't used the latter, but git has a unique storage model compared to svn and hg.
bzr is said to be easier to use, but slower (it's written in python).
I'm personally satisfied with git, but you should do your own research; or maybe just choose one and stick with it. As far as I can tell, they're all mature and stable.