Related
According to this page:
No central approval process for adding packages. When you upload a package to the NuGet Package Gallery (which doesn’t exist yet), you won’t have to wait around for days or weeks waiting for someone to review it and approve it. Instead, we’ll rely on the community to moderate and police itself when it comes to the feed. This is in the spirit of how CodePlex.com and RubyGems.org work.
This makes me feel uneasy. Before I download a Firefox add-on, I know it should not contain malicious code, because AFAIK all add-ons on addons.mozilla.org are reviewed by Mozilla. Before I download a open source project from codeplex.com or code.google.com, I know it should be safe because anyone can check it's source code. And I can also use WOT (web of trust) to check how other people think about the project.
But before I download a package from NuGet official package source. Take this one for example. I do no know who made this package, nor what is contained in the package. It seems to me that anyone can pack anything into a package, give it any name they want (like "Microsoft Prism", as long as the name is not taken), then upload it to the official package source.
Should I be worried about the safety of the packages on NuGet official package source?
Your uneasyness should apply to software you obtain from any source:
Binaries downloaded from Sourceforge.net, Codeplex.com, etc could feasibly contain malicious code (either planted by the original submitter or, more likely, inserted by a hacker into the website) that may pass unnoticed until someone (you?) gets bitten and raises the alarm.
Even if you compile your own binaries from source downloaded from one of the former websites, it could still perform malicious acts unless you go over all the source code and understand what it does.
Even software downloaded from 'app stores' (e.g. Apple iTunes, Android Market) could feasibly contain malicious code; some of these review processes are partially automated but are still not infallible, and the human review that also occurs is definitely not infallible!
There have been examples in the past of boxed software containing malware!
Perhaps there is a continuum of trust that you can have in software (delivered as binaries or source code), and something like the Nuget Package Gallery (and CodePlex.com and RubyGems, etc) probably lies on the less-trustworthy end of the continuum.
There are potential solutions to this sort of problem, such as those proposed by the Trusted Computing Platform Alliance, however they come with huge restrictions on the freedoms that we currently enjoy in developing software and sharing the software we develop as we see fit, without the need for licenses or cryptographic keys obtained from central authorities at great expense.
I believe that the community will come up with conventions and mechanisms for ensuring that Nuget becomes a trustworthy source of software libraries for .Net developers, whilst retaining the agility it has with not requiring a formal review process. However, the ultimate responsibility rests with yourself as a user to ensure that your IT security isn't compromised, and the precautions you take are a function of the criticality of IT security in the context of the software you are writing (e.g. home projects; probably low. Banking, medical, process control projects; probably high!)
NuGet doesn't manage trust. Even if it did, you would still have to be concerned about trusting what NuGet trusts.
You should absolutely be concerned about the safety of the code in a NuGet package. You should be concerned about the safety of any code you are not familiar with.
The approach I take to using packages, both personally and professionally, through NuGet and NPM are below:
Lock in the semantic version number completely. Explicitly specify the major, minor, and patch numbers. Don't assume that new updates will be safe or that their semantic version will be accurate.
Use only well known current versions for production.
Experiment with anything in a test environment with limited access e.g. under an account which isn't a local administrator, no local access to highly privileged credentials, no access rights to privileged resources granted to the test machine's IP.
Check the vendor. For example if the package is released by Amazon and it's an AWS SDK, then that package is probably safe to use if you trust Amazon.
For example the only packages I would trust right now to just go and add them in a production environment are Newtonsoft.Json and Nhibernate. My biggest concern with new open source packages that anyone can publish, is that they actually work as described before I buy-in and waste my time on something that doesn't meet my needs.
I feel as though if you did enough research on the package to see if it's suitable for a production environment, you probably have learned enough about the software and its community to determine if you can trust it's not doing anything maliciously. Researching the software and it's community really means more to me than NuGet's stamp of approval decided by one central authority that we all pray is perfect.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Version Control. Getting started…
I am interested in implementing version control for the first time. I am starting to amass custom libraries and would like to know what methods you would recommend for implementing version control on a Windows Vista OS. I also have an Ubuntu server setup. I'm not sure if OS is relevant.
Also, if it is relevant, I primarily use PHP and AS3.
Thanks!
Usually I recommend either GIT or SVN. If you use Windows, SVN may be a better option (I believe the GIT binaries are still in beta for Windows, and the SVN clients are better). I'd also recommend registering for a hosted version system (such as github or beanstalk). Most services offer a free option, and will provide far better data replication than an any individual could create. Lastly, check out a GUI client (such as Tortise SVN) or check for integrations with the IDE you use for editing code.
The tutorial at http://hginit.com/ covers a lot of ground regarding the concepts behind version control, specifically distributed version control. Mercurial is the focus of the tutorial, but the concepts extend to git as well, and to other SCMs to a small degree.
My biggest recommendation is just to start using some version control, right now. It'll change the way you work--honestly.
(full disclosure: I work for Fog Creek, the sponsor of the hginit tutorial)
Last question first: what language you're using doesn't really matter. Even for text documents, Word documents, etc., a source control system will keep track of your versions.
As for which one to use, there are a number of free ones available, that require different levels of administration and expertise. If you're mostly comfortable with Windows programs, SourceGear licenses their Vault product free for single users.
Open source repositories are also not uncommon. Subversion is widely used, but does require a fair amount of server administration expertise.
For an individual, Bazaar in Solo mode is very easy to use. Later if you want a multi-user configuration, other "workflows" are possible.
Go with something like http://beanstalkapp.com
SVN is probably more conceptually easy to understand than Git, and it has more users - hence more tools and easier to find help.
I'd recommend Subversion (SVN) using the Red Bean Subversion book as a guide. Start with Appendix A, then go through chapters 1, 2 at least.
This is my recommendation primarily because it is how I started with version control, not because I think SVN is better than other version control systems.
I agree with Kevin Gessner just start using something and feel the change wash over you!
We use Mercurial. It is fast.
Git, Mercurial, or Bazaar
I'm a grad student in Electrical Engineering, and my lab has various projects related to ultrasonics. We have lots of code to perform simulations, but right now our situation is such that any given script has ~5 different versions. In addition, one person might develop code to simulate wave propagation, while another needs that code to perform a different simulation. This results in code being emailed back and forth quite a bit.
I suggested version control to my advisor, and she says that she likes it, but doesn't have time to manage a VCS, so it would have to be set up in such a way as to require as little maintenance as possible. Obviously, we're not releasing software to the public, so it doesn't matter if the internal structure is unconventional.
Most of the lab are not professional coders, but we all need to write MATLAB code as well as some other stuff. So, I don't expect the users to be so good about clean commits and the like, so it would be good for everyone to have their own "workplace" or something like that. But to be honest, I've only ever used version control for 3 people at once, so I'm not sure how to set this up.
So I am asking what is the best way to do this. I have only used Subversion, but I wonder if that is the right choice. We need a system that would (sorted by importance, descending):
require little maintenance
be easy to use and learn, since not everyone has used version control
have shell integration (we all use Windows XP)
be easy to set permissions and give everyone their own workspace
be easy to set up and get running
So, (1) What VCS is the best choice, and (2) how should we structure it. Thanks for the help.
We use subversion and love it, for its simplicity, easy of use, integration into the shell environment and the ability to not just version, code, but also specification documents pdf's and other resources we have.
As for structuring it, try and use your logical structure, as close as possible. Keep it simple :)
I see no reason why you should look further from Subversion. Although, for extra little maintenance you could check GitHub (since it is hosted solution, so no worrying about backup, servers etc) but there are hosted Subversion repos as well.
Especially if you're already familiar with it, so you can bring others up to speed and get extra credit :)
Once completely setup subversion should require very little maintenance, it's model is simple to apprehend, it is integrated in the shell, it supports ACLs which work just fine and it's setup is well documented.
you can setup subversion in a webserver, integrate it with a windows domain for auth if needed (otherwise you have to add/remove users, change passwords on the svn server)
You could also go the distributed vcs way, with hosted solutions no server setup, but to get that across your user's mind is gonna be way more difficult than svn. Not to mention getting it across your own head first.
Unless you have complex, fast-paced, parallel development models, I wouldn't recommend dvcs, I would stick to SVN
I agree that subversion is a very good choice.
But you can also consider mercurial: it's easier and it also has a tortoise integrated interface.
I would recommend www.assembla.com. They offer paid subscriptions but for academic projects you can apply for a free pro account.
I have used it for my academic projects and was 100% satisfied by the ease of maintenance, up-time and simplicity
The far easiest way is to use Subversion. But to get it to work the most easiest way (under Windows) you should definitely use TortoiseSVN.
After installation it works right within the explorer is just one right click away from usage. Maybe one of your guys should take a deeper look into the whole documentation to give help if needed. All other guys should take a look into the Daily Usage Guide for a first start.
Also you should take care about how you structure your repository!
Subversion has too many limitations related to the "always online + central server" model.
I would strongly recommend using a distributed version control system.
From the three main ones Git, Mercurial, Bazaar; in my experience Bazaar is by far the easiest one to use and setup.
I am looking for a good source control solution. Here are the requirements:
Must have a GUI or have an available GUI plug-in.
Must be free.
Must work with HTTP.
What source control would you choose?
BACKGROUND
Our .Net development team is part of a large parent company. We're in the process of acquiring VS Team System, however the bureaucracy of a large company moves slowly and it could be months before we have a Team System server up and running. In the meantime, we have a large project that will be outsourced to a vendor in India. In the past, our team's process has been something like this: 1)specify the requirements, 2)let the Indian team create the solution, and 3) receive the solution back from the vendor a month later.
We're looking for a more disciplined approach and Team System is our long term solution, however I'd like to use something right now instead of nothing.
Here are some of my thoughts:
Source Safe is a no-go, because of stability issues.
Ease of use is more important than advanced features, like branching and I'd really, really want it to use a GUI versus command lines.
HTTP access is a must, because the development team will be remote.
Additional Information as a follow up to feedback so far
We need a free solution, not because we can't afford it, but because the company's corporate purchasing policies will delay getting it. Free enables us to install at any time. I suppose that if it were cheap enough, I could pay out of my own pocket, but it would have to be pretty cheap.
Final
Sadly, we did not end up using any of the recommendations. We did finally obtain a TFS license, however we're not expected to have clearance to use the server until next year. In the interim, the offshore team is uploaded zip files onto an ftp server. Ugggghh! Why is it so hard to convince large companies that it's ok to use non-standard solutions (such as GIT) rather than wait months (or years) as they dither on trying to decide whether or not a purchase (in this case TFS) is worth it.
I recommend Subversion and TortoiseSVN. Even the documentation for Subversion is free.
Edited to add:
I also strongly recommend VisualSVN Server to setup your SVN repository. The setup was a snap and its been so trouble free I had to go look to see what it was called because I haven't had to touch it once since the initial set-up.
Think about a distributed system: darcs, git, or mercurial. They all have their adherents, but operationally they're much similar. darcs can take a long time to build, because it's written in Haskell, and you end up needing to build Haskell first. Mercurial is python based, easy to hack with and extend. And of course git is what's used for Linux, very widely available, lots of tools.
Subversion is, I think, pretty much the baseline of modern SCM; it would be a good choice too, but it does force you into having a fixed central server; either you, or your Indian collegues, will have to check out and commit over a long pipe.
Subversion (SVN) is obviously a popular choice. It's also quite commonly used now (Google Code, Sourceforge, etc.) so there should be lots of documentation out there about its use. Git is a good choice too, but the lack of GUI interfaces available makes it not fit your requirements so well.
I'm assuming since you're using .NET you're developing in a Windows environment primarily. Check out VisualSVN products. They make a great (FREE) Server product for actually running a full fledged svn server in a windows environment (it supports SSL, group/user authentication including Active Directory support).
They also offer a Visual Studio plugin, although it is not free (although quite reasonable at $49/developer). AnkhSvn is another Visual Studio client plugin option. It's not quite as great, but it is free.
http://www.visualsvn.com/server/ - Free Windows SVN Server
http://www.visualsvn.com/visualsvn/ - Visual Studio Client Plugin
http://ankhsvn.open.collab.net/ - Free Visual Studio Client Plugin
So, I think Subversion using VisualSVN's product offerings are going to give you the best windows/gui integration at a very reasonable price.
SVN sucks quite badly over HTTP in my experience. You will want to pull your hair out if your repo is of any significant size especially with a Trans-Atlantic round trip stuffed in there. Personally I'd go with Mercurial.
Google has recently done some research on Git versus Mercurial. The largest advantage that Mercurial had was that it played extremely well with HTTP.
TortoiseHg, while not quite as mature as TortoiseSVN, is a pretty solid Windows GUI. Although you mentioned you're not very interested in branching and merging, these are common activities in all DVCS. Fortunately because they are common, they are well supported in the UI and relatively painless activities overall.
Check out Subversion: http://subversion.tigris.org/
Has GUI plugin as well VS .NET. http://tortoisesvn.tigris.org/ http://ankhsvn.open.collab.net/
All open source & free.
My recomendation is Subversion + TortoiseSVN (for Explorer integration) + AnkhSVN (integration with Visual Studio).
I think you shouldn't use any of the distributet version control systems because after that you will have to get back to centralized one which could be painful.
As mentioned SVN and Tortoise are the way to go.
I'd also get a license for visual SVN (http://www.visualsvn.com/) it's not free but it is really good, it uses Tortoise svn and gives you it's features in the IDE.
Team Foundation Server is quite easy to use and is easy to get started with coming from a source safe background (shares common terminology for commands). However with part of the development being in India, they may be more knowledgeable about Subversion.
If you use Subversion, i would look at VisualSVN. It's fantastic, simple to use, and quick to set up (TFS is a bit complicated to set up). VisualSVN offers an IDE plug-in ($50) and a server counterpart that bootstraps Subversion for windows machines (Free)
Mercurial is great and really easy.
Give Mercurial a shot. BitBucket has free accounts you can play around with. I've written more about why I use it here.
Have you tried SVN and using TortoiseSVN for the Shell Extension?
I second SVN and TortoiseSVN.
I moved from CVS and WinCVS and I am very happy with this setup.
I would recommend the source control where most of your team members have the most experience or where you have someone on your team who is an expert for.
In my opinion besides the endless "git is better than Subversion is better than CVS"-discussion I don't think the differences between them is what matters.
It's more important to have someone who really knows how to use whichever system you decide to use.
Setting up Subversion for .Net development has gotten easier. You could start by installing Visual SVN Server. This will install Subversion Server on a windows machine, will work you through setting up your repository, authentication, etc.
Then for Visual Studio integration with Subversion you can try VisualSVN, it's not free but well worth the license. But if your budget don't allow it, Ankhsvn also works fine, I use it everyday.
I had to make a similar decision several months back. I liked SVN a lot, but the lack of GUI for the administration was a big issue for my team. TFS was ideal, but very expensive.
We decided to meet halfway and license SourceGear Vault. It doesn't meet your requirement of "free," unfortunately. Although I did find its comparison with SVN to be interesting.
If you're certain you're going to Team System, then I believe there's a 180-day trial you can use. That way, you son't have to switch.
Have you tried unfuddle (http://unfuddle.com/). Fulfills all your requirements.
Another vote for SVN.
For a lightweight SVN server on windows look at sliksvn. It doesn't do http source browsing, but is a much smaller and easier setup than apache based servers for small groups.
Ok, when hired on to my current company a year ago, I was tasked with migrating our development teams from VSS. They already had it in their minds that they wanted Subversion, and since I had experience using and setting up subversion, I was a good candidate. I first tried to sell TFS because it woul dhave solved the problem I am in right now, but since money is tight, and Subversion is free... well you get it. Anyway, I have finalized the propsal and the only thing standing in the way is the following.
I proposed that we store only our source code in SVN, and all documentation, release builds, and other project artifracts be stored in our SharePoint portal, so we don't have to give non developer stakeholders access to SVN. When I presented the proposal, all was excepted but the question arose about how to manage the syncronization between the artifacts (Ex: How to is document x version 3.1.2 associated with release 4.5.2). My initial reaction is to create a section in the SharePoint porject page for each new release that will hold the artificats (and keep track of changes too). Is there a better way of doing this? Does anyone know of anyone doing this? Or any integration packages to sync SVN with SharePoint?
Here is some info on the companies development environment. All of our software is for internal use, we sell none of it, so our customers are all in-house. We have 2 types of developers: 1. those who take care of maintainance and customization of third party software, and 2. those who write proprieatry software (which is where I fall). Our software we write is mostly .NET, but the 3rd party software is all over the board (COBAL, C, FORTRAN, Other crap that no ones cares about anymore).
Please advise, as I need to get this submitted soon. I HATE VSS!!!!!!!!!! and I need relief!
What we do internally is putting all docs under our version control system, I think it's much easier. Then, of course, you have to give access to not-developers.
In your case, using SVN, why don't you put everything inside and then use the webinterface to give access to the stakeholders? It's easy enough for them :-P
I would use SVN for both documents and source code.
Advantages:
You can synchronize versions of
documents with versions of source
code.
You have everything in one place, so
no two repositories to administrate.
Disadvantages:
You'd probably need to manage the
access rights for some stakeholders
to some parts of the folder
structures.
SVN is not the most appropriate tool
for document management
In order to solve the possible concurrent changes to the same document, you can use SVN property svn:needs-lock for these items, to make them editable by one person, who locks the item.
As pablo said, you can access the documents (at least for reading them) through the web interface.
You could expose the svn repo via the web interface and link to that in sharepoint. That way people who need to edit the documents would need access to subversion but anyone could easily access the documents "read only".
In our organization, we have docs/artifacts, code everything in SVN and have given access to non-technical stakeholders as well who use tortoise client.
however you can look at the following option
Option 1 : create a ASP.Net interface for non-technical users
You can build a simple web interface in ASP.net, configure that with a single user so you would not have to create separate users for all the nontechnical stakeholders and they would get access to the docs with proper version control, etc. you could look at sharpsvn for the implementation aspect. the disadvantage of this approach would be that you might have to invest some time in developing this app
Option 2 : ofcourse, create separate users for each non-developer stakeholder
This answer is probably too late for you implementation, but the simplest integration path may be to store the docs in SVN and then publish to Sharepoint with an svn-hook.
Build artifacts could be programatically published the same way from you build scripts.
You can upload docs to SharePoint using a simple POST
i.e.
http://blogs.msdn.com/rohitpuri/archive/2007/04/10/upload-download-file-to-from-wss-document-library-using-dav.aspx
Probably a little late, too, but I would avoid putting the documents in SVN if you have a SharePoint system setup. Though SVN does a fantastic job for source code, for document management it doesn't provide the ease-of-use of SharePoint. If you have it already setup and you are a primarily MS based network, SharePoint makes a lot of sense and can handle revision control for the MS based documentation much better than SVN.
Yes, you can manage access to SVN documents with a needs-lock, but chances are at some point you'll have a non-developer needing to access the documents. Explaining SVN to a non-developer, non-techie is not an easy thing.