问题
I find this way easier to merge branches and less conflicts:
Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the new branch back to the trunk. This technique is quite like the mercurial and git rebasing.
I used to merge whatever changs from trunk to feature branche/s. But later when I merged the feature branch back to trunk, some of the stuff from trunk would be merged back again to the trunk, which caused a lot of conflicts. There is a choise of reintegrate merge, but it didn't seem to work for me.
Does anyone do similiar subversion rebasing? I just started doing this recently, and haven't seen any side effects. Would this cause any unforseen problems?
回答1:
Generally speaking, rebasing is the act of incorporating upstream changes into a feature branch, before merging the feature branch back into the upstream branch.
In git, the process is even more sophisticated, because the changes that have been made since the branch was created are first taken off and buffered, the upstream changes are applied, then the buffered changes are applied. The takeaway here is merging trunk into a feature branch is not a rebase in git terms, there's more to it. The git approach has a number of advantages, but can't be implemented very cleanly in svn since all commits must be stored on the server (svn is not distributed), however it can be done in svn.
An 'svn rebase' (the git way) might look something like this
svn cp trunk feature- commits to feature & trunk
svn cp trunk feature-rebasesvn co feature-rebasecd feature-rebasesvn merge featuresvn commitsvn rm featuresvn mv feature-rebase feature- (back on feature-rebase WC)
svn switch feature
Then eventually on a working copy of trunk, svn merge --reintegrate feature
You see the difference from simply merging trunk to the feature branch? You start with the latest from upstream, trunk in this example, then merge the changes from feature onto that.
Imagine some of the commits on trunk could come from a merge of another feature branch into trunk, so I am not at all advocating committing directly to trunk.
回答2:
I wish I had a clever trick to tell you on how to achieve rebasing in SVN but I've always avoided manual refreshing of a branch with trunk changes in SVN mainly because of the complications requiring manual cherry picking that jdehaan mentions.
What I generally do instead is follow the practice of merging changes from a branch to the trunk, deleting the branch, and then recreating the branch from the trunk. This allows me to refresh/rebase my feature branch but with the sometimes unfortunate side effect that any prior changes from that branch are now part of the trunk. For this reason I only follow this practice when a feature branch is at a stable and usable point yet I still wish to continue work on that feature in order to further complete some bigger objective.
What I would prefer is that refreshing a branch by merging trunk changes back into a branch not cause subsequent reintegration merges from that branch to pull those rebased revisions during the process. It should be possible to do this based on the merge-info properties but according to what jdehaan states and what I have feared is that doing this still requires cherry picking.
Note that proper rebasing implementation should also be able to take into consideration stair casing examples where a branch is made from another branch.
Update: According to the Subversion documentation it appears that when using the --reintegrate option that Subversion should be able to properly reintegrate work done in a branch in a way that minds any possible refresh merges that may have been done to bring base changes into the branch. Of course this is is technically a little different than rebasing but i think it is similar enough in usage that it could be referred to as rebasing.
回答3:
In my company we use following approach:
- for each task NK-$X in the issue tracker we have a separate branch branches/NK-$X
- we start work on a task by svn cp trunk branches/NK-$X
- we never commit changes directly to the trunk. For each schedulled update UPDNK-$X we have a separate branches/UPDNK-$X. We create it with svn cp trunk branches/UPDNK-$X just before the update.
- when the task NK-$X is schedulled for an update UPDNK-$Y we merge branches/NK-$X inot UPDNK-$Y. That is cd UPDNK-$Y; svn merge -r start:HEAD branches/NK-$X
- after UPDNK-$Y is ready, we merge it to trunk. That is cd trunk;svn merge -r start:HEAD branches/UPDNK-$Y
If it happens that task NK-$X lasts longer than one iteration cycle, and therefore needs refreshing, we never, ever, NEVER merge trunk to NK-$X. We have a rule that you commit to your branch only things that you wrote yourself, which makes everything easier. Instead we do:
cd NK-$X
svn log
//let L = the number of the last changeset to this branch changeset
//let F = the number of the first changeset to this branch
svn rm branches/NK-$X
svn cp trunk branches/NK-$X
svn up
svn merge -r F:L branches/NK-$X@L
svn ci -m 'refereshed'
This way, whenever you look at the changelog of branches/NK-$X you see only changes actually performed by the developer.
Update: Since the above workflow can be automated, I've started a project on github: svn rebase.
回答4:
I am using this approach:
With rebasing you have to take care not to take the rebased revisions over when you merge again. When it comes to merging, do a cherry picking: select only the revisions on the feature branch that implement something new, not the rebasing changesets. Then it should work fine. COMMENT: I cannot ever remember having used the reintegrate branch for something. I think it is intended for very simple use-cases only.
In your new approach, it is not clear from the description how you handle the rebase from trunk to your feature branches if you need to. Do you want to completely disallow rebasing? As branching in svn is a cheap operation this could be an option too.
回答5:
I use a script that does a git like rebase for svn:
#!/bin/bash
set_safe()
{
set -eo pipefail
}
validate_number()
(
if (! [ "$1" -eq "$1" ] 2>/dev/null ) then
{
echo "$1 is not a number"
return 1
}
fi
)
get_line()
(
set_safe
#head -n "$1" | tail -n 1
sed -n "${1}p;$(($1+1))q"
)
split_trim()
(
set_safe
tr "$1" '\n' | sed -e 's/^\s*//;' -e 's/\s*$//'
)
run_svn()
(
set +x
#echo "svn $*" 1>&2
svn --non-interactive --password "$svn_password" "$@"
)
rebase()
(
set_safe
url="$1"
cur="$2"
end="$3"
validate_number "$cur"
if ([ -z "$end" ] || [ "$end" = "HEAD" ]) then
{
end="$(run_svn info "$url" | grep "Last Changed Rev" | cut -d' ' -f4)"
echo "end: $end"
}
else
{
validate_number "$end";
}
fi
while (true) do
{
log="$(run_svn log "$url" -l1 -r "$cur:HEAD")"
meta="$(echo -n "$log" | get_line 2 | split_trim '|')"
next="$(echo -n "$meta" | get_line 1 | tail -c +2)"
author="$(echo -n "$meta" | get_line 2)"
date="$(echo -n "$meta" | get_line 3 | awk '{print $1, $2, $3}')"
msg="$(echo -n "$log" | tail -n +4 | head -n -1)"
cur=$next
if ([ -z $cur ] || [ $cur -gt $end ]) then { break; } fi
echo "$msg" > .msg
echo "Merging revision $cur:"
echo "========"
cat .msg
echo "========"
run_svn merge "$url" -c $cur
run_svn commit -F .msg
rm -f .msg
run_svn update
echo "Success"
echo
cur=$(($cur + 1))
}
done
)
if ([ -z "$1" ]) then
{
echo "Usage:"
echo " svn-rebase.sh <url> <begin revision> [end revision]"
exit
}
fi
echo -n "svn password: "
read -s svn_password
echo
rebase "$1" "$2" "$3"
err=$?
if ([ $err -ne 0 ]) then { echo "rebase failed: $err"; } fi
exit $err
It merges revisions from other branch one by one.
回答6:
use git svn:
git svn clone -s <link to svn trunk/branches/tags parent>
then feel free to use git rebase command
来源：https://stackoverflow.com/questions/3177192/subversion-rebase