在 svn 中的文件夹之间保留修订历史 [英] Keep revision history between folders in svn

问题描述

我在一个简单的项目中使用 svn 进行版本控制.这是一个主要的emacs 模式，所以只有一个文件.

I am using svn for version control on a simple project. It is a major mode for emacs, so it is only one file.

我想要一种方法来维护开发和发布给用户的代码的修订历史，所有这些都是从同一个 svn 存储库完成的.我的目标之一是用户可以查看一致的 URL，并且让用户始终能够运行 svn update 以获取最新的发布"，尽管发布是非常非正式的.

I want a way to maintain revision history of both development, and of code released to users, all of which is done from the same svn repository. One of my goals is a consistent URL that users can check out, and for users to always be able to run svn update to get the newest "release," although releases are very informal.

我目前在devel"文件夹中进行开发，提交更改必要时进行开发.当更改准备好发布时，我复制mymode.el 从 devel 到trunk"(可能是一个糟糕的名称选择 - 这是用户签出的文件夹)以使用新更改覆盖工作副本，然后提交到主干.

I currently do my development in a "devel" folder, committing changes to devel as necessary. When changes are ready to be release, I copy mymode.el from devel to "trunk" (perhaps a poor choice of name - this is the folder users check out) to overwrite the working copy with the new changes, and then commit to trunk.

我很确定这会保留主干中的修订历史记录，但该方法似乎有点笨拙，我觉得我没有使用 svn它的预期方式.

I am pretty sure that this preserves the revision history in trunk, but the method seems sort of kludgey and I feel like I'm not using svn the way it's intended.

有没有更好的方法可以将 devel 的变化带到主干，或者也许是组织我的项目以允许更好的方法?

Is there a better way of either bringing changes from devel to trunk, or perhaps of organizing my project to allow a better method?

推荐答案

你现在的风格很丑:

• 任何 SCM 的任务之一是轻松重建整个代码演变，但在您的情况下，如果您(我理解正确吗?)只是将多个修订文件中的修改从 WC 复制到 WC - 您失去了关系在主干状态和开发分支状态之间:主干作为一组标签工作，没有已知的父级(尝试回答问题我在主干中从哪个分支修订版创建了 $THIS 修订版" - 你会失败)

工作流程、习惯和品味可能会有所不同.无论如何，我总是更喜欢每个任务分支"的风格(甚至为单次提交更改创建分支)并且在主干中只有合并集.为了您的目标为存储库中不同版本的代码提供永久 URL"我(同样，这是个人选择)更喜欢使用浮动"外部作为发布的 URL(不时更改 PEG 修订版)在定义中).即它可以是存储库根目录中的目录类型外部定义(Release"，fe)，映射到/trunk 的某个修订版(对于仅主干开发或对于几乎任何其他工作流 - 只有链接节点策略可能改变).

Workflow and habits and tastes may differ. Anyway, I always prefer "Branch per Task" style (and create branch even for single-commit changes) and have in trunk only mergesets. For your goal "Provide permanent URL to different revision of code in repository" I (again, it's personal choice) prefer to use "floating" externals as published URL (with changing from time to time PEG-revision in definition). I.e it can be directory-type external definition in the root of repository ("Release", f.e), mapped to some revision of /trunk (the same for for trunk-only development or for "Branch per task" of for almost any other workflow - only linking node policy may change).

你的用户总是会得到 REPOSTORY/RELEASE，但它可以在开发过程中/trunk@1,/trunk@10,/trunk@100 并且你将能够看到历史仅使用日志发布(发布"意味着更改外部定义，因此 - 特殊提交)

Your users will always get REPOSTORY/RELEASE, but it can be during development process /trunk@1, /trunk@10, /trunk@100 and you'll be able to see history of releases just using log ("release" means changing externals definition, thus - special commit)

这篇关于在 svn 中的文件夹之间保留修订历史的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！