JDK 7 moving to mercurial -- svn repositories

[Kelly O'Hair]

Mark Wielaard wrote:
> Hi Kelly,
> 
> On Mon, 2007-10-29 at 13:44 -0700, Kelly O'Hair wrote:
>> But the granularity of the change history is incomplete between the
>> OpenJDK subversion and icedtea mercurial repositories.
> 
> The granularity is the same between the systems. The Mercurial
> repository contains the exact same change history as the subversion
> repo.

Which is not what is in the TeamWare workspaces we had used, up until Build 23 ;^)

> 
>> All information about who made a change or why the change was made
>> has been lost in the subversion repository, all you have are all the changes
>> made between promotions, all munged together with no changesets for bug
>> fixes or feature additions.
> 
> Sure, but that is all we hackers have for the moment. If the other SCM
> doesn't provide more information than that then that is what we have to
> work with. It is still useful information if you are searching for
> changes between openjdk b[x] and b[y] to track down a bug introduced
> between versions.

Understood.

> 
>> Accurate SCM changesets should record the correct date/time the changeset
>> was created, and by who, and include the specific comments added by the
>> engineer making the change. This is difficult to get right when transitioning
>> history between SCM's.
> 
> I don't believe it is that hard to transition history between SCMs. At
> least not if it is between modern ones like subversion and mercurial
> (CVS is explicitly excluded). Yes, incomplete information in, means
> incomplete information out. If you could introduce that extra
> information into the subversion repo it is easy to pick it up in the
> mercurial repo. If not, then we manage with what we have.
> 
> All I am saying is that incomplete information is better than no
> information if you are tracking down stuff in your SCM of choice,
> whether it is subversion, mercurial or something else.

For the state of the source files, I can see your point, but most of the
developers I talked to did not consider just having the granularity of
per build changes (promotion or weekly or biweekly snapshots) to be enough.
They wanted to know who made a change, and what specific revision of a file
changed a line, and exactly when that change was created. They wanted details.
To them, change history was not change history without those details.
Having that level of detail, and also having correct source snapshot views
that mesh well with those detailed changes is not impossible, and may indeed
be easier with newer SCMs, but it is not simple to get all the details accurate.
And TeamWare did present some major problems being a relatively loose collection
of separately managed SCCS files.

Some of the major changes made in Build 20, 21, and 22 involved massive file
movements out of the j2se workspace (soon to be called "jdk"), and into
separately managed workspaces for langtools, corba, jaxp and jaxws.
Each of these TeamWare workspaces would/have become independent repositories,
but part of the jdk forest of repositories.
We did that movement BEFORE creating the Mercurial repositories because we
didn't want to create initial repositories just to turn right around and delete
10,000 files from the repository, because even though deleted, they would
continue to live on in the repository as part of the initial changesets.

So our Build 24 repositories will start out fresh, with no history, because
any accurate history (even build promotion history) would inflate the
repositories just for the sake of that history.

People may ask why we didn't just create one big workspace or repository
for the entire jdk, and that's a good question. But it came down to being able
to separately manage and perhaps independently deliver, various components
of the jdk. That decision to create a forest rather than one big repository
may come back to haunt me, which if we release our repositories on Halloween
maybe I should be haunted. :^(

-kto

> 
> Cheers,
> 
> Mark
>