Geeks With Blogs
Rodney Vinyard - .NET & SQL Developer When all is said and done, more will be said than done

Visual SourceSafe 2005 - Sharing and Branching 

 

Rodney’s Walk-through:

  1. Create a VSS Database
    1. Menu -> Open SourceSafe Database
    2. Observe list of databases previously opened
    3. Click add Button; observe Wizard
    4. “Create a New DB”
    5. Browse to a folder location
    6. Choose a DB name
    7. Pick Copy-Modify-Merge Model
    8. Finish wizard.
    9. In Windows Explorer, observe new folders & files:

 

 

  1. Open your new database.
  2. Create a “Test Source Project To Be Branched” in VSS.
    1. In VSS, right-click a node, (perhaps the $\ root node) under which you will create the new Node.  -> "Create Project" with new name.
  3. Populate “Test Source Project To Be Branched”
    1. In VSS, select new node (on left side of VSS Explorer)
    2. Observe empty contents on right side of VSS Explorer.
    3. use Windows Explorer to select a folder (on left side of Windows Explorer)
    4. select all child folders (on right side of Windows Explorer)
    5. Drag files from right side of Windows Explorer to empty right side of VSS Explorer
    6. Observe new folders and files on left & right sides of  VSS Explorer
  4. Create a “Branching Destination Node” in VSS.
    1. In VSS, right-click a node, (perhaps the $\ root node) under which you will create the new Node.  -> "Create Project" with new name.
  5. Populate “Branching Destination Node” in VSS.
    1. In VSS, select new node (on left side of VSS Explorer)
    2. Observe empty contents on right side of VSS Explorer.
    3. right-click the node -> “Share To”

                                                               i.      Select at the “solution file level” (to also share the child projects)

 

 

    1. click the Share Button
    2. check the Recursive checkbox
    3. Observe empty copy of Source Tree, copied under Destination Tree.
    4. You  have Shared, but you have not Branched

                                                              i.      If you make a change in either project, conflicts will arise.

                                                            ii.      However you resolve the conflict will be saved in both places, because physically there is only one copy of the file in the VSS DB.

  1. Branch the “Branching Destination Node” in VSS.
    1. (In VSS, you can branch files but not folders)
    2. For each subtree in “Branching Destination Node” (on left side of VSS Explorer)

                                                               i.      On right side of VSS Explorer, select file(s) e.g. File A

                                                             ii.      Menu –> Versions -> Branch

                                                          iii.      You  have Branched

1.      If you make a change in either project, no conflicts will arise.

2.      Physically there are two copies of the file in the VSS DB.

  1. Test Source and Destination Code Changes.
    1. Make changes to File A . from both Source and Destination projects,
    2. check in the changes in both Source and Destination projects
    3. note that there are separate versions with no conflicts
  2. Merge  Source into Destination Code Changes.

 

 

Some other guy’s Walk-through:

http://www.ezds.com/html/ss_admin_branching_projects.html

 

Branching SourceSafe Projects

 

The official Microsoft word on branching projects is '132923 Sharing SourceSafe Projects'.  It's on the lean side. I've added some more meat that hopefully will help you through the trauma of your first attempt at branching projects.

 

You and I might think it logical to start by specifying the source tree so that the software could check that such a thing actually exists and, gathering confidence as we go, move on to specify where we want to put the new tree. That's being too logical.. The actual sequence of events is ...

 

 

1-Destination Project Root | 2-Source Project Name | 3-Destination Project Name

1. click on the project UNDER WHICH the DESTINATION project tree is to be created. In this case we'll suppose we want to create the replicated tree off the root so select $/

 

2. Right click on $/ and click again on 'Share' on the menu.

 

3. On the 'Share with' dialog Select the head of the SOURCE project tree you want to branch. In this case select project Word 1.

 

You may want to check the [] Branch after Share checkbox, but for now just let's defer that. The dialogs we're trekking through are very un-intuitive. I'll get to the effect of checking that later.

 

4. Click the [Share] button

 

5.Now we're in a second 'Share $/Word1' dialog.

 

The system doesn't know what the name of the DESTINATION project tree is to be at this point. All it knows is that it's going to hang it off of the project you specified in 1. above.

 

In the 'New Name' field enter the name for the head of the DESTINATION project tree. In this case, since we're creating the DESTINATION project as a peer of $/Word 1 it can't have the same name, so let's call it Client2. However all the child projects will retain their original names.

 

6. Now IMPORTANT! check the [Recursive] box or all we'll get is $/Client2!

 

Enter in the comment box

 

 'I have lead a clean life, and I have backed up the database,

  and made sure I have at LEAST double the free space the current database takes up,

  and I have run analyze in the hope it will clean up the deleted files and any

  and all broken links in the tree

  and I truly believe that SourceSafe will recurse over the thousands of projects

  and files in the tree I want to branch without breaking and leaving a gawdawful mess.

  I do. I do. I do.'

Lastly place chicken entrails or rabbits foot to taste on the keyboard and

 

7. click on [Ok].

 

If and when the Status bar shows 'Ready' Click [Close] to exit the 'Share with ..' dialog. And go and have a cold one. You deserve it.

 

 

The Small Print

 

 If you think that this dialog sequence is .. awkward .. imho you'd be right.

 

 If you want to place the destination tree somewhere in the tree where it's not a peer to the source tree then the head source and destination names can be the same as there won't be a conflict.

 

 Don't specify a destination tree that overlaps with the source tree or you'll get "A project cannot be shared under a descendent" messages indicating that you're trying to do illegal recursion.

 

 Selecting the 'branch after share' checkbox has this effect:

 

If NOT SELECTED you'll see double document icons in the Client2 tree indicating that file appearances in the Word and Client2 trees are still only backed by one physical file in SourceSafe, so changes to one appear in both.

 

If SELECTED you'll see single document icons in the client2 tree indicating that each file is now backed by it's own physical file (the Client2 files were copied from the Word files which is why you made sure you have plenty of free disc space to accomodate the growth in the database size).

 

Pinning

If you want to refine the torture your brain has already endured, and assuming that you elected the 'Branch after Share' checkbox, then you might want to consider pinning.

 

In this case the files in the Client2 branched project tree have a separate history from now on, and can be modified at will without affecting the corresponding files in the the Word tree.

 

However it's quite likely that you don't want some, perhaps most, of the files in the branched tree to be changed, and you want to lock those down so they stay the same as the originals.

 

The SourceSafe term for locking them down.is 'Pinning'.

 

This is really a separate topic, but if you want to dip a toe in start here

 

 

Afterword

There's a good writup on Branching in Larry Whipple's excellent book 'Essential Sourcesafe'.

 

You'll find a link to it on the 'SourceSafe Third Party Tools' page.

 

When you do get to it click on the 'Search inside this book' link under the jacket image. When you get the next page scroll up the page to uncover 'Search [Inside this book]. Finally select the 'on Page 51' link.

 

I say this not to do Larry out of his royalties but to encourage you to try and buy the book. If you're a professional SourceSafe administrator i'd say it's pretty well ... essential.

 

MSDN:

 

Visual SourceSafe supports

·          sharing of files and projects

·          and branching of shared files.

Sharing a Visual SourceSafe file or project makes it part of two projects at the same time, for example, in a case where you want to propagate a bug fix between development projects.

To Visual SourceSafe, branching a shared file means breaking the shared link created when the file was shared.

Sharing Files or Projects

Visual SourceSafe has a Share command that allows sharing of files or projects. For use of the command, see How to: Share an Item.

When you request file sharing, Visual SourceSafe creates a shared link between the versions of the file in the projects that share the file. When you check in the file to one of the projects, your changes are automatically checked in to all the sharing projects. All the projects that share a specific file are listed in the Links tab for the file.

When you share a Visual SourceSafe project, you create a completely new duplicate project under the current project. All the files in the new project are shared with the corresponding file copies in the shared project, and changes in one are reflected in the other during check-ins to the Visual SourceSafe database.

Sharing has the following advantages:

·                     Makes it unnecessary for each project that uses the shared item to store a separate copy. This conserves disk space on both client and server machines.

·                     Because every project to which the item is shared uses the same version of the item, you avoid version incompatibilities that occur when each copy of an item is changing independently within multiple projects.

Branching Shared Files

Visual SourceSafe allows you to branch a shared file using the Branch command, available on the Versions menu of Visual SourceSafe Explorer. After branching, the file is independent, and changes made to it are not reflected elsewhere. Similarly, changes made in the previously shared file copy in the other project are not reflected in the branched file.

After you create a branch, the branched file and its counterpart in other projects have a shared history up to a certain point, and separate histories after that time. You can track the different branches on the Paths tab for Visual SourceSafe properties, and bring them back together using the Merge Branches command on the Tools menu. For more information about branching, see How to: Branch a File.

Sharing and Branching in One Operation

The Share command supports branching of a file immediately after sharing it. When you branch a file after sharing, the Links tab for file properties no longer shows a file relationship. However, you can use the Paths tab for file properties to see the path of the file branch you have created. For more information, see How to: Share and Branch a File.

See Also

Tasks

How to: Branch a File
How to: Share an Item

 

How to: Share an Item

Visual SourceSafe supports file and project sharing as described in Sharing and Branching. This topic provides some specific sharing procedures. To use the Share command, you must have the Check Out/Check In right in the project you are sharing from. You will need the Add/Rename/Delete right in the project to which you are sharing.

To understand sharing, consider a scenario in which your team develops a suite of tools that do different things but work on the same data format. All the tools are built around a common set of core code. You will store the specific files for each tool in its own project, but share the common files among all the tool projects. That way, any change made to a common file is immediately propagated to all the tools.

For example, the database group of the office tools team wants to add a spell checker. The word processing group already has a spell checker. The database group could just add the spell checker files to its project, but the two groups would not be connected. If the database team found a bug in the spell checker, the word processing group would have to duplicate the change. By sharing the files, both groups work with common source files and all changes are automatically seen by both projects.

To share an item using Share on the Versions menu:

1.                 In Visual SourceSafe Explorer, select a project to share a file.

2.                 On the Versions menu, click Share.

3.                 In the Share with <name> dialog box, use the File to share box to select the name of the file to share with the selected project.

4.                 If necessary, click View to look at the latest version of the file.

5.                 In the Projects box, choose the project from which you want to share the file.

6.                 Click Share to share the selected file.

To share an item 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.

See Also

Tasks

How to: Share an Item Using a SourceSafe Plug-in
How to: Share and Branch a File

Reference

Share with <name> Dialog Box (Explorer and Plug-in)

Concepts

Sharing and Branching

 How to: Branch a File

Visual SourceSafe branching for shared files is introduced in Sharing and Branching. This topic provides some specific branching procedures. See also How to: Share and Branch a File.

Note

When you branch a file and then delete the branched versions, the database does not recover space until all copies of the branched file in the database are destroyed.

Let's look at an example of branching. Suppose you are working on two programs for two clients. The two programs are virtually identical, but you want to tailor program behavior in one or two files. First, you share a project $/WORD to a new project $/CLIENT2. If $/WORD has subprojects, you recursively share them as well. You now have two projects that are identical in every way. Next, you select the few files you want to tailor in $/CLIENT2 and branch them. Now, when you modify these specific files in $/CLIENT2, your changes do not propagate to $/WORD. All the other files, however, are still shared between the two projects. If you modify any of the shared files, the changes will be propagated to $/WORD.

Here's another branching example. Suppose that after your project reaches version 3.1, development proceeds in two different directions. One team is working toward the next major release, the 4.0 version. The other team is working on a maintenance release, version 3.2.

You create a new project named $/PATCH to represent the 3.2 version. You branch all the files into it, using branching because you don't want the projects to track each other, since versions 3.2 and 4.0 are diverging, and changes made in one version are not automatically reflected in the other.

Later, you might want to merge the version 3.2 changes, for example, bug fixes or minor feature enhancements, into version 4.0. You can do this using the Merge Branches command. See How to: Merge File Versions.

To perform a basic branch operation:

1.                 Select the file(s) to branch in Visual SourceSafe Explorer.

2.                 On the Versions menu, click Branch.

3.                 On the Branch dialog box, type a comment in the Comment box to describe the Branch operation.

4.                 Click OK.

See Also

Tasks

How to: Merge File Versions
How to: Share an Item
How to: Share and Branch a File

Reference

Branch Dialog Box (Explorer)
Paths Tab (Explorer and Plug-in)

Concepts

Sharing and Branching

 

 

How to: Share and Branch a File

Visual SourceSafe's Share command supports branching of a file immediately after sharing it. When you branch a file after sharing, the Links tab for file properties no longer shows a file relationship. However, you can use the Paths tab for file properties to see the path of the file branch you have created.

Caution

Use the sharing and branching functionality of Visual SourceSafe with discretion. Try to avoid sharing or branching across top-level projects, since it complicates the process of archiving a project and restoring it into another database.

To share and branch using Share on the Versions menu:

1.                 In Visual SourceSafe Explorer, select the project to share and branch a file.

2.                 On the Versions menu, click Share.

3.                 In the Share with <name> dialog box, use the File to share box to select the name of the file to share with the selected project.

4.                 If necessary, click View to look at the latest version of the file.

5.                 Select the Branch after share check box.

6.                 Click Share to share the selected file and branch it afterwards.

To share and branch using drag and drop:

1.                 In Visual SourceSafe Explorer, right-click a file.

2.                 Drag the item over the receiving project and drop the item.

3.                 In the resulting menu, click Share and Branch.

See Also

Reference

Links Tab (Explorer and Plug-in)
Paths Tab (Explorer and Plug-in)
Share with <name> Dialog Box (Explorer and Plug-in)

Concepts

Sharing and Branching

 

 

How to: Enable Merging

 

Visual SourceSafe supports merging in a variety of ways, as described in Compare and Merge Mechanisms. The following procedure describes how to enable merging.

To enable merging in Visual SourceSafe Explorer

1.                 In Visual SourceSafe Explorer, on the Tools menu, click Options.

2.                 In the SourceSafe Options dialog box, click the General tab.

3.                 In the Use visual merge box, choose one of the following options:

Yes. Always use visual merging.

No. Attempt to do an automatic merge first and prompt to resolve conflicts manually only if there are conflicts.

Only if there are conflicts. Show the merge window if there is a conflict, and otherwise do automatic merge.

4.                 Click OK.

To enable merging using an initialization variable

1.                 Access your Ss.ini file.

2.                 If you want to use visual merging, set the Mark_Merges initialization variable to Yes. To use manual merging, set Mark_Merges to No.

3.                 Save the Ss.ini file and close it.

See Also

Reference

Mark_Merges Initialization Variable
SourceSafe Options Dialog Box, General Tab

Concepts

Compare and Merge Mechanisms

 

How to: Pin a Version

Visual SourceSafe pins versions as described in Version Control. When you pin a file version, Visual SourceSafe does not delete versions that are more recent than the pinned version. If you want to discard all the recent versions of the file, roll back to the pinned version as described in How to: Roll Back to a Previous Version.

To pin a version:

1.                 In Visual SourceSafe Explorer, select the file you want to pin.

2.                 On the Tools menu, click Show History.

3.                 In the History Options dialog box, click OK.

4.                 In the History of <name> dialog box, select the version that you want, then click Pin. A pushpin icon appears next to the pinned file.

5.                 Click Close.

To unpin a version:

1.                 In Visual SourceSafe Explorer, on the Tools menu, click Show History.

2.                 In the History Options dialog box, click OK.

3.                 In the History of <name> dialog box, select the pinned version, then click Unpin.

4.                 Click Close. Visual SourceSafe unpins the file so that the most recent version is the current version in the project.

See Also

Tasks

How to: Pin a Version Using a SourceSafe Plug-in
How to: Roll Back to a Previous Version

Reference

History of <name> Dialog Box (Explorer and Plug-in)

Concepts

Version Control

 

How to: Reconcile File Differences

As described in Compare and Merge Mechanisms, you can use either visual merging or manual merging for combining two file versions. This topic describes how to reconcile file differences using visual merge methods.

To reconcile file differences using visual merge:

1.                 Attempt a merge operation, as described in How to: Merge File Versions. Note that your merge operation must include the selection of visual merging for you to be able to see the visual merge window.

2.                 In the visual merge window, compare the database version in the left pane (marked SourceSafe) with your local version in the right pane. The bottom pane shows the differences that Visual SourceSafe has already been able to resolve.

3.                 In either pane, right-click to select a line and click Apply Change, Remove Change, or Apply Both Changes as needed.

4.                 Repeat step 3 for all the changes to reconcile. The merged version appears under Merged version in the bottom pane.

5.                 Click the Save button when you are satisfied with the merged version, and close the visual merge window. If there are any file differences that you could not reconcile, you must manually correct the files.

See Also

Tasks

How to: Merge File Versions

Concepts

Compare and Merge Mechanisms

 How to: Merge File Versions

Visual SourceSafe supports the merging of file versions as described in Compare and Merge Mechanisms. Merging occurs when you check a file in to the database, when you use the Get Latest Version command, or when you combine two branched file versions. If the database detects no merge conflicts, the merge operations are automatic.

Merging File Versions at Check-in

To merge file versions at check-in:

1.                 Choose the type of merging you prefer, as described in How to: Enable Merging.

2.                 Now select the file that you want to check in, and click Check In on the Versions menu. If you have questions about this operation, see How to: Check In Changes to an Item.

3.                 If there is a merge conflict, Visual SourceSafe notifies you. Resolve any merge conflicts as described in How to: Reconcile File Differences.

4.                 When the conflicts are resolved, you are prompted to check in the file. Click OK.

5.                 Examine the checked-in file to ensure that it contains merged changes.

Merging File Versions During a Get Latest Version Operation

To merge file changes during a Get Latest Version operation:

1.                 Choose the type of merging you prefer, as described in How to: Enable Merging.

2.                 On the Versions menu, click Get Latest Version. If you have questions about this operation, see How to: Get an Item to Your Working Folder.

3.                 If there is a merge conflict, Visual SourceSafe notifies you. Resolve any merge conflicts as described in How to: Reconcile File Differences.

4.                 When the conflicts are resolved, you are prompted to get the file. Click OK.

5.                 Check your working folder to ensure that the retrieved file reflects the merged changes.

Merging Two Branched Versions of a File

To merge two branched versions of a file:

1.                 Choose the type of merging you prefer, as described in How to: Enable Merging.

2.                 In Visual SourceSafe Explorer, select the file version to merge.

3.                 On the Versions menu, click Merge Branches.

4.                 In the Merge to <name> dialog box, use the Projects box to select the project that has the version of the file into which you want to merge changes.

5.                 Use the Comment box to enter an optional comment about the merge operation.

6.                 Click Merge to combine the file versions.

7.                 Click OK.

8.                 If there is a merge conflict, Visual SourceSafe notifies you. Resolve any merge conflicts as described in How to: Reconcile File Differences.

9.                 When the conflicts are resolved, you are prompted to merge the branches. Click OK.

10.             Check the database to ensure that the branched file versions have been properly merged.

See Also

Tasks

How to: Check In Changes to an Item
How to: Enable Merging
How to: Get an Item to Your Working Folder
How to: Reconcile File Differences

Concepts

Compare and Merge Mechanisms

 

 

Microsoft SourceSafe Frequently Asked Questions (FAQ)

 

http://support.microsoft.com/kb/q134369/

 

SUMMARY

This article covers some of the most Frequently Asked Questions (FAQ) about Microsoft SourceSafe.

MORE INFORMATION

1.

Q. Where is SourceSafe putting my files?

A. SourceSafe stores any files added to it in its DATA directory. The DATA directory is like a database, but only SourceSafe has access.

To create a network share to access files outside of SourceSafe, the Shadow directory is used. The Shadow directory is a read-only location you can use to build from or access the latest files stored in SourceSafe.

For additional information, please see the following article in the Microsoft Knowledge Base:

124529 (http://support.microsoft.com/kb/124529/EN-US/) How to Access SourceSafe Code from a Central Directory

2.

Q. How do I install SourceSafe on a network?

A. SourceSafe stores its contents like a database. All SourceSafe information shared by users will be in one location, the DATA directory. When the product is installed for multiple users, you want to install SourceSafe in a location where everyone has access. Typically, this location is a network server.

Users often want to have executables and other personal files on the local machine for speed purposes. This can be done with the following steps:

1.

Copy executables and Dynamic Link Libraries (DLLs) to the local directory.

2.

Set the environment variable SSDIR to point to the network installation of SourceSafe. For example: SET SSDIR=G:\SS.

Some additional optional steps are:

Make a copy of the SS\TEMP directory on the local machine. Set the variable Temp_Path in the SS.INI. For example: Temp_Path = c:\ss\temp.

Make a copy of the SS\USERS\<user name> subdirectory on the local machine. Set the variable for the desired user in the Users.txt file to point to the new location. For example: JOHN = c:\ss\users\john\ss.ini.

For additional information, please see the following articles in the Microsoft Knowledge Base:

130142 (http://support.microsoft.com/kb/130142/EN-US/) How to Install SourceSafe on a Windows NT Client Workstation

129112 (http://support.microsoft.com/kb/129112/EN-US/) How to Install SourceSafe on a Windows 95 Workstation

3.

Q. What is SSWCL.EXE?

A. SSWCL.EXE is the command line product for the Windows platform. This executable allows you to execute SourceSafe commands from Windows.

For example: the command SSWCL dir $/ -r displays the contents of the Root project ($/) recursively.

For additional information, please see the following article in the Microsoft Knowledge Base:

124526 (http://support.microsoft.com/kb/124526/EN-US/) SourceSafe: Using the Windows Command Line

4.

Q. What are sharing, branching, and merging?

A. Sharing is a unique feature of SourceSafe that allows you to access the same file from multiple projects. This feature is very beneficial for users who have several different projects that share common components.

All actions that take place on the file can be viewed from all projects the file is currently in. Therefore, a change made in one project will be reflected in all projects.

Branching, takes a shared file and "separates" it or breaks the link with it and the other projects it currently is in. At this point, changes made to the file will not be reflected in the other file(s). This feature is often used when there is a need for specializing a common file, often for language differences or customizing an application.

The Merge command allows you to merge any changes between separated files. This is often useful when a fix made to a branched file needs to be updated with the original project(s).

For additional information, please see the following articles in the Microsoft Knowledge Base:

132923 (http://support.microsoft.com/kb/132923/EN-US/) Sharing SourceSafe Projects

132971 (http://support.microsoft.com/kb/132971/EN-US/) Merging SourceSafe Files

132922 (http://support.microsoft.com/kb/132922/EN-US/) Sharing SourceSafe Files

132921 (http://support.microsoft.com/kb/132921/EN-US/) Branching or Separating SourceSafe Files and Projects

5.

Q. Where can I go for additional help?

A. The following documentation ships with Visual SourceSafe:

Manuals

Online Help

README.WRI

Additional sources of information include:

The Microsoft Knowledge Base:

129725 (http://support.microsoft.com/kb/129725/EN-US/) Obtaining Knowledge Base Articles on the World Wide Web

Microsoft Technet

Microsoft MSDN

If you need to contact Microsoft Technical Support, the following information will help the SourceSafe support engineers answer your question.

Version of SourceSafe. Identify whether you are using the GUI, Command Line, or Add-in product.

Operating System (Microsoft Windows 95, Macintosh System 7.5, and so forth).

If you are reporting a problem, identify the specific conditions or steps to reproduce the problem.

6.

Q. How do I send suggestions for product features or improvements to Microsoft?

A. Contact the Microsoft Wish Line at (206) 936-WISH [936-9474]. If it takes more than two minutes to describe, you can:

Fax the suggestion to us at (206) 936-7329 -or-

-or-Send a letter addressed:

Attn: Microsoft Wish
One Microsoft Way
Redmond WA, 98052
-or-

-or-You can access the following URL on the Web to send feedback for SourceSafe:

http://www.msdn.microsoft.com/ssafe (http://www.msdn.microsoft.com/ssafe)

Then, click the Submit Feedback button.

 

Posted on Wednesday, November 22, 2006 8:57 AM Visual Source Safe | Back to top


Comments on this post: Visual SourceSafe 2005 - Sharing and Branching

# re: Visual SourceSafe 2005 - Sharing and Branching
Requesting Gravatar...
I enjoyed reading your post. It's very engaging and quite useful for me. Wish to get some more information though.
Left by ted on Jun 17, 2010 9:41 AM

# re: Visual SourceSafe 2005 - Sharing and Branching
Requesting Gravatar...
BU GAI JIE SHU __ NAN QUAN MA MA ..
Left by burberry on Nov 12, 2010 2:27 AM

# re: Visual SourceSafe 2005 - Sharing and Branching
Requesting Gravatar...
Thanks for the useful post
Left by priyanak shah on Mar 30, 2011 12:22 AM

Your comment:
 (will show your gravatar)


Copyright © Rodney Vinyard | Powered by: GeeksWithBlogs.net