[wp-hackers] Switching from SVN

[Ankur Oberoi]

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.

you're right.

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.

its diff because for the individual, merging the changes that occurred in
trunk because fast and easy, and the right person for the job is doing it
(namely the person who knows where their code has impact and where it
doesnt). this directly impacts how many 'not so good' patches the maintainer
should see. the truth is that if distributed isn't your style, your workflow
doesnt change at all. the flexibility for others is nice though.

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.

not exactly, thats a lot of what your used to with central vc speaking.
basically your job as a maintainer becomes the following: pull request comes
in, you look through the code and see if it verifies fine. it does great,
merge. another pull request comes in, it looks like it works great with what
they have, so merge. but wait it doesn't play nice with what the person who
i just merged with just gave me, okay i'm not going to waste any time on
solving this, he wrote the code so he can do it ant then ill look at it
again. and then u keep going..." merging just becomes a simple job that can
happen almost daily. like checking your email. you get involved at some
major milestones to do more thorough testing. you'll probably make the
community more active by having regular updates.

On Fri, Dec 10, 2010 at 12:09 AM, 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
>