git-cc

git-cc 是一个简单的 ClearCase 或 UCM 与 Git 之间的桥。

警告

作者纯粹是出于娱乐目的而写的，目的是看看是否可以一劳永逸地停止使用ClearCase。

作者可能会继续修改它以适应他自身的需要，但是更希望看到它得到一些实际的改进。（实际上，我希望看到更多的是ClearCase死亡，但是不要认为这种情况会很快发生）。

另外，我最近进行了更改，以支持添加使用git-cat的二进制文件。不幸的是git-cat不能处理终端行转换，因此我将gitcc初始化将core.autocrlf设置为false。这仅与Windows用户有关。请勿在第一次提交后尝试更改此设置，因为这只会使情况变得更糟。我对任何为此感到st恼的人表示歉意。

安装

安装git-cc的最简单方法是使用Python软件包安装程序pip并直接从其GitHub存储库中进行安装。在命令提示符处执行以下命令以安装最新版本：

C:\> pip install https://gitee.com/mirrors/git-cc.git#egg=git_cc

如果您是从python.org安装的Python，则pip包含在Python 2> = 2.7.9和Python 3> = 3.4中。如果您没有pip，请 参阅《 Python打包用户指南》中的[本节] pip安装。

如果pip或git无法访问GitHub，例如，在您工作的地方不允许进行这种访问，则可以 从GitHub存储库下载具有最新版本的[zip文件] zip文件。解压缩它并使用pip在目录树的根目录中执行以下命令：

C:\master> pip install .

最后，如果您不能使用pip，则还可以使用老式的方法来安装Python软件包：

C:\master> python setup.py install

工作流程

初始化：

git init
gitcc init d:/view/xyz
gitcc rebase
# Get coffee
# Do some work
git add .
git commit -m "I don't actually drink coffee"
gitcc rebase
gitcc checkin

初始化（快速）：

最初的重新设置可能会很慢，并且如果您只想获取ClearCase的快照而没有历史记录，那么此方法适合您：

gitcc init d:/view/xyz
gitcc update "Initial commit"

其他：

这是两个非常有用的标志，用于重新设置基准。

gitcc rebase --stash

在重新设置基准之前运行隐藏项，然后将其弹出。

gitcc rebase --dry-run

打印出ClearCase中待处理的提交和已修改文件的列表。

要仅同步部分git历史记录（而不是从第一次提交到HEAD同步），请使用以下命令标记起点：

gitcc tag <commit>

要在签入时指定一个现有的ClearCase标签，以使您的动态视图显示刚刚签入的元素的版本（如果您的confspec进行了相应配置），请使用以下命令：

gitcc checkin --cclabel=YOUR_EXISTING_CC_LABEL

请注意，如果CC标签已被使用，它将被移动到该元素的新版本。

组态

文件.git / gitcc包含gitcc的配置选项。例如，它允许您限制从中导入的分支和文件夹：

[core]
include = FolderA|FolderB
exclude = FolderA/sub/folder|FolderB/other/file
users_module_path = users.py
ignore_private_files = False
debug = False
type = UCM
[master]
clearcase = D:\views\co4222_flex\rd_poc
branches = main|ji_dev|ji_*_dev|iteration_*_dev
[sup]
clearcase = D:\views\co4222_sup\rd_poc
branches = main|sup

在这种情况下，有两个单独的git分支，即master和sup，分别对应于ClearCase中的不同文件夹/分支。

您可以在ClearCase历史记录中为每个用户添加一个映射。这是通过您提供的单独的Python模块完成的。用户模块示例如下所示：

users = {
    'charleso': "Charles O'Farrell",\
    'jki': 'Jan Kiszka <jan.kiszka@web.de>',\
}
 
mailSuffix = 'example.com'

您可以将用户模块的路径指定为gitcc配置文件中键“ users_module_path”的值。在上面的示例中，指定的值为“ users.py”。如果路径是相对的，则相对于配置文件的位置。因此，在此示例中，gitcc将从目录.git导入users.py。但是您也可以使用绝对用户模块路径。

如果您未在配置文件中指定用户模块路径，则将使用ClearCase用户信息。

如果制作ClearCase VOB的快照，则复制视图中所有可见的文件，包括视图专用文件。这可能不是您想要的，例如，如果VOB包含各种构建工件。要仅复制实际上受ClearCase控制的文件，请将键“ ignore_private_files”设置为True。

笔记

可以使用静态或动态视图。我在工作中使用动态，因为它不需要更新的速度更快。无论如何，我已经完成了rebase的更新，以防万一有人想以这种方式使用它。

还可与需要将“类型”配置设置为“ UCM”的UCM一起使用。这项工作仍在进行中，因为我最近才改用此工具。请注意，历史记录仍是通过lshistory检索的，而不是专门从任何活动信息中检索的。这在很大程度上是为了方便我，所以我不必重写所有内容。因此，诸如“推荐”基准之类的东西将被忽略。我不知道这是否会引起大戏剧。

故障排除

1. WindowsError：[错误2]系统找不到指定的文件

您最有可能在Windows Cmd下运行gitcc。目前不支持此功能。而是使用Git Bash，无论如何这是一个更好的控制台。:-)

如果同时安装了msysgit和Cygwin，则也可能是 此问题。

2. cleartool：错误：VOB中不是对象：“。”。

您在init中指定的ClearCase目录不正确。请注意，该目录必须位于VOB内，该VOB可能是您指定的视图内的文件夹之一。

3. 致命：参数“ ClearCase”含糊不清：未知修订或路径不在工作树中。

如果这是您的第一个变基，请忽略它。这是预期的。

4. pathspec'master_cc'与git已知的任何文件都不匹配

请参阅第8期。

幕后花絮

聪明的人会考虑其他git bridge实现的灵感，例如git-svn等。另一方面，我决定去牛仔并重新发明轮子。我不知道其他脚本是如何工作的，所以我希望这不是一种完全愚蠢的做法。

我想拥有它，以便历史上的任何点都可以基于当前工作目录之上。我也通过使用ClearCase的git提交时间来做到这一点。另外，最后一次基于重新提交的提交被标记，并用于限制历史查询，以防止出现任何机会。因此，此标记的变更集还用于选择哪些提交需要检入ClearCase。

问题

毫无疑问，当最初从ClearCase导入历史记录时，如果不更改配置规范，将无法访问当前不在您视图中（即已删除）的文件。这非常可悲，意味着导入的历史记录不是真实的历史记录，因此回滚到较早的修订版将受到一定的限制，因为很可能所有内容都无法编译。其他ClearCase进口商似乎也受到相同问题的限制，但尽管如此，它仍然令人沮丧。!！

对于开发人员

本节为git-cc开发人员提供信息。

所需的包

要开发git-cc，需要几个Python软件包，这些软件包不是标准Python发行版的一部分，您必须单独安装。由于这些软件包可能与您的系统Python环境冲突，因此强烈建议您为工作设置virtualenv virtualenv。

在存储库根目录中的文件“ requirements.txt”列出了开发所需的Python包。要安装这些软件包，请使用以下命令：

git-cc $ pip install -r requirements.txt

测试中

git-cc带有一小套单元测试，您可以在子目录tests /中找到它们。有几种方法可以运行单元测试。例如，您可以让Python搜索单元测试并在当前的Python环境中运行它们。为此，请从仓库的根目录执行以下命令：

git-cc $ python -m unittest discover tests/

这将导致如下输出：

........
----------------------------------------------------------------------
Ran 8 tests in 0.002s
 
OK

如果您从仓库的根目录运行单元测试，则即使未安装git-cc软件包，所有单元测试也将能够导入它。如果从另一个目录运行单元测试，则必须先安装git_cc。

运行单元测试的另一种方法是使用Python工具tox tox。tox不仅仅是运行单元测试：

• 它会为您指定的每个Python解释器创建Python包的源分发，
• 它为您指定的每个Python解释器创建一个virtualenv，并且
• 对于每个virtualenv，请使用源分发版安装软件包并运行单元测试。

如果从仓库的根执行tox，其输出将如下所示：

git-cc $ tox
GLOB sdist-make: /home/a-user/repos/github.com/git-cc/setup.py
py27 inst-nodeps: /home/a-user/repos/github.com/git-cc/.tox/dist/git_cc-1.0.0.dev0.zip
py27 installed: git-cc==1.0.0.dev0
py27 runtests: PYTHONHASHSEED='2322284388'
py27 runtests: commands[0] | python -m unittest discover tests/
........
----------------------------------------------------------------------
Ran 8 tests in 0.003s
 
OK
py34 inst-nodeps: /home/a-user/repos/github.com/git-cc/.tox/dist/git_cc-1.0.0.dev0.zip
py34 installed: git-cc==1.0.0.dev0
py34 runtests: PYTHONHASHSEED='2322284388'
py34 runtests: commands[0] | python -m unittest discover tests/
........
----------------------------------------------------------------------
Ran 8 tests in 0.002s
 
OK

如输出所示，tox在virtualenvs中针对Python 2.7和Python 3.4运行测试。这已在文件tox.ini中指定，您可以在存储库的根目录中找到该文件：

[tox]
envlist = py27,py34
[testenv]
commands=python -m unittest discover tests/

仅当您同时安装了两个解释器时，此方法才有效。如果要支持其他Python版本，则必须相应地更新ini文件。

使用tox可以轻松地在多个Python环境中测试您的Python包。与在当前环境中运行单元测试相比，运行tox花费的时间更多。因此，开发人员运行它的频率降低，例如仅在发布新版本或请求请求之前运行它。

变更和版本控制

该仓库包含一个CHANGES文件，其中列出了每个git-cc版本以及当前正在开发的版本的更改。该文件具有特定的格式，最好通过示例来解释。假设CHANGES文件看起来像这样-注意git-cc的实际CHANGES文件看起来不同：

Changelog
=========

1.2.0 (unreleased)
------------------

- Fixes issue Z

1.1.0 (2016-02-03)
------------------

- Adds support for feature Y
- Updates documentation of feature X

1.0.0 (2016-01-03)
------------------
 
- Started versioning at 1.0.0

该文件提到版本1.0.0和1.1.0已发布，下一个版本将是1.2.0。

发布新版本的过程可能很麻烦且容易出错：您必须针对开发版本更新CHANGES文件和setup.py，创建标签，再次更新CHANGES文件和setup.py等。对于git- cc中，使用Python软件包[zest.releaser] zest- releaser提供的工具可以完全自动化地创建发行版。

为了显示zest.releaser的工作方式，以下是zest.releaser命令'fullrelease'的（经过清理的）输出，并带有示例CHANGES文件：

# execute fullrelease on the command-line
git-cc $ fullrelease

# the command outputs the beginning of the CHANGES file 
Changelog entries for version 1.2.0:
 
1.2.0 (unreleased)
------------------
 
- Fixes issue Z
 
1.1.0 (2016-02-03)
------------------
# the command proposes to set the release version to 1.2.0
Enter version [1.2.0]:    
# pressed RETURN to accept the proposed release version
# the command automatically updates the CHANGES file and the version number used by setup.py

OK to commit this (Y/n)?
# pressed RETURN to commit the changes

Tag needed to proceed, you can use the following command:
git tag 1.2.0 -m "Tagging 1.2.0"
Run this command (Y/n)?
# pressed RETURN to tag the release

Check out the tag (for tweaks or pypi/distutils server upload) (Y/n)? n
# answered 'n' and pressed RETURN to not check out the tag

Current version is 1.2.0
# the command proposes to set the development version to 1.2.1dev0
Enter new development version ('.dev0' will be appended) [1.2.1]: 
# pressed RETURN to accept the proposed development version
# the command automatically updates the CHANGES file and the version number used by setup.py

OK to commit this (Y/n)? 
# pressed RETURN to commit the changes

OK to push commits to the server? (Y/n)? n
# answered 'n' and pressed RETURN to not push the latest commit yet

命令完成后，CHANGES文件的开头已更改为：

Changelog
=========
 
1.2.1 (unreleased)
------------------
 
- Nothing changed yet.
 
 
1.2.0 (2016-07-01)
------------------
 
- Fixes issue Z