Default action after Update opens the file, rather than show diffs.

[Tony Rietwyk]

In most TSVN dialogs, double clicking a file name shows you the diffs - except after doing an Update - it opens the file instead.  Strangely, the right-click menu in Update doesn't show Open as the bolded default action.  It would be really, really nice if you could add an advanced setting to make 'Diff with working copy' the default, instead of Open file.  I'm happy to make US$20 contribution to make it higher priority.  :O)

[Stefan]

A "diff with working copy" from the progress dialog requires network access to the repository. That's why it's not the default action because it's expensive, i.e. it can take quite a while to complete. And that's the reason why this won't change, sorry.

[Tony Rietwyk]

Thanks for the quick reply, Stefan, though it's a shame that you won't progress the request any further.  I have downloaded the tortoisesvn sources and seeing the supplied visual studio project gave that a try.   It built the SciLexer.dll, then promptly died on apr.h.  It appears that I have to run ./buildconf in the ext/apr project - but I can't see how to do that in Windows.  Can you point me to the minimum instructions to rebuild the ext dependencies for TortoiseProc?  My google-fu is having problems getting past the forest of 'how to use' rather than how to build. 

PS.  Now I know why Open With doesn't work in the progress dialog.  :O)

[Stefan]

there's a file named build.txt in the source root of TSVN...

[Tony Rietwyk]

A related post yesterday, reminded me to look into this.  Following the build.txt instructions:

• http://users.skynet.be/sbi/libxml-python/ seems to be broken.
  
• I downloaded libxml2_python-2.9.3-cp27-none-win_amd64.whl from https://www.lfd.uci.edu/~gohlke/pythonlibs/#libxml-python.
  
• I already had python2.7 installed.  Running pip install libxml2_python-2.9.3-cp27-none-win_amd64.whl didn't work.
  
• pip also warned about being an old version, so I upgraded it.  It then still complained about python 2.7 being past end-of-life.
  

Are there more up-to-date instructions?

Is there another list for developers of TortoiseSVN?

Since I only want to alter the double-click handler in TortoiseProc, are there more specific instructions for just building that?

I have attached an untested patch file.  From what I can see, CompareWithWC only does an extract, it doesn't need to download from the server.  Note - there is a warning in the previous merge handling section to do with the window handle, which may also apply to work copy diff. 

Is there anyone who can build TortoiseProc, who would be willing to make the change for me for a fee? 

[Bruce C]

I can help with one query.

> Is there another list for developers of TortoiseSVN?

https://groups.google.com/g/tortoisesvn-dev

Hope this helps.

[Stefan]

On Sunday, March 21, 2021 at 6:18:57 AM UTC+1 Tony Rietwyk wrote:

A related post yesterday, reminded me to look into this.  Following the build.txt instructions:

• http://users.skynet.be/sbi/libxml-python/ seems to be broken.
  
• I downloaded libxml2_python-2.9.3-cp27-none-win_amd64.whl from https://www.lfd.uci.edu/~gohlke/pythonlibs/#libxml-python.
  
• I already had python2.7 installed.  Running pip install libxml2_python-2.9.3-cp27-none-win_amd64.whl didn't work.
  
• pip also warned about being an old version, so I upgraded it.  It then still complained about python 2.7 being past end-of-life.

I'll try to update all python scripts to work with python3...

 

Are there more up-to-date instructions?

Sorry, no. 

Is there another list for developers of TortoiseSVN?

Since I only want to alter the double-click handler in TortoiseProc, are there more specific instructions for just building that?

I have attached an untested patch file.  From what I can see, CompareWithWC only does an extract, it doesn't need to download from the server.  Note - there is a warning in the previous merge handling section to do with the window handle, which may also apply to work copy diff. 

Is there anyone who can build TortoiseProc, who would be willing to make the change for me for a fee? 

I'm sorry, but your patch makes no sense. A compare-with-WC only makes sense for modified files, i.e. if they show a modified icon overlay.

After an update, the updated files are not modified.

So really, your patch makes no sense to me.

Stefan

[Tony Rietwyk]

After doing an update, I look through the files in the Update dialog list to verify the changes that other team members have done.  At the moment for each file, I have to right-click and then select "Compare with working copy".  I'd much prefer to just double-click the file to perform the same action.  That way my workflow is consistent with Show Log, and TortoiseGit/Pull. 

I never want to open the editor associated with a single source file, eg VS2019 - it's pointless when I need to open the project to get the related includes, etc. 

[David Balažic]

The menu text is confusing. As Stefan said, comparing non-modified WC files does not makes sense, but in this case the text is misleading. The operation is actually something like like "Compare your latest checkout with current checkout" (or similar).

This puzzled me also for a while.

And making this work on a doubleclick instead of opening the context menu makes perfect sense.(is is the already existing operation, just invoked differently)

Lp,

David

[Daniel Sahlberg]

måndag 22 mars 2021 kl. 01:31:11 UTC+1 skrev Tony Rietwyk:

After doing an update, I look through the files in the Update dialog list to verify the changes that other team members have done.  At the moment for each file, I have to right-click and then select "Compare with working copy".  I'd much prefer to just double-click the file to perform the same action.  That way my workflow is consistent with Show Log, and TortoiseGit/Pull. 

I never want to open the editor associated with a single source file, eg VS2019 - it's pointless when I need to open the project to get the related includes, etc. 

I also follow Tony's workflow (for the same reasons), but as Stefan posted in the other thread:

> Because we'd have to fetch the "previous" file version from the repository - and that simply takes too much time for a double click handler. 

As usual there is no one-size-fits-all and I can also see users that would prefer to have the way it is now. (David Balažic, downthread, has a point though regarding naming of the option).

However when investigating this I realised there is an inconsistency in the user interface. When right-clicking a file that was merged during the update the bold text is "Compare with working copy". A bold text would implicate that this is the default action - same as double click. However the double click handler is showing the local changes (same as double click in the commit dialog).

Kind regards,

Daniel Sahlberg

[Tony Rietwyk]

I agree with David, it IS confusing terminology.  My reading of the code is that "Compare with working copy" calls CompareWithWC, which does an extract, then calls the diff utility.  I don't recall the compare ever having to wait for the server, so I'm confused by Stefan's response.  Hopefully my request is now clearer to him, and we can get an option to enable this behaviour override.

[Bruce C]

I've been trying to follow this suggestion but I got a little confused because I don't normally follow the workflow that was being described. I was curious and thought I'd try to create a simple test to better understand.

I created a test repo. I added a couple of text files with some content. I then created two separate checkouts. On one of the checkouts, I made a couple of further commits to change one of the files. After that, I updated the second checkout.

The update dialog titled "Update Finished!" showed changes to the one file that had been changed.

In that update dialog, if I right click the changed file and choose the "Compare with working copy" context menu item, it opens a diff showing the changes that have been applied by the update. That is, the changes for the two additional commits made in the other checkout. I was a little surprised that this functionality existed since, at this point, there are no changes between the local working copy and the local pristine copy - both having been updated to the latest repo revision. I would also agree that the term "Compare with working copy" seems inaccurate and might be better as "Review update changes".

In the update dialog, if I right click the changed file and choose the "Open" context menu item, it opens the file in an editor. Absolutely as expected.

In the same dialog, if I double click that file it opens the file in an editor. That is, a double click performs the open operation. This does seem to be a surprising default action having already noted that the diff functionality is available.

I also note that the update dialog has a "Show Log..." button. If I click that it shows a log of the changes that have been committed since the last checkout/update. This is particularly helpful for reviewing the changes commited by others as it doesn't simply show all the changes at once but allows each commit to be reviewed individually, including the helpful information in the commit message. The log view also allows all revisions to be selected allowing the cumulative effect of the changes on a particular file. Also note, that double clicking the file in the log view will show the diff view.

If I were to make my own suggestion it would be that the update finished dialog report not only the final revision but the initial revision (e.g. "Updated from revision 900 to revision 1000"). If the update did something that I didn't want, this information allows for the option to return to the previous state by manually updating to the previous revision.

In summary, it does seem that the default action (i.e. double click) for the file be to show the diff, rather than simply to open the file. However, if I were trying to review the changes committed by others that are applied by the update, another option is to review the changes from the log view using the button functionality that is already provided. This log view also has the benefit that it has the requested double click behaviour for individual files.

Hope this help.

[Tony Rietwyk]

@Bruce - Thanks for your suggestions - I really like "Review update changes".  I hadn't realised that "Show Log..." was limited to only the applied commits.  I can then select all of the revisions in order to achieve the same effect as the aggregated diffs done by "Compare to working copy". 

The "Show Log..." seems to respond immediately, so I will use that.  I can then happily double-click as usual. 

This issue can be closed.