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

[James Blackwell]

Thanks for the reply! I always look forward to your pearls of wisdom. =)

I'll stick to the technical aspects of your post. I don't feel comfortable
commenting upon my previous employer. I recommend that you contact them
directly if you have any questions. More clearly: I'm not part
of "you folks at Canonical." and have not been since 3 April. =)

Speaking of which, I'm looking for a new employer in this dog-eat-dog
world. I've had some successes in making some appointments but haven't
gotten anything solid yet. I think that my resume needs further grooming
to get the fluffy stuff right. What recommendations do you make? Its at:
http://jblack.linuxguru.net/~jblack/resume/ 

My previous post was about revision control systems in general with some
hints on how smart pruning could be a way for gnuarch to regain the
logical lead what gnuarch could do to take over the DRCS world. 

I'll have to rely on the experience of others as concerns GIT. 

I'll amplify and clarify upon my previous posts in the hope that you can
better understand. :)

 1. Over the last almost three years I've worked on trying to get dozens, if
    not hundreds, of projects migrate to one DRCS or another.

 2. New CVS and Subversion adoptions are both much, much, much more common
    then all of the decentralized revision control systems combined. 

 3. Decentralized Revision Control Systems generally require the downloading
    of much more data than Centralized Revision Control Systems. A
    get/branch under most any drcs takes some multiples of time than a
    equivilant CVS/SVN checkout.

 4. Most decentralized revision controlled systems are not geared to work
    well with limited history. Gnuarch is.

 5. Part of the work for gnuarch is already done when it comes to avoiding
    the copying of revisions. Outstanding is a modification to tag that I
    introduced a long while back that would be smarter about copying
    revisions.
      1. I'm referring to the modification that I made in tag that does a
         full copy of a branch if its tagged from a foreign archive.
      2. Tag should behave differently. Instead of augomatically
         cachreving if a foreign branch it should say something like
         "Warning: This tag refers to a foreign branch. Please see 
                   tla help tag for details on this message and how to
                   protect against it"
 6. Record the ancestry with every commit. Don't copy Bazaar-1.x. As its
    not done right.
 7. Automatically prune all patchlogs that have been around for more than
    50 revisions. That should be enough to find good ancestors for merges
    and such. Perhaps a tunable variable on a branch per branch basis
    would make sense.
 7. For operations that need to go back further, get it from the last
    revision to have it. It'll cost more, but won't be as necessary.
 8. Ensure that cachedrevs have all patchlogs.

These steps performed properly should give a very solid performance
improvement for reasonable operations. Revisions will be smaller, things
that require tree scans (including commits & merges) will also go much,
much faster.


> Without downloading all of history one can, using Arch, form
> a local "vendor branch" (in CVS terms), do updates to that branch,
> form a local branch, modify that branch, do smart merging, post
> changes....   on an on.
> 
> The only history one needs to download for these purposes are the
> base revision and merge "pivot points" one actually needs.
> 
> As you presumably know.
> 
> As far as I know, similar truths hold for git.
> 
> As you presumably know.
> 

> >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.
> >
> >  
> As near as I can tell, you folks at Canonical went off and did something
> that made no sense and got bad results.  Well, congratulations on that.

> >Facts are less of a factor to Adoption then perception. 
> This does, suddenly, appear to be your religion.

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