Following up to last month's meeting topic, I'm wondering if anyone can help me choose a revision control system for my purposes.
It'll be 2 developers (possibly more later, but always a small number).
We'll share access into 1 box, but I'm thinking we'd prefer a system that lets us check out the complete source tree to our own dev boxes where we can code, and then merge back up changes.
Also, it would be great if we could have a way to check out the current project into a dir that would then serve directly to the web (it's a php project). For example, I'd want a copy to dev on, the other guy would have a copy, and a 3rd copy (possibly older) would be the live web site. When commits are shown to be good, we'd check out into the live site. Hope that makes sense.
I'm thinking CVS or subversion. I'm not sure this small project (maybe 30k lines of code) warrants the strangeness of git. Anything else I'm missing? I'd love to hear the pros/cons.
I'd still suggest git. It's really not that strange unless you want it to be.
The best reason I can give is the ease of branching and merging. Even if you're one developer, it's a great thing to have. You can easily manage parallel streams, such as adding a new feature, stopping, and making a change in your production version, then going back to your feature branch (and pulling in your production changes)
When I started building smallpayroll.ca I used SVN. As I started adding bigger and bigger features I needed to branch. http://ertw.com/blog/2009/08/27/svn-merge/ are the instructions I came up with to figure that out. It was evil. Git is just so much easier in that respect.
I eventually migrated to git and love it. It makes sense. The learning curve was not that bad. It's efficient on my time -- I hardly spend any time thinking about version control.
Now that I've got other people working on it it's easy enough to keep on top of their changes and to share stuff.
Even though git will work between developer workstations without the need of a server, I'd suggest running something like gitolite. It's a breeze to set up and it makes things a bit easier to share because everyone points to one server.
Git will also happily do what you're trying to do in production. You'd just clone a copy and pull changes as needed. Since the cost of branching/merging is near zero, you can choose to deploy from master or another branch, depending on how you want your workflow to be.
Sean
On Fri, Sep 30, 2011 at 5:51 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
On 2011-09-30 Sean Walberg wrote:
I'd still suggest git. It's really not that strange unless you want it to be.
Thanks for everyone who replied with advice. I looked over all the options at length after this discussion and (I think) I decided on git. The main reasons are easy multi-level deployment and easy multi-developer merging.
After learning the basics, I must say I'm hitting my head against the wall. Git is one wacky beast.
I'm wondering if someone who's done it can help me with a quick pointer in the right direction.
Specifically, I'm stuck at figuring out how/where to structure the "main" repo.
Here's the copies I currently have that I'd like to git-itize:
1. Raw dev copy on my box 2. Testing copy on production server 3. Live copy on production server
Add to that 4. 2nd dev copy on some other guy's server
and I think, though am not sure, we'll need with git: 5. git "master" copy somewhere on production server
I'd love some help with confirming this structure will work with git and maybe some tips on actual git commands to get it going. The 2 developers have full shell access on the production server. I've setup a "git" user on it too, which both users can access if required.
From what I've learned, the testing and live copies can be done with a
special push or pull or clone, maybe with post-hooks. I don't think those will be a big problem.
The main stumbling block is where/what/how I make the "git master copy" (#5) and how I'm supposed to integrate that with the #1 & #4 dev copies.
Thanks!!
On Wed, Nov 2, 2011 at 2:23 PM, Trevor Cordes trevor@tecnopolis.ca wrote:
You'll want to set up what's called a "bare repo" somewhere. A bare repo is basically the contents of the .git directory with none of the working files. git init --bare does it, or you can set up a git server. Gitosis-lite is easy to use and only takes a bit of time to set up. Or pay a few bucks and use github.com or another service. This is what you will think of as your master copy. No one ever touches it directly.
Everyone will clone the repository locally with something like
git clone git@git.yourdomain.com:yourapp.git
This will create a local copy of the repo with a remote called "origin". Everyone works locally, commits, then pushes stuff to origin.
(make local changes) git add . git commit -m "fixed bug #71" # now it's committed to my local repo git push origin master # now it's committed to the master
other guys can git pull origin master # now I have your changes
Git doesn't have "different copies". Everyone has the same thing, and you use branches to figure out what your working copy looks like.
For your different users, you have to decide which branches mean what. I follow the continuous deployment model which means that master is always in a "ready to push" state. I usually create "topic branches" to do work and merge them back in to master when I'm happy. Usually these topic branches stay local, but if I want to share changes with other developers I can push the branch itself (which is just a pointer) to the origin server and the other devs can see what I've got.
So if I'm a developer, my procedure would be
git pull origin master # update to the latest code git branch myfeature # change to a new feature (implement myfeature) git add . git commit -m "implemented myfeature" git checkout master # get back on to master, my changes disappear git merge myfeature # merge the changes from myfeature onto master git push origin master # on to the server
(it seems verbose, yes)
So for your staging and production servers, you would update master from origin as needed (first staging, verify, then prod) in two separate clones of the repo.
None of this requires post-commit hooks. People only log in as git to update their local repos, never interactively.
(feel free to talk to me off list if you need more details)
Sean
I'd love some help with confirming this structure will work with git
I have never used Git but I just bumped into this site tonight. No idea if it will be useful but its byline was on topic "A Guide for the Perplexed"
-- Bill
SVN was created to to be the easier version of CVS and it did fix a lot of the CVS strangeness.
However, I've worked with SVN a fair bit and it frequently stumps me on things that I think should be simple.
I've never tried git so I can't comment on it.
John
I've used SVN for things like this in the past.
I have one SVN repo on a server. Access was done via authorized_keys and forced command to load svnserve (and force a user/blame).
Deployment was managed via a post-commit hook which simply just ran svn update in the document root of the web app. This of course requires some discipline given you shouldn't commit broken code. :)
If you want truly distributed management then I would suggest git since it was built for offline work/activities. I've not had the occasion to use it so I can't comment on how good it is as SVN has always been good-enough for my purposes.
That screams "git".
Yup. Any decent RCS can do this.
Although I'm a CVS die-hard, for any new deployments I can't see why I would want to use anything other than git. (Commercial/contractual requirements notwithstanding, of course.) SVN has too many corner cases that don't quite work "right", and I've been bitten by some of them while doing fairly ordinary things. There is definitely a learning curve involved with git, or rather, there's an UNlearning curve - if you try to apply RCS/CVS/SVN concepts to git you will fail, or at best will constantly be fighting the system.
Check out the LJ article on git from a couple of months ago, http://www.linuxjournal.com/content/git-revision-control-perfected. When I read that, git "clicked" for me mentally for the first time.
I agree with one of the other comments - git is only as strange as you make it. Trying to use it as a drop-in replacement for CVS or SVN will make it strange.
FYI - IMHO, SVN has a bigger learning curve than git, coming from CVS.
-Adam
-
Adam Thompson -
Bill Reid -
Gerald Brandt -
John Lange -
Sean Cody -
Sean Walberg -
Trevor Cordes