llvm dev - Jul 2011 - [LLVMdev] git

> After git, mainline will still be the most important branch for the
> *project*,
> but you will work with quite a few branches on parallel.
>
>
Who's mainline? :) Be prepared to assign a super-merger, like Linus, to
maintain the "mainline".

The git workflow works really really great, but it does require getting rid
of mainline thinking. It doesn't exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/fb3584ab/attachment.html>

On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes
wrote:
> One thing that I wanted to see (and probably missed, because I didn't
> read all the thread) is to discuss the workflow. I'm under the
> impression that not all regular LLVM developers understand the
> implications for the LLVM community of migrating from a central VCS to a
> distributed one, on terms of developer workflow, group management,
> etc. We should make those details explicit just to avoid surprises.
You know, this is exactly the crux of this whole "move to git" thread.
It is the very same problem of every other VCS migration I have seen (or
dealt with). The core issue here is that you are effectively telling us
that the current workflow is not supported by Git. You are also telling
us that the current workflow is in some way wrong or misguided or
suboptimal and has to change. Let's avoid all the religious argument
about how distributed version control is somehow better than
centralistic version control. What are the precise gains from changing
the status quo? What can you do by moving everything to Git that you
couldn't do in the current world with svn as master repository and the
additional git mirror?

If the argument is "I don't like svn", it is weak. Others
don't like Git
and would prefer Mercurial. Or Bazaar. Or maybe even Perforce or CVS.

If the argument is better branching, I would like to see it clarified
for how this improves the workflow. I have dealt with many open source
projects and many VCS variants. I don't see a noticable improvement from
using Git compared e.g. to SVN for sane usage of branches -- be it
short-term feature branches, mid-term restructoring or long-term release
branches. The exception may be doing wild cross branch merging and long
dependency chains between branches like done in the Linux kernel -- but
I don't think that's a sane development model and I certainly don't
see
that agreeing with the development policy of LLVM.

If the argument is doing detached development, that is already possible.
Approaches include the Git mirror, SVN mirroring solutions etc.

Advocats of DVCS tend to ignore the cost of the move. The linear commit
graph and associated properties is the biggest one. This can be dealt
with as part of a defined workflow, but that is far more work than just
saying "use tool XXX" and I don't see this happening yet. At least
on
that point, we both agree.

Joerg