我是SVN的新手，我有一个问题吗？ [英] I'm new to SVNs, and I had a question?

问题描述

Hello Codeproject，



我已经做了很多年的程序员了，并且从来没有费心去搜索正确支持项目的方法（自动）。经过一段时间的搜索，今天我发现了一个叫做SVN的东西，我设法在没有服务器的情况下在本地进行设置，因为我不希望在服务器上共享它。



我想知道我的SVNVisualSVN有一种方法可以让它在构建解决方案后自动备份为新版本（通过调试或强制构建。）。 br />


如果涉及到Visual Studio的外部工具，我是一个完整的黑猩猩，所以如果这很明显，我很抱歉。

Hello Codeproject,

I've been a programmer for quite some years now, and have never bothered to search a way to properly back the project up(automatically). After a while of searching today I found out something called an 'SVN', I've managed to set it up locally without a server as I do not wish to share this on a server.

I was wondering there was a way for my SVN 'VisualSVN' on how to make it automatically back it up as a new version once the solution is build(Either by debugging, or a force build.).

I'm a complete chimpanzee if it comes to external tools for Visual Studio, so I'm sorry if this should be obvious.

推荐答案

备份的概念与版本控制的概念不兼容，后者旨在避免备份。相反，保存了所有更改的整个历史记录。当然，您可以备份整个代码库，并且可以创建不是Subversion的一部分的标记，但这是一种常见的做法。标签不会保存在每个版本中，它们会保存在重要步骤（例如版本）或更改软件版本的某些步骤上。



但是，你可能意味着简单的提交最近的变化。而且，我强烈建议不要将提交包括在构建项目中。您应该更好地隔离开发，批量构建和提交代码存储库。通常，开发人员多次构建解决方案，初步测试，并在确保更改有意义后，将它们提交到存储库。这个想法是：提交可能非常频繁，有时会在几分钟之后，但它们应该是一致的，永远不会破坏同一解决方案的其他开发人员的工作（虽然会发生错误，但我正在谈论原则）。每次开发人员在代码的一个或很少方面创建一组一致的修复更改时，提交都是有意义的。同时，在这种变化的中间，开发人员可能需要多次进行完整的批量构建。什么，你想提供一些可能的垃圾吗？



我建议你检查你的开发周期。同时，批量提交根本不是问题。只需阅读Subversion客户端文档（当然是常规的仅限控制台的客户端）。但是，首先，想想只使用一个好客户。你从来没有需要这样的批次。更好地考虑完美的全面批量构建，这是培养开发周期的必要条件。

-SA

The concept of "backup" is incompatible with the idea of Revision Control, which is designed to avoid backing up. Instead, the whole history of all changes is saved. Of course, you can backup the whole codebase, and you can create tags, which is not a part of Subversion, but is a common practice. The tags are not saved on each build, they are saved on important steps, such as releases, or some steps when you change the version of your software.

However, you may mean simple commit of the most recent changes. And still, I'll strongly recommend not to include even the commit to the build project. You should better isolate development, batch build and commit to code repository. Normally, a developer builds the solution several times, tests it preliminarily, and, after making sure the changes make sense, commits them to the repository. The idea is: commits could be quite frequent, sometime in a few minutes after each other, but they should be consistent, never disrupt the work of other developers of the same solution (mistakes happen though, but I'm talking to principles). Each time a developer creates a consistent set of changes of fixes in one or very few aspects of the code, it makes sense to commit. At the same time, in the middle of just one such change, a developer may need to do full batch build several times. And what, do you want to commit some possible garbage?

I would advise you to review your development cycle instead. At the same time, batch commit is not a problem at all. Just read the Subversion client documentation (regular console-only client, of course). But, first of all, think at using just a good client. You bay never need such batch. Better think of perfect comprehensive batch build, a must for cultured development cycle.

—SA

这篇关于我是SVN的新手，我有一个问题吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！