Am 27.05.2010 18:48, schrieb David Woodhouse:
> On Thu, 2010-05-27 at 17:51 +0200, Lutz Jaenicke wrote:
>
>> David Woodhouse wrote:
>>
>>> On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote:
>>>
>>>
>>>> Those [i_a] bits are my markers in our local code base so I know which
>>>> edits
>>>> are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know
>>>> there are smarter systems around, but I've been 'tracking' OpenSSL for
>>>> almost a decade and tools available to me haven't always been smart enough
>>>> to ensure I didn't lose local edits across upgrades. And drilling down the
>>>> RCS database for every edit isn't fun nor fast like that. So marking has
>>>> become a habit by now. Often accompanied with a short text about the 'why'
>>>> or related info. Sorry, wasn't meant to be bothersome to you.
>>>>
>>>>
>>> None of the existing CVS->git import tools handle the OpenSSL repository
>>> correctly -- they all do strange things on branches. But for HEAD, they
>>> should work OK.
>>>
>>>
>> So far we have not seen technical problems when last tested.
>>
> That's interesting. What tool were you testing? I've had issues with
> both cvs2git and git-cvsimport.
>
> My normal reaction in dealing with _any_ project which uses a legacy
> version control system (cvs,svn,hg,bzr,etc) is to mirror it into git so
> that I can deal with it sensibly. OpenSSL has so far resisted my
> efforts, which is one of the reason I find it a PITA to deal with.
>
The state of the test-repository is a bit old (approx one year) but you
may have a look into
git://login.openssl.org/openssl
http://www.openssl.org/gitweb.cgi/
When the initial test migrations were performed (2 years ago) I used
cvs2svn-2.1.1
with some setup in cvs2svn-git.options. Since then Geoff Thorpe also
worked a bit on some automatic way to keep the test repo in sync with
the CVS repo but all of this is on hold until the team has come to a
final decision...
Best regards,
Lutz
# (Be in -*- mode: python; coding: utf-8 -*- mode.)
# As a partial check that the example options file is functional, we
# use it as the basis for this test. We only need to overwrite the
# output option to get the output repository in the location expected
# by the test infrastructure.
execfile('cvs2svn-example.options')
from cvs2svn_lib.fulltext_revision_recorder \
import SimpleFulltextRevisionRecorderAdapter
from cvs2svn_lib.git_revision_recorder import GitRevisionRecorder
from cvs2svn_lib.git_output_option import GitOutputOption
ctx.trunk_only = False
ctx.cross_project_commits = False
ctx.cross_branch_commits = False
ctx.username = 'cvs2svn'
# CVS uses unix login names as author names whereas git requires
# author names to be of the form "foo <bar>". The default is to set
# the git author to "cvsauthor <cvsauthor>". author_transforms can be
# used to map cvsauthor names (e.g., "jrandom") to a true name and
# email address (e.g., "J. Random <[email protected]>" for the
# example shown). All values should be either 16-bit strings or 8-bit
# strings in the utf-8 encoding.
author_transforms={
'jaenicke' : (u'Lutz Jänicke', '[email protected]'),
'ben' : ('Ben Laurie', '[email protected]'),
'levitte' : ('Richard Levitte', '[email protected]'),
'bodo' : (u'Bodo Möller', '[email protected]'),
'ulf' : (u'Ulf Möller', '[email protected]'),
'steve' : ('Dr. Stephen Henson', '[email protected]'),
'geoff' : ('Geoff Thorpe', '[email protected]'),
'appro' : ('Andy Polyakov', '[email protected]'),
'nils' : ('Nils Larsch', '[email protected]'),
'rse' : ('Ralf S. Engelschall', '[email protected]'),
'mark': ('Mark J. Cox', '[email protected]'),
'holger': ('Holger Reif', '[email protected]'),
'paul' : ('Paul C. Sutton', '[email protected]'),
}
# How to convert author names, log messages, and filenames to unicode.
# The first argument to CVSTextDecoder is a list of encoders that are
# tried in order in 'strict' mode until one of them succeeds. If none
# of those succeeds, then fallback_encoder is used in lossy 'replace'
# mode (if it is specified). Setting a fallback encoder ensures that
# the encoder always succeeds, but it can cause information loss.
ctx.cvs_author_decoder = CVSTextDecoder(
[
'latin1',
'utf8',
'ascii',
],
#fallback_encoding='ascii'
)
ctx.cvs_log_decoder = CVSTextDecoder(
[
'latin1',
'utf8',
'ascii',
],
#fallback_encoding='ascii'
)
ctx.output_option = GitOutputOption(
'cvs2svn-tmp/git-dump.dat',
author_transforms=author_transforms,
)
ctx.revision_recorder = SimpleFulltextRevisionRecorderAdapter(
RCSRevisionReader('co'),
GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'),
)
ctx.revision_excluder = NullRevisionExcluder()
ctx.revision_reader = None
run_options.clear_projects()
run_options.add_project(
r'/home/ljaenicke/opensource/openssl/openssl',
symbol_transforms=[
# See cvs2svn-example.options for more documention about
# symbol transforms.
ReplaceSubstringsSymbolTransform('\\','/'),
NormalizePathsSymbolTransform(),
],
symbol_strategy_rules=[
# See cvs2svn-example.options for more documention about
# strategy rules.
# Read from a file how symbols should be converted:
#SymbolHintsFileRule('symbol-hints.txt'),
# Specific rules for symbols matching particular regexps:
#ForceBranchRegexpStrategyRule(r'branch.*'),
#ForceTagRegexpStrategyRule(r'tag.*'),
#ExcludeRegexpStrategyRule(r'unknown-.*'),
ExcludeRegexpStrategyRule(r'unlabeled-.*'),
# If a symbol is used consistently in CVS, do the same in git:
UnambiguousUsageRule(),
# If there are ever commits on a symbol, force it to be a
# branch:
BranchIfCommitsRule(),
# Uncomment at most one of the following group of
# "catch-all" rules:
HeuristicStrategyRule(),
#AllBranchRule(),
#AllTagRule(),
# This rule should always be included. It determines from
# where each branch sprouts.
HeuristicPreferredParentRule(),
],
)
