标签: repository-design

我在SVN存储库中有几个具有不同发布周期的项目.通过使用SVN中的经典标记结构创建版本.当在版本中存在要修复的错误时,会从标记创建分支,该错误会被修复,然后从那里合并到主干中.

现在,出于多种原因,我想通过中央推送站点从SVN切换到mercurial.

问题:在mercurial中组合多个项目的最佳方式是哪种方法在它们之间共享很少的代码？我应该创建多个推送网站,每个项目一个？

请在答案中包含有关如何使用您首选的存储库设计版本重新创建我的release-tag,bugfix分支的说明.

编辑:我想安装尽可能少的扩展.

EDIT2:

鉴于此SVN布局:

.
|-- project-a
|   |-- branches
|   |   |-- 1.x
|   |   `-- feature-1
|   |-- tags
|   `-- trunk
`-- project-b
    |-- branches
    |-- tags
    |   |-- 1.0
    |   `-- 1.1
    `-- trunk

(谢谢@bendin!:))

使用多个hg推送存储库更好吗？

project_a-trunk
project_a-1.x
project_a-feature-1
project_b-trunk

对于分支机构.标签被折叠到适当的分支中.

或者你宁愿在这个例子中使用两个推送存储库

project_a
project_b

使用命名分支,因此在一个回购中有多个头.

我看到多头回购的优点是我不必去寻找多个回购中的标签.我看到的缺点是,hg书似乎不鼓励多头回购.你会怎么做？

大多数subversion工具使用/ trunk,/ branches和/ tags创建默认存储库布局.该文档还建议不要为每个项目使用单独的存储库,以便可以更轻松地共享代码.

根据该建议,我得到了一个具有以下布局的存储库:

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

等等,你明白了.随着时间的推移,我发现这个结构有点笨拙,我发现对建议有另一种解释,例如:

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags       

那么,人们使用哪种布局,为什么？或者 - 还有另一种方法可以做我完全错过的事情吗？

我正在从集中式SCM系统切换到GIT.好的,我承认哪一个,它是Visual SourceSafe.因此,除了克服Git命令和工作流的学习曲线之外,我目前面临的最大问题是如何将我们当前的存储库迁移到Git,关于单个或某些类型的多个存储库.

我已经通过各种方式看到了这个问题,但通常只是基本..."我有应用程序想要共享一些较低级别的库"并且预制响应总是"使用单独的存储库"和/或"使用Git子模块"没有太多解释何时/为什么应该使用这种模式(它克服了什么,它消除了什么？)从我对Git的有限知识/阅读到目前为止,似乎子模块可能有自己的恶魔来战斗,特别是对于刚接触Git的人.

然而,我还没有看到有人公然问的是,"如果你有传统的n层开发(UI,业务,数据,然后是共享工具),每个层都是自己的项目,你应该使用一个或多个库？" 我不清楚,因为几乎总是,当添加一个新的"功能"时,代码更改会波及每一层.

为了使与Git相关的问题复杂化,我们在"框架"中复制了这些层,以便从开发人员的角度制定更易于管理的项目/组件.出于本讨论的目的,我们将这些项目/图层集合称为"Tahiti",它代表整个"产品".

我们设置的最后一个"层"是增加了对塔希提岛进行定制/扩展的客户网站/项目.在文件夹结构中表示这可能最像是:

/Clients
  /Client1
  /Client2

/UI Layer
  /CoreWebsite (views/models/etc)
  /WebsiteHelper (contains 'web' helpers appropriate for any website)
  /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites)

/BusinessLayer (logic projects for different 'frameworks')
  /Framework1.Business
  /Framework2.Business

/DataLayer
  /Framework1.Data
  /Framework2.Data

/Core (projects that are shared tools useable by any project/layer)
  /SharedLib1
  /SharedLib2

在解释了我们如何通过多个项目扩展传统的n层设计之后,我正在寻找任何关于你在类似情况下做出的决定的经验(甚至简单的用户界面,业务,数据分离就是你的全部因为你的决定,更容易/更难.在初步阅读中,子模块有多痛苦,我是否正确？比痛苦更有益吗？

我的直觉反应是塔希提岛的一个存储库(所有项目除了'客户项目'),然后是每个客户的一个存储库.我猜的整个大溪地来源必须是<10k文件.这是我的推理(我欢迎批评)

• 在我看来,在Git中你想要追踪'特征'与个人'项目/文件'的历史,即使我们的项目分离,一个'特征'将始终跨越多个项目.
• 核心站点中编码的"特征"几乎总是对核心网站和"框架"的所有项目(即CoreWebsite,Framework1.Business,Framework1.Data)产生最小影响.
• 一个功能可以轻松跨越多个框架(我说我们实现的功能的10%将跨越框架 - CoreWebsite,Framework1.Business,Framework1.Data,Framework2.Business,Framework2.Data)
• 以类似的方式,功能可能需要更改一个或多个SharedLib项目和/或"UI网站帮助程序"项目.
• 对客户端自定义代码的更改几乎总是只对其存储库是本地的,并且不需要跟踪对其他组件的更改以查看"整个功能更改集"是什么.
• 鉴于一个功能跨越项目以查看整个范围,如果每个项目都是自己的存储库,那么尝试分析存储库中的所有*代码更改将会很痛苦吗？

提前致谢.

所以我在应用程序中实现了存储库模式,并且在我对模式的理解中遇到了两个"问题":

1. 查询 - 我已经读过使用存储库时不应该使用IQueryable的响应.但是,显而易见的是,您希望每次调用方法时都不返回完整的对象列表.应该实施吗？如果我有一个名为List的IEnumerable方法,那么IQueryable的一般"最佳实践"是什么？应该/不应该有哪些参数？

2. 标量值 - 最好的方法(使用存储库模式)返回单个标量值而不必返回整个记录是什么？从性能的角度来看,在整行上只返回一个标量值会不会更有效率？

我正在寻找一种在(2)服务器之间自动同步Git存储库的方法,以便它们可以从第三点进行互换.

情况如下:我们对所有项目大量使用git,并且一些存储库的大小增长很快.目前我们有一个中央服务器,每个人都在推/拉这个/从这个.然而,这一切都通过互联网连接,因此不是最快的方式.

想法:将另一台服务器放在办公室,并将所有git存储库放在那里供办公室使用.该服务器需要与在线服务器同步.用户甚至不会通过某些dns调整知道他们使用哪一个,因此当连接到那里的网络时,在线服务器存储库的地址解析为办公室内的一个.

有没有人在那里做类似的事情？或者是否有更简单的方法来完成目标.

我有一些在我的主目录"点"的文件,我想跟踪与git的-例如.pryrc,.zshrc等我想有这些文件的远程存储库,以便一)有恢复一个简单的方法我配置设置应该因任何原因丢失我的机器; 和b)安全地跟踪在配置更改时我搞砸的事件对文件所做的任何更改.

我最初在主目录中设置了一个git存储库来跟踪它们,并将.gitignore文件配置为忽略除特定白名单文件名之外的每个文件.但是,我意识到我并不是因为在我的主目录中有一个git存储库而感到疯狂,而且在我的终端窗口中看到分支名称"master"也更加分散注意力.我在设置中使用ZSH来在提示符中显示git分支,结果看到我在git存储库中导航到我不希望拥有存储库的目录时,结果令人惊讶和困惑.

我尝试在主文件夹下创建一个配置目录,将其初始化为git存储库,并为所需文件生成符号链接.但是,在添加并提交远程分支仅显示链接的所有内容后,我注意到,而不是文件的实际内容.

实现这一目标的最佳方法是什么？

我首先获得了我的代码,SQL数据模型(使用EF Core 1.1),用于模拟我的模式/表.但是我也有域对象,它们是这些SQL数据模型的部分或完整映射版本,实质上它们具有与SQL数据模型相同的形状.

现在,我想知道当复杂对象在其被跟踪上下文的上下文之外被更改时,处理级联更新的最佳方法是什么.当您认为我的所有域操作都不在被跟踪的实体上进行时,它们就会发生在域对象上.

简而言之,这就是我想要实现的目标.

1)从数据库中读取实体.

2)将实体映射到域对象.

3)对域对象应用更新.

4)将域对象映射回实体.

5)对映射的实体应用数据库更新,这导致实体及其相关的相关实体被更新.

顺便说一下,实体和域对象具有可能遇到的典型的多对一关系.这样做的最佳方法是什么？

我应该在哪里建造我的回购？我的教程repos转到root,但我想我会对我的生产站点进行测试,我应该将它们构建起来~/sites/.

这看起来似乎微不足道,但我见过的Git的大多数介绍并没有真正指定一个特定的位置.

我有一个项目使用几个（目前〜6）依赖项（其他库）。它们中的大多数都使用 MIT/简化的 BSD 许可证，因此将它们复制到我的存储库应该不是问题。

将所有这些库放入我的存储库并推送它们（当新版本出现时，也更新它们）是否是一个好习惯？或者我的项目存储库应该只包含项目文件（代码、资产等）？

优点：

• 建筑变得更加简单，因为我需要的一切都在附近
• 添加的库意味着我使用这些版本测试了我的项目，因为其他版本（较旧/较新）可能会产生一些问题

缺点：

• 项目回购中的膨胀

• 必须手动更新依赖项

• 如果我想粘贴也构建的版本，我将不得不粘贴很多

• 文件，这会占用大量空间，所以可能只坚持源代码？

• 有些库可能没有那么好的许可证，直接使用它们（除了要求用户自己获取有效的库之外）并将它们放在我的存储库中可能会带来一些麻烦

• 拥有更多项目来保持依赖关系意味着我必须同时更新所有项目的它们（例如，如果我根据当前项目（它的库）创建一些其他项目，那么它们都将具有相同的依赖关系）

我正准备建立一个SVN存储库,并且想知道是否有人为repo结构提供了一个很好的例子.我目前在想:

开发
..应用
.... App1
......主干
......分支
......标签
..数据库
..第三方

虽然这种结构可能包含我们需要的一切,但我想让它更加颗粒化.有什么想法吗？