 |
Migrating from TeamWare to a new SCM
Posted by martin on September 27, 2006 at 02:39 AM | Comments (3)
As
Mark
pointed out,
I'm investigating the technical details on how we should migrate from
TeamWare
to a more recent
SCM.
At the moment I'm busy gathering data about
Mercurial
to determine the impact it will have on disk usage and time it takes to bringover
(the TeamWare equivalent of the Mercurial clone command).
I am also working with
Kelly
on how we should go about an migrate all information in TeamWare and SCCS
to Mercurial.
Right now I'm not worrying about non-technical details,
e.g. if the SCCS comments are encumbered,
i.e. if they contain information which can not be open sourced.
I've written a simple
Perl
script,
reusing what
Steve have done for OpenSolaris,
which allows me to iterate over all SCCS revisions,
and do a "hg add" of revision 1.1 and then "hg commit" on all the following revisions.
Doing a simple migration like that is not a problem,
but we'd like to group each TeamWare
putback
into a
change set,
and that requires some magic.
One problem is that TeamWare records time in local time of the
engineer who ran the "sccs delget" command,
so when you have many engineers working on code that gets integrated
at the same time, we can not use the timestamp to group the entries.
Another problem is that the Java SE source have had very relaxed
requirements on the SCCS comments,
especially if you compare it to
Solaris.
Lately it has gotten a lot better,
but it is far from as stringent as what you find in the
ON RTI process.
You can find other random notes about Mercurial on my
other blog.
[Technorati Tags:
Java
SCM
Mercurial ]
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Being a non-sfbay guy, I hope you've already considered cross-continent bringover/putback performance issues.
Posted by: weijun on September 27, 2006 at 08:14 AM
-
Yes, the distributed part of the new SCM is a very important part of the equation.
First of all, we tried a bringover (clone) over VPN and DSL, which took about 8 minutes for the whole of the JDK, secondly we plan to put clone gates at all major development sites.
I'm also a remote developer, so I suffer from the TeamWare bringover sluggishness too, and will be very happy if we chose Mercurial.
Posted by: martin on September 27, 2006 at 09:35 AM
-
I have a similar Perl script that takes changes from ClearCase, collects them into change sets, and imports into some other SCM system (several possible targets). I am using the commit message (check-in
message) together with a time windows to build the change sets.
The
tricky part is that there may be dependencies, e.g. if you have two
changes to the same file with a comment of "cool feature X", then they
cannot be rolled into a single change set (they were different changes
to the *same file*). Also I want to preserve the ordering, so I want to
collect the change sets roughly in chronological order, but still if one
change set is dependent upon another (because that other had
changed the same file at a lower rev) I want to respect that.
I think I could share my script if you are interested. Let me know.
Posted by: gwk on October 02, 2006 at 02:17 AM
|