Bruno Medeiros Wrote: > On 09/02/2011 23:02, Ulrik Mikaelsson wrote: > > 2011/2/9 Bruno Medeiros<brunodomedeiros+spam@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?
