Re: New functionality

On 09.12.2009 04:52, Stefan Fuhrmann wrote:
> Hi there,
>
> as you can see from the commit log, I added / extended
> two features.
>
> (1) Checkout works from repobrowser for any combination
> of files and folders selected in the rhs list. Only these will
> then be fetched from the repository. Everyone who wanted
> as selective c/o: this is it.
>
> However, there is still an inconsistency in behavior. If all
> more than one path but no file is selected for c/o, the target
> directory on the disk will end up containing N independent
> working copies. The target path itself will not become a
> working copy. This is the traditional behavior.
>
> If there is at least one file involved, the new code path is used.
> The target directory itself will become a working copy of the
> common parent folder. After the checkout, only the selected
> sub-items will have been added. It is also possible to add
> further items later using the same procedure.
>
> Question: Which of the following should we do?
> (a) keep that inconsistency as is
> (b) use the new behavior for all cases
> (c) add an "create independent w/cs" (or the opposite)
> option to the c/o dialog and disable it in the second case.
> (d) something else

I'd say b and c here. Default should be b.

> (2) New "editfile" command. It is currently available via CL
> only but will soon be added to the repobrowser.
>
> Synopsis:
> * the given path may either be a URL or a path within a w/c
> * if it is a URL, the item will be checked out to temp location
> and will be deleted after the command finished.
> * if the item is not locked but has svn:needs-lock set, the
> lock will be acquired (asking the user for a lock comment,
> if the TSVN or project settings require it). In the latter case,
> it will released automatically at the end as well.
> * the document gets opened with the associated application
> (using Windows standard mechanism)

You're using CreateProcess() to start a console here. I think this is a
little bit strange to use "cmd /c" for this kind of feature?

I think it would be better to use ShellExecuteEx() and use the hProcess
handle of the SHELLEXECUTEINFO struct. And when using ShellExecuteEx(),
make sure you use the "edit" verb instead of the "open" verb. We don't
want to execute e.g., *.js files but edit them here.

Or you could read the registry yourself and find the editing app (with a
fallback to the opening app) - see CAppUtils::StartTextViewer() for an
example of this.

> * after closing that application, the changes will be committed
> using the standard commit dialog. If nothing was changed,
> the dialog will not show up.
> * final cleanup when applicable: unlock and delete temp. w/c
>
> Question:
> It's currently an orgy of flicking dialog boxes. With all the
> "auto-close" and "no lock comment" options active no
> clicking is required, though. Is there a way to hide the
> progress dialog unless there is error?

You could introduce a new flag in the CSVNProgressDlg which forces a
call to ShowWindow(SW_HIDE) if the flag is set. Then whenever an error
or something important happens you have to call ShowWindow(SW_SHOW) again.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2428953
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].