SVN导出到工作目录
我们必须解决以下问题。如果我们将您的更改导出到我们的开发服务器，则导出不会删除服务器上的任何文件。出于充分的理由，我们不想手动执行此操作。因此，我考虑将服务器上的目录作为工作副本，但任何开发人员都必须将其更改提交到存储库以测试其更改。我认为这是非常不切实际的，而且会做出很多没有必要的修改。
因此，我们需要两全其美 - 如果我们将更改导出到工作目录进行测试，然后在开发完成后更新工作目录，那么 SVN 是否有能力处理它。
问候， 马塞尔
we have to following problem. If we export your changes to our development sever the export will not delete any files on the server. And for good reasons we do not want to do this manually. So I thought about to make the directory on the server as working copy to but so any developer has to submit his changes to the repository just for testing his changes. I think this is very unpractical and will make many revision who are not necessary.
So we need the best from both world - so is SVN have the ability to handle it if we export our changes to the working directory for testing and afterward to update of the working directory after our development is finished.
Regards,
Marcel
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的部署脚本应该简单地删除以前导出的文件夹并创建一个新的导出。对于开发服务器来说，几秒钟的停机肯定不是问题吗？
如果停机是一个问题（例如，您的项目非常大，需要很长时间才能完成导出），那么您仍然可以通过使用硬链接或符号链接立即部署下一个修订版本。
例如，您可以将项目托管在
/var/www/myproject.latest中，这实际上是到/var/www/myproject.r123的硬链接。导出新版本124后，您可以使用以下命令立即更新硬链接：（我假设您的项目托管在 Linux 服务器上，但您也可以使用 [NTFS junction][1] Windows 上的点。）
svn export具有相同的限制，因此我看不出两种方法在这方面有何不同。如果所有开发人员都需要共享同一个测试服务器，那么无论如何这都是一件好事：如果开发人员 A 破坏了测试服务器，那么开发人员 B 希望能够查看 SVN 日志以了解发生了什么！Your deployment script should simply delete the previously exported folder and create a fresh export. Surely a few seconds of downtime is not a problem for a development server?
If the downtime is a problem (e.g. your project is very large and it takes a long time for the export to complete) then you can still deploy the next revision instantly by making use of hard links or symbolic links.
For example, you could host your project in
/var/www/myproject.latestwhich is actually a hard link to/var/www/myproject.r123. After a new revision124is exported, you instantly update the hardlink with this command:(I have assumed that your project is hosted on a linux server, but you can also use [NTFS junction][1] points on Windows.)
svn exporthas the same restriction, so I don't see how both approaches differ in this regard. If all developers need to share the same test server, then this is a good thing in any case: if developer A breaks the test server, then developer B wants to be able to look at the SVN log to see what happened!