Strategies for push/merge problem?

[Sean Kelley]

Hi

On Mon, Jul 14, 2008 at 5:50 PM, Alpár Jüttner <alpar at cs.elte.hu> wrote:
>> >> > Of course that is assuming a very CVS point of view that you
>> don't need to bother to check/test the result of the fetch. Perhaps if
>> the person doing this is getting emails from the central repo, they
>> can know that things won't break...
>> >>
>> >> The only answer that actually scales is: don't use push.
>>
>> The hard part about the pull model is one of resources.  How does one
>> manage a pull model with 100s of repos and 100s of developers?
>
> Do you really have 100s of developers in a flat structure with no
> hierarchy at all?

Yes, we do.  They are all team focused with many product teams.  In
fact, many of these projects they work on are applications, daemons,
utilities, vendorsrc and other projects that make up embedded Linux
products.  We use the a modified version of the PokyLinux
(www.pokylinux.org) build system to pull from HG repos via tags.

> I think there should be some "modules" or "components" defined, and also
> with someone responsible for the development of each of those parts of
> the software. These maintainers will collects (using 'pull') the
> changesets that affects their territories. Then, a global maintainer
> will synchronize only with the components' maintainers.

I don't believe that is realistic with developers working on many
different and varying projects.  In our case, no one 'owns' particular
repos.  On any given day of the week, you may be working on different
products that have varying projects that make up its build.  It would
be incredibly unproductive to tether someone to a particular repo that
may only be used once for maybe three products.  We are an enterprise
level development house that pushes out embedded products.

>
> It is also important, that 'pulls' operations do not have to be as
> frequent as the commits.

Our repos are hosted on a remote server.  SSH keys are used for remote
push/pull access.  Ultimately, even if a developer 'owns' a repo, he
still has to push to it.  There are no 'user' level repos on the
remote server.  Everyone works off of their Linux workstations and
pushes to the remote repos.

>
> Finally, the "frequent commit" policy is probably a legacy of the
> locking model revision systems. Using mercurial, you will typically find
> it much better to commit larger block of changes, and synchronizing your
> repository even less frequently, for example when you more-or-less
> completely finished implementing a new feature.

We do frequent commits because we push out many products a year and
have many many projects in development requiring frequent changes and
releases.


>
>> For us, the push model is the only way.
>
> I hardly believe this.
>

The pull model is just incredibly impractical at the enterprise level
for embedded Linux product development, in my experience.

Regards,

Sean

> Best regards,
> Alpar
>
>
>