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 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.
Actually, I don't think this is a problem the SCM should HAVE to overcome if we do our repo maintenance scripts properly. The SCM should not be tracking what is current/testing/etc. The repository manager should know what's CURRENT and should be pointing to the proper SCM version. This is the design in repoman. I believe right now we are really burdened because this division between repo maintenance and SCM is not optimal. - P