Re: Merging from main trunk to release branch
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 <<< === >>> 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
On Wed, Aug 31, 2011 at 4:14 AM, Ulrich Eckhardt 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. > ** > >
Dump file
Hi all, Actually I have a problem that I can't figure out. I have included the dump file. Please help. Thanks & Regards JF svn-crash-log20110831181047.log Description: svn-crash-log20110831181047.log
Apache Subversion 1.7.0-rc2 Released
I'm happy to announce the release of Apache Subversion 1.7.0-rc2, the first public release candidate of Subversion 1.7.0. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: 691fd19a88908b10f4a96cbbd930ed359543d18b subversion-1.7.0-rc2.tar.bz2 261ae261bebce283ec3f4941641a536c7ffe7df2 subversion-1.7.0-rc2.tar.gz e2b3d54b5aafc0414657d88646df8575801ee158 subversion-1.7.0-rc2.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.0-rc2.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.0-rc2.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.0-rc2.zip.asc For this release, the following people have provided PGP signatures: C. Michael Pilato [1024D/1706FD6E] with fingerprint: 20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC Bert Huijben [1024D/9821F7B2] with fingerprint: 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 This is a release candidate for what will eventually become Apache Subversion 1.7.0. It is thought to be free of blocking issues, and if none are found will become the final release. For this reason, we encourage thorough testing in as many environments as possible. This release candidate begins the four-week "soak" period to allow for further testing, and barring show-stopping bugs, the final 1.7.0 release can be expected on or near Sept. 28. Even though we feel that this release is ready for widespread testing by the community, some things may still change before the final release. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.0-rc2 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.0-rc2/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Re: Dump file
On Aug 31, 2011, at 18:14 , Fernandes-Bastos, Joao / Kuehne + Nagel / Lux FY-P wrote: > Hi all, > > Actually I have a problem that I can’t figure out. > > I have included the dump file. The crash-dump file doesn't tell us much. What were you doing when the problem happened? Can you reproduce it? Regards, Steve -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
