皮皮网

1.tortoisehg 要先安装 mercurial吗
2.Hotspot调试环境搭建-基于Ubuntu16.04.7-OpenJDK8u-Clion
3.Ubuntu下编译OpenJDK9
4.git是如何感知文件修改的?
5.写Java这么久，JDK源码编译过没？编译JDK源码踩坑纪实
6.常见的Web源码泄漏及其利用

tortoisehg 要先安装 mercurial吗

       ç‰ˆæœ¬æŽ§åˆ¶ç³»ç»Ÿï¼ˆVersion Control System / Revision Control System，或者叫做源码控制系统Source Control System，以下简称VCS），是软件开发人员最常用的工具之一，由于VCS是如此常用，所以花一些时间去了解它是有必要的。

       åˆ†å¸ƒå¼ç‰ˆæœ¬æŽ§åˆ¶ç³»ç»Ÿï¼ˆDistributed Version Control System,DVCS），是相对于集中式版本控制系统（Centralized Version Control System，CVCS）而言的，比如，使用人数最多的SVN、VSS就是典型的CVCS。如果你曾经用过SVN或VSS，就可以很容易理解什么叫做“Centralized” 。CVCS，是指只有一份数据仓库存放在一台服务器上，所有客户端都连接到这台服务器以读写数据仓库的工作模型。而DVCS模型则不然，每一台终端都有一份完整的数据仓库，所有终端之间都是平等的，并不存在唯一的一台“服务器”。所有的终端之间，可以自由地交换数据。

       DVCS可以很容易地模拟CVCS的工作方式，只要指定任意一台终端作为服务器，规定所有人都将更改推送到这台服务器，并且所有人也都从这台服务器获取更新即可。而与CVCS相比，DVCS则有以下优点：

       a) 更加安全的代码管理。

       åœ¨SVN中，每次提交都意味着正式的代码被更改，别人可以立即看到此次提交，并且可能直接影响到正在运行的系统（可能会有人立即将此更新拷贝到服务器），这导致一系列的问题。首先一个问题是，有人可能会无意中提交错误的、不可靠的代码。其次，这导致程序员不敢轻易签入更改，当程序进行一项耗时很久，大量修改的工作时，所有的修改都是没有经过VCS保护的，这是非常危险的，也不符合使用VCS的初衷。

       è€Œåœ¨DVCS中则不同，因为首先提交到自己本地仓库中，所以程序员可以尽量地向数据仓库提交更改，而不用担心这会影响到其他人或系统，这可以将程序员在开发过程中所产生的各个版本代码完善地保护起来，在周期较长的开发中，这一特点尤其显得重要。

       è™½ç„¶åœ¨SVN中有分支功能可以达到类似的目的，但是分支合并操作起来较为繁琐，而且非常容易发生冲突，结果就是很多应当使用分支的场合其实并没有使用分支。

       b) 摆脱网络的束缚，随时进行完整的工作。

       åœ¨SVN中，由于中央仓库只有一个，所以任何需要与仓库沟通的动作（例如查询历史版本，提交更改等等）必须首先联网，而在有些时候，这一束缚就显得不方便，而在DVCS中，则随时可以与数据仓库进行无缝的沟通，程序员可以向其中不停提交新的更改，或查询某个文件的历史版本，都可以在完全断网的情况下进行。

       c) 更加智能的代码合并。

       å½“两个人对同一份代码进行工作时，两个人的修改可能会产生冲突。然而，SVN当新的更改被提交时，SVN只能查看最终的版本，这导致SVN对某些差异很大的文件无法自动合并，而人工合并是很费时费力的。在Mercurial中，当两个不同的版本需要进行合并时，DVCS可以使用这个文件所有的修改历史来一步一步地还原整个修改的过程，这样一来，Mercurial的合并能力就远远地超过了SVN，所以在Mercurial中，极少会出现人工合并的问题。

       d) 更快的反应速度. 由于各种日常操作都是在开发人员的本机进行的, 所以与任何的CVCS相比, DVCS的操作反应速度都将快很多倍.

       å¦å¤–，对于个人项目来说，尤其适合使用DVCS，因为DVCS天然地擅长管理本地的数据仓库，不像CVCS那样必须架设一个服务端，一个客户端。

       å› æ­¤æ€»çš„来说，分布式结构的Mercurial具有SVN的所有优点，而又比SVN更加合理有效。

       ç›®å‰çš„DVCS最主要有Mercurial和Git两款软件，其中Git的原作者是Linus大神，用C语言编写，运行性能优于Mercurial（Mercurial是用Python写的，天生注定性能不可能比Git更快），但是Linus以及最初的开发团队并不打算开发Windows版本的Git，所以Git本身并不支持Windows，后来有了一个msysgit项目将Git移植到了windows平台，并且有了开发了一个TortoiseGit客户端，使得Git在windows下也变得容易使用了，但是在我使用的过程中，连续发生多次严重的故障，我怀疑其在windows下还不够成熟，因此采用与操作系统兼容完美的Mercurial。 Mercurial这个单词是水银的意思，所以Mercurial的命令名采用了水银的化学元素符号hg，这也是为什么它的图形终端叫做TortoiseHg，而不是TortoiseMercurial之类的。

       è¿™é‡Œï¼ˆ/read/）有一份完整的Mercurial文档，详细描述了Mercurial的各种细节，不过鉴于其是英文的，我简单再罗列一下Mercurial的基本用法。

       é¦–先，下载并安装一个TortoiseHg with Mercurial(mand here， 这会打开一个cmd命令窗，路径就是当前文件夹，直接输入命令hg init， 即可完成数据仓库的创建。

       ï¼ˆä»¥å‰æˆ‘也不喜欢用命令，但是使用Mercurial以后，我发现其实用命令并不麻烦，很多时候比TortoiseHg来得还要舒服一些）

       image

       åˆ›å»ºæ•°æ®ä»“库以后，再次右击， 会发现首先在一级右键菜单上增加了Hg Commit选项，而子项中则出现了一大排可用命令。这些暂时不用去理它。

       éšä¾¿æ–°å»ºä¸€ä¸ªæ–‡æœ¬æ–‡ä»¶ï¼Œç‚¹å‡»hg commit，输入一点注释（Mercurial强制要求每次commit必须写注释），点击提交即可。

       image

       æ³¨æ„å·¦ä¾§çš„文件列表， 必须先打上勾。因为是向Mercurial新增文件，所以必须先执行add命令， 然后才能commit，体现在这个图形界面上，就是先勾上左边，再点commit。

       å¦‚果使用命令，则分别输入：

       hg add

       hg commit –m “some comment here”

       ç¬¬ä¸€è¡Œhg add会将所有新增的文件标记为需要Mercurial进行追踪管理，第二句则是向数据仓库提交修改。

       è¿™é‡Œéœ€è¦æ³¨æ„çš„是Update命令。Mercurial的Update与SVN在实际效果上差异巨大。Update是用于使工作目录与本地数据仓库之间保持一致。所以，如果你是单人项目，总是在工作目录提交修改的话，它们肯定是完全一致的，Update命令将永远不必执行。（这大约也是为什么TortoiseHg把Update命令作为二级命令而不像Commit那样是一级菜单命令） 那么什么时候需要Update？先看一下push和pull。

       å‡å®šæˆ‘们刚才创建的仓库位于D:\repo1， 现在执行命令hg clone d:\repo1 d:\repo2， 或者在tortoisehg上点击clone执行相应操作（图形界面不再一一截图，很简单的操作），这样就创建了一个新的仓库repo2， 它与repo1是完全相同的。现在向repo1提交另外一些修改，显而易见的，repo2仍然停留在clone时的状态，repo1的最新修改repo2并不知道。 如果现在希望repo2也能更新到repo1的最新状态， 则有两种操作方式：

       1. Push。 Push顾名思义，是推送的意思，就是从repo1中推送数据到repo2， repo2 不需要做任何动作。在repo1目录下执行命令hg push d:\repo2。 或者点击tortoisehg的Syncronize， 在同步窗口中点击push命令：

       image

       ï¼ˆè¿™ç§æ“ä½œæˆ‘实在觉得还是命令方便一些。。。）

       å…¶ä¸­ï¼Œpush命令后面的路径并不是必须的。每个数据仓库可以有一个默认的远程仓库，如果在repo1中设置了默认远程仓库为repo2， 则只需要执行hg push 就可以了。当执行clone命令时，会自动把来源仓库设为默认远程仓库，所以在repo2中可以直接执行hg push或hg pull， 会自动到repo1中同步数据。

       å› ä¸ºrepo1并不知道repo2的存在， 所以如果需要手动设置默认远程仓库，如下这样操作：

       ç‚¹å‡»å³é”®â€”>TortoiseHg—>Repository settings,

       image

       ç‚¹å‡»Edit file, 如图所示, 修改default为需要指定的路径即可.

       ä¿®æ”¹å®Œæˆä»¥åŽ,即可直接执行hg push 而不用写成hg push d:\repo2了.

       2. Pull. Pull是拉取的意思, 即被更新的仓库主动从远程仓库拉取数据. 在本例中, 到repo2的目录下执行hg pull即可. 因为repo2是从repo1 clone来的, 所以repo2已经自动把repo1设置默认远程仓库, 不需要再写hg pull d:\repo1了.

       æ‰€ä»¥,无论是从repo1端push, 还是从repo2端pull, 都可以达到更新repo2数据仓库的目的.

       ç„¶è€Œéœ€è¦æ³¨æ„çš„是, 无论是push还是pull, 都只更新数据仓库, 而不更新工作目录.

       è®°ä½è¿™ä¸€ç‚¹éžå¸¸é‡è¦, 否则可能经常会迷惑为什么与预期不符. push或pull之后, repo2的数据仓库与工作目录已经不符, 这时就需要在repo2目录下执行hg update命令, 即可将工作目录更新到与数据仓库一致.

       å½“像SVN那样使用远程服务器作为主机时, 每次Pull后可以肯定是要执行update的, 这样两次操作显然带来不便, 在TortoiseHg中, 已经集成了这样的命令, 首先右键—>TortoiseHg—>Syncronize, 打开同步窗口,

       image

       ç‚¹å‡»Post Pull, 在弹出的小窗口中选择Update, 这样每次pull之后就会立即执行update了.

       æˆ–者在项目的根目录下写一个批处理文件, 包括以下两行即可:

       hg pull

       hg update

       ä»¥åŽæ¯æ¬¡éœ€è¦èŽ·å–æ›´æ–°æ—¶, 双击一下这个批处理即可, 我觉得还是命令方便……

       ä»¥ä¸Šç®€å•ç½—列了Mercurial的基本用法, 对于查询历史修改等操作, TortoiseHg的菜单已经非常简单, 与SVN也没有什么差别, 自行点击看一下即可.

       å…³äºŽåœ¨ä¸¤å°ç”µè„‘之间传递数据，Mercurial自带了一个简单的Serve命令，例如在d:\repo1目录下执行命令hg server， 会立即启动一个默认在端口监听的服务进程，这个命令会返回一个url地址，另一台电脑可以用hg clone <url> local-path 的形式复制本机的repo1仓库，但是这个serve命令显然只是一个非常简单的临时途径，如果要配置一台作为服务器的中央仓库，当然就不能仅仅使用serve命令了，而是应该使用IIS或其它web server，下一篇就介绍如何在IIS上架设一个Mercurial的Web Server,请参阅 分布式版本控制系统Mercurial

Hotspot调试环境搭建-基于Ubuntu..7-OpenJDK8u-Clion

       搭建基于Ubuntu ..7与OpenJDK 8u的Hotspot调试环境，涉及以下步骤：

       首先，安装版本管理工具Mercurial，其功能类似Git，用于管理OpenJDK版本。互站源码代理使用命令进行安装，遇到问题时尝试重启系统解决问题。

       其次，设置代理以加速下载国外仓库，如hg.openjdk.java.net。在用户家目录下创建.hgrc文件，配置代理信息。如果没有代理，可考虑从其他GitHub源下载代码，但同样会面临速度问题。

       接着，下载代码。下载地址提供的是一个壳工程，包含get_source.sh脚本。执行该脚本下载完整代码。

       下载时需注意，get_source.sh脚本仅适用于带有版本信息的仓库，使用其他方式下载的查重网源码源码文件不能执行。确保下载完整。

       预装依赖，安装GCC及编译所需依赖包。

       安装BOOT JDK，可通过华为JDK官网镜像下载，使用绿色解压方式。

       编译配置完成后，进行编译。使用bear命令行工具，生成compile_commands.json文件，此文件可用于导入Clion进行调试，无需生成CMakeList.txt文件。至此，环境搭建完成。

       搭建Hotspot调试环境，遵循上述步骤，确保所有操作正确无误，即可成功搭建基于Ubuntu ..7与OpenJDK 8u的调试环境。

Ubuntu下编译OpenJDK9

       为了在Ubuntu下编译OpenJDK9，首先安装VMware Workstation Pro和Ubuntu ..2 LTS，确保系统干净无其他应用。

       接着，通过Mercurial（hg）获取OpenJDK9的jdk18源码源代码，安装并下载hg，然后访问OpenJDK官网获取源代码的下载地址。按照指导，使用hg下载源代码，注意要执行get_source.sh脚本。

       在下载过程中可能会遇到问题，如“exited abnormally”或“stream ended unexpectedly”，此时可重新执行下载脚本。完成下载后，会生成约1GB的文件，包含大量.hg文件夹。

       阅读OpenJDK官网提供的JDK 9 Build README，以了解编译步骤。在配置阶段，应避免使用系统自带的OpenJDK8作为Boot JDK，推荐手动下载安装Oracle的Java 8版本以确保稳定性。

       访问Oracle官网下载Java 8，解压后将其放置在指定目录。配置编译环境时，可能会遇到缺少X库的问题，通过执行特定脚本解决。在多次尝试和调整后，完成配置。溯源码鸽子肉

       使用make images命令开始编译过程，整个编译耗时约8分钟。编译完成后，生成的build文件夹包含了所需JDK文件。将整个jdk文件夹复制到指定目录，并进行简单测试以验证编译成功。

       对于Mac和Windows用户，OpenJDK9的编译流程类似，只需根据各自操作系统的特定需求进行调整。

git是如何感知文件修改的?

       Git通过递归扫描仓库里所有文件的最后修改时间来感知文件是否修改。在执行commit操作时，Git会计算文件的SHA-1值以判断文件是否被改动。理论上，如果篡改被改动文件的最后修改时间至改动前，则Git可能无法察觉文件内容的更改。然而，这种操作的验证需要具体实验来确认。

       Meta（Facebook的母公司）使用修改过的Mercurial作为源代码管理系统，其原理与Git相似。由于使用单一代码库，repo内的文件数量可能达到百万甚至千万级别。为此，Meta发明了Watchman，web项目练手源码一个后台进程，通过inotify监控文件系统改动，并向Mercurial报告文件状态变化。Watchman在首次启动时需要扫描整个repo以建立初始状态。

       随着repo体积增大，Watchman的性能逐渐受限。为解决这一问题，Meta后来开发了EdenFS，一个虚拟文件系统，用于按需加载repo中的文件。这样，用户无需将数十个G的repo一次性克隆到本地磁盘，同时监控文件改动的功能直接集成于文件系统中。对于较小的repo，这种解决方案的优势不明显。

写Java这么久，JDK源码编译过没？编译JDK源码踩坑纪实

       在Java开发中，我们通常使用JDK环境来运行和编写Java代码。然而，你是否曾经好奇过，你天天使用的JDK源码究竟是如何由源码编译而来的呢？

       带着这个疑问，本文将带你一起探索如何手动编译一个JDK，从环境准备到编译过程，再到验证成果。过程中会遇到各种问题与解决之道，让你在实践中学习，提升编程技能。

       在编译过程中，环境的配置和工具的选择至关重要。首先，需要有一个与目标JDK版本相匹配的bootstrap JDK（boot JDK），以确保编译工作的顺利进行。接着，需要一个Unix环境，无论是Linux、macOS还是通过Cygwin、MinGW/MSYS等工具模拟的Windows环境。

       编译所需的工具链包括C++/C编译器、Mercurial版本控制工具等，用于管理源码。在编译前，还需要进行自动配置，确保所有依赖环境正确安装并兼容。

       下载JDK源码有两种方式：使用Mercurial工具或直接下载打包好的源码包。下载完成后，进入源码根目录进行配置和编译。编译过程可能需要一点时间，但通过验证编译结果，如输出提示，你将成功完成编译。

       编译完成后，JDK源码将会生成一系列产物，包括Java可执行程序、成品JDK套装等。验证成果时，可以通过运行编译出的Java程序来确认一切正常。接下来，将自己编译的JDK应用到实际项目中。

       在关联JDK源码并修改时，可能会遇到注释问题，如行尾注释、多行注释等。通过自行编译JDK，这些问题可以得到解决。同时，解决中文注释编译报错的问题，需要调整源码中字符编码设置。

       通过实践，你不仅能够深入了解JDK的编译过程，还能够解决实际开发中遇到的种种问题。最后，分享资源与持续更新的学习材料，鼓励大家在编程的道路上不断进步。

常见的Web源码泄漏及其利用

       Web源码泄漏漏洞及利用方法

       Git源码泄露是由于在执行git init初始化目录时，会在当前目录下自动创建一个.git目录，用于记录代码变更等信息。若未将.git目录删除即发布到服务器，攻击者可通过此目录恢复源代码。修复建议：删除.git目录或修改中间件配置以隐藏.git隐藏文件夹。

       SVN源码泄露源于其使用过程中自动生成的.svn隐藏文件夹，包含重要源代码信息。若网站管理员直接复制代码文件夹至WEB服务器，暴露.svn隐藏文件夹，攻击者可利用.svn/entries文件获取服务器源码。修复方法：删除web目录中的所有.svn隐藏文件夹，严格使用SVN导出功能，避免直接复制代码。

       Mercurial（hg）源码泄露通过生成的.hg文件暴露，漏洞利用工具为dvcs-ripper。运行示例需具体说明。

       CVS泄露主要针对CVS/Root和CVS/Entries目录，直接暴露泄露信息。修复工具为dvcs-ripper，运行示例同样需具体说明。

       Bazaar/bzr泄露为版本控制工具泄露问题，因其不常见但多平台支持，同样存在通过特定目录暴露源码的风险。具体修复方法与运行示例需进一步说明。

       网站备份压缩文件泄露是管理员将备份文件直接存放于Web目录，攻击者通过猜测文件路径下载，导致源代码泄露。常见备份文件后缀需具体列出，利用工具御剑用于这类漏洞的利用。

       WEB-INF/web.xml泄露暴露了Java WEB应用的安全目录，若直接访问其中文件需通过web.xml文件映射。WEB-INF目录主要包括文件或目录，通过web.xml文件推断类文件路径，最后直接访问类文件，通过反编译得到网站源码。

       .DS_Store文件泄露源于Mac系统中Finder保存文件展示数据的文件，每个文件夹下对应一个。若上传部署到服务器，可能造成文件目录结构泄漏，特别是备份文件、源代码文件的泄露。利用工具为github.com/lijiejie/ds_...

       SWP文件泄露为编辑文件时产生的临时文件，是隐藏文件，若程序意外退出则保留。直接访问并下载.swp文件，删除末尾的.swp后，可获得源码文件。

       GitHub源码泄露通过关键词搜索功能，容易找到目标站点的敏感信息，甚至下载网站源码。此类泄露源自代码托管平台，需注意个人代码管理安全。

       总结，Web源码泄漏涉及多个环节，从代码版本控制到备份存储，再到代码托管平台，每个环节都可能成为攻击点。修复策略包括删除隐藏文件、严格使用版本控制功能、加强代码备份安全措施以及提高代码托管平台安全意识。