git svn 一个疯（傻）子的想法

以往的git或者tortoiseSVN说到底就是维护一个最新的项目，说真的，很多时候并不是很方便的功能，就算能追溯到很久以前的版本，但是在实际开发的时候依然会遇到很多很尴尬的场景

如果在很多项目中都需要调用同一个项目，同一个功能，同一个模块时，git或许就变得尴尬了，当然，出现这样的疑惑也可能是我对于git的机制了解不够深入的原因，那么问题来了如果我在项目在进行了一个改进，或者说修复了bug，但是这个bug很可能在很多项目依然存在，但是你要知道，这个项目数量改起来真的很令人崩溃。

当然，使用组件化能在一定程度上面能解决以上的问题，因为组件化的核心理念就是减少build以及其他操作的时间，每一个模块单独都可以作为一个单独的项目运行。

我们可以使用git对每一个组件进行维护，看起来的确可以解决当前的问题了，但是，这是不是有点治标不治本的感觉。

因为按照这个思路，项目会被无限划分，每当每个被分割的部分功能过大时，就一定隐隐然会有这种趋势，即"将组件的组件化"。

注意，以上出现的问题很可能是因为我个人的目光狭隘，知识水平跟不上时代的潮流的结果，因为个人觉得，大佬们一定早就解决了这个问题，只是我不知道罢了。

然后呢，我决定将这个问题作为一个智力游戏，仔细想想如果是我的话，会怎么偷这个懒。

整个项目是一棵树，是按照项目的目录逐渐展开的一个层级结构，我们的目的还是需要将每一个结点尽可能地宽泛的复用。

打个比方，当前的项目构建相当于在平面直角坐标系上面进行操作，为什么说是平面直角坐标系上面进行呢，因为无论怎么分叉都依然在"项目"这个概念中打转，就像有理数无论怎么加减乘除都不会得到一个无理数一样

那么从平面直角坐标系跳跃到空间直角坐标系，即二维到三维乃至更多维的坐标系(更多维这个是我瞎想的。。。)，个人感觉，多一条维度说到底也就是你有了一个新的度量来衡量当前的同一个事物罢了。

记得有一篇科幻小数描述了非线性时间的名叫"七肢桶"的外星人，他们和我们的世界就是在空间直角坐标系上面的三个轴分别选取了两个轴来感知，其实感受很可能是相似的，但是因为处于垂直的观念中，所以完全无法互相理解。我说这个干嘛= =

回到项目的构建上，我们(至少是我)对于项目构建的想法其实都是线性的，平面的，能不能用一种立体的方式来描述项目的管理和控制呢?

让我们回到git上面，我没有了解过git的具体实现，不过对于我而言，理解一个东西的原理常常只需要把自己代入进去就能得到答案，除非这个原理超越了我的认知水平。

"如果是我，我会怎么设计这个东西"。

首先对于文件版本管理的问题，如果是我的话，对于每一个版本只会储存那些被修改过的文件，虽然单纯保存修改也不错，但是观察版本管理工具的话，就能发现能直接看到每次版本变化前和版本变化后的文件全文，如果单纯只保存了修改，每次起码就要遍历一次所有修改，也未免太愚蠢了，好拿不如拙打。

正如我之前描述的，对于一个项目，所有的文件共同构建成了一棵树，一个文件夹就是一个普通节点，源头的文件就是叶子节点，项目的根目录就是树的根节点。这构成了一个平面。

我们不妨先构想出这棵树未来的样子，也就是这个项目已经满足了人类的所有需求，已经没有任何bug了，我们已经完全不必对这个项目进行任何的修改了，可以想象，这是一棵枝繁叶茂的大树。

将这棵树本身投影在x，y轴上，将时间作为z轴，我们可以看到什么?我们可以看到每一个节点在时间节点上的产生消亡再产生，再消亡状态(没准哪个13点工程师，就像我，没有做好好好的规划，直接开展了项目，导致后来项目的反复修改，很多节点虽然没有在这棵树的最终状态上，但是依然可以在这个三维立体坐标系上面看到它的踪迹)

三维体系就这么构成了。

当然项目一定不止一个。。。人们的要求很多的= =，只要不死

之前我已经说了，这样构思的目的其实只有一个，为了让项目的复用性尽可能的高，所以下一步的目的就是怎么让每一个组件(这个组件很可能代表着我前面所说的"组件的组件化的结果")尽可能地少的进行重复创建。(而且有这样一种情况，之前被废弃掉的组件很可能有着一定的价值，后面的组件可以基于他的基础上运作)。

讲到这里我想到了"全球脑的量子跃迁"，感觉很像对不对= =

在组件复用的问题上还有一个问题，对于每一个子组件进行的修改，我们是否应该让父组件完全应用的问题。

我们创建的每一个新的项目，都可以从之前的所有项目中获取对应的元素。之前的项目(在这个时候，之前的项目只有一个)，我们创建的新的项目的方法就是在之前的项目的所有节点(注意，这里的节点选取不不再是在平面中选取，而是在空间中选取)中选取自己需要的节点，如果之前的节点完全不满足自己的需要，新的项目则需要创建新的节点，这些节点相互组成新的节点，当最后变成了只有一个节点时，新的项目就诞生了。

当前空间中存在两棵树，并且每一个空间节点一旦发生变化，他的祖先节点一定会发生变化。

接下来的问题是，新的节点所构成的树一定还需要继续演进，我们在怎么维护这棵新的项目树呢

我们先不讨论之前这个问题，我们先来看看最初那棵树吧，他的所有节点都存在于空间直角坐标系里面，那么我们该怎么获取这棵树在每个时间点的结构呢?我之前已经描述了，我们有一个时间轴，时间是一个单向增长的(至少在这里我们这么默认)，我们在时间轴上选取一个时间点，过这个点作垂直这个时间轴的平面，我们不妨这么定义，这个平面将空间一分为二，在这个平面的"负空间"，他们的每一个点所对应的时间都是小于这个时间面的，在这个平面的"正空间"，他们的每一个点所对应的时间都是大于这个时间面的。

每一个节点在时间轴这个单一维度看来可能是一堆线段，也可能是射线，或是他们的组合，(不可能是直线，因为我假设了一个完美状态，之前已经说了)

那么绘制任意时刻的项目结构就很明显了，只需要在这个时间面上面画出所有的穿过这个时间面的实线对应的点，我们已经知道每个组件的关系了，这样，我们就能绘制出对应的项目树了

回到维护新树的问题上，我们该如何维护这棵新树呢?在新树的维护上，我们依然希望位置之前的原则，在修改子组件之后，父组件也会发生变化。

我之前应该也提及了，项目也是一个维度，只是并不是连续的，就像我之前所说的"非线性时间"一样的感觉(但不是一样的概念)，对于每一个节点，一旦在基于这个节点创建了一个新的项目之后，这个节点将产生两个分支(视情况可能不止两个，如果维持原状分支已经存在了，就只需要创建一个新的分支)-维持原状和作出改变两个分支，或者说两个状态(还是两个分支更为贴切，而且，对于项目本身的每一个节点，是可以在这两个分支之间随意跳跃的)。

子组件发生变化的同时，会传递给作出改变那个分支，依次类推。这就完成了项目的维护。