Related
Our dev team uses VS.NET for app development and TortoiseSVN/VisualSVN for version control. It seems that almost every day issues arise with the working copy or the repository getting screwed up, and folks just throw up their hands and call me when it happens. There are definitely human factors at work (SVN works as it should) but I'm tired of playing SVN helpdesk to the dev team. Can anyone recommend a better/more intuitive setup for version control?
Agent SVN works well for me. It integrates nicely with Visual Studio.
SVN is about as simple as version control systems get. Problems should only arise when dealing with merging operations...those can be tricky.
If you don't address the "human factors" it won't matter which version control system you use, you will always be the helpdesk. To address these kinds of problems, you typically need to:
Set up a wiki with common "recipes" for version control tasks.
Include a workflow diagram for how changes are made to your code (for those who don't like to read).
Host a training session that is specifically
designed for your users (use the wiki
material).
When helping someone with a problem, be sure to make them perform the actual fix. Don't just do it for them, talk them through it instead.
Make a point of directing users to product documentation when helping them.
Introducing a new version control system into any organization should include the items I listed. I realize it is extra work for those who get it done, but it does save you from long "support" hours down the road.
Can anyone recommend a better/more intuitive setup for version control?
Better? Yes. More intuitive? That's debatable. Look into distributed version control software, namely Mercurial or Git. Both have freely available plugins to integrate with Visual Studio. And if you can manage spending a little money, I've heard very good things about Fog Creek's Kiln.
As for your issues with SVN, I have a couple tips. The first is to make sure you keep everyone synced on the same version of the product. It tends to update frequently, and so this can be tricky, as you also don't want to fall too far behind the current version. The second is that we used to have big problems with Tortoise trying to cache icon overlays on mapped network drives. There is an option you can turn off somewhere that suddenly made things way more stable. But that was at my last job, and I don't remember the exact setting any more.
I think you already gave the answer in your question - sort out the "human factors" by providing appropriate training. Version control for software development doesn't get much simpler than SVN, so from the way your question is phrased, my guess would be that said human factors are just going to find other ways of making your life interesting.
if you have issues with your repository getting screwed (like committing on tags, wrong commit messages...), one of the easiest way is to play it the hard way : put hooks on the server to enforce policies. You can have a look in official documentation.
Basically, this is an easy way to enforce naming / formatting and avoid a lot of human issues (committing on tags, messing with externals...)
There's no shortage of traditional version control software, but I'm looking for something that doesn't require me to constantly commit. In other words, I am searching for background software that automatically keeps a history of all files in a directory. If possible, I would also like to be able to add commit notes myself for benchmarks later on.
I have no preference on whether or not the solution is a web service or a local service that I host myself, as long as it is free or has a reasonable one-time fee (no subscriptions please). Performance and Hard Drive Usage are not issues.
I hope that I'm not being too specific with my request. I searched the web for solutions, but I could not find any software that does what I want. For compatibility, I have Windows 7 64-bit and an AMD processor.
You should consider Dropbox. It's not strictly version control software, but it runs in the background and syncs your files to the cloud.
They give you 2GB of storage for free (more if you pay a subscription), and from their website, you can view the different versions of the files in your Dropbox folder.
I don't know of any software or services that do this.
I did come up with a quick idea though
This idea seems like a bit of a hack and it is right off the top of my head (so issues may come up in implementing).
Create an app/service that uses the FileSystemWatcher to detect changes/creation/deletion to the location(s) that you want to version.
When a detection is made, do [bat/cmd/powershell/code/ect] that uses the command line (or other) interface of [insert version control software here] to do a commit.
I think it's fairly straight forward. I think it's easy to implement, but that's the danger of 'top of the head' ideas. A direction to look for rolling your if nothing else. :)
I don't know of any stock solutions, but depending on your IDE/Make system, you should be able to create a postbuild event that commits the files to your "regular" version control system after a successful build (the version control system will need an external API or CLI for this to work). You can then add commit notes, etc. in the version control system at your leisure.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am a very new programmer, I have made a couple basic applications, however I was told that it would be good to get used to using "source control" at the near the beginning of learning so I get accustomed to it. I have gathered that source control is what is used to manage programs with multiple programmers and that it is somehow connected directly to my projects in Visual studio. I also believe there are two primary versions, "TFS" and "SVN". Past that I am fairly lost, I am not sure what I need to actually implement this, specifically how I would do so on my personal projects. Also I don't know what program(s) are needed.
Should I use TFS or SVN?
What program(s) do I need to install?
How do I implement them in Visual Studio?
Is it a good habit to get into for my personal programming or would you disagree?
Please go ahead and open up wikipedia, you have a bit of reading to do:
Revision control
Subversion
With that reading done, you should have a better understand of what source control is. As a programmer, I'm pretty sure you'll find it makes sense to "save" what you're working on, making changes incrementally and being able to go back to those changes.
In a nutshell, revision control is the ability to go back in time, so that you can read code you have written at that moment.
Ok first there are many source control products other than the two you have mentioned but I would get used to SVN first.
TFS is expensive and tied into the Microsoft stack.
I'd start with reading this:
http://svnbook.red-bean.com/
Specifically the chapter on fundamental concepts
Yes this book is tied in to svn but it covers the basics too.
When you have read that download TortoiseSVN. This is an svn client that hooks into your windows shell. Only when you are comfortable with using this would I then move on to an integrated svn client. (I actually don't use one) AknhSVN is free.
The source control system is separate from your IDE. You can use it from the command line, or from a graphical client as well as from your IDE.
What you should know about a source control system is this:
you save your increment changes to the SCM (source code management), and each save receives an unique id/revision
you can retrieve any revision on any time, therefore changes are never lost
this gives you the liberty to delete unused code, debug info, or to refactor existing functionalities
and most importantly, it gives these functionalities to all members of a team, so that the team can work at the same time on the same code base, from their own development machines
You could start with svn, as it's very popular (especially for open source projects) with widespread support. You can gen the command line client from here:
http://subversion.tigris.org/
This is a nice graphical interface (windows):
http://tortoisesvn.net/
This is a free book to help you start with svn:
http://svnbook.red-bean.com/
If you need to setup a server on your development machine, this tutorial should help:
http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/16/Setting_up_a_Subversion_Server_under_Windows.aspx
check out Git and think about hosting your projects on https://github.com/ - also, check out linus talk on git: http://www.youtube.com/watch?v=4XpnKHJAok8
there are many different source control providers including TFS, Subversion (SVN), Perforce, CVS and Visual Source Safe to name but a few. It is also one of those areas that people tend to get semi-religous on, so I'll tread carefully!
I think most people would agree that Visual Source Safe is not the way to. It is fairly simple as a source control system but would do little to teach you about source control in general. TFS, SVN and Perforce tend to get pretty good feedback from their users.
Out of these, SVN is the only one that is free, so if you are planning to do this as a learning exercise, I'd be inclined to start there [actually I believe you can get a free 2 user license for Perforce too, but I'm not 100% sure on that). You can learn all the basics with this, as well as more advanced areas such as branching and merging.
If you do give it a go, I recommend you download SVN itself, and the TortoiseSVN client for Windows Explorer (I'm assuming you are on Windows here as you mention Visual Studio). You may also want to look at source control integration into Visual Studio, in which case I use VisualSVN (there is a free trial), but there is another popular one whose name eludes me (someone will hopefully add it as a comment).
Additionally there is a great, free, e-book for SVN, available (here)
Overall - to answer your specific questions:
Should I use TFS or SVN?
SVN
What program(s) do I need to install?
SVN itself (the server) and TortoiseSVN
How do I implement them in Visual
Studio?
Use VisualSVN or another SVN for Visual Studio client. You don't need this to learn source control, but it is well worth trying it out from in the IDE.
Is it a good habit to get into for my
personal programming or would you
disagree?
Yes, definitely!
Good luck, and hope you enjoy getting into source control.
Of the source control systems I've used Subversion with Tortoise is my preferred choice (I've used VSS, Subversion (SVN) and TFS).
Subversion has some excellent documentation on how it works and also on the general concepts of version control so that you actually understand what you are doind and why.
If you want to set up Subversion on a Windows stack then by far the easiest way is with VisualSVN which is free. The client side plug in to Visual Studio, however, is not free. But there are many free alternatives such as Tortoise.
You should not usually host your own subversion/git/whatever server. It is time consuming and error prone. For small projects subversion and git hosting can be found for free, and give you offsite backup, the ability to work from anywhere and the ability to add offsite programmers to a project with ease. If your needs grow, you can pay a small monthly fee.
You can use a google search to find candidates. The one I use is http://unfuddle.com.
I found this article to be very clear. (It recommends SVN).
So I've decided it's probably best if I get some Source Control solution going to keep my hard work safe, and to help eradicate bugs between versions.
I'm familiar with SVN as far as checking stuff out, but I have NFI about the committing side of things.
What is a good Source Control solution, keeping in mind that I develop in Visual Studio on Windows? Should I get a hosted solution, or host it myself on my own server (running Windows Server '03)
I'd suggest using git and get Git Extensions for better Windows integration.
If you're just getting started and are looking to self-host, I suggest VisualSVN. It's a lightweight, extremely easy-to-use SVN server, and free. I've used it for small projects at work and home. It includes security, with folder- and file-level ACLs based on local or Windows users.
You may decide later to move to more powerful servers or an externally-hosted solution; you can just dump the repository from VisualSVN with the standard svnadmin tools and load it into something else very easily.
For the client side of things, I use TortoiseSVN and love it, and I understand Ankh has gotten better since last I used it.
Use git.
One workflow that git does really well:
Have an idea for some feature you want to implement
Create a new branch for that feature
Write code, commit like crazy
When you're done implementing, squeeze all the crazy commits into one big patch
Commit that patch against your main branch
Delete the for-that-one-feature branch.
This is wonderful to have. You can have multiple parallel branches for this, and it's really easy.
As an additional feature, if your project goes public and you use git, people who check out your code will have an easy time making their own changes to (their copy of) your code, version-controlled and all, and it'll easy to track upstream at the same time.
If not git, try some other distributed source control system and see if it does good branching and local commits as well.
We are a small team (seven people) we have been using a hosted solution (hosted-projects.com) for more than one year. It's cheap and has worked very well for us. We use tortoiseSVN for the clients.
The main advantages of a hosted solution are:
no need to worry about server setup and maintenance
remote hosting means we have a complete and up to date backup of our code on a remote location
very fast
I recently did a team development thing and we just hosted subversion on one of our workstations and it worked... passably. We used visual svn on the server, and tortoiseSVN on all of the clients (and I occasionally connected my macbook using Versions, SVNX, or the command line). Merging is the really hard part... we had a lot of trouble with that (resolved, once again, with some command line skill). I also set up my own subversion server on my linux workstation for personal use, which worked better (merges were smoother, only one developer). Overall, it has been fairly easy and merging is probably the largest problem you'll face.
If your new to source code then I would recommend you read Eric Sink's series on Source Control. It doesn't really cover distributed source control but it's still a very good primer.
I personally use Perforce. They allow up to two uses for free for home and small business use. It is a little expensive compared to others but there is reasons why companies like Google and Symantec use it. It has ok to good Visual Studio support.
I really like hosted solution because often comes with other tools like trac to manage your project timeline and bugs control.
I recommend projectlocker or codespaces
Assuming that I'm starting a new web project at home using Visual Studio, which version control system, viz. Git or Subversion will be better to use? Which one will have the least setup complexity?
Since this is for your own personal playing around, my question is simple: Do you know Subversion or Git already?
If you know SVN - use Git.
If you know Git - use SVN.
If you don't know either - use SVN. It's a better introduction.
I'd go with Git. It's not that bad getting up to speed on the basics (there are now a ton of good resources, including learn.github.com) and it'll pay off in spades. And I've been using it on Vista with no probs.
Subversion is far more Windows-friendly in my experience and also more immediately useful for the solo developer.
Another possibility is Perforce, which is slightly less Windows-friendly, but full featured and fairly easy to use, not to mention free for up to two users.
Git is a distributed source control setup and as you are the only user I can't imagine that you would benefit much from its features. Subversion is (in my opinion) easier to set up so I would recommend you go with it.
If you are working alone and want some kind of version control easy to use, then use Subversion.It works great on Windows, setting up the repository is one right click in an empty with Tortoise SVN. Ankh SVN provides a very good integration with Visual Studio - almost on par with TFS provided you use VS 2005 or more recent.
On the other hand, Git is much more promising than SVN. I'll check it during this year, but third party tools are not on par yet.
I'd go with Mercurial instead. It's supposed to be similar to Git (which I never could get running because of the Windows issue) and is really easy to setup in Windows & very nice for "personal" version control systems.
Which one you decide to use depends a lot on what your needs are now and going forward. Git has a very nice community built a round it with GitHub which is great for sharing code and projects. SVN is pretty simple to setup and get going, but in large teams Git has it beat hands down with it's branching and merging. This is ideal in cases where you have multiple people working on the same project, either in an office setting or an OSS sense where the team is spread out.
If all you need is something quick and simple to setup and get going so you can start your project, SVN should be fine. SVN is also integrated into many editors and IDE's as well as many bug tracking and continuous integration systems.
If you plan on having a team, or already do, Git is worth looking at for its branching and merging setup. Git however, due largely to still being kind of young, doesn't have nearly as much support available
If you want Visual Studio integration there is no question. Only Subversion has Visual Studio integrations (AnkhSVN, VisualSVN and several scripts that allow access to TortoiseSVN).
One of the most important reasons that Subversion has such a large amount of tools written for it is that it was designed as a stable library for use by multiple clients.
It's unlikely that Git gets the same level of integration in Visual Studio before git support is available as some kind of reusable library. (There are plans for a libgit2 that could make this a reality).
Let's my ride-in on your question and ask:
Does Git work on Windows?
Does it have something that's equivalent to Tortoise? (otherwise I don't see how it could compete with SVN in terms of ease-of-use)
On a side note: If it's really a one man home project, you don't really need any source control tool. Just put your project in a DropBox folder and you're done (auto-commits, infinite revisions, undelete).
Unless you really think you're going to need tags and branches and stuff. But for personal home projects... do ya?
You can make your own opinion after reading this : http://whygitisbetterthanx.com
Git................................(these dots are there because SO wont accept a 3 lettered answered).
A great answer to this question was recenting written about by Jack Repenning here:
If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree)
Neither of those? Take your pick, you should be fine with either tool.*
Full Blog Post here: http://blog.codesion.com/post/15692788883/subversion-or-git-decisions-decisions
With SVN you will have to set up a server, create a repository there, check out the (empty) repository, add your files, and then commit.
With Git, all you need is git init in your project's root directory. Then you can add and commit files as you see fit.
There's not really any idea in setting up a Subversion server, since you're the only one working on the source. Contrary to what many people think, solo projects is a perfect match for distributed version control tools. It's also very easy to grow your project later on.
In my experience, Subversion is easier to "grok", but Git is faster and easier to engage in software development best practices. As a former CVS user, Subversion made immediate sense to me when I started using it. Git took some study and I still have to refer to the manual from time to time, but I love how easy it is to branch and merge code when I've got to maintain a release process.
If you are already familiar with CVS and just need something to keep your history and diffs, Subversion will be easier to get started with. If you are new to version control, the tide is shifting toward DVCS in general and Git in particular, so you may get more mileage out of that in general.
I do recommend you look at a hosted provider so you don't have to worry about setting up a Subversion server or so you can have a backup location for your Git data. You can Google for "subversion hosting" or "git hosting" to see the premier providers in the space.
If you plan to take your project along on an USB stick, use Subversion. Windows XP it really, really, really bad at caching lots of small files on an USB stick. Git writes many small files for commit operations and that takes ages on Windows.
[EDIT] The problem with Windows XP and files on an USB stick is caching (or the lack thereof). To prevent data loss, XP will always write files synchonously on an USB stick (so any write will come back only after the FS has reported that all blocks have been written to the stick). Add that to the fact that USB sticks are slow when handling small files (they have a lot of overhead initializing their wear level management) which leads to very poor performance for any kind of application which writes lots of small files.
[EDIT2] If you put a SVN checkout on the USB stick, you will also have a lot of small files (especially in the .svn directories). So the solution in this case is to put the Subversion repository (the "server") on the USB drive. The repository uses only a bunch of big files (if you use the database option instead of the file based one: svnadmin create --fs-type bdb). This avoids the "many little files problem". There is no way to achieve the same thing with current versions of Git.