Re: [Gnu-arch-users] Google Summer of Code

[James Blackwell]

I'm sure that you're happy to shoot this particular messenger whenever the
opportunity presents itself. I can even understand why -- I used to work
at a company that you wrongly believe destroyed you.  But lets leave that
off to the side. Fighting on a mailing list is like participating in the
special olympics -- even if you win you're still retarded. =D

Anyways...

My source for this is the approximately 500 public full history imports
that were done in first GnuArch, then Bazaar, then Bazaar-NG. The projects
had a pretty wide range and covered about any combination of working tree
size and history size that you could imagine.  The results for full
history imports were both bad enough that neither are really practical.

I've been hitting the same wall time and time again while working on
getting people to adopt any of the three projects. Projects want as low a
bar as possible to encourage new developers. The feature set doesn't
matter because projects walk as soon as they realize that a branch for
their thousands of revisions for a branch/get/checkout can take anywhere
from 1 to 5 hours. 

Facts are less of a factor to Adoption then perception. This is obvious as
a team considering adopting a tool can not be biased by features and flaws
that are not known. Less obvious is that when considering adoption, the
perception of severity ("that's a REALLY cool feature" vs. "that's way too
slow") works as a multiplier.

Decentralized revision control systems suffer from a double whammy --
the paradigm shift from centralized to decentralized is tough for new
people to understand quickly. The drawback (cost of time) is something
they understand all too well.

And there you have it. Big perceived cost, small perceived gain. Impatient
users give up and run away. More patient users stick it out for a while
build up a better understanding of the gain and cost. Many of those run
away too because they realize they doubt that they'll be able to express
themselves well enough to change minds.

But most people just see 1+ hour long branch/get commands and run for the
hills.

One thing that minor testing tells me is that history conflation wouldn't 
help too much. My testing showed me that the twitter (multiple
modifications on the same logical lines) for Bazaar-NG over 100 revisions
is only roughly 17%. Thats a minor savings instead of the order of
magnitude that is necessary.

So whats needed for all of the RCSs that I've studied is for there to be
a primary storage that is backed by a secondary storage. Most common
operations use the primary storage (which only has a couple hundred revs)
and can reach back into the secondary storage when deeper meaning is
required.


On Wed, Apr 19, 2006 at 04:07:32PM -0700, Thomas Lord wrote:
> James Blackwell wrote:
> >The hindrance is that all of the drcs's that I can think of today all have
> >one requirement that devastates DRCS usage in projects with reasonably
> >sized  histories -- doing any useful work involves downloading all
> >history.
> >
> >  
> I do intend to reply to Ludovic separately but I should point out that 
> that particular
> comment is nonsense.  It isn't true of Arch.  It isn't true of git.  It 
> probably isn't
> true of other systems.
> 
> If there is a remote kernel of truth to that statement it is that 
> downloading all
> history enables more things than not doing so but how you get from there
> to "any useful work"... the mind boggles.
> 
> -t
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

-- 
My home page:   <a href="http://jblack.linuxguru.net";>James Blackwell</a>
Gnupg 06357400  F-print AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400

signature.asc
Description: Digital signature