[arch-dev-public] Killing CVS [was: Status Report 2007-10-15]
jason at archlinux.org
Tue Oct 16 15:18:32 EDT 2007
On Tue, Oct 16, 2007 at 12:58:49PM -0500, Dan McGee wrote:
> 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
YES! I totally agree that this is an oversimplification that I think is
> called current/testing. Right now, it sucks. We use CVS tags. Why is
> there no kernel 126.96.36.199 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
> 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.
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".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the arch-dev-public