Tortoise SVN merge adds `<<<<<<< .working`

I'm merging trunk into my branch to keep it up to date, but the process adds <<<<<<< .working (and other, similar metadata) within the files themselves - I've been getting a large number of tree errors but I've made some extensive changes so it's to be expected (although it seems like the merge is flagging every single folder as a tree conflict)

Is there any way to prevent Tortoise SVN from adding this metadata to the file directly (that messes about with its ability to compile) and/or cleaning a large number of files without having to revert + re-merge?

APPEND: The answers so far are correct however, the problem here is that metadata was remaining after resolving the conflict. Could this just be a bug?

4 Answers

Answers 1

These markers are inserted when tortoise can't resolve merge conflicts automatically, so it marks those as conflicted with information from both files - working copy and repository. These markers will be removed after you resolve conflicts in any way - manually with TortoiseMerge, with menu items "resolve conflicts use mine"/resolve conflicts use theirs". But you have to decide what part will be used in your working copy after update.

Answers 2

Those <<<<<<< markers are added by Subversion itself (it isn't a TortoiseSVN feature) but as far as I know not for tree conflicts. You must have regular file conflicts.

As far as I know, TortoiseSVN doesn't have any feature to fully automate conflict resolution. Options I can think of:

• Choose "Prefer local" or "Prefer repository" every time the "Resolve Conflict" shows up.
• Choose "Resolve all later" (I believe you only need to do it once) and, once finished merging, use the "Check for modifications" dialogue to select all conflicts and choose a method from the context menu.

Answers 3

this occurs when we run merge and conflicts comes in same file more than once.

Answers 4

Those metadata are written by SVN because of conflicts. You can solve using this command:

svn resolved <directory> 

Read More

All TortoiseSVN actions from the context menu are very slow

Every TortoiseSVN action I take from the context menu in Windows Explorer is extremely slow. For example, it takes ~91 seconds to open the About dialog. Results are the same for any other TortoiseSVN action I take from the context menu. However, if I login to a local administrator account, I don't have this problem. Additionally, once a TortoiseSVN dialog finally opens, further actions that I take within that dialog don't seem to be slow at all.

I'm running v1.9.5.27834 (and I've tried rolling back to earlier versions.) I have IPv6 disabled across the board. I've uninstalled and reinstalled multiple times, as well as manually removed all applicable %APPDATA% folders and registry keys I could find. I have no mapped network drives.

For what it's worth, I'm on a newly-imaged machine. I have a feeling that the backup restore restored some settings for my user account that are causing some conflict/timeout here (hence my uninstalling and removing %APPDATA%\TortoiseSVN, %APPDATA%\Subversion, etc.)

4 Answers

Answers 1

Usually, Tortoise SVN can be slow because of Icons Overlays:

Every file and folder has a Subversion status value as reported by the Subversion library. In the command line client, these are represented by single letter codes, but in TortoiseSVN they are shown graphically using the icon overlays.

This feature is very resource hungry and turning it off could dramatically increase performance of context actions and the whole system.

Please, refer this guide for disabling it.

Alternatively, you can filter displaying icons only on specific paths. To do that open Settings dialog -> Icon Overlays -> Exclude paths and put

C:\* 

Then set the include paths to the path where the working copy is:

C:\users\<username>\projects\someprojectname* 

Answers 2

Try to create another user profile from scratch, and see if the issue is still present on that new user.

That kind of lag usually comes from a resource which freezes.
It does timeout and is killed by the system.

Try to check these:
- your network connections
- the send (AppData\Roaming\Microsoft\Windows\SendTo) explorer-context menu
- the Explorer shell extension handlers (in the registry, classes_root)
- You can also check the Event Viewer for errors when you try to use SVN.
- Finally use Process Explorer from Sysinternals; it provides many tools to figure out what's going on deep under a process.

Answers 3

First, try latest nightly for 1.9 branch, next enable ipv6 again, the nightly you use uses ipv6, so disabling is a bad idea.

To see why also the latest nightly of TortoiseSVN is slow you need to install the Windows Performance Toolkit, which is part of the Windows 10 SDK (if you still use Windows 7, use the v1511/Build 10586 SDK, because this is the last version that works on Windows 7, for Windows 8(.1) and Windows 10 use the latest Windows 10 SDK).

^{(all other entries can be unselected)}

Run WPRUI.exe, select First Level, CPU Usage and click on start. Now do the slow right click in Explorer and try to go to about dialog, after you did this slow action, click on Save to save the data into a ETL file.

Now double click on the generated ETL file to open the ETL in WPA, setup and load debug symbols in WPA (add the debug symbol server from TortoiseSVN to the dialog in WPA).

Drag & Drop the CPU Usage (Precise) graph to analyse pane

and look for WAIT (µs) max for Explorer.exe in the table view to see that long hang and expand the stack to see where it happens.

Now WPA should show you the function of TSVN take take most time.

One idea is that TSVN tries to detect the last available version but it fails because you disabled ipv6.

Answers 4

It doesn't seems to be a Tortoise SVN specific problem, more an administrative one on your account. As the local admin as no problems, I suppose it may be related with hidden folders and user permissions.

What about it the .svn folder is not writeable for the current user, hence every single write (and maybe every read) fails, making you wait a counple of tenth of a second for each of those?

I would check the rights on the .svn folder of the project you are working on.

Read More

SVN - how to transform individually checked-out sub-folders into sparse checkout

SVN repo looks like this:

top/
top/one
top/two
top/three
...etc

You don't want to checkout the entire top folder but you don't know about SVN's sparse checkout feature.
So you check-out repo folder top/one into C:\svn\top\one and then you checkout repo folder top/two into C:\svn\top\two

At this point, both of the checked-out folders have their own .svn folder

Then you discover sparse checkouts.

QUESTION

How do you transform the "standalone" checkout of these two folders into a sparse checkout of the top-level folder with minimal re-checking out?

Is it as simple as initiating a sparse check-out while not overwriting existing items and then simply deleting the pre-existing .svn folders?

1 Answers

Answers 1

SVN works recursively, which means that every folder is mostly independent from its parent. So the issue comes from the .SVN in the parent folder, this is the one you want to recreate from scratch.

Rename your former folder (.old) and create a new one. Do your Sparse Checkout in that folder. It should download the files but you can prevent that with --depth empty.

Then, move your old folders back in the freshly created Sparse Checkout folder and Clean it. SVN will scan and repair the folder recursively.

Read More

Undo a Repair Move in TortoiseSVN

Suppose I have renamed File A to File B with windows explorer and created a new File C.

In Tortoise SVN, I accidently use the "Repair Move" on File A and C, instead of A and B. Is there an easy way to undo the repair (and redo it with the right files)? Changes are not committed at that point.

The only way I'm currently aware of is reverting the delete and add, which will restore File A, then manually delete the file again and redo the associations correctly. With multiple files involved, this somewhat involves the risk of accidently reverting local changes, so I'm interested if there is a better way.

Note: even though TortoiseSVN is used to produce the problem, an answer with svn console is also acceptable.

---

Here is the example with Files A.txt, B.txt and C.txt step by step:

After A is renamed to B and C is added locally

>svn st !       A.txt ?       B.txt ?       C.txt 

After Tortoise SVN "Repair move" is incorrectly applied A -> C

>svn st D       A.txt         > moved to C.txt ?       B.txt A  +    C.txt         > moved from A.txt 

My workflow to fix the situation, which I'm not really happy with:

>ren C.txt C.txt.bak >svn revert C.txt A.txt >ren C.txt.bak C.txt >del A.txt 

Resulting in the starting situation from where I can redo the repair with correct files

>svn st !       A.txt ?       B.txt ?       C.txt 

---

What I would love but which doesn't appear to exist

svn mv --force --ignore-files A.txt B.txt svn add --force C.txt 

in a way that it ignores that A is already marked deleted and allow a history transfer from A to B, reinterpreting C as clean add instead of transfering history from A.

1 Answers

Answers 1

There is way involving 2 commands on A.txt only instead of the 4 commands in your current workflow (affecting C.txt too). After TortoiseSVN "repair move" is incorrectly applied, execute:

svn revert A.txt del A.txt 

svn stat will be:

!       A.txt ?       B.txt A  +    C.txt 

From Tortoise SVN you can now "repair move" between A.txt and B.txt, resulting in the correct state:

D       A.txt         > moved to B.txt A  +    B.txt         > moved from A.txt A  +    C.txt 

Same technique can be used in TortoiseSVN UI (revert A.txt, then delete A.txt from the explorer). The reason why this works, is that the move state is coupled to the missing file, not to the non-versioned file. The only modification on C.txt is, that it was added by using the repair move command (which you wanted to add probably anyway).

The "Repair move" command only works if exactly two files are selected, one having the "missing" and the other the "non-versioned" status. Only that way TortoiseSVN can find out which file got renamed to which file.

https://tortoisesvn.net/repairmoves.html

After reverting & deletion of A.txt you end up with a missing file (A.txt) and a non-versioned file (B.txt) again, as before the incorrect applied repair move. So you can apply repair move again between these two files.

Read More

Why TortoiseMerge is slowly ditching “use theirs than mine” and similar functions?

I'm using SVN/Tortoise as code repository for my projects. When merging different branches I often encounter conflicts on (Microsoft Visual Studio) resource files; this happens easily if a dev adds a resource on a branch and another in trunk, for instance.

I always managed this kind of conflicts using "use theirs then mine" button in TortoiseMerge tool, the one that opens when trying to resolve conflicts.

During last years it seems to me that this function (the whole "use" thing) is getting relegated in secondary places: at first they put all the options under a drop down button and more recently I have to right-click on the preview pane to access it (no more button in the ribbon).

Now I wonder if I'm using the tool the wrong way: I mean, isn't "use" the main purpose of TortoiseMerge? If so, why all the other functions have more visibility and are more accessible than the only one I use?

Another option is that something is wrong with the "block" ribbon button, because it's always disabled in my experience.

0 Answers

Read More