[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]

[Dan McGee]

On 10/16/07, Aaron Griffin <aaronmgriffin at 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