Kevin.Gao.Blog

Today when I was browsing the MSDN VC++ forum, I saw a post asking the differences between “Start with debugging” and “Start without debugging”.

The original post is:

I’m having a problem with a network application I’m coding. I have this connection between a client and a server that only works when I start my application with “Start with debugging” and never with “Start without debugging”, both in Debug and Release configuration.

So my question is : what’s the differences with “Start with debugging” and “Start without debugging” that could possibly change the behaviour of a program? Because I don’t have a clue as of where to search for the problem… If it can help, my program is multi-threaded.

I also had the same question several years ago.

This issue is caused by the different variable initialization behavior of differnt run modes.

In the “Start with debugging” mode, the un-initialized variables are set to the default values. But in the “Start without debugging”, the variables are left random.

For example, you have:
int iHowMany;

In the “Start with debugging” mode, iHowMany is initialized to 0. But in the “Start without debugging” mode, the value of iHowMany is random.

It is easy to find all the un-initialized variables. The VC compiler generates a warning for using an un-initialized variable. Just go through the compiler warning list, find them and initialize them.

Check out basics

Check Out, along with Get Latest and Check In, is one of the most common operations in many version control systems.

The screen shot of Check Out in VSS 2005:

(Screen shot of Check Out project)

If we are checking out files (not a project), the Recursive and Build Tree options are not available.

In VSS 2005, we can check out a previous version in the history dialog box. In this article, we only talk about checking out the latest version.

To make changes to a file we must first check it out of the VSS database. When we Check Out an item, VSS retrieves the latest copy of the file to our working folder and makes it writable.

There are exclusive check out and non-exclusive check out. If a file is checked out exclusively, it cannot be checked out by other users.

Please always check out a file first before making any changes for the following reasons:

1. If a file is not checked out, it cannot be checked in;
2. If a file is not checked out, our local copy may not be the latest copy. Not working on a latest copy will definitely cause extra work, overwriting other’s change, confusion and many other problems;
3. If we change a file without checking it out first, other team members can check out the file and make changes to it, which can cause huge problem if parallel changing to a file is not desired.

Recursive, Build tree, Replace writable and Set file time

Please see the Get Latest article for details.

Allow multiple checkouts

There are two types of check out in VSS: exclusive check out or non-exclusive check out. For binary files, VSS automatically makes every checkout exclusive, since binary files cannot be merged. For mergeable files, if multiple checkouts is allowed by the administrator, we can choose to check out a file exclusively or not. If a file is checked out, but not exclusively, other team members can check out the same file and make changes to it.

Please see Lock-Modify-Unlock or Copy-Modify-Merge for details.

The SQL Server-based source control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Get Latest in SourceSafe / VSS
Next article >>>>: Lock-Modify-Unlock or Copy-Modify-Merge in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

VSS supports two modes of work, Lock-Modify-Unlock and Copy-Modify-Merge. Lock-Modify-Unlock is the default style.

The details of Lock-Modify-Unlock mode:

Under this mode, only one developer can check out a file and work on it. Other developers need to wait for the file to be checked in.

1. Developer A checks out a file, exclusively. An exclusive lock is placed on the file by VSS.
2. Developer A works on the file.
3. If Developer B wants to edit the same file, according to the behavior of SourceSafe, he/she needs to check the file out first. Since the file is exclusive checked out (locked) by Developer A, it cannot be checked out by Developer B.
4. After Developer A is done with the file, he/she checks the file back in. The file is unlocked.
5. Other developers can check out the file and work on it.

The details of Copy-Modify-Merge

Under this mode, multiple developers can check out a text file not-exclusively and work on it at the same time, which is also called parallel development.

1. Developer A checks out a file, not-exclusively.
2. Developer A works on the file.
3. Developer B wants to edit the same file, according to the behavior of SourceSafe, he/she needs to check the file out first. Since the file is NOT exclusively checked out (locked) by Developer A, the file can also be checked out by Developer B not-exclusively.
4. If Developer C wants to edit the same file, he/she can also check out the file not-exclusively.
5. When someone checks in the file, VSS checks if the current version number is the same as the version number when the file was checked out by the current user.
   • If the current version number is the same as the version number when the file was checked out by the user, a regular check in is performed by VSS.
   • If the current version number in the database is bigger than the version number when the file was checked out by the user (which means that someone else has checked in the file after the current user checked out the file), VSS will try to merge the file content first and check in the merged file content into the database.

Icons for different checkout modes

SourceSafe uses different icon for different check out modes as shown in the following screen shot:

1. Exclusive check out: . In this icon, there is a red box surrounding the icon;
2. Not-exclusive check out by single user: . In this icon, there is no red box surrounding the icon;
3. Not-exclusive check out by multiple-user: . In this icon, there is no red box surrounding the icon and there are two ticks in the icon.

How to choose the Lock-Modify-Unlock or Copy-Modify-Merge mode

1. Multiple check out needs to be enabled at the database side. To enable multiple check out:
   • Start SourceSafe Administrator;
   • Choose menu Tools -> Options, and click the General tab;
   • Check the Allow multiple checkouts checkbox.

The interface is shown as follows:


(Enabling multiple checkouts)

 

2. After the Allow multiple checkouts option is enabled on the server side, we can choose that if we want to check out a file exclusively on the client side. Please note that binary file can only be checked out exclusively no matter if the Allow multiple checkouts option is enabled or not.

   
   (Allow multiple checkouts at the client side)

The SQL Server-based source control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Check out in SourceSafe / VSS
Next article >>>>: File Diff in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Navigation Links:
Get Latest Version Basics
How does VSS determine if our local copy is the latest version?
Build tree
Set file time
Replace writable

Get Latest Version Basics

Get Latest, along with Check Out and Check In, is one of the most common operations in many version control systems.

The screen shot of Get Latest Version:

(Get Latest Version screen shot)

The Get Latest Version command retrieves the latest or the pinned version of the files to our local disk. For pinned files, the pinned version is retrieved, instead of the latest version.

A working folder is required for the Get Latest Version command.

The Get Latest Version command is the most commonly used command in SourceSafe. Usually when we come to work in the morning, want to compile a solution, or simply want to view the changes by our team members, we do Get Latest Version.

To get the previous versions by date, version or label, we need to use Show History command and then work on the previous versions.

The Get Latest Version can automatically detect which files are changed and only get the changed files. So even if we have a huge project, there is no problem, just go ahead and carry out the Get Latest Version function. There will be no big performance penalty. There is an option in VSS to let us specify how VSS determines if our local copy is the latest one. I will talk about the option in the following section.

How does VSS determine if our local copy is the latest version?

The interface for specifying how VSS compares files:

(Compare files by)

The default option is checksum, which is enough for most cases.

Build tree

When we try to get the latest of a project, if we select the Recursive option, a Build tree option is shown:

(Build tree option in Get Latest dialog box)

What does Build tree mean? When the Build tree option is not selected, if a sub project has a working folder explicitly set, the files under that project will be retrieved to the working folder. When the Build tree option is selected, VSS ignores/overrides the working folders setting of the sub projects and retrieves the files to the relative sub folders according to the VSS database project structure.

For example, we have $/working/projects with the working folder set to C:\VSS\working\projects, and $/working/projects/SCCManager with the working folder set to D:\SCCManager. When we do Get Latest recursively on $/working/projects, all the files directly under $/working/projects are retrieved to C:\VSS\working\projects. That is for sure. If the Build tree option is selected, all the files under $/working/projects/SCCManager will be retrieved to C:\VSS\working\projects\SCCManager (the working folder setting of $/working/projects/SCCManager is overridden). If the Build tree option is not selected, all the files under $/working/projects/SCCManager will be retrieved to D:\SCCManager (the working folder setting of $/working/projects/SCCManager is used).

Set file time

(Set file time)

When we do Get or Check out, VSS allows us to choose how VSS sets the file time.

Before we talk about the options, I need to point out that the time setting mechanism in VSS has issues if we have a distributed team. VSS was designed for local teams more than 10 years ago. Time zone difference is not incorporated into the design.

Let’s see an example. We have 2 developers using VSS. One is in North America east coast using east time and another is in west coast using pacific time. If the developer checked in a file from the east coast office at 10:00AM ET, and then if another developer checks out the file from the west coast office using check in time for the set file time option, the time of the file will be set to 10:00 AM. That is 10:00AM pacific time, not east time.

So why does this can cause problem? The answer is that if our developers are all in the same time zone, there is no problem at all. But if not, there are problems:

• The modification time in the file list of the main interface will be totally messed up:


(Modification time is messed up)

Depending on the time zone of the machine that the file is checked in through, the modification time listed here represents the time in different time zones.

• Our compiler may not be able to compile our solution correctly.

Most compilers use time to determine if a file is changed and only compile the changed files. If we choose Modification or Check In for the Set File Time option, we have to rebuild the whole project/solution all the time. If we choose Current for the Set File Time option, our compiler can work properly, since the files are set to the local time when we retrieve the file.

Replace writable

There is a very important concept in SourceSafe: VSS treats read-only and writable files very differently and overwrites read-only files without any warning or prompt. By default, after we add a file into VSS database, the file is set to read-only. And only after we check that file out, the file is set to writable. Under any other circumstances, the file is read-only. When we do Get or Check out, if the local file is read-only, no matter if the file content is the same as the one in VSS database, VSS overwrites the file.

Best practice: never change the read-only property of a file manually if that file is under VSS control.

VSS lets us specify how it replaces the local writable copy:

(Replace writable)

The SQL Server-based source control Software Designed to be a SourceSafe Replacement

The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Add operation of SourceSafe / VSS
Next article >>>>: Check out in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

After 7 months of hard work, I am excited to see that we are about to reach the Zero Bug Bounce milestone for SourceAnywhere 3.0 cross platform client. At this point, we have only 38 not closed bugs. 9 of them are in the Open state, and 29 of them are in the Fixed state (fixed by programmers, but not verified and closed by testers). During the whole process, we created 3317 issues, including tasks, bugs and notifications.

Although it took longer than expected to reach the ZBB milestone, we are glad to see that we will reach the ZBB milestone this week. SourceAnywhere 3.0 is a major release of SourceAnywhere. We added issue/bug tracking, project branch & merge, shelve/unshelve and many other features into this release.

A few months ago, our web team changed our site, www.dynamsoft.com, to make the visitor experience better.

Two weeks after the work was finished and the live web pages were finally updated, our web site team analyzed the web site usage data in Google Analytics. To our surprise, there were very few clicks from the organic Google content. The team tried searching in Google and almost none of our pages could be found. Even searching “Dynamsoft” or “SourceAnywhere” could not lead to our site.

Was it the magic of David Copperfield? Where had the website gone? If Google works properly (which we can assume it does), the causes of this issues are from the website. Our web team asked me for help. I reviewed the code of the web pages and found the cause of this issue. It was in a tag with the “robots” set to “noindex, nofollow”. -_- These tags are used when the pages are in our testing web server, to prevent search engines (such as Google, MSN and Yahoo) from indexing our not-ready web pages. After the pages are tested and before the pages are moved to our production server, the tags should be removed. But we did not do this.

So, we fixed the code and now finally the pages in www.dynamsoft.com can be searched in Google and other search engines again.

I also noticed several details but did not do further research:

1. When www.dynamsoft.com was not searchable in Google, the site was still searchable in Yahoo and MSN. The reason could be that Yahoo and MSN do not update their search database as often as Google, or they just ignore the noindex and nofollow tag.
2. When noindex and nofollow tags were used, the SSL encrypted pages, such as the download and purchase pages, were all still searchable.