Re: Subversion's repositories

Chris.Fouts@qimonda.com wrote:
> In a normal development environment, trunk and branch dev/v1 (or any
> branch) are "parallel" development cycles, meaning, new code may
> be submitted to both in parallel. So once the trunk changes, it's no
> longer in "sync" with the branch. Conversely, once the branch changes,
> it's no longer in sync with the trunk. Ok so far?
>
> Even if the trunk does NOT change in parallel, that is, if ALL
> development is done on dev branch, one will still have to create tags on
> BOTH trunk and branch since they signify the last the time the branch
> was merge with trunk (trunk tag), and the last time trunk was merged
> with branch (branch tag)
>
> To resync the branch with the trunk, one would have to "svn merge" the
> "delta" between the trunk and branch, which is, the code from
> branch-pont to HEAD. In SVN terms this means
>> cd to branch sandbox (important step!!!)
>> svn merge //svn_root/project1/tags/trunk-to-dev_v1
> //svn_root/project1/trunk
>> (resolve conflicts)
>> svn commit
> Now the branch is in sync with the trunk. For future merges, one will
> have to move the trunk tag.
>> svn del //svn_root/project1/tags/trunk-to-dev_v1
>> svn cp //svn_root/project1/tr //svn_root/project1/tags/trunk-to-dev_v1
>
> Now to resync the trunk with the branch, the converse operation from
> above, one would need to "svn merge" the "delta" between branch and
> trunk, which is, the last time the branch was in sync with trunk to
> latest branch code. In SVN terms this means
>> cd to trunk sandbox (important step!!!)
>> svn merge //svn_root/project1/tags/dev_v1-to-trunk
> //svn_root/project1/branches/dev/v1
>> (resolve conflicts)
>> svn commit
> Now the trunk is in sync with the branch. For future merges, one will
> have to move the branch tag.
>> svn del //svn_root/project1/tags/dev_v1-to-trunk
>> svn cp //svn_root/project1/branches/dev/v1
> //svn_root/project1/tags/dev_v1-to-trunk
>
> Clear as mud?

This sounds awfully complicated to do a resync.

We do development on trunk and feature and per-developer branches all the time.
  Instead of merging using the tags and resolving conflicts like this, I would
suggesting switching to using svnmerge.py to maintain merges between trunk and
the branch.

It's trivally simple:

$ cd ..../my-trunk
$ svnmerge -b merge

If trunk was only receiving merges from a single branch, that's all you would need.

Likewise,

$ cd .../my-branch
$ svnmerge -b merge

would pull any unresolved revisions on the trunk.

The -b option to svnmerge tells it to ignore merges from the source of the merge
that originated on the destination of the merge. So it won't merge into the
branch a revision from trunk that originally was an original commit on the branch.

This is much faster and easier. Also, you can have multiple feature branches
work in this method, as long as all merges go through one trunk to distribute to
other branches.

See this URL for more info

http://www.orcaware.com/svn/wiki/Svnmerge.py

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org