To comment on the original question, SVN has the following going for it:
free
cross-platform
commercial support
large installations
vast community knowledge
editor/ide/tool integration
visual UI options
good administrative tools/practices
fair security/authentication tools
written in a common and performant language
stable
I’ve used VSS, ClearCase, Perforce(currently at work), CVS, SVN, Darcs,
SVK, and some others I can’t remember. Perforce is very good, but
expensive. SVK - i do use it but I can’t seem to get past my bias
against Perl. I couldn’t even begin to look at Git because I use Windows
and Mac mostly. Darcs is performant, free, and cross-platform - all good
but it doesn’t compete against the list above, at least not yet. I’m
keeping my eye on it, though. I wouldn’t use VSS, CVS, or ClearCase
again, given the choice.
I think this list is why SVN is such an easy choice. None of these are
perfect, so it comes down to your work style and project needs.
Distributed systems make more sense for start-ups with all remote devs
than in big brick-and-mortar enterprises with all on-site development.
Perforce would be hard to beat if it were free and had a distributed
option, but I don’t see the free thing happening any time soon. Find
wide adoption and support of Darcs, or decentralization of Subversion,
and you may find a break-away leader. Until then you need to ask “which
one fits the way I/we work?”.
As Ryan said, this isn’t completely true for open source projects
(although it seems a little harder for a non-GPLed project; I haven’t
tried to set one up, yet). However, even for corporations, Perforce
isn’t that expensive compared to some of its competition and how
much it provides, and the level of support is just amazing.
It’s not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I’d set up a public read-only SVN
repository for others to access.
fair security/authentication tools
again, given the choice.
Hope that helps.
You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven’t seen a large project using mercurial (yet).
However, I guess pretty much all the advantages you named above would
apply to mercurial as well.
There is a link to SCM comparison site earlier in the thread. From
that it looks like the centralized SCMs are more space efficient in
some cases (ie working on part of the repository) at the cost of being
less flexible (only one central repository to which you need access
all the time, harder branching).
To me the move the use of distributed SCM brings complete new way of
thinking about code management that things like SVK do not. All the
repositories are the same, one may be “central” only because more
people use it than any other.
You did not mention mercurial which is easier to start with than
darcs. It uses python which is more widespread than the thing darcs
uses.
Unlike git I haven’t seen a large project using mercurial (yet).
Mercurial was choosed by OpenSolaris, but I don’t know if it’s already
used or not.
Not entirely true. To be clear: Perforce licenses are FREE for open
source projects.
But having to renew the licenses every year is a PITA. (been there, done
that for 5 years and saw the process getting more complicated over the
years).
In the end, I switched over to Arch when they asked me to fax both the
GPL and BSD license to them to get my renewed license… Nuff said.
I’ve switched to Mercurial and won’t come back ever to centralised
systems like svn.
On Tue, 3 Apr 2007 23:41:14 +0900, Ollivier R. [email protected]
wrote:
Jan F. wrote:
Trans schrieb:
In subversion I have never create a branch: It was to expensive for me.
Well, it is cheap in git as it is in svn, the differences are not
there…
In my experience that isn’t really true – git has much better merge
tracking than svn, so repeated merges on long-lived branches are
substantially less painful with git.
Well, it is cheap in git as it is in svn, the differences are not
there…
The main difference is for me that in svn the branch is a part of the
hole history of the repository while in git a can simple delete a branch
and it is not any more existent. Therefore I use it in many cases when I
don’t know if an idea is best way to solve a particular problem. If I
want to do it this way, I merge it to the master and delete the
temporary branch. Otherwise I delete the branch also and don’t see it
again. This is my definition of cheap: temporary branches.
It’s not going to be something that start-ups use first, though. If I
were to use Perforce myself, though, I’d set up a public read-only SVN
repository for others to access.
That is hard to do actually. At least, I haven’t found any scripts
that do a good job of it (esp with continual/periodic updates). I’m
finishing up the last of the edge cases on my script to do just that
and will be releasing it “soon”. I think all I have left is to delete
empty dirs in svn (which at this point I may just do by hand because
it isn’t THAT big of a deal).
If you know of any good scripts for this, I’d love to look at them.
Not entirely true. To be clear: Perforce licenses are FREE for open
source projects.
But having to renew the licenses every year is a PITA.
It isn’t that much of a PITA for the benefits of using perforce for
free.
(been there, done
that for 5 years and saw the process getting more complicated over the
years).
No, it is getting easier.
I’ve been running my perforce server for about 8 years running now
and while for a while they were indeed requiring a FAX of the license
application form their lawyers (behind the times as lawyers always
seem to be) finally realized the benefits of the electronic signature
act and accept email.
were to use Perforce myself, though, I’d set up a public read-only SVN
repository for others to access.
I saw an interesting article about bazaar, which is meant to be a
replacement
for subversion that is designed specifically for open source type
projects
which have many different contributors/developers and is supposed to be
easier
and more intuitive than subversion. It sounded interesting.
In my experience that isn’t really true – git has much better merge
tracking than svn, so repeated merges on long-lived branches are
substantially less painful with git.
Yes, this is a major drawback of current svn (although svk sorta fixes
that problem). svn has more problems anyway
Disclaimer: I’m the author of a paper on using dVCS on FreeBSD with
focus on Arch & Mercurial.
Ryan D. wrote:
-> I’ve been running my perforce server for about 8 years running now
and while for a while they were indeed requiring a FAX of the license
application form their lawyers (behind the times as lawyers always
seem to be) finally realized the benefits of the electronic signature
act and accept email.
That’s good for them. I got hooked on dVCS when I switched to Arch then
Mercurial so any centralised VCS is out in my book (and P4 is even more
centralised than svn :-)).
If you know of any good scripts for this, I’d love to look at them.
I’m not actually using Perforce at all for my OSS work, so I don’t
have anything, sadly. I like hearing what you’re saying, though, and
it’ll be worth looking at when you release it.
I’m even more fine with software that doesn’t corrupt repositories,
is easy to back up, easy to understand, and works really well / stays
out of my way. Perforce is rock solid and has a long standing rock
solid history. I have to have 100% complete trust in my VCS and its
backups. I simply can’t say that about much of any other VCS out
there (except the nice stable old ones, like CVS). Too new. Too
buggy. Too experimental. Too full of agendas. I just want to get work
done.
In my experience that isn’t really true – git has much better merge
tracking than svn, so repeated merges on long-lived branches are
substantially less painful with git.
Yes, this is a major drawback of current svn (although svk sorta fixes
that problem). svn has more problems anyway
Disclaimer: I’m the author of a paper on using dVCS on FreeBSD with
focus on Arch & Mercurial.
I’m even more fine with software that doesn’t corrupt repositories,
is easy to back up, easy to understand, and works really well / stays
out of my way. Perforce is rock solid and has a long standing rock
solid history. I have to have 100% complete trust in my VCS and its
backups. I simply can’t say that about much of any other VCS out
there (except the nice stable old ones, like CVS). Too new. Too
buggy. Too experimental. Too full of agendas. I just want to get work
done.
To me, that only sounds like an argument against using Visual Source
Safe
As far as backing up an SVN repository (especially if it’s using the
file system instead of BDB) tar does a pretty good job.
For the completely paranoid people that are afraid their backup will
be useless in 5 years because software will no longer be available, or
the current version won’t read the old version, the svn source code is
small enough to be included on the backup disc.
To me, that only sounds like an argument against using Visual
Source Safe
Well, that’s just a given.
As far as backing up an SVN repository (especially if it’s using the
file system instead of BDB) tar does a pretty good job.
I think this is part of the problem. I don’t want to think about what
storage mechanism it uses (past an evaluation stage at least). I
don’t want to have to think: Did they test this storage format as
well as the previous? What are the repercussions of using this over
the other (eg http vs svn protocol)? I just want it to work so I can
do the same.
I’ve seen too much SVN corruption already to trust it.
