On Mon, Aug 18, 2008 at 2:01 AM, Steven Woody <narkewoody_at_gmail.com> wrote:
> I am following release-branch pattern described in the book "Version
> Control with Subversion". And, I have a question as below:
>
> Say, the release branch is rel-1.0 and the trunk is 'trunk' and,
> during a week, developers did some bug fixes in rel-1.0 while the team
> still work on the 'trunk', so
> the 'rel-1.0' and the 'trunk' both contains changes that differ with
> the status when the branch was firstly created (say the revison is 100
> when 'rel-1.0' was created).
> In the middle of the week, a developer found a bug in hello.c of
> rel-1.0 that can be fixed by merge current hello.c in the 'trunk', so
> he did it:
>
> $ /* cd to the rel-1.0 working copy */
> $ svn merge -r100:HEAD svn://the.server/trunk/src/hello.c
> $ svn ci -m '...'
>
> Now, it's end of the week, and we like to merge those bug fixes in
> 'rel-1.0' back to the 'trunk', by doing this, we kept the 'trunk' as
> bug-free as possible. So, I think we
> need to do:
>
> $ /* cd to the 'trunk' working copy */
> $ svn merge -r100:HEAD svn://the.server/branches/rel-1.0
> $ svn ci -m '...'
>
> But, I am afraid, in this way, some bad thing may happen to the
> src/hello.c, because I am re-applying some changes in the file (am
> I?). And, the hello.c is just an example, in the
> real world, there may be many files involved. So, I want to ask, what
> is the right way to handle this kind of situation?
With SVN 1.5, it will just skip any changes you have already merged.
With previous versions it would try to merge them again and would
likely produce conflicts.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-18 15:03:22 CEST