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!
Related
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.
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
For a solo developer using Visual Studio 2010 beta 2 is TFS Basic a better option than Subversion (with VisualSVN or Ankh) and (optionally) something like Cruisecontrol?
I don't need distributed source or even remote access. I don't really care about drilldowns and all that reporting. I just want version control & potentially automated testing & building.
EDIT: to respond to Bob Aman's questions (Thanks Bob)
I was considering self-hosting but off-site is a good idea , as you say. I back-up regularly. It is really only me who will have access to the repository so access control would not be complicated. I do have an MSDN subscription so cost is not an issue. The repository won't get particularly large - I'm not that productive. :/
If you're not a large company beholden to microsoft, I'd recommend subversion.
TFS source control is - how can I put this - unfortunate.
It works very well if the only thing you ever do is work within visual studio. However, as soon as you want to interact with it from outside (for example, add a text file or some batch files that aren't inside a visual studio solution file), it becomes painful and problematic.
This is mainly because it marks all files as read-only on the file system unless you explicitly check them out. Visual studio does this automatically, but for anything else you always have to explicitly check out files using either the command line tf.exe or the TFS power tools. It gets really annoying really quickly.
Another side effect is the tracking of new files. Subversion et al will tell you about new untracked files and directories when you do a diff, whereas TFS will ignore them entirely. This has led to many many broken builds because a developer forgot to check in a new file, because as far as TFS was concerned, it didn't exist at all until they explicitly added it.
TFS is also strongly tied to the windows domain-model of user authentication. You need to add windows user accounts for people to have access to it, which a pain if you're not already running on a corporate domain network.
Depends very much on a couple of factors. Are you hosting the repository yourself or outsourcing it to a company that handles that for you? (Highly recommended, since that usually means you get off-site backup and redundancy for cheap. Things that can sometimes be hard to get right.) It's a lot easier to find stellar hosting for Subversion. I believe there's only one or two options on the market for TFS hosting. How many people will have access to the repository? Do you need to set permissions on portions of the repository? How do you want to handle access control? If you need to do anything particularly complicated, it's either not possible in TFS or its very expensive. Subversion can usually handle it, though it's not always easy to set up.
Almost everything that TFS's version control can do can also be done on Subversion, either out-of-the-box or with the aid of some additional tool. Subversion also integrates pretty well with Visual Studio, though personally I always preferred TortoiseSVN. It's also a lot less expensive, assuming you don't already have TFS through MSDN subscriptions of some sort.
However, if you ever get into the extreme realms of version control (absurdly huge repositories, or gigantic binaries in the repository, for example) what you really want is Perforce.
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)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
As developers, we believe that not having local administrative access is going to severely handicap our productivity. We will be restricted from running IIS (we’re a web development shop), installing applications, running Microsoft power tools, etc. If you’re going through the FDCC process now, it would be great to hear how you are coping with these changes.
Having actively worked as a contract developer at a base that uses the AF Standard Desktop, I can tell you a few things.
1: and most important. Don't fight it and don't do what the first person suggested "and let them choke on it". That is absolutely the wrong attitude. The military/government is fighting lack of funding, overstretched resources and a blossoming technology footprint that they don't understand. The steps they are taking may not be perfect, but they are under attack and we need to be helping, not hindering.
OK, that off my chest.
2: You need to look at creating (and I know this is hard with funding the way it is) a local development lab. Every base that I have worked at has an isolated network segement that you can get on that has external access, that is isolated from the main gov network. You basically have your work PC for e-mail, reports etc.. that is on the protected network. But, you develop in your small lab. I've had a lab be 2 PCs tucked under my desk that were going to be returned during a tech refresh. In other words, be creative with making yourself a development machine +servers that are NOT restricted. Those machines are just not allowed to be connected to the main lan segment.
3: Get the distributions of the desktop configurations. Part of your testing needs to be deploying/running on these configurations. Again, these configurations are not meant for development boxes. They are meant to be the machines the people use for day to day gov work.
4: If you are working on web solutions, be very aware of the restrictions on adding trusted sites, ActiveX components, certs, certain types of script execution that the configuration won't allow. Especially if you are trying to embed widgets/portlets/utils that require communications outside the deployed application domain.
5: Above all remember that very few of the people you work for understand the technology they are asking you to implement. They know they want function X but they want you to follow draconian security rule Y while achieving it. What that usually means is that the "grab some open source lib or plugin and go" is not an option. But, that is exactly what your managers think you are going to do because of the buzz around rapid development.
In summary, it's a mess out there. Try to help solve the problem.
While I've never been through the FDCC process, I once worked for a U.S. defense contractor who's policy was that no one had local administrative access to their machines. In addition, flash drives and CD-ROMs were disabled (if you wanted to listen to music on CDs, you had to have a personal CD player with headphones).
If you needed software installed you had to put in a work order. Someone would show up at your desk with the install media, login to a local admin account, and let you install the software (the reasoning being that you knew what to install better than they did). Surprisingly, the turnaround was pretty quick, usually around 1/2 an hour.
While an inconvenience, this policy didn't really cripple us. We were doing a combination of Java, C++ (MS Visual C++ and GNU/C++), VB 6.0 and some web development. For what little web development we did, we had a remote dev box we would RDP into for testing. Again, a bit of an inconvenience, but it didn't stop us from getting our jobs done.
Without ever having had the problem, today I'd probably try a virtualising solution to run these tools.
Or, as a friend of mine once opined: "Follow the process until They choke on it." In this case this'd probably mean calling the helpdesk each time you needed to have a modification to your local IIS config or you'd needed one of the powertools started.
From what I can tell FDCC is only intended to be a recommended security baseline. I'd give some push back on the privileges that you require and see what they can come up with to accommodate your request. Instead of saying I need to be a local administrator, I'd list the things that you need to be able to do and let them come up with a solution that works (which will likely to be to let you administer your machine or a VM). You need to be able to run the debugger in Visual Studio, run a local web server (Cassini), install patches/updates to your dev tools on your schedule, ...
I recently moved to a "semi-managed" environment with SCCM that gets patches installed on a regular basis from a local update repository. I was doing this myself, but this is marginally more efficient for the enterprise and it makes the security office happy. I did get them to put me, and the other developers, in a special collection so that we could block breaking changes if needed (how could IE7 be a security update?). Not much broke except that now I need to update Windows Defender manually since I updated it more frequently than they do in the managed collection! It wasn't as extreme as your case, obviously, but I think that is, in part, due to the fact that I was able to present the case for things that I needed to do for my job that required more local control.
From the NIST FAQ on Securing WinXP.
Should I make changes to the baseline settings? Given the wide
variation in operational and technical
considerations for operating any major
enterprise, it is appropriate that
some local changes will need to be
made to the baseline and the
associated settings (with hundreds of
settings, a myriad of applications,
and the variety of business functions
supported by Windows XP Systems, this
should be expected). Of course, use
caution and good judgment in making
changes to the security settings.
Always test the settings on a
carefully selected test machine first
and document the implemented settings.
This is quite common within financial institutions. I personally treat this as a game to see how much software I can run on my PC without any admin rights or sending requests to the support group.
So far I have done pretty well I have only sent one software install request which was for "Rational Software Architect" ('cos I need the plugins from the "official" release). Apart from that I have perl, php, python, apache all up and running. In addition I have jetty server, maven, winscp, putty, vim and a several other tools running quite happlily on my desktop.
So it shouldnt really bother you that much, and, even though I am one of the worst offenders when it comes to installing unofficial software I would recommend "no admin rights" to any shop remotly interested in securing their applications and networks.
One common practice is to give developers an "official" locked down PC on which they can run the official applications and do their eMail admin etc. and a bare bones development workstation to which they have admin rights.
Not having local administrative access to your workstation is a pain in the rear for sure. I had to deal with that while I was working for my university as a web developer in one of the academic departments. Every time I needed something installed such as Visual Studio or Dreamweaver I had to make a request to Computing Services.