MS SourceSafe 8 (yes, really)




  • A few weeks back my department re-organized. Along with splitting into separate divisions, each division now has a separate SourceSafe repository. It's more organized that way.

    Today, I logged onto another division's SS database to look at a project. I used the "guest" account, which is read-only. I checked out a project and looked at it in VS2005 (yes, really). When I return to MY project in VS2005 it has now set the VSS binding to use the guest account, so I can't actually check out any files to actually, you know, do work. The only fix I've found is to drop the project binding, then re-bind them. It's not that big of an inconvenience, except that this could potentially repeat every time I have to look at a project that resides in a different SS database.

    WTF #1: Changing the login credentials for a project without prompting me first.
    WTF #2: Changing the login credentials for a project that is bound to a different SS database. Yes, this database has a guest account with the same password. No, it is not the appropriate thing to do.



  •  You know what they say: Visual Source Safe ... isn't.



  • What's wrong with Source safe? I have never had a well maintained source safe database lose code.
    Except when you are running a rapid development cycle with multiple developers, remote developers, where time stamps are not synchronized between all dev machines AND the source safe database, and it was imperative we get things done quickly.

    OK.. never mind.



  • @KattMan said:

    What's wrong with Source safe?
    Usability.



  • @Sutherlands said:

    @KattMan said:
    What's wrong with Source safe?
    Usability.
    Okay, man. Slow down. Smell the code offsets. There's a last sentence in that post as well. Can you dig it, man?



  • @Ben L. said:

    @Sutherlands said:
    @KattMan said:
    What's wrong with Source safe?
    Usability.
    Okay, man. Slow down. Smell the code offsets. There's a last sentence in that post as well. Can you dig it, man?
    I can, but I apparently misread "except" as something closer to "even"



  • You have to forgive Sutherland, if it isn't written by him or spelled out, or part of his world it is obviously total crap. Apparently he can't even note the sarcasm no matter how clear I tried to make it.
    Sutherland, It's along the lines of "this paper is garunted to always keep you dry, except for when it rains".



  • @KattMan said:

    You have to forgive Sutherland, if it isn't written by him or spelled out, or part of his world it is obviously total crap. Apparently he can't even note the sarcasm no matter how clear I tried to make it.
    Sutherland, It's along the lines of "this paper is garunted to always keep you dry, except for when it rains".
    Wow, you can't even spell my name but accuse me of not being able to read?  Did you miss the previous post where I admitted I misread one word, which changed the entire tone of the post?

    What a douchebag.



  •  Sourcesafe is very good for a basic, rudimentary 1.0 release of a source control application, and has been that way for its entire history.



  • @dhromed said:

     Sourcesafe is very good for a basic, rudimentary 1.0 release of a source control application, and has been that way for its entire history.

    I agree to some extent, but there are two features from VSS that I liked that I have never been able to understand how to mimic in (for example) git. This is probably more my lack of understanding of git, but perhaps someone can explain how to ..

    1. Span the project under control across physical sub-directories, but maintain it as a single project (DVCS' seem to be "single directory" orientated)
    2. Share the same file between two separate projects (eg a client/server app pair)

    This stuff is trivial in VSS, but every time I have looked into it with git I come away with a head-ache and the thought that I'll take another look at it again in a few months time.

    But having used VSS for a long long time (and supported commercial products that use VSS as their backing store) I am well aware of what you should and should not use VSS for. It works well as a single user repository on a local machine, and in using it that way I have never had a single issue with corruption. It was never really designed to be a client/server multi-user system across a network and I suspect that is where the corruption factor comes in.



  • @OzPeter said:

    @dhromed said:

     Sourcesafe is very good for a basic, rudimentary 1.0 release of a source control application, and has been that way for its entire history.

    I agree to some extent, but there are two features from VSS that I liked that I have never been able to understand how to mimic in (for example) git. This is probably more my lack of understanding of git, but perhaps someone can explain how to ..

    1. Span the project under control across physical sub-directories, but maintain it as a single project (DVCS' seem to be "single directory" orientated)
    2. Share the same file between two separate projects (eg a client/server app pair)

    This stuff is trivial in VSS, but every time I have looked into it with git I come away with a head-ache and the thought that I'll take another look at it again in a few months time.

    But having used VSS for a long long time (and supported commercial products that use VSS as their backing store) I am well aware of what you should and should not use VSS for. It works well as a single user repository on a local machine, and in using it that way I have never had a single issue with corruption. It was never really designed to be a client/server multi-user system across a network and I suspect that is where the corruption factor comes in.

    1. What, exactly, do you mean by this? A tree can only have one root. That's where .git (or .svn or whatever) lives. If you want to VC multiple directories, just create a folder to contain both of them, and make it the root.
    2. Why on earth would you do this? What happens if the file changes in one repo but not the other? Or changes in both? If you really want to do this, you should break it out into a third project separate from both. (Unless, by "Project" you mean a VS Project, in which case that has nothing to do with source control (and, indeed, is trivial to do))


  • @pkmnfrk said:

  • What, exactly, do you mean by this? A tree can only have one root. That's where .git (or .svn or whatever) lives. If you want to VC multiple directories, just create a folder to contain both of them, and make it the root.
  • Why on earth would you do this? What happens if the file changes in one repo but not the other? Or changes in both? If you really want to do this, you should break it out into a third project separate from both. (Unless, by "Project" you mean a VS Project, in which case that has nothing to do with source control (and, indeed, is trivial to do))
  • Yeah, this sounds like a bad idea to me, too. If multiple things share something, then abstract it to a library that gets its own source tree, configuration management, etc., and they can share those things as they like.

    In any case, the svn approach to this is probably vendor branches. I don't see why this wouldn't work with DVCS (and would probably be easier, to boot).



  • @OzPeter said:

    Share the same file between two separate projects (eg a client/server app pair)
     

    That seems unwise on an epic scale.



  • @pkmnfrk said:

    What, exactly, do you mean by this? A tree can only have one root.
     

    VSS "projects" are folder-like items that map to a physical directory, which is called the Working Folder. You can make a project Foo that doesn't correspond to a directory, and inside that have two sub-projects, perhaps a webservice and a website, and map them to different directories. These two VSS folders are of course the roots of their projects, and from there on everything's predictable. It's a matter of terminology, mostly.

    Point is that VSS's folder tree is not the same as the directory structure.



  • @boomzilla said:

    Yeah, this sounds like a bad idea to me, too. If multiple things share something, then abstract it to a library that gets its own source tree, configuration management, etc., and they can share those things as they like.
    So a header file that contains definitions that need to be shared between a client and a server project get abstracted out to their own library? That seems a bit excessive.



  • @dhromed said:

    and map them to different directories.
    Not mapping the VSS structure to the physical directory structure is asking for trouble.

    But I was asking about a controlling a physical structure that is in a directory tree, and having it treated as a single project.



  • @OzPeter said:

    @boomzilla said:
    Yeah, this sounds like a bad idea to me, too. If multiple things share something, then abstract it to a library that gets its own source tree, configuration management, etc., and they can share those things as they like.

    So a header file that contains definitions that need to be shared between a client and a server project get abstracted out to their own library? That seems a bit excessive.

    Maybe "library" is the wrong term here. But, yes, if you really want to share between them, and it's something that actually belongs in source control, I'd give it its own repository, and then it's a dependency on the project to configure it. Of course, different languages / tool chains have different setup and configuration requirements.

    Obviously, I was generalizing. What is the header file for? Does it ever change? Is there a reason that the client and server are separated? Do they just share that one header? If it never changes, maybe it's OK to just have it in two places.

    Different tools have different paradigms, and so I guess that maybe the way you were set up to work with VSS isn't appropriate for most VCSes. But it's still kinda smelly to me.



  •  @Evilweasil said:


    A few weeks back my department re-organized. Along with splitting into separate divisions, each division now has a separate SourceSafe repository. It's more organized that way.

    Today, I logged onto another division's SS database to look at a project. I used the "guest" account, which is read-only. I checked out a project and looked at it in VS2005 (yes, really). When I return to MY project in VS2005 it has now set the VSS binding to use the guest account, so I can't actually check out any files to actually, you know, do work. The only fix I've found is to drop the project binding, then re-bind them. It's not that big of an inconvenience, except that this could potentially repeat every time I have to look at a project that resides in a different SS database.

    WTF #1: Changing the login credentials for a project without prompting me first.
    WTF #2: Changing the login credentials for a project that is bound to a different SS database. Yes, this database has a guest account with the same password. No, it is not the appropriate thing to do.

    The fact that Microsoft won't even use (or support?) Source Safe any more should clue you in as to how bad it is.  Is there some reason that you can't at least use Team Foundation Server which replaced VSS sometime [url=http://msdn.microsoft.com/en-us/library/aa302182.aspx]around 2005[/url]?

     



  • @OzPeter said:

    But I was asking about a controlling a physical structure that is in a directory tree, and having it treated as a single project.
     

    ?

    There is no other way of doing things.

    You mean other VCS's can only treat files in the same directory as a single project? That can't be right.

    I'm having trouble deciphering your words.



  • @powerlord said:

    The fact that Microsoft won't even use (or support?) Source Safe any more should clue you in as to how bad it is.  Is there some reason that you can't at least use Team Foundation Server which replaced VSS sometime around 2005?

    I will suggest it to the department manager. Fingers crossed.



  • @boomzilla said:

    Obviously, I was generalizing. What is the header file for? Does it ever change? Is there a reason that the client and server are separated? Do they just share that one header? If it never changes, maybe it's OK to just have it in two places.
    And doing so brings up the old saying of "A man with one watch always knows what time it is, but a man with two watches never knows". If you can't easily define fundamental information for a system in one location (imagine control codes defining messages passed between systems), then you increase you risk by bringing a human into the loop in order to ensure consistency. And systems should be built to mitigate risk imposed by humans.



  • @dhromed said:

    You mean other VCS's can only treat files in the same directory as a single project? That can't be right.
    I'm not saying that I am right, but that is the sense I get about git. That you seem to build a repository on a per directory basis and that everything including the kitchen sink goes in there. I'm happy to be proved wrong by someone.



  • @OzPeter said:

    @boomzilla said:
    Obviously, I was generalizing. What is the header file for? Does it ever change? Is there a reason that the client and server are separated? Do they just share that one header? If it never changes, maybe it's OK to just have it in two places.

    And doing so brings up the old saying of "A man with one watch always knows what time it is, but a man with two watches never knows". If you can't easily define fundamental information for a system in one location (imagine control codes defining messages passed between systems), then you increase you risk by bringing a human into the loop in order to ensure consistency. And systems should be built to mitigate risk imposed by humans.

    Yes I agree with all of that, and I don't think my post contradicts it at all. Everything is a trade off. As it stands, I cannot figure out what, exactly, you can do with VSS but not other things. Your apparent walk back:
    @OzPeter said:

    Not mapping the VSS structure to the physical directory structure is asking for trouble.

    But I was asking about a controlling a physical structure that is in a directory tree, and having it treated as a single project.

    ...has me really confused about what you're doing. It seemed like the whole thing was based on not mapping the VSS structure to a physical directory structure. Perhaps the key is what your definition of "single project" is. In svn, you can check out a working copy from anywhere within the directory structure of the repo (and, of course, this is all that branches, tags, etc are). DVCSes that I'm familiar with only allow you to check things out at the root of the repository, though you can actually nest repositories (at least with mercurial, and I'd be surprised if you couldn't do that with git).


  • @OzPeter said:

    I'm not saying that I am right, but that is the sense I get about git
     

    I was talking about only the file items immediately inside tha dir, not any subdirs. And you don't seem to think so, so let's end this thread before it gets overconfusing.

    @OzPeter said:

    That you seem to build a repository on a per directory basis and that everything including the kitchen sink goes in there.

    Now I understand.

    I doubt recursion is forced on you, but I haven't used anything else.

     



  • @boomzilla said:

    Perhaps the key is what your definition of "single project" is.
     

    ding ding ding



  • @OzPeter said:

    @dhromed said:
    You mean other VCS's can only treat files in the same directory as a single project? That can't be right.
    I'm not saying that I am right, but that is the sense I get about git. That you seem to build a repository on a per directory basis and that everything including the kitchen sink goes in there. I'm happy to be proved wrong by someone.

    That's definitely how Github's client works. The only way to get it to ignore files is to add it to a TEXT configuration file. Unchecking a file during check-in will prevent it from being part of that check-in, but it'll still bitch that you have uncommitted changes afterwards.

    Oh and even worse, that configuration file doesn't actually seem to work until its checked-in as well. So if you have a "rogue" file in your folder tree, you have to temporarily move it somewhere else, update the ignore file, do a check-in with NOTHING BUT THE IGNORE FILE, then move your file back and cross your fingers and knock on wood that Git is now properly ignoring it.

    It's fucking irritating as shit.

    By the way, reading this thread has been great at showing the groupthink in the development community. "VSS is nice because it can do those two things nothing else (well, except TFS) can do". Next 26 replies? "YOU ARE CRAZY why would you do those things YOU ARE AN INSANE CRAZYPERSON Linus Torvalds says a repository can only be in one directory YOU CAN NOT GO AGAINST LINUS TORVALDS YOU INSANE CRAZY PERSON OMG OMG OMG!!!"



  • @blakeyrat said:

    By the way, reading this thread has been great at showing the groupthink in the development community. "VSS is nice because it can do those two things nothing else (well, except TFS) can do". Next 26 replies? "YOU ARE CRAZY why would you do those things YOU ARE AN INSANE CRAZYPERSON Linus Torvalds says a repository can only be in one directory YOU CAN NOT GO AGAINST LINUS TORVALDS YOU INSANE CRAZY PERSON OMG OMG OMG!!!"

    Are you reading the crazy alien thread? Or did they whisper this stuff to you exclusively. Because I don't see any of that here.

    You know, there used to be a guy around here who liked to talk about how "Reading is FUNdamental." He was totally right about that. You should try it.



  • @boomzilla said:

    ...has me really confused about what you're doing.
    In hindsight I think was not as clear as I should have been. Starting with:

    • VSS Repository Root maps onto a physical directory root
    • VSS internal "folder" layout is mapped 1-to-1 onto physical directory tree structure, including sub-directories (doing other wise can cause you pain). Also VSS maps logical files in the repository to physical files on the disk
    • Some where down in the VSS folders you have the VSS project "A" (which also corresponds to some physical directory for "A")
    • In another VSS folder that is not a parent/child of "A", you have the VSS project "B"
    • Both "A" and "B" have files in sub-directories (both in VSS and in the physical directory structure)


    Now for my two questions:

    1. In VSS it is easy to say that the sub-directories of "A" and "B" include files for the respective projects. I'm not sure that this concept translates well to the DVCS systems that I have seen (such as git). My understanding about DVCS' is that by default control a single directory and if you want to include sub-directories in a repository then you have to jump through hoops

    2. In VSS I can say that a file in project "A" is the same VSS logical file in project "B". Not a copy, but the same VSS "object". So that it doesn't matter if you are editing the file in "A" or "B" you are still editing a single file. Given that DVCS' are not monolithic by definition, it seems that the only way to transfer this concept across is to jump through hoops to create project "C' that contains the files that contains the data that needs to be shared between "A" and "B". That has a bit of a smell to me as now the information is actually divorced from the the projects that use it. But even so I still can't see how you would share things like constants (e.g. #defines) between "A" and "B" using a third project.


    BTW I'm not putting down DVCS', they are streets ahead of VSS in things like branching and have enabled me to things I never could have done in VSS, and I wouldn't want to go back. I'm just puzzled how I should mapping concepts mentioned above from VSS to a DVCS. Fortunately in what I have been doing since moving to a DVCS based system I have not had to implement those above concepts.



  • @boomzilla said:

    Because I don't see any of that here.
     

    The common pattern "this maligned tool it lets me do this! // that's weird you should probably not do that" is pretty well-demonstrated in the second half of this thread.



  • @OzPeter said:

    In VSS I can say that a file in project "A" is the same VSS logical file in project "B". Not a copy, but the same VSS "object".
     

    I never understood this linking. It seemed like an overcomplication. I never investigated it very much either, though. It's called Sharing, i.o.w a file-item or folder-item can appear in a completely different VSS folder, and even has the typical Windows shortcut overlay icon.

    @OzPeter said:

    My understanding about DVCS' is that by default control a single directory and if you want to include sub-directories in a repository then you have to jump through hoops

    I thought you earlier said that they include everything and the kitchen's sink, while VSS allows you to limit inclusion easily. The latter is true, the former may or may not be, but it would really odd if it were true.

    STOP CONFUSING ME.

     

     



  • Boomzilla you are a terrible horrible person.

    @boomzilla said:

    Are you reading the crazy alien thread? Or did they whisper this stuff to you exclusively. Because I don't see any of that here.

    It's obvious hyperbole. There also weren't 26 posts, that was an exaggeration. But that's ok; I know you know this. You're only pretending to be a fucking dumbfuck because you want to get me angry and because you are a terrible horrible person. Kindly die.



  • @OzPeter said:

    In VSS it is easy to say that the sub-directories of "A" and "B" include files for the respective projects. I'm not sure that this concept translates well to the DVCS systems that I have seen (such as git). My understanding about DVCS' is that by default control a single directory and if you want to include sub-directories in a repository then you have to jump through hoops

    Ah. Yes, I think for Mercurial, you'd put a whole new repository in place of A and B. I've never done this, but I know that the docs talk about this.

    @OzPeter said:
    In VSS I can say that a file in project "A" is the same VSS logical file in project "B". Not a copy, but the same VSS "object". So that it doesn't matter if you are editing the file in "A" or "B" you are still editing a single file. Given that DVCS' are not monolithic by definition, it seems that the only way to transfer this concept across is to jump through hoops to create project "C' that contains the files that contains the data that needs to be shared between "A" and "B". That has a bit of a smell to me as now the information is actually divorced from the the projects that use it. But even so I still can't see how you would share things like constants (e.g. #defines) between "A" and "B" using a third project.

    OK, here's where I'm confused. Where is this file? You talked about the importance of the VSS logical structure matching the physical structure. Where is this shared file (let's call it H)? I can imagine a few scenarios:

    1. H is in A or B in the VSS logical structure, and you must have both checked out and the one that doesn't contain it must have its build setup configured to be able to find H.
    2. H is outside of either A or B in the VSS logical structure, and you must have H separately checked out and both A and B must have its build setup configured to be able to find H.
    3. H is outside of either A or B in the VSS logical structure, but you can have VSS check H out into either A or B, which breaks the 1-1 correspondence between VSS and your working copy.

    Each one of these seems to contradict what you said, so there must be something I'm not getting about this.

    @OzPeter said:
    BTW I'm not putting down DVCS', they are streets ahead of VSS in things like branching and have enabled me to things I never could have done in VSS, and I wouldn't want to go back. I'm just puzzled how I should mapping concepts mentioned above from VSS to a DVCS. Fortunately in what I have been doing since moving to a DVCS based system I have not had to implement those above concepts.

    Yeah, I get that. I just don't understand VSS well enough to see what you're really doing. And common code like this can be a bitch, so I'm interested in learning new ways to deal with it.


  • Winner of the 2016 Presidential Election

    I think he basically has two hardlinks to the same file in VSS, and wants to do that on a DCVS.



  • @blakeyrat said:

    Boomzilla you are a terrible horrible person.

    @boomzilla said:

    Are you reading the crazy alien thread? Or did they whisper this stuff to you exclusively. Because I don't see any of that here.

    It's obvious hyperbole. There also weren't 26 posts, that was an exaggeration. But that's ok; I know you know this. You're only pretending to be a fucking dumbfuck because you want to get me angry and because you are a terrible horrible person. Kindly die.

    Shhh...the adults are having a conversation. Feel free to join if you come up with something relevant to say.



  • @boomzilla said:

    Ah. Yes, I think for Mercurial, you'd put a whole new repository in place of A and B. I've never done this, but I know that the docs talk about this.

    And I love the first line of that page "This is considered a feature of last resort." I'm dealing with git (thanks Apple) and they have their own set of caveats Subproject Support
    @boomzilla said:
    H is outside of either A or B in the VSS logical structure, but you can have VSS check H out into either A or B, which breaks the 1-1 correspondence between VSS and your working copy.
    I would say that this is the best description. But as someone else mentioned, the linked files are like filesystem links, so H is in A and is in B. But as VSS is a centralized system you are basically trained to do always get a tree before you do a clean build anyway, so the inconsistency doesn't matter (or is short lived)
    @boomzilla said:
    And common code like this can be a bitch, so I'm interested in learning new ways to deal with it.
    I just keep scratching my head over it and hoping someone will figure it out for me. I can handle the concept of symbolic links from a file in one location to another location, but I feel I'm out of my depth when even the DVCS people say "there be dragons". I suppose I need to do some intense revision someday.



  • @OzPeter said:

    @boomzilla said:
    H is outside of either A or B in the VSS logical structure, but you can have VSS check H out into either A or B, which breaks the 1-1 correspondence between VSS and your working copy.

    I would say that this is the best description. But as someone else mentioned, the linked files are like filesystem links, so H is in A and is in B. But as VSS is a centralized system you are basically trained to do always get a tree before you do a clean build anyway, so the inconsistency doesn't matter (or is short lived)

    OK, that makes sense. Personally, I dislike the misdirection done with H. I probably would want to treat H as an external dependency for both A and B. In some ways it's less convenient, but the clarity is attractive to me.



  • @OzPeter said:

    1. In VSS it is easy to say that the sub-directories of "A" and "B" include files for the respective projects. I'm not sure that this concept translates well to the DVCS systems that I have seen (such as git).

    With Git (and other DVCS's) you should probably create a separate repository for each project.

    @OzPeter said:

    My understanding about DVCS' is that by default control a single
    directory and if you want to include sub-directories in a repository
    then you have to jump through hoops
     

    You can have as many subdirectories as you want in DVCS's, so I don't know what you mean. Just add them like any other file. Specifically, if you want Git to recognize them as separate subprojects, you might want to use Git submodules, but in my experience it isn't usually necessary.

    @OzPeter said:

    In VSS I can say that a file in project "A" is the same VSS logical file in project "B". Not a copy, but the same VSS "object". So that it doesn't matter if you are editing the file in "A" or "B" you are still editing a single file.

    I use filesystem symbolic links to accomplish (I think) what you want when using
    Git. So one file is the real file, and the other "copy" is just a
    symlink to the first. Then just check them in this way. You can do it
    with folders as well if you like.

    @OzPeter said:

    Given that DVCS' are not monolithic by definition, it seems that the only way to transfer this concept across is to jump through hoops to create project "C' that contains the files that contains the data that needs to be shared between "A" and "B". That has a bit of a smell to me as now the information is actually divorced from the the projects that use it. But even so I still can't see how you would share things like constants (e.g. #defines) between "A" and "B" using a third project.

    Yes it is "divorced" from A and B. It is modularized, in a way that maps directly to your directory structure. It only takes seconds to make a directory into its own repository, so I can't really call it jumping through hoops.

    Using submodules (or by simply putting project C in the directories for A and B, or a sibling directory) you can share your #defines. Just add project C's directory to your include paths in A and B. It's exactly the same as if you were using someone else's library that might not even be using Git at all.

    But don't forget -- you can always just have one big Git repo with subdirectories for projects if that's easier for you. If you control the whole superproject then I think it's a good solution.

     

     



  • @OzPeter said:

    In VSS it is easy to say that the sub-directories of "A" and "B" include files for the respective projects. I'm not sure that this concept translates well to the DVCS systems that I have seen (such as git). My understanding about DVCS' is that by default control a single directory and if you want to include sub-directories in a repository then you have to jump through hoops

    It sounds like you're talking about what Git calls "submodules" (and other SCMs may call "externals").

    @OzPeter said:
    In VSS I can say that a file in project "A" is the same VSS logical file in project "B". Not a copy, but the same VSS "object". So that it doesn't matter if you are editing the file in "A" or "B" you are still editing a single file.

    Again I think you can probably mimic this with submodules.



    For the record though, submodules were considered Wrong and Evil back when we were all using CVS and they were called "externals", and I don't think the reasons behind that have changed.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.