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. **************************************************************************************
