Pin: the “Share my greatest, not my latest” Feature in VSS
If you code like me, your latest version of a file or project is almost never your greatest. Wouldn’t it be nice if you could just mark a version of a file or changeset as “use this one!” so that your teammates would stop bugging you about “issues” with the latest version?
If you use SourceSafe, you can. I call it the “Share my greatest, not my latest” feature but the economical developers of VSS decided to call it “Pin”. No, not Personal Identification Number (PIN). In this case, we mean “pin” like a pushpin. It’s called a “pin” because pinning a particular version of a file or project in VSS is like hanging it on a bulletin board for public consumption.
In Visual SourceSafe, you can “pin” a specific version of an item (a file or VSS project folder) in order to:
- Lock, or preclude checkouts of an item in a database where multiple checkouts are enabled.
- Trick your teammates into thinking that the pinned version of a file or project is the latest, or tip version of the item while you continue to work on later and perhaps less stable versions.
It is this second scenario that I explore in this blog post.
Background
When you Get an item from a SourceSafe database, the most recently created version of that item, often referred to as the “tip version”, is copied from the database into your local working folder by default. However, when you Get a file or VSS project that is pinned, it is the pinned version of that item and NOT the most recently created version of the item that is copied down to your local working folder. Tricky, tricky, eh?
Pins vs Labels
A Pin serves the same general function as a VSS Label. Whereas a pinned version is gotten implicitly, you must explicitly request that a labeled version be copied to your working folder during a Get operation. The other differences between pins and labels worth noting are: 1) you can only apply one pin per item but you can label as many versions of that item as you want and 2) labels have names like “beta 1” whereas pins do not and most importantly 3) You can Check Out a labeled item but you cannot Check Out a pinned item.
How To: Work on the Latest Version but Share only the Greatest Version
The canonical pinning scenario involves two developers—let’s call them Mark and Juan—who have been tasked with writing a simple text editor with a built in spellchecker/grammar checking component. Mark writes the editor while Juan works on the spell/grammar checker.
On the eighth day of development, Juan checks in a sterling component (spellgrammar.cs) that is practically bug free but only checks for spelling errors, not grammar mistakes. To celebrate the occasion, Juan pins the latest version, ver. 8, shares spellgrammar.cs from its project ($/spellgram/m1) into a second project, $/spellgram/m2, goes home early, and opens a nice bottle of Chilean carmenere.
The next day, Juan checks out spellgrammar.cs from the m2 project folder and starts working on the more complex grammar checking features. Over several days, he creates ver. 9, 10, 11, and so on. By ver. 12, neither the grammar checker nor the spellchecker are working and Juan reluctantly checks in a version of his component that does not compile.
Later that day, Mark wants to test his editor with the latest and greatest version of Juan’s spelling and grammar checking component. Mark performs a Get of what he believes to be the latest version of Juan’s component. Behind the scenes, Visual SourceSafe copies version 8 of spellgrammar.cs from $/spellgram/m1, which is the pinned version, rather than the tip, ver. 12, which Juan is editing in $/spellgram/m2. Mark compiles his project and Juan’s spellchecker works like a charm.
On the 14th day of development, Juan finally checks in a decent version of his component that identifies both spelling and grammar errors. He checks his changes into $/spellgram/m2, creating version 14, opens the $/spellgram/m1 project in VSS Explorer, Shows History for the original spellgrammar.cs, and UNPINS the file.
Magically, all of the changes that Juan made to his component in the M2 project folder are ported into the M1 project folder. The next time Mark gets Juan’s component from the $/spellgram/m1 project folder, he retrieves a version that checks both spelling and grammar.
To Pin an Item in Visual SourceSafe Explorer
- Right-click the item and then click Show History…
- In the History Options dialog box, click Ok.
- In the History of <Item> dialog box, select the version you want to designate as your “latest and greatest” version, and then click Pin.
To Pin an item Visual Studio .NET
- Select the item in Solution Explorer
- Click File, click Source Control, and then click History…
- In the History of <Item> dialog box, select the version you want to designate as your “latest and greatest” version, and then click Pin.
To Pin an Item from a Command Prompt Or in a Batch File
- Type “SS Pin $/ SpellGrammar.cs –V8”, where SpellGrammar.cs is the name of the file and 8 is the version of that file you want to pin.
Big Red Note Sharing is bassackwards in Visual Studio. Don’t ask why ‘cause I don’t know. If you share a source-controlled solution or project inside Visual Studio, please read my post on sharing beforehand: How To Use VSS' Share Command in VS.NET.