我应该如何使用 Subversion 处理 pdf、word 文档和 Excel 电子表格？
我在目前的职位上使用 Subversion 已经一年多了。这是我在这里做的第一件事之一。我立即实施了它，因为没有任何类型的版本控制。
去年，我将整个网站导入 Subversion。我完全按照原样导入了它，垃圾等等。 PDF、图像、frontpage _vti_cnf 文件夹，一切。
我觉得这将使我能够安全地对网站进行任何更改，并为我提供一个能够跟踪更改进度等的起点......
现在一年后，我对我的一些方式感到有点不安设置这个。主要是我想找出一种更好的方法来处理二进制文档。 我不想将二进制文件放入我的存储库中。期间。
请注意
图像不同。 TortoiseSVN可以比较图像，而且它们是不同的动物。它们会影响网站的外观或感觉。对于 pdf、word 文档、excel、access db、zip 文件、电影等，情况并非如此……
以下是我们如何管理网站更新到生产的流程。网站更新每周进行一次，网站更新后，我会为该周创建一个带标签的副本。
- 我收到一个请求，要求用新版本更新 pdf，并更改超链接文本以包含一些新的描述。
- 我将工作副本更新到最新版本，对网站进行 html 代码更改。
- 我将新版本的 pdf 文件复制到我的工作副本中，用新的 pdf 替换旧的 pdf。
- 此时，我的工作副本显示 2 个待处理的更改，但实际上只有一个更改是代码更改。 PDF 只是内容。
- 我将这两项更改都
提交到我的存储库中。 - 现在，当需要转向生产时，我将我的主干与上周的标签文件夹进行比较。
- TortoiseSVN 能够仅生成需要在生产中更新的文件的导出，并带有完整路径。我这样做是为了始终可以将根目录复制到生产站点。
- 我将文件和空文件夹结构导出到另一个团队将其拾取并将其复制到生产环境的位置。
因此，使用此方法，代码更改和 PDF 都会转移到生产环境中。但是，我不喜欢它。
我的另一个问题是，如果不使用上述过程，我也不相信自己的记忆会在每次转移到生产过程中记住在转移到生产之前手动将 pdf 复制到我的变更集中。
I have been using Subversion at my current position for just over one year. It was one of the first things I did here. I immediately implemented it as there was no versioning control of any kind in place.
Last year, I imported our entire site into Subversion. I imported it exactly as it was, garbage and all. PDFs, images, frontpage _vti_cnf folders, EVERYTHING.
I felt this would allow me to safely make any changes to the site, and give me a starting point to be able to track changes progress, etc...
Now a year later, I'm a little upset with some of the way I set this up. Mainly I want to figure out a better way to handle binary documents. I do not want to put binary files in my repository. period.
Please note
Images, are different. TortoiseSVN can compare images, and they are a different animal. They would affect the look or feel of the site. This is not the case for pdfs, word docs, excel, access dbs, zip files, movies, etc...
Here is the process for how we manage website updates to production. Updates to the site are done weekly, after the site is updated I create a tagged copy for that week.
- I get a request to update a pdf with a new version, and change the hyperlink text to have some new description
- I update my working copy to the latest version, I make the html code change to the site.
- I copy the new version of the pdf file into my working copy, replacing the old pdf with the new.
- At this point, my working copy shows 2 pending changes, though only one is actually a code change. PDFs are just content.
- I
commitboth changes to my repo. - Now when it's time to move to production, I compare my trunk with last week's tag folder.
- TortoiseSVN is able to generate an export of only the files that need to be updated on production, with full paths. I do this so I can alway have the root copied over to the production site.
- I export the files and empty folder structures to a location where another team picks it up and copies it over to production.
So using this method, both the code change and the PDF get moved to production. But, I don't like it.
My other problem, with not using the above process is that I also don't trust my memory to remember during every move to production to manually copy the pdfs into my changeset prior to moving to production.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否考虑过使用 Nexus 或 Artifactory 之类的东西来存储这些文档？是的，这些程序用于管理 Maven 存储库，但您没有理由必须使用 Maven 才能使用它们。
优点：
另一种可能性是使用 Dropbox 之类的东西。该界面非常简单，即使是经理也可以使用它。而且，作为奖励，Dropbox 还为您创建所有文档的版本。您和他们之间创建一个共享的 Dropbox，他们只需将所需的文档放在该目录中即可。
Subversion 的问题不在于二进制文件，而在于你陷入困境，因为 Subversion 对于没有受过技术培训的人来说实在太复杂了。 （因此，您获取文件并将它们放入存储库中）。像 Artifactory 或 Nexus 这样的发布存储库可以让您摆脱困境。
Have you considered using something like Nexus or Artifactory for storing these documents? Yes, these programs are for managing Maven repositories, but there's no reason you have to be using Maven to use them.
The advantage:
Another possibility is to use something like Dropbox. The interface is so simple that even a manager can use it. And, as a bonus, Dropbox also versions all of the documents for you. You create a shared Dropbox between them and you, and they simply put the documents they want in that directory.
The problem with Subversion isn't the binary files, but the fact that you are stuck because Subversion is really too complex for people with no technical training to handle. (Thus, you get the files and you put them in the repository). A release repository like Artifactory or Nexus can get you out of the loop.
我将在 svn 中创建第二个存储库。称之为 htdocs，它可以根据需要变得臃肿。
我会将其作为 svn:external 链接到我的实际存储库。
不用大惊小怪。没有混乱。
I am going to create a second repo in svn. Call it htdocs, it can get as bloated as it needs.
I'll link it as svn:external to my actual repository.
No fuss. No muss.
听起来该网站的某些内容是由该网站的网络编码团队以外的其他人更新的。我们将这些疯狂的内容更新者称为“营销”，只是为了好玩。现在，流程是他们将文件提供给您，您签入它们，然后将它们推送给您的制作团队。
将文件置于版本控制中不是问题；问题在于。问题是你是中间人。您永远不会拒绝 PDF 更新，那么为什么要把自己置于这样的境地呢？不要成为中间人；努力实现去中介化。要么：
A.授予营销部门直接在 Subversion 中更新文件的权限，或者
B. 与制作团队合作，为营销部门提供一个单独的位置，让他们可以直接交付文件。
请注意，营销部门很可能仍然受益于将 PDF 文件（或者更好的是，他们生成 PDF 的源文件）置于版本控制中；您显然知道其中的好处，所以也许您可以说服他们（向他们展示如何进行差异！）。但如果您出于某种原因确实反对的话，它不一定是您的存储库。
Sounds like there is content for the website that get updated by someone other than the site's web coding team. Let's call these crazy content updaters "Marketing", just for fun. Right now, the process is that they give the files to you, you check them in, then you push them to your production team.
Having the files in version control is not the problem; the problem is that you are the middleman. You're never going to refuse a PDF update, so why put yourself in that position? Don't be the middleman; work towards disintermediation. Either:
A. Give Marketing permission to update the files directly in Subversion themselves, or
B. work with the production team to give Marketing a separate place where they can deliver the files directly.
Note that Marketing might well still benefit from having their PDF files (or better yet, the source files that they generate the PDFs from) in version control; you obviously know the benefits so maybe you can convince them (show them how to diff!). But it doesn't have to be your repository, if you are really opposed to that for some reason.