blocks|key|990003|text|Git不能检出一个子树并将其作为一个完整的存储库来使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|990004|例如，使用Subversion，您可以签出目录"trunk“，并将其作为存储库来使用。您还可以查看“分支/功能1”并使用它。使用Git，只能签出根目录(尽管在最近的版本中，你可以执行稀疏签出，它不会下载所有文件，但你仍然必须签出根目录)。在Git中，您将使用分支而不是检出子树。|990005|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Git can't check out a subtree and use that as though it was a complete repository.

For example, with Subversion you can check out the directory "trunk" and use that as if it was a repository. You can also check out "branches/feature1" and use that. With Git it's only possible to check out the root directory (although with recent versions you can do a sparse checkout which doesn't download all files, you still have to check out the root though). In Git you would use branches instead of checking out subtrees.

blocks|key|990047|text|Git不能svn+lock文档，因此有人可以阻止其他人编辑不可自动合并的实体(如Word或Excel文件)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|990048|entityMap|0|LINK|mutability|MUTABLE|url|http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html^0|5|8|5|8|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

Git can not <a href="http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html" rel="noreferrer"><code>svn lock</code></a> documents, so that someone could prevent others from editing a non-auto-mergeable entity (such as Word or Excel file).

blocks|key|775050|text|对我们来说，SVN最重要的特性是能够存储整个锁文件。由于我们使用的是二进制和不可合并的CAD文件，因此任何DVCS的基于合并的工作流程都不能在这里工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|775051|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For us the most important feature of SVN ist the ability to repositoy-wide lock files. Since we work with binyary and unmergeable CAD files the merge-based workflow of any DVCS doesn't work here.

blocks|key|990148|text|Git无法存储空目录。可以说，这是一个优势，但这是git不能做但svn可以做的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|990149|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Git can't store empty directories. Arguably, this is an advantage, but it is one thing that git can't do but svn can.

blocks|key|775151|text|由于Git的分布式特性，/sysadmin没有一个地方(服务器)可以备份整个代码库。每个节点必须进行自己的备份，或者每天合并到一个进行每日备份的节点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|775152|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

With Git's distributed nature, there is no single place (server) where you/sysadmin can backup the entire code base. Each node must take their own backups or merge daily to a node which takes daily backups.

blocks|key|775454|text|Subversion是一个中央存储库|type|unstyled|depth|inlineStyleRanges|entityRanges|data|775455|虽然许多人希望拥有分布式存储库，以获得速度和多个副本的明显好处，但在某些情况下，中央存储库更可取。例如，如果你有一些关键的代码，你不想让任何人访问，你可能不想把它放在Git下。许多公司希望保持他们的代码集中，并且(我猜)所有(严肃的)政府项目都在中央存储库下。|775456|颠覆是一种传统智慧|775457|这就是说，许多人(特别是经理和老板)都有通常的方法来对版本进行编号，并将开发看作是随着时间的推移而硬编码到他们大脑中的一条“单线”。无意冒犯，但Git的慷慨是不容易接受的。任何一本Git书的第一章都会告诉你，把所有传统的理想从你的脑海中抹去，重新开始。|775458|Subversion只有一种方法，没有其他方法|775459|SVN是一种版本控制系统。它只有一种方法来完成它的工作，每个人都是这样做的。句号。这使得从/从SVN到其他集中式VCS的转换变得很容易。Git甚至不是一个纯粹的VCS+--它是一个文件系统，在不同的情况下如何设置存储库有许多拓扑结构--而且没有任何标准。这使得选择一个更加困难。|775460|其他优势包括：|775461|SVN+supports+empty+directories
SVN+has+better+Windows+support
SVN+can+check+out/clone+a+sub-tree
SVN+supports+exclusive+access+control+svn+lock+which+is+useful+for+hard-to-merge+files
SVN+supports+binary+files+and+large+files+more+easily+(and+doesn't+require+copying+old+versions+everywhere).
Adding+a+commit+involves+considerably+fewer+steps+since+there+isn't+any+pull/push+and+your+local+changes+are+always+implicitly+rebased+on+svn+update.|code-block|syntax|javascript|775462|找到了这一点，并同意它。再一次，当你触摸git时，新蜜蜂是相当的农业。我不能信任git或github，直到更多的安全变化，比如超越了可破解的ssh密钥。|775463|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|13|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Subversion is a central repository

While many people will want to have distributed repositories for the obvious benefits of speed and multiple copies, there are situations where a central repository is more desirable. For example, if you've got some critical piece of code that you don't want anyone to access, you'd probably not want to put it under Git. Many corporations want to keep their code centralized, and (I guess) all (serious) government projects are under central repositories.

Subversion is conventional wisdom

This is to say that many people (especially managers and bosses) have the usual way to number the versions and seeing the development as a "single line" along time hardcoded into their brain. No offense, but Git's liberality is not easy to swallow. The first chapter of any Git book tells you to blank out all the conventional ideals from your mind and start anew.

Subversion does it one way, and nothing else

SVN is a version control system. It has one way to do its job and everybody does it the same way. Period. This makes it easy to transition to/from SVN from/to other centralized VCS. Git is NOT even a pure VCS -- it's a file-system, has many topologies for how to set up repositories in different situations -- and there isn't any standard. That makes it harder to choose one.

Other advantages are:

<pre><code>SVN supports empty directories
SVN has better Windows support
SVN can check out/clone a sub-tree
SVN supports exclusive access control svn lock which is useful for hard-to-merge files
SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.
</code></pre>

Found this and agree with it. Again the newbees are pretty agro when you touch git. I cannot trust git or github until a few more security changes like going one step beyond the hackable ssh keys.

I am currently deep into <code>Git</code> before ever mastering <code>SVN</code>. Its my first serious source control management system learning experience. 

I wonder about the opportunity-cost of not learning (or even de-learning what little I learned about) <code>SVN</code>. Is there something that I need to watch out for? 

Are there things that are just not doable or prohibitively hard in <code>Git</code> as compared to <code>SVN</code>?

What can SVN do that Git can not?

版本控制系统

分布式存储

文件系统

服务器

Windows

在掌握SVN之前，我目前已经深入了解Git了。这是我第一次认真学习源代码控制管理系统的经验。我想知道不学习(甚至取消学习我所了解的很少的东西) SVN的机会成本。有什么我需要注意的吗？与SVN相比，在Git中有没有什么事情是不可行的，或者是非常困难的

问SVN可以做什么是Git做不到的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN可以做什么是Git做不到的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SVN可以做什么是Git做不到的？
EN