使用TortoiseSVN客户端Merge时出现的问题_tortoisemerge the file is not a valid text file

如题，记录一个使用TortoiseSVN客户端合并时走得一个弯路

为了方便代码管理，我们在服务端通常会生成三个文件夹 trunk ， branches ， tags 分别为主干，分支，标签。
根据本人理解（如有不正确之处欢迎批评指正）：

trunk（主干）用于保存最新的代码，当然，如果一起开发的技术人员少的话也可以直接在trunk上开发，这样分支就没有什么用了。
branches（分支）：举个例子，当多个人合作，可能有这样的情况出现：John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branches。John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。
tag（标签）：通常在最新版本上线后会从trunk里打一个标签，一是方便版本的管理，二是如果你发现以前某个已上线的版本出现一个bug时你就可以从tag里拿到相应版本的代码进行修改。因此在实现上，branches和tag，都是svn使用主干copy实现的。

如果还有不明白的点击看这里。

介绍以上三个知识后讲讲用svn进行合并时的注意点。当亲自实践完后，其实你发现从分支合并到主干需要注意三点：

一、保证你本地有trunk的最新代码，如果没有务必先checkout下来。并且你服务器上的branches的代码也是最新的；
二、在trunk的整个目录下执行merge，并从服务器上的相应的branches合并到本地的trunk；
三、再把本地trunk代码commit到服务器上。

没错，就是这简单的三步TM使我这菜鸟头疼了将近一天。最开始我直接想从服务器上相应的branches合并到trunk上，现在想想完全天方夜谭啊，老程序员说得永远不要在服务器上动代码或者各种文件就是真理啊。错误点二、我想从分支合并到主干，可是执行时却在本地branches的整个目录下进行merge，结果就是一大堆一大堆的conflict，还解决不了。到最后项目已经完全不知道是不是最新的了。最后把以前本地trunk（当时也不知道本地的主干是不是最新的了，真是笑哭）的所有文件（除了.svn）全部删除并commit，然后把备份好的最新分支代码整个手动复制粘贴到trunk上再提交，这是当时的应急之策，也是醉了。接下来再附上几张过程图：

这里再次强调想要合并到哪儿，就要到哪儿的本地文件夹上进行merge，这里合并到trunk

这里我都选第二种，第一种字面意思上是合并一定版本范围内的代码

这里又是一个注意点，和我们平常理解的意思相反，from是指要合并到的地方，我要合并到trunk这里就选服务器上trunk的地址，to选来源，即相应分支]

三步过后就能把branches里最新的代码merge到trunk上了，注意，此时SVN上的log日志没有记录（我也不明白为啥没有一个相应版本号来记录merge），然后再把合并后的本地trunk上的代码commit一下就完工了。

这里顺便记录一下创建分支，同样也是在trunk上的文件夹上右击选择branch/tag，然后To path选择branches下相应的应用版本的文件夹即可。
To选择branches下建的相应应用版本的文件夹即可

各路大神有不同意见的欢迎更正批评，希望初学者也不要走和我一样的弯路！！！

如题，记录一个使用TortoiseSVN客户端合并时走得一个弯路为了方便代码管理，我们在服务端通常会生成三个文件夹trunk，branches，tags分别为主干，分支，标签。根据本人理解（如有不正确之处欢迎批评指正）：trunk（主干）用于保存最新的代码，当然，如果一起开发的技术人员少的话也可以直接在trunk上开发，这样分支就没有什么用了。branches（分支）：举个例子，当多个人合作

如果使用 git，相信大家比较多的使用 merge ，对于rebase则少有陌生。相信刚使用 git不久的同学会有一个困惑，经常使用 merge 会造成破窗效应，查阅log 时会掺杂了大量无用的小提交，起初也对此习以为常，毕竟svn就是这样。使用 rebase其中的一个好处就是能够将多个commit 合并为一次提交，但是网络上比较多的都是基于命令行，今天记录一下总结的基于小乌龟Git的 merge /rebase提交管理流程。理解git中上游下游概念上游下游是一种相对概念，相对于remote/master，master就是

SVN常用指令1.Repo-browser(浏览版本库) 通过“浏览版本库”可以直接查看服务器上指定目录下的所有目录结构(需要有相关权限），包括特定版本的作者，提交时间等，并且在浏览版本库里面链接了很多SVN常用的功能。如显示日志，检出，导出，检入文件/文件夹，改名，删除文件，分支建立等。2.Checkout（检出）从SVN服务器上得到数据，即建立本地副本，并

一个项目一般会有多个分支，当某个大的改变在某个分支做完后需要被 merge 到trunk或其它分支时，这就需要用到 merge 。同步 Merge (sync merge ) svn merge source[$rev] [TARGET_WCPATCH] TARGET_WCPATCH是工作副本，默认是”.”（代表当前目录）。使用这个命令的主要目的是为了与源分支保持同步，把源分支上的更改也复制到当前

原文地址：http://blog.163.com/qq371557620@yeah/blog/static/8428365820172110320574/ 编码过程中，我们经常会遇到需要多个分支并行开发的情况。那么问题来了，在svn下如何建分支，开发任务完成后如何分支合并就成了开发人员需要熟练掌握的svn技能。 1、创建分支在trunk（主干）上点击右键，在 tortoiseSVN 菜单中选...

1、首先切换到作为主要的分支，然后选 Merge ，在对话框 From 中选中被 Merge 的分支，点OK即可 2、 Merge 时很可能提示冲突，不用管它，完成后，在项目文件夹中直接打开冲突的文件，修改发生冲突的地方即可。发生冲突的地方会被 ======= Tor to ise Merge 是一个免费软件/开源软件。通过它你可以查看文本文件之间的差异，并合并这些差异；甚至审查和采用这些标准差异文件——通常称之为补丁。　　当处理文本文件时，比如用你所喜欢的编程语言写的源代码，或者 Html/Xml 的文档或网站，你经常会碰到需要比较文件的不同版本的情况：有时候你从别人那里得到了一个不同版本的文件，或者有时候干脆就是你想知道你曾经做过什么修改。　　如果你使用版本控制系统（如 Subversion）时，当你更新工作副本时你可能会遇到“ 冲突 ”。这种情况通常发生在其他人也修改了你当前正在处理的文件的同一部分。当遇到冲突时，你必须手工来解决它——这就是 Tor to ise Merge 能帮助你的地方。

配置管理员将svn分支(branch) 合并到主干(trunk)上，分支的修改是由A同学提交的，合并到主干上的时候是由配置管理的B同学完成的，某天你突然心血来潮想看看主干上某个文件的修改的完整历史，发现使用 svn log或者乌龟都只能看到配置管理员B 同学 merge 的日志记录。难道将分支合并到主干上，分支的提交日志都丢失了？？这也太不可能了吧，可能的原因有两个，一个是svn merge ...

由于之前是小分组开发，并没有做过SVN的 merge ，都是人肉 merge 代码，现在到大的开发组，才发现Eclipse上的SVN有两种 merge 方式。大概是因为版本不同吧。而其中一种网络上是很少见的，经过一段时间的研究，做一个总结。如下：不论哪种方试合并，都是将其它的分支，合并到本地，然后再上传到SVN服务器，即本地合并到服务器上的branch/trunk或者其他branch 合并到本地都是一样的流...

要升级 TortoiseSVN 客户端 ，您可以按照以下步骤进行操作： 1. 下载最新版本的 TortoiseSVN 客户端 。您可以从官方网站（https:// tortoisesvn .net/downloads.html）或其他可信赖的软件下载网站获取最新版本的 TortoiseSVN 客户端 。 2. 安装最新版本的 TortoiseSVN 客户端 。如果您已经安装了旧版本的 客户端 ，请在升级前卸载旧版本。 3. 在您的Windows资源管理器中打开任何一个本地SVN工作副本。 4. 单击鼠标右键，选择“SVN更新”，以打开SVN更新对话框。 5. 单击“检查更新”按钮以获取最新版本的SVN文件。 6. 如果有新版本可用，单击“更新”按钮以将工作副本更新到最新版本。 7. 如果您在升级 TortoiseSVN 客户端 之前已经提交了修改，那么您需要在升级后提交您的修改以确保它们包含在最新版本中。完成以上步骤后，您已经成功升级了 TortoiseSVN 客户端 。

$ redis-server redis.windows.conf 之后得到: [146496] 09 Feb 22:44:55.106 # Creating Server TCP listening socket 127.0.0.1:6379: bind: No error 进入 redis-cli不需要输入密码. 这该怎么办呢