Careful who you call troll. You'll find your assumption comes back to bite you.
I knew I could count on a good reply. I know you are a good debater. I
need not bring up the topic of benchmarking with you for example. ;-)
Technology is proven by (1) wide use and (2) long experience. CVS and
Subversion at this point are proven technologies that are widely
adopted. That doesn't necessarily make them best of class, but it
means that people know what to expect from them. Some of that will
include bugs, but the core technology is proven. There are billions of
lines of code in CVS and Subversion systems being protected and
managed right now.
Yes. Though there a millions of lines of code written in languages a
lot here would consider primitive. There are also millions of more
lines of code being written with no version control as well (I would
guess, though there is no denying that this number is larger than it
should be). I think I will agree that the wide spread use is
important, but I don't think adoption is the only metric to look at.
Subversion has meaningfully improved upon CVS and has improved the
state of the art for open source centralized source management. I
wouldn't dare call it best of class, but I would use it for any open
source project because it (1) has a lower barrier of entry across
platforms and (2) works in ways that people expect it to. I'm less
convinced that I'd use it for professional software development after
my experience with Perforce at my current job. Perforce is an
absolutely amazing piece of software that gives many of the supposed
benefits of distributed development platforms (lightweight branches,
patch cherry picking), and with p4proxy, you get better distributed
development (although *not* apparently disconnected distributed
development).
No argument here. There are a lot of projects that thrive off of easy
entry. I think Ruby on Rails is an excellent example that many in this
community have been influenced by. I hear more and more people taking
up Subversion because of how pleasantly it works with the rails
development environment.
Professionally, I use subversion, though my team is looking to migrate
to something that does a better job at branch management and merging.
The verdict hasn't been given yet, but it will likely also be
distributed. Your review (and the reviews of others in this community)
might make an impact. I will likely give Perforce another shot (though
I know the team I work with is much more likely to want something open
source).
The important thing here is, for those of us who can afford to learn a
new tool (effort required here is usually exaggerated), the history of
a tool is a smaller barrier to entry (provided it works correctly). I
am much more likely to pick up an alternative in some of my projects
because of this.
There's so many different distributed systems right now that work
differently from each other and have forked because of differences in
opinion on how the programs should work that it's nearly impossible to
choose one reliably. Many of them suffer from an extreme anti-Windows
bias and very few of them (if any!) have GUI support for visualizing
changes over time. I personally find disconnected distributed version
control systems to be very fragile in that entire branches can go away
because a middle version is purposefully or accidentally deleted.
People say that distributed systems have cheap branching, but I find
that very hard to believe, since (at least in the ones that I've
tried, and I have a hard time imagining how others would differ) the
branches are physical copies in a different location. That's cheap for
the making, yes, but your total storage cost goes up (since none of
the advantages of having a single repository can be found) and it then
becomes possible to *lose* branches from your repository (cf fragility
above).
I have to admit that none of the people I work with write their code
in a Windows environment. In fact, as a team, we officially don't
support it. The only windows environments we have left are for testing
some of the web applications in Internet Explorer. This would probably
count as a bit of context I guess.
I will note that I've never had a branch problem, though I guess it
depends on how you manage your code. I usually have very little that
could be lost if I, for some reason, wanted to rm -rf a working copy.
I think most of this is helped by following a set of conventions for
each tool. There is a reason subversion makes use of the
trunk-tag-branch structure... and there are similar reasons that
people work certain ways with other tools. I usually have a couple
places I put code depending on the project type. In many cases, I
setup my environment with a central repository that represents
something like a trunk. Real development is done outside of the trunk
but synced in functional groups. Locally, small changes are recorded
quite often (this accentuates the power of cherry picking in an
interactive system). It seems that this duplication gives it the same
"relative" reliability that a standard Subversion setup would have
(detached code repo being one if you have multiple machines).
For cheap branches... I'm not sure either. It has always boggled my
mind why people are so upset when two files have to be duplicated. One
system that really does cheap branching well is git. Only a single
file with a few characters is created for each branch (initially,
changes are added of course). I'd love to hear from others who know
more about this.
There's a lot of things to like about the *ideas* of DDSCM, but in the
real world, I find that I'm rarely disconnected from the 'net long
enough to care about the fact that I'm using a centralised management
system.
True enough. I like some of the ideas because I am one of those people
who has experienced significant offline development. Maybe it
conditioned me to where I am now.
So no, not a troll. Well informed using shorthands that should have
been pretty easy to determine if you weren't blinkered by the
proponents of DDSCM in the first place.
Yes. I know I lean far to the DDSCM side of things and I don't intend
to hide it. I think the quality of this reply made up for the
originally open claims. Though, I would like to ask, out of all the
problems you mention, none of them really give a benchmark that could
be used to note if a DDSCM would be ready under your definitions, are
there any specific things that could be fixed or done to make your
trust in a DDSCM system more likely? Or is DDSCM, for some reason,
mutually exclusive with what you get out of your current SCM usage?
Thanks,
Brian.
I was expecting to find a SVN UI with the google I just did.