I understand (at a basic level) how hierarchical workspaces work. Can't
something like child workspace be achieved by having branches? I still
feel we are talking about two different things here. What has it to do
with binary repository? Any way, my point is we should not let
development engineers upload binary to a repository that's shared by peers.
Thanks,
Sahoo
Sreeram Duvur wrote:
> Sahoo,
>
> Hierarchical workspaces have been used in Solaris and JDK development
> engineering to great effect (using Teamware). Check-ins to lower level
> workspaces can be done without much effort. Checking into higher level
> workspaces require increasingly rigorous testing to make sure that the
> changes do not break builds or cause any test regressions on other
> platforms or modules. A golden workspace at the top is always
> "production ready" i.e it always builds and passes the prescribed
> regressions. Mercurial facilitates this style of independent working
> in each module area without impacting others. I support what Bill is
> saying here: We must consider adopting distributed SCM.
>
> Sreeram
>
> On Feb 17, 2008, at 10:37 AM, Bill Shannon wrote:
>
>> Sahoo wrote:
>>> 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.
>>
>> Well, part of the point is to move away from our style of svn/cvs use
>> to the distributed SCM use that Mercurial supports. If you need some
>> background on the advantages of distributed SCM systems, I recommend
>> starting with the Mercurial book: http://hgbook.red-bean.com/.
>>
>> Too much of the traffic on this list is about how the build is broken.
>> A distributed SCM system can help isolate breakage so that one person's
>> mistake doesn't prevent others from making progress. Having
>> repositories
>> associated with workspaces means it's more likely that you'll see a
>> consistent set of sources and binaries.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>