subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Mielke <m...@mark.mielke.cc>
Subject Re: Subversion in 2010
Date Tue, 05 Jan 2010 01:16:03 GMT
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@mielke.cc>


Mime
View raw message