[wp-hackers] Switching from SVN

[Piyush Mishra]

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