incorrect change set after creating branch

nmcalpin · Post by **nmcalpin** » Thu Sep 22, 2005 9:30 am

Vault 3.1.1 client and server

note from our developer:

Steve branched [Project X] in Vault. I created a new local folder for the
new branch and set the working folder appropriately in Vault. Now I've
got a bazillion changes listed for that folder, which is impossible since
that folder was just now created. I have problems similar to this all the
time -- it makes the system difficult to use because it's hard for me to
tell what are "real" changes and what are changes Vault has randomly decided
I've made when I haven't touched any files.

any ideas?

nmcalpin · Post by **nmcalpin** » Thu Sep 22, 2005 9:44 am

I wanted to post a clarification to the above.

the changes are listed in the change set immediately *after* getting the files from vault.

so the order of events is:

project gets branched
user creates new local folder for branch
user sets working folder for new branch to new local folder
user gets files into working folder from vault
user notices that many files are shown as edited/changed

dan · Post by **dan** » Thu Sep 22, 2005 9:49 am

By default, Vault determines whether a file has changed in a working folder if the datetime of the file is different than when it was retrieved from Vault. In 3.0 and later, you can also use checksums to determine whether a file has changed via Tools->Options->Local Files

Is there anything non standard about the working folder, such as it being on a network drive or a Samba drive? Are the files checked out?

You could try the checksum route to see if that addresses it, but I'd still be interested why the file's datetimes are being reported as different from the Get time.

mlippert · Post by **mlippert** » Thu Sep 22, 2005 3:04 pm

I've got a question for you as well.

Double check the working folder of both the original tree and the branch and make sure they're both correct.

A couple of times now I and at least one other developer swears that our working folders got confused (I think my original tree WF was set to the new branch WF) and that caused some weird actions (such as get latest getting a ton of stuff) until we noticed. We're still not sure it wasn't somehow a user error though. (As a side note we're still using 3.0.7)

Mike

dan · Post by **dan** » Thu Sep 22, 2005 3:13 pm

Mike,

Are you using Visual Studio? There is a known problem with VS that after a branch, the bindings are still set to the old trunk rather than the new branch, and you have to rebind it to get it right.

I guess the main thing to verify is that the working folders with Vault are indeed pointing to the right place after a branch. We've not heard any reports of problems with this outside of VS, so if you can reproduce something that is Vault specific, we'd of course want to know about it.

Thanks,
Dan

mlippert · Post by **mlippert** » Thu Sep 22, 2005 3:25 pm

If I see this happening in a reproducible way I will definitely tell you about it. I wasn't posting trying to get a fix, just hoping to get you another datapoint from nmcalpin, but thanks for the response.

In answer to your question, yes we do use VS, but I don't think that was the issue. For 1 thing the original tree WF was set to the branch not the other way around. I'm not sure I started the VS UI although it is possible. And I think I fixed the mssccprj.scc file by hand before I did load the VS UI. I've carefully edited our solution and project files by hand to make sure that the project source control lines say "SAK", and that the solution source control lines for each project is a relative path, meaning that the only reference to source control is in the mssccprj.scc file.

I've actually found that this works much better than trying to unbind and rebind using the Visual Studio interface.

Mike