| 1 |
Ryan Phillips wrote: [Sat Mar 25 2006, 01:47:51AM EST] |
| 2 |
> It sounds to me like the overlays would benefit of using git/cogito. |
| 3 |
> The Linux Kernel uses this DVCS to full affect. Pulling changes from |
| 4 |
> other repositories, and even receiving email patches pushed from |
| 5 |
> people not having their own official repository (or repository http |
| 6 |
> or ssh accessible). Any git checkout is a branch, so its easy to |
| 7 |
> stay up to date with the mainline tree and still work on personal |
| 8 |
> branches. |
| 9 |
|
| 10 |
Most of the other DVCSs are easier to use than git, and just as |
| 11 |
powerful or more. IMHO git is used for Linux mostly because Linus |
| 12 |
wrote it, rather than it being the best tool for the job. |
| 13 |
|
| 14 |
I think any of mercurial, darcs or bazaar-ng is a better choice than |
| 15 |
git. Regarding cogito, I haven't looked at it in a while, but the |
| 16 |
last time I did, it was underpowered and buggy. AFAIK none of the |
| 17 |
kernel developers use it, 'cause it doesn't hold up under serious use. |
| 18 |
|
| 19 |
> We need to pick one VCS and only one. Having multiple systems |
| 20 |
> requires users to install multiple applications and learn each one. |
| 21 |
> Not all of them are easy to pick up. Plus, it would be nice to be |
| 22 |
> able to merge from the overlays to the Portage trunk. |
| 23 |
|
| 24 |
This would be pretty neat eventually, to switch portage itself over to |
| 25 |
a DVCS so that all the overlays would simply be branches that could be |
| 26 |
merged, etc. At this point it would be biting off more than we can |
| 27 |
chew, though... Perhaps using various DVCS solutions for the overlays |
| 28 |
might actually be a good testing ground for determining the successor |
| 29 |
to cvs for the actual portage tree. |
| 30 |
|
| 31 |
At any rate, I don't think it's necessary to limit ourselves to one. |
| 32 |
You're right, developers will have to install multiple applications |
| 33 |
and learn each one for the overlays they work on. Probably it won't |
| 34 |
be that many, though (overlays or applications) and r/o users will |
| 35 |
likely just get an rsync'd copy instead of using the DVCS to access |
| 36 |
the overlay (at least that's how I imagine it working...) |
| 37 |
|
| 38 |
> I think git/cogito might be the solution. It works for a highly |
| 39 |
> distributed kernel development, which would be similar to the way |
| 40 |
> the overlays would work. Gentoo User A would checkout the kde |
| 41 |
> overlay, make some changes, cg-commit them to their own overlay, and |
| 42 |
> submit the patches upstream via an email requesting a pull, or |
| 43 |
> emailing them patches directly with a git-mkmail command. |
| 44 |
|
| 45 |
*shrug* All possible with the other DVCSs, generally easier to use, |
| 46 |
and harder to screw up your repo. |
| 47 |
|
| 48 |
> An alternative to git would be using subversion. |
| 49 |
> |
| 50 |
> *** The main portage tree should be switched away from CVS. *** |
| 51 |
> There are much better alternatives (svn or git) to use. |
| 52 |
|
| 53 |
Have you followed the threads in the past regarding using other |
| 54 |
version control systems for portage? Some devs have done benchmarks |
| 55 |
and found that there are blocking issues with subversion, particularly |
| 56 |
because of its repo-wide revisions that prevent multiple commits from |
| 57 |
happening simultaneously. |
| 58 |
|
| 59 |
> CVS is our bottleneck when it comes to development and our users |
| 60 |
> too. What I see is that the overlays are trying to create branches, |
| 61 |
> when they should not need to. Making a PHP or Gnome v2000 overlay |
| 62 |
> is ridiculous, since a branch is almost free using subversion. |
| 63 |
> There are more advantages, like making sure the rest of the tree |
| 64 |
> doesn't break, and when the branch is stable for package.mask or |
| 65 |
> arch masking then merge the branch to trunk. The main tree could |
| 66 |
> live within subversion (or whatever VCS we choose) as a branch. It |
| 67 |
> would be easy to keep the branch up to date with trunk, and then |
| 68 |
> merge the changes to the live branch. Major changes to the tree |
| 69 |
> need to be done in a branch where it should be done. |
| 70 |
> |
| 71 |
> Overlays should be used only for small additions/changes/or tests. |
| 72 |
> It feels like the overlays are already trying to create branches, |
| 73 |
> when in fact, they would not have to if the main tree was _not_ in |
| 74 |
> CVS. |
| 75 |
|
| 76 |
I agree this sounds really nice and makes a lot of sense. I think |
| 77 |
that the overlay project is a step toward this, though, not a step |
| 78 |
away. The time isn't yet ripe for switching the portage tree to |
| 79 |
different VCS. |
| 80 |
|
| 81 |
> Comments? |
| 82 |
|
| 83 |
I guess you asked... :-) |
| 84 |
|
| 85 |
Aron |
Archives