JDK 7 moving to mercurial -- svn repositories

[Max (Weijun) Wang]

I think Kelly and some other guys have done a lot of experiments on  
how to turn Teamware histories into Mercurial changesets (this even  
reminds him of being a math graduate long time ago). Unfortunately it  
seems there's not a perfect solution.

Yes, throwing away the history of OpenJDK before b23 is not something  
to boast on, but, let's expect that comparing to the huge  
contributions from all Sun and non-Sun developers after b24, the  
changes before b23 is only a tiny except of the long history/future  
of OpenJDK. We won't lost much.

If someone really want to look into there, for archive or memorial  
purpose, the current OpenJDK Mercurial repository managed by IcedTea  
can stay forever.

Max

On Oct 31, 2007, at 2:23 AM, Kelly O'Hair wrote:

>
>
> 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