sujithps / tortoisesvn

Automatically exported from code.google.com/p/tortoisesvn
0 stars 0 forks source link

user hook scripts not loaded and saved correctly #482

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
As reported on the mailing list:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=30584
35

I am encountering two problems (which I believe to be opposite sides of the 
same coin) with client defined hook scripts as of the 1.8.0 release.

FIRST - during the upgrade, my previously defined hooks were corrupted.  I 
believe this ~might~ be due to the new field choice "Always execute the 
script".  The old registry key did not possess a placeholder or delimiter for 
this field , and as a consequence when the new 1.8.0 tortoise unpacked the 
registry hooks key, the fields were not aligned properly.

This lead to the settings dialog showing the hooks in a bizzare visual format:  
attachement one.

SECOND - once I erased the bogus hooks , and recreated the hooks as they should 
exist - I am finding they disappear unpredictably.  I believe again this is 
tied to the 'Always' option NOT defining an empty delimiter.

Examining my Registry key: HKEY_CURRENT_USER\Software\TortoiseSVN\hooks
and unpacking the newlines - just after defining a new hook, I see: (bolding I 
added of course)

pre_update_hook
C:\SVNFocus
C:\SVNFocus\Utilities\Magic.exe MATTortoiseHandler.mps "{Pre-Update}"
true
show
post_update_hook
C:\SVNFocus
C:\SVNFocus\Utilities\Magic.exe MATTortoiseHandler.mps "{Post-Update}"
true
show

However, returning to the hooks dialog, and I do not see the post_update_hook 
defined.  BUT , if I then check off the "Always" option for the pre-update 
hook,  Isee:

pre_update_hook
C:\SVNFocus
C:\SVNFocus\Utilities\Magic.exe MATTortoiseHandler.mps "{Pre-Update}"
true
hide
enforce

Notice the new 'enforce' option - and notice that the post_update_hook is 
entirely removed.  I suspect an investigation into the registry import/export 
code for the client hooks would turn up this bug readily enough.

Original issue reported on code.google.com by tortoisesvn on 19 Jun 2013 at 5:52

Attachments:

GoogleCodeExporter commented 8 years ago
Follow up here:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=30584
48

Seems to me that the problem is in the  src\Utils\Hooks.cpp  code, in bool 
CHooks::Save() , where the defined hooks are stored back into the registry key 
, the code that glues together the string to store looks like:

for (hookiterator it = begin(); it != end(); ++it)
{
    strhooks += GetHookTypeString(it->first.htype);
    strhooks += '\n';
    strhooks += it->first.path.GetWinPathString();
    strhooks += '\n';
    strhooks += it->second.commandline;
    strhooks += '\n';
    strhooks += (it->second.bWait ? _T("true") : _T("false"));
    strhooks += '\n';
    strhooks += (it->second.bShow ? _T("show") : _T("hide"));
    strhooks += '\n';
    if (it->second.bEnforce)
      strhooks += _T("enforce\n");
}

Those last two lines, that tack on the 'enforce\n' bit ... well, if bEnforce 
isn't true, then no '\n' delimiter will be tacked on, and then later during the 
read in, if there are more than one hooks stored in the registry string, 
they'll be fouled up via an off-by-one style error.  Perhaps something like:

    strhooks += (it->second.bEnforce ? _T("enforce") : _T("disregard"));
    strhooks += '\n';

would fix this ... Hope that is useful...

Original comment by tortoisesvn on 19 Jun 2013 at 5:53

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r24419.

Original comment by tortoisesvn on 19 Jun 2013 at 6:11

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r24422.

Original comment by tortoisesvn on 19 Jun 2013 at 7:26