[wp-hackers] Switching from SVN

[Eric Mann]

Not trying to argue away from the core committer system.  I highly support
that model because it keeps a lot of needless junk out of the repository.
 I'm just trying to explain hpw and why *I* use distributed version control
systems (in response to your original statement that you didn't understand
why people would want to).

The only reason I would ever want WordPress to move to a Git/Hg/Whatever
system would be to make it easier on developers.  As is, I *do* use my own
version control system, export to a diff when I'm finished with my work, and
upload the patch to Trac.  But that's a lot of extra work to set up, not a
clean development cycle, and makes it very difficult to distribute my
changes.  Pulling diffs down from Trac and patching my working copy so I can
test new features before their committed is also a very convoluted and
frustrating system (and the #1 reason new developers give me for *not* working
on WordPress).

A Git base system would allow us to retain a similar system to the one we
have now - lots of developers can work on WordPress and submit changes but
only a select few can commit to the central repository.  When a developer
who's not a core contributor has a patch to submit, s/he pushes the
changeset to a public location (not to trunk, but to a branch of the
repository marked specifically for a ticket) and anyone else can clone from
that branch.

It makes testing a patch as simple as right-clicking in a GUI ...

If the patch is good and the core committers decide to make it core, they
merge it into trunk.  If not, they can provide feedback and the dev can keep
working (or another dev can pitch in).  Or they could close the branch all
together.

On Thu, Dec 9, 2010 at 9:09 PM, Otto <otto at ottodestruct.com> wrote:

> On Thu, Dec 9, 2010 at 10:55 PM, Eric Mann <eric at eam.me> wrote:
> >> I work on it until it's working, then I check it in.
> >
> > Yes, this works for smaller projects.  Quick patches, adding filters,
> etc.
> >  But if you're working on a larger project and will need to step away at
> any
> > point in time, it might be too large to keep your entire thought process
> in
> > hand at once.  For example, the reason why I pitched an idea for ticket
> > 15066 but haven't written a patch yet is the size of the project.  Yes, a
> > new class will be a separate file, but as I build it I'll want to keep
> track
> > of the changes I make.
>
> Okay, so you want a local repository for your own use. I get that. Makes
> sense.
>
> But why do you want to inflict all your changesets on everybody else?
> Why not just send the final product to the root when you're done? See,
> that's my confusion here. In the examples on hginit.com, he shows how
> the local changes can be pushed to the central hub as a whole, showing
> all those local changes in the central after the push. That I don't
> understand. Why should anybody care about your local changesets? Until
> you push to the root, nobody else has to care about what you're
> working on. And when you do push, only the final product is important.
>
> And yes, Curtis pointed out earlier that this is optional with git and
> you can make it only show the overall change. But how is that
> different than now? You make all your changes using whatever local
> repo system floats your boat, then create a patch against trunk and
> send the patch. If good, patch is committed. If not, it's not, or you
> change until it is.
>
> The merging process weirds me out too. With the distributed method,
> the person doing the push has to do the merge with everybody else's
> push. But that's the same anyway, because in order for a commit to
> happen, the patch must be refreshed and merged with the latest trunk.
> There just isn't enough difference here for me to see any value.
>
>
> On Thu, Dec 9, 2010 at 11:02 PM, Eric Mann <eric at eam.me> wrote:
> >   1. First I coded for metaWeblog.editPost.  Once I finished that, I
> tested
> >   and made sure it worked.  If I were using Hg or Git, I would have
> committed
> >   then ...
> >   2. Next I worked on metaWeblog.newPost (which was very similar).  After
> I
> >   finished I tested and made sure it worked.  (I would have committed
> here).
> > ...
>
> Committed where? To your local repo? Who cares? You do, obviously, but
> committing locally is basically wanking, as far as I can see. A local
> commit is pointless unless you do actually need to revert to it at
> some point in time.
>
> And yes, that may help your development process. Everybody develops
> differently, and I fully get that. But that doesn't change anything
> with regards to the overall project. When you actually do send your
> changes back out to everybody else (commit to the central point),
> you're still committing all at once.
>
> Why can't you just run your own local repo in any way you choose,
> using any software you choose? Hell, run git locally, commit to your
> hearts content. Then, when you're done and have something worthy of
> the main core, submit a diff like everybody else does.
>
> I'm trying to understand the benefits, really, but I'm just not seeing
> it. You seem to be making some kind of assumption that anybody is
> allowed to commit to the central point, which makes no sense. A select
> group controls the central point. And you're not going to successfully
> argue away from that. Even in small teams and closed projects, the
> central repository is tightly controlled. It takes effort to get past
> the gatekeepers, and that effort doesn't go away, ever.
>
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>