与SVN上游同步工作 [英] Working in sync with SVN upstream

问题描述

我正在开发一个使用OpenSource项目代码的项目。其中一个要求是将尽可能多的代码推回到上游。

远程项目使用Subversion（不太好）。

我的当前设置如下所示：

  [Remote SVN]（git svn fetch） - > ; [My public Git]< ;-( push / pull） - > [我的开发。 Git] 
 VV 
（pull）
 VV 
 [测试网格] 
  

编辑11.7。 - 重新提出了问题

我的问题是我的本地公共回购和svn上游并存。

I必须提供3个公共分支机构：

• 保守稳定
  
• 实验稳定
  
  
  $ b

  这些分支现在是线性的（开发变得实验稳定，实验变得保守），但目标是标准3头合并方式。由于它们的公共性质，我不能重新分配这些分支。
  
  

  现在完全正交于此，我试图以某种方式使发送补丁更容易。从我的分支挖出它们很慢，并且容易出错。
  
  

  我的典型当前工作流程是：
  
  $ ul b $ b

• 在顶层开发分支上实现一些功能


• test&修复功能


• test&修复这个新功能破坏的其他功能（实际发生的很多）


• 确定这是否可以在上游接受（30:60是：否）


• 做了一些事情（我通常只写一个新的TODO）
  
  
  

  上游的另一个问题是他们接受补丁到不同的分支（我的公共分支是基于他们稳定的分支）。一旦补丁达到稳定的分支，我可以简单地忘记它们存在，但在这种情况发生之前，我仍然需要保持它们在本地。

  > git svn 文档建议在处理Subversion分支时，以下工作流程：
  
  

  ＃克隆一个repo（像git clone）：
   git svn clone http：// svn。 example.com/project -T trunk -b branches -t tags 
   
  ＃将svn：ignore settings添加到默认的git排除文件中：
   git svn show-ignore >> .git / info /不包括
   
  ＃查看您已克隆的所有分支和标签：
   git分支-r 
   
  ＃在SVN中创建新分支
   git svn分支waldo 
   
  ＃将您的主人重置为waldo：
   git reset --hard remotes / waldo 
   
  ＃本地更改
   git add ... 
   git commit ... 
   
  ＃当前分支上的更改
   git svn分拣
   $ b $将更改发送给Subversion 
   git svn dcommit 
   
  ＃检查新分支
   git svn fetch 

  以上工作流程适用于不间断在一个单一的Subversion分支上进行更改，你有一个提交位的奢侈品，但是跟多个活动的Subversion和git分支混杂在一起是有点棘手的。为了跟踪Subversion版本库waldo分支，从
  
  

   git checkout -b waldo-svn远程/ waldo 

  -svn后缀是为了避免形式警告
  
  

  警告：refname'waldo'含糊不清。

  ，同时也提醒你这个git分支是用于跟踪Subversion分支的。总是保持对这些分支线的变化！

  
  
  

  要更新waldo-svn，请运行
  
  

   git svn rebase 

  这将从Subversion获取更改，并对其上的任何本地更改进行重定位。它也足够聪明，可以识别当你的本地变化之一被逐字上游接受时：它将被Subversion提交替换，并且以 git-svn-id：... 在其提交消息中。

  



  当上游维护者修改补丁的内容和结构（例如将一个补丁分割成多个Subversion提交，或者将多个补丁合并为一个提交）是当生活变得有趣时，解决冲突并试图解开混乱。
  
  

  保持你的-svn分支在git中干净（没有变化），并创建问题分支关闭-svn分支。要发送补丁，请使用
  
  

   git diff waldo-svn waldo-fix-frobnicator 

  
  
  <然后当你 git svn rebase 赶上Subversion回购时，你需要查看日志并决定你的问题分支的相应处置， git的 GTD 。

  
  

  I'm working on a project that is using code from an OpenSource project. One of the requirements is to push as much code back to upstream as possible.

  The remote project is using Subversion (not very well).

  My current setup looks like this:

  [Remote SVN] (git svn fetch)-> [My public Git] <-(push/pull)-> [My dev. Git]
                                      VV
                                    (pull)
                                      VV
                                 [Testing grid]
  

  EDIT 11.7. - reformulated the question

  My issue is the coexistence of my local public repo and the svn upstream.

  I have to provide 3 public branches:

  • conservative stable
  • experimental stable
  • development

  These branches are now linear (development becomes experimental stable and experimental becomes conservative), but the target is a standard 3 headed approach with merging. Due to their public nature I can't rebase these branches.

  Now completely orthogonal to this I'm trying to somehow make sending patches to upstream easier. Digging them out from my branches is slow and prone to errors.

  My typical current workflow is:

  • implement some feature on top development branch
  • test & fix feature
  • test & fix other features broken by this new feature (actually happens a lot)
  • determine if this is something that could be accepted in upstream or not (30:60 yes:no)
  • do something about it (I usually just write a new TODO)

  Another problem with the upstream is that they accept patches into different branches (my public branches are based on their stable branch). Once the patches reach stable branch I can simply forget that they exist, but until that happens I need to still keep them locally.

  解决方案

  The git svn documentation recommends the following workflow when dealing with Subversion branches:

  # Clone a repo (like git clone):
  git svn clone http://svn.example.com/project -T trunk -b branches -t tags
  
  # Append svn:ignore settings to the default git exclude file:
  git svn show-ignore >> .git/info/exclude
  
  # View all branches and tags you have cloned:
  git branch -r
  
  # Create a new branch in SVN
  git svn branch waldo
  
  # Reset your master to waldo:
  git reset --hard remotes/waldo
  
  # local changes
  git add ...
  git commit ...
  
  # pull changes on current branch
  git svn rebase
  
  # send changes to Subversion
  git svn dcommit
  
  # check for new branches
  git svn fetch

  The workflow above is for an uninterrupted change on a single Subversion branch to which you have the luxury of a commit bit, but juggling multiple active Subversion and git branches is a little tricky.

  To track the Subversion repository's waldo branch, start off with

  git checkout -b waldo-svn remotes/waldo

  The -svn suffix is to avoid warnings of the form

  warning: refname 'waldo' is ambiguous.

  and also to remind you that this git branch is for tracking the Subversion branch. Always keep changes to these branches linear!

  To update waldo-svn, run

  git svn rebase

  This will fetch the changes from Subversion and rebase any local changes on top of those. It's also smart enough to recognize when one of your local changes has been accepted verbatim upstream: it will be replaced by the Subversion commit and have a line beginning with git-svn-id: ... in its commit message.

  When the upstream maintainers alter the contents and structure of your patches (e.g., modifying the code, splitting a patch into multiple Subversion commits, or combining multiple patches into a single commit) is when life gets fun resolving conflicts and trying to untangle the mess.

  For full generality, keep your -svn branches in git clean (no changes) and create issue branches off the -svn branches. To send a patch, use

  git diff waldo-svn waldo-fix-frobnicator

  Then when you git svn rebase to catch up with the Subversion repo, you'll need to review the log and decide on the respective dispositions of your issue branches, sort of a GTD for git.

  这篇关于与SVN上游同步工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！