Re: [Dotgnu-libjit] Re: [Dotgnu-pnet] CVS is down -> Switching to SVN?

[Robbert Haarman]

On Thu, Jun 04, 2009 at 08:32:40AM -0500, Harley Laue wrote:
> On Thu, 2009-06-04 at 09:39 +0200, Radek Polak wrote:
> > Klaus Treichel wrote:
> > 
> > > 2. One should be able to create a branch on a subproject like pnet,
> > > libjit, ...
> > 
> > Hi Klaus,
> > why is this needed?
> 
> Because that's how Git tends to work best. Rather than having 4
> projects in one repo, it's best practice to have those split up. This
> is pretty much because when you check out a project you get the whole
> history and it's not per file like CVS. So bundling projects together
> makes the history get rather large, and the initial clones rather large.

I don't think you really need to worry about history getting too large. 
In my experience, Git is very efficient, both in terms of speed and in 
terms of storage use. http://git-scm.org/gitwiki/GitSvnComparsion seems 
to agree:

   For example the Mozilla repository is reported to be almost 12 GiB
   when stored in SVN using the fsfs backend. Previously, the fsfs backend 
   also required over 240,000 files in one directory to record all 240,000 
   commits made over the 10 year project history. This was fixed in SVN 
   1.5, where every 1000 revisions are placed in a separate directory. 
   The exact same history is stored in Git by only two files totaling just 
   over 420 MiB.

> > I dont think that splitting modules into repositories is good idea.
> > Pnet is dependent on pnetlib and libjit - with separate repositories
> > you can end up easily with different version of e.g. pnet and pnetlib
> > that do not work together - because of internal calls and other stuff.

This is something that I would be much more concerned about than about 
the size of the history. If the projects are interdependent to the point 
that they evolve together and basically cannot be used separately, I 
think having them in separate branches would lead to usability issues 
far worse than having a larger history. In fact, in that case, you 
wouldn't probably have a larger history if you merged them all in a 
singe branch, because you would always have to use all the separate 
branches together anyway.

> IMO that's irrelevant. That's like saying because GTK is dependent on  
> GLib, they should be bundled together in one repo. It doesn't make
> sense to do that since they're two projects

Indeed, if you can use the parts separately, there is sense in putting 
them in separate branches.

So, in the end, I think the choice boils down to how tightly coupled the 
projects are.

Regards,

Bob

-- 
"What if this weren't a hypothetical question?"

signature.asc
Description: Digital signature