[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Question about Branching/Merging practices

From: Srilakshmanan, Lakshman <lakshman.srilakshmanan_at_police.vic.gov.au>
Date: Tue, 18 Mar 2008 14:21:20 +1100

Hi Lars,

Sorry I am bit late replying to your email, hope it's not too late.

Assuming you have taken all changes from trunk into your branch then you
can do the following

svn co svn://trunk wc-trunk
cd wc-trunk
svn merge svn://trunk svn://branch

If you have taken all the changes from trunk into branch, since taking
your branch copy, then your branch is a "superset of trunk". The above
commands will apply all changes needed to make trunk reflect branch,
which is what I believe you need.

-----Original Message-----
From: Lars Grunewaldt [mailto:lgw_at_dark-reality.de]
Sent: Thursday, 13 March 2008 10:02 PM
To: subversion
Subject: Question about Branching/Merging practices

Hash: SHA1

Hi there,

I have a problem with a specific "use case" of subversion, considering
branching and merging. Of course I read the svn book, and for most
"simpler" cases, branching and merging works like a charm (for years,
that is).

But in my current working environment with more than 10 developers
working in different groups, I ran into this problem:

1. we reach a point where we need to branch from trunk for a second dev
team for a "special enhancement" which will most likely break the system
for some weeks/month (i.e. major redesign). Lets say we branch in r100,
work begins, and the branch develops to r110.

2. while those 2nd branch is "in the works", there where some bugfixes
that had to be applied to the trunk (critical stuff). Those have been
commited in r106.

3. we decide that we need those bugfixes *immediatly* in the branch,
because they affect work on the redesign badly as well, so we do a
branch_wd:> svn merge -r100:110 svn://trunk ....

branch_wd:> svn commit
commited as r111

4. so far so good. The branch continues, and we finally reach completion
on r140.

5. now we want to merge all changes from the branch back to trunk:

trunk_wd:> svn merge -r100:140 svn://branch

Wupps: this will lead to some conflicts, because we will actually
re-"merge" the changes we merged from trunk to the branch in r111 into
the trunk!

But what can be done to avoid this? Is there a possibility to somehow
make svn "ignore" changes that have been commited?

Should we do two merges, like:

svn merge -r100:110 svn://branch
svn merge -r111:140 svn://branch

which would obviously ignore the merged changes from trunk, but leads to
a LOT of work if more than one time in history changes have been merged
from trunk to the branch? Or is this use of svn merge simply wrong, and
the whole scenario should be handled differently in the first place?

With best regards,

- --
Lars Grunewaldt - Dipl. Inf. (FH)
* software development
* multimedia design
skills: C/C++/Java/Python/PHP/(X)HTML/Flash/audio/video
web: http://www.dark-reality.de
mail: lgw_at_dark-reality.de

Version: GnuPG v1.4.7 (Darwin)


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org


This email and any attachments are confidential. They may also be subject to copyright.

If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email.

You must not read, use, copy, retain, forward or disclose this email or any attachment.

We do not accept any liability arising from or in connection with unauthorised use or disclosure
of the information contained in this email or any attachment.

We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-18 04:21:56 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.