On 01/04/2010 05:59 PM, Mark Phippard wrote:
> It is probably worth noting that Git, and probably all of the DVCS
> options, are particularly strong in these two areas. I suspect if we
> could make significant improvements in these areas we would remove the
> desire of a lot of people to migrate away from SVN. I still believe
> the number of users that want or need the distributed workflow model
> is a small minority, especially in the corporate world.
>
For the last part, I think it is worth noting that the corporate world
often has no clue how to actually use DVCS, and DVCS solutions are being
sold on features that are not really specific to DVCS (reliable merging,
performance).
I'm in a position where I'm about 50/50 between pushing Subversion and
pushing GIT widely within our organization, and if some of these issues
(reliable merging, performance) are addressed, it would really make the
difference. DVCS is actually a hard sell in a corporate atmosphere,
because de-centralization either doesn't work, or is undesirable. I'd
rather use a clean widely integrated tool designed to be centralized,
than try and force a DVCS to act like a centralized system.
> I also think as a community we need to do a better job evangelizing
> the strengths of SVN against the DVCS tools, in addition to addressing
> the areas where we are weaker and can make improvements.
>
Very much agree. DVCS is cool because it is new - but what scenarios
actually require or work better under DVCS? In most cases I deal with,
"distributed" is unnecessary, and actually reduces my productivity. Do I
really want to be playing with an SHA1 sum as my change identifier? Do I
really want a commit number which changes depending on which site I am
looking at? Do I really want changes to be kept on designer desktops
where a disk failure or user accident can lose a week of work? Do I
really want every user to have 20 Gbytes repositories on their local
disk, because they need a fully copy of the history?
The last part is slightly ironic, as GIT stores more data than
Subversion, but too often uses a *smaller* workspace size. I'm hoping
the next generation working copy implementation is able to fix this
problem. We have many projects with 1 to 10 Gbyte "checkouts". With
Subversion, this is 2 to 20 Gbytes. With 5 branches being accessed at
the same time - that is 10 to 100 Gbytes. Maybe users should have TByte
disks in 2010, but they don't. They have 80 Gbyte disks. We have a
concern that Subversion repositories won't fit (and GIT repositories are
similarly unlikely to fit).
Some sort of light-weight compression should be possible to reduce the
X2 requirement, or allow multiple checkouts to share common backend data
cached. I saw references to this in WC NG, and I was very happy about that.
> BTW, I do not think Mike was suggesting we try to be a compelling
> replacement for DVCS. I assumed that was a semi-joke or was at least
> meant to make the point that we as a community need to decide what we
> want to be. Perhaps more importantly what do we want to be that we
> are also committed to implementing.
>
Subversion is a good product and it would be a shame to see it fall
aside due to lack of promotion or lack of maturity in areas. No product
will be perfect for everybody. Choose the niche, and thrive. That's my
advice. :-)
Cheers,
mark
--
Mark Mielke<mark_at_mielke.cc>
Received on 2010-01-05 02:16:42 CET