Ok, perhaps I'm trying to accomplish something not doable.
I am a single developer (not part of team).
I'm trying to get some kind of versioning system going. I had used CVS with XCode 3, but XCode 4 no longer has that as an option. I've heard that SVN and Git are better alternatives anyway.
Basically, I've wasted more than half a day trying to get XCode to work with SVN / Git out of the box. I do not have a server running, and would rather not expose my project on a server.
It doesn't make sense for me to have a separate user just to run the Git/SVN Servers, either.
I'm just trying to have version control using either one, in the simplest possible way.
I've tried to add Repo, using local file path (/Volumes/AAA/BBB/Repo) where I manually created the "Repo" directory. I've set the type as Subversion (and also tried Git). XCode says "Host is reachable". But, the Commit functionality is not there (Disabled). I can't import my working directory.
I just don't get it - must I have a server running in order to have SVN/Git, or can XCode just do it through command line? I much more prefer it being done over command line, since the server is complete overkill. Or, am I missing something? Maybe I'm putting in the wrong settings into XCode?
This isn't strictly an XCode 4 issue, I had the same issue with XCode3, but at least it had the CVS option - now it's gone.
With Git you don't need a central server or even a central repository unless you have multiple people on the project. SVN requires you to have a central repo & server running all the time, but with Git you can simply git init a new repo and start using it. If you don't have a central repo you will never use push, pull, or fetch.
Xcode's help mentions the following:
Choose Git or Subversion Xcode supports two SCM systems: Subversion
(often abbreviated svn) and Git. Subversion is always server-based and
the server is normally on a remote machine, though it is possible to
install one locally. Git can be used purely as a local repository, or
you can install a Git server on a remote machine to share files among
team members. The Xcode 4 installer installs the Git and Subversion
tools when you select System Tools. If you are working alone, it’s
generally easiest to use Git, as you don’t need to set up a server. In
fact, Xcode can automatically set up a Git repository for you when you
create a new project (see “Create a Git Repository For Your New
Project”). For a group project, the choice of Subversion or Git is
usually a matter of taste and prior experience. In so far as is
possible, Xcode provides a consistent user interface and workflow for
users of either Subversion or Git.
So the official advise is that in your case, Git is the easiest solution. I'm now in the same position as you described and will be trying Git as advised.
Previously, when working for a small company, we used a dedicated leftover MacMini as an SVN server; this was quite easy to set up, and worked like a charm for many years. Be aware that the SVN integration of Xcode 3 was better than that of Xcode 4 though, so that I ended up using Xcode 4 for development and basic SVN usage, together with Xcode 3 for SVN stuff that Xcode 4 wouldn't do anymore.
Related
When I was on an army programming course me and my friends used SVN with a repository we had. I wanna set up a repository so that I can work on my projects without having to worry about moving my files from pc to pc and working with the right version.
If there's something you can recommend and what source control program I can use I'd love that. Thanks!
Two commonly-used repository hosting sites are Github (https://github.com/) and Bitbucket (http://bitbucket.org). They use git (Bitbucket also supports Mercurial) instead of SVN, which is similar but has a slightly different workflow. These two services are easy to get started with and have great tutorials. And repositories are free!
You can:
Install, configure and run own instance of SVN-server on own host
Move to Assembla, which offer natural SVN-hosting
Select any other SVN-hosting
Create Git-repos on GitHub, but use SVN-gate (special SVN-URL) and SVN-clients
I'd very much appreciate anyone sharing best-practices, patterns, anti-patterns, backup, rollback processes that you have formulated for a pain-free, foolproof, Play framework upgrade.
I'm thinking just replacing the bin/play directory with the latest version can cause problems
Edit:
I'm looking for more specific version management strategies, say,
a) Do you just have /bin/play directory having the latest play version or
b) Do you keep versions like /bin/play-1.1 /bin/play-1.2 and change your $PATH to point to the latest (cons: you have to rebuild your modules, dependencies & libs; pros: gives better control over rollback)
I prefer to install play from source using git:
git clone git://github.com/playframework/play.git
cd play
# checkout specific version
git checkout 1.2.1
cd framework
ant
cd ..
ln -s $PWD/play ~/bin
So I have a full install including all source. Later, when play was updated to version 1.2.2 I did the following:
cd <play_home>
git pull
git checkout 1.2.2
cd framework
ant
In your application you then do
play clean && play run
The advantage of running play from a source build is that you can always and easily roll back to the previous version or even test out features from current development. This does not solve the problem of having multiple versions of play active at the same time though.
I agree with Andre. However, if you are asking for best practice for a live project, I would do it differently.
You can have multiple version installed on your local machine. The only thing you have to change is which one is visible in the path. For instance you could have 1.1, 1.2, 2.0 and depending on which one you want, you just modify your /home/youruser/.bashrc file.
The reason, why simple update of play from git or hg will not work/good idea is because, incase there are problems, you have to revert, rollback modules, or goodness know what not.
It is far better to simple swap out the play version, rebuild, test extensively, once you are ok that everything is good, then you can make the same changes in a live site.
If things don't workout, or your are hopelessly lost, all you have to do is revert the changes to your project and switch the play version. You will be back to where you started.
I'm an iOS developer looking to better manage the projects I am creating. I've never touched SCM before so I'm not sure which system to use.
I'd like to keep track of changes to the different apps I'm making for my boss, but also have them in a centralised place, and be able to branch off and be working on features separate from the main app and then merge the changes back in when I'm finished. All of this will be done locally (stored on an external hard disk in my office), and once versions are complete I'd like to be able to export a copy without the SCM features to send to my boss.
I've just upgraded to Xcode 4 and noticed Git is built in. I played around with both Subversion and Git, but it sounds like Git is what would fit my needs better. However, it seems to be totally different to Subversion. The Xcode 4 documentation suggests Git is best for lone developers, but that doesn't seem the case. If the git repository is inside your working copy, how on earth do you make branches of it? Where do you send your changes to? Do you copy the entire working directory and use that as your branch?
Just looking for someone to explain in plain english which SCM system would be best for a lone developer to use and any tutorials people may know of to help me understand it.
Thanks for any help!
Go for git!
The repository actually resides in your working directory. There is .git folder which contains all the data about your branches and commits and whatsoever. You can create a bare repository(only the contents of the .git folder) if you like but having both in the same place is nice, especially if you are a single developer who doesn't need distribution.
Branching in git is very easy:
# create the branch
git branch mybranch
# switch to branch
git checkout mybranch
# show branches
git branch
Git does not depend on a server like svn does. You can have distributed development by using remotes but this is not necessary.
If you like to make a copy for your boss without the git files in it do a
git archive branchname --format=zip -o tree.zip
I suggest some reading on git
Git in five minutes
Git Community Book
The Thing About Git
Branching in git is very different from SVN. Branching happens in place, in stead of in another directory.
Read this book and other resources to get a better understanding about how git works
About the centralized server, Git is a decentralized SCM. That means that every clone contains the entire repository, not only the current working directory.
That doesn't mean you can't have a central repository. On the central server you create a bare repository, and on you're local machine you clone from that repository, push and pull from that repository, often through ssh.
We have a largish standalone (i.e. not Java EE) commercial Java project (10,000+ classes, four or five SVN repositories, ten or twenty third-party libraries) that's in the process of switching over to Maven. Unfortunately only one engineer (in a team of a dozen or so distributed across three countries) has any prior Maven experience, so we're kind of figuring it out as we go.
In the old Ant way of doing things, we'd:
check out source code from three or four repositories
compile it all into a single monolithic JAR
release that (as part of a ZIP file with library JARs, an installer, various config files, etc.)
check the JAR into SVN so we had a record of what the customers had actually got.
Now, we've got a Maven repository full of artifacts, and a build process that depends on Maven having access to that repository. So if we need to replicate what we actually shipped to a customer, we need to do a build against a Maven repository that has all the proper versions of everything. This is doable, I guess, if in (some version of) the (SVN-controlled) POM files we set all the dependencies to released versions?
But it gives our release engineer the creepy-crawlies, because there doesn't seem to be any way:
to make sure that somebody doesn't clobber the copy of foo-api-1.2.3.jar on the WebDAV server by mistake (the WebDAV server has access control, but that wouldn't stop a buggy build script)
to detect it if they did
to recover afterwards
His idea is, for release builds, to use a local file system as the repository rather than the WebDAV server, and put that local repository under SVN control.
Our one Maven-experienced engineer doesn't like that -- I guess because he doesn't like putting binaries under version control? -- and suggests that maybe the professional version of the Nexus server can solve the clobbering or clobber-tracking/recovery problem.
Personally, I'm not happy (sorry, Sonatype readers) with shelling out money for a non-free build system when we haven't even seen any benefit from the free version yet, and there's no guarantee it will actually solve the problem.
So our choices seem to be:
WebDAV server
Pros: only one server, also accessible by devs, ...?
Cons: easy clobbering, no clobber-tracking/recovery
Local file system
Pros: can be placed under revision control
Cons: only works with the distribution script
Frankly, both of these seem like hacks to me, and I have to wonder if there isn't a better way to do this.
So: Is there a right thing to do here?
I'm not sure to get everything but I would:
Use the maven-release-plugin (which automates the release process i.e. execute all the steps documented in release:prepare).
Use WebDAV with anonymous read-only and authenticated write policy (so only release engineer can actually deploy released artifacts to the corporate repo).
There is a no need to put generated artifacts under version control (if you have the poms under version control). I don't see the benefits of using the local file system instead of WebDAV (this is not providing more security, you can secure WebDAV as well). I don't see what the commercial version of Nexus would solve here.
Nexus has a setting which prevents you from clobbering an already released artefact in a release repository.
For a team of about a dozen, the free version of Nexus should be enough.
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.