On 04/28/2011 10:31 AM, Tommaso Cucinotta wrote:
Il 26/04/2011 20:14, Julien Rioux ha scritto:
I don't feel the need to move to git. At all.
I'm seeing 2 discussions merged, in this thread:
1) what development model to use (how many branches, what & how often
to commit where, what & how often to release, etc.)
2) what development tools to use to implement (the proposed changes
to) 1).
I think this is exactly right. And we should decide (1) before we decide
(2).
AFAICS vfr is actually asking for a lower number of merges into trunk,
with more testing made on alternate experimental branches, till the
features are rock stable, then merge them as a single (or a reduced
number of) commit. AFAICS, this can be done with svn as well as with git.
While I can share his viewpoint, as he's going through all of the
patches (!), I also suspect this will lead to a lower number of
developers having the chance to try a feature before the merge into
main trunk, because it's being developed in an alternate branch, and
I'm not sure everybody wants to download and synchronize tens of other
branches, with all the burden for compiling each one of them (unless
you have a 48-core over which to do that).
Concerning the fragmentation of a feature into multiple patches, I'm
suspecting the point is not actually in svn vs git, but rather the key
is in the proper use of other tools (e.g., quilt or who knows what
else) which help in "managing patches".
A while ago I wrote a set of scripts that helped me manage development
in svn branches. I.e., merging trunk into the branch, and so forth. It
may be that git makes this sort of thing easier, but, obviously, it's
not as if this kind of thing can't be one in svn.
I'll also note, with some bemusement, that I started XHTML development
in an svn branch, and then everyone told me not to do that but just to
do it in trunk.
Richard
