svn merge tree conflict: unable to determine the conflicting local changes
Hi, I'm trying to understand a tree conflict problem during merge. After the merge from an import branch to trunk the client states "Tree conflict on 'upload.bat' > local file edit, incoming file delete upon merge" Normally I understand tree conflicts and generally know how to solve them. But I am not able to see which changes have been done to the file that are causing the conflict. There simply are none. svn log on trunk only shows two revisions: - adding the file in the initial import on the branch - copy to trunk So I'm not sure whether I'm doing something wrong or if this is a bug in subversion. I was able to dump and load the relevant parts of the repo and put it to a public server. The error is still reproducible. The repo can be found at svn://kfpc.de/Test/trunk/QtSrc The repo is still quit large. But for demonstration only trunk/QtSrc/qtwebengine/src/3rdparty/chromium/buildtools/win/ is needed. Merging branches/b015001/QtSrc/qtwebengine/src/3rdparty/chromium/buildtools/win/ into trunk will result in the tree conflict on 'upload.bat'. There are five more tree conflicts with deleted directories during a complete merge which are of the same category. There have never been changes to these directories or to file/sub-folders inside the directory since the initial import. Unfortunately there are more than 50.000 files/directories involved in the whole action. So it is not that simple to get an overview. I know that I could simply solve the conflicts as I know that the changes from the branch are what I want. But I'd really like to understand the issue. The original server is using subversion version 1.8.10 (VisualSVN Server Standard Edition 3.2.1). I tried the merge under Linux (command line client version 1.8.13) and Windows (TortoiseSVN 1.8.11, includes subversion 1.8.13). -- Christoph Sigma Surface Science GmbH, Idsteiner Str. 78, 65232 Taunusstein. Amtsgericht Wiesbaden, HRB 27422. Geschäftsführer: Norbert Nold
Something like svn:executable for the read-only bit?
We have some generated files that, for logistical reasons, are way easier to just check into the respository alongside the source than to build on-demand. (They're small text files, not some big binary or something like that.) Is there a way to instruct Subversion to remove write access when checking them out? Obviously the user could just chmod them to add it back, but the point is just to avoid someone unintentionally modifying the generated file instead of the source, not to keep people from being jerks. :-) Evan
Re: Something like svn:executable for the read-only bit?
On 16.07.2015 02:41, Evan Driscoll wrote: > We have some generated files that, for logistical reasons, are way > easier to just check into the respository alongside the source than to > build on-demand. (They're small text files, not some big binary or > something like that.) > > Is there a way to instruct Subversion to remove write access when > checking them out? > > Obviously the user could just chmod them to add it back, but the point > is just to avoid someone unintentionally modifying the generated file > instead of the source, not to keep people from being jerks. :-) Setting the svn:needs-lock property will make files in the working copy read-only. -- Brane
RE: Something like svn:executable for the read-only bit?
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Thursday, 16 July 2015 10:53 AM > To: users@subversion.apache.org > Subject: Re: Something like svn:executable for the read-only bit? > > On 16.07.2015 02:41, Evan Driscoll wrote: > > We have some generated files that, for logistical reasons, are way > > easier to just check into the respository alongside the > source than to > > build on-demand. (They're small text files, not some big binary or > > something like that.) > > > > Is there a way to instruct Subversion to remove write access when > > checking them out? > > > > Obviously the user could just chmod them to add it back, > but the point > > is just to avoid someone unintentionally modifying the > generated file > > instead of the source, not to keep people from being jerks. :-) > > Setting the svn:needs-lock property will make files in the > working copy read-only. Hi Evan, You can even do this automatically from the client settings or the server (from 1.5). If you look at the SVN book (http://svnbook.red-bean.com/) under Chapter 3: Advanced Topics -> Properties -> Automatic Property Setting, it talks about MIME types. It says that SVN will automatically set the svn:executable property on newly added or imported files whose execute bit is enabled. By enabling auto-props and including a MIME type statement similar to the following in your config file, you can automatically set the read-only properties: In our Windows world, we use a registry tool to set it on the client. Here are the relevant bits of our .reg file: ... [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany] "enable-auto-props"="yes" ... [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props] ... "*.exe"="svn:needs-lock" ... Obviously, this would need to be updated for your Unix system, but that's what we're doing here. The SVN book should give you good guidance there. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
