Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")

[Alexander Best]

On Mon Jan 24 11, Garrett Cooper wrote:
> On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy <peterjeremy at acm.org> wrote:
> > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" <simon at nitro.dk> wrote:
> >>Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful?
> >
> > Can cvsup-master still lose atomicity of commits?  I suspect it can,
> > in which case syncing directly off the SVN master would seem a better
> > approach.
> 
> I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I
> wonder if it's time to look at another solution to this problem as
> these annoying stability issues don't appear to be going away. What
> about git?
> 
> Just some things I'm able to rattle off that come to mind with git..

it would also be nice to have github running on freebsd.org. that way it would
be much easier to discuss src changes without having to point people at a file,
a function or even a specific line. also it would finally kill the
mailinglists, which have lots of issues: spam, broken mailman installation,
people going berserker when they see lines > 80 etc. there have been a few
attempts to introduce a code review system, but since that was all hosted on
foreign websites the idea never cought on and afaik those websites weren't
being supported/promoted by freebsd.org.

but personally i don't expect a change like this to happen in the near future.
basically most of the freebsd administrative people are quite conservative. i
wouldn't be surprised if some them are still trying to run freebsd on their
typewriters. ;)

cheers.
alex

> 
> Some arguments `for git'...
> 
> 1. One tool to rule them all:
>    - cvsup/csup can be replaced with git archive [1].
>    - cvs git scales a bit better.
>    - less support cost for p4 and lower likelihood of downtime in the
> event of critical failure (perforce's proprietary DB is a pain to
> recover I've recently discovered from other dealings).
>    - svn <-> cvs exporter is no longer required as it's all one SCM.
>    - As a side-effect, the bits present in CVS and SVN would now be
> 100% in sync, unlike cvs which can lead svn in terms of commits (at
> least that was the case when I last talked to someone about version
> numbering in pkg_install done by re@).
> 2. More evolved tool:
>    - branches are cheap and can be local or remote.
>    - distributed SCM seem to work well with large groups of developers.
>    - works better with branching and merging from what I've seen.
> 
> Some arguments against git...
> - The one caveat to cvsup/csup that's awesome is its componentization
> capability, i.e. being able to selectively download components in src
> / ports; I'm not 100% sure but there doesn't appear to be a clear
> analog in git. It might be achievable through gits remote.<group> in
> git-config, git-remote, etc, but I would need to prototype whether or
> not this is true.
> - Higher learning curve.
> - Some slightly annoying nits with stashing local changes when working
> on separate branches (need to talk to git maintainers).
> - <More items might be here>
> 
>     Some more git experienced folks could comment here, but it would
> be nice to unify all of the systems under `one flag' for the sake of
> simplicity and hopefully the sanity of the tool maintainers (Simon, et
> all).
> Thanks!
> -Garrett

-- 
a13x