Microsoft just released Silverlight 2 Release Candidate 0

Today I got an email from Microsoft MSDN Flash with the news that Microsoft just released Silverlight 2 Release Candidate 0.

For those who do not know about Silverlight, Silverlight is a Microsoft tool to build a RIA (Rich Internet Application).
http://en.wikipedia.org/wiki/Rich_Internet_application

Much to Microsoft’s dismay, even though Microsoft launched massive marketing campaigns to promote Silverlight, it seems development teams like Adobe AIR and FLEX better.

For what’s new in Silverlight 2, please refer to:
http://silverlight.net/GetStarted/overview.aspx

Using Visual SourceSafe – Share

This article is a part of SourceSafe / VSS Tutorial

In version control, Share enables files to be shared among multiple projects. It creates share links among these projects, so that the item can be viewed in all projects. If an item is modified in one project, the changes will be reflected in other projects simultaneously.

To use the Share command, we must have the Check Out/Check In right in the project we are sharing from, and the Add/Rename/Delete right in the project to which we are sharing.

 

Why Share

Consider a scenario in which your team develops several projects at the same time, and they all use one header file named common.h. You can share common.h in all projects. That way, any change made to common.h in one project is immediately propagated to all other projects. The file in all projects will always keep the same content.

If we do not use the Share command, we may need to copy the shared files to other projects. This will cause a problem: We need to synchronize the file manually every time we make changes to the file.

Now we can understand Share better. Share command enables files to be viewed/ modified in multiple projects at the same time.

 

How to Share file(s)

To share an item, we can use Share command on the Versions menu.

  1. In Visual SourceSafe Explorer, select a project to share the file(s) to.
  2. On the Versions menu, click Share to.
  3. In the Share to dialog, choose the project from which you want to share the file(s) in the Projects box, and then select files in the File to share box. You can check the Branch after share option if you need to branch the file(s).

    Share Using Versions Menu
    (Share using Versions menu)

     

  4. Click Share to share the selected file.

 

However, there is an easier way to perform the Share command. We can Share the file(s) using drag-and-drop:

  1. In Visual SourceSafe Explorer, right-click an item.
  2. Drag the item over the receiving project and drop the item.
  3. In the resulting menu, click Share.

Share using drag and drop
(Share using drag and drop)

 

 

How to Find the Share Links

After we shared the file(s), we may want to know which projects the file(s) are shared in. In Visual SourceSafe explorer, we can right-click on a shared file and click Properties -> Links tab, thus all share links for the selected file will be displayed. A share link is a Visual SourceSafe path to a project that shares the file with other projects.

Share links
(Share links)

 

 

How Project Share is performed in VSS

According to the Visual SourceSafe help file, VSS supports file and recursive project sharing. This makes Share in VSS very convenient and efficient.

However, please be advised that VSS does not truly share projects. Instead of sharing project structure, VSS shares project through sharing all of its subsidiary files (recursively). So, if we change the project structure by adding or deleting a file, the change will not be reflected in other shared projects.

Share needs to be combined with Branch to play a greater role. We will go into details of Branch in my blog later. Please continue to pay attention.

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: Project Diff in SourceSafe / VSS
Next article >>>>: Branch in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Using Visual SourceSafe – VSS in Visual Studio 2005 & 2008

This article is a part of SourceSafe / VSS Tutorial

Navigation Links:

  1. Choosing SourceSafe as the SCC Provider in Visual Studio
  2. Adding Solution into Source Control of SourceSafe
  3. Performing SourceSafe Operations in Visual Studio
  4. Changing Source Control Binding
  5. Pending Checkins Window
  6. Viewing Source Control Message

 

Visual SourceSafe can be integrated into Visual Studio to source control solution files, project files and application configuration files. Using SourceSafe in Visual Studio allows us to source control the code directly in the Visual Studio IDE. When we try to modify a file source controlled by SourceSafe in Visual Studio, it will check out the file automatically (If you use the default setting Check out automatically for Checked-in item behavior On Edit in menu Tools -> Options -> Source Control -> Environment). We can then check in the modifications into the VSS Database.

 

Choosing SourceSafe as the SCC Provider in Visual Studio

To use SourceSafe to source control your files in Visual Studio, you need to select SourceSafe as your source control provider first. You can do that through the Visual Studio menu Tools -> Options -> Source Control.

Choose Source Control Provider
(Choose Source Control Provider)

 

Adding Solution into Source Control of SourceSafe

The files must be added into Source Control of SourceSafe before you can perform SourceSafe operations on them. To add a solution or project into VSS DB, right-click a solution/project file in Solution Explorer and click Add Solution to Source Control. In the following dialog boxes, enter your credentials and select a location for your project.

 

Performing SourceSafe Operations in Visual Studio

Now if you right-click an item in Solution Explorer or click menu File -> Source Control, you will see some additional SourceSafe functions, such as Get, Check Out/In, Undo Check Out, Compare etc.

Access SourceSafe functions through right mouse button
(Access SourceSafe functions through right mouse button)

 

Access SourceSafe functions through File menu
(Access SourceSafe functions through File menu)

 

View History
To view the history information of an item, you can right-click the item and select View History. You can perform operations like Check Out, Get, Pin in the History Explorer.

History Explorer
(History Explorer)

 

Changing Source Control Binding

If the project structure in SourceSafe is changed, or the project is moved to a new VSS DB, you will need to change the source control binding of the solution. Go to menu File -> Source Control -> Change Source Control, perform Unbind to removes the solution/project from source control and then perform Bind to associate the solution/project with the recent server folder or database.

Change source control binding
(Change source control binding)

 

Pending Checkins Window

Visual Studio provides a Pending Checkins Window which allows you to see all of the checked out files in the current solution. You can select items to check-in in the Pending Checkins window. To open it, click menu View -> Pending Checkins.

 

Viewing Source Control Message

In cases when source control operations failed for some reason, you may be confused at the vague error message prompted by Visual Studio. In this situation, you may take a look at the Output Window of Visual Studio. If it is not already open, you can click menu View -> Output to open the window, choose to view the output message of Source Control and you can find more detailed information there.

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<:
Next article >>>>: Switching Visual Studio projects from SourceSafe to other SCC providers
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Using Visual SourceSafe – Project Diff

This article is a part of SourceSafe / VSS Tutorial

Why Project Diff

Project Difference compares two versions of a project and displays the comparison results. We can use it to see the differences between our local Windows folder and VSS project, two local Windows folders or two VSS projects.

This is a very useful feature that gives us the big picture of differences between two project trees. In the Project Diff, we can also launch File Diff by double clicking a file.

How to Launch Project Diff

To show project difference, we can select a project in Visual SourceSafe Explorer, and then click menu Tools -> Show Differences.

We can also right-click a project, and select Show Differences to show project difference, as seen in the following figure:

Show Differences
(Show Differences)

Project Diff Results

Results of the Project Diff are displayed as side-by-side panes listing files and subprojects alphabetically. By default, the left pane represents the project version in the VSS repository, while the right pane represents the working folder version.

There are four types of files that can be listed in the comparison results:

  • Files that are only in the compare location highlighted with red.
  • Files that are only in the to location highlighted with green.
  • Files that are different in both places highlighted with blue.
  • Files that are the same in both places highlighted with black.

Project Difference
(Project Difference)

Basic Operations
In the Project Difference results window, we can do basic version control operations, like Add Files, Check In Files/Project, Check Out Files/Project, File/Project Difference, Get Latest Version and View, directly in this interface.
Reconcile All

 

Reconcile All
(Reconcile All)

There is also a powerful feature called Reconcile All, which can synchronize our whole local folder and VSS database by just making several simple choices.

Reconcile All is only enabled when we compare the differences between our local working folder and VSS project. It allows us to reconcile file differences between projects. There are 5 possibilities when reconciling differences:

  • Files that are not in our working folder, but are in the VSS project.
  • Files that are deleted in the VSS project, but are in our working folder.
  • Files that are not in the VSS project at all, but are in our working folder.
  • Files that are checked out to us, and differ between our working folder and the VSS project.
  • Files that are not checked out to us, but differ between our working folder and the VSS project.

By using Reconcile All, we can get, add or check in/undo check out files to synchronize our working folder with the VSS project.

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

Links:
Previous article <<<<: File Merge in SourceSafe / VSS
Next article >>>>: Share in SourceSafe / VSS
SourceSafe How To series home page: VSS / SourceSafe Tutorial

Using Visual SourceSafe – File Merge

This article is a part of SourceSafe / VSS Tutorial

To better understand how files are merged, you first need know something about how diff works. If you have not read the article: Using Visual SourceSafe – File Diff, please click here.

File Merge Introduction

File merge is the foundation of parallel development. Different team members can work on the same file at the same time and merge their changes back when they are done.

SourceSafe supports two work modes, the lock-modify-unlock mode and the copy-modify-merge mode. Lock-modify-unlock is the default mode and in this mode, only one person can work on a file at one time and file merge is avoided in most cases.

How merge is performed

Before discussing how merge is performed in version control, we first need to understand the concept of 3 parties in merge and 3 types of change.

3 parties in merge:
To perform a merge, 3 parties are needed: base version, source version and target version.

3 types of change:

  1. Add. We added new lines into the source code;
  2. Delete. We deleted lines from the source code;
  3. Change. We changed the content of a line.

Merge steps:

  1. SourceSafe compares the source version against the base version to have a list of changes made in the source version;
  2. SourceSafe compares the target version against the base version to have a list of changes made in the target version;
  3. SourceSafe tries to apply all the changes in the source version to the target version
    • If there is no conflict, all the changes in the source version are applied to the target version.
    • If there are any conflicts, visual merge is required. SourceSafe shows an interface to let us choose if we want the changes in the source version or the target version. We can also edit the content in the visual merge interface.

How Conflict is Detected
If the source version and the target version change the same line of the code, there is a conflict.

Example of merge

For example, the content of the base version is:
1
2
3
4

In the source version, the content is:
0
1
22
3
4

In the target version, the content is:
1
222
3
4
5

So in your current version, you have made the following changes:
Added ‘0’ before the first line
Changed 2nd line from ‘2’ to ’22’

In the another version, the following changes have been made:
Changed 2nd line from ‘2’ to ‘222’
Add ‘5’ after 4th line.

For the merge result, ‘0’ is added before the first line, ‘5’ is added after the 4th line. But since both of the versions have changed the second line, there is a conflict. When there is a conflict, it is not possible for SourceSafe to merge the files automatically and a visual merge is initiated to let us decide which changes will be kept.

The following is the screen shot for the above scenario:

Screen shot: Visual merge when there are conflict(s)
(Screen shot: Visual merge when there are conflict(s))

As we can see that the ‘0’ and ‘5’ are added to the merge result. Since there is a conflict in the second line, the content from the base version, which is ‘2’, is the default content in the merge result. We can choose ‘222’ or ’22’ for the conflicting line by clicking the mouse on the content we want.

Four scenarios that merge may be performed

In SourceSafe, there are four circumstances when merge may be performed:

  1. Merge branch
    In SourceSafe, you can branch a file to a different location and change the file content independently.
    Later on, you can merge the file content in the different locations back when needed.Under this situation:
  • The base version is the version that the file is branched;
  • The source version is the version that you want to merge the changes from;
  • The target version is the version you want to merge the changes into.

To merge a branch:

  • Select a file as the merge target (the merge result will be in this file)
  • Choose menu Versions -> Merge Branches to bring up the Merge Branches dialog box, as shown:

Screen shot: Merge branches
(Screen shot: Merge branches)

  • Choose a branch (this is the merge source) in the branch list;
  • Click Merge.
  • Check in when multiple-checkout is enabled.
    When multiple-checkout is enabled, after we check out a file non-exclusively, someone else can continue to check out and check in the same file.When we check in the file, SourceSafe will check the version number of the file in the VSS database. If the version number in the database is the same as the one we checked out (no one has checked in the file after we checked the file out), a normal check in operation is performed. If the version number in the database is bigger than the one we checked out the file (which means someone else checked in the file after we checked out the file), merge is performed before the normal check in operation.Under this situation:

    • The base version is the version that we checked the file out;
    • The source version is our local version;
    • The target version is the current version in the VSS database.
  • Get a checked out file when multiple checkouts is enabled
    After we check out a file, when we get the latest version of the file, if someone checked in the file after we checked out the file and if we choose Merge for the Replace writable option in the check out dialog box, a merge operation will be performed.

    Screen shot: Merge option in Get Latest Version
    (Screen shot: Merge option in Get Latest Version)

    Under this situation:

    • The base version is the version that we checked the file out;
    • The source version is the latest version in the VSS database;
    • The target version is our local copy.
  • Check out a file
    After we get a file to local disk, if we change the file property to writable, when we check out the file, if we choose Merge for the Replace writable option in the Check out dialog box, a merge operation will be performed.

    Screen shot: Merge option in Check out
    (Screen shot: Merge option in Check out)

    Under this situation:

    • The base version is the version that we did Get Latest Version;
    • The source version is the latest version in the VSS database;
    • The target version is our local copy.

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

 

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

Using Visual SourceSafe – File Diff

This article is a part of SourceSafe / VSS Tutorial

Why File Diff

File Diff is one of the important features that we use with a version control system. File Diff compares two files and shows the differences. With these differences, we can better track the modification of our code or documents.

What File Diff can do

File Diff can compare:

  • A local file and a source-controlled file.
  • Two local files.
  • Two source-controlled files.
  • Two versions of a source-controlled file.

For the first three situations, we can launch Difference Options by right clicking on the file list pane and selecting Show Differences…

Launch Difference Options
(Launch Difference Options)

In Difference Options, we can specify the two files, local or source-controlled.

Specify the two files for comparison
(Specify the two files for comparison)

To compare two versions of a source-controlled file, we can launch Difference Options in the History window of the source-controlled file.

Launch Difference Options in History
(Launch Difference Options in History)

For binary files, File Diff can indicate if they are identical but cannot show the differences.

How File Diff works

File Diff compares the two files line by line.

  • If a line exists in the first file only, SourceSafe indicates this line as deleted.
  • If a line exists in the second file only, SourceSafe indicates this line as added.
  • If a line in both two files has different contents, SourceSafe indicates this line as changed.

Example of File Diff

For example, we have an original file with the content:
111
222
333
444
555
666

After we make the following changes:
Added ‘000’ before the first line
Changed 2nd line from ‘222’ to ‘aaa’
Deleted the 4th line

We get the current file with the content:
000
111
aaa
333
555
666

For the diff result:

Diff Result

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft The Fastest SourceSafe Remote Access Tool Recommeded by Microsoft

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

Today, we reached the ZBB milestone for SourceAnywhere 3.0

I am very excited to announce that today at 5:25PM Pacific Time, 18th September 2008, our SourceAnywhere 3.0 team reached the Zero Bug Bounce (ZBB) milestone for the SourceAnywhere 3.0 cross-platform client. All together, we created 3362 issues, including bugs, tasks and notifications for the project.

In the coming 2 weeks, our team will continue to work on the cross-platform client to further improve the product quality. 2 weeks later, our testing team will start to do release testing for the client and our coding team will start to work on the Visual Studio IDE integration client.

The difference between “Start with debugging” and “Start without debugging”

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.

Using Visual SourceSafe – Check Out

This article is a part of SourceSafe / VSS Tutorial

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
(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.

 

SourceAnywhere - the SQL Server-based SourceSafe Replacement The SQL Server-based Source Control Software Designed to be a SourceSafe Replacement SourceAnywhere for VSS - the Fastest SourceSafe Remote Access Tool Recommended by Microsoft 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