1 |
On Friday 28 April 2006 20:14, Ryan Phillips wrote: |
2 |
> __Problem: Live Tree__ |
3 |
> |
4 |
> Having a live tree requires people to be perfect. People are not perfect |
5 |
> and requiring it is ridiculous. I love having commits in my local tree |
6 |
> within the hour, but having a stable and unstable branch makes a lot of |
7 |
> sense. |
8 |
> |
9 |
> CVS doesn't do branching nor tags very well... |
10 |
> |
11 |
> __Problem: CVS__ |
12 |
> |
13 |
> CVS is one of the worst application ever created. The portage tree needs |
14 |
> to move to subversion. A lot of the problems within the project would be |
15 |
> solved by using a better SCM system. The previous problems regarding the |
16 |
> Live Tree and Developer Growth would be solved, IMHO, by just switching. |
17 |
> Branches Work. Tags Work. Reverts work. Moves work. I don't see any |
18 |
> reason not to use it. It just plain works. |
19 |
> |
20 |
> Projects (gentoo/bsd, embedded, hardened) could choose to keep their own |
21 |
> branches of the portage tree and merge with trunk as needed. Projects |
22 |
> could stick to traditional solutions like profiles if they so wished. |
23 |
> |
24 |
> Some will probably ask who will merge between branches. We can do that |
25 |
> easily ourselves. If I think a package is good to go, then svn merge |
26 |
> -r1123:1124 to the branch. |
27 |
|
28 |
I'm very much in favor of moving to a new SCM, and I see how it could solve |
29 |
many problems. But I don't understand how it could remove the need for a live |
30 |
tree. Could you explain the new usage pattern you're suggesting here? |
31 |
|
32 |
If there's no live tree (or live branch), then every commit has to be merged |
33 |
from the 'incoming' branch or trunk where it is originally committed to |
34 |
the 'outgoing' branch which is directly used by users, even for ~arch chages. |
35 |
Is that really what you mean? |
36 |
|
37 |
And this becomes a lot worse if you want to replace (at least some) KEYWORDS |
38 |
with branches, and have to merge each change many times. |
39 |
|
40 |
Meanwhile, if no-one is using trunk (or the 'incoming' branch) directly |
41 |
(because it's not live), what is the benefit of leaving commits there for a |
42 |
few hours? It won't help you find most problems. |
43 |
|
44 |
|
45 |
Apart from having no live tree, though, I understand and like the model of |
46 |
having: |
47 |
- 'Incoming' (sandbox) branches where non-dev affiliates, and new devs, commit |
48 |
things which are then reviewed by a full dev/mentor and merged into trunk. |
49 |
- Branches replacing today's various overlays for devs (or projects, etc) and |
50 |
anyone else we might welcome on g.o infrastructure (given per-branch commit |
51 |
permissions). |
52 |
- Short-lived branches to replace things that are today package.masked. |
53 |
- Branches to replace various non-arch keywords and projects, like hardened |
54 |
stuff, some server/ultrastable tree proposals, ... |
55 |
|
56 |
-- |
57 |
Dan Armak |
58 |
Gentoo Linux developer (KDE) |
59 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
60 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |