On Fri, Sep 10, 2010 at 12:43 AM, Joshua Jensen
<jjensen@xxxxxxxxxxxxxxxxx> wrote:>>
>> Presumably you had exactly the same problem in perforce, i.e. because
>> you only had have the files you were changing checked out in Perforce
>> in the time between `hack&& pull&& test&& push` someone else might
>> have already pushed. Thus what you just submitted wasn't guaranteed to
>> pass tests.
>>
>> So is the flow in Git where you don't run the tests again, rebase and
>> push and hope for the best any different?
>
> The end result is the same; submitted code is never really tested against
> latest in Perforce either. The primary difference between the two is that
> the Perforce submit is successful the majority of the time (odds of someone
> editing and submitting the same file as you are low), and the Git push fails
> the majority of the time.
>
> Don't get me wrong. I've given training on why Git's enforced
> pull-before-you-push model can be better than what we had before
> (reproducible state, fewer broken builds, etc). Nevertheless, the issue is
> very frequent, and that's why I am querying others.
I am not sure that git does enforce a pull before push model, except
if you attempt
to use git without the equivalent of a maintainer - in essence
devolving responsibility of maintaining the tip of the shared branch
to the whole team.
This is probably the cultural shift that is hardest for enterprises to
accept - why do I need a _person_ to do this _manual_ work when tools
like {insert favourite non-DVCS here} can do this for me? To
management, this looks like a step-backwards.
In our case, the team leaders act like the subsystem leads and the
build team acts like the maintainer. Team leads have a more review
oriented focus, where as the build team doesn't understand the code
that well and will reject merge conflicts if they are non-trivial.
Their focus is just to keep the daily build rhythm going.
If you don't have a maintainer role, then everyone is obliged to pull,
test, pull-again, then push because there is no-one else there to do
it and no other time to do it. The delays inherent in the test process
inevitably mean you have to cycle several times until your commit
wins.
But with a maintainer role on your project, you don't need to do this.
Everyone develops on yesterday's baseline and verifies that they don't
regress anything with respect to that baseline - there is no
requirement to certify against the bleeding edge of the integration
stream - that's the role of the maintainer/build team once the daily
build is done, thereby amortising test execution effort across the
whole team.
>
> I'm grossly oversimplifying the process, but the Linux model seems to be
> built on hierarchical 'pull requests'. I can tell a subsystem maintainer I
> have some changes and then ask that maintainer to pull them from a certain
> location. When that person has time/inclination, the change is pulled,
> merged in, and then another pull request is sent to the upstream hierarchy.
>
Note that one difference between the maintainer and maintainer-less
model is that the tip of the reference branch is published relatively
rarely - it is quite stable. This is quite helpful because the
baseline doesn't keep shifting every 30 minutes. In the
maintainer-less model, you never have stability, nor any opportunity
to acquire it.
> This _is_ compelling, but even if it would work within the company I work
> for, it is such a dramatic shift in workflow that I am certain it could not
> be done in one fell swoo
>
The big difference between commercial work and open source projects
like git and linux is that the latter have just one constraint -
quality whereas the former also have budgets and schedules to worry
about. Unintegrated crap code has cost the open source project almost
nothing. Commercial enterprises, on the other hand, pay lots of money
for people to develop code whether it is crap or otherwise. The idea
of leaving expensive code unintegrated causes management paroxysms of
concern that are hard to ignore - a tool that blindly integrates crap
code automatically is a soothing balm for such people. Hence the
resistance to tools like git that encourage a maintainer role and,
implicit in that, the possibility of review that might result in crap
code being exposed for what it is.
jon seymour.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html