Rudi Ahlers wrote:
> On Thu, Feb 11, 2010 at 1:09 PM, Dave Cross <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> On 11 February 2010 10:44, Rudi Ahlers <Rudi@softdux.com
> <mailto:Rudi@softdux.com>> wrote:
> > Hi all,
> > I would like some suggestion on this matter please. I have never
> > using any code repositories / version control systems for our web
> > development project, many cause I didn't know any better, and
> probably cause
> > most of our projects don't really require that we need to keep a
> history of
> > what has changed. i.e. a client wants to change something on
> their website,
> > and we change it, whether it's cosmetics or code (normally PHP &
> [ snip ]
> If you're just getting into source code control, then I'd strongly
> recommend bypassing "legacy" systems like CVS and Subversion. Most of
> the world seems to be moving to distributed system like git
> You can host your own git repositories, or you can use a third party
> hosting service like github (http://github.com/).
> I moved all of my projects from Subversion to github
> (http://github.com/davorg/) a year ago and I'm very happy with it.
> Thanx Dave, I'll check it out. Isn't GIT more aimed at software, than
> web development projects?
> P.S. I don't have a problem hosting my own code, we already have all the
> infrastructure in place
The philosophical difference between git and subversion is that subversion by
design has only one central repository. You can branch the work there if you
want to maintain different versions simultaneously, but the working copies where
you make changes don't store the history or multiple versions. With git you can
clone the whole repository and make changes locally and it is optional whether
the central (if there is such a thing) repository accepts your changes.
Subversion is good if you want central control and have good network connections
to all places where you edit. Git is better if some people need to edit offline
or people want to be able to fork the work and never commit back to the original
repository. If you use subversion, you probably want to start with the current
version packaged in rpmforge instead of the ancient one in stock centos.
CentOS mailing list