[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Commit dialog doesn't always refresh

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-05-18 19:30:20 CEST

Duncan Booth wrote:
> I'm using TortoiseSVN 1.3.3, Build 6219 and recently I've noticed a
> situation where the commit dialog doesn't work quite as well as it should.
> My configuration has the following setting:
> [auto-props]
> * = svn:eol-style=native

don't do that! You could (under certain circumstances) add that property
to a binary file and corrupt it by doing so.
Such a property should only be added to *specific* file types.

> This ensures that all newly added text files get the correct eol-style by
> default, but with the unfortunate side effect that any attempt to add a
> binary file will add the file but generate an error message. Adding
> multiple files will stop at the first binary file.

Only if you add multiple files. You can however add a single binary
file, and it will get the property set to it. Once you've done that,
your file is screwed.

> When I add a file by right clicking and selecting 'add' in the commit file
> window, the window refreshes to show the changed state of the newly added
> file. When the add generates an error it doesn't refresh, even though the
> add may have successfully added a large number of files, and I have to use
> F5 to force a manual (and probably slower refresh) instead.

Yes, we know the problem. But there's not much we can do about it (at
least not without forcing a complete refresh after every right-click
operation). Refreshing the state of selected files after an operation is
purely done by 'guessing' the new state (otherwise we'd have to do a
real refresh, which as you already noticed is much slower).

> I think right now the code is assuming that an error on an add means none
> of the selected files were added, when it should just assume that they may
> not all have been added. Either way it should update the displayed status
> on the affected files.

Refreshing (really refreshing, not just guessing) some files takes as
long as refreshing the whole dialog (fetching the status of a file is
the same as fetching the status of a folder and filtering out all other
files - that's what the Subversion library does).

> Of course it would be even nicer if it could detect this particular
> situation and regard it as a warning rather than a real error, and then I
> could add a whole bunch of mixed text and binary files in one go, but I
> guess that is down to the underlying svn libraries.

Yes, that's the library's responsibility.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu May 18 19:30:41 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.