VSS alternative for one person show (army of one?)

I have been programming for 10 years for the same employer, and the only source control we have ever used is VSS. (Sorry - this is what they had when I started). There were only a few of us; two now, and we usually work alone, so VSS works fine for us. So, I have two questions: 1) Should we switch to something else, such as subversion, git, TFS, etc., What exactly and why (please)? 2) Am I really hopeless and doomed to an eternal damnation because VSS messed me up (as Jeff says)?

Wow - thanks for all the great answers!

Looks like I have to clean up a few things. We are an MS store (Gold parntner), and we mainly work with VB, ASP.NET, SQL Server, sharepoint and Biztalk. I have a CS degree, so I built x86 C, C ++ on Unix DEC, and Slackware Linux in "time crazy" ...

My problem with VSS is that now I am working more on VPN and suss VSS performance, and I am afraid that our 10-bit version of the VSS VSS database will be built ... There is a LAN service that should speed up work, but I never used it, and I'm not sure if it helps with corruption - did anyone use the VSS LAN service? (new from VSS 2005)

+12
version-control visual-sourcesafe
Aug 28 '08 at 3:40
source share
16 answers

I would probably go with Subversion if I were you. Right now I'm a complete Git fanatic, but Subversion certainly has some advantages:

  • Simplicity
  • plenty of compatible tools
  • active and supportive community
  • portable
  • Excellent integration with the Windows shell
  • integrates with visual studio (I think, but confidently through a third party)

Git has many, many other benefits, but the higher ones are usually those that people care about when asking general questions like the ones above.

Edit : The company I'm working with now uses the VisualSVN server, which is free. This makes installing the Subversion repository on a Windows server stupidly simple, and on the client we use TortoiseSVN (for shell integration) and AnkhSVN to support Visual Studio. This is not bad and should be fairly easy even for VSS users.

Editing the last days . So ... almost eight years later, I never recommended Subversion to anyone for any reason. I really do not renounce, as such, because I think that my advice was valid at that time. However, in 2016, Subversion retains almost no advantages that it had over Git. The tool for Git is superior (and much more diverse) to the fact that it once was, and in particular to GitHub and other good Git hosting providers (BitBucket, Beanstalk, Visual Studio Online, very close to my head). Visual Studio now has Git support out of the box, and in fact it is very good. There are even PowerShell modules to provide users with more familiar Windows features for console dwellers. Git is even easier to configure and use than Subversion, and does not require a server component. Git has become as ubiquitous as any single tool, and you really only fool yourself into not using it (unless you just want to use something non-Git). Donโ€™t get me wrong - itโ€™s not me who hates Subversion, but rather, I admit that it is a tool from another time, more like a straight razor for shaving.

+28
Aug 28 '08 at 3:44
source share

SubVersion seems to be the winner here. I would do a favor and use VisualSVN Server . It's free and saves you a ton of headaches.

+10
Aug 28 '08 at 4:20
source share

If you're used to how VSS works, check out (not a pun) SourceGear Repository . This is a great way to get away from VSS, as it comes with IDE integration and supports verification / registration, but when you are ready and comfortable, you can also move on to the style of fixing updates to programming updates contained in SVN.

It's free for single developers, runs on IIS and is built on .net, so you need to use a fairly familiar stack.

+9
Aug 28 '08 at 3:55
source share

Whatever you do, do not change for the sake of change.

If it works for you, and you have no problems with it, I see no reason to switch.

+6
Aug 28 '08 at 3:48
source share

For what it's worth, Perforce is a potential option if you really stick with 1 or 2 users. In the current documents, which indicate that you have 2 users and 5 clients, without the need to buy licenses.

You may have reasons to switch to perforce depending on your workflow, and if you need to fork, as perforce does. Without being too familiar with some of the other products mentioned here, I cannot tell you how perforce compares in the function department for things like branching, etc.

It's fast, and for us it was solid (more than 300 developers on a 10-year code base). We store several T information, and it was quite responsive. With a small number of users, I doubt that you will have many performance problems if you have good hardware for your server.

Using VSS before, I believe that you can get so many benefits from a better SCM system that switching should be considered regardless of whether you have corruption or not. Branching in itself can be worth it. A true client / server model, better interfaces (software and command line) are a couple of other things that can really help just improve the workflow and help a little performance.

In conclusion, my view on Perforce is this:

  • It is fast and reliable.
  • Many cross-platform client tools (windows, unix, mac, etc.)
  • it is free for 2 users and 5 clients
  • Integrates into the developer's studio (and other tools).
  • Has a powerful branching system (which may or may not be suitable for you).
  • It has several scripting interfaces (python, perl, ruby, C ++)

Of course, YMMV - I offer this alternative only as something that might be worth a look.

+6
04 Sep '08 at 15:31
source share

I recently started using Mercurial for some of my work. It is a distributed system such as Git, but it seems easier to use and seems much better supported on Windows, the latter of which is crucial to me.

With distributed source control, each user has a complete local copy of the repository. If you are the only person working on a project, as you say, often, this can simplify a lot, as you simply create your own repository and execute all your commits, etc. At the local level. If you want to attract other developers later, you can simply completely download the contents of your repository - current versions and the whole story - to another system, either to a shared server, or directly to the workstation of other users.

If you work only with local storage, remember that you will also need a backup, since your shared server does not have a copy of all your code.

I think that Mercurial has many other advantages over Subversion, but it has a big drawback, which was already mentioned as a Subversion plus point: there are lots of third-party tools and integrations for Subversion. Since Mercurial was not around almost like ong, the choice is much less. On Windows, it seems that you either need to use the command line (my choice) or TortoiseHg Integration with Windows Explorer.

+5
Aug 28 '08 at 6:45
source share

VSS is terrible. I can direct Spolsky (not sure if he said that), but using VSS is actually worse than not using source control at all. Despite its name, it is unsafe. This creates the illusion of security without providing it.

Without VSS, you are likely to make regular backups of your code. With VSS, you will think: โ€œFur, this is already under source control. Why bother with backups?โ€ Great, while corrupting your entire code base , and you lose everything. (By the way, this happened at the company in which I worked.)

Get rid of VSS as soon as you can and switch to a real version control solution.

+5
04 Sep '08 at 15:57
source share

Don't worry about VSS messing you up; worry about VSS corrupting your data. He does not have a good reputation in this department.

Backup often if you do not switch to another version control system. Backups should be performed daily even with other SCMs, but this is doubly important with VSS.

+4
Aug 28 '08 at 4:15
source share

I like to use Subversion for my personal projects. I could go down the list of functions and pretend that it brings a lot to the table, which is not in other version control systems, but there are many good and correct options - this is really a matter of style. If you register after each small change (i.e., with one check for a function change), many people can work with the same source file with a very low risk of merge conflicts in almost all , but VSS (I havenโ€™t used VSS in years, but from what I remember, only one person at a time can work on a file.) If this never happens to you, I feel that the best way to do this is to use what you know. VSS is better than no source control, but these days it seems limited to me.

I donโ€™t think you have anything to hope for, because you are asking if it would be better to switch; you are not hope when the answer is obvious, and you ignore the evidence.

Even if you do not change version control systems, you should choose one of them, for example, SVN or git, and spend several weeks reading this and make a small project using it; it always helps to sharpen the saw.

+3
Aug 28 '08 at 3:45
source share

I do not agree with people who say that if you have no problems, you better not switch.

I think that SCM is some of the disciplines that a good developer should know well, and to be honest, even if you are familiar with VSS, you are just experimenting with a small fraction of the benefits, and a good SCM tool and SCM strategy can do for you and for your team.

Obviously, first evaluate and test alternatives in a non-production environment.

+2
Aug 28 '08 at 7:51
source share

At work, we use subversion with TortoiseSVN - it works very nicely, but it is philosophically different from VSS (in fact, this is not a problem, if only you, but it's worth knowing). I really like that the whole repository has a version number.

Given the free choice, I probably left with storage, but at that time I had a zero budget.

I look at things for personal use. There are reasons to use subversion and reasons to use something completely different. The alternatives I consider are Vault (as before, free for one use) and Bazaar. GIT I had to fire, as I, shamelessly, a Windows person, and now GIT is simply not there.

The distributed nature of GIT and the possibility of private / temporary checks (provided that I understand what I read) is attractive - so I look at the bazaar.

Update: I did even more digging and playing, and I really went to Mercurial for personal use, the integrated installation with TortoiseHg makes things very simple and seem to be well regarded. I'm still trying to figure out how to get the automatic commit mirror to the server, and there seem to be some minor limitations to the ignore function, but it does work so far ...

Murph

+2
Aug 28 '08 at 8:17
source share

I would say stick to what works for you. If you have no problem with VSS, why switch? Subversion swells, although a bit sticky, to start using it. TFS is much better than VSS, although it is quite expensive for such a small team. I have not used git, so I can not talk to him.

+1
Aug 28 '08 at 3:44
source share

I used vss for many years until I switched to svn about two years ago. my biggest complaints about vss were poor network performance (this problem can be solved now) and pessimistic file locking. svn solves both of these problems, it is easy to configure (I use the collabnet server and the tortoisesvn client, although there are two good Visual Studio plugins: visualsvn - commercial and ankhsvn - open source), easy to use and administer, and well documented.

It's tempting to say โ€œif it doesn't break, then don't fix it,โ€ but you should learn a more modern source code management tool and, more importantly, new ways to use source control (for example, more frequent branching and merging) that the new tool will support.

+1
Aug 28 '08 at 3:58
source share

If you have only 2 people, and you mostly work independently, git will give you much more flexibility, power and be away from the fastest you can work with.

However, back pain is used. Using VSS, you obviously program for Windows - if you use the Win32 API in C, then git will be a learning curve, but it will be quite interesting.

If the depths of your knowledge apply only to ASP and Visual Basic, just use subversion. Go through before you can run.

** I'm not trying to say if you only know VB that you are dumb or something like that, but that git can be very thin and picky to use (if you used WinAPI in C, you all know about picky and subtle ), and you may need a more gradual introduction to SCM than git provides

+1
Aug 28 '08 at 4:28
source share

If you are a one-man show and strictly a Microsoft store, then SourceGear Vault is definitely the prime candidate for the switch.

Features:

  • Free for a single user, great for you
  • It uses SQL Server for this backend, so the data reliability is huge.
  • It has atomic checks, all files marked at the same time are located in a group and are called change sets.
  • VisualStudio Integration.
  • Has a tool to import from SourceSafe, so you can save your history
  • The client communicates with the server via HTTP, so access to the source outside the office can be very easily configured and performed well, because they only transmit deltas of submitted and received changes. You can use SSL to secure the connection.

I would definitely consider this as an option.

+1
Sep 04 '08 at 16:02
source share

If you need a full life cycle in one package, you probably want to look at the Visual Studio Team System. This requires a server, but you can get the "Action Pack" from MS, which includes all the licenses required for the "Team Foundation Server Workgroup Edition" from the Partner Center.

With this, you will get tracking of errors, risks and problems, as well as many other functions :)

  • Source control
  • Track work items (requirements, errors, problems, risks, and tasks)
  • Reports on your project data (work item tracking, assembly, verification, and much more in one quest mode)
  • Code analysis
  • Device testing
  • Load testing
  • Performance analysis
  • Auto build
+1
Sep 16 '08 at 11:38
source share



All Articles