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

[eliott]

On 10/16/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On 10/15/07, Andreas Radke <a.radke at arcor.de> wrote:
> > >From what I read and talk around it seems most European devs are more
> > comfortable with svn and American devs prefer git.
>
> Heh, you forgot Canadian!
>
> Either way, I think the distinction is more like so:
> The coders tend to prefer git, while the non-coders prefer svn.
>
> I'm glad you brought this up as it's something that has gone by the
> wayside for far too long. I have basically been waiting to see how
> other discussions have gone.
>
> 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.
>
> * There will always be a discomfort when we switch these things.
> However, if all developers use devtools except in extreme
> circumstances, there's no reason this discomfort should actually cause
> any problems.
>
> * Pros and cons are useless here. As I said in the first point, we
> have no need for the advanced features based on our usage patterns.
> Sure, we can make use of them later, but right now it shouldn't be
> weighting any decision.
>
> * Changing SCMs is fairly easy. If we fuck up, we change to something
> else - I could do all the grunt work here if people see this as any
> sort of issue (it's a 5-10 line config file for tailor)
>
> ------------------------------
>
> So, here's what I'd like to do. This decision is fairly arbitrary, so
> let's try and throw out FACTUAL points FOR each SCM.
>
> I don't want to see any "X is better than Y because of Z" drivel. I
> want to see "X supports Z". Everyone has their "baby" SCM. That's not
> the issue. We need to make a decision, and opinions should have no
> place here.
>
> So. Bring up your points as they apply to our usage patterns. We'll
> discuss this until this weekend, and come next monday, I'd like to
> start a vote and see if we can get anywhere.
>
> Thanks guys,
> Aaron

The only real salient (read: non fanboy) problem I have with
subversion would be repository size.
Subversion isn't very good at keeping repo side down, and with large
checkouts this could be a problem. The arch pkgbuild repository would
grow some considerable history over time, and this may be a factor.

A work around would be to occasionally nuke history. I have no problem
with doing it for something like our pkgbuilds, since they only matter
for 'today' anyway.

Other than that, I think I have come to accept that subversion is the
'low hanging fruit' so to speak, insofar as across the board adoption.
1. It is easy to learn for the non-coders.
2. It works 'well enough' for now.
3. We *can* always change it later, like Aaron said.
4. It interfaces with git, so I can still use 'my favorite tools' with it.