You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Rothkin, Steven" <St...@Honeywell.com> on 2011/08/30 16:47:38 UTC
Merging from main trunk to release branch
I'm doing some testing and documentation in preparation for migrating
from CVS to Subversion.
I'm using svn, version 1.6.16 (r1073529) on Cygwin.
I'm having some difficulty with merging to release branches that I
haven't been able to find a solution for (other than continuing our old
CVS way of patching changes to active release branches).
The problem is this - there are inherently many changes between a
release branch and the main trunk (the older the release branch, the
more the number of changes). When we fix a bug and want to put the fix
in several releases, ONLY that change should be merged/patched.
So I made some changes in the trunk and committed them. I made some
changes that I expect to merge cleanly and some that I know will cause
conflicts due to differences between the code in the main trunk and
older release branches.
I then tried various different ways of merging just that change to a
release branch. I tried (all while in the top of the working copy of the
target branch):
svn merge -c 9840 $SVNHVAURL/argus/trunk
svn merge -r 9839:9840 $SVNHVAURL/argus/trunk
svn merge $SVNHVAURL/argus/trunk@9839
$SVNHVAURL/argus/trunk@9840
and a bunch of other ways as well (including using the trunk's working
copy as the source).
In all the cases, the conflicts that showed up included all of the
differences between the trunk and the branch (including in sections of
the affected files that weren't anywhere near any of the test changes
and so therefore didn't need to be merged).
As a comparison I tried:
svn diff -r 9839:9840 $SVNHVAURL/argus/trunk
That actually showed me just the changes that had been made. So the
question is how to get merge to apply just what svn diff shows and not
try to bring the release branch all the way up to the code that is in
the trunk? If I can't find a way to do that reliably, we'll be forced to
sticking with patch L
--
Steve Rothkin
Honeywell, Inc.
555 Pleasantville Road, North Bldg Suite 205
Briarcliff Manor, NY 10510
Office: 914-747-7198
Home: 914-762-4566
Cell: 914-420-3235
RE: Merging from main trunk to release branch
Posted by Bob Archer <Bo...@amsi.com>.
> > I'm using svn, version 1.6.16 (r1073529) on Cygwin.
>
> Concerning Cygwin, this is neither MS Windows nor Linux, and how much of
> each also depends on the way it is configured. In particular, you can configure
> Cygwin to use DOS-style line endings or Unix-style line endings, in order to
> easier integrate with other OSs. There is a working command line client for
> MS Windows and an even better graphical one (TortoiseSVN), so normally I
> would use those. If you really need to develop Linux software on MS
> Windows, then indeed I would also use Cygwin, but then I would keep other
> native MS Windows clients away from Cygwin working copies.
>
>
> Concerning line endings under SVN, it knows about different line endings
> (svn:eol-style property) and transcodes the files if told to. What it doesn't
> cope too well with is merging changes across changes of that property, I have
> many times seen SVN get confused and marking whole files as changed even
> though just a few lines were changed. Changing the line endings to one style
> before merging and back after that helps usually.
I think what he is saying is that he is trying to do a cherrypick merge and rather than just the changes applied in that one revision it is bringing in more.
BOb
Re: Merging from main trunk to release branch
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Aug 31, 2011 at 4:14 AM, Ulrich Eckhardt
<ul...@dominolaser.com> wrote:
> I.e. the whole file was marked as conflicted? This is an effect of conflicting
> line endings, as I initially mentioned. Try transcoding the file's line
> endings using dos2unix or unix2dos before merging and back afterwards. If the
> changes are then as expected, then you can blame the line endings.
Note that this is *exactly* the problem that can also happen when
using any shared storage for working copies, such as a CIFS mounted
network directory or a USB drive, and hopping from Windows clients to
UNIX or Linux or MacOS clients. It's why manipulating EOL settings
should be avoided if possible: treat the files as the default "binary"
mode.
The commonest source of such adventures I've run into is using CygWin
and TortoiseSVN on the same working copy on the same client, followed
closely by using a shared working copy for group members from both NFS
and Samba clients.
>
>
> You mentioned converting using cvs2svn. I haven't used this tool for ages
> (since converting my private stuff at SVN 0.27 or so) so I'm not familiar with
> its use. However, you can probably tell it how to manage line endings. For
> most textual files (code, scripts, XML, HTML, texts), I would normally use
> "svn:eol-style=native", so that they are easily usable on any system.
>
>
> There are also "auto-props". These don't affect the converted sources but only
> new files. Since they are client-side settings, you have to configure each
> workplace separately. This is not necessary to look at right now, but good to
> keep in mind, since it makes it easier that new files have e.g. the right line
> endings. The real place to verify the endings is a hook on the server side,
> but that then takes away the informed user's ability to choose.
>
> Good luck!
>
> Uli
>
>
> --
> ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
> FAQ: http://subversion.apache.org/faq.html
> Docs: http://svnbook.red-bean.com/
>
> **************************************************************************************
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **************************************************************************************
> Visit our website at http://www.dominolaser.com
> **************************************************************************************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
> **************************************************************************************
>
>
Re: Merging from main trunk to release branch
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
On Tuesday 30 August 2011, Rothkin, Steven wrote:
> I'm doing some testing and documentation in preparation for migrating
> from CVS to Subversion.
>
> I'm using svn, version 1.6.16 (r1073529) on Cygwin.
Concerning Cygwin, this is neither MS Windows nor Linux, and how much of each
also depends on the way it is configured. In particular, you can configure
Cygwin to use DOS-style line endings or Unix-style line endings, in order to
easier integrate with other OSs. There is a working command line client for MS
Windows and an even better graphical one (TortoiseSVN), so normally I would
use those. If you really need to develop Linux software on MS Windows, then
indeed I would also use Cygwin, but then I would keep other native MS Windows
clients away from Cygwin working copies.
Concerning line endings under SVN, it knows about different line endings
(svn:eol-style property) and transcodes the files if told to. What it doesn't
cope too well with is merging changes across changes of that property, I have
many times seen SVN get confused and marking whole files as changed even
though just a few lines were changed. Changing the line endings to one style
before merging and back after that helps usually.
> I'm having some difficulty with merging to release branches that I
> haven't been able to find a solution for (other than continuing our old
> CVS way of patching changes to active release branches).
>
> The problem is this - there are inherently many changes between a
> release branch and the main trunk (the older the release branch, the
> more the number of changes). When we fix a bug and want to put the fix
> in several releases, ONLY that change should be merged/patched.
For the record, "main trunk" is partially redundant. Here(tm), we just say
"trunk". That said, what you intend is what many people are doing
successfully. It is a normal operation that is supported and it should work,
so we just need to find out why it doesn't for you.
> I then tried various different ways of merging just that change to a
> release branch. I tried (all while in the top of the working copy of the
> target branch):
>
>
>
> svn merge -c 9840 $SVNHVAURL/argus/trunk
>
> svn merge -r 9839:9840 $SVNHVAURL/argus/trunk
>
> svn merge $SVNHVAURL/argus/trunk@9839
> $SVNHVAURL/argus/trunk@9840
AFAICT, those should all three be equivalent.
> In all the cases, the conflicts that showed up included all of the
> differences between the trunk and the branch (including in sections of
> the affected files that weren't anywhere near any of the test changes
> and so therefore didn't need to be merged).
Something like
<<<
<whole file at revision A>
===
<whole file at revision B>
>>>
I.e. the whole file was marked as conflicted? This is an effect of conflicting
line endings, as I initially mentioned. Try transcoding the file's line
endings using dos2unix or unix2dos before merging and back afterwards. If the
changes are then as expected, then you can blame the line endings.
You mentioned converting using cvs2svn. I haven't used this tool for ages
(since converting my private stuff at SVN 0.27 or so) so I'm not familiar with
its use. However, you can probably tell it how to manage line endings. For
most textual files (code, scripts, XML, HTML, texts), I would normally use
"svn:eol-style=native", so that they are easily usable on any system.
There are also "auto-props". These don't affect the converted sources but only
new files. Since they are client-side settings, you have to configure each
workplace separately. This is not necessary to look at right now, but good to
keep in mind, since it makes it easier that new files have e.g. the right line
endings. The real place to verify the endings is a hook on the server side,
but that then takes away the informed user's ability to choose.
Good luck!
Uli
--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************
RE: Merging from main trunk to release branch
Posted by "Rothkin, Steven" <St...@Honeywell.com>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Tuesday, August 30, 2011 3:59 PM
> To: Rothkin, Steven
> Cc: users@subversion.apache.org
> Subject: Re: Merging from main trunk to release branch
>
> On Tue, Aug 30, 2011 at 10:47:38AM -0400, Rothkin, Steven wrote:
> > I'm having some difficulty with merging to release branches that I
> > haven't been able to find a solution for
>
> > svn merge -c 9840 $SVNHVAURL/argus/trunk
>
> This one should work.
[[SDR]]
As I explained it isn't
> Where do run this command?
> It should be run in the root directory of a working copy of
> the release branch.
[[SDR]]
That is where I am running it.
> What version of Subversion is running on the server?
[[SDR]]
I'm currently testing using a local repository on my laptop. I am using
svnserve, version 1.6.16 (r1073529) (which exactly matches the svn
version).
The production server that it will eventually run on is 1.6.9 running
under RedHat linux.
> It needs to be at least 1.5 for merge-tracking to work.
> Also, the repository needs to be upgraded to 1.5 format or later
[[SDR]]
I created the repository by migrating our CVS repository using cvs2svn
version 2.3.0 under Ubuntu linux running inside a VM on my laptop.
> if it was created with an earlier release of Subversion
> (see
http://subversion.apache.org/docs/release-notes/1.5.html#mt-compatibilit
y)
Re: Merging from main trunk to release branch
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 30, 2011 at 10:47:38AM -0400, Rothkin, Steven wrote:
> I'm having some difficulty with merging to release branches that I
> haven't been able to find a solution for
> svn merge -c 9840 $SVNHVAURL/argus/trunk
This one should work.
Where do run this command?
It should be run in the root directory of a working copy of
the release branch.
What version of Subversion is running on the server?
It needs to be at least 1.5 for merge-tracking to work.
Also, the repository needs to be upgraded to 1.5 format or later
if it was created with an earlier release of Subversion
(see http://subversion.apache.org/docs/release-notes/1.5.html#mt-compatibility)
RE: Merging from main trunk to release branch
Posted by Bob Archer <Bo...@amsi.com>.
> I’m doing some testing and documentation in preparation for migrating from
> CVS to Subversion.
> I’m using svn, version 1.6.16 (r1073529) on Cygwin.
>
> I’m having some difficulty with merging to release branches that I haven’t
> been able to find a solution for (other than continuing our old CVS way of
> patching changes to active release branches).
>
> The problem is this – there are inherently many changes between a release
> branch and the main trunk (the older the release branch, the more the
> number of changes). When we fix a bug and want to put the fix in several
> releases, ONLY that change should be merged/patched.
>
> So I made some changes in the trunk and committed them. I made some
> changes that I expect to merge cleanly and some that I know will cause
> conflicts due to differences between the code in the main trunk and older
> release branches.
>
> I then tried various different ways of merging just that change to a release
> branch. I tried (all while in the top of the working copy of the target branch):
>
> svn merge -c 9840 $SVNHVAURL/argus/trunk
> svn merge -r 9839:9840 $SVNHVAURL/argus/trunk
> svn merge $SVNHVAURL/argus/trunk@9839
> $SVNHVAURL/argus/trunk@9840
>
> and a bunch of other ways as well (including using the trunk’s working copy
> as the source).
>
> In all the cases, the conflicts that showed up included all of the differences
> between the trunk and the branch (including in sections of the affected files
> that weren’t anywhere near any of the test changes and so therefore didn’t
> need to be merged).
>
> As a comparison I tried:
>
> svn diff -r 9839:9840 $SVNHVAURL/argus/trunk
>
> That actually showed me just the changes that had been made. So the
> question is how to get merge to apply just what svn diff shows and not try to
> bring the release branch all the way up to the code that is in the trunk? If I
> can’t find a way to do that reliably, we’ll be forced to sticking with patch ☹
What does:
svn diff -c 9840 $SVNHVAURL/argus/trunk
...show? Does it show more than you're expecting?
Whatever it shows is the same diff that:
svn merge -c 9840 $SVNHVAURL/argus/trunk
should apply to your wc. Also, can you verify it is the file CONTENTS that are being changed and not just the svn:mergeinfo propery on all those other files?
BOb