【问题标题】:fossil: add files to existing repo, do I need to open first?化石:将文件添加到现有仓库,我需要先打开吗?
【发布时间】:2014-03-29 21:29:33
【问题描述】:

我希望控制一个目录的版本,我们称之为“项目”,并将化石文件保存在另一个名为“fossils”的目录中。我已经成功创建了“project.fsl”存储库,添加了我的项目文件,提交并关闭了。我的问题是了解如何采取下一步行动。

这是我按照fossilbook 的建议所做的。

$ cd project
$ fossil new ../fossils/project.fsl
$ fossil open ../fossils/project.fsl
$ fossil add .
$ fossil ci -m "first commit"
$ fossil close project.fsl

现在我已经完成了我的项目,编辑了一些文件,删除了一些文件,创建了一些文件,重命名了一些文件。我想将项目的当前状态添加到存储库中。我该怎么做?

根据我在文档中阅读的内容,我的印象是我必须首先打开存储库,然后添加文件,然后提交。如果我不打开存储库,我会收到 Not within an open checkout. 消息。但如果我openfossil 想用旧文件覆盖我的目录。 (如果我从fossils 目录中打开,我会将项目的“解包”版本复制到化石目录中,这也不是我想要的)

$ cd project
$ fossil open ../fossils/project.fsl

这里化石想用旧版本覆盖我的项目。我对每一个建议都说不。我怀疑open 不是正确的方法,但如果不是,那是什么?

我想将我的更改添加到存储库,所以现在 project.fsl 是 open,我试试这个:

$ fossil add .
 ADDED  Slides/tmp.tex

$ fossil commit -m "no idea what I'm doing, this will not end well"
 would fork.  "update" first or use --allow-fork.

$ fossil close
 there are unsaved changes in the current checkout

此时我删除了所有名为 .fslckout .fossil 的隐藏文件并重试,结果同样令人失望。

坦率地说,我对fossil 的唯一兴趣是保留我的项目历史。我没有合著者,也不打算做fossil difffossil ui 或类似的事情,直到我希望这永远不会发生,当我需要深入研究我的项目的历史时。

编辑。我完全是新手。我不确定我是否理解checkoutmanifestleaf 等的含义,因此我很难从手册中得到任何东西,尽管我花了无数小时尝试。我不太了解fossil open上的这个页面:http://fossil-scm.org/fossil/help/open

【问题讨论】:

标签: version-control fossil


【解决方案1】:

fossil open 正确的做法。在您的情况下,fossil close 不是必需的。

此时,您应该使用fossil open ../fossils/project.fsl --keep 打开您的存储库,同时保留所有更改。

open 命令将当前目录标记为工作目录(在 Fossil 术语中,checkout)。我建议您在需要移动存储库或工作目录本身之前不要关闭它。就我个人而言,只有当我转移到另一台计算机时才会发生这种情况。

要让化石识别所有变化,只需fossil addremove;然后化石将添加所有新文件,并删除所有已删除文件,以便存储库再次与工作目录匹配。当然,您仍然必须在之后提交更改。

注意addremove不会自动识别文件重命名!如果您已重命名文件,则应在执行addremove 命令之前使用fossil rename 命令让Fossil 知道每个文件的这一点。当然,如果你不介意破坏特定文件的编辑历史,你可以跳过它,让化石认为一个文件被删除,另一个文件被添加。

【讨论】:

  • 谢谢。因此,如果我所做的只是想跟踪回购的历史,而不需要拉/推/共享或类似的东西,那么我不应该需要“关闭”,对吗?请你澄清一件事:我可以保持几个回购开放吗?谢谢!
  • 感谢重命名建议。我确实意识到fossil 不会“猜测”文件何时被重命名,我应该告诉fossil,但这对我来说工作量太大了,我宁愿让 repo 的大小增加而不是继续历尽艰辛,除了效率低下,应该没问题吧?
  • 如果我运行fossil open <project.fsl> --keep,我会得到Usage: fossil open REPOSITORY-FILENAME ?VERSION? 有什么建议吗? (没关系,我将删除所有内容并从头开始)
  • @PatrickT:是的,您可以保持多个存储库处于打开状态(通常在几个不同的工作目录中)。 fossil all list --ckout 告诉我我的机器上有 27 个打开的工作目录。
  • 如果你得到Usage: fossil open REPOSITORY-FILENAME ?VERSION?,那只是意味着它不理解你输入的内容,并告诉你它期望什么。 CAPITALS 中的所有内容都是占位符:您必须将其替换为(在这种情况下),您的存储库的文件名(和路径)。任何包含在?问号?是可选的,因此可以省略。
【解决方案2】:

低仪式和简单的开始

对于单个开发人员来说,化石存储库的生命周期可以非常简单:

  1. fossil new 创建存储库文件本身。
  2. fossil open 创建第一个(或可能唯一的)活动工作区
  3. fossil addfossil removefossil renamefossil addremove 让化石了解要跟踪的文件。
  4. fossil commit 提交对存储库的更改

在项目的整个生命周期中根据需要重复步骤 3 和 4。

这是化石最强大的优势之一:它在设计上是非常低级的仪式。您可以单独维护一个非常精细的项目,并且真的只能定期使用fossil commit

后续步骤

复杂性的下一个阶段可以向多个方向发展。如果您想与第二位开发人员共享项目工作,您将需要了解有关克隆存储库和同步更新的更多信息。如果您想在不破坏主干构建的情况下允许独立工作,您可以了解有关分支和合并的更多信息。如果您想利用 wiki 和工单跟踪器功能,您需要了解 fossil uifossil server 或配置您的网络服务器以启动化石。

但这些用例都需要使用fossil close 命令。事实上,fossil help 的输出最近被拆分为一个较短的大多数用户需要的命令列表,以及一个较长的所有命令列表。在那个部门fossil close 没有进入候选名单。它执行的唯一无法通过简单删除文件轻松完成的功能是验证它们不是未保存的更改,并从fossil all 命令可用的个人签出列表中删除打开的签出。

化石特定词汇

即使是单个开发人员也想了解化石文档中使用的一些词汇。

  • “checkin”:一组特定的文件修订版,由 UUID 标识,也可能由一个或多个标签标识。
  • “checkout”:与特定存储库关联的文件夹树(fossil open)。大多数化石命令要求当前目录位于打开的结帐中。
  • “UUID”:存储在化石存储库中的任何特定事物的唯一标识符。在实践中,UUID 是 SHA-1 所具有的以十六进制表示的事物。在大多数情况下,UUID 可以缩短到刚好足够完整哈希的前导数字来唯一标识它。它通常写成 8 位或 10 位数字,放在方括号中。
  • “工件”:存储在存储库中的文件或其他内容(wiki 页面、票证、清单等)。您签入的每个文件都会成为工件。每次签到的所有元数据(评论、时间戳等)也是如此。
  • “分支”:从某个根签入分支的连续签入行。分支用于将更改搁置一旁,直到它们准备好被合并,或者只是用于包含错误的更改。
  • “叶子”:分支结束时的签入。
  • “trunk”:任何存储库中的第一个分支都被命名为“trunk”。大多数其他分支将是沿着树干的一些签到的分支。
  • “manifest”:在特定签入中修改的文件列表以及描述签入的元数据(用户、时间、描述、其父签入的 UUID 以及它可能携带的任何标签)构成清单.大多数用户真的不需要担心清单,它们是由fossil commit 创建的,可以从网络界面查看。

网页界面

任何用户都想了解化石的网络界面。一个简单的第一步是在开放结账时说fossil ui。时间轴显示开发历史,每个签入都有一个节点,并绘制线条以显示分支和合并。 Web 界面是高度可配置的,提供 wiki 和工单跟踪器,还提供了一个 gui,可以从中调整与项目和存储库相关的大多数设置。

Fossil 本身是存储库内容的高效 Web 服务器。事实上,fossil's official web site 的大部分页面都是由化石本身提供的,从源代码存储库到化石。

更多帮助来源

除了web sitefossil help 提供的单个命令帮助之外,还有其他一些资源是许多用户应该注意的。

fossil-users list 具有始终如一的高信噪比。关键的开发人员和许多乐于助人且知识渊博的用户一样关注它。该列表至少有一个archive,还有一个单独的列表供开发人员讨论新功能和计划,但fossil-dev 不会很有趣,除非你想研究fossil 本身的内部结构。

Jim Schimpf 有一个book,它试图作为教程和完整参考,并包含一些关于最佳实践的建议。值得一读。

内置命令行帮助以及 Web 界面理解的所有页面 URL 的文档也可从任何存储库站点内的化石 Web 界面的/help URL 获得。该帮助文本包括每个命令的文档,包括不受支持的内部测试命令。

最后,StackOverflow 中的 [fossil tag][tag] 不能作为资源被忽略。

【讨论】:

  • @PatrickT,当然,没问题。我只是一个快乐的用户。我将编辑答案并添加一个指向邮件列表的链接,其中包括核心开发人员在内的很多人都在此闲逛。
猜你喜欢
  • 2021-06-09
  • 2020-11-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多