分布式团队的源代码管理文件夹组织
我们的团队分布在两个地理位置。 我们共享并使用类似的脚本来自动化执行不同的测试。 我们最近决定使用源代码控制来管理正在使用的不同脚本。到目前为止，我们生成的任何脚本都共享到其他位置，他们会根据自己的需求进行较小的本地修改并使用它。 也就是说，我们将使用相同版本的脚本，并针对我们的本地设置进行一些小的修改。 如何最好地在源代码管理中组织它。我们计划使用 Subversion 并在两个位置复制存储库。
我想到的一种解决方案是为每个位置创建两个文件夹。因此，他们上传的任何脚本，我们都会复制到我们自己的目录并进行本地修改。还有其他建议吗？
谢谢...
Our team is distributed across two geographic locations.
We share and use similar scripts for the automation of different tests we perform.
We have recently decided to use source control to manage the different scripts that are being used. So far whatever scripts we generated was shared across to the other location, they would make minor local modification appropriate to their needs and use it.
That is we would be using the same version of the script with few minor modification specific to our local setup.
How best to organise this in a source control. We are planning to use Subversion with the repository duplicated across the two location.
One solution I was thinking was making two folders one for each location. Thus any scripts they upload, we will copy to our own directory and make local modification. Any other suggestions?
Thanks...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该有一个存储库来保存脚本。每个修改（由本地或远程团队进行）都会获得版本控制。更改可以回滚。您将拥有修订历史记录等。多个文件夹违背了版本控制系统的目的。当然，您可以使用子文件夹来逻辑分隔脚本。
如果网络性能是一个问题，您可能需要查看分布式版本控制系统，例如 git 或 mercurial。
You should have a single repository to hold the scripts. Each modification (by local or remote team) would get versioned. Changes can be rolled back. You will have revision history and so on. Multiple folders defeat the purpose of having a version control system. Of course, you can have subfolders for logical separation of scripts.
If network performance is an issue, you may want to look at distributed version control systems like git or mercurial.
这就是每个站点一个分支的样子。
每个站点对其分支都拥有完整的所有权，并且您可以导入/合并站点分支中一个站点所做的更改。
除此之外，使用集中式 VCS 时，最好远程访问 SVN 存储库（针对其中一个站点），以避免两个手动克隆之间出现任何历史记录差异。
由于 Raghuram，Git 或 Mercurial 更适合该场景。
That is what a branch per site looks like.
Each site has complete ownership on their branch, and you import/merge changes made by one site in your site branch.
Except that, with a Centralized VCS, it is better to access the SVN repo remotely (for one of the sites), in order to avoid any history discrepancies between two manual clones.
As Raghuram, Git or Mercurial are a better fit for that scenario.
我没有使用过 SVN，但广泛使用过其他许多 vcs 系统，并且...
我同意优先级应该是“您应该尝试参数化或移出特定于位置的条目”，但首先要获取所有脚本在公共存储库中的源代码控制下。事实上，您的流程文档也应该受到源代码控制。
我之前加入了一个 CM 团队，该团队未能在自己的脚本中使用 CM 工具。果然，我们经常会发现一个问题，即并非所有成员都会使用相同的脚本来执行相同的任务。将脚本和文档放入存储库中可以方便、轻松地让每个人都使用相同的工具并保持最新状态。
要通用化您的脚本等，请为具有 common/site A/site B/ 结构的脚本创建文件夹树。将各个站点的所有脚本放置在该目录下。然后，相同的脚本将迁移到“通用”并从其他脚本中删除，并签入所有内容。最终目标是将所有脚本移动到通用代码库。用于实现这一目标的通用去本地化框架或模板将加快这一过程。你会发现，一旦完成了前几个，剩下的就会很快完成。拥有单独的目录可以让您轻松区分本地化并消除它们。
您不希望用户必须不断合并（呃！）并覆盖其语言环境的本地化数据，或者更糟糕的是在签出后手动执行此操作。最理想的是，在更新任何脚本时，应牢记去本地化的目标，因此除非有情有可原的情况，否则仅接受通用更新；还强制更新程序在执行一侧时更新 A 和 B 分支。您会发现人们厌倦了做两次事情（并且为了别人的利益），并且很容易开始对脚本进行去本地化。
I haven't worked with SVN but have worked extensively with other many vcs systems and ...
I agree a priority should be "You should try to parametrize or move out location-specific entries", BUT the first priority to get all your scripts under source control in a common repository. In fact, your process documentation should also be under source control.
I previously joined a CM team which failed to use a CM tools for their own scripts. Sure enough, every so often we would discover a problem which not all members would be using the same scripts for the same tasks. Putting the scripts and documents in the repository makes it convenient and easy to have everyone using the same tools and stay up to date.
To universalize your scripts, etc., create a folder tree for the scripts with common/site A/site B/ structure. Place all scripts for the respective sites under the directory. Identical scripts are then migrated to "common" and deleted from the others and check everything in. The ultimate objective is to move all scripts to a common code base. A common de-localization framework or template for achieving this will speed up the process. You'll find once the first few are done, the rest will follow very quickly. Having the separate directories allows you to easily diff the localizations and eliminate them.
You do not want to be in a situation where users must constantly merge (ugh!) and overwrite localization data for their locale or worse do it manually after check-out. Optimally, when updating any scripts, they should be done with the de-localizing objective in mind, so only accept updates to common unless there are extenuating circumstances; also force the updater to update both A and B branches when doing one side. You'll find people get tired of doing things twice (and for someone else's benefit) and will readily start de-localizing scripts.