You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lars Grunewaldt <lg...@dark-reality.de> on 2008/03/13 11:02:01 UTC
Question about Branching/Merging practices
-----BEGIN PGP SIGNED MESSAGE-----
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
merge:
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
- --
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@dark-reality.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFH2QmpISCS20rPIYsRApbsAJwL076UsiWryXYvFbuwzgSvpphgCwCfUa4n
TtJ+DwkmFxbc/3oVWJ47wHo=
=bd9t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Question about Branching/Merging practices
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Lars Grunewaldt [mailto:lgw@dark-reality.de]
> Sent: Thursday, March 13, 2008 7:02 AM
> To: subversion
> Subject: Question about Branching/Merging practices
>
> 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
Yes. Multiple merges to skip the r111 is the solution.
> 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?
Less work than fixing the spurious conflicts. I can't remember if
svnmerge.py helps in this regard or not.
IIRC, you also have to remember not to make any extra, non-merge related
changes during the initial merge to the branch. Otherwise, you won't
remember to merge them back to the trunk.
> Or is this use of svn merge simply
> wrong, and the whole scenario should be handled differently in the
> first place?
When it comes out, Subversion 1.5 should handle the situation correctly:
http://subversion.tigris.org/merge-tracking/requirements.html
More fun 1.5 reading:
http://merge-tracking.open.collab.net/servlets/ProjectProcess?tab=2
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Question about Branching/Merging practices
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
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.
Thanks
Lakshman
-----Original Message-----
From: Lars Grunewaldt [mailto:lgw@dark-reality.de]
Sent: Thursday, 13 March 2008 10:02 PM
To: subversion
Subject: Question about Branching/Merging practices
-----BEGIN PGP SIGNED MESSAGE-----
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
merge:
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
- --
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@dark-reality.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFH2QmpISCS20rPIYsRApbsAJwL076UsiWryXYvFbuwzgSvpphgCwCfUa4n
TtJ+DwkmFxbc/3oVWJ47wHo=
=bd9t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
================================================================================================
EMAIL DISCLAIMER
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org