A problem about binary file source safe versioning
Does anyone of you ever try to check in your binary files for versioning? We have this habit since the day when we work on VB projects. Since COM versioning is very important, we have very clear habit to keep different versions of the DLLs.
Now in .net, with VS.NET 2003, we realize there is a very strange behaviour which prevents binary files checking from working properly.
Lets say, we have 3 projects:
ClassLibrary1, ClassLibrary2, WindowsApplication1
-->: reference
ClassLibrary2 --> ClassLibrary1
WindowsApplication1 --> ClassLibrary1, ClassLibrary2
When I have checked out all WindowsApplication1 binary files, while leaving ClassLibrary1 and ClassLibrary2 binary files as read only, I would not be able to compile WindowsApplication1. A message saying it cannot find ClassLibrary1 and ClassLibrary2 reference. The cause behind is when VS.NET tries to build WindowsApplication1, ClassLibrary2 is triggered to be build as well, which is not possible since ClassLibrary2 is read only. However, practically I never changed any source codes inside ClassLibrary2, so in fact its not making sense to rebuild that project.
Thus, if I keep checking in the binaries I have a hard time to build files.
I would recommend creating another configuration that does not build ClassLibrary1 and ClassLibrary2. Here's how:
Build... Configuration Manager... Active Solution Configuration dropdown... <New...> Give it a name and which template to copy from. Then uncheck the "Build" checkbox for ClassLibrary1 and ClassLibrary2. If you do make any changes to ClassLibrary1 and ClassLibrary2, you'll have to switch to the config that builds them as well as check out the binaries from VSS.
No that doesn't work. Try to do the following:
1. Create new configration (e.g. 'Final')
2. Build
3. Check in all binaries
4. Check out WindowsApplication1 binaries in Final
5. Build again- it is successful, notice the read only files in ClassLibrary1 and ClassLibrary2 are overwritten.
6. Check in WindowsApplication1 binaries
7. Get all binaries to make it back to read only again
8. Close VS.NET
9. Open VS.NET again, check out WindowsApplication1 binaries
10. Build again
Dada.... same problem happen again....
Someone from MS can tell us what to do?
I tried your scenario and it worked just fine. Make sure you have you set your configuration to "Final" before selecting (re)build solution. Also your ClassLibrary1.dll and ClassLibrary2.dll will be overwritten in WindowsApplication1\bin\Debug as WindowsApplication1 copies those dependencies into its output directory as part of the build process. You want to check in the binaries from their original compile location. (i.e. ClassLibrary1\bin\Debug)
To be honest, it is generally not a great idea to check binaries into VSS as versioning of binary files is poor in VSS. Each check-in of a binary file is a completely new version even if only a single bit has changed. (Subversion, Vault, and other source control products do a much better job with binary files. You get real diffs even on binaries.)
If you're looking for recommendations from Microsoft, read "Team Development with Visual Studio .NET and Visual SourceSafe":
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/Tdlg_rm.asp
Sometimes its necessary to check-in a binary if you receive a binary from a 3rd party, and have no control over the source, and need to maintain version compatibility.
 James Kovacs wrote: |
| Each check-in of a binary file is a completely new version even if only a single bit has changed. (Subversion, Vault, and other source control products do a much better job with binary files. You get real diffs even on binaries.) |
|
How does Team System work with binaries? What about VSS 7?
Team System does just store the diffs (although this is a storage space optimization only), but VSS7 doesn't.
One would have throught that it would be the other way around! So VSS7 works similar to the way that Subversion works, using a binary diffing algorithm to transmit and store successive revisions.
My understanding is that VSS7 is simply some enhancements of the existing VSS6 codebase that makes it more network friendly. I don't believe they have made any substantial improvements to the way that data is stored. With VSS, text files are versioned by storing the latest complete file and diffs to regenerate previous versions. However binary files are stored as complete copies on every check-in, even if only a single bit in the file has changed. (i.e. If you have a 50 KB JPG and modify a single pixel, you'll take up 100 KB of disk space for the two versions of the file.) Subversion, Team System, and Vault (among others) store diffs of both text and binary files. If you can avoid using VSS, I would highly recommend it. Whoops! I misread what Matthew Watson said - he did say what you've just clarified. Anyway, that's what I would have expected.
I've migrated all of my work from VSS6 to Subversion, and it works a treat. It'd be good if there was a UI tool similar to the VSS Repository Explorer, but I've found SmartSVN, and it does the job.
I do miss the VSS recursive Directory comparison tool, and although WinDiff has such a feature, it can't really be integrated with Subversion, because a local version of every directory of SVN's latest version (highest version/HEAD) would have to be stored in one directory locally.
Anyway, a bit off topic.
Thanks for the reply. 
You may also want to have a look at RapidSVN (http://rapidsvn.tigris.org) as it has a lot of similarities to VSS Explorer. Personally I use TortoiseSVN (http://tortoisesvn.tigris.org), which is awesome. One complaint I do have about SVN is that it is a bit 'NIXy for your average Windows developer and the error messages are not always clear.
Yeah - I checked them all out, and made a list of the tools that I use here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=287570&SiteID=1I found RapidSVN too, and although it looked good, and worked reasonably well, it didn't have an option for changing its internal working directory from ".svn" to "_svn" as required(?) by .NET web projects. So I use SmartSVN instead, which handles that well. ... even though it's written in Java... (Read into that statement what you will!)
I agree that TortoiseSVN is pretty good, so I wrote a .NET VS.NET add-in to use the Tortoise SVN commands (diff, repo browser, check for modifications etc.) instead of using Ankh SVN.
'NIXy's not so bad - you never know when you might need one of those extra command line switches to solve some problem that you never knew you had!
Being 'NIXy isn't so bad for me since I've worked with a wide variety of 'NIX environments over the years. (Although the last 5+ years have been predominantly Windows in its various flavours.) My complaint with being too 'NIXy is I often want to introduce REAL version control (i.e. not VSS) to clients and SVN is a bit too 'NIXy for a straight Windows shop. Yes, you can host your SVN server on Windows, but it's not completely straightforward. Bringing in a Linux or other 'NIX box for version control is often a no-no. I just want a real version control system that is as comfortable and easy to use as VSS as well as free. Vault by SourceGear is very good, but isn't free.
I suppose the fact that SVN is free and open souce means that its development direction is somewhat haphazard. It also be said, however, that the its direction is dicated by where people want it to go (and are prepared to spend their unpaid time developing for it).
I think all of the hooks are in the right place, just a nice layer of paint, and a few bug fixes (and perhaps a bit more integration between products - eg. clients), and it'd all work well. The clients (ie. repository interfaces) shouldn't really be competing with each other, as there's nothing to gain - except perhaps a bit of prestige (my product's better than yours), but from what I've read, that doesn't seem to be the case.
It seems many-a-time the case with software that you'll get a product that meets nearly all of your needs, except for one or two critical factors (I've got the SVN product that you mentioned in mind, with its inability to support the '_svn' directory).
I would have to agree. SVN stands to be a phenomenal product, except for a few limitations that really hold it back from being a slamdunk on the Windows platform:
- No integration with Windows security (Active Directory or NTLM). This is a major pain because I've now got to manage users in another place. I've seen authentication for SVN implemented using LDAP and AD can expose itself via LDAP. Unfortunately this requires additional setup. Also I haven't seen SVN do authorization (i.e. you can read from branches, but you can't create one), only use LDAP for autentication (i.e. who the heck are you).
- Quirky versioning issues. I've often had problems with repositories created with previous versions working seamlessly with newer versions of the client. Maybe it's just me, but I've often had to dig through documentation and/or google to get my old repositories working again. I'm a developer. So I understand the need to occassionally make breaking changes. I would appreciate some upgrade tool or even batch file so I don't have to dig through the inner workings of SVN just to be able to browse my old repos.
I would wholeheartedly agree wit your opinion regarding competing UIs. They really serve no purpose other than to fragment the available free developer bandwidth to develop them. (I could say the same thing about the plethora of Linux distros, but I don't want to start a flamewar. But just for a second imagine if everyone working on a Linux distro started investing his/her efforts in a single one. Microsoft just might have a competitor then.) :)
