external merge tools for conflicts only
Is there any way to get svn to use an external merge tool, but only for conflicts? In other words, if I set up an external merge tool like diffuse (http://diffuse.sourceforge.net/), when svn finds a conflict it just throws both repository and working copy files at the external merge tool. In that tool, you'll see every difference, not just the conflicts. What I'd like is to have svn merge everything it can, and then call the external merge tool. The only differences shown in that tool will be the conflicting sections. Sort of an external version of the 'dc' command. Or is there some other way to do this? I'm using svn 1.7.8.
RE: external merge tools for conflicts only
On Mon, 14 Jan 2013, Warden, Neil wrote: From: Warren Block [mailto:wbl...@wonkity.com] Sent: Samstag, 12. Januar 2013 21:24 To: users@subversion.apache.org Subject: external merge tools for conflicts only Is there any way to get svn to use an external merge tool, but only for conflicts? In other words, if I set up an external merge tool like diffuse (http://diffuse.sourceforge.net/), when svn finds a conflict it just throws both repository and working copy files at the external merge tool. In that tool, you'll see every difference, not just the conflicts. What I'd like is to have svn merge everything it can, and then call the external merge tool. The only differences shown in that tool will be the conflicting sections. Sort of an external version of the 'dc' command. Or is there some other way to do this? I'm using svn 1.7.8. Hi Warren, possibly not the answer you are looking for, but hav you tried http://kdiff3.sourceforge.net/ as merge tool? In case of conflicts it resolves everything it can do automatically and only non-automatically resolved merge conflicts left over for manual resolution. I'm aware of it, but have not tried it because of the KDE dependencies. There's also meld, http://meldmerge.org/, which I tried a little. That was before it had an auto-merge option, which is apparently new. Diffuse made more sense to me. As far as the merge: I'm working on documentation in FreeBSD. Sometimes there is a merge from the current version back to a previous version, for example, a bug is fixed in both version 9.0 and version 8.0. The two doc files differ not just in the sections that are being merged, but in the places where they show version numbers. The version 8.0 doc should still have that version number after the merge. Anything that just does a diff on the two files will want to change those version numbers. The svn merge handles that correctly, leaving the 8.0 version numbers alone. It's possible--probably likely--there's a better way.
local dir edit, incoming dir delete upon update
May I humbly request improvements for this error message? local dir edit, incoming dir delete upon update The ambiguity of "edit" and "delete" (whether adjectives or verbs) is confusing every time. Could it be: local dir has been modified, but dir has been deleted in repository Or something like that. Thanks!
Re: Update-Only Checkout Enhancement
On Wed, 11 Dec 2013, Les Mikesell wrote: On Wed, Dec 11, 2013 at 11:16 AM, Bob Archer wrote: Yes, I understand the export function. I want functionality for release management into test and production environments. For these environments I have a few requirements: Files in these environments will NEVER be edited For new releases I will need to perform an update to revision, which will add, update and delete needed files I want as small of a .svn directory as possible Why? Disk is cheap. Much cheaper than the time it would take to modify svn to work the way you are requesting. Heck, I just bought a 1TB SSD for ~$500. The spinning version was about $120. Sometimes it is a good idea to distribute work out to clients and sometimes you really want the client to just be a lightweight client and make the server do the work of serving. I've always liked the minimal amount of data that CVS needs on the clients and sometimes wished that svn could match that. When FreeBSD switched from CVS to Subversion, there were a couple of projects attempting to replace our cvsup/csup commands for simple, history-less, source checkouts. One of these projects was svnup, http://jcm.dsl.visi.com/freebsd/svnup/ Not sure of the present status.
