Should we rename the MASTER forest?

Andrew John Hughes gnu_andrew at member.fsf.org
Thu Nov 8 22:49:03 UTC 2007


On 08/11/2007, Mark Reinhold <mr at sun.com> wrote:
>
> > Date: Thu, 08 Nov 2007 19:53:21 +0000
> > From: Andrew John Hughes <gnu_andrew at member.fsf.org>
>
> > jdk7 seems a bit odd, given that presumably the mercurial repositories
> will
> > live on beyond the release of version 7.  How about simply jdk?  Or am I
> > missing some subtle point that means we can't simply mark a snapshot
> that
> > was the jdk7 release?
>
> Good question!
>
> Yes, we could tag the final changeset in each tree, but ...
>
> Our usual practice has been to freeze the master TeamWare workspaces for
> each release when that release goes final.  Successor releases, whether
> they're small update releases or the next big feature release, are
> developed in their own workspaces, which start out as clones of the
> original master.  This is, yes, different from the way that people tend
> to use centralized SCMs such as CVS and Subversion.
>
> Transposing this to Mercurial: When JDK 7 ships then the jdk7 master
> forest will be archived, and work on JDK 8 will begin in a jdk8 forest,
> which will initially be a clone of jdk7.
>
> One could argue that this practice arose in response to the inherent
> weaknesses of TeamWare, and that's largely true.  There are, however,
> at least two reasons to retain it:
>
>   - Familiarity - This counts for a lot.  We're already forcibly
>     stretching the brains of Sun engineers to transition from TeamWare
>     to Mercurial; let's not stretch them more than absolutely needed.
>
>   - Paranoia - So far Mercurial has been very robust in our experience,
>     but there is nonetheless a certain comfort in knowing that a
>     read-only, archived copy of every release forest is readily available
>     just in case something goes very wrong.  (Yes, of course we do
>     backups too, but restoring really old backups tends to be painful.)
>
> None of this is cast in stone.  If down the road we find better reasons
> to have just one big JDK master forest then we can pretty easily make
> that happen.
>
> To be clear, the URL for the JDK 7 master forests is currently
>
>     http://hg.openjdk.java.net/jdk7/MASTER
>
> but with my proposal will change to
>
>     http://hg.openjdk.java.net/jdk7/jdk7
>
> and live alongside the other JDK 7 integration forests:
>
>     http://hg.openjdk.java.net/jdk7/2d
>     http://hg.openjdk.java.net/jdk7/awt
>     http://hg.openjdk.java.net/jdk7/build
>     http://hg.openjdk.java.net/jdk7/corba
>     http://hg.openjdk.java.net/jdk7/hotspot
>     http://hg.openjdk.java.net/jdk7/...
>
> - Mark
>


Ok, I'll admit I'm still sceptical about this, but let's see how it works
out.  I don't see why we need to repeat the name 'jdk7' for master though if
it's already in the path.  Why not jdk7/jdk?
-- 
Andrew :-)

Help end the Java Trap!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/discuss/attachments/20071108/6d5dc3a7/attachment.html>


More information about the discuss mailing list