Re: Google Summer of Code

Le Jeudi 20 Avril 2006 11:56, James Blackwell a écrit :
> 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.
>

Having history permit merging. Better than choosing what isn't necesary for 
now through a number of revisions expiration, we can for example choose when 
doing a merging or a tag if we want to integrate history or not.

This can be interesting for cycle branch like a functionality branch.
For example with a alpha branch, when we tag to a beta branch, an option 
--no-history  can be interesting, i order to suppress only this branch 
history when merging or tagging.

Or when we merge a branch like bug-798, when we merge it

If we make 
tla export
tla import
We delete past history, and all history.

After we have : tla remove-log-version

That's why a simple option can be enough to automate more, and we have the 
possibility to delete logs in tla, so tla don't miss a lot of thing to manage 
well size history. IMHO



Aldrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBER19bjb5cY0n/yTgRAut2AJsHzvsAzg7m0SMK3jm6C/zC+BnBMgCeMue5
0ZFKGqo8a6laALojFenQm5E=
=YH5+
-----END PGP SIGNATURE-----