Dreamweaver 8 Checkout issue

[JimG]

After setting up a managed site, I can checkin/checkout files. If I don't checkout the file first and I double-click it to open it, Dreamweaver states it's a read-only file and asks what I want to do: View, Check Out, Cancel.

If I choose Check Out, the file doesn't show as being checked out. Also, if I then make a change to the file and save it, Vault sees it as Renegade.

Is Dreamweaver really supposed to Checkout the file when I select "Check Out" on that pop-up window or am I required to do a Checkout first on the file?

[lbauer]

What version of Vault are you using with Dreamweaver?

[JimG]

4.1.0

Linda, do you offer training/setup for Vault? I'm wondering if having someone come in a set things up and show us how it's "supposed" to work would help.

[JimG]

While we're on the dreamweaver 8 topic with my question above, I'd like to add another question/problem and figured this thread is as good as any.

I've installed the Vault Client (again, 4.1.0) on a co-worker's machine (also running Windows XP and Dreamweaver . He created a managed site for his repository. He can Checkout and Undo Checkout from Dreamweaver, but he gets a "File Activity" error when trying to Checkin. This error always occurs and it doesn't matter whether he's doing the Checkin from the Remote view or the Local view. Checkin works fine from the Vault Client.
Here's the error from the server log:
----3/26/2008 11:12:39 AM --()-- Exception in plugin thread : The request failed with HTTP status 400: Bad Request.

[lbauer]

We'll see if we can reproduce this issue.

[JimG]

While we're on the dreamweaver 8 topic with my question above, I'd like to add another question/problem and figured this thread is as good as any.

I've installed the Vault Client (again, 4.1.0) on a co-worker's machine (also running Windows XP and Dreamweaver . He created a managed site for his repository. He can Checkout and Undo Checkout from Dreamweaver, but he gets a "File Activity" error when trying to Checkin. This error always occurs and it doesn't matter whether he's doing the Checkin from the Remote view or the Local view. Checkin works fine from the Vault Client.
Here's the error from the server log:
----3/26/2008 11:12:39 AM --()-- Exception in plugin thread : The request failed with HTTP status 400: Bad Request.

Linda,
On this second issue here, I found 2 separate posts (Aug '06 and Nov '06) with older versions of Vault where the exact same thing happened. No resolutions were ever posted though (user's never followed up?). This type of issue is definitely user-specific. I can repeat the setup on my machine but I don't experience the checkin problem.

Edit:
However, if the user logs onto my machine and uses my Vault Client or my Dreamweaver, the same problem occurs with him. One obvious problem is that as soon as he checks out the file, it displays a Red checkout mark. Per Dreamweaver, the red check indicates the file is checked out to a teammate...that's where the problem is occurring, but that's also odd because he's allowed to edit the file and undo a checkout. If I check out a file as Admin and then go into Dreamweaver as myself, I can then get the red checkmark but it won't allow me to edit the file because it's not checked out to me.

This really sounds like a bug in Vault with the checkout to Dreamweaver 8.

[jclausius]

JimG:

PTI, but on the second issue, can you generate a Dreamweaver log file, post that along with a note of the file you are working with to this thread. ( See http://support.sourcegear.com/viewtopic.php?t=9499 for more info on the log file )

I don't think the log file will point to a specific problem, but I want to double check.


+ Do you know if the file is open within Dreamweaver 8 when checking it in?
+ Is the file in Templates?
+ When the file is not checked out, do you happen to see any .lck files for the file on disk? When the file is checked out, do you see the .lck file?
+ Check the the file's "read-only" attributes when checked out vs. not checked out.
+ Do you know if the file was at the "latest" version on disk before it was checked back in? (The GUI client would let you know the status of "old.")

[JimG]

I was going to create the DW log file as soon as he returns from a meeting. We were also going to try a test repository with a single test file to see if it happens to him on more than one repository. I'll post answers as soon as I have them all.

Thanks.

[JimG]

Okay, I tested this out with another person (BTW, three of us now have the client installed, all are in the Admin Group, and I'm the only one where this problem does not occur...remember, one logged onto my computer and used all my local software to verify that they still have the problem so it's not the software on their machines...it must be related to their rights somehow). We are validating their passwords using the Active Directory so all IDs and passwords are in sync.

I've attached the Dreamweaver Error Log. The only thing in this file relates to this test. We created a repository titled "Dreamweaver_Test" and added a new folder under the root titled "Temp1". In the Temp1 folder is a single file titled "Test.cfm" (the file only contains some spaces, carriage returns and the words "Test" in it). The User Name is PHinson.

To answer the other questions above:
1. The file is closed when checking it in from Dreamweaver 8.
2. The file is not in Templates.
3. When the file is not checked out, I don't see any .lck files. What I do see are _sgbak and a _notes folder with a dwsync.xml file in it.
4. Read-Only attribute is correct. Read-only before checking it out, but not read-only after it is checked out. After the failure to checkin, it's still "writable".
5. File was still the latest version before checkin. Before saving the changes, the Vault Client showed just exclusive checkout. After the save, it showed a status of Edited (and showed as Modified in the Pending Change Set.

One last thing to mention is that upon receiving the file error when trying to checkin, Dreamweaver is closing with a Fatal Error where it wants us to report the error to Microsoft (typical application has to close/reporting error).

I still don't get how they can check out a file in dreamweaver and it immediately shows that someone else checked it out by the red check (whereas Vault shows it checked out to them), yet dreamweaver lets them modify the file even with the red check.

[jclausius]

Jim:

Good catch on the checkout marks... I didn't see your Edit until this morning.

I think I might see a possible problem....

What is the name on the Vault account (noting case)? When the users are logging in with Dreamweaver, have them try to log in using the EXACT same case which matches their Vault accounts. Does that work?

Or you could try to create a new Vault login using all lower case letters. You may need to temporarily disable an account if you are out of licenses. Then using those newly named accounts (logging in with lower case), does DW seem to be working correctly?

[JimG]

You're good! Problem resolved.

Yes, you are right in that it's the case (upper vs. lower) of the Login ID. It appears the connections to Vault are not case-sensitive when initially connecting, but the minute something is checked out where Vault is trying to monitor the files in Dreamweaver, then the case-sensitivity does matter.

I reproduced the problem many times with my ID and theirs. The moment I checked a file out from Dreamweaver with my id with one letter in the opposite case than it is in Vault, then I got the Red Check.

So, the lesson here is that Login IDs in Dreamweaver are case-sensitive...even though it doesn't initially appear that way.

This certainly might be something to add to the Knowledge Base articles in the Dreamweaver section of Vault Knowledgebase...since this isn't the first time this was experienced and likely won't be the last.

Thanks for your help, Jeff. Is Linda still looking at my original issue in this posting?

[jclausius]

I'll log a bug to see if we can figure out a way to make DW ignore case.

In regards to the double click issue, I'll ask Linda to update the thread.

Thanks again.