版本控制与普通备份有何不同？
让我们忘记功能装饰,专注于版本控制的灵魂.在将备份称为VCS之前,备份是否必须交叉？或者,它们对于不同的目标市场而言,同样重要吗？
如果存在根本区别,那么达到版本控制状态的绝对最低要求是什么？
当您回答时,请不要只列出大多数版本控制系统已经或应该具有的功能(例如增量压缩,分布式/中央存储库和并发访问解决方案),除非它们根据定义实际上是VCS所必需的.
我的一些同事确信将构建工件提交到subversion存储库是个好主意.这样的论点就是这样,测试机器上的安装和更新很容易 - 只需"svn up"!
我敢肯定有一些重要的论据反对这种不好的做法,但我能想到的都是蹩脚的,比如"它需要更多的空间".没有做到这一点的最佳原因是什么？我们应该采取哪些其他方法呢？
这适用于Java代码,如果这会产生影响.一切都是从Eclipse编译的(没有自动PDE构建).
当我说添加构建工件时,我的意思是提交看起来像这样:
"Added the new Whizbang feature"
M src/foo/bar/Foo.java
M bin/Foo.jar
每个代码更改都有相应的生成的jar文件.
人类编写源代码
版本控制用于记录源代码中的更改
工具处理源代码并生成机器可读的东西(exec,libs,GUI代码等)
每隔一段时间我就想保存工具输出的副本(例如保存ARM的beta版本的可执行文件).我可以手动保存工具的输出,给它一个反映修订控制历史记录中的点的名称(例如使用标签名称).这似乎很尴尬,容易出错.
我想深入了解两件事:
使用修订控制在修订历史记录图表中的特定位置存储工具生成的输出的优缺点是什么？您使用哪些非RCS工具作为替代方案？
在mercurial,git中,什么是在特定修订中包含工具生成的输出而不是其他修改的最佳方法