Re: Controlling project version

Stut wrote:
I don't like the branching in subversion, it's a lot easier to work with
in CVS.

That's odd since this is one of the major advantages that Subversion has
over CVS (for me at any rate). When you branch or tag in CVS it will sit
there and create a copy of every single file in the repository.
Depending on the size of your projects this can take a while.

Can't agree more with you Stut!

I've used CVS and Subversion quite a lot for a number of years. All my
live sites are just svn checkouts these days - makes deployment very simple.

The branching in Subversion is a gazillion times better than CVS if you
take a bit of time really reading the SVN Book (linked earlier). I sat
down and read it properly and have a pretty good understanding of the
branching and merging procedure and find it very intuitive now. CVS's
branching was always a bit of a dark art to me!

Personally I used to use CVS until I discovered Subversion, and I've
never looked back. However, I am now looking forward and have recently
started playing with Git. Git is something of a paradigm shift when
compared to "traditional" source control, but the way it works is
starting to make a lot of sense to me. I suggest you include it in your
evaluations before deciding on a source control system.

Yeah I need to learn Git too for various projects I work on (Xorg and
compiz/beryl stuff mainly), but it's maybe not the best utility for
website development.

With Git, you keep a full copy (or clone) of the RCS on your local
machine (this means all the changes you ever made!). This can take up a
lot of space for web work with e.g. large graphic files all over the
place (although there are ways to compress down/flatten a git repo).
With Subversion, you'll pretty much need double the space as it keeps a
"clean" copy of all files in addition to the ones you can work on.

With SVN you can do a modicum of offline work - make changes revert to
clean copy, see your changes to the repository (svn diff). With CVS you
have to be online to do this.

With wrappers to SVN like SVK you can also get some of the Git benefits
(and drawbacks) with SVN.

One other good thing about Subversion is the flexibility of it's hooks.
You can setup scripts to automatically deploy your changes to a live
environment. It's ace!

If you are using an interal Wiki, Ticket system I can thoroughly
recommend Trac for this. It has excellent integration with Subversion.

Hope that helps.

Col
.

Relevant Pages

  • Re: "Offline files" and Linux
    ... I didn't say git wasn't good. ... subversion, which is by your argument, a limited model, is perfectly good ... svn certainly isn't rubbish: it's just that the authors approached ... it from a perspective of `fix the uglinesses in CVS'. ...
    (uk.comp.os.linux)
  • Re: "Offline files" and Linux
    ... don't know git, you might think that his comments regarding how it ... I can't think of anything subversion does that git ... with the singular exception of acting like CVS. ... before you even get to the distributed-VCS part ...
    (uk.comp.os.linux)
  • Re: Why SVN?
    ... Is it because SVN is more like CVS than the other choices? ... Subversion is reasonably familiar to those who are used to the CVS paradigm ... however Git was written to achieve nothing more than managing the ... wish there was better handling in distributed revision control ...
    (comp.lang.ruby)
  • Re: Version Control Software
    ... including the old warhorse CVS. ... migrate to a different platform (server or PC), ... git may work, http://git.or.cz/, ... subversion may work better, http://subversion.tigris.org/, ...
    (comp.sys.hp.mpe)
  • Re: Distributing Java Source
    ... In Subversion, branching and tagging actually make sense. ... The do not in CVS. ...
    (comp.lang.java.programmer)