Freigeben über

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

  • Artikel

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

  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.

  • Anonymous
    February 14, 2005
    Synchronization across distibuted team environment (servers in different locations).
  • Anonymous
    February 14, 2005
  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
  • Anonymous
    February 14, 2005
    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...
  • Anonymous
    February 14, 2005
    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.




  • Anonymous
    February 14, 2005
    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:


    http://davebost.com/blog/archive/2004/06/04/182.aspx

    http://davebost.com/blog/archive/2004/07/08/183.aspx
  • Anonymous
    February 15, 2005
    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.
  • Anonymous
    February 15, 2005
    Source control for Database objects, Stored procedures, UDF's etc...

    And I don't mean 'database project'.
  • Anonymous
    February 15, 2005
    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.