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.
Related
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.).
i have a project where i do something i have same copy from another who have do something in it later i have a thing to do currently.
so that's three copy and i am unsure that i am not confused with it. sometime i call wrong copy for finding the thing i want from them.
without using any software outside our office window any trick to manage all project or how i can manage them and make them one copy.
the same problem with some other problem come with when the same script used in two software , website who are used same script with have a small difference in both.
so i want to know how exactly all other manage them. i want to have a answer with .net plateform.
There are several source control solutions that have plugins to integrate directly with Visual Studio. I would recommend looking into Subversion. Currently at my office we use Vault, but it has some short comings, especially when it comes to renaming or moving a file and then editing it prior to a check in.
http://ankhsvn.open.collab.net/
http://www.sourcegear.com/vault/
I recently started a small pet project. It's written in C# with ASP.NET MVC3. As it's grown, my needs for source control also has grown. Here's what I've done:
Day one, I placed my project in a Dropbox folder. That way, I could reach my project files from all my computers (and even my iPhone).
A few weeks later, when I first had to make some serious changes and neede a fallback, I created a Mercurial repository in my Dropbox folder and commited all my code. I've got a blogpost on that here: http://csharptutorial.blogspot.com/2011/06/using-dropbox-with-mercurial.html. Mercurial is a great versioning system, because it doesn't require a server installation and your repository is copied in full to all locations where it's checked out.
Now, I'm looking at moving my project over to BitBucket (http://bitbucket.org/) where you also share and discuss code with others.
A good alternative to Mercurial is Git, using github.com in stead of bitbucket.org. Both have a learning curve, but they both represent modern version control tools and is well worth having a look at.
Source control and discipline.
You need to get an approach and method for managing your source. A source control system is essential for this. I use SVN and Ankh, as does Clayton.
However, you need an approach for using this. I always have branches. You can have development branches and merge these changes into a release branch when your code has passed all the tests. This way takes a discipline and time, but you need to do this to build quality into your system.
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'm working on the upgrade of my c# visual express 2008 project to a newer version.
How do I manage this without having to copy the whole project directory and work into the copied directory project?
Create a new branch in the source control system that you are using. You can read more about it at Branching and Merging Primer.
If you are not using a source control I suggest you start with subversion. VisualSVN SERVER is an easy way to get started. You can use TortoiseSVN to work with it or visual studio plugins such as ankhsvn or VisualSVN.
You do not really have to install svn server. You can create repository with Tortoise Svn too and use file protocol to connect to it. This means that you can put the repository on your flash drive and query it with you so that you can work from any computer.
Subversion is good, and easy to pick up, but you might also want to consider Mercurial or Git. These are almost as easy to pick up and give you some flexibility in that they are distributed - which I have found makes much more sense for an individual user. These also tend to take up less space in the long run as well.
In addition, for your needs, you will not necessarily need to branch. Get your chosen Source Control installed, and create your repository with your stable version in it. Once you have that, as long as you have a backup in place, you will always be able to get back to your stable version. If you ever have to do a bug fix on your stable version, that would be the time to branch from that version. For a small individual repository, it'll probably be less confusing to keep your main work in the trunk -
Lastly, since you are new to source control, get in the habit of doing one thing at a time, then checking that change in. Your source control tool (or commandline) should be open every time your IDE is, and you should use it often. Even small changes are important to track. Establishing this habit will take work, but will pay off immensely.
Good luck!
I have a three-tier application which is installed in corporate environments. With every server version update, all clients have to be updated, too. Currently, I provide an MSI package which is automatically deployed via Active Directory, however my customers (mostly with 20-300 users each) seem to hate the MSI solution because it is
Complicated to get it running (little Active Directory knowledge);
The update process can't be triggered by the server, when a new version is detected;
Customers can't install multiple versions of the client (e.g. 2.3 and 2.4) at the same time to speak to different servers;
The update process itself doesn't always work as expected (sometimes very strange behaviour healing itself after a few hours)
I've now made a few experiments with ClickOnce, but that way to unflexible for me and too hard to integrate in my automated build process. Also, it produces cryptic error messages which would surely confuse my customers.
I would have no problems to write the update logic myself, but there the problem is that the users running to self-updating applications have too restricted rights to perform an update. I've found that they are able to write to their Local Application Data directory, but I don't think this would be the typical place to install application files into.
Do you know a way to an update that "just works"?
You can somewhat replicate what ClickOnce does, just adjust it for your needs.
Create a lightweight executable that checks a network/web location for updates.
If there are updates, it copies them locally and replaces the "real" application files.
It runs the "real" application.
The location for the application files should be determined by permissions and operating system. If users only have write permission to a limited set of folders, then you don't have a choice but use one of these folders. Another option is provide an initial installation package that installs the lightweight executable and grants r/w permission on a specific folder such as "C:\Program Files\MyApp". This approach usually requires a buy-in from IT.
I hope this helps.
It is really hard to provide you exact answers because critical information about the client side installer is not explicit. Do you install client side files into Program Files? Then you may meet problems when users are restricted.
You don't think Local Application Data is a folder to deploy application, but Google does. Its Chrome browser installs that way on Windows, and its automatic update process is even unnoticable (which may sound horrible). So why not deploy your application into this folder for restricted users? You may find more about Chrome installer here,
http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx
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. It should give you all the flexibility you need for all that you have described.
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)
I plan on extending it more when I'll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn't support.
If you don't want to give your users too many rights, it is possible to write a Windows Service, which will run on each computer under an account with the appropriate privileges, and which can update your application, when a new version gets available.