Minor (but anoying) Check In problem

Rachel Lavoie · Post by **Rachel Lavoie** » Mon Sep 20, 2004 12:29 pm

Vault version : 2.0.3

One of our programmeur has a bug when trying a check in. it went like this:

- check in file
- Vault display this sequence :
· [2004-09-15 16:41:47] Preparing data to begin transaction
· [2004-09-15 16:41:47] Beginning transaction
· [2004-09-15 16:41:47] Check in $/BlaBla/BlaBla.H
· [2004-09-15 16:41:48] Ending the transaction
· [2004-09-15 16:41:48] Transaction completed successfully

- File "check out" status desapear
- The user name that check out the file didn't desapear
- the file didn't get the read only status
- Unable to do a "checkout" neither a "check in" (see attachment)
- check in the history if the version was there. It were, modifs included, with the corresponding date displayed in the Vault sequence.
- try refresh without sucess.
- try close and re-open Vault, the bug was corrected, the file is read only now.

This problem doesn't block programmers to work, but it offen happens and it's kind of anoying. Programmers have to close and reopen client application each time.

Do you have informations about it? Do you know if there is any client configuration that can cause this? Is this a bug that will be corrected in the next version?

(we use the CVS check in style, means that we didn't necesseraly check out before check in, is this could cause this?)

Thanks in advance.

Regards,

Rachel Lavoie · Post by **Rachel Lavoie** » Mon Sep 20, 2004 12:37 pm

Seems like the attachment wasn't there...
sorry...

Rachel Lavoie · Post by **Rachel Lavoie** » Mon Sep 20, 2004 12:37 pm

Seems like the attachment wasn't there...
sorry...

Rachel Lavoie · Post by **Rachel Lavoie** » Mon Sep 20, 2004 12:39 pm

Well, this time it add-it twice!!
Sorry again...

sterwill · Post by **sterwill** » Mon Sep 20, 2004 2:06 pm

If you can reproduce this bug easily, please turn on the client-side logging for the check out list. See this KB article for detailed instructions.

You can enable the logging class "all" (which will create a large log file) until you can reproduce the problem. Then mail me the log file (you can disable logging then, to save drive space). Be sure to tell me the time the bug happened, so I can match it to the log file.

Rachel Lavoie · Post by **Rachel Lavoie** » Wed Sep 22, 2004 8:19 am

Thanks

I will activate it and as soon as we catch it again, I'll send it...

Rachel Lavoie · Post by **Rachel Lavoie** » Wed Sep 22, 2004 12:03 pm

I tried to activate the log file, and after modifying it, the application can't initialise...

I have 2 questions about it :

1- does spaces influence anything?
2- were do I add the code... before or after what's already in the config file? (After or befor the <Configuration> tag? or inside it??

Or... maybee you can refer to an article that will answer my questions?

Thanks...

sterwill · Post by **sterwill** » Thu Sep 23, 2004 3:26 pm

Spaces within the quoted values may affect logging operation, but spaces outside will be parsed according to XML standards (basically all collapsed into a single space). So the indentation of your tags shouldn't matter.

The tags in the KB article should be placed inside the <appSettings> tag (which itself is inside the <configuration> tag). A sample file may look like:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    [standard settings are already here]
  </system.web>
  <appSettings>
     [logging stuff goes here]
  </appSettings>
</configuration>

New Vault client installations will already have the logging keys in the .config file (logging is still disabled by default). If your Vault client was upgraded from 2.0.4 or earlier, these keys won't be there.

Guest · Post by **Guest** » Wed Sep 29, 2004 12:46 pm

Hello!

I don't know what I did wrong, but it still don't work...
Vault cannont open with this modification.

There is my config File :

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.net>
    <defaultProxy>
	<!-- 
            The following entry enables reading of the per user (LAN) Internet settings.
            Adding additional proxy settings, without first setting to "false",
            will individually override. Note that "Automatic configuration" and 
            "automatic configuration scripts" cannot be read.
            
            <proxy> settings:
                usesystemdefault="[true|false]" - Read settings from Internet Options (see above)
                proxyaddress="[string]" - A Uri string of the proxy server to use.
                bypassonlocal="[true|false]" - Enables bypassing of the proxy for local resources.
             -->
		<proxy usesystemdefault="true"/>
		<!--<proxy usesystemdefault="false" proxyaddress="http://proxyhost:proxyport" bypassonlocal="false"/> -->
		<!-- use this section to disable proxy use for matching servers
            example:
        <bypasslist>
            <add address="bypassRegexString" />
        </bypasslist> 
        -->
    </defaultProxy>
  </system.net>
  <appSettings>
    <!--
      enableLogging turns on client-side logging to a file in your temp directory (%TEMP%).
      If you think you have this file configured properly, but no log file appears
      in your temporary directory, check the system event log (we send messages there if we
      can't open the log file).
                   
      <enableLogging> settings:
       value="[true|false]" - When true logging is enabled, when false no messages will be logged.
    -->
    <add key="enableLogging" value="true" />
    <!--
      classesToLog lets you filter some log messages by class name.  SourceGear support will be
      able to suggest the appropriate class names to use for specific problems.  "all" will
      result in lots and lots (really) of messages.
                  
      <classesToLog> settings:
        value="class1,class2,class3,..." - Log these classes; separate with commas.
        value="all" - Log all messages from all classes.
    -->
    <add key="classesToLog" value="all" />
    <!--
      includeLoggingStackTraces includes stack traces with each log message in the client-side log.
      enableLogging must be set to "true" for this to have any effect.
                   
      <includeLoggingStackTraces> settings:
        value="[true|false]" - When true stack traces are included, when false they are not.
    -->
    <add key="includeLoggingStackTraces" value="false" />
    <!--
      includeThreadInfo includes thread names and IDs with each log message in the client-side log.
      enableLogging must be set to "true" for this to have any effect.
                   
      <includeThreadInfo> settings:
        value="[true|false]" - When true thread info is included, when false it is not.
    -->
    <add key="includeThreadInfo" value="true" /> </appSettings>
  </appSettings>
</configuration>

The section added was a copy paste of what I found at the link you gaven to me. It is textually this part :

Code: Select all

  <appSettings>
    <!--
      enableLogging turns on client-side logging to a file in your temp directory (%TEMP%).
      If you think you have this file configured properly, but no log file appears
      in your temporary directory, check the system event log (we send messages there if we
      can't open the log file).
                   
      <enableLogging> settings:
       value="[true|false]" - When true logging is enabled, when false no messages will be logged.
    -->
    <add key="enableLogging" value="true" />
    <!--
      classesToLog lets you filter some log messages by class name.  SourceGear support will be
      able to suggest the appropriate class names to use for specific problems.  "all" will
      result in lots and lots (really) of messages.
                  
      <classesToLog> settings:
        value="class1,class2,class3,..." - Log these classes; separate with commas.
        value="all" - Log all messages from all classes.
    -->
    <add key="classesToLog" value="all" />
    <!--
      includeLoggingStackTraces includes stack traces with each log message in the client-side log.
      enableLogging must be set to "true" for this to have any effect.
                   
      <includeLoggingStackTraces> settings:
        value="[true|false]" - When true stack traces are included, when false they are not.
    -->
    <add key="includeLoggingStackTraces" value="false" />
    <!--
      includeThreadInfo includes thread names and IDs with each log message in the client-side log.
      enableLogging must be set to "true" for this to have any effect.
                   
      <includeThreadInfo> settings:
        value="[true|false]" - When true thread info is included, when false it is not.
    -->
    <add key="includeThreadInfo" value="true" /> </appSettings>
  </appSettings>

The section that was already there works fine when I don't edit it.

Can you tell me what's wrong in the code or if there are another options to enable in Vault to make this modification?

Thanks in advance

Post by **jclausius** » Thu Sep 30, 2004 8:22 am

Rachel:

I'll let Shaw answer your questions about the client side logging.

I have a couple of questions:

1) In the Vault Admin tool, does the file display it is still checked out by the user?

2) Can you enable the Checkout Location setting for the File List Columns option, and view the location information. Does the machine / path in this column match the same machine from which you took your screen shot?

Rachel Lavoie · Post by **Rachel Lavoie** » Thu Sep 30, 2004 12:59 pm

Thanks again for your answer.

1) In the Vault Admin tool, does the file display it is still checked out by the user?

2) Can you enable the Checkout Location setting for the File List Columns option, and view the location information. Does the machine / path in this column match the same machine from which you took your screen shot?

Well, I can verify all that in the admin tool, but the user close the Cllient App, reopen it and update the file status since... so I don't think that the Admin tool will currently have the right information. (or maybee am I missing something, do you want me to check in an history log?)

I can try to reproduce the bug, verify these elements and give you some news if it appens again.

sterwill · Post by **sterwill** » Thu Sep 30, 2004 2:02 pm

You appear to have a duplicate </appSettings> key near the end of the file.