我签入的 svn 文件夹在服务器上的什么位置？

发布于 2024-08-26 23:38:42 字数 154 浏览 8 评论 0原文

试图理解一些东西。我在我的服务器上创建了 ad:\svn\repository 。我提交了文件夹，但是当我返回 d:\svn\repository 时，我看不到它们。它们都在数据库中吗？我的所有存储库都会进入该主文件夹并且 svn 会跟踪它们吗？如果我有两个项目怎么办？

谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

静赏你的温柔 2024-09-02 23:38:42

Subversion 不会将逻辑文件夹存储在服务器上的相同结构中，它会跟踪“数据库”中增量文件中的所有内容。该数据库特定于 Subversion。提交给该存储库的所有内容都位于该文件中。您不会在服务器上找到您的逻辑结构，它只是不那样工作。

来自 FSFS

2004 年中期，第二种类型
存储库存储系统问世
存在：不使用
根本没有数据库。 FSFS 存储库
将修订树存储在单个
文件，等等所有存储库的
修订可以在一个单一的
充满编号文件的子目录。
交易是单独创建的
子目录。完成后，会出现一个
创建单个交易文件并
移动到修订目录，因此
保证提交是原子的。
并且因为修订文件是
永久且不变的，
存储库也可以备份
“热”，就像 Berkeley DB 一样
存储库。
修订文件格式代表
修订版的目录结构、文件
内容以及相对于文件的增量
其他修订树。不像一个
Berkeley DB数据库，这个存储
格式可以跨不同格式移植
操作系统且不敏感
到CPU架构。因为有
没有日志或共享内存文件
正在使用时，存储库可以是
通过网络安全访问
文件系统并以只读方式检查
环境。缺乏数据库
开销也意味着总体
存储库大小有点小。
FSFS有不同的性能
特点也。当提交一个
包含大量文件的目录，
FSFS 使用 O(N) 算法来追加
条目，而 Berkeley DB 使用
整体重写O(N^2)算法
目录。另一方面，FSFS
将文件的最新版本写入为
与早期版本的增量，
这意味着检查
最新的树比
获取存储在 a 中的全文
Berkeley DB HEAD 修订版。 FSFS还
完成任务时有较长的延迟
提交，在极端情况下可能
导致客户端等待超时
寻求回应。
最重要的区别，
然而，FSFS 是否无法
当出现问题时“楔入”。如果
使用 Berkeley DB 数据库的进程
遇到权限问题或
突然崩溃，数据库就剩了
管理员之前无法使用
恢复它。如果同样的场景
发生在使用 FSFS 的进程上
存储库，存储库不是
完全受到影响。最坏的情况是，有些
交易数据被留下。

Subversion doesn't store the logical folders in the same structure on the server, it tracks everything in an file of the deltas in a "database". This database is specific to Subversion. Everything committed to that repository goes in that file. You won't find your logical structure on the server, it just doesn't work that way.

From FSFS

In mid-2004, a second type of
repository storage system came into
being: one which doesn't use a
database at all. An FSFS repository
stores a revision tree in a single
file, and so all of a repository's
revisions can be found in a single
subdirectory full of numbered files.
Transactions are created in separate
subdirectories. When complete, a
single transaction file is created and
moved to the revisions directory, thus
guaranteeing that commits are atomic.
And because a revision file is
permanent and unchanging, the
repository also can be backed up while
“hot”, just like a Berkeley DB
repository.
The revision-file format represents a
revision's directory structure, file
contents, and deltas against files in
other revision trees. Unlike a
Berkeley DB database, this storage
format is portable across different
operating systems and isn't sensitive
to CPU architecture. Because there's
no journaling or shared-memory files
being used, the repository can be
safely accessed over a network
filesystem and examined in a read-only
environment. The lack of database
overhead also means that the overall
repository size is a bit smaller.
FSFS has different performance
characteristics too. When committing a
directory with a huge number of files,
FSFS uses an O(N) algorithm to append
entries, while Berkeley DB uses an
O(N^2) algorithm to rewrite the whole
directory. On the other hand, FSFS
writes the latest version of a file as
a delta against an earlier version,
which means that checking out the
latest tree is a bit slower than
fetching the fulltexts stored in a
Berkeley DB HEAD revision. FSFS also
has a longer delay when finalizing a
commit, which could in extreme cases
cause clients to time-out when waiting
for a response.
The most important distinction,
however, is FSFS's inability to be
“wedged” when something goes wrong. If
a process using a Berkeley DB database
runs into a permissions problem or
suddenly crashes, the database is left
unusable until an administrator
recovers it. If the same scenarios
happen to a process using an FSFS
repository, the repository isn't
affected at all. At worst, some
transaction data is left behind.