[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Google Summer of Code
From: |
Aldrik KLEBER |
Subject: |
Re: [Gnu-arch-users] Google Summer of Code |
Date: |
Thu, 20 Apr 2006 12:15:48 +0200 |
User-agent: |
KMail/1.8.3 |
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
pgpVcf46zwIPA.pgp
Description: PGP signature
- [Gnu-arch-users] Google Summer of Code, Andy Tai, 2006/04/18
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/18
- Re: [Gnu-arch-users] Google Summer of Code, Ludovic Courtès, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, James Blackwell, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, James Blackwell, 2006/04/19
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, James Blackwell, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code,
Aldrik KLEBER <=
- Re: [Gnu-arch-users] Google Summer of Code, Stefan Monnier, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Aldrik KLEBER, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Aldrik KLEBER, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/20
- Re: [Gnu-arch-users] Google Summer of Code, Stephen J. Turnbull, 2006/04/22
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/22
- Re: [Gnu-arch-users] Google Summer of Code, Stephen J. Turnbull, 2006/04/23
- Re: [Gnu-arch-users] Google Summer of Code, Thomas Lord, 2006/04/23