DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
> 2011/2/9 Bruno Medeiros<brunodomedeiros+spam at com.gmail>:
>>
>> It's unlikely you will see converted repositories with a lot of changing
>> blob data. DVCS, at the least in the way they work currently, simply kill
>> this workflow/organization-pattern.
>> I very much suspect this issue will become more important as time goes on -
>> a lot of people are still new to DVCS and they still don't realize the full
>> implications of that architecture with regards to repo size. Any file you
>> commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
>> heard the last word on the VCS battle, in that in a few years time people
>> are *again* talking about and switching to another VCS :( . Mark these
>> words. (The only way this is not going to happen is if Git or Mercurial are
>> able to address this issue in a satisfactory way, which I'm not sure is
>> possible or easy)
>>
>
> You don't happen to know about any projects of this kind in any other
> VCS that can be practically tested, do you?
>

You mean a project like that, hosted in Subversion or CVS (so that you 
can convert it to Git/Mercurial and see how it is in terms of repo size)?
I don't know any of the top of my head, except the one in my job, but 
naturally it is commercial and closed-source so I can't share it.
I'm cloning the Mozilla Firefox repo right now, I'm curious how big it 
is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29)

But other than that, what exactly do you want to test? There is no 
specific thing to test, if you add a binary file (from a format that is 
already compressed, like zip, jar, jpg, etc.) of size X, you will 
increase the repo size by X bytes forever. There is no other way around 
it. (Unless on Git you rewrite the history on the repo, which doubtfully 
will ever be allowed on central repositories)

-- 
Bruno Medeiros - Software Engineer