版本管理

问题： Error:svn: E195020: Cannot merge into mixed-revision working copy [241:250]; try updating first 分析： 提示的是合并代码的版本号有出入，这种情况在使用AS开发多个android项目时，使用svn进行版本管理会出现； 主要是服务器版本号和本地版本号没有同步 如果是一个项目的版本号高于了另外一个项目的版本号，这种情况使用TortoiseSVN客户端是可以直接合并同步的； 但是AS使用的TortoiseSVN command line，稍微有点儿出入 解决方式： 方式一、使用AS 更新代码库，最好是提交完（commited）就及时更新（update） 方式二、直接使用TortoiseSVN对当前项目先执行update, 然后在执行后续操作 来源： 51CTO 作者： 扶垚而上 链接： https://blog.51cto.com/12539515/2389209

1.查看历史版本 ·git log ·git reflog 2.版本回退 ·git reset --hard HEAD^(HEAD代表当前版本) ·HEAD^代表回退到上一个版本 以此类推 ·HEAD~1 和上面同理 ·也可以用git reflog 查看历史版本 用版本号来回退（git reset --hard+版本号） 3.撤销修改 ·运行git status命令会显示当前工作区，暂存区，仓库的状态。当工作区所有代码都提交到仓库，并和仓库保持一致时会显示： On branch master nothing to commit,working tree clean 1.将暂存区代码撤销到工作区： ·git reset HEAD +文件名 2.撤销工作区代码 ·git checkout + 文件名 4.对比文件 1.对比本地仓库与工作区 ·git diff HEAD 文件名 2.对比本地仓库各版本代码 ·git diff HEAD HEAD^ --文件名 5.文件删除 1.直接删除文件或者文件夹 2.先撤回到工作区 ·git reset HEAD 文件名 然后删除 3.从版本库撤回 ·先删除文件或者文件夹 ·git add . ·git commit -m 来源： https://www.cnblogs.com/sexy-945/p/11366496.html

Eclipse中CVS 版本管理 1.1 CVS 简介 CVS 是 Concurrent Versions System （并发版本系统）的简称。它是一个开放源代码的项目，是当前最流行的版本控制系统，目前绝大部分 Open Source 项目都使用它来做版本管理。微软的 VSS 也可以用来进行 Java 项目的版本管理，但在学会使用 Eclipse 后，使用 CVS 。 CVS 采用客户机 / 服务器体系，代码、文档的各种版本都存储在服务器端，开发者首先从服务器上获得一份复制到本机，然后在此基础上进行开发。开发者可随时将新代码提交给服务器，也可以通过更新操作获得最新的代码，保持与其他开发者的一致。 由于 Eclipse 本身内置了 CVS 客户端，只要再建立一个 CVS 服务器就可以使用这一功能强大的版本控制系统。 CVS 的功能虽强大，但一般项目通常只用到其 20% 的功能，所以只要了解最常用的操作就可以了。本系统是的是 Eclipse 3.0.1 版本，下面将以面向实际项目使用需要的方式来介绍 CVS 。 1.2 CVS 服务器端的安装与配置 CVS 起源于 UNIX/Linux 平台，由于我们平时大多使用的是 Windows 系统，所以在 UNIX/Linux 平台下安装使用 CVS 服务器端的方法，我们不再重复。 CVS 服务器在 Windows 平台的版本： CVSNT

感谢 http://zh-tw.whygitisbetterthanx.com的《why git is better than x》 一.便宜的本地分支 GIT让你可以拥有多个本地的分支，它们可能是完全独立的，而且建立，合并和删除这些开发分支只需要几秒钟的时间。 二.所有内容都在本地端 你可以很容易拥有不只你自己的分支副本，还有其他任何和你一起工作的人的分支都可以存在你的GIT仓库中而不打扰你原有的东西。 三.GIT很快 四.GIT很小 五.暂存区域 和其他系统不一样，GIT有称为staging area或者index的东西，这是一个中间地带让你可以在提交前设定你想要提交什么。 六.它是分散式的(分布式无中心管理) GIT是分散式的，你不是只checkout目前最新版的原始代码，而是clone了整个仓库。这意味着使用GIT不会因为遗失单一的点而造成灾难，除非就只有那么一个点。 七.适用任何工作流程 八.我们有GitHub GitHub=社交网络+hosting服务 九.容易学习 来源： oschina 链接： https://my.oschina.net/u/98095/blog/12707

前些天参加了公司内一个项目的代码库管理策略的讨论。以前在客户那里做咨询的时候类似的讨论也有很多，但是相对来说客户的情况比较稳定，而且项目与项目之间相似度比较高，所以可选的方式并不多。这一次讨论，因为是发生在ThoughtWorks内部，大家处于完全平等的位置，敞开讨论，反而让原来死板的理论真的活了起来。 背景 CWP是ThoughtWorks内部比较大的一个项目有30多人，当然这跟我们咨询的项目没法比。不过ThoughtWorks比较崇尚小团队，我们认为超过10个人的团队就应该考虑拆分了，这对于项目管理、团队沟通、架构隔离都有好处。项目原来主要关注于一个产品MTX，最近准备加入MTL产品，我们认为这是一个好的时机。MTX和MTL共享一个账户管理的功能。我们想把这个功能抽出来单独成为一个产品——Account Setting，因为未来还有其他的产品也要依赖于这个功能。由于人力资源的限制，Account Setting实际上要放到MTL团队开发，MTX与Account Setting的集成也要放到MTL团队开发。Account Setting的部分功能在MTX中已经实现。 讨论 一个基本的问题是——码库分开还是合在一起。 首先不论是分开还是合在一起都是可以工作的。其次，不论是分开还是合在一起都有相对的劣处。看上去很简单的两点。不事先明确地承认这两点，往往会导致争论陷入僵局。而且

本文参考链接地址： https://blog.csdn.net/u010104435/article/details/79633067 pyenv的使用 1.使用pyenv进行python版本管理 1.1安装对应的依赖包，如果不安装后续操作可能会因为缺少某一个变量包而出现错误 sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvmgit 1.2从GIT上克隆源码到本地的 ~/.pyenv 文件，后续操作基于该路径进行 git clone git://github.com/yyuu/pyenv.git ~/.pyenv 1.3配置环境变量，官方提供的方法： echo 'export PATH="$HOME/.pyenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc source ~/.bashrc 1.4常用命令 pyenv version # 查看当前系统使用的python版本 pyenv

目前维护的项目是我从入职到现在一直维护与开发的一个超大型业务系统；解决方案中有数十个项目在其中，因为各子项目的维护人员不同，导致相同的Nuget包存在两个，甚至四个不同版本的存在。包版本的不同经常导致各种编译或者发布失败的问题；拖延开发和QA 的工作效率，我们小组职责就是为了提高工作人员的效率；今天领导找我，要我把解决方案中，所有的Nuget 包版本都唯一化。 我使用Visual Studio 2019 来解决此问题。使用 Visual Studio 2019 打开 解决方案，点击工具 > Nuget 包管理器 > 管理解决方案的Nuget 程序包 > 合并。 合并中展示的程序包，就是存在不同版本的程序包，需要我们处理的；选择需要合并的程序包 > 选择版本 > 安装。 这真的是今天要讲的重点吗？不。我想阐述的是我在合并过程中包与包之间兼容的问题。问题是：在本地合并完包后，编译成功，本地运行成功；但是签入到测试环境的时候，发生了一个问题，那就是发布后的dll 不是我升级的版本，而是旧的。重点来了，我想讲解的是我今天是如何处理这个问题的。 我先排查是不是我版本是否成功 检查代码是否签入 检查服务器发布代码 清理bin 目录 经过上面几个步骤还是没有解决问题；于是请教同事，他要我删了sln 文件中的引用，要编译自动引入packages中的包，结果编译失败；然后要我卸载要升级的程序包

　　人禾娱乐绿色VIP注册通道之基于 Lerna 管理 packages 的 Monorepo对于维护过多个package的同学来说，都会遇到一个选择题，这些package是放在一个仓库里维护还是放在多个仓库里单独维护，本文通过一个示例讲述了如何基于Lerna管理多个package，并和其它工具整合，打造高效、完美的工作流，最终形成一个最佳实践 　　 　　背景 　　 　　最近在工作中接触到一个项目，这个项目是维护一套 CLI，发到 npm 上供开发者使用。先看一张图： 　　 　　项目仓库中的根目录上就三个子模块的文件夹，分别对应三个 package，在熟悉了构建和发布流程后，有点傻了。工作流程如图中所示： 　　 　　使用webpack、babel和uglifyjs把 pkg-a 的 src 编译到 dist 　　 　　使用webpack、babel和uglifyjs把 pkg-b 的 src 编译到 dist 　　 　　使用webpack、babel和uglifyjs把 pkg-main 的 src 编译到 dist 　　 　　最后使用拷贝文件的方式，把pkg-main、pkg-a、pkg-b中编译后的文件组装到 pkg-npm 中，最终用于发布到 npm 上去。 　　 　　痛点 　　 　　不好调试。因为最终的包是通过文件拷贝的方式组装到一起的，并且都是压缩过的

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/NlOn7er0ixY1HO40dq5Gag 作者：孔垂亮 目录 一、背景 二、Monorepo vs Multirepo 三、Lerna 1、Lerna 是什么 2、开始使用 （1）安装 （2）项目构建 四、Lerna的最佳实践 1、优雅的提交 2、自动生成日志 3、编译、压缩、调试 五、结语 六、参考文献 对于维护过多个package的同学来说，都会遇到一个选择题，这些package是放在一个仓库里维护还是放在多个仓库里单独维护，本文通过一个示例讲述了如何基于Lerna管理多个package，并和其它工具整合，打造高效、完美的工作流，最终形成一个最佳实践 背景 最近在工作中接触到一个项目，这个项目是维护一套 CLI，发到 npm 上供开发者使用。先看一张图： 项目仓库中的根目录上就三个子模块的文件夹，分别对应三个 package，在熟悉了构建和发布流程后，有点傻了。工作流程如图中所示： 使用webpack、babel和uglifyjs把 pkg-a 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-b 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-main 的 src 编译到 dist

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/NlOn7er0ixY1HO40dq5Gag 作者：孔垂亮 对于维护过多个package的同学来说，都会遇到一个选择题，这些package是放在一个仓库里维护还是放在多个仓库里单独维护，本文通过一个示例讲述了如何基于Lerna管理多个package，并和其它工具整合，打造高效、完美的工作流，最终形成一个最佳实践 背景 最近在工作中接触到一个项目，这个项目是维护一套 CLI，发到 npm 上供开发者使用。先看一张图： 项目仓库中的根目录上就三个子模块的文件夹，分别对应三个 package，在熟悉了构建和发布流程后，有点傻了。工作流程如图中所示： 使用webpack、babel和uglifyjs把 pkg-a 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-b 的 src 编译到 dist 使用webpack、babel和uglifyjs把 pkg-main 的 src 编译到 dist 最后使用拷贝文件的方式，把pkg-main、pkg-a、pkg-b中编译后的文件组装到 pkg-npm 中，最终用于发布到 npm 上去。 痛点 不好调试。 因为最终的包是通过文件拷贝的方式组装到一起的，并且都是压缩过的，无法组建一个自上到下的调试流程