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 <jran...@example.com>" 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', 'jaeni...@openssl.org'),
    'ben' : ('Ben Laurie', 'b...@openssl.org'),
    'levitte' : ('Richard Levitte', 'levi...@openssl.org'),
    'bodo' : (u'Bodo Möller', 'b...@openssl.org'),
    'ulf' : (u'Ulf Möller', 'u...@openssl.org'),
    'steve' : ('Dr. Stephen Henson', 'st...@openssl.org'),
    'geoff' : ('Geoff Thorpe', 'ge...@openssl.org'),
    'appro' : ('Andy Polyakov', 'ap...@openssl.org'),
    'nils' : ('Nils Larsch', 'n...@openssl.org'),
    'rse' : ('Ralf S. Engelschall', 'r...@openssl.org'),
    'mark': ('Mark J. Cox', 'm...@openssl.org'),
    'holger': ('Holger Reif', 'hol...@openssl.org'),
    'paul' : ('Paul C. Sutton', 'p...@openssl.org'),
    }

# 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(),
        ],
    )

Reply via email to