[wp-hackers] Switching from SVN

Ankur Oberoi aoberoi at gmail.com
Fri Dec 10 05:35:27 UTC 2010


also for somewhat larger changes, if a team of people want to work on it
together before someone higher up looks at it and gives it time of day, all
that is soo much easier with distributed. right now i think a larger change
would just be shunned because its too much effort to merge properly.

basically it helps the individual by making their code more current (by
making merges easier) and the maintainer by spending less time on patches
that need to be revised (aka bad).

On Fri, Dec 10, 2010 at 12:26 AM, Piyush Mishra <me at piyushmishra.com> wrote:

> it roxx for testing also. unless someone mentioned it already, I can fork
> the main and push my tests to my repo. people from all over can test what I
> made directly and the guys incharge of the main repo can merge my branch
> anytime. yay!!
>
> On Fri, Dec 10, 2010 at 10:53 AM, Ankur Oberoi <aoberoi at gmail.com> wrote:
>
> > 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
> > >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
>
> --
> Regards
> Piyush Mishra
> http://www.piyushmishra.com/
> Life's Short, Live it to the maximum
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


More information about the wp-hackers mailing list