On Tue, Oct 16, 2007 at 12:58:49PM -0500, Dan McGee wrote:
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
YES! I totally agree that this is an oversimplification that I think is untrue.
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.
Yes!
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.
Agreed. That's why I haven't made any recommendations, though the closest was that slightly modified svn suggestion. I'm glad that someone else understands what I've been saying.
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.
I can't make a good suggestion right now either. I'll help people flesh out ideas because I've thought about this lots, but sometimes I feel like people think I impeed things unnecessarily. If we run into problems later with a solution, I know I'll feel like saying "I told you so". Jason