> 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...
yeah, and the rest of the world hasn't.
anyway, my post wasn't about whether DSCM is really useful or not,
it was about who is going to review the code committed to the main trunk.
> > 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.
It's not the patching process which takes time, but the reviewing
process. It's irrelevant whether you can create a pull / merge in seconds to
a local branch, the code changed has to be reviewed before you commit to the
main trunk, which is far more time consuming.
> 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.
sure, but how relevant is that to reviewing code? knowing that
something has changed is also doable with a patch. What you want to know is
why that change was made and more importantly, what effect it had on other
code. so you have to review the change, which is what you can do with a
patch as well. It _is_ helpful if the commitlog shows which fixes were made,
why they were made this way etc.. With patches on the main trunk this is
also the case btw.
> 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.
Still you mentioned it as a big feature of git. If it's not
happening, the feature is irrelevant apparently. It can't be both.
Nevertheless, I posted because I wondered something. You now try
very hard that what I wondered about is totally nonsense as it doesn't
happen in practice. Oren, fine by me. However without strict guidelines,
it's inevitable it will happen. NH isn't ravendb.
> 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.
yeah, like I said, this will give for me a big headache so I won't
do that as I then have 2 local copies to work with, two sets of tests to run
etc.. and this thus halts progress as I then for example decide not to give
you the code as it's too much work.
For a project where 'it's nice if someone contributes' is the motto,
that's fine. For a project where 'we need these features / patches in' is
the motto, it is a problem.
> 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.
it IS your problem, because it halts my code as well. Anyway, NH
seems to be patch driven anway, so I see where you come from.
> 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.
then what are you waiting for then? Move it to github, get busy. two
days of bickering back/forth about SCMs and apparently irrelevant problems,
what's the hold up? You can't decide? There's no-one holding you back,
except me (irrelevant) and fabio (who wants hg). So go for bitbucket instead
if you don't want to pull Fabio's hair out: you get your DSCM, everybody's
happy and more devs will start devving.
FB
