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<m...@mielke.cc>
