0

对不起这个蹩脚的标题。

我有一个产品图片库（大约 55,000 张，每年增长大约 1000 张），每天都在变化（每天最多添加、修改和/或删除 100 张图片）。

我需要三个人才能进行上述更改（以便他们可以读/写目录）。他们都将使用windows vista PC。

我还需要能够托管图像，以便供应商可以每天了解最新的变化。大约有100个供应商。

我现在正在考虑实施的系统将涉及使用 Subversion。

在后备箱中，我将拥有图像（分解为多个目录和子目录）。这三个人将在他们的本地机器上拥有工作副本，这样他们就可以进行必要的更改，而我们不必担心冲突。另外，每个人都可以轻松地了解存储库的最新信息（更不用说版本控制和备份的明显好处）。

我会有一个公共的、只读的、指向主干的 url，以便供应商只能结帐更改。这很好，因为我可以向他们提供有关如何签出存储库并设置 cron 以每天更新存储库的说明，因此始终保持最新。

所有供应商都有足够的技术专长在他们的服务器上设置一个 cron 作业和 svn repo。

这一切都让人感觉有点 hacky（我考虑任何时候尝试使用不是为 hack 设计的东西）。

我的问题是，有人看到这个解决方案有什么缺点吗？对于我正在尝试做的事情，还有其他解决方案可能更好吗？

我考虑使用 Dropbox 在所有这些服务器之间进行同步，但我不希望供应商能够进行任何更改。

我的目标是：

  1. 让我的设计师更容易维护。
  2. 供应商的一次性设置，他们将始终与我们的图像保持同步。
  3. 有一个像样的备份/恢复和回滚系统，以防发生危机。
4

2 回答 2

1

您的解决方案似乎和任何解决方案一样好。您所要做的就是一个小的客户端脚本，它将图像从您的服务器检索到客户端。

我唯一不喜欢的是使用颠覆来保存图像。它可以工作，但每个更改都不会存储为增量，而是作为一个全新的文件。这可能不是您关心的问题。

此外，使用rsync将允许您轻松传输唯一更改的文件，节省带宽。此外，您可能需要考虑使用 SSH 进行传输。

还有一件事，您可能希望将同步脚本安排到客户端一天中的不同时间，以平衡负载，并使其看起来更快。

于 2010-02-25T19:12:52.063 回答
1

您的解决方案总体上是有意义的，尽管我对包含这么多图像的存储库大小感到担忧。在某种程度上，专门用于图像的内容管理系统可能更有意义（尽管我不知道有哪一个可以推荐）。

我建议更改的一件事是，除非供应商确实需要能够编辑/提交文件，否则您可能需要考虑设置一个计划作业以导出到文件系统（然后通过 FTP/HTTP/etc 提供）。让供应商执行结帐意味着他们将承担工作副本的所有开销。（然后你最终会处理“所有这些 .svn 目录是什么以及这些其他文件是什么？”的问题）

于 2010-03-02T15:12:01.533 回答