I recommend you to check in your files before you start to do heavy modifications to them (check in early, check in often).
It depends, some people like to have the trunk stable, work in branches and then merge the branches back to the trunk when the features are ready, but you can also commit directly to the trunk.
It also depends on how you will work and what do you like to have in trunk (the latest stable version or the latest bleeding edge version).
There are many ways to do this, but the most common I have successfully worked with is working off a development branch and merging to the trunk when you get to a stable point (minor version releases, milestones, etc).
If you haven't already, check out the red book, it is a great resource for svn information.
When creating a new project from scratch I usually do so in a user area in SVN such as
/svn/users/me/project1
this is because most projects start out as throw away prototypes and I rarely use branches for these. Once a project becomes official and nears it's first "prototype" release I will migrate it over to it's own repository
/svn/project1/trunk
The use of branches require a bit of extra work so we don't use them unless they're necessary. Which is when multiple people are working on the same project and collisions are often or I'm working on a feature which I might decide to revert and throw away. If done in a branch I can simply choose not to merge and just delete it.
我读过有关公司使用 Subversion 作为应用程序存储库的信息。 因此，他们告诉服务器他们想要安装应用程序 Y 的版本 X。然后服务器在 SVN 服务器上运行更新。 他们也在那里存储配置文件。 然后对配置所做的任何更改（通过最终客户的单独 Web 界面）都会提交到 SVN 配置存储库。 这太棒了。 当然，这些人在 Win2k3 上使用 MS Power Shell，但该技术仍然可以应用于其他地方。
All answers suggest that you check in early, check in often, I couldn't agree more. So thats all I'll say about that. However, I read the summary as: What kind of uses can Subversion fit? So here's an answer for that.
I've read about companies using Subversion as their application repository. So, they tell the server that they want to install Version X of application Y. Then the server runs an update on the SVN server. And they also stored configuration files in there too. And any changes made to the config (via a separate web interface for end-customers) were then committed to the SVN config repo. This is brilliant. 'Course these guys were using MS Power Shell on Win2k3, but still the technique can be applied elsewhere.
Check in IMMEDIATELY, not early. Even if you have nothing more to commit than an ad-hoc text file containing brainstorms and some horribly cryptic psuedo code, commit it.
I (like many) find projects just like your's while doing some kind of code search, or searching for a program that does what I want. I will read your front page then immediately browse your SVN trunk to see what you're doing.
If you have zero code in the trunk, I'll likely forget all about you. If you have at least some file explaining your intended design and some psuedo code, I'll likely start sending you patches that show my ideas.
A project with an empty repository screams "itch that will never be scratched" .. so push something as soon as you can.
After that, commit often. I like to make many small, ordered commitments so its easy to track regressions and roll back/fix toxic revisions.
Check in once you have created your blank baseline project/solution structure. Blank because at this state it is actually compilable albeit no working code. The principle is to keep the entire project - at least - in a compilable state throughout development as the team incrementally and regularly commits small changes, so that the build hardly gets broken.
There is no law requiring the initial check-in must happen at the Trunk or a Branch. You may start up the Trunk with empty project so it is stable right from the start, then branch out to carry out development and merge it back to the Trunk once complete. You may also choose to check-in the empty project to a Branch and develop the first working or base feature before merging something substantial into the Trunk. Either way, based on point #1 the Trunk should be stable and high quality. Only merge high-quality content into the Trunk.
Again there is no strict mandate on this type of practices. Some teams branch out everything, even simple refactoring of variable name changes. Some teams do not even know branching/merge and develop everything in a single branch (the Trunk). Every team has its own level of balance on this issue. My personal guideline is if there are going to be new features or major bug fixes or re-design, branch it out to test. If it is a minor fix like string spelling errors or displaying four decimal places instead of two in the web page, fixing the Trunk copy should suffice. Of course, interpretations of "major" versus "minor" are going differ so the development/team leads should establish their standards. Either way, there must be unit/integration tests accompanying the changes to verify the Branch or the Trunk are working as intended, as defect-free as possible. The keyword to remember is always "high quality, tested code".
发布评论
评论（6）
我建议您在开始对文件进行大量修改之前先签入文件 (尽早签入，经常签入）。
这取决于，有些人喜欢主干稳定，在分支中工作，然后在功能准备好时将分支合并回主干，但您也可以直接提交到主干。
这还取决于您的工作方式以及您喜欢在主干中拥有什么（最新的稳定版本或最新的前沿版本）。
I recommend you to check in your files before you start to do heavy modifications to them (check in early, check in often).
It depends, some people like to have the trunk stable, work in branches and then merge the branches back to the trunk when the features are ready, but you can also commit directly to the trunk.
It also depends on how you will work and what do you like to have in trunk (the latest stable version or the latest bleeding edge version).
我建议尽早并经常检查。
有很多方法可以做到这一点，但我成功使用的最常见的方法是在开发分支上工作，并在达到稳定点（次要版本发布、里程碑等）时合并到主干。
如果您还没有，请查看红皮书，它是一个很好的 svn 信息资源。
I suggest checking in early and often.
There are many ways to do this, but the most common I have successfully worked with is working off a development branch and merging to the trunk when you get to a stable point (minor version releases, milestones, etc).
If you haven't already, check out the red book, it is a great resource for svn information.
当从头开始创建一个新项目时，我通常在 SVN 的用户区域中这样做
，因为大多数项目都是从废弃原型开始的，而我很少使用分支。 一旦项目正式发布并接近第一个“原型”版本，我会将其迁移到它自己的存储库。
分支的使用需要一些额外的工作，因此除非有必要，否则我们不会使用它们。 当多个人在同一个项目上工作并且经常发生冲突时，或者我正在开发一个我可能决定恢复并丢弃的功能时。 如果在分支中完成，我可以简单地选择不合并并删除它。
When creating a new project from scratch I usually do so in a user area in SVN such as
this is because most projects start out as throw away prototypes and I rarely use branches for these. Once a project becomes official and nears it's first "prototype" release I will migrate it over to it's own repository
The use of branches require a bit of extra work so we don't use them unless they're necessary. Which is when multiple people are working on the same project and collisions are often or I'm working on a feature which I might decide to revert and throw away. If done in a branch I can simply choose not to merge and just delete it.
所有答案都建议您早点入住、经常入住，我完全同意。 这就是我要说的全部内容。 然而，我读到的摘要是：Subversion 适合什么样的用途？ 所以这是一个答案。
我读过有关公司使用 Subversion 作为应用程序存储库的信息。 因此，他们告诉服务器他们想要安装应用程序 Y 的版本 X。然后服务器在 SVN 服务器上运行更新。 他们也在那里存储配置文件。 然后对配置所做的任何更改（通过最终客户的单独 Web 界面）都会提交到 SVN 配置存储库。 这太棒了。 当然，这些人在 Win2k3 上使用 MS Power Shell，但该技术仍然可以应用于其他地方。
All answers suggest that you check in early, check in often, I couldn't agree more. So thats all I'll say about that. However, I read the summary as: What kind of uses can Subversion fit? So here's an answer for that.
I've read about companies using Subversion as their application repository. So, they tell the server that they want to install Version X of application Y. Then the server runs an update on the SVN server. And they also stored configuration files in there too. And any changes made to the config (via a separate web interface for end-customers) were then committed to the SVN config repo. This is brilliant. 'Course these guys were using MS Power Shell on Win2k3, but still the technique can be applied elsewhere.
立即入住，不要提前入住。 即使您除了包含头脑风暴和一些极其神秘的伪代码的临时文本文件之外没有什么可提交的，也请提交它。
我（像许多人一样）在进行某种代码搜索或搜索可以实现我想要的功能的程序时找到了与您类似的项目。 我会阅读你的首页，然后立即浏览你的 SVN 主干，看看你在做什么。
如果你的后备箱里有零代码，我可能会忘记你。 如果您至少有一些解释您的预期设计的文件和一些伪代码，我可能会开始向您发送显示我的想法的补丁。
一个拥有空存储库的项目尖叫着“永远不会被抓伤的痒”..所以尽快推送一些东西。
之后，经常提交。 我喜欢做出许多小的、有序的承诺，这样很容易跟踪回归并回滚/修复有毒的修订。
Check in IMMEDIATELY, not early. Even if you have nothing more to commit than an ad-hoc text file containing brainstorms and some horribly cryptic psuedo code, commit it.
I (like many) find projects just like your's while doing some kind of code search, or searching for a program that does what I want. I will read your front page then immediately browse your SVN trunk to see what you're doing.
If you have zero code in the trunk, I'll likely forget all about you. If you have at least some file explaining your intended design and some psuedo code, I'll likely start sending you patches that show my ideas.
A project with an empty repository screams "itch that will never be scratched" .. so push something as soon as you can.
After that, commit often. I like to make many small, ordered commitments so its easy to track regressions and roll back/fix toxic revisions.
创建空白基线项目/解决方案结构后，请签入。 空白，因为在这种状态下，它实际上是可编译的，尽管没有工作代码。 原则是在整个开发过程中保持整个项目 - 至少 - 处于可编译状态，因为团队增量并定期提交小更改，以便构建几乎不会被破坏。
没有法律要求首次办理登机手续必须在干线或分行进行。 您可以用空项目启动 Trunk，这样它从一开始就稳定，然后分支进行开发，并在完成后将其合并回 Trunk。 您还可以选择将空项目签入分支并开发第一个工作或基本功能，然后再将实质性内容合并到主干中。 无论哪种方式，基于第一点，主干应该稳定且高质量。 仅将高质量内容合并到主干中。
同样，对于此类做法并没有严格的规定。 有些团队扩展了一切，甚至是变量名称更改的简单重构。 有些团队甚至不知道分支/合并并在单个分支（主干）中开发所有内容。 每个团队在这个问题上都有自己的平衡程度。 我个人的指导方针是，如果有新功能或重大错误修复或重新设计，请将其分支出来进行测试。 如果是一个小修复，例如字符串拼写错误或在网页中显示四位小数而不是两位小数，修复主干副本就足够了。 当然，“主要”与“次要”的解释会有所不同，因此开发/团队领导应该建立他们的标准。 无论哪种方式，都必须有伴随更改的单元/集成测试，以验证分支或主干是否按预期工作，并尽可能无缺陷。 要记住的关键词始终是“高质量、经过测试的代码”。
Check in once you have created your blank baseline project/solution structure. Blank because at this state it is actually compilable albeit no working code. The principle is to keep the entire project - at least - in a compilable state throughout development as the team incrementally and regularly commits small changes, so that the build hardly gets broken.
There is no law requiring the initial check-in must happen at the Trunk or a Branch. You may start up the Trunk with empty project so it is stable right from the start, then branch out to carry out development and merge it back to the Trunk once complete. You may also choose to check-in the empty project to a Branch and develop the first working or base feature before merging something substantial into the Trunk. Either way, based on point #1 the Trunk should be stable and high quality. Only merge high-quality content into the Trunk.
Again there is no strict mandate on this type of practices. Some teams branch out everything, even simple refactoring of variable name changes. Some teams do not even know branching/merge and develop everything in a single branch (the Trunk). Every team has its own level of balance on this issue. My personal guideline is if there are going to be new features or major bug fixes or re-design, branch it out to test. If it is a minor fix like string spelling errors or displaying four decimal places instead of two in the web page, fixing the Trunk copy should suffice. Of course, interpretations of "major" versus "minor" are going differ so the development/team leads should establish their standards. Either way, there must be unit/integration tests accompanying the changes to verify the Branch or the Trunk are working as intended, as defect-free as possible. The keyword to remember is always "high quality, tested code".