How to set options via the API

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

How to set options via the API

Post by Tilman » Tue Jun 19, 2007 7:42 am

Hi,

How can I set options via the API. In particular, I'd like to make it so that checked in files aren't read-only in my local folder.

Thanks,

Tilman

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 9:17 am

Which version of Vault are you running?

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 9:18 am

Sorry, 3.5.2.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 9:23 am

Also, why does this need to be set in the API? If you change your user's settings in the GUI's options window, the change should be reflected in any custom apps as well.

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 9:25 am

Yes, i noticed that, too, after I posted. However, now I'm thinking, I'd like to make sure of this setting, to ensure smooth running of my app.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 9:34 am

Assuming that your app is also doing the Get operation, you can just pass the
ClientInstance.Get method the MakeWritableType.MakeAllFilesWritable flag and it will override any user settings.

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 9:42 am

I tried that, but I still got files which suddenly turned read-only.

Possibly related to that, it sometimes happens that files get checked out, but they are not checked back in. As far as I can tell this happens totally randomly. Maybe you could help with that, too? Here is the code

Code: Select all

            ChangeSetItemColl updateFileChangeSets = new ChangeSetItemColl();

            VaultClientFolder root = m_VaultClient.Repository.Root;

            VaultClientFolder configurationFolder = root.FindFolderRecursive(m_ConfigurationFolderName);

            foreach (ITaskItem file in Files)
            {
                string vaultFileName = String.Format("{0}/{1}{2}", m_ConfigurationFolderName, file.GetMetadata("Filename"),
                                                        file.GetMetadata("Extension"));

                if (configurationFolder.HasFile(file.GetMetadata("Filename") + file.GetMetadata("Extension")))
                {
                    string localFolderName = String.Format("{0}{1}", file.GetMetadata("RootDir"),
                       file.GetMetadata("Directory"));

                    m_VaultClient.TreeCache.SetWorkingFolder(m_ConfigurationFolderName, localFolderName);

                    VaultClientFile vaultClientFile = root.FindFileRecursive(vaultFileName);

                    m_VaultClient.CheckOut(vaultClientFile, VaultCheckOutType.CheckOut, "Updated by build automation");
                    m_VaultClient.Refresh();

                    foreach (ChangeSetItem csi in m_VaultClient.InternalChangeSet_GetItems(false))
                    {
                        if (csi.DisplayName == file.GetMetadata("FullPath"))
                        {
                            updateFileChangeSets.Add(csi);

                            Log.LogMessage("Updating Vault file {0} with file {1}", csi.DisplayRepositoryPath, csi.DisplayName);

                            break;
                        }
                    }
                }
                else
                {
                    updateFileChangeSets.Add(new ChangeSetItem_AddFile(VaultDateTime.Now, "Added by build automation", "",
                       file.GetMetadata("FullPath"), vaultFileName));

                    Log.LogMessage("Adding file {0} to Vault as {1}", file.GetMetadata("FullPath"), vaultFileName);
                }
            }

            bool success = m_VaultClient.Commit(updateFileChangeSets);


jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 10:04 am

I think that you need to do an explicit

Code: Select all

m_VaultClient.CheckOut(vaultClientFile, VaultCheckOutType.CheckOut, "Updated by build automation");
m_VaultClient.Refresh(); 
m_VaultClient.UpdateKnownChanges_RefreshKnown(true)
to make sure that the internal change set is ready for you when you want to loop over it to get your changed file.

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 10:20 am

Nope, that didn't do it. Also, when the check in fails, sometimes the status is 'Needs merge' and sometimes its 'Edited'?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 10:27 am

That's it. A Needs Merge file can never be checked in. If the file is NM, your options are limited to

1. Get with MergeType.OverwriteWorkingCopy - delete what's on disk and try again.
2. Get with MergeType.AttemptAutomaticMerge - try to automerge the disk and the repository. If this fails (conflicting changes have been made on disk and in the repository), the file will remain Needs Merge.

Look at http://support.sourcegear.com/viewtopic.php?t=131 for more on Needs Merge

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 10:31 am

What if I used CVS mode? Hopefully then i wouldn't check out the file, instead, I would just set the working folder and check in. Would that work?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 10:32 am

CVS style users can get into a Needs Merge state just as easily as a VSS user, so it would not help to switch over.

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 10:45 am

Now the thing is, that the files I want to check in are mostly dlls, also I somehow don't quite trust automatic merging. Is there no way of just setting the merge status to resolved. After all, when I resolve the merge status manually, all that happens is, the status changes from 'Needs merge' to 'Edited' (which is why I'm a bit puzzled about the 'Needs merge' status, anyway).

Two other ideas I'm toying with are. a) check out the file, the make changes to it (i.e. copy new file on top), then check back in. b) delete file every time and add again. Would either of those have better chances of success?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Jun 19, 2007 10:53 am

I've just emailed you a bit of code which will resolve the merge manually (essentially forcing the checkin to always overwrite what was already there), since the files you're dealing with can't be merged ever.

Tilman
Posts: 52
Joined: Thu Mar 08, 2007 3:49 am

Post by Tilman » Tue Jun 19, 2007 11:56 am

Thanks for that, but that still didn't do it.

Debugging showed that in my app the status is always 'Edited', never 'Needs merge'. Only in the GUI does it say 'Needs merge' sometimes.

The other thing is that it doesn't always say 'Needs merge' in the GUI. Often the check in fails and the status is 'Edited'

I just tried to manually commit a failed check in and got this error message:

Upload for item $/Red Gate/Referenced Dlls/TestProject/1.0.0/Release/TestProject.exe failed too many times, aborting transaction.
Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client.
The specific error was "The server returned an unknown error header: VaultFileUpload.aspx encountered: FailFileInvalidCheckSum"
An exception was encountered during the transaction. Exception: The server returned an unknown error header: VaultFileUpload.aspx encountered: FailFileInvalidCheckSum at VaultClientOperationsLib.ClientInstance.UploadItem(ChangeSetItem item, String txID, Byte[]& streamBuffer, Int32& bytesWrittenThisFile, Boolean bIsImport)
at VaultClientOperationsLib.UploadThread.ProcessCommand(UploadThreadCommand command, UploadThreadCommandResult& outputResult)

However, I did that before and it worked.

Locked