mercurial和svn_DBA Mercurial简介–处理文件和更改

mercurial和svn

介绍 ( Introduction )

In my previous article, we went over the reasons why DBAs should use version control, as well as the benefits of Mercurial as a specific choice. We also gave three examples of instances where source control can come in handy (though to be honest they were picked from a much longer list). In this article, I’m going to go a step further and actually walk you through setting up your first repository (locally for now, we’ll go into setting up a remote one later), making your first commit, and making (and viewing) changes to your newly tracked files. Let’s get started!

在上一篇文章中 ，我们探讨了DBA使用版本控制的原因，以及Mercurial作为特定选择的好处。 我们还给出了三个示例的示例，这些示例中的源代码管理可以派上用场（虽然老实说，它们是从更长的列表中挑选出来的）。 在本文中，我将更进一步，并实际引导您建立第一个存储库（目前在本地，我们将在稍后建立一个远程存储库），进行第一次提交并进行（和查看）对新跟踪文件的更改。 让我们开始吧！

建立资料库 ( Setting up a repository )

Now that we have some ideas for things to actually put in version control, how do we actually go about getting it setup? The steps are not difficult, so we’ll go through them here one at a time. Note: I’m very much a command line guy, so I will tend to give examples using that as a method when possible.

既然我们对要放入版本控制中的东西有了一些想法，那么我们如何实际进行设置？ 这些步骤并不困难，因此我们一次将在这里进行遍历。 注意：我是一个非常命令行的人，所以我会尽可能地举一些使用该方法的示例。

下载TortoiseHG ( Downloading TortoiseHG )

First we need to download the Mercurial tools. I find the best way to get this is to go and grab TortoiseHG, an excellent variation on the popular TortoiseSVN Subversion client. Yes, I know I just said I love the command line, and yet I’m advocating downloading a GUI tool. I do this for two reasons: 1) it’s an easy way to grab everything you need in one shot, 2) there are still times when I find a GUI nice, such as looking at revision history. I’d also recommend that you download and install WinMerge, which at least in my opinion is the best visual comparison tool available. As we’ll see, viewing the differences between files is a huge part of using version control.

首先，我们需要下载Mercurial工具。 我发现实现此目标的最佳方法是去抓紧TortoiseHG ，这是流行的TortoiseSVN Subversion客户端的绝佳变体。 是的，我知道我刚刚说过我喜欢命令行，但我仍主张下载GUI工具。 我这样做的原因有两个：1）这是一种轻松获取所需所有内容的简便方法，2）有时候我发现GU​​I不错，例如查看修订历史记录。 我还建议您下载并安装WinMerge ，至少在我看来，它是可用的最佳视觉比较工具。 我们将看到，查看文件之间的差异是使用版本控制的重要组成部分。

When running the installation package, I recommend leaving the default options selected.

运行安装程序包时，建议您保留默认选项。

Once the installation finishes we can go on to creating our first repository.

安装完成后，我们可以继续创建第一个存储库。

创建存储库 ( Creating the repository )

Before we go on, it bears repeating that the concept of a “repository” is very different with a distributed version control system than with more tradition server-centric models. Remember, each and every user has their own complete copy of the repository kept locally, including all history.

在继续之前，需要重申的是， 分布式版本控制系统的“存储库”概念与传统的以服务器为中心的模型大不相同。 请记住，每个用户都拥有自己的完整的本地存储库副本，包括所有历史记录。

To create a new repository, simply open a command prompt, navigate to the folder where you want the repository created, and type “hg init”. This command initializes the repository, and if it works you’ll see a folder called “.hg” in your directory.

要创建新的存储库，只需打开命令提示符，导航到要在其中创建存储库的文件夹，然后键入“ hg init”。 该命令将初始化存储库，如果运行成功，您将在目录中看到一个名为“ .hg”的文件夹。

Next, we’ll want to change a few settings. Mercurial stores its settings at three levels: computer wide, the current user, and the current repository. There’s a few settings that we’ll want to configure at the user level, so we’ll start there. Navigate to your user profile directory (powershell shortcut: “cd $env:userprofile”) and look for a file called “mercurial.ini”. If it’s not there, then simply create an empty file with that name and open it in your favorite text editor. Then, paste in the following lines:

接下来，我们将要更改一些设置。 Mercurial将其设置存储在三个级别：计算机范围，当前用户和当前存储库。 我们需要在用户级别上配置一些设置，因此我们将从此处开始。 导航到用户配置文件目录（powershell快捷方式：“ cd $ env：userprofile”），然后查找名为“ mercurial.ini”的文件。 如果不存在，则只需使用该名称创建一个空文件，然后在您喜欢的文本编辑器中将其打开。 然后，粘贴以下行：

 
[ui]
username = Your Name And E-Mail Here
merge = winmergeu
 
[extensions]
mercurial_keyring = 
 

These settings tell Mercurial the following:

这些设置告诉Mercurial以下内容：

• The user name to record when changes are committed (you could use an e-mail address but I like an actual name).
  提交更改时记录的用户名（您可以使用电子邮件地址，但我喜欢实际名称）。
• To use the aforementioned WinMerge utility for all visual merging activities.
  要将上述WinMerge实用程序用于所有可视合并活动。
• mercurial_keyring extension, which allows you to securely save credentials for remote repositories (believe me, this is worth its weight in gold, unless you like entering in user names and passwords over and over again).mercurial_keyring扩展名，该扩展名可让您安全地保存远程存储库的凭据（相信我，这值得一试，除非您喜欢一遍又一遍地输入用户名和密码）。

Now, we’re ready to try our first commit of a file.

现在，我们准备尝试第一次提交文件。

您的第一次提交 ( Your first commit )

First, we need something to commit, so create a text file and put some content in it. We can do this easily from the command line. Note that for ease of use I’m using some Powershell commands to add the text to the file, rather than through a text editor (I’m a command line guy, remember?).

首先，我们需要提交一些内容，因此创建一个文本文件并将一些内容放入其中。 我们可以从命令行轻松地做到这一点。 请注意，为了易于使用，我使用了一些Powershell命令将文本添加到文件中，而不是通过文本编辑器（我是命令行专家，还记得吗？）。

 
PS C:\A_Workspace\repo> Add-Content .\helloworld.txt "Hello World!"
 

Now we can check to see what the status of the file is.

现在，我们可以检查文件的状态。

 
PS C:\A_Workspace\repo> hg status
? helloworld.txt
PS C:\A_Workspace\repo>
 

The “hg status” command tells Mercurial we want to see the status of all the files in our repository working directory. The “?” tells us that Mercurial isn’t sure what to do about that file, because it’s not currently being tracked. By default Mercurial doesn’t track files in a folder until we ask it to, which we can do with the following command:

“ hg status”命令告诉Mercurial我们要查看存储库工作目录中所有文件的状态。 “？” 告诉我们Mercurial不确定该文件的处理方法，因为当前尚未对其进行跟踪。 默认情况下，Mercurial不会跟踪文件夹中的文件，直到我们要求它为止，我们可以使用以下命令进行操作：

 
PS C:\A_Workspace\repo> hg add
adding helloworld.txt
PS C:\A_Workspace\repo>
 

Note that we could specify a specific file name with the “hg add” command, or even a path or pattern. If you want to know all the different combinations, all you need to do (as with any Mercurial command) is type “hg help add”.

注意，我们可以使用“ hg add”命令指定特定的文件名，甚至可以指定路径或模式。 如果您想知道所有不同的组合，则只需执行“ hg help add”（与任何Mercurial命令一样）即可。

Now we’re ready to actually commit our change, meaning it will be stored in the repository.

现在，我们准备好实际提交更改，这意味着更改将存储在存储库中。

 
PS C:\A_Workspace\repo> hg commit -m"My first commit!"
 

This commits the change into Mercurial with the comment “My first commit!”. Don’t believe me though, let’s verify that it’s there. There’s two ways to do this: 1) via the command line or via TortoiseHg’s graphical interface. First, the command line:

这会将更改提交到Mercurial，并带有“我的第一次提交！”注释。 不过不要相信我，让我们验证一下它在那里。 有两种方法可以做到这一点：1）通过命令行或TortoiseHg的图形界面。 首先，命令行：

 
PS C:\A_Workspace\repo> hg status -A
C helloworld.txt
PS C:\A_Workspace\repo> hg log
changeset:   0:5b776a994ea9
tag:         tip
user:        Josh Feierman
date:        Sun Oct 25 09:06:20 2015 -0400
summary:     My first commit!
PS C:\A_Workspace\repo>
 

The “status -A” command shows us all files in the working directory and their status (the “C” means “clean”, I.e. the file has not changed since its last committed state); the “log” command shows us the history of changes committed to the repository.

“ status -A”命令向我们显示工作目录中的所有文件及其状态（“ C”表示“干净”，即自上次提交状态以来该文件未更改）； “ log”命令向我们显示了提交到存储库的更改的历史记录。

If we’d rather see this in the graphical interface (and even a hard core command line guy like me does admit this is a case where a graphical interface is pretty nice), we can look in the folder in Windows Explorer, where we’ll see this.

如果我们希望在图形界面中看到它（甚至像我这样的硬核命令行专家也承认这是图形界面非常不错的情况），我们可以在Windows资源管理器中的文件夹中查找，会看到这个。

That little green “check” tells us the file is unchanged since its last commit. We can also right click in the directory and choose “Hg Workbench”:

绿色的小“检查”告诉我们该文件自上次提交以来未更改。 我们也可以右键单击目录，然后选择“ Hg Workbench”：

Then we’ll see this.

然后，我们将看到此。

Here you can see the complete history of the repository, including the files changed in each revision and (as we’ll later see) the differences between them.

在这里，您可以查看存储库的完整历史记录，包括每个版本中更改的文件以及它们之间的差异（我们将在后面看到）。

进行修改 ( Making modifications )

Now let’s learn how to make modifications to a file, see the differences between what we’ve committed, and finally commit our changes back to the repository.

现在让我们学习如何对文件进行修改，查看已提交内容之间的差异，最后将所做的更改提交回存储库。

First, let’s make some changes to the file.

首先，让我们对文件进行一些更改。

 
PS C:\A_Workspace\repo> Add-Content .\helloworld.txt "Hello again!"
 

We can then use the “hg status” command to see that the file has been modified.

然后，我们可以使用“ hg status”命令来查看文件已被修改。

 
PS C:\A_Workspace\repo> hg status
M helloworld.txt
 

We can also look at the file in Windows Explorer, where we will notice a change in its appearance.

我们还可以在Windows资源管理器中查看该文件，在该文件中我们会发现其外观有所变化。

See that little red exclamation point? That tells us the file has been modified since the last commit. To see what changes have been made, we can right click on the file and choose “Visual Diff”.

看到那个红色的感叹号吗？ 这告诉我们该文件自上次提交以来已被修改。 要查看已进行了哪些更改，我们可以右键单击该文件，然后选择“ Visual Diff”。

This will bring up a window showing the differences between the committed version of the file and the one currently in your working directory. Note that your window’s appearance may vary from the one you see below, depending upon what tool is configured for Mercurial to use for comparisons. For me, there is no better option than WinMerge.

这将打开一个窗口，显示文件的提交版本与工作目录中当前版本之间的差异。 请注意，窗口的外观可能与下面看到的有所不同，这取决于为Mercurial配置的用于比较的工具。 对我来说，没有比WinMerge更好的选择了。

Now, let’s suppose that we’ve accidentally made changes to the file and wish to remove them. Again, this is exceptionally easy with Mercurial. All we need to do is issue a command from the command prompt in the repository folder.

现在，假设我们不小心对文件进行了更改，并希望将其删除。 同样，这对于Mercurial来说非常容易。 我们需要做的就是从存储库文件夹中的命令提示符处发出命令。

 
PS C:\A_Workspace\repo> hg revert .\helloworld.txt
 

Now if we run the “hg status” command, we will see that there are no differences. We can also see that the familiar green check mark has returned.

现在，如果我们运行“ hg status”命令，我们将看到没有区别。 我们还可以看到熟悉的绿色复选标记已返回。

Let’s say that we did in fact want to commit these changes. If that’s the case, the procedure is exactly the same as our first commit.

假设我们确实确实想提交这些更改。 在这种情况下，该过程与我们的第一次提交完全相同。

 
PS C:\A_Workspace\repo> hg commit -m"Committing change." .\helloworld.txt
 

Note that I specified the file name here. If you have multiple modified files and only want to commit one, this is how to do it.

请注意，我在此处指定了文件名。 如果您有多个修改过的文件，并且只想提交一个，那么这就是方法。

The change has now been committed, and we can see the results in the history of the file.

更改现已提交，我们可以在文件的历史记录中看到结果。

修复历史 ( Fixing history )

One of the neat things about Mercurial is that it enables you to go back in time and fix your mistakes. Those changes are then propagated to any downstream versions with minimal further intervention. This makes fixing bugs a lot less painful since there is less work to do. Let’s look at an example.

关于Mercurial的一件整洁的事情是，它使您能够及时返回并纠正错误。 然后将这些更改传播到任何下游版本，而无需进行进一步干预。 由于减少了工作量，因此使修复错误的痛苦减轻了很多。 让我们来看一个例子。

 
PS C:\A_Workspace\repo> Add-Content .\helloworld.txt "Here's a change that introduces a bug."
PS C:\A_Workspace\repo> hg status
M helloworld.txt
PS C:\A_Workspace\repo> hg commit -m"Commit of bug"
PS C:\A_Workspace\repo> Add-Content .\helloworld.txt "Here's another change."
PS C:\A_Workspace\repo> hg status
M helloworld.txt
PS C:\A_Workspace\repo> hg commit -m"Commit of another change."
 

What we’ve done above is the following: 1) made and committed a change that introduced a bug, 2) made and committed another change.

我们在上面所做的工作如下：1）进行并提交了引入错误的更改，2）进行并提交了另一个更改。

At some point in the future, we discover the bug. In this case we’re only one step ahead, but in many cases you might have committed many more changes before the bug was discovered. How would we go about solving this?

在将来的某个时候，我们会发现该错误。 在这种情况下，我们仅向前迈出了一步，但是在许多情况下，您可能还需要进行更多更改才能发现该错误。 我们将如何解决这个问题？

First, we need to determine when the change that introduced the bug was committed. Mercurial has a great feature for this, aptly called “blame” (technically it is called “annotate”, but “blame” is a shortcut and besides, I like the name better). Blame lets you list out the file and see who last modified a particular line of code and in what revision it was modified.

首先，我们需要确定何时引入引入错误的更改。 为此，Mercurial 具有一个很大的功能 ，恰当地称为“责备”（技术上称为“注释”，但“责备”是捷径，而且我更喜欢这个名称）。 Blame允许您列出文件，并查看谁最后修改了特定的代码行以及对其进行了哪个修订。

 
PS C:\A_Workspace\repo> hg blame -u -d -l -c .\helloworld.txt
Josh Feierman 8779c69e108f Mon Jan 25 06:28:31 2016 -0500:1: hello world!
Josh Feierman 0daec33bfe0d Mon Jan 25 06:31:36 2016 -0500:2: Hello Again!
Josh Feierman 1aa44aa5accf Mon Jan 25 06:37:27 2016 -0500:3: Here's a change that introduces a bug.
Josh Feierman f8ddcc0802ff Mon Jan 25 06:37:45 2016 -0500:4: Here's another change.
 

Curse that rascal Josh…

诅咒那个无赖的乔什…

Moving on, here’s the step by step process for actually fixing this bug. First, we need to “update” to the revision where the breaking change was made. In the list shown above, the revision is identified by that odd looking string of characters right after the user’s name. So in this case, the target revision is “1aa44aa5accf”.

继续，这是实际修复此错误的逐步过程。 首先，我们需要“更新”到进行重大更改的修订。 在上面显示的列表中，修订版本由用户名后紧跟的奇怪字符串标识。 因此，在这种情况下，目标修订为“ 1aa44aa5accf”。

 
PS C:\A_Workspace\repo> hg update 1aa44aa5accf
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
 

Next, we need to edit the line of code causing the bug to occur. We can use the “Visual Diff” feature to see our change.

接下来，我们需要编辑导致该错误发生的代码行。 我们可以使用“ Visual Diff”功能来查看我们的更改。

Then, we commit the change.

然后，我们提交更改。

 
PS C:\A_Workspace\repo> hg commit -m"Fixed the bug."
created new head
 

You’ll notice that Mercurial let us know that we “created a new head” when we issued the commit command. What this means is that we now have two paths of changes in the repository; one where our bug still exists and our final change (that line that says “Here’s another change”) was added, and one where the bug has been fixed but that last change doesn’t exist. To complete the process, we need to merge the two of them together.

您会注意到，Mercurial让我们知道在发出commit命令时我们“创建了一个新头”。 这意味着我们现在在存储库中有两个更改路径； 一个仍然存在我们的错误，并进行了最后更改（添加了“这是另一个更改”这一行），另一个已修复了该错误，但最后一个更改不存在。 要完成此过程，我们需要将它们两者合并在一起。

 
PS C:\A_Workspace\repo> hg merge
merging helloworld.txt
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
 

When you issue the merge command, in general Mercurial is pretty good at merging the contents of two files together and will do so on its own. Sometimes it will need a nudge in the right direction however, such as cases where the edit conflicts with changes made later (such as editing the same line of code or adding on to the end of the file). When this happens, Mercurial will pop up a window of your chosen differential viewer, and let you choose the exact result. In our case, I had to copy and paste that last change into the merged file to get everything looking right.

通常，当您发出merge命令时，Mercurial非常擅长将两个文件的内容合并在一起，并且可以自己完成。 但是，有时需要在正确的方向上进行微调，例如在编辑与以后所做的更改冲突的情况下（例如，编辑同一行代码或添加到文件的末尾）。 发生这种情况时，Mercurial将弹出您选择的差异查看器的窗口，并让您选择确切的结果。 在我们的例子中，我必须将最后的更改复制并粘贴到合并的文件中，以使一切看起来正确。

Finally, we need to issue the commit command to get everything back in order. You can then use the “hg log” command to see the complete list of changes.

最后，我们需要发出commit命令以恢复一切。 然后，您可以使用“ hg log”命令查看更改的完整列表。

 
PS C:\A_Workspace\repo> hg commit -m"Merge of bug fix."
PS C:\A_Workspace\repo> hg log
changeset:   5:d56d0cadaa51
tag:         tip
parent:      4:681119c99a77
parent:      3:f8ddcc0802ff
user:        yardbirdsax
date:        Tue Jan 26 06:13:25 2016 -0500
summary:     Merge of bug fix.
 
changeset:   4:681119c99a77
parent:      2:1aa44aa5accf
user:        yardbirdsax
date:        Tue Jan 26 06:04:42 2016 -0500
summary:     Fixed the bug.
 
changeset:   3:f8ddcc0802ff
user:        yardbirdsax
date:        Mon Jan 25 06:37:45 2016 -0500
summary:     Commit of another change.
 

Notice how the second change listed (changeset 4:681119c99a77) lists the “parent” as not the one directly before it? This is because we essentially went back in time and created a new line of changes by fixing the bug. Then, we merged the two together for the final committed changeset (5:d56d0cadaa51), hence that one has two parents listed.

请注意，列出的第二个更改（更改集4：681119c99a77）如何将“父”列表而不是紧接在其之前的列表？ 这是因为我们从本质上回顾了过去，并通过修复错误创建了新的更改行。 然后，我们将这两个合并在一起以生成最终提交的变更集（5：d56d0cadaa51），因此其中一个列出了两个父级。

If all this sounds a little confusing, don’t worry, it all becomes very natural with time and experience. The important thing to understand is how to go through the steps detailed above in order to fix problems introduced in our code. And if you ever find yourself in a situation where you’re not quite sure how to proceed, always review the documentation first and experiment. It’s a good idea to make a copy of your repository before trying anything new. Since each copy is a complete isolated repository in and of itself, this minimizes risk. (And yes, it’s true that you could just undo anything you accidentally did, but when playing around it’s often easier to just do it in a sandboxed copy rather than having to go through a long series of steps to back out mistakes.)

如果这一切听起来有点令人困惑，请放心，随着时间和经验的流逝，一切都会变得很自然。 要了解的重要事情是如何完成上述详细步骤，以解决代码中引入的问题。 而且，如果您不确定如何进行操作，请始终先阅读文档并进行实验。 在尝试任何新操作之前，最好先复制存储库的一个副本。 由于每个副本本身就是一个完整的隔离存储库，因此可以最大程度地降低风险。 （是的，的确，您可以撤消您不小心做的任何事情，但是，在玩游戏时，通常只需将其复制到沙盒中即可，而不必经过一系列漫长的步骤来消除错误。）

结论和下一步 ( Conclusion and next steps )

Congratulations, you’ve successfully configured and setup Mercurial, created a repository, and made your first commit! You are well on your way towards leveraging the remarkable power of version control to better standardize and maintain your tools and scripts as a DBA.

恭喜，您已经成功配置和设置了Mercurial，创建了存储库，并进行了首次提交！ 您正在充分利用版本控制的强大功能来更好地标准化和维护作为DBA的工具和脚本。

In the next installment, we’ll dig deeper into Mercurial, looking at how to use branches to make experimental changes to our code without risk, and even create linked copies of existing files (something that will come in very handy as we’ll see). Finally, we’ll look in more depth at the specific cases mentioned earlier, and how we can leverage Mercurial to keep track of all the scripts in our DBA’s toolbox. Stay tuned!

在下一部分中，我们将更深入地研究Mercurial，研究如何使用分支无风险地对我们的代码进行实验性更改，甚至创建现有文件的链接副本（这将非常方便） ）。 最后，我们将更深入地研究前面提到的特定情况，以及如何利用Mercurial来跟踪DBA工具箱中的所有脚本。 敬请关注！

翻译自: https://www.sqlshack.com/a-dbas-introduction-to-mercurial-working-with-files-and-changes/

mercurial和svn