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:

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. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable

-- Sean Walberg <sean@ertw.com> http://ertw.com/

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

-----Original Message----- 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.

That screams "git".

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.

Yup. Any decent RCS can do this.

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.

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

On Wed, Nov 2, 2011 at 2:23 PM, Trevor Cordes <trevor@tecnopolis.ca> wrote:

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 4. 2nd dev copy on some other guy's server 5. git "master" copy somewhere on production server

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

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!!

_______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable

-- Sean Walberg <sean@ertw.com> http://ertw.com/