VCS 和单一开发者“团队”
我是一名单身开发人员，正在为我的公司开发一个项目。 我使用 subversion 和 Trac（用于错误跟踪以及与管理类型的通信）。 我有一台临时服务器和一台生产服务器。 今天我检查了一些代码，发现我的基于 FSFS 的 svn (v1.4) 存储库已严重损坏。 虽然这很令人沮丧，但它让我有机会将我的 VCS/staging 系统迁移到更现代的发行版（目前使用的是 2 年历史的系统）。 （就存储库而言，我确实有一个未损坏的当前版本的代码，因此，虽然我丢失了开发的所有历史记录和注释，但我并没有丢失任何代码。唷。）
目前我在 Ubuntu 上开发，生产运行 RHEL5-64。 我的硬件将保持不变，即 32 位 x86 单核系统。
我熟悉 SVN 及其构造，但 FSFS 损坏问题让我感到有点恼火。 我对 git 了解不多，只是知道它相当流行。 我目前使用 Trac 来管理问题，我真的很喜欢它与 svn 的集成。 似乎有插件可以支持 Git，但我不确定该开发的成熟度。
我目前正在考虑构建以下内容：
- Ubuntu 8.10 Desktop（然后添加 apache2 和其他软件包... 上次我尝试添加 GUI 我刚刚谈到的服务器版本 拔掉我的头发）
- SVN（因为我 熟悉它，Git 似乎也 对于一个人来说有点大材小用 团队）
- Trac（因为我很熟悉 与它一起工作并且它与 SVN 一起工作）。
我想要一些关于我的“新”VCS 系统的建议和想法。 我有理由应该迁移到 Git 吗？ 还有比 Trac “更好”的东西吗？
I am a single developer working on a project for my company. I use subversion and Trac (for bug-tracking and communication with management types). I have a staging server and a production server. Today I checked in some code and discovered that my FSFS-based svn (v1.4) repository is irreparably corrupt. While this is quite a bummer it has afforded me the opportunity to move my VCS/staging system to a more modern distro (currently on a 2-year old system). (As far as the repo is concerned I do have a non-corrupted current version of the code, so while I lose all the history and comments of the development I don't lose any code. Whew.)
Currently I develop on Ubuntu and production runs RHEL5-64. My hardware will be staying the same, a 32-bit x86 single-core system.
I am familiar with SVN and it's constructs, but am feeling a little burned by the FSFS corruption issue. I don't know much about git except that it's rather popular. I currently use Trac to manage issues and I really like it's integration with svn. It appears that there are plugins to enable support for Git, but I'm not sure of the maturity of that development.
I'm currently thinking of building the following:
- Ubuntu 8.10 Desktop (and then adding
apache2 and other packages...the
last time I tried adding a GUI to
the server edition I just about
pulled my hair out) - SVN (because I'm
familiar with it and Git seems to be
a bit overkill for a one person
team) - Trac (because I'm familiar
with it and it works with SVN).
I would like some suggestions and thoughts regarding my "new" vcs system. Is there a reason that I should move to Git? Is there something "better" than Trac?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我所有的个人项目都使用 git。 我无法想象还有什么比这更好的了。 一旦项目超出你的能力，它就特别有用。 除了偶尔向公共存储库添加推送之外，您的开发流程几乎不需要改变。
I use git for all my personal projects. I can't imagine anything nicer for that. It's especially useful once the project outgrows you. Your development process needs to change almost not at all, except to add an occasional push to a public repo.
git 相当轻量且易于使用。 语法与 subversion 略有不同，但仅此而已。 我不会说这太过分了。 确实没有什么比 subversion 使用起来更复杂或更简单了。
对于错误跟踪，我使用一个名为 Pivotal 的基于网络的系统。 它是免费的（目前），并且内置了一些项目管理功能。它非常适合小型团队，因为它非常简单，几乎不需要任何设置即可使用。
git is pretty light weight and easy to use. The syntax is slightly different from subversion, but that's about it. I wouldn't say it is overkill. There really is nothing about it that is more or less complicated to use than subversion.
For bug tracking I use a web based system called Pivotal. It's free (for now), and it has some project management features built in. It's great for small teams because it is very simple, requiring almost no setup for use.
Git 是一个很好的源代码控制系统，特别是如果您对命令行感到满意的话。 SVN 显然是一个很好的老主力，并且现在有了 1.5 合并支持，变得更好了。
Trac 很好，但是当我们查看它时，它仅限于单个项目，并且在源代码控制支持部门中表现不佳。
我们现在使用redmine，它允许多个项目，并允许我们为每个项目使用不同类型的源代码控制，包括git。
哦，是的，我们使用 hudson 来构建:)
Git's a fine source control system, especially if you're happy with the command line. SVN is obviously a good old workhorse, and is much better now with the 1.5 merge support.
Trac is good, but when we looked at it, it was limited to single projects and not good in the source control support department.
We use redmine now, which allows multiple projects and allows us to use different kinds of source control for each project, including git.
Oh yeah, and we use hudson for building :)
我们这里使用 svn/trac/ubuntu。
为了减少损坏的影响，我建议您实现一个自动化作业（cron？），每天热复制 svn 和 trac 存储库一次，并将它们发送到异地（rsync）进行备份。 我们在这里使用 NAS，但 S3 或 Dreamhost 之类的东西也很好用。
这样，如果出现问题，您只会损失一天的工作量。
SVN 热复制：
trac 热复制：
We use svn/trac/ubuntu here.
To reduce the impact of corruption, I'd suggest that you implement an automated job (cron?) to hotcopy both the svn and trac repositories once a day and send them offsite (rsync) for backups. We use a NAS here, but something like S3 or Dreamhost works well too.
That way, you will only lose one days worth of work if something goes wrong.
SVN hotcopy:
trac hotcopy:
我赞同 Redmine 的建议。 虽然我主要是 Mercurial 用户，但也支持 git（Darcs、svn 和 cvs 也是如此）。 分布式版本控制系统的好处之一是你基本上可以免费获得备份（你知道你应该备份旧的 svn 存储库，对吧？）...
I second the recommendation for Redmine. While I'm primarely a Mercurial user, git is also supported (as are Darcs, svn and cvs). One of the nice things about distributed version control systems is that you basically get backups for free (you know you should have done backups of your old svn repo, right?)...
Perforce 最多可供两名用户免费使用，并且有 良好声誉。
Perforce is free-as-in-beer for up to two users, and has a good reputation.
我要退后一步，以更广阔的视野。 如果您熟悉并熟悉 SVN 和 Trac，并且它们可以为您完成工作（暂时忽略腐败问题），我会质疑是否需要迁移。 这是源代码控制和错误跟踪，一般来说，只要它们为您的团队工作，我就看不到在管理环境、安装和评估新工具等方面花费大量精力。
我的 10,000 英尺建议是借此机会考虑完全外包此功能。 有一些主机（免责声明：我的公司就是其中之一）可以免费/低成本地为您托管 Subversion、Git、Trac、Lighthouse 等。 然后，当磁盘阵列、FSFS 或其他任何问题出现时，花费 100% 时间担心这些问题的人可以处理它，可能您甚至没有意识到这个问题。 如果您公司的政策允许您使用主机来实现此功能，那么您现在可能可以节省一个周末，以后也可以节省一个周末（以防下一次灾难），并节省无数美元的生产时间。
I'm going to step back and take a larger view. If you're familiar and comfortable with SVN and Trac, and they get the job done for you (ignore for a second the corruption issue), I would question the need to move. This is source control and bug tracking, and in general as long as they work for your team, I can't see spending a ton of effort on managing their environment, installing and evaluating new tools, etc.
My 10,000 ft. recommendation would be to use this opportunity to look at outsourcing this function entirely. There are hosts (disclaimer: my company is one) that will host your Subversion, Git, Trac, Lighthouse, etc. for you at free/low cost. Then, when something goes wrong with the disk array, or the FSFS or whatever, someone who spends 100% of his time worrying about this stuff can handle it, likely without you even becoming aware of the issue. If your company's policies allow you to use a host for this function, you might be able to save a weekend now, a weekend down the road (for the next catastrophe), and countless dollars of your productive time.