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

[Jean Crystof]

Bruno Medeiros Wrote:

> 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)

One thing we've done at work with game asset files is we put them in a separate repository and to conserve space we use a cleaned branch as a base for work repository. The "graph" below shows how it works

initial state -> alpha1 -> alpha2 -> beta1 -> internal rev X -> internal rev X+1 -> internal rev X+2 -> ... -> internal rev X+n -> beta2

Now we have a new beta2. What happens next is we take a snapshot copy of the state of beta2, go back to beta1, create a new branch and "paste" the snapshot there. Now we move the old working branch with internal revisions to someplace safe and start using this as a base. And the work continues with this:

initial state -> alpha1 -> alpha2 -> beta1 -> beta2 > internal rev X+n+1 -> ...

The repository size won't become a problem with text / source code.

Since you're a SVN advocate, please explain how well it works with 2500 GB of asset files?