API: Determine if file is ChangeSetItemType.Unmodified?

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
jkewley
Posts: 18
Joined: Wed Jan 05, 2005 4:36 pm

API: Determine if file is ChangeSetItemType.Unmodified?

Post by jkewley » Tue Jan 09, 2007 7:44 pm

I've got a process that runs daily and checks an XML file into vault. My process basically checks the file out to a working folder, then checks the file in from a different location. I'd like to be able to determine if the file I'm checking in is different from the file that's already in vault.

For now, I'd like to ignore the fact that I'm checking in from an alternate location. I've written a Unit test that checks out a text file, touches it without modifying the content, then checks it in. I'm trying to allow my checkin method to undo checkout if the file is unchanged. My current code always determines the ChangeSetItem to be of type ChangeSetItemType.Modified. Here is a snippet of what I've tried:

Code: Select all

public long CheckInFile(string aCheckInComment, VaultClientFile aFile) {
    MyInstance.Refresh();

    ChangeSetItemColl allPendingChanges = MyInstance.InternalChangeSet_GetItems(true);
    foreach(ChangeSetItem aChange in allPendingChanges) {
        if(aChange.DisplayRepositoryPath == aFile.FullPath) {
            myChange = aChange;
            break;
        }
    }
    if(myChange.Type == ChangeSetItemType.Unmodified) {
        //always hits, even when contents are the same
    }    
}
I've tried UpdateKnownChanges_All, which takes a long time but returns Modified anyway. I've also spent some time with the Command Line Client to see if you were forcing the comparison to update, but I didn't see any. I thought it might be related to the speed of the unit test running, but when I hit a breakpoint in my code and use the vault client to check the file in, it undoes checkout correctly.

Can you guys suggest something that I might be overlooking in the API that will allow me to force a ChangeSetItem to reevaluate whether or not it has been changed?

Thanks
-JK

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Wed Jan 10, 2007 9:01 am

Is it safe to assume you've not set the options to use CRC checks? See the UserOptionCollection instantiated in ClientInstance.UserOptions.DetectModifiedFilesWithCRCs for more info.

If you do not have this option set, you'll have to do this yourself with VaultLib.FileCRC32.
Jeff Clausius
SourceGear

jkewley
Posts: 18
Joined: Wed Jan 05, 2005 4:36 pm

Post by jkewley » Wed Jan 10, 2007 1:40 pm

Thanks, that did it. In case anyone else is running into this, here is the code that I'm using now:

Code: Select all

theClientInstance = new ClientInstance();
theClientInstance.Init(theAccessLevel);
theClientInstance.Login(theVaultServiceURL, theUserName, theUserPass);
theClientInstance.EventEngine.addListener(this, typeof(StatusMessageEvent));
//allows the client instance to determine if a file should be checked in or checkout shoud be undone
theClientInstance.WorkingFolderOptions.DetectModifiedFilesWithCRCs = true; theClientInstance.WorkingFolderOptions.RequireCheckOutBeforeCheckIn = true;
Is there a place where the WorkingFolderOptions are documented? I may have an olde version of the command line client, but I see no use of the DetectModifiedFilesWithCRCs option there...

Post Reply