I have next situation. I need to choise source control system for my project. This scs must provide the API to my .net application to get information about check-in-s for specified user and date period and about changes which was done in this check-in-s (the number of added and updated lines).
What source control system provides this functionality?
P.S. I can't use the TFS, it's a limitation..
Aside from SharpSVN, which Mikael Svenson already mentioned, most source control systems should have a command-line client with output that you can easily parse, even if they don't have an "API" as such.
Therefore I'd suggest that you choose the best source control system based on other factors (such as reliability, ease of use and how well it fits your development process) and then look for a way to implement the metrics.
(As an aside, it's my highly subjective opinion that metrics from source control will not be very meaningful. I mean, they can be interesting to look at, but as soon as you have management trying to make any decisions based on them you're in trouble!)
Take a look at using SubVersion and SharpSVN.
SharpSVN encapsulates client functionality for SVN and should have enough functions to cover your requirements. They also provide a wiki and forum for questions about how to use the library.
Also check out Git and GitSharp. Git is a distributed source control system, which I personally like very much. Once you get your mind around how it works it's a beaut to work with.
I did some work with code change metrics and Subversion out of the box was of great help. It's command-line client can dump the log history in XML for convenient processing (in my case, using XSLT and SQL).
You can find more details on the PanBI Subversion page and get a feel for the kind of metrics I was interested in from the screencast showing an analysis of the Apache web server subversion history. Got the apache mailing list going for a couple of days. :)
Related
At work, we are required to use a custom "source control" system. Basically, it takes snapshots of our code whenever we push new changes to our live environment. There are no rollback capabilities except to get a copy of the last live push, there are no mechanisms for seeing who changed what, and once one person is working on the code someone else can change the source and you would not know (unless you spotted the change).
I would like to implement Git in this environment but I'm not wise enough in the ways of Git to figure out how best to do this. Here are the requirements that I need to handle:
Source code is stored on a remote file path.
Once I start a project, anyone can change the remote source (I would like to capture these changes if possible).
The source is (usually) existing before I start to work on it.
After I complete a project, someone else may change the source (not using Git).
I am going to attempt to get the rest of my coworkers involved in doing this too.
I have only file read/write access to the remote server.
My coworkers do not like the command prompt (and, quite frankly, I prefer to use a GUI), so use of a GUI (like GitHub for Windows or, even better, the Team Explorer tools inside Visual Studio) would be a high priority.
We are a Windows-only shop specializing in C# and ASP.NET MVC so any solutions would need to work inside those bounds.
The impact on the remote files and folders should be minimal. I know Git is light but anything I can do to keep it as invisible as possible will be great.
I've looked into how to do this but I've not found a good solution that works for me (or at least that I understand would work for me). I found this article but it didn't appear to really work well for my environment (again, maybe that is my lack of understanding):
http://mattsnider.com/develop-locally-using-git-instead-of-your-company-s-crappy-version-control/
Any help that you can give would be much appreciated. I would really appreciate it if the help you give is doable for a Git user (me) who is not very knowledgeable. Steps to follow and instructions on why would be tremendous.
If your employer already has an established version control system that can handle all their different artefacts that the company needs to store (which will be more than just source code) then don't even try to actually change their system.
The question is more about how you can help yourself, which will depend on the level of access you have to personal storage and to network storage - the latter being maintained by others.
Assuming you have local storage, then you can set up a git repository within your own local copy of the source code. You would then set up a remote on a/your network drive to act as your back-up. (as described in the blog you reference).
I use (variously) Git-for-Windows, Git-Gui, gitk, and Git Extensions for my development so that I can pick and mix the best tool/command for any particular task. I find it especially useful for my Matlab development with its rapid interactive edit-fix-update common in (my sort of) systems engineering.
When I have a stable version in a commit, that I want to send back to the company VCS, I can then check it out/back-in (or whatever their process demands) to their system (do tag that commit).
Likewise if there is an update to another file that you need from their VCS you should have a branch for receiving it's checkout, followed by a merge back into your development branch (or whatever flow most suits you).
Regularly push your local repo onto your bare network repo so you have a backup and some security. You can always bundle your repo, or archive a commit as required for other backups if you need.
We need to have documents shared between clients (CRM-like functionality). Users need to be able to:
Edit the documents and save them again
Attach new documents
Our application is coded in WPF with WCF for data-transport and NHibernate/SQL for data on the server.
what we're thinking is to use SVN and have the app create a local check-out of parts of the repository (when they click a document, it is checked out by SVN in the background and opened from the local path) - When saved it will silently (using monitoring of the path) be committed back to the repository.
Question: Is this feasible - or are there better solutions to this?
EDIT 1:
Summary so far:
I'll look into using Git/Mercurial instead of SVN
Document size (revisions) might be prohibitive pending tests
SharePoint is an option (although not viable in my case as the cost alone is prohibitive) - I will look into the alternatives for SharePoint, tho.
Not much experience out there about using repositories for many users although it works for small teams..
Wiki software might be an alternative to SVN.
Thanks for all the feedback - I'll keep it open a bit longer.
EDIT 2:
Summary after a few days of work - I have a client working - see my progress here.
Based on the heavy .NET references, are you all set up with MSDN? Perhaps you can make use of SharePoint...which may already be included within your MSDN account.
You might also want to consider using a Wiki for document management - I've seen this done and do it myself for my own organisation. We're using Atlassian's Confluence Wiki. Confluence provides for the versioning and general management of documents.
I wouldn't use SVN for this, SVN is not very efficient when dealing with binary files. By using SVN as a back channel for some content in your application you just complicate things by adding another technology and dependency, but you will not use much of its real potential.
I would store the documents as blobs in the database and get/store them through WCF.
Generally I don't think that SVN or any version control system is a good thing to use for sharing documents. Main disadvantage is the diff system on binary files... Your SVN repo will grow rapidly..
Maybe you should try using some of the commercial tools designed for document sharing (eg. Microsoft Sharepoint). Or some Open Source alternatives... Perhaps you should read this post...
It depends on the kind of documents you are using. If you have lots of changing, compressed binary files, then don't use it.
However, if the documents are in an open format like a Wiki language, (X)HTML, LaTeX or uncompressed ODF, then using a version control system makes absolutely sense. Also, a bunch of compressed ODF files or PDF files are handled very well, especially if the files are mostly smaller than 5 MB or so.
In addition, make sure to check some more recent version control systems like Mercurial and Git before sticking to the conceptually outdated SVN. In your scenario, you won't profit much from the "distributed" part of Mercurial and Git, but they are nevertheless easier to setup - at least to my experience. And they provide very advanced version control features which can save your day in the rare cases when you need them.
In case you stick to SVN, and if your client software runs under a modern Unix system, you can also try SVN-FS. This is a filesystem that uses a remote SVN server. Each read goes to the latest revision. Each write creates a new commit. This seems to be exactly what you wanted to build around SVN.
I think that using ready made and proven tech is great idea. Would like to see it's progress if you really go that way.
I would strongly go AGAINST SharePoint - you'll tie yourself to Microsoft in manners that are hard to describe here. From my point of view, SharePoint is a tech that needs taking care of just for itself.
I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!
We have an in house winform application that is used by about 20 users in my company. It's a real pain having to send the users a new msi when the application has changed in scope and I would like to have the users prompted from the application as to whether they would like to update their copy. My thoughts are that the source of the application would be on our company server and that the application would look to a database to see if updates area available. Aside from that I don't know where to go from there. Has any one done anything similar to this or does any one have any recommendations on how I should implement this.
Here's an open-source solution I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible.
So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you make the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.
Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.
This boild down to one DLL, less than 70kb in size.
More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
ClickOnce.
If it's a fairly simple program (not many dependencies) consider keeping the program on a network share have have users run from there.
The most popular solutions with graphical update prompts are AutoUpdater.NET and WinSparkle. For a more powerful solution, take a look at Google Omaha.
Squirrel is definitely worth a look
In a .NET C# program, is it easy to transition from FTP to SFTP? I'm trying to get a sense of how muh time it would take the contractor to make the transition. My personal experience is mostly with PHP, so I have no idea.
Basically, what I'm talking about, what steps would have to be made? Obviously, different commands, but would anything else in the code itself? Like do the commands require different formats, etc.?
Also, if anyone has a list of all the .NET/C# FTP and SFTP commands, that would be really helpful.
Clarification, as requested: The program is uploading extremely small files (20 KB) to a server. By format, I mean visually, because I was wondering about a find/replace job.
This is a pretty vague question. You haven't told us what the C# program is doing with FTP. Is it a server, is it a client, is it doing directory listings, is it uploading 100 GB files? What library is it using?
According to this forum post , there is no built-in support for SFTP in .NET, so you would have to use third-party libraries such as SharpSSH or Granados SSH.
I don't really know what you mean, "do the commands require different formats". Obviously, the code will use different:
Libraries
Types
Wire protocol.
It will obviously appear somewhat similar, thanks to the abstraction of the libraries. I suggest you provide more information, and a clearer question.
One thing that you'd need to consider is how well your current code is written. If your existing FTP implementation is horribly designed spaghetti code then converting it to SFTP may be next to impossible and take way longer than you'd like. Without knowing the current state of the code, it would be difficult for anyone to make a good estimation. And even if you do get an estimation from people on this site, I wouldn't recommend trusting it (even though the people on this site are great) since without all the information in front of them it will be next to impossible for anyone to come up with a reliable estimate.
Perhaps you should consider hiring a good consultant or business analyst to do a thorough estimate for you.
It really depends on what C# library your developer has used to implement FTP.
If, for example, they used edtFTPnet, a widely available open source library, then the upgrade path is trivial if you replace it with edtFTPnet/PRO. The PRO version has the identical API and just a few extra lines of code would be needed.
I've been down this road.
It depends, but keep in mind that SFTP, FTP-SSL and FTP are different.
If he's writing the SFTP libraries himself, a month or two, since it's a lot of work to make it perfect and compatible. But he should NOT do that.
In short, get him to use an external library to add SFTP functionality. This will make it pretty short. Maybe a week or two of full-time work, but it depends on how involved it is. There's open-source options.. But for $50-150 you can get a license to well-maintained code that's really easy to use. will save him days of work.
There's links above, but I'd look at:
Free:
http://www.enterprisedt.com/products/edtftpnet/overview.html
Commercial:
http://www.weonlydo.com/