Monday, June 23, 2008

VSS2005. How to create a broken database

While debugging Microsoft Visual SourceSafe support in TeamCity, I had found out quite easy case where VSS 2005 Automation api fails.
So, to reproduce it do the following:

  • Create Folders A,B,C

  • In each folder create a file. File names should be different.

  • Delete A

  • Rename C to A

  • call get_Versions on parent folder. You'll receive exception of loading IVSSItem from IVSSVersion object



Moreover, for that case, IVSSItem::Deleted getter returns false when calling to the file, that was created in folder A(before rename!)

Any idea of workarounds?

Wednesday, April 23, 2008

Books pack


P3130357x
Originally uploaded by eugene.petrenko
So nothing to write here. I just wanted to notice that all those books were packed to that box (on the top). All are on Microsoft technologies. Actually quite a good, but heavy bundle.

Monday, April 14, 2008

VSS has been digged

According to the problem mentioned earlier. I found the workable solution! The trick was, of course, to follow the workaround from Microsoft. But, I had to add one more workaround.

In case I found 'Added ' record, and I cann't tell sub items of VSSItem of the version and the previous version, I need to report all items inder that VSSItem as changed. This trick allowed me to build patch (for TeamCity version control integration) in the right way.

So the last portion is to handle renames and moves in the right way. The problem is that all changes are reported with path on the latest version, but not to the actual version. Thus, I have to implement some kind of mapping. Actually, apply backward mappings to all operations that was found in the history.

Stay tuned.

Wednesday, April 9, 2008

VSS digging: two cents

As far as I got, this is a known issue on VSS. Thay suggests comparing items sets to resolve the item... But sometimes this workaound does not works.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;843024
http://support.microsoft.com/kb/248078/

Digging into Source Safe Automation

Actually I have the problem to realize the name of the item that was added to the project. I receive IVSSVersions, iterate through it got IVSSVersion. This object represent all info of the current chage.

All information about change can be received by IVSSVersion::get_Action(BSTR*) method. I do not want to describe the troubles of parsing that string. I just want to show the case where there is no way to realize what is up. It is about VSS 6.0 and 'Added ' action.

I found out quite the same article on the problem here: http://www.eggheadcafe.com/forumarchives/vsnetvss/Sep2005/post23722335.asp

Moreover, it is fixed in VSS2005, but I need to solve it for VSS 6.0.

As the matter of fact, for that change it assocites parent project. So I can get the logic behind it, but, the only way for me is to try comparing items in that project on the version that is reported and the previous version. Looks promising, don't it?

But, as I noticed, some bulk additions may broke the versioning for the parent project. That means you will recieve THE SAME SETS of items for either current version or previous version, neglecting the fact of 'Added ' change.

Any idea on how to coupe with it?

Friday, March 21, 2008

Java and Process Tree

As you may know, Java is cross-platrofm, thus many os-specific features are not presented in the language at all. The same is for process-id.

The problem is to implement the cross-platfrom utility which is able to kill all sub processes of the current java process. For doing it under windows it is possible to use JNIWrap from TeamDev to get a proxy for WinAPI. After it getting possible to know out java-process's PID. That it is possible to build process tree and decide PID's to be killed. 

Under linux it is possible to do even without any calls to JNI! Even for NTPL threading model, where ps used to return all threads lists of the system.

The solutin is obvous. It is possible to call ps and than parse it's output to build the process tree. ps used to report itself. It is the most clear way to find current java process's PID. Killing processes is a sequence of kill -9 commands. But the trick is to be sure that you found the right ps process in the output... 

Have a goot hunting...

Welcome

Actually, I now realize I want to start new blog here. 

Everybody is still welcome to my livejournal blog at http://users.livejournal.com/_jonny_/

For now, I can hardy define the scope of it... So stay tuned to know more.