We are a small team (undergraduates) works on some freelance projects. we need to have a SVN. how could i do this? how does it work? do i need a dedicated server? or could it be done with a virtual server? Please clarify me.
Thank You.
uberSVN has a nice web interface if you want something easy to administer
If you are not familiar with Subversion, you might be, in your circumstances, better off reading up on Git. Git is a distributed version control system and one of its main advantages is that each user has a full copy of the repository. This means that your repository doesn't have to be up on the Internet at all times.
Another big advantage of Git is that you can submit patches (what Git uses for Source Code Changes) without a network. You simply create a patch, which can be transfered via email, a patchfile sitting on public file area like Dropbox, or even a USB thumb drive that's passed back and forth. In fact, you can trade patches with anyone and not with the main repository.
That means if you have four users, User A and User B can trade patches back and forth in one project while User B and User C can trade them back and forth in another project. In the end, you can all submit the changes to User D who would have all the changes.
If you can't use Git, Subversion works well in many circumstances. It'll work on virtual servers, and can use multiple protocols for communication. The simplest is probably the _svnserve` that comes with Subversion. You can setup basic security with svnserve very easily. Subversion is very light weight, so it takes up little processing bandwidth.
SourceForge is the most widely known free Subversion hosting site. Google Project Hosting is also a good Subversion hosting provider. Or, if you already have a system that's sitting on the Internet, you could just run svnserve and do your own hosting from that.
If you have your own system, and feel like being really fancy, you can use httpd to run Subversion under http or https.
Take a look at the on line Red Bean Subversion manual on the Web. It's one of the best open source documents around.
If you're a complete beginner, and don't want to learn the ins and outs, go with a hosted service. Many have free offerings like http://beanstalkapp.com or http://xp-dev.com/
Here's an SO question discussing many of the hosted providers
https://stackoverflow.com/questions/69384/opinion-of-hosted-svn-providers
It would run fine on a virtual server, it has very little overhead. Here's a quick tutorial on setting it up on Windows (since you tagged it Windows).
The easiest way to install Subversion on Windows is to use VisualSVN server. It integrates into your services and provides a nice GUI for management.
Whether you should use VM or a real PC highly depends on your usage. VM has very limited resources and therefore might introduce lags on heavy usage (large projects > 50mb, frequent commits and checkouts, frequent polling). For less than 20 developers VM should be just fine.
Related
I have a team of developers that all work remotely, from home (no intranet or extranet). We have dedicated managed hosting through a hosting provider, and they do not offer TFS. The production web and sql server are behind firewall at host and prevent remote connection outside their network. We connect via SFTP and/or VPN.
We're developing in ASP.Net MVC, VS 2012, and I'm looking for suggestions on source control options for this type of environment.
Any feedback is appreciated.
I really like Distributed Version Control Systems for stuff like this. Mercurial is my favorite, for no particularly good reason other than I learned it first.
This allows your remote staff to have essentially a full copy of the source tree on their workstations which really eliminates any friction that is introduced in a remote system due to network pokiness.
The downside is that you have to be on top of the source control management, by ensuring that only mature change sets are promoted into build streams, and reducing conflicts with various changes. Depending on how you look at it, this could be a benefit because it forces you to do something you probably ought to be doing anyway: keeping close tabs on the changes.
Now, for hosting, you can use a lot of different services. I have used Bitbucket, others use GitHub, but there are plenty of others, or you can host your own. I have found that hosting Mercurial internally is not any more difficult than hosting anything else that needs to be backed up.
Good luck!
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
I there a Visual SourceSafe server running somewhere that I can connect to for practice? I have a couple of things that I would like to test before buying the VSS server but I don't want to download the whole app for testing.
Best regards
short answer: save your time and don't buy. Use SVN, git or if you are all for an ms solution then use Team Foundation Server.
There are lots of people who love to hate on VSS, and honestly I can't blame them (much). VSS has a reputation for being unstable, corruptable, and idiosyncratic. This reputation, in some cases, is well deserved, in others it's a case of improper management, improper administration, or improper too choice for the job.
VSS is not the tool for everyone, but it is an adequate tool for a large number of people, and it's got very good integration with Visual Studio.
VSS these days is pretty stable, but you don't want to use it over an unstable network (unless you're using the HTTP based server approach) because it can corrupt files. It should only use the file-based version control inside a reliable on-site network. If you're going to do any off-site ore distributed development, then you need to use the HTTP model, or choose a different product.
VSS has some quirks. Branching doesn't work the way most people want it to. This is not necessarily VSS's fault, as it was designed to operate a little different from other Version Control of the time (remember, it's 20 year old product). People that choose it, expecting it to work differently than it's designed to have chosen the wrong tool for the job.
I've successfully used VSS in monster sized repositories. One of the keys is that you need to run the analysis and fix tools on it regularly to head off potential problems before they become corrupting problems.
You also don't want to use VSS in any situation where you need security, because VSS's security is application based. Being that you need direct file read/write access, anyone can go into the files and fiddle with them by hand if they want. Again, this is different if you're using the HTTP server component. (For what it's worth, this is similar to many kinds of version control of that era, such as RCS and SCCS, so it's not like this was unheard of)
Now, having said all this, to answer your question, if you've got download access to VSS (such as through MSDN), just download it.. it's not that big. It's only 100MB.
If you have to implement a source control system. Start with SVN or Git, hands down. Take a look at VisualSvn server with AnkhSvn and TortoiseSvn for client tools. They are all FREE.
Try Accurev (www.accurev.com) or Perforce (www.perforce.com) or PlasticSCM (www.plasticscm.com)
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm trying to find a source control for my own personal use that's as simple as possible. The main feature I need is being able to read/pull a past version of my code. I am the only developer. I've looked at a lot of different version control systems, but they all seem way more complicated than I need. I need one that's simple, runs under Windows, and doesn't expose itself to the network.
Specifically, the version control system should not require exposing an HTTP interface, it should interact with the local filesystem only. It just needs to be a version control system geared for one guy and one guy only. Graphical UI is a plus.
Does anyone know of software would satisfy what I'm looking for?
Thanks!
-Mike
Subversion is great -- you can run the server yourself or use something like assembla.com to host your code (although that exposes it to the network).
There are numerous gui applications like tortoise svn that would allow you to interact w/ the source control repo
From what I understand, and at the risk of sounding like a fanboy, you might want to consider a DVCS (distributed version control system) like git or mercurial. They essentially take away the central repository part, so it should be ideal to use when you're a solo developer.
Another advantage is that when you decide to add people to your one-man team, you don't have to set up a central repository. All they have to do is clone your repository and they're good to go!
If you're windows based and are used to a shell plugin like TortoiseSVN I'd pick mercurial. Their windows integration is just a bit better than git's, using TortoiseHg. The git counterpart (cheetah) is on hold at the moment, due to the developer getting sick and tired of all the demands people were making ;-)
If DVCS is too exotic for this situation you could always rely on SVN. I've heard good stories about the already mentioned VisualSVN solution. Install, make some repositories and go. Install TortoiseSVN for shell integration, or perhaps Subclipse or ankhSVN for eclipse and visual studio, respectively.
Note: I have not actually tried git or mercurial in a real life project, just some test setups. I now have a simple project WITH version control (using mercurial in my case), without having to have access to a central repository.
Sourcegear Vault is free for a single user and you can run both the client and the server on your own machine.
Subversion with TortoiseSVN.
Like all version control systems, it will sound reasonably complex when you start off, but it's really very simple once you get into it, works well for a single developer, and doesn't require any network access if you don't want it to.
Plus, it's free.
For what it's worth, you can use Subversion & TortoiseSVN without a server using file:/// URLs to connect to you repository. I've done this to create repositories on USB thumb drives that I can move from machine to machine.
Here's a nice write-up: http://www.fredshack.com/docs/tortoisesvn.html
I use the free (2 user?) licence of Perforce. Powerful, fast, and well documented.
I'm a very satisfied user msysgit for Windows. It contains a recent copy of git as well as a GUI, a shell and a history browser in a single install package.
No need for a server component and if you do decide to host it somewhere your repository is signed and cannot be modified by the hoster without you seeing it. Finally, moving the repo to a server is a easy "push" operation which keeps all of your history.
You really can't get much easier than VisualSVN for version control on Windows.
I like to use Google Code, even for my one man projects, as it provides a Subversion repository already set up. Also, the server is offsite, which protects against hard drive failures and other disasters.
You might find Mercurial to be pretty nice for that purpose. You won't have to set up a server and creating the repository is as simple as doing "hg init" in the directory where your work is.
All the previous suggestions are pretty simple, and I know cvs is a bit out of vogue these days, but I like to use it's local mode for a repository that doesn't even need a server to install or set up. The repository can be anywhere on your hard drive. I have mine on a memory stick to have access to it anywhere even without an internet connection.
The key commands are:
cvs -d:local:/full/path/repository init
to create the repository
mkdir /full/path/repository/project
to create the module, and
cvs -d:local:/full/path/repository/cvs co project
to check out a local version.
TortoiseCVS gives you your Graphical UI
Bazaar. See Bazaar in five minutes for a great start.
Whenever you save a file, run the $ bzr commit -m "Added first line of text" command, and it's all taken care.
If you edit over FTP, make the FTP folder as a drive or folder, and bzr update after the commit.
+1 for Subversion, for those not familiar with it I would recommend the SVN Book.
VisualSVN Server is a complete installer for Subversion Server on Windows.
VisualSVN is a Visual Studio plugin for Subversion integration.
You could go with Mercurial.
It's very easy to start working with and there's TortoiseHg which integrates nicely with Windows shell.
You don't need a server for it as it's a distributed version control system - you can hold a whole repository copy on a flash drive and push/pull changes from it.
If you wish, you can put hg in a web server mode that makes the repository easily accessible over http.
As opposed to SVN and CVS, it doesn't spread its metadata directories all over the repository. There's just one .hg directory in repository root.
I use it daily and love it!
I use Subversion and TortoiseSVN — both are free. Your repository can be on the local machine. You don't have to work over a network.
However, for disaster recovery or even simple machine fault, it's probably a good idea to store your repository on a different computer and also back it up.
You might want to consider using a third party service to host your repositories off-site over the internet. I use CVSDude and am satisfied.
I am also a lone developer, and I use Subversion and TortoiseSVN.
Setup of Subversion is quick and painless; it can be done in less than half an hour including setting up the repository.
There is no requirement by Subversion to run on a server, I actually run it on my local machine and keep my repositories on a separate drive. Connecting to the repository uses svn:// instead of http://. I'm not sure why you require that it does not expose itself to the network, but this would be a matter of security via obscurity. I'm sure networking experts could suggest better methods for locking it down, should that be necessary.
Once the repository has been created, commits and updates from the repository are as simple as right-clicking on a folder in Windows Explorer.
Any distributed revision control system is best for lone developers, like git or Mercurial. Best thing is you can incorporate more developers to your project seamlessly, as opposed to having to give them access to your main centralized SVN or CVS repository.
SVN and TortoiseSVN work for me. Definitely ensure you have offsite backup.
You might want to check out the wiki article Comparison of revision control software. A (slightly hard-to-read) comparison tool might help. You might enjoy If Version Control Systems Were Airlines.
I came here looking for the same thing, and I saw someone suggest Google Code. I tried it out, and it was brain dead easy to set up. Exactly what I was looking for. Works like a charm with TortoiseSVN (my favorite).
I came here for a solution, Google Code was all set up in about 2 minutes. You can choose SVN, git, or mercurial for your version control.
You should check CVSNT as server and use any of the clients you would like (standalone or integrated with your IDE). There are plenty of them.
Use Visual SVN to setup your server and then use Tortoise to access your repository. Both are free to use and we have been successfully using it for quite sometime now.
#gorgapor: Doesn't the Google Code TOS specify an open source license? It's not a generally applicable solution in that case.
I haven't seen anyone mention Perforce. Perforce allows you to use their software for up-to 2 users for free. You can run the server and clients in the same machine, which will give you the environment that you want.
This is much the same question as Source control system for single developer
The bottom line is: yes there is. More than one.
My opinion is that SVN will do just fine. it does for me in similar cases, as described here: Single serving source control
I have heard of a hosted Subversion vendor Versionshelf (http://www.versionshelf.com) on a podcast I listen to.
This site also has a list: http://snook.ca/archives/servers/hosted_subversion/