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
pgp3g7Wgshjhd.pgp
Description: PGP signature
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
