What does your SCC system do (or not do) today you wish it would do differently?

I’m just curious.  What does your current SCC system do (or not do) today that you wish it would do differently?  Have you developed plug-in or custom tools on top of it to get your work done?  If you tell me what your top gripes or wishes are, perhaps I can tell you how or if we do things differently in Team System Version Control.

I know I’m kinda fishing in the dark here, but let’s give it a try…

Comments (11)

  1. Charles Chen says:

    SCC Plugin for Visual Studio and TortoiseSVN:


    Subversion GUI client (including a diff GUI):


    KDiff3 (alternate diff GUI, looks very feature rich):




    Subversion documentation (very well done and complete, taking into account common usage scenarios for developers and admins):



    ** the ability to build a working copy from several different repositories (http://svnbook.red-bean.com/en/1.1/ch07s03.html),

    ** linking single files to a different branch (http://svnbook.red-bean.com/en/1.1/ch04s05.html),

    very complete (and well documented) branch operations (http://svnbook.red-bean.com/en/1.1/ch04.html),

    ** lots of extra goodies like script hooks (http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1),

    ** automatic token replacement (svn:keywords limited predefined token set) (http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.4),

    ** arbitrary custom properties (which are versioned as well, see previous),

    ** HTTP and WebDAV support using Apache as a proxy (http://svnbook.red-bean.com/en/1.1/ch06.html#svn-ch-6-sect-1) or,

    ** Custom server for network access (http://svnbook.red-bean.com/en/1.1/ch06s03.html),

    ** Database (BerkeleyDB) or file system representation (http://svnbook.red-bean.com/en/1.1/ch05.html#svn-ch-5-sect-1.3)

    ** Highly performant (see the docs for details)


  2. BarryBo says:

    1. True Revision Control instead of just source – efficient storage of binaries, from .EXEs and .DLLs to .LIBs and .OBJs. Sufficient to be able to use the RCS as the release point for daily product builds, and to enable fast incremental builds without first needing a full build.

    2. Offline support. Subversion’s is good, but disk-space-intensive.

    3. Clients for multiple platforms.

  3. bonder says:

    Synchronization across distibuted team environment (servers in different locations).

  4. 1) How SCC handles repeatable merges of the trunk to a branch ?

    2) How the merge operation handles renames from either side (trunk or branch) ?

    3) Can the branch after several merges, be merged back to the trunk with a single command?

    We currently use Subversion and the above are not very well implemented

  5. I think I’ve mentioned some of these before 🙂 I’m not listing things I already know TSTF *does* do right, because that list would be pretty long.

    – Offline mode. I want the *full* power of version control (minus those bits that you simply can’t get without a full copy of the repository) while offline. Branching, reverting to repository version, shelving, etc. It would be nice to have a kind of "offline checkin" or "checkpoint" feature that would let me mark a version that I could then revert to in the future, even though you obviously can’t really check in while offline. When I reconnect to the server everything ought to sync up perfectly, because there’s absolutely no reason for the system to be wilfully unaware of the stuff I did while offline. CVS is old and doesn’t do much of this, but even what it did is much better than it seems TSTF will in the first iteration. And you can do a lot better than CVS did if you really want to do it right.

    2) Work with older VS versions. These aren’t going to go away anytime soon – why should people be forced to maintain multiple source code repositories just so they can work on projects that aren’t migrated yet? This is a huge deal and I honestly can’t understand how you got this close to shipping without lots of prospective users screaming. I understand that SS2005 will work with older versions, but SS doesn’t do half of what TSTF does.

    3) This is probably well-supported already but *please* make sure that TF is scriptable and automatable. A .NET API, direct ScriptingHost access via CreateObject(), and a good commandline client (whose output is designed from the ground up to be machine-readable as well as human-readable, unlike ss.exe) are all good ideas.

    That’s about it for my wishlist, because most of the things I wanted I already know that TSTF *does* do, and gets them right. Moving to TSTF (from SS) will certainly be a vast, vast improvement for my team, but without these things (especially the first two, which I’ve heard from reliable sources that TF is *not* going to do) there’ll still be major source-control-related frustration…

  6. Mike Weiss says:

    I started to post a whole list of things… but honestly in comes down to this:

    I want Perforce, or a system w/ feature parity w/ it.

    However, my little "pet" feature of SCM systems in what CVS call the "Annotate" command.

  7. Dave Bost says:

    We have built a custom tool that sits on top of Visual SourceSafe (currently) to help us manage source code promotion. You can read more here:



  8. Phil Issler says:

    One of the things I really miss from my Smalltalk/ENVY days is the ability to browse code versions at the class or method level, instead of only at the file level. Obviously, this requires language-specific extensions to the base source code control system, allowing it to recognize and track elements of the code DOM. For example, one often wants to do something like "find the previous revision of this method", which requires some meta information about which file revision contains a different definition of that method. VisualAge for Java also worked in this way. In the same vein, my ideal system would allow one to flexibly define a versionable code base, and would allow granular diff of all affected code elements between versions of that code base. I realize that some kind of compartmentalization would have to be enforced to allow this, since it is rare to find a real-world software project that only contains artifacts in a single language. Perhaps files containing a supported language like C# or VB.NET would enjoy the full feature set, while all others would fall back on lowest common denominator (i.e. file version tracking) functionality.

  9. Source control for Database objects, Stored procedures, UDF’s etc…

    And I don’t mean ‘database project’.

  10. The biggest dissapointment with VSTS and Visual Studio 2005 as of the December preview is the diff utility.

    The implementation in Eclipse and IntelliJ are both much better – the way that different panes are kept in sync and the way differences are shown in a visually appealing but clear way.