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