Martin Hollmichel wrote:
Jens-Heiner Rechtien wrote:
Hi Martin,
since almost all OOO300 CWSs (for the RC) will be integrated into
DEV300 as well it makes sense to have most of them already integrated
into DEV300 before starting the migration. Also there are some quite
huge CWSs currently in the queue which will go into DEV300 today or in
the next few days.
The current plan is to have all the cws for 3.0 rc ready this week
(today or tomorrow).
Currently it looks like that DEV300 m31 (the next DEV300 milestone)
could be a good basis for migration.
yes, but I think we should coordinate and announce this on
[EMAIL PROTECTED]
Ok.
I would suggest that we wait until DEV300 m31 is done and finished and
then start the migration. If all goes well this could be next Monday
and DEV300 m32 would already be on Subversion (expected about a week
later). I think we could also have the necessary documentation in
place when DEV300 m32 is published.
how many days of SCM outage are you calculating for the migration ? Will
there be the possibility to work still on open cws during the migration
? Will there be an outtage for CVS or will just be the committing to
HEAD be forbidden ?
There will be no outage for CVS at all (one of the major reasons for
going with the trunk only approach). Just release engineering will
refrain from integration on trunk (HEAD) during migration, no one else
should be committing there anyway (the exception being new modules which
will be handled separately). The OOO300 code line is not affected at all.
I would reconsider the plan if someone steps up with a CWS nominated
for DEV300 m32 with hundreds of changed files. In this case it would
make sense to throw in another CVS based milestone, just to save
ourselves a bit of work.
What are developers required to do with their open cws during the
migration ?
During migration? Nothing special, developers can just work on them as
usual. When they are done with a CWS, we'll ask the developer to resync
their CWS to the latest CVS milestone. We (that is Release Engineering)
will create a patch from the CVS branch and apply it either directly to
the latest SVN milestone (thus integrate it) or create a (CWS)-branch on
the first SVN milestone for further resyncing with the latest SVN
milestone. The first option is of course for nominated CWSs without to
many conflicts, the second one for complicated CWSs or ones where the
developer wants to resume developing via SVN.
I guess we'll need a hand here and there from developers but it
shouldn't be that bad.
Please note that we have a soft dependency on the RC. Since CWSs which
are meant for OOO300 can only be opened in CVS, we'll need to manually
merge then into SVN for DEV300. The simple double integration trick we
usually use to propagate the fixes between different masters doesn't
work in this case. Will not be a problem for a few small CWSs and
because the majority of the CWSs is already integrated I do not worry to
much about then.
Heiner
Martin
Martin Hollmichel wrote:
Jörg Jahnke wrote:
Hi,
due to the trunk-only migration mentioned below, we do no longer
have a dependency on the first release candidate of OOo 3.0, which
is done on the OOO300 branch. At the same time, Heiner is ready to
start the migration. So do we want to start the migration now i.e.
prior to the RC?
from my point of we don't need to wait for the release candidate to
proceed with the migration as we decided to go with the trunk
migration only (see
<http://wiki.services.openoffice.org/wiki/Scm_migration_scope>). If
nobody objects I would ask you to provide a concrete plan for the
migration starting asap.
Regards,
Jörg
Martin
Jens-Heiner Rechtien schrieb:
Hi,
Jens-Heiner Rechtien wrote:
Hi Guido,
the migration is going nicely along. We do plan to migrate after
the 3.0 RC.
- We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The
URL will be svn.services.openoffice.org. An updated test repository
will be on that machine RSN.
- We'll use Subversion 1.5.1, that is with the build in merge
tracking
- The ESC council decided after some debate about the migration
scope,
aka how much history do we want
(http://wiki.services.openoffice.org/wiki/Scm_migration_scope)
We will go along with option c) "trunk only", this will also help
with later DSCM options.
Some asked, so I probably should explain it in a bit more detail
what we mean with "trunk only" migration:
- only history on the main development line (trunk) will be
migrated,
thus no branches and tags
- we'll migrate only files which are still active (nothing from
the CVS "Attic" directories)
- binary files will be pruned to the last version
- Localization files (*.sdf) will be pruned to the last version
Existing branches will be maintained in CVS. This includes the
OOO300 branch, on which OpenOffice.org 3.0 will be released.
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
