Sorry, I don't see the connection between our style of use of svn/cvs
and the need for development engineers to stage binaries in any kind of
shared repository.
Thanks,
Sahoo
Bill Shannon wrote:
> Moving to Mercurial (or rather, moving to a distributed SCM
> development style)
> should help us solve this problem. As I remember, here's how Solaris
> deals
> with similar issues...
>
> Below the master workspace are a bunch of integration workspaces (gates)
> used by different teams. Each workspace has associated with it a set of
> already built binaries corresponding to the sources in the workspace. A
> developer's workspace might have only one or two modules in it, but will
> depend on the prebuilt modules in the parent workspace. A developer
> would
> only publish binaries to his own (local) repository. The integration
> gate
> keeper would publish binaries to the repository associated with the
> integration gate. Only release engineering would publish binaries to an
> "official" public repository. (Although each of the integration
> repositories
> would also be available to the public, they just wouldn't correspond
> to any
> well-defined release of the product.)
>
> This is a grossly simplified description of what I think we should be
> doing.
> The key is that there is not just one workspace or one maven repository.
>
> This approach provides a consistent set of binaries for use by developers
> while isolating developers from unexpected changes.
>
> Hopefully we'll soon publish our plan for how we're going to manage our
> Mercurial workspaces. We can learn a lot from how OpenSolaris and
> OpenJDK
> are managing their workspaces.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>