使用eclipse进行单人项目的版本控制？
我目前正在自己开展几个项目（至少开发部分只由我完成:)。 将Eclipse与不同的Java，R，SQL和其他源文件一起使用我想知道什么版本的控制系统最适合我。
当时Eclipse IDE的历史似乎已经足够了，但我不确定这是否会在一个月/一年内成立……
你会推荐什么解决方案？为什么？
更确切地说：如果我决定使用完整版控制系统，我肯定会使用SVN或git。 但我不确定是否有必要……
small update: has the release of Eclipse Helios added new opinions? a / 有必要有一个VCS
b / CVCS和DVCS完全不同
c / Eclipse目前正在将其所有项目移至Git （并且正在改进EGit ），因此Git将成为Eclipse上的VCS目标。
我推荐几乎所有的分布式版本控制系统。 我在愤怒中使用了git和hg ，并在fossil戳了戳（我包含它因为它提供了一些git和hg缺乏的function）。 我将打破我眼中的主要优点和缺点（注意：如果它们都具有相同的优点，我就不会提及它，例如，它们都快速轻巧）：
-
git- 优点
- 非常灵活
- GitHub上
- 缺点
- 陡峭的学习曲线
- 更灵活
- 上次我看时，Eclipse集成很蹩脚
- 优点
-
hg- 优点
- （IMO）更一致的命令
- 不太灵活
- 到位桶
- 缺点
- 不太灵活
- 没有像
git那么多的动力
- 注意事项
- 我最近没有检查Eclipse支持; 它曾经比
git更好，但似乎相当停滞
- 我最近没有检查Eclipse支持; 它曾经比
- 优点
-
fossil（免责声明：我没有愤怒地使用过这个）- 优点
- 由SQLite背后的人写的，所以你可以相当确定它的SOLID代码
- 提供的不仅仅是版本控制，例如，分布式错误跟踪器
- 易于设置以供其他人访问
- 缺点
- 没有像
git或hg那么多的动力 - 我很确定Eclipse对
fossil整合是不存在的（这是我最后一次看） - 没有免费托管我知道并行GitHub或BitBucket，所以你实际上必须自己托管你的仓库
- 没有像
- 优点
还有其他DVCS，特别是包括darcs和bzr ，但我没有用它们对它们有一个有价值的意见。
Git ，因为你可以马上开始，不需要中央存储库服务器。
其他一些优点（与其他SCM相比）：
- 不那么杂乱的文件系统：Git只在存储库的根目录创建一个文件夹（与SVN不同）。
- 不会对“普通”文件处理function造成太大影响。 例如，在SVN中，您需要使用自定义命令来重命名或移动文件。 Git的情况并非如此。
我觉得Git非常轻巧，所以没有理由等到你的项目“足够大”或者其他什么。
您的评论似乎是您真正的问题是您是否真的需要使用版本控制，因为它是一个单人项目。
设置和使用git或mercurial只需要很少的时间。 去做就对了。 如果你不需要它，你就会失去几分钟。 如果您确实需要它，它可能会为您节省数周时间。
据我所知，这只是你最喜欢哪个版本控制系统的问题。
但是我认为最性能的系统可能就是git。 http://www.eclipse.org/egit/为eclipse插件🙂
无论如何，我建议使用版本控制系统。 即使在小型项目中，您也会非常快地达到以前的解决方案可能会更好的程度。 如果没有版本控制系统，您将很难恢复更改或恢复到以前的版本（嗯，这是这些系统的一大优势，对吧？;））。
Git和Mercurial（hg）确实有很多动力作为分布式源代码库，但在我看来，对于一个单独的乐队，你会发现Subversion的支持最多。 如果你在Windows中有TortoiseSVN shell集成，它非常棒（它甚至可以与Trac集成），并且免费的Subversion托管已经到位，并且可以与ProjectLocker.com（他们使用Git和SVN）有一些个人经验。 此外，Subversion很容易直接集成到Eclipse IDE中。
使用SCM而不仅仅是Eclipse histoiry有很多好处，即使对于一个人来说也是如此：
-
对提交的评论：你可以说为什么你做了什么。 当您需要根据历史记录确定某些代码的作用时，这将有助于您。
-
备份：哦，你完全弄乱了你的Eclipse工作区？ 只需创建一个新的，并提取代码的新副本。
-
持续集成：在每次保存后检查代码是否构建，运行测试（这很重要），并创建实际的二进制文件以发送给客户。
这是你的安全网。 花点时间学习它，并正确使用它。 你最终会喜欢它:)