Suppress Diff Window

[erods]

Is there any way to not show the Diff Window after calling DoWorkingFileDiff using the sgdm.exe program. Basically I would just like to return a boolean on whether two items are different or not.

Thank you

[ericsink]

DoWorkingFileDiff always brings up a diff app. That's its purpose.

If you just want a bool result on difference, there are other ways to do this. For example, if you are trying to compare a working file against its repository counterpart, you could just get the file status from the WorkingFolder object.

Can you tell me exactly what you are trying to compare?

[erods]

Thanks Eric, that is all I really need to do is compare the repository version to the working file version.

[Ramesh]

I have a followup question that could actually require a comparison of the contents of the file in Vault to the working copy. This is for files automatically generated by MIDL and/or mktypelib.

We check in these generated files also into Vault. So on the build machine, we have a ksh script that does the following

• 1. Check out the autogenerated .h or _i.c file from vault
  2. Run the midl compiler
  3. Run a script that removes the timestamp that MIDL puts into the file (this is to ensure that that doesn't cause a checkin even though the rest of the file is identical to the one on the server).
  4. Then check in the file with the following

  Code: Select all

  gvault commit $1/iface/foo.h -unchanged undocheckout -repository xyz -comment "Automatically updated from foo.idl"
  

The 4th step ends up creating a version entry in the history, and I am not sure if the undocheckout is working - even though the files are identical.

So my questions are

• 1. How do I know if undocheckout worked if there is an entry in the history? BTW the version does get bumped up each time for the files
  2. If the above doesn't work, then is there a way to do a diff in a script on the actual contents? Then in that case, I could just call undocheckout instead of a commit with the option to undo checkout - assuming the history is unaffected! We end up with 24 checkins for each build when essentially there is no real change in the files. Makes reading the history search very slow.
  3. Obviously the folder versions are changing for each of these checkins also. The folder version gets bumped up at least by 24 during each build. Is there a way to group them as one? Should I use the batch option to achieve this?
  4. Is there a better solution?

Thanks!

[ericsink]

I have a followup question that could actually require a comparison of the contents of the file in Vault to the working copy. This is for files automatically generated by MIDL and/or mktypelib.

We check in these generated files also into Vault. So on the build machine, we have a ksh script that does the following

• 1. Check out the autogenerated .h or _i.c file from vault
  2. Run the midl compiler
  3. Run a script that removes the timestamp that MIDL puts into the file (this is to ensure that that doesn't cause a checkin even though the rest of the file is identical to the one on the server).
  4. Then check in the file with the following

  Code: Select all

  gvault commit $1/iface/foo.h -unchanged undocheckout -repository xyz -comment "Automatically updated from foo.idl"
  

The 4th step ends up creating a version entry in the history, and I am not sure if the undocheckout is working - even though the files are identical.

So my questions are

• 1. How do I know if undocheckout worked if there is an entry in the history? BTW the version does get bumped up each time for the files
  2. If the above doesn't work, then is there a way to do a diff in a script on the actual contents? Then in that case, I could just call undocheckout instead of a commit with the option to undo checkout - assuming the history is unaffected! We end up with 24 checkins for each build when essentially there is no real change in the files. Makes reading the history search very slow.
  3. Obviously the folder versions are changing for each of these checkins also. The folder version gets bumped up at least by 24 during each build. Is there a way to group them as one? Should I use the batch option to achieve this?
  4. Is there a better solution?

Thanks!

Sorry for the slow reply on this. This question was assigned to me, but the truth is I need to look at the code for the cmdline client in order to answer it. We owe you another response.

For now, let me point out that the rest of this thread was dealing with the client API, whereas you are using the cmdline client. That difference is significant.

[ericsink]

I have a followup question that could actually require a comparison of the contents of the file in Vault to the working copy. This is for files automatically generated by MIDL and/or mktypelib.

We check in these generated files also into Vault. So on the build machine, we have a ksh script that does the following

• 1. Check out the autogenerated .h or _i.c file from vault
  2. Run the midl compiler
  3. Run a script that removes the timestamp that MIDL puts into the file (this is to ensure that that doesn't cause a checkin even though the rest of the file is identical to the one on the server).
  4. Then check in the file with the following

  Code: Select all

  gvault commit $1/iface/foo.h -unchanged undocheckout -repository xyz -comment "Automatically updated from foo.idl"
  

The 4th step ends up creating a version entry in the history, and I am not sure if the undocheckout is working - even though the files are identical.

So my questions are

• 1. How do I know if undocheckout worked if there is an entry in the history? BTW the version does get bumped up each time for the files
  2. If the above doesn't work, then is there a way to do a diff in a script on the actual contents? Then in that case, I could just call undocheckout instead of a commit with the option to undo checkout - assuming the history is unaffected! We end up with 24 checkins for each build when essentially there is no real change in the files. Makes reading the history search very slow.
  3. Obviously the folder versions are changing for each of these checkins also. The folder version gets bumped up at least by 24 during each build. Is there a way to group them as one? Should I use the batch option to achieve this?
  4. Is there a better solution?

Thanks!

OK, so I'm trying to figure out exactly what you're doing and why. You may have found a bug in the cmdline client, but I'm not sure yet.

You are checking out the file.
Then you modify it.
Then you try to prevent it from being checked in.
Then you check it in.

I'm confused. Are you trying to checkin the modified file or not?

[Ramesh]

I knew the questions weren't as clear as they could have been...

This whole convoluted logic is there because these are generated by the MIDL compiler. The idea is that we want to check them in iff they are modified as a result of changes made to their 'source' files - i.e., the idl files. If the idl files haven't changed these files do not need to get checked back into Vault.

Since it is not straightforward to figure out if the idl files changed since the last successful build, the option is to do as outlined - regenerate the files after checking them out. But after that, if they havent really changed, undo checkout - but how do I find out if they haven't changed? I was hoping to rely on vault commandline to do the heavy lifting. The hope was the "-unchanged undocheckout" option would do the equivalent of an undocheckout if the commit command detects that the "contents" of the local file and the repository file are identical! But I suspect that the "-unchanged undocheckout' logic uses some other rule to detect if the file is unchanged - perhaps a timestamp comparison.. If so, I guess my only choice is to rethink my strategy...

Clear as mud....

[ericsink]

I knew the questions weren't as clear as they could have been...

This whole convoluted logic is there because these are generated by the MIDL compiler. The idea is that we want to check them in iff they are modified as a result of changes made to their 'source' files - i.e., the idl files. If the idl files haven't changed these files do not need to get checked back into Vault.

Since it is not straightforward to figure out if the idl files changed since the last successful build, the option is to do as outlined - regenerate the files after checking them out. But after that, if they havent really changed, undo checkout - but how do I find out if they haven't changed? I was hoping to rely on vault commandline to do the heavy lifting. The hope was the "-unchanged undocheckout" option would do the equivalent of an undocheckout if the commit command detects that the "contents" of the local file and the repository file are identical! But I suspect that the "-unchanged undocheckout' logic uses some other rule to detect if the file is unchanged - perhaps a timestamp comparison.. If so, I guess my only choice is to rethink my strategy...

Clear as mud....

In general, I recommend that people never checkin something which was automatically generated from something else. I can't help but observe right now that perhaps your difficulties now are due to your transgressions against this particular bit of doctrine?

Anyway, on to a more practical point: You said you are using ksh, right? How much of a usual Unix environment do you have? Could you just use 'cmp' to figure out if the idl file changed?

[Ramesh]

In general, I recommend that people never checkin something which was automatically generated from something else. I can't help but observe right now that perhaps your difficulties now are due to your transgressions against this particular bit of doctrine? Wink

Agreed - checking in an autogenerated file is a bad idea in general. But there are historical reasons beyond my control - we use some of the mktypelib generated files as includes in several projects.

If these files weren't autogenerated, and I had a reason to check them in with the same command, would I not face the same issues? I could verify that - I'll test the behavior... Really what would be helpful is to know the expected behavior - would a -unchanged undocheckout cause a version entry in the history if it does indeed do an undocheckout...

Anyway, on to a more practical point: You said you are using ksh, right? How much of a usual Unix environment do you have? Could you just use 'cmp' to figure out if the idl file changed?

Yep. I could use the cmp command - I'll give that a shot. i could do that for the autogenerated files too, now!

Thanks for your help and patience!