On 10/16/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
So let me make a few salient points here:
* The SCM doesn't matter. It doesn't. We're not doing anything complicated that we need advanced features for. The *ONLY* reason we use an SCM at all for PKGBUILDs is to track history.
We keep discussing all this stuff as if we need super advanced features for PKGBUILDs and local branches, complex N-way merges, etc etc.
We don't. We need to commit, and update. That's it.
I think you may be simplifying it a bit too much. We have this issue called current/testing. Right now, it sucks. We use CVS tags. Why is there no kernel 2.6.22.10 in our core repo right now? Oh yeah, because the CVS has already been shifted to the 2.6.23 path so we can't go back and update it. That is a problem whatever SCM we move to has to overcome. I agree with Thomas here- maintaining RC branches for things like the kernel should at least be possible if we can do that, even if they do not get maintained on the main server, they should at least be able to be shared among developers. On the other hand, and I know its odd, but no one has proposed both a SCM tool and a usage pattern that sticks out to me as better than CVS. CVS, for all its shortcomings, does have one good thing that most projects see as bad- changes are tracked on a file basis, not a atomic commit basis. This makes a lot more sense for things like PKGBUILDs because packages (usually) do not depend on other changes in the repository, although in cases like a rebuild they could. So I've proposed nothing here, sorry about that. But I really think the point I made in my first paragraph needs to be addressed by whatever SCM we switch to, otherwise there is no reason to switch away from the current (but working) CVS model we have. -Dan