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.
Related
Many thanks #Mirko for the reply and comment. So sorry if im not clear myself.
I'll try to make it alot more understandable.
First thing is, I want to create an application for a Data Entry Form on Windows (Windows Form Application .exe). This application required database
and for a database server im thinking about SQL (Need some advise here on the server).
After the Form-Design completed and linked to the database, i want it to be able accessing PDF/PNG and stamping also, For approval purpose. Thus i need some file transfer server for this and some new coding line for this function. (I need a lot of help here especially the coding line).
Please note i've also tried making a form-based application on VBA Excel and use it's sheets for the database. But im struggling on how to make an access for File transfering and stamping (Approval) protocol. Thus lead me to C# on Visual Studio, hoping this coding program could handle such file-embed system.
Edit: Nico, I am not sure this will make a great SO question. Sorry, I cannot provide this detailed feedback in comments as they do not allow enough text. You are asking for advice that is in my opinion too broad. Meaning you really have many considerations here and are in essence asking (I think) how do I build a document management and approval (workflow) application.
You may want to look into document management solutions (I am no expert on those), but many handle approval flows and meta-data on documents well.
I would recommend you carefully consider even your starting assumptions. In my opinion if you are building a green-field application now you should decide between WPF (instead of Windows Forms) and a Web Application (that is in the .NET space) and I would probably recommend ASP.NET Core Razor Pages. If more than one person will use this application I would lean towards the latter strongly as it is more easily accessed and updated.
I am not the best person to answer how to do the Stamping approval part, but you may want to consider either an existing document management solution (maybe DocuSign, etc. as an integration) as they may offer you the features you are looking for out of the box. If not take a look at PDF libraries in the .NET space (I personally used Aspose in the past, but they tend to be expensive).
If you are looking to track metadata about the documents to be uploaded/approved SQL server is often a good choice, but since you are quite literally seeming to aim for document management, more document-centric options maybe a good fit (MongoDB, Cosmos (Azure), DocumentDB (AWS), ...) as they allow you to store arbitrary meta-data.
Right now I am saving my all visual studio projects in C drive.
Now I want to keep copy of that all projects in some other drive, so if my C drive get crashed then also I can access all projects.
So what is best way for that.
If I just make zip of current projects from C drive and paste it in another drive.
And when needed I extract it, then will it work OR any error will come.
Thanks for help in Advance.
If I just make zip of current projects from C drive and paste it in another drive.
Well you could do that but it's rather tedius; error-prone and rather brute-force. It's difficult to maintain history.
A better choice is to use some form of source control (SC) / software configuration management (SCM). SC is a tool for maintaining a code repository. It works by associating metadata about every source file and any changes you make.
e.g.
Git
Subversion
Microsoft TFS
Perforce
IBM/Rational ClearCase
Microsoft SourceSafe (ewww, retried thankfully)
Source control not only keeps a copy somewhere else (ideally a different computer) but it also allows you to
keep track of what changed
rollback a change
share with your friends or colleges
integrates nicely with your IDE of choice (VS) or command-line
But in this day and age there are plenty of free cloud-based solutions that offer you more than just acting as a code repository such as stats; wikis; bug tracking; and spiffy charts. Check out:
Microsoft Visual Studio Team Services (VSTS)
Github
Atlassian Bitbucket
Summary
Irrespective of whether you perform manual folder copies or use source control; both will lead to a copy of your code. However only the latter introduces workflows and due-diligence (via SCM) so that as you code you are unlikely to lose information due to the procedures and safeguards in place.
A word on file backup
If for some absolute reason you decide not to proceed with SC but rather stick with plain-old-file-backup then at least follow the fine wisdom of Scott Hanselman (MSFT) where he talks about file backup best practices:
I've got a number of backups because I practice the Backup Rule of Three.
3 copies of anything you care about - Two isn't enough if it's important.
2 different formats - Example: Dropbox+DVDs or Hard Drive+Memory Stick or CD+Crash Plan, or more
1 off-site backup - If the house burns down, how will you get your memories back?
...using apps like CrashPlan.
Scott will most likely agree that his plan wasn't intended for source code but at least you have 3 backups of files as he recommends.
See Also
Hanselman, S, "Is your stuff backed up? Recovering from a hardware failure"
Have a look at Visual Studio Team Services. You can add code to source control (I would use Git if I were you) and manage your projects there for free.
Having your code in a source control system has many benefits, like having history of each commit.
Next to that, VSTS has lots of opions like Continuous Integration / Continuous Deployment, Testing, project management support like making your project an Agile project.
What will you do if hard drive crash?
Code Management is a practice and there are many tools to help you to manage your code. Try GitHub or bitbucket
Moreover you can also zip the code and save on external disks but check how much risk is involved with your code.
You could use a .zip archive to back up your work, but this is slightly laborious and will likely include a number of files you do not need to get up and running again (for example the build output, nuget packages folders, etc.) which will bloat your archives.
A better option would be to use a Version Control System of some kind, which will allow you to back up those parts of the project/solution that actually need to be backed up while ignoring the parts that can be rebuilt from the code. A good walk through of what and why can be found in Version Control By Example, which also includes comparisons about different types of VCS as well as how to perform many of the usual tasks.
There are various free options out there, based on a number of different providers. As some examples, I've used the following services, and all of them will give you a free account, and some will also give you private repositories (so that random members of the public can't see your work if that's what you want):
GitHub - unlimited public repositories, uses Git.
BitBucket - unlimited private repositories, uses Git or Mercurial
Visual Studio Team Services - unlimited private repositories, uses Git or TFS
Using an online provider will give you the added benefit of the backups being on a third party - so if your disk fails you'll still have a backup, as well as the other benefits a VCS will provide (the ability to rollback to a specific point in time, annotations about changes, etc.).
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.
I'm a hobbyist programmer and I've created an application for my office. Every so often I need to improve the code, add features or fix issues that come up under certain circumstances - I've found bugs or ineffective coding even after 3-4 months of heavy usage of the application. The thing is that whenever I modify the code, visual studio saves the changes. This means that if I want to use the program I'll have to be really fast in coding and debugging or it won't build - and I won't be able to use it...
Is there any way to keep the old version of the program without having to save the complete project folder elsewhere? Like creating a new version but keeping the option to go back to the old - working - one...
What you are looking for is called source control.
There are many systems out there, two popular ones are subversion and Git.
Used properly, you will have a full history of each file you have in your project.
There are two other answers here regarding source control at the time I write this, but there is another angle on this as well.
You're executing your production copy from the development directory. Don't do this.
When you have developed the program to a stable version, make a copy of it somewhere else and use that copy. In this way you're free to keep developing on the software without destroying your ability to keep using the existing stable version.
As for source control, you should definitely use that as well if you're not already doing it. It would, among other things, allow you to go back and hotfix the stable version with minor bugfixes while still doing major rewrites of the software, as well as the features others here have mentioned, full history of your project, "unlimited" undo, etc.
I'm not sure what you mean that Visual Studio saves the code when you modify it. It does by default save when you build, but I don't think it saves while you're typing.
Anyway, what you're looking for is called a source control system.
You can try Team Foundation Service from Microsoft.
It works fine and you can share youre project whit colleagues.
http://tfs.visualstudio.com/
EDIT:
This is a free of charge option you can use, until you want to share youre project with more than 4 persons!! than you have to pay for TFS
You need source control.
If your project is open source you can use codeplex, it's an open-source Website where engineers and computer scientists share projects and ideas. Its features include wiki pages, source control based on Mercurial, Team Foundation Server or Subversion (also powered by TFS), Git,discussion forums, issue tracking, project tagging, RSS support, statistics, and releases
If you don't want to share your code you can use Team Foundation Server
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. :)