inline On Thu, Nov 4, 2010 at 2:01 PM, Frans Bouma <[email protected]> wrote:
> > On Thu, Nov 4, 2010 at 1:07 PM, Frans Bouma <[email protected]> wrote: > > > You are confusing theoretical problems with actual problems. > > I don't think I do. > > > > You keep bringing up potential problems, and you ignore me when I tell > you > > that they don't occur or rarely occur in practice > > Time will tell, Oren. Sourcecode management, or better, what's the > 'real current version' isn't a problem which is related to the used SCM. > > Um... I have been doing this for a while, you know... > > All of them work on their own repo. > They send me a pull request, and I pull their changes to the main repo, > after reviewing / testing / modifying the code. With a DSCM you pull changes the user has pulled from others as well, you need to avoid those, but if the user has to do that for you, what's the difference with creating a patch in svn for the main trunk? I already described the difference. I can apply a pull request in seconds, patch takes minutes. Also, who on the main committers list is going to review code pulled from others if it matches the rest of the code of NH? So it matches a codeing standard, doesn't introduce clones, doesn't do things already there, has no documentation etc. Whoever it is who have pulled the code to his local repo. Remember, only committers can push to the main repo. If I pull changes from John and John isn't a main committer, and you pull changes from my branch, you get John's changes as well. And the problem here? The history is preserved, and I can see all the changes. > You then have to review those as well. That's something you have to deal with. Beside. I have been doing this for a long while now. It doesn't happen. > If John's a crappy coder and I don't give a hoot, you have to decide if John's stuff is necessary for my changes. Yep, I tell you. There is crappy stuff there, give me a clean branch to pull from. > As you pull from me, I'm responsible for the patch, as it's all in my patch, but as I don't care (example) it's harder to apply my patch to the main trunk because of John's work. Not my problem. If your patch relied on John stuff, and John's stuff is not up to snuff. Then your pull request will be denied. > So it comes down to: accept everything, thus also john's code, because my tests worked (but john's crap code is in there too) vs. reject everything and tell me to clean it up first vs. you do the cleaning. Yes, that is pretty much it. If I use a central trunk repo, John's changes wouldn't have been in my changes, as I change on the trunk's repo and send a patch. John's patch, as he's a crapcoder, was rejected (or never even sent), less work for the maintainer who looks at my patch. Or, as happen very often, users don't really pull from one another, only from the main repo. IMHO the central trunk works better for this, because it's easier to apply patches to a main trunk for the main committers: John's drivel was filtered out without looking at my patch. Throwing out my patch because John's goo was in there too is also easy, but that halts progress. I am sorry, but you are talking theory, while I am talking practice. One last time, I *have been doing this* for a long while. None of your problems cropped up. And the whole experience is much nicer. I'm aware how it works Oren, the concept of feature branching isn't something unique to DSCM. I wasn't talking about 'if it works', I was talking about the quality of the code being pushed to the main repo. What feature branch? Your master branch has John's changes + yours. I refuse John's changes and tell you to setup a clean branch You create a branch for this pull request, and I pull from that to my, then to the main repo's master.
