On 10/16/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/15/07, Andreas Radke <a.radke@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.