保存部分完成的更改以处理其他更改
我正处于一个巨大的变化之中(比如说 ProjectA
),并且必须切换到同一文件上的不同项目(ProjectB
)。我还不希望我的工作进入 trunk
,而且可能需要几天时间才能回到 ProjectA
。
设置这个的正确方法是什么?我是否应该创建一个 ProjectA
分支并将部分完成的工作签入其中,然后将我的工作副本切换回 trunk
并在那里处理 ProjectB
?
完成后,我该如何将 ProjectA
合并回 trunk
?
我对冲突的解决
感到满意,我只需要知道分支、切换和合并的命令......如果我走在正确的轨道上的话。
目前我们只是在trunk
中完成所有工作。如果这是问题的一部分,请告诉我。
抱歉,如果这是一个骗局,但我已经尝试解决这个问题有一段时间了。
I'm in the middle of a large change (let's say ProjectA
), and have to switch gears to a different project on the same files(ProjectB
). I don't want my work to get into trunk
yet, and it may be a few days before I get back to ProjectA
.
What's the right way to set this up? Should I create a ProjectA
branch and check the partially completed work into it, then switch my working copy back to trunk
and work on ProjectB
there?
When I'm done, what do I do to merge ProjectA
back into trunk
?
I'm comfortable with resolved
for conflicts, I just need to know the commands for branching, switching, and merging... If I'm even on the right track.
Currently we just do all our work in trunk
. If that's part of the problem, let me know.
Sorry if this is a dupe, but I've been trying to figure this out for a while.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
假设在
trunk
中完成所有工作是一个好主意,并且假设您不需要来回切换(即,您在ProjectB
上完成工作在返回ProjectA
之前),我会执行以下操作:在
ProjectA
上记录我的工作ProjectA
上的工作,然后提交应用
ProjectA
中正在进行的更改<前><代码>补丁-Np0 -i ProjectA-WIP.diff
确保一切都很好
ProjectA
我经常遵循同样的过程。假设
项目 A
是一项新功能,项目 B
是一个错误修复;显然我不能将它们混合在同一个提交中,并且我必须在恢复新功能的工作之前修复错误。如何解决冲突
当冲突不是微不足道的,并且
patch
根本无法帮助您时,您可以使用一些技巧让svn
解决您的冲突。在
ProjectB
上提交工作后:在您的工作副本中,返回到您生成
diff
所针对的修订版;它记录在ProjectA-WIP.diff
中:如果您的旧版本是
NNNN
,则只需使用应用补丁;这次不会有任何冲突
更新
借助常用 Subversion 冲突处理工具解决任何冲突
Assuming that doing all your work in
trunk
is a good idea, and assuming that you don't need to switch back and forth (that is, you complete the work onProjectB
before returning toProjectA
), I would do the following:Record my work on
ProjectA
withWork on
ProjectB
and then commitApply your in-progress changes from
ProjectA
withEnsure that everything is fine
ProjectA
I often follow this very same procedure. Let's say
Project A
is a new feature, andProject B
is a bug fix; clearly I cannot mix them in the same commit, and I must fix the bug before resuming work on the new feature.How to solve conflicts
When conflicts are not trivial, and
patch
is not helping you at all, you could makesvn
resolve your conflicts with a bit of trickery.After having committed your work on
ProjectB
:In your working copy, go back to the revision you produced the
diff
against; it is recorded inProjectA-WIP.diff
:If your old revision was
NNNN
, just useApply the patch; there won't be any conflicts this time
Update
Resolve any conflicts with the help of the usual Subversion's conflict handling tools