I have a project and I want to work with another developer on the same project. I'm looking for a way to share the project between us, so that we can work on it parallel at the same time. I need it to work locally, without using an internet connection.
I'm a part of a 2-3 iOS developers team so I can give you a few tips from my experience on collaborating (we use git, I'm assuming you know a bit about. if not, read this), after you get the hang of it here are my thoughts -
Try to make as little change as you can to your project pbx file simultaneity, It'll result in a conflict almost every time
Don't be scared of branches, we're using them all the time, if you two are planning to work on different features of the same product try to do it in different branches
We had serious problems with storyboards and collaboration - like pbx their content change even on open and merging those changes can be very tiring
You already have Git available to you inside of XCode. You can share your code and work on it on the same time using "branching" mechanisms.
Bitbucket has excellent FREE private mode where you and 5 other people can share a Git repository. There are easy-to-use tutorials available on their site. I would highly suggest using that.
I would steer away from using SVN, there are better tools for what you are looking for.
Why don't you use SVN ?
You can configure SVN in Xcode for doing this. Also you can use Git.
Check:
Configuring Xcode to use subversion
Git Source Control With Xcode
Check this question How to set up an SCM in Xcode?.
There you will get links about how to setup SCM for xcode
Related
I am searching since at least 29 years ;-) but I don't find anything, that would match my understanding of a good workflow.
Isn't there any tool, to do some versioning with shared-hosting ftp-servers for web-development on a mac?
This is my case: I am php-coder, just have written a bigger application with Symfony. now, as the 1.0 is final and released, I have setup a dev release, where I can test and develop - but each time I want to publish a new release, I have to look for all files, that changed since the last update and upload them by hand or just update everything (7000+files...).
There MUST be anyone who had this problem and wrote a versioning tool for mac or a versioning and deployment plugin for eclipse or whatever for testing AND publishing on different ftp-servers (and publishing cannot be github or whatever, because its all about shared-hosting) - does anyone know one?
Thanks so much!
At last, I found myself beginning to use bitbucket. Didn't like git, so I use mercurial for now. Works fine, as I can submit everything once I finished an update and sync changed files to the production environment.
SVN is quite cool... :-)
Thanks for your thoughts!
UPDATE
Some months later, i found http://www.gitlabhq.com/ - exactly what i was searching for. Didn't really have the time to use it, but seems to fit the needs!
If you'll use (for example) Subversion (svn-client exist in OSX) you can use any mentioned here bash-scripts for automating deploy (for any transfer-protocol really) of files, changed between revisions (OLD-RELEASE and NEW-RELEASE in your case) with (possibly) smallest adaptations or Ryby-script, which export range from a box.
Uploading tree by FTP in unattended way is a task for second tool - ncftp, ncftpput namely
First, a confession. In about 10 years of professional development, I've never used a source control system. There, that feels better. My historical setup (as recommended by management, ha!) has been to create dated folders on a server and copy-and-paste my data into it each evening.
I've known for a long time that a much better, manageable solution would be to use git or Mercurial to manage my source but I've never taken the time to learn any of these new tools because myold system has always worked well enough for my needs as the lone developer for every project I've ever worked on.
I have finally change this setup. I've installed Mercurial on my Mac, which after a bit of reading, I prefer over git. As a GUI front-end, I have installed SourceTree which appears to be easy to use and quite friendly. The problem I am having is that I can't find a very simple, straight-forward walkthrough for setting up a server repository that I use for pushing changes to each evening. I'm sure it's there, I just can't find it.
I've honestly tried to Google this, but there is something about the term "SourceTree". I can't find anything useful because half of the information I find is in regards to using git and it tends to involve pushing a project to a site like github.com, which is not pertinent in my case.
Additionally, I have skimmed the Mercurial documentation and I still may not be entirely clear about the full commit/update/push/pull/branch/merge concept. I just want to get something setup rather fast that will back-up and track the changes of my projects, without having to be a source control guru.
How do I setup a simple repository on a Windows network server, and push and pull changes each evening? My company want me to store my data in a personal folder, on a network share that is backed up to tape and is then stored off site.
I'm sure it has to be simple. I just want to be sure that I'm doing it correctly so that in the case that I need to access a back up, it is there and can be easily pulled... or branched.. or whatever.
Well, it depends on the kind of the server you are going to use.
Let's assume it's not a Windows server (just a guess, as you're a Mac user). Let's also assume that right now you only need it for yourself, not for a bunch of users.
Then the simplest way is to use SSH. Suppose the server is server, and you have an account rlh there. You'll need to have a public/private key pair for a seamless access (no need to enter the password on each pull/push). You'll need to install Mercurial on the server as well, obviously.
On the server, create a repo (in your home dir, for example):
rlh#mac$ ssh server
rlh#server$ mkdir myproject
rlh#server$ cd myproject
rlh#server$ hg init
On your machine, clone the repo:
rlh#mac$ hg clone ssh://rlh#server/myproject myproject
The default target will be set automatically, and you should be able to pull/push with no additional configuration.
Feel free to ask if you have a question regarding this.
When searching for hosting solutions, best not to include the term SourceTree in your query — SourceTree is just a front-end tool that is in principle unrelated to Mercurial hosting. That might explain the lack of useful information.
Here is an overview of ways to set up Mercurial servers:
https://www.mercurial-scm.org/wiki/PublishingRepositories
Personally I’m using plain hgweb and that has served me well.
Also I would recommend to consider using a hosting service such as BitBucket or Google Code. It requires much less effort to set up and maintain. Here is an overview of Mercurial hosting services:
https://www.mercurial-scm.org/wiki/MercurialHosting
Personally I’m also considering moving my self-hosted Mercurial repositories over to BitBucket, because of reduced maintenance overhead, and also it has functionality like bug tracker, wiki etc.
So I'm creating my project using a git source control and using some libraries from another repositories. But I'm also developer of this libraries and I want edit/debug them in my project so I can add it to project not alike binary dll but alike another project.
I found this article : Multiple projects in a solution vs. multiple projects in source control
But I'm working on Windows and usually just using Tortoise Git. I guess that will be really hard to configure it such way.
There is another idea. Do not add solution file to version control and create some readme how another developers must construct project and it's dependents.
Maybe someone already met or even solved such trouble, I'm interesting to know any solutions and variants for it.
Thank you.
At a company I used to work for, we ended up putting the projects themselves into different repo's which made managing them easier as opposed to 1 solution. We then wrote a batch file to simply put all the pieces back together and compile it correctly (just compiling the component Projects). This may not work for everyone but it is just a suggestion.
The reason we did this was because opening the solution in VS was getting to be very memory intensive for the machines and was becoming a giant mess of files.
Also this can be used so that teams only work on their specified software and can really only talk to the other components. This is a great way to enforce 3-tier/n-tier architecture design since you separate the projects out and let teams/developers only worry about what they're working on (not really fool proof but it helps).
In our company we usually have a solution consist of several projects, mostly dozen or several dozens. Those are coming from different repos 'cause some of those are general purpose libs, frameworks etc. We, however, use SVN with VS AnkhSVN plugin so there are completely no issues with commiting changes to more than one repo.
My assumption for you is to check whether Git VS plugins could work with seeral repos in one solution. More info on Git VS plugins here: Using Git with Visual Studio
BTW, accroding to 'one or many repos' discussion - we create one repo for a project. So if there are several parts of the project and some of those existed before and will most probably keep being after - those should not be placed in the project repo. Should something great be born within the project and we do believe this will overlive it - we could always migrate repo subtree to an independent SVN repo.
I have a question, the answer isn't really hard technically, but I am more looking for the experience of most advanced programmers here.
So like many noobs, I am doing my version control in the crappiest way, which is to copy paste my project directory and rename it with the current date/time.
You will agree that it's a quite limited solution :P
I decided to learn version control system(s), but I am facing many choice, and I would like to know what are the best for your points of view ?
Using Xcode integrated version control (git or anything else), with organizer, cloning, commits from xcode etc. I mean totally or almost controlled by Xcode ?
Ignoring Xcode letting him think there no version control and doing it myself in command line ?
A merge of the two above ? How ?
And then :
Using git ? Github is very popular and powerful, but you must learn git, and learn it hard.
Mercurial ? It seems more friendly.
Something else ?
It would be priceless to have some feedbacks about more experienced people, so that me and many others I hope can choose their paths when facing the VCS wall :-)
Thanks a lot !!!
First: Use a VCS at all.
The rest:
Mercurial is nice, but Apple went with Git for Xcode. So if you want source control integration within the IDE, Git is the best option.
The things I miss most when working with Xcode & Mercurial are the "Modified" indicators in the source list and the integrated diff-viewer. (Which is pretty good in Xcode IMO)
The actions you perform in the Organizer are a bit limited at the moment, but you can always fall back to Terminal.app for that.
I can only recommend git. Merging is easy, I remember the days when a merge conflicts occured with SVN, it was pain, horrible pain to resolve those. You can easily start a local repository with git, especially if you are the only one developer.
Have a look at Which SCM system to use with Xcode 4 for a lone developer?.
I suggest some reading on git for the beginning:
Git in five minutes
Git Community Book
The Thing About Git
Take some time to invest in learning the basics of git, it's absolutely no rocket science to get you started on basic usage and you will benefit from it right away. Once you know the basics of git, you aren't locked into another tool wrapping git, you can use git if there are some problems with XCode. Also, git is available for several OS so the knowledge you gain about git will not go away if you move between different computers that have different OS.
Here are my best of bookmarks for git:
http://www.delicious.com/Ralphtheninja/bestof+git
I've had good success with SubVersion.
Intro
I've used SVN before, back when I was working as a solo programmer, just to keep an offsite record of what I was doing, so I kind of know about ideas like "repositories" and "commits" and the like, though not much more than that. "Branches", "merges" and "checking out" are, sadly, a mystery to me.
I want to start using Git because we've got a couple of guys who work away from the office and they have complained that they sometimes can't get through to some other version control systems because their IDE integration causes them to sulk and fall over when they get out of contact. Git's idea of "Every working directory is a repository" seems like it should go some way towards solving that.
Anyway, I've downloaded the "Git Extensions" to add The Shiny to the Windows context menus, etc. and I've found that I really have no concept of how I'm supposed to use this to control my versioning. Not finding anything obvious after a google search, I present the following theoretical scenario to Stack Overflow in the hopes that someone will tell me what to do, in small words:
Scenario
I have three projects. One project, ProjectReuse is used by the two other projects (ProjectA and ProjectB). Various people in the organisation will need to edit the code for each project, using Visual Studio 2010.
I have three folders on my desktop, labelled "ProjectReuse", "ProjectA" and "ProjectB". I've got the Git Extenstions window open. A cow, wearing a Santa Claus hat, is staring at me.
Questions
What do I do now to create the repositories in such a way that several people (including those pesky not-always-on-site guys) can access a repository when they need to, on-site or off, with or without a permanent connection to our servers?
When the first guy needs to edit a file, what does he need to do? Check out? Branch? I have to explain this to the other team members and I'm a bit wobbly on these concepts, myself. I've only used version control for my solo projects before.
Wheedling and excuses
The first "how do I set this up?" question is what I'm most interested in, but I figure if I'm going to ask for the idiot's guide, I might as well ask for it to be as useful as possible for the next idiot who stumbles onto this question. I'm not looking for particularly in-depth answers, here; I just haven't got any clear picture in my mind of how a multi-user version control system works. Once I've got that in mind I should be able to put the rest together by myself.
Ok, let's get the first thing about git straight. Git is distributed. Repeat this to yourself as many times as necessary: there is no central server, central repository or indeed anything central. Completely in contrast to SVN, you are not all accessing one repository (nothing central).
What you do is create a repository somewhere. Then everybody else clones (copies) it. Now everyone has their own copy of the repository and can do with it as they wish. Branch names don't even need to be consistent across repositories although many people do this as it helps.
So, how do you set it up? You init a repository then everyone who wants it clones it. In your case, I'd recommend each project have its own git repository rather than lumping all three together.
But but but how on earth am I supposed to manage a development team, I hear you say? Never fear. I said there was no central repository, but that doesn't stop you designating one of the repositories to be the release repository, and another to be the experimental or whatever.
What you need then is a workflow. Typically, what you do is create said release repository and then say: "everybody pull from the master on here". This represents your latest "stable" release. Now you tell everyone to branch from here and develop their new features. They do this. As these get done, you ask people to merge their changes back into their own master or wherever, then you, the release manager, pull from them (probably into a development branch but you could well do it into your release master because it is trivial to reverse commits). The next person then updates their master and does their merge. They resolve their own merge conflicts etc, and so on until you have all the features you want. You do your testing etc then the release repository really does pull all of that into its master.
In practice you might do many different things. For example, if you have a lot of people you're going to need quite a lot of communication going on, because if lots of people make incompatible changes to your shared project there's going to be a few merge commits. To avoid this, users can pull/merge from each other or use a local "shared" repository.
It does work.
As said by Ninefingers, just init a new repository and let others clone it. Keep in mind that when you want a public (or central) repository, create a shared repository and not a private repository. The easiest way is to create a personal repository first, and than clone it to a place (e.g. network share) where everyone has access to as a shared repository.
I created a few video tutorials for Git Extensions here:
http://code.google.com/p/gitextensions/
The video tutorials are a bit old and not very good since I do not have a mic or any video editing skills, but it should be enough to get you started.
Good luck!