automatically resolve (some) tree conflicts
Hello, nailing down some tree conflicts show that there are no differences at all comparing merged versions. One example is a file that has the same name, path and content, but was removed/added meanwhile, and Subversion lost the tracking that it is exactly the same file than before. Is there a tool or command to automatically resolve such sort of tree conflicts? Thank you. Regards Michael
automatically resolve (some) tree conflicts
Hello, nailing down some tree conflicts show that there are no differences at all comparing merged versions. One example is a file that has the same name, path and content, but was removed/added meanwhile, and Subversion lost the tracking that it is exactly the same file than before. Is there a tool or command to automatically resolve such sort of tree conflicts? Thank you. Regards Michael
Re: automatically resolve (some) tree conflicts
On Mon, Aug 20, 2012 at 12:14:06PM +0200, Michael Hüttermann wrote: > Hello, > > nailing down some tree conflicts show that there are no differences at all > comparing merged versions. One example is a file that has the same name, > path and content, but was removed/added meanwhile, and Subversion lost the > tracking that it is exactly the same file than before. Is there a tool or > command to automatically resolve such sort of tree conflicts? Hi Michael, Subversion performs additions and deletions as explicit operations that are independent of file content. If you don't want to break the line of history of a file you should not be replacing it. If a replacement happens accidentally and this causes tree conflicts during merges, I'd recommend to revert the replacement before committing the merge result. This way the replacement won't propagate further and will eventually stop causing trouble. I cannot give you more detailed advice without more information about the exact tree conflict cases you've been looking at. I'd recommend to take a look at trumerge: http://trumerge.open.collab.net It is an add-on to Subversion that detects renames by scanning the revision log and runs subtree merges on renamed files (as you would usually do manually to merge changes between branches with diverging tree structure). Note also that work is being done to make Subversion resolve some tree conflicts automatically and to provide interactive guidance when resolving tree conflicts in general. This will eventually make it much easier to deal with fallout from accidental replacments as well. Some improvements will be visible in Subversion 1.8 when it is released. Further improvements are planned for later releases. For details, see http://www.elegosoft.com/files/Downloads/Subversion_Day_2012/svn-day-berlin-2012_sperling_moves-and-renames-in-1-8.pdf (This slide set presents my personal view which is not necessarily shared by the entire development community. There is general agreement that we need to improve Subversion in this area but some details of how we're going to do it are still being discussed.)
Re: AW: Corrupt .svn directory using Subversion 1.7
Steven Lee writes: > On Aug 19, 2012 11:45 PM, "Steven Lee" wrote: >> >> Yes, I tried "svn update --set-depth infinity" and nothing happened. > Many of the files are still missing from my working copy. It does seem > like that should have worked. >> > > Just to be clear, I tried "svn update --set-depth infinity" in the foodir > directory and "svn update --set-depth infinity foodir" in foodir's parent > directory. The problem is that in 1.7 the operation you interrupted is not properly atomic so foodir is probably still marked as depth infinity despite haoving missing children. sqlite .svn/wc.db "select local_relpath, depth from nodes where local_relpath like 'foodir%'" So you probably have to do: svn up --set-depth empty foodir before svn up --set-depth infinity foodir will work. -- Philip
Re: AW: Corrupt .svn directory using Subversion 1.7
On Mon, Aug 20, 2012 at 1:21 PM, Philip Martin wrote: > Steven Lee writes: > >> On Aug 19, 2012 11:45 PM, "Steven Lee" wrote: >>> >>> Yes, I tried "svn update --set-depth infinity" and nothing happened. >> Many of the files are still missing from my working copy. It does seem >> like that should have worked. >>> >> >> Just to be clear, I tried "svn update --set-depth infinity" in the foodir >> directory and "svn update --set-depth infinity foodir" in foodir's parent >> directory. > > The problem is that in 1.7 the operation you interrupted is not properly > atomic so foodir is probably still marked as depth infinity despite > haoving missing children. Can / should this be fixed? Should an issue be created for this? -- Johan
svnsync fails on a 'pull' operation
We synchronise our production repository to a backup server, using a push model from post-commit and post-revprop hooks, and also a pull model (from the backup server) to a different synchronised copy as an hourly cron job. We also make a nightly hotcopy of the repository which is backed up to tape. The proverbial 'belt, braces, and a piece of string' backup approach. This has run quite well for us for some years, through various 1.6.x releases of subversion, and then 1.7.x releases. I was recently away for a few weeks, and returned to find the pull sync was failing, not able to lock the repository. I suspected some transient problem, likely a network glitch, had corrupted the target. We were running subversion 1.7.5 on both the source and target repositories. I re-created the target repository, re-initialised the synchronisation, and tried again. After 91 revisions copied, the svnsync command aborted. I thought, maybe something about that revision? So I recreated the repository, checked the permissions, and started again. After some 4 revisions, the svnsync command aborted again. I have since updated the target server to subversion 1.7.6, svnsync still crashes, always at a different point. I have just updated the source server to subversion 1.7.6, I have not had the chance to try svnsync again, but I am not hopeful. So, currently, we have Production server, svnsync source repository, Ubuntu 10.04 with a hand built subversion 1.7.6 Backup server, svnsync target repository, Ubuntu 12.04 with a hand built subversion 1.7.6 The repository has around 77000 revisions currently. The push svnsync still works correctly, but I am not sure if this is chance. Unfortunately our mail gateway has a history of blocking some mails from this list, so I will try to follow up via web archives. Replies cc'd to me should also make it through (I hope). Tony Butt CEA Technologies Canberra, Australia.
