[wp-hackers] Switching from SVN

[Otto]

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