共享开发服务器上的 Subversion
我正在考虑在工作中实施源代码控制。理想情况下，我想使用 Subversion，因为它似乎是目前的首选工具。然而，我似乎遇到了困难，因为对于我们所有的开发人员来说，在本地环境中工作是不切实际的。我们使用 Coldfusion 进行 Web 开发并使用共享开发服务器。对文件所做的更改可以在浏览器中快速刷新。
我们公司维护着 100 多个站点，我们的开发服务器在生产中镜像所有这些站点。我们经常必须对这 100 个中的 1 个进行快速调整、测试并快速上传到生产环境。如果我们必须在本地下载给定的站点，并将其设置在本地网络服务器中，这些小的更改将成为更耗时的任务。此外，文案撰写者和技术水平较低的人员通常会想要进入 html 页面并更改副本。这在我们当前的共享服务器设置中很简单。
很久以前，我们使用了一个名为 NGSource 的源代码控制，当您将项目签入存储库时，它会将文件权限更改为只读。我们会将文件检出到共享开发服务器，它将更改读写权限。我们都会检查存储库，以确保有人没有处理我们认为需要处理的文件。这很有效，并且可以向撰稿人解释。问题是 NGsource 客户端速度很慢，据我所知，他们可能会倒闭。
那么有没有办法在 Subversion 中实现签入和签出时文件权限的更改呢？如果没有，有更好的开源解决方案吗？在共享环境中开发并跳过本地开发有那么糟糕吗？
I'm thinking about implementing source control at my work. Ideally, I wanted to use Subversion since it seems to be the tool of choice at the moment. However, I seem to have hit a brick wall since it just isn't practical for all our developers to work in local environments. We do web development with Coldfusion and use a shared development server. Changes made to files can quickly be refreshed in the browser.
Our company maintains over 100 sites, and our development server mirrors all these sites on production. We often have to make quick tweaks to 1 of these 100, test it and quickly upload it to production. If we had to download a given site locally, set it up in our local webserver, these small changes would become more time consuming tasks. Also, often are copywriters and less technical folk will want to go into an html page and change copy. This is straightforward in our current shared server setup.
A long time ago we used a source control called NGSource, when you checked a project into the repository, it changed the file permissions to read only. We'd check the file out to the shared dev server, and it would change the permission to read and write. We'd all check the repository to make sure someone wasn't working on a file we thought to work on. This worked well and was explainable to copywriters. The problem was that NGsource client was slow and they might be out of business as far as I know.
So is there a way to implement this changing of file permissions on check in and check out with Subversion? If not, is there a better open source solution? Is it so bad to develop in a shared environment and skip developing locally?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以使用“svn lock”[1] 确保其他人无法编辑您当前正在处理的文件。
[1] http://svnbook.red- bean.com/en/1.2/svn.ref.svn.c.lock.html
You can use ‘svn lock‘[1] to ensure that no-one else is able to edit the file you're currently working on.
[1] http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html
您能解释一下为什么文件需要“只读”模式吗？
正如您所描述的，您可以在生产站点上维护一个工作副本。因此，开发人员或撰稿人只需连接到该站点，对其进行编辑并直接从生产站点提交更改即可。
Can you explain why do you need "read only" mode for the files?
as you describe it, you can maintain a working copy on the production site. So developers or copywriters, just connect to the site, edit it and commit their changes directly from production site.
我是一家开发公司的版本控制经理，该公司制作和维护 Web 应用程序和网站，尽管数量没有您那么多。我了解让 100 多个网站在 n 开发者/版权人的本地机器上正常工作（如果有的话）的复杂性，并相信不在每个网站上进行本地检查是一个合理的理由。
关于我们的流程
在我们的流程中，本地所做的任何更改都会首先进入暂存环境，并根据客户数据的合理表示进行审查，然后当认为良好时，最终会传输到生产环境。我们不在生产中安装版本化代码库，因为：
相反，我们使用 RepliWEb 等工具将代码库从暂存复制到生产。
关于您可能的流程
如果您有一个临时环境，其中所有 100 多个站点均已配置、正在运行并处于源代码控制之下，那么它会起作用吗？这是所有开发人员和版权所有者用来进行修改的环境，然后他们会提交。当修改被认为是好的时，像 RepliWeb 这样的工具可以将 Staging 中的版本（没有 .svn 目录）传输到 Production。如果文件系统开销和安全风险对您的公司来说可以忽略不计，那么只需在生产中对站点进行彻底检查（确保删除任何以前的工件）即可取代 RepliWeb。
我希望这有帮助。
谢谢你，
扎卡里
I am version control manager for a development company that makes and maintains web applications and web sites, though not nearly as many as yours. I understand the complexity in getting 100+ sites to work correctly (if at all) on n developer's/copyrighter's local boxes and believe it is a legitimate reason to not check out locally to each.
About Our Process
In our process, any change that is made locally first goes to a staging environment where it is vetted against a reasonable representation of the customer's data, then when it is deemed good it finally is transfered to a production environment. We do not install a versioned codebase in Production, because:
Instead we use a tool like RepliWEb to copy the codebase from Staging to Production.
About Your Possible Process
Would it work if you had one staging environment with all 100+ sites configured, running, and under source control? This is the environment all developers and copyrighters would use to make modifications, and then they would commit. When the modifications were deemed good, a tool like RepliWeb could transfer the version in Staging (sans the .svn directories) to Production. If the file system overhead and security risks are negligible for your company, than RepliWeb would be replaced by simply doing a clean checkout of the site in Production (making sure to remove any previous artifacts).
I hope this helps.
Thank you,
Zachary
我可以想象您的痛苦，但您没有告诉我们您当前的程序出了什么问题；）。毕竟，这是“如果它没有损坏，就不要修复”。只是因为每个人都使用 SVN/GIT 等，所以不能保证它适合你。
我们这里有类似的要求，但幸运的是仍然设法拥有一些人在提交之前使用的本地结账和本地网络服务器。这是推荐的方式。
通过 samba 或 nfs 挂载的其他人有一个共享的开发环境。但每个人仍然拥有自己的工作空间。
经常在前端工作并检查不重要的更改的人员使用 Web 界面在数据中心或目标（客户端）系统的主登台系统上调用 svn 更新。当事情发生时，这是他们的判断力和错误。当然，这些步骤也可以使用 svn hooks 完全自动化。
到目前为止我们的结果是可以接受的。
如果您认为个人工作空间的开销对于您的业务案例来说太高，那么据我所知，没有任何源代码控制可以帮助您。你仍然可以在 svn 中锁定文件，这样人们在解锁之前无法签入更改，但这已经是 1990 年的事了……
毕竟源代码控制的目标是什么？我能想到的一些：
当您没有个人工作空间和“用户”签入而不是匿名“团队”破坏文件的概念时，大多数当然，源代码管理功能对您不起作用。
也许您的 Coldfusion 服务器上可以有子文件夹？通过从源代码管理服务器自动更新所有内容来减少个人工作区管理开销（通常我不会推荐）？
如果可能的话，您需要首先摆脱“我们在服务器上编辑”的习惯，然后再考虑源代码控制。反过来会很复杂；）
C
I can imagine your pain but you did not tell us what's wrong with your current procedure ;). It is "dont fix if it aint broken" after all. And only because everyone uses SVN/GIT etc. there is no garuantee that its for you.
We have similar requirements here but luckily still manage to have local checkouts and local webservers that some people use before committing. It is the recommended way.
There is a shared development environment for others that who mount via samba or nfs. But still everyone has their OWN workspace parked on it.
People that work on the frontend alot and check in uncritical changes use a webinterface to invoke svn updates on the main staging system in the datacentre or on the target (clients) system. Its their discretion and their fault when things break. The steps could be completely automated using svn hooks too of course.
Our results are acceptable so far.
If you think the overhead for personal workspaces is too high for your business case then no source-control that I know can help you. You can still lock files in svn so people can not check in changes until it is unlocked but this is so very 1990 ...
After all what are the goals of source control? Some I can think of:
When you have no concept of a personal workspace and a "user" checking in instead of the anonymous "team" mangling the files, most Source Control features will not work for you, naturally.
Maybe you can have subfolders on your coldfusion server? Decrease personal workspace management overhead by updating all of them automaticly from the Source Control server (usualy not something I would recommend)?
If possible you need to get out of the "we edit on the server" habit first and then think about source controll. The other way round will be complicated ;)
C
在我们公司，我们的情况非常相似——项目比开发商多。因此，所有项目都在开发服务器上，开发人员可以轻松地处理它们。通常在给定时间只有一名开发人员从事一个项目。但开发人员来来去去、休假、生病等等，所以我们需要快速切换项目。
但理想情况下，通过版本控制，可以摆脱对更改某些内容的恐惧，以及版本控制带来的所有其他好处。
svn、csv、p4 等集中式版本控制不适合此类解决方案。只能以某种方式使用分布式版本控制。
我们即将测试一些分布式版本控制，例如 Mercurial 或 GIT，它们似乎是唯一适合在所描述的环境中工作的版本控制器，即使它们可能不是为这种情况开发的。
但由于开发人员没有个人空间，我们将无法使用版本控制的所有方面。开发人员需要将他们的名字写入签入记录中。但至少有总比没有好。
我做了一些研究，以下是我发现的一些有趣的链接：
如何在远程开发服务器上使用版本控制？
版本控制有我难住了
https://www.mercurial-scm.org/wiki/TortoiseHg
http://git-scm.com/
In our company we've very similar situation - more projects than developers. So all the projects are on dev server, where developers can easily work on them. Usually only one developer works on one project at given time. But developers are coming and leaving, vacations, sicks, etc, so we need to switch the projects quickly.
But ideally with version control, to get rid of the fear of changing something, and all the othe good things which versioning brings.
The centralised version controls like svn, csv, p4 and more aren't suitable for such solution. Only distributed version control can be somehow used.
We're just about to test some distributed version control like Mercurial or GIT, which seems as the only version controllers, which are suitable to work in described environment, even they're probably not developed for such case.
But as there is no personal space for developer, we'll not be able to use all the aspects of the version control. Developers will need to put their name int checkin note. But at least something than nothing.
I've made some research, here are some interesting links I found:
How to use version control on a remote development server?
Version control has me stumped
https://www.mercurial-scm.org/wiki/TortoiseHg
http://git-scm.com/