Related
I am working on a website of 3,000+ pages that is updated on a daily basis. It's already built on an open source CMS. However, we cannot simply continue to apply hot fixes on a regular basis. We need to replace the entire system and I anticipate the need to replace the entire system on a 1-2 year basis. We don't have the staff to work on a replacement system while the other is being worked on, as it results in duplicate effort. We also cannot have a "code freeze" while we work on the new site.
So, this amounts to changing the tire while driving. Or fixing the wings while flying. Or all sorts of analogies.
This brings me to a concept called "continuous migration." I read this article here: https://www.acquia.com/blog/dont-wait-migrate-drupal-continuous-migration
The writer's suggestion is to use a CDN like Fastly. The idea is that a CDN allows you to switch between a legacy system and a new system on a URL basis. This idea, in theory, sounds like a great idea that would work. This article claims that you can do this with Varnish but Fastly makes the job easier. I don't work much with Varnish, so I can't really verify its claims.
I also don't know if this is a good idea or if there are better alternatives. I looked at Fastly's pricing scheme, and I simply cannot translate what it means to a specific price point. I don't understand these cryptic cloud-service pricing plans, they don't make sense to me. I don't know what kind of bandwidth the website uses. Another agency manages the website's servers.
Can someone help me understand whether or not using an online CDN would be better over using something like Varnish? Is there free or cheaper solutions? Can someone tell me what this amounts to, approximately, on a monthly or annual basis? Any other, better ways to roll out a new website on a phased basis for a large website?
Thanks!
I think I do not have the exact answers to your question but may be my answer helps a little bit.
I don't think that the CDN gives you an advantage. It is that you have more than one system.
Changes to the code
In professional environments I'm used to have three different CMS installations. The fist is the development system, usually on my PC. That system is used to develop the extensions, fix bugs and so on supported by unit-tests. The code is committed to a revision control system (like SVN, CVS or Git). A continuous integration system checks the commits to the RCS. When feature is implemented (or some bugs are fixed) a named tag will be created. Then this tagged version is installed on a test-system where developers, customers and users can test the implementation. After a successful test exactly this tagged version will be installed on the production system.
A first sight this looks time consuming. But it isn't because most of the steps can be automated. And the biggest advantage is that the customer can test the change on a test system. And it is very unlikely that an error occurs only on your production system. (A precondition is that your systems are build on a similar/equal environment. )
Changes to the content
If your code changes the way your content is processed it is an advantage when your
CMS has strong workflow support. Than you can easily add a step to your workflow
which desides if the content is old and has to be migrated for the current document.
This way you have a continuous migration of the content.
HTH
Varnish is a cache rather than a CDN. It intercepts page requests and delivers a cached version if one exists.
A CDN will serve up contents (images, JS, other resources etc) from an off-server location, typically in the cloud.
The cloud-based solutions pricing is often very cryptic as it's quite complicated technology.
I would be careful with continuous migration. I've done both methods in the past (continuous and full migrations) and I have to say, continuous is a pain. It means double the admin time for everything, and assumes your requirements are the same at all points in time.
Unfortunately, I would say you're better with a proper rebuilt on a 1-2 year basis than a continuous migration, but obviously you know best about that.
I would suggest you maybe also consider a hybrid approach? Build yourself an export tool to keep all of your content in a transferrable state like CSV/XML/JSON so you can just import into a new system when ready. This means you can incorporate new build requests when you need them in a new system (what's the point in a new system if it does exactly the same as the old one) and you get to keep all your content. Plus you don't need to build and maintain two CMS' all the time.
I need to come up with a CM process for PLC code.
Currently, the system is developed using RSLogix 5000. The build product is a monolithic file that can be loaded onto a PLC for execution and edited directly in the development environment. With multiple developers, this has become a problem. They're stepping on each others changes.
As an analogy, it's as if, when doing Java development, the only wway to edit and save the source would be to load up a *.jar file into your IDE, make the change, and then save it back to the jar file. This is less than ideal.
How can I coordinate changes between multiple developers working with PLC's?
If we are talking about one big binary files, then a VCS (centralized or decentralized) is not the best tool for the job.
An external referencial (a shared disk for instance) where a batch will copy and label the current PCL state is better.
See "Tracking Software History"
To avert discontinuities in the historical record of revisions, old versions of programs must be stored.
“We take it a step further, though. Using our MDT AutoSave, we actually go out and interrogate the equipment. Overnight or at whatever frequency is specified, the software reads the programs in the PLCs and then compares that information to the last known program. The version-control software will copy the new program and store it and [then] compare it to the last one.
Launching version control is fairly simple. Required is software installation and then hardware configuration. “You would need a server and a couple of weeks of engineering and you’re good to go,” Perysyn says. However, his company uses a “shrink-wrap approach” that involves installing the software and then customization by users filling in the blanks.
That being said, when you have multiple changes from multiple developers, you need an integration environment where a first delivery can be done and validated, before pushing it to the actual server.
See also this post.
I use Unity Pro, so this may not apply for other brands.
Unity can export an "archive" file which is XML which describes the PLC program and IO setup in its entirety. After commissioning changes, I create an export and check it in to my local Git repo. This gets me an annotated history of changes, but no visual comparison. I can always use UnityDiff for comparison.
Check out http://www.mdtsoft.com/ also
You need specialized versioning system for PLCs like VersionDog.
From the manufacturer:
"Special support with Smart Compares for SIMATIC S5, SIMATIC S7,
SIMATIC PCS 7, WinCC, WinCC flexible, InTouch, CoDeSys, TwinCAT,
Phoenix PC WORX, RSLogix, Schneider Modsoft, Schneider Concept,
Schneider Unity, SINUMERIK 840D, Bosch IndraWorks and more. Also robot
programs from ABB and Kuka and office related data formats like
Microsoft Word, Microsoft Excel and Adobe PDF are perfectly supported
by versiondog.
Update: Here is a screenshot showing ladder version compare. I guess that's what most PLC folks are interested in. We also use it to schedule e-mail report if PLC offline and online application versions are a match, as an alarm that something has been changed in PLC but not put into version control server.
About RSLogix5000 specifically, I have seen developers use an emulated PLC and make their changes online. The final product once developed is then put together with all the comments (as they are not contained in the PLC) and then commissioned. There are issues with changes that cannot be done online, such as AOIs. There are tools in place to stop two people editing the same logic online at once and to take ownership of sections. Backups can be done in the form of uploads, but there isn't any way to track changes.
It is a messy problem, messier still for when you are maintaining a system as you want an .ACD that you can go online with, as unless you are somehow doing a diff with the RSLogix compare tool you just see unreadable machine code like "+|Éû³´¬ÙÆW×晵‚>Ù,"
The most common revision control I have seen (sadly) is just saving the the latest file, then taking a copy and adding the current date to the file name, like the recommended control.com post described.
RSLogix5000 has always prohibited multiple users from opening and editing on the same .ACD simultaneously. However, if multiple users have identical .ACD files, open them, and all make connections to the same target controller, they each can edit on the controller simultaneously, but only if they are working on different routines. Other's edits appear automatically, if they were to look at another programmers routine.
Note that working online like this is usually done with the PLC running, even sometimes with the target system (some kind of machine) operating. This kind of arrangement for the purpose of completing work faster, or in some cases because the system is huge. No one develops like this, as it is really a debug tool and impractical for significant changes.
If one programmer finishes, and another is not done, the unfinished work of the other will be saved to the first programmer's .ACD when they save. Whoever saves last will have everyone's work.
Like others have mentioned in this thread, using file date is fairly reasonable. Some companies use a version control variable that is usually displayed on a connected HMI. Other companies use a separate document that documents who and what changes. Sometimes version notes are placed in a lengthy rung comment in the main routine.
My company uses a separate change log, and dated archive copies are maintained. Multiple programmers are only used in the most extreme cases. Someone is always designated to maintain the offline file integrity, usually the person who will be working the longest, or the project manager.
It is important to note that rung comments are not carried from one user to another before RSLogix5000 v21 because previous versions didn't store comments on the controller.
All this said, you might be trying to manage offline development. I haven't seen any sophisticated methods for this. Usually programmers write the needed routines separately, and a project manager will assemble them into a single project. The cleanest approach I've seen is where a project manager will create an architecture with global functionality, and assign routine work to others, giving them a copy of the .ACD to work with. They return the .ACD with changes, and the project manager copies and pastes their routines into the "master" project.
This is a very good question and it really depends on what you want it to do.
If you are only using Rockwell equipment it might be helpfull to look at their solution, I think it's called FactoryTalk AssetCentre.
Currently I am looking into using Bazaar from Canonical.
One thing that VonC pointed out is that a piece of software that can interogate the PLC is a deffinate plus, not a must in my oppinion but it sure as hell helps.
Am I reading your question properly and you have multiple developers working on the same PLC code at the same time? It's a scary thought but I know it sometimes needs to happen, Siemens PLC's are a bit easier to program with multiple developers but I would assign one person to consolidate and test all the changes before committing to the PLC. Any CVS system will let you create branches for every developer but how you would get them to consolidate their changes is the million dolar question.
Bart.
A simple thing to do would be to do a text diff on the .l5k files so you can easily see whether a developer has been messing with part of the file that is outside of their scope.
I saw this question just now from a link at stack exchange: Are There Realistic/Useful Solutions for Source Control for Ladder Logic Programs. Rather than have a link only answer, I'll dupe my answer here:
There is actually a canned solution - from GE-IP of all places. Check out Proficy Change Management. This product does version control from a PLC control systems point of view, rather than a pure version control of files point of view - it works as a layer sitting on top of a VCS (the scary part is that originally this VCS was Visual SourceSafe) and handles rights management, reporting and checkout/checkin.
While the product is from GE-IP, it is designed to support a variety of PLC and HMI systems out of the box.
Full disclosure, I used for work for a company selling and installing PCM (but that was 7 years ago). So if you ask me what it was like back then I'm likely to tell you where it all went wrong!
In my company we just started a trial with Copia.io
Check it out. Our first tests look very promising!
It brings, branching, merging, ladder diff etc... for multiple PLC platforms (Rockwell, Siemens, Codesys)..
PS. I work for a company that builds machines, we were looking for version-dog alike solutions with a bit more power in collaboration and diffing capabilities. I used tools like Mercurial, Git, Tortoise in past companies (not for PLC though).
I'm beginning development on a solution that will plug into an existing application. It will be made available for public use.
I have the option of using a newer technology that promotes better architecture, flexibility, speed, etc... or sticking with existing technology that is tried and tested which the application already uses.
The downside of going with the newer technology is that a major change to an essential config file needs to be made to support it. If the change goes wrong the app would be out of service. Uninstall is also an issue as future custom code by other developers may require the newer tech and there's no way this can be determined.
How important is this issue in considering an approach?
Will significant config changes put users off deploying code, or cause problems for them later?
Edit:
Intentionally not going into specifics about technologies here to avoid the question from being siderailed.
Install/uninstall software can be provided but there is some complexity involved which may cause them to foul up on edge cases resulting in a dead app. (A backup of the original config would be a way to mitigate that.) Also see the issue about uninstall above where I essentially can't provide one.
Yes, in my experience, any large amount of work will make users think twice about deploying or upgrading.
It's your standard cost/benefit analysis done by businesses with just about every decision. Will the expected benefits more than outweigh the potential costs?
When we release updates to our software, there's almost always a major component that's there just to assist the users to migrate.
An example (modified enough to protect the guilty): we have a product which generates reports on system performance and other things. But the reports aren't that pretty and the software for viewing them is tied to a specific platform.
We've leveraged BIRT to give us intranet-based reporting that looks much nicer and only needs the client to have a web browser (not some fat client).
Very few customers made the switch until we provided a toolset that would take their standard reports and turn them into BIRT reports. Once we supplied that, customers started taking it seriously - the benefit hadn't changed, but the cost had gone right down.
You've given us no detail, so we can't answer with any specificity. But if your question is, will a significant portion of your potential userbase be deterred from using your product if they have to do significant setup work, then the answer is yes. I've seen this time and time again, with my own products and those that I've installed myself. When the only config change is an uninstall and reinstall. People don't like to do work.
You may want to devote more effort than you've considered so far to making the upgrade painless. Even if you're upgrading someone else's framework, you may find the effort worthwhile and reflected in an increased number of installs.
I have noticed that "power users" - developers, sysadmins, etc. - are willing to put up with more setup work.
I'm not sure what you mean by "major config change", but if you're talking about settings / configuration files, then I've been doing something like this:
An application always contains a default configuration which is useful for most users, and which can't be replaced. Instead, users can override one or more of the default settings in their own, separate configuration file. When a new (major) version is released, most users don't need to reconfigure anything: their own custom configurations are still taken from their own configuration file, and possibly required new parameters are taken from the new release's default settings.
It's obvious that most users don't want waste their time adjusting some settings that already were right - and quite rightfully so.
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 6 years ago.
Improve this question
What arguments can be used against using zip files of source code as a form of version control?
In general each developer is working on their own program and has a responsibility for it. But there are times of course when other developers are involved in work on that program.
Each developer has their own naming convention for zip files ranging from appending the date, a number after the program name or even appending _old / _oldold _newversion etc… When there is collaboration on development of some code. It has to be checked who has the ‘latest’ version of the code – and where it resides, usually the correct version is identified.
There is no easy existing method to diff source trees and during development unwanted changes occasionally slip into code.
The zip file corresponding to software releases that have release to manufacturing are archived. This at least adds some traceability.
Also before RTM there the code is peer reviewed against the previously released version so quality assurance does exist.
Are there any formal white papers explaining the advantages of source control, making clear that the above isn’t a fully valid form of source control? Arguments exist here that since the end product (manufacturing releases) are under control and these are reviewed that there is no problem with the process. Developers do not have too much of a problem working with zip files in this way, but may not be aware of the advantages.
Creating and managing zip files is error-prone.
Real source control gives you tools to understand your code:
History browsing
Diffs between revisions
Annotation of source files to track the origin of a change
Real source control isn't difficult, there's lots of help out there.
The best argument is surely that using a version control system like Subversion or Mercurial is much, much easier and more secure than messing about with zip files. I doubt there has been much paper writing on the subject, as the use of
zip files for this purpose is fairly obviously wrong.
There are a number of SO questions on the general advantages of version control. For example How can I convince my department to implement a version control system? and https://stackoverflow.com/questions/250984/do-i-really-need-version-control
I assume you currently work at a company that practices this method of zip control, and you're looking for ammunition to help you change this practice. There are a lot of questions on StackOverflow about source control, and the community here are in near-total consensus on the benefits of proper source control and the horrors of working without it (for very good reason).
I'll add something here to benefit your battle: YOUR COMPANY IS #$#%&$## CRAZY!!! ZIP FILES??? ARE YOU ##$##% KIDDING ME???
I am assuming that this question was asked because the original poster is working in an office where the standard practice is to share zip files.
Zip files are obviously bad, for the reasons given by Ned Batchelder. The biggest reason I would suggest is that it's clunky, and difficult to merge changes, or get diffs between past revisions easily.
I would recommend you read A Visual Guide to Version Control for some good arguments about why version control systems are very useful, and a superior way of managing code.
I suspect there'll be as many white papers comparing zip files to proper source control as there'll be white papers comparing cutting one's genitals off with a rusty butter knife with buying a puppy.
Zip files work as a very basic form of version control. It's a way to separate "states" of the source. However, it's not a good form of version control because you have to do a lot of work to perform basic source control management tasks. For example:
Bob's team is working on a major feature that requires changing dozens of files. He works in his own private zip-controlled area for a while. He's created 30 new files, added features to 12 existing files, and made changes to existing behavior in 3 existing files over 4 months. How do you merge Bob's work with the main trunk that has also evolved over the last 4 months? Do you hand-diff thousands of lines of code and decide how to merge them? How do you ensure that anything that uses the 15 existing files isn't broken? How do you ensure that Bob's features or main trunk features aren't accidentally omitted?
Alice is investigating a bug in her code and realizes that one of Sam's classes has changed its behavior. Sam says he didn't make the change. How does Alice find when and why the change was made? How does Alice know who depends on the change?
A major customer has reported a bug in an older version of the program. This customer needs a fix and is important enough to warrant a patch. How do you add the code to the old zip file in a way that it also exists in the new files? Also, how do you record that there is a relationship between the two changes?
These are just three scenarios that a version control system handles well. Situation 1 is handled by development branches. Almost every version control system has a notion of branches that can be developed in parallel and merged as needed. Situation 2 is easily addressed by any source control system with a "blame" feature and less easily addressed by just searching commit logs. Situation 3 is a variant of situation 1, but when you merge branches most version control systems make a note. For example, you'd make a branch off of the old version, fix the bug, then merge that branch into the new code. Now when someone asks "Where did this change come from?" they see it was merged from the patch branch and the change was made to fix a bug.
By the way, I've been in each of these 3 situations and used both SVN and Perforce; both made finding a solution very easy.
These people already know all the arguments for SCM, there is nothing anyone can say to them that will sell them on it. These things must happen:
You install SCM on your local machine and use it. If you must, have it autogenerate these .zip files at every build, so no one outside your cube knows the difference.
Some kind of disaster occurs, like loss of work, show-stopper bug is re-introduced or some other worst-case scenario that is the real reason we all use SCM (the other features we learn to appreciate later).
You are unaffected by the disaster, and/or use your personal copy of the code in SCM to fix the problem/recover the lost work/whatever.
You are a hero and everyone wants to know how you did it.
Only by experiencing firsthand the pain of loss caused by poor SCM practices will your organization realize the benefits of SCM. You're smart enough to learn from the mistakes of others, but not everyone is. The rest of the time, you'll just be 2/3X more productive than the rest of the team and maybe, just maybe they'll wonder how.
By the way, this is how you get agile, continuous integration, unit testing, etc into the organization: lead by example.
The ZIP solution requires a pro-active step at the end of the development cycle when things tend to get dropped because no one outside the dev group notices when they doesn't happen. Sort of like that final code cleanup you always plan on doing when things slow down.
An SCM integrated into the dev environment pretty much enforces/encourages keeping a version history with a small amount of effort all the way through the process. This makes it more likely that a version history will actually be created.
On Using ZIP as a SCM
I'm not going to take as hard of a line as some of the others on the ZIP file solution. It is at least better than nothing. It is a perfectly valid way of keeping version histories, it is just a lot more labor intensive, error prone, and lacks a lot of useful features.
Know who you are selling to
Someone in the Dev Group: Focus your arguments on features like ease of troubleshooting by using change histories, safety to experiment with big code changes (because of rollback), and avoiding accidents where work is overwritten by other developers.
Non-Tech Managers/Bean-counters: There are free/low-cost tools that will reduce the labor cost of version control and give greater accountability/transparency into what each developer is doing/the source of coding mostakes.
I wrote a Version Control tool long ago for a company who did the authoring for DVD titles. Before that they had nothing, just a directory full of clips, icons, scripts etc. which anyone could hack away at, and no way to backtrack if it went wrong etc. HOWEVER these people were 'artists', not programmers, so they could not (would not???!) be trained to use a decent Version Control system. So as a bare-minimum, get-out-of-the-mud level tool I wrote a utility which zipped up the current state of the directory, gave the Zip a meaningful name (date + comment supplied by user) and stuck it in a Backups directory, and also allowed you to restore one of these backups.
So zips CAN provide minimum-level version control, and I speak as someone who endorsed that approach when it was right for the skill-level (in terms of programming, I don't want to imply that they couldn't manipulate pixels!) of the people using it.
But as a programmer, you should be thinking to use a tool which really helps you. As such you want to be able to compare differences for individual files, compare differences between complete milestone sets, and (if you are working on anything other than trivial programmes) handle branching and merging. If you want these features you need something BETTER than zip files.
I used to use ComponentSoftware RCS, and if it wasn't for its poor performance over a WAN we might still be using it: it is cheap (even free for single-developer use, in which form I used to use it at home) and simple to use. However nowadays I would suggest looking at SubVersion. It is very flexible, reasonably simple to understand, has a good set of Windows tools to make it even easier (e.g. Tortoise, Ankh), and ... best of all ... you can get it running for free.
It's not good as only creating a zip before a release means loosing a lot of power you get with version control.
Useually you should check in to the repository after you have added/removed/changed a functional aspekt. So that you can go back later when an error occurres that you think migth be because of this change. Or when you say "dammed this worked before the file format changed in someday in march." Naming revisions after changes makes it also easier to remember because you forgot what was done on 27 march 2009.
In general each developer is working
on their own program and has a
responsibility for it. But there are
times of course when other developers
are involved in work on that program.
In a normal development shop, this is not at all true. Different people work on the same source code all the time. XP makes it almost mandatory. Even if you separate the code into modules, there will still be interaction points with code that concerns at least two programmers.
Of course, it's almost impossible to collaborate without major problems if you don't use source control. But the scenario you describe is much more a way to adjust to this limitation than a sane project structure.
Having only a single person working on a module means that nothing will happen when that person is on vacation and you have a major problem when he leaves the company, gets sick for a long time, or dies.
How do you do a merge? How do you do an annotate? How do you bisect? Where are changelogs stored? Just go to wikipedia and look up "Version control" and go down the list: zip files can kind of sort of do about 2 things out of the whole page.
This is like asking "What arguments can be used against shorthand as a form of double-entry bookkeeping?". It's a completely different thing.
For arguments, there's Walter Tichy's original paper on RCS.
For missing features, among many others there's the ability to merge changes from different versions. This is especially well supported by tools like git and darcs, and to a lesser extent mercurial.
P.S. To Mercurial fans: the problem is that Mercurial delegates the merge process to external tools, and it's very difficult for the mercurial novice to know which tool to use, or to understand how they work—the mercurial model of merging seems far more powerful than others but correspondingly difficult to get a grip on.
I haven't seen an answer include Eric Sink's Source Control HOWTO, but it's a valuable reference. I haven't seen any formal white papers on version control, but I'm not sure the argument about "validity" is your strongest one. The problems you describe in your question indicate some pretty serious drawbacks with the current approach. If "the powers that be" in your environment aren't convinced by that, change the argument entirely.
If you make it a question of quality control, and point to continuous integration as a practice that encourages it, then the zip file approach to version control isn't a "not fully valid form of version control", but an obstacle to implementing continuous integration as a practice.
Your question doesn't indicate whether or not the end product "under control" is tested in any automated fashion (in addition to being reviewed). If the process you describe would prevent that from taking place as well, certainly add that to your argument too.
I think your best argument is showing a GOOD form of source control and showing how powerful it is. Don't trash what is currently being done (as someone is surely emotionally attached to that). You don't want to trash the "ZIP Source Control Method." Show the power of something like SVN. Make it very easy to explain. Show common use cases. (A solid demo would help.)
Let the source control version sell itself.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have the opportunity to give a formal presentation to my boss about anything that benefits the company. My idea is to adopt source control in my workplace. I have been using Mercurial to manage my own project at work, but the rest of the team does not have a formal source control system in place. Unfortunately, I'm not very good at presenting ideas.
So, can you guys tell me why developers MUST use source control? Additionally, why would you choose any tool except Visual SourceSafe? I don't have experience using VSS, but he is likely to ask why we wouldn't just use Microsoft's tools.
I want to hear opinions from the many smart programmers here! My preferred options are SVN or mercurial. Both seem to have good support for their Windows versions, and both are less archaic than CVS. Also, as a self-declared open source disciple, I would prefer to suggest an open-source tool. :)
Thank you!
Edit: To make it short, generally, current practice for other developers is copying folder, tag with date and maybe record on their own. You get the picture. What if my boss says "if it works, why fix it?"
Let's compare two examples, one development environment that uses source control, and one that doesn't.
A: Does Use
B: Does not Use
Scenario 1: A project is requested, completed, and rolled out
A + B) Programmers develop the project internally, when it's completed, push it out to testing, and then deliver to the client (whoever that may be)
Not much difference, in the big picture
Scenario 2: After a project is released, the client decides that they don't want feature X
A + B) Developers remove the code that the client doesn't want, test, and deliver.
Again, not much difference.
Scenario 3: Two weeks later, the client decides that they actually DO want feature X
A) Developers reintegrate the code they took out in 2 back into the normal development tree, test, and deliver.
B) The developers search for the old code on their personal machines, the file server, and backups. If they find the code, they must manually reinsert each file. If they do not, they probably have to recode that entire feature.
It's easy to get old code that you took out for one reason or another
Scenario 4: There's a strange bug in the system where a function is supposed to return a boolean result, but always returns false. It wasn't like that two weeks ago.
A) Developers examine all the old versions of the software, and figure out that a return false directive isn't in the proper scope - it's executing inside a loop instead of outside.
B) Developers spend weeks trying to figure out what the problem is. Eventually, they notice the return on the wrong line, and fix it. Not having source control means they had to examine each and every file that was executed, rather than finding the differences from when it was working and now.
Scenario 5: Someone breaks the build. It gets past testing and is only noticed weeks later.
A) The team examines the commit history, finds out who broke the build, makes that person fix it and buy the team dinner.
B) The team has to go back through the entire project to find the error, but can't figure out who put that code in. Developers blame each other, and the team dynamic fails.
It's easy to see who committed what, when, and why.
Use source control because neither you nor your team are perfect. The primary function of source control is to ensure that you have a complete historical record of your development process. Having this record, you have the ability to confidently branch out with "experimental" versions, knowing that if the experiment fails, you can back up to an earlier version.
In addition, a good source control system like svn will permit multiple developers to work on the same file and provide powerful tools for reconciling the differences that each introduces.
Simply - so you have a true history of the code - to investigate changes (reasons for bugs), revert to versions, audit, etc. Backup isn't enough - you simply have a copy of the current picture. Ever change a file and wish you could remember what you did?
You have to use Source Control for these reasons
1) You can rollback to any version
2) Different developers can work on the same files
3) All developers, will have access to the same code base
4) You can track changes
5) You can rollback changes that don't work
6) Source control is the basis of continuous integration and helps massively with TDD
7) If you don't use source control, you will slowly go mad as files get lost/overwritten and nothing works as it should
VSS is not the worst SCC application, I used it for years and grew to hate it, but it does work, is simple, and many people know it.
Here's a simple real-life example.
A few years ago, my boss says, "Feature XYZ used to work, and now it doesn't. No one knows what happened. Can you fix it?"
Now I've never worked with feature XYZ before. So fixing it would involve a lot of flailing around trying to figure out what it does.
But we have source control! So I do this:
Create a test script to test feature XYZ: "Click here, type this, click there, etc."
Get current version. Build. Test. Feature XYZ is broken.
Get version from a week ago. Build. Test. Feature XYZ works.
Get version halfway between those two. Build. Test. Feature XYZ works.
Get version halfway between previous one, and current one. Build. Test. Feature XYZ is broken.
I kept doing this binary search until eventually I hit the point of change: version 145 (we'll say) had the feature working, but version 146 had it broken. Then I just did a compare between those two versions to see what changed. Turns out our technical lead (sigh) had checked in code that changed functionality, but also introduced a side effect that broke feature XYZ.
So I removed the side effect, tested...and lo and behold, feature XYZ worked again.
Without source control, you can never do this. You'll have to flail around, changing one thing or another, hoping to magically hit on the thing that makes feature XYZ work again.
With source control, you just test your way through the versions, pinpoint the exact code that caused the problem, and fix it.
Microsoft (MSDN) has a good article on the benefits of source control.
http://msdn.microsoft.com/en-us/library/ms173539.aspx
There are also lots of good questions here on SO as to the pros and cons.
What are your pros and cons of git after having used it?
Subversion is very popular, but Git is going to be the "next big thing" in the source control world.
It seems to me that most people have covered the major feature of source control but one of the biggest positives is skipped over. These are:
Branches
Without a source code repository it is impossible to create branches (or copies/stream/etc.) of your code for particular purposes. Not being able to create and merge branches is one of the biggest things that disqualifies VSS from being a real source code control system. Some of the purposes of a branch include:
Bug Fix
Sometimes you need to resolve a bug and do it in a place away form the mainline or trunk version of your code. This may be to resolve a problem in the testing environment or any number of reasons. If you have a version control tool you should be able to easily make a new branch (something VSS sucks at) to fix the bug and be able to merge it back into the mainline code if necessary
Maintenance Release
This could be much the same as a bug fix but done after code has been released to production. Examples would be for fix packs, service releases, etc. Again, you want to be able to merge the changes back into the trunk if necessary
New Feature
Sometimes you need to start development of a new version while maintaining your current code. For example you release and maintain v1.0 but need to start work on v2.0 while maintaining v1.0. Branches help resolve this situation
Tagging/Labeling
Another thing source code control systems do is make snapshots of the source code at a particular point in time. These are called labels in VSS, tags in subversion, etc. By creating these on a regular basis and linking them to some substantial milestone in your project it then becomes possible to determine what exactly has changed in your code between releases. This can be important for auditors but also in tracking down the source/scope of an issue. VSS also gets a fail here because VSS only versions the files, not directories. This means it is impossible to re-create a previous version of the system if you rename/move/delete files or directories in the repository (something that happens a lot if you refactor). Good source code control systems like Subversion do just this.
I suggest using SVN, because:
Source control gives you excellent history. You can see where what changes have been made, thus providing a great way to see what's changed over time (even better if you fill out the submit summary each time)
To the developer, it provides an excellent fallback if something goes horribly wrong. You can revert changes to a file back to any point in its history, so you can try out that mod you wanted to make, and if it doesn't work, roll it right back easily.
It provides a central repository that is much easier to back up than running around to different developers' computers.
It allows you to branch a project off in a different direction - useful for specializations and customizations.
It enables more than one developer to work together on the same project, and the same source, by letting you merge and otherwise manipulate changes to one central copy.
I suggest NOT using VSS - see this page for reasons:
http://www.highprogrammer.com/alan/windev/sourcesafe.html for more reasons.
If the current process is copying a folder and giving it a date, isn't that so that you get some sort of development history, so isn't that basically a simple form of source control?
So to answer any criticisms about source control, you're already doing it. Now you just need to point out the weaknesses in the current system and suggest a better one.
Why do you need to re-invent the wheel when people have really thought about a lot of the complex scenarios which can occur during development and developed the tools which let them handle them.
What you're currently doing is very fragile and will fall over if any sort of complex scenario comes up, at which point you'll have to expend a lot of energy working out how to do something that the tools already do. VSS is better than what you're doing, but doesn't have the very useful conventions that SVN, git or mercurial has which allows multiple projects to live together in a well organised manner - I'm talking branches, tags and merging, both of which are fragile and basically a nightmare under vss.
SVN does have plugins for visual studio. Some are free. But I find that tortoise-svn just eclipses anything else. The only benefit I find with a plugin is that new files get added to svn automatically.
So, weaknesses of your current system:
If you have to make a change to a file, you are likely to overwrite or be overwritten by the other dev's changes. You may not even notice this.
If you have to remember which files you've changed to copy them over some 'master' copy, you're likely to miss one at some point.
Good luck ever finding any documentation about when you made a change and why.
How could you ever build a stable automated build system on your current system? Cruise control and hudson work really well, you're hobbling yourself
VSS doesn't group changes to multiple files together very well. Everything modern does this extremely well and with atomic consistency.
VSS branch and merge support is awful. When we used it we ended up bracketing every change with comments in source code and manually copying code around rather than relying on VSS merge.
It's going to be very hard, near impossible in your current system, to have some version of the code in live maintenance and some other, later version, in heavy development. Think about what's needed to keep two projects in sync like this, you'll need a good tool. SVN can do it, git can do it really well.
That might be enough to go on with, can do more.
Having some version control system helps in any, many cases:
Single developer, single branch
The most basic task that each version control system has to perform perfectly if it wants to call itself version control is to be able to go back to specified version of a project. If you made mess of things, you can got to previous version. You can examine some previous version to check how it was done then (for example how it was before refactoring, or before removing some code/file).
Version control systems take much less disk space compared to simply saving backup copies with specified date, because they use deltaification (storing only differences from previous version) and compression. Usually backup systems are means to store last N versions of a project, sometimes with N=1 (only previous version) while version control systems (VCS) store all the history of a project. Knowing Murphy a while after deleting Nth last version you would realize that was the version you want to examine.
Additionally going back to some last version is easy and automated. You can also examine how single file looked like at some past version, and you can get differences (in diff format) between current state and some past version. You can also tag (or 'label') versions, so you can refer to past version not only by date, or by being nth version from current one, but also by symbolic name, for example v1.2 or v1.2-rc0.
With version control system you can examine history to remind you why (and how) some piece of code (some part of a given file) arrived at current state. Most VCS allow to examine line-wise history of a file, i.e. annotating each line of a file when it was changed, in what commit, and by whom (the command is named annotate, blame or praise depending on VCS). In some VCS you can search history for a version (revision) which introduced given fragment of code (e.g. called 'pickaxe search' in Git, one of VCS).
For this feature to be really useful you have to maintain some discipline: you should describe each new version (each new revision / each new commit) writing down why the change was made. Such description (commit message) is very useful, but it doesn't have natural place in backup system.
This feature of course is even more useful if you are not the only developer...
Using version control system allows for alternate way to find bugs in the code, namely by searching history to find version which introduced bug: bisectiong history. When you find revision which introduced bug, you would have limited (in best case: very limited) area to search for bug, because bug has to be in the difference betwen last working version and first version with a bug. Also you would have description of a change (a commit message) to remind you what you wanted to do. This feature is also called sometimes diff debugging. Modern version control systems (VCS) have support for automated (or semi-automated) searching the history by bisecting it (dividing history in half, finding which part contains bug, repeat until single responsible version is found), in the form of bisect (or similar) command.
For this feature to be really useful you have to maintain some discipline: you should commit (save changes / put given state in version control system to remember) single change, dealing with only one feature, with only small difference from the previous version; i.e. commit often.
Most version control systems offer various hooks which allow for example for automated testing, or automated building of a product... or simply reminding you that you do not follow coding standard (coding guidelines).
Single developer, multiple branches
Version control systems allow to create multiple alternate parallel lines of development, called branches (or streams, or views). Common case is having development branches, i.e. having separate branch for unstable development (to test new features), separate branch for stable (main, trunk) version which is (or should be) current working version, and one on more separate maintenance (fixup) branches.
Having maintenance branches allow you to do bugfixes and generate service packs / minor version with corrections to some released version, without need to worry about interference from the new development. Later you can merge maintenace branch into stable, or pick bigfix from maintenance branch into stable and development branches (if further/other development didn't fix bug independently).
Modern VCS (here modern means that both branching and merging branches is easy) allow to go a bit further, i.e. generate separate branch for working on a separate feature (so called topic branches). This allow you to switch between working one one feature to working on other feature (and not only switch from eveloping new feature to working on urgent requested bugfix).
If you are developing your product based on source of some other (usually third party) product, you really should use vendor branches to be able to easy integrate new version of a product from vendor with the changes you made. Admittedly this is no longer purely "single developer" case.
Multiple developers
Using version control systems brings even further advantages if there are more than one developer working on the same project. VCS allow for concurent (parallel) development without worrying that somebody would overwrite your changes, or does not take your changes into account. Of course using version control system is no substitute for communication.
All of the above features are even more important in the multiple-developer case: examining who generated given change, who last changed the code (aka. who broke the build), finding a bug in code not written only by you.
Simple: If the code is not in source safe, it doesn't exist
Subversion is free and better than VSS but VSS is definitely better then nothing.
Before you say anything, find out why your company is not using source control.
Once you know why, it is easy to come up with scenarios where source control can help.
Long discussion on why you should absolutely have source control:
Is Version Control necessary for a small development group (1-2 programmers)?
My comments from that thread:
You always, always want to have some
sort of Source Control even if you are
working on a project by yourself.
Having a history of changes is vital
to being able to see the state of a
codebase at any given time. There are
a variety of reasons for looking back
in a project history which range from
just being able to rollback a bad
change to providing support for an old
release when the customer just wants a
patch to fix a bug rather than
upgrading to a newer version of the
software.
Not having some sort of source control
is pure insanity.
As far as VSS goes - it's certainly better than nothing. It's definitely not the best source control and it's very dated, but the fact it that it continues to do the job for an awful lot of companies out there.
If your boss is determined to stick with Microsoft tools, go for Team Foundation Server instead of VSS. It's a much better system than VSS and it has nice features like integrated bug tracking.
Take it from me, VSS blows. It's basic file storage w/ history. Anything is better than VSS and VSS is better than nothing :)
So, can you guys tell me why
developers MUST use source control?
It provides one method for an entire
team to use; everybody operates under
the same 'ground rules'.
Changes are
orderly vs. chaotic, saving
development time.
The ability to track
changes promotes accountability and
makes it easier to find the right
persom to solve problems in the
materials maintained.
A list of exact
changes made can be generated quickly
and easily, making it easier to
advise users of the information on
how it has changed from version to
version.
It is easy to 'roll back' to
an earlier version of the
information, if a serious mistake was
made during a change.
Source Control is like insurance! You hope you never need it, but are glad you have it when you do!
Why do a formal presentation?
Assuming the team size is at least two, do a real-world example: Let two (or more, the more the better) people get the code, make their changes and show what it takes to integrate all those changes using whatever non source control means you use.
Then do the same scenario using the source control.
The amount of time and pain you save by using source control will speak for itself.
Stick to the bottom line, explain how it relates to money and your boss will probably listen.
If you are only one programmer, I'd say the main argument is the reduced chance that you will waste time (and therefore money) fixing simple mistakes, trying to rollback code that turned to be the wrong idea etc.
If you are more than one programmer then the above goes twice plus it's the only sane way to be able to work together on the same codebase without wasting even more time waiting for eachother,
Visual Source safe is better than nothing but there are free options that are better in almost every respect. If your boss needs a presentation to understand why source control is essential he might not care what tool you use once he has been enlightened. That you have experience with other tools and not vss again relates to the bottom line so that might suffice.
Why shouldn't your team adopt source control?
Even as a solo developer, I use source control. In a modern software development environment, I can think of few if any reasons why you would not use source control. It is more surprising that you don't already have it. The question strikes me as something like house painters asking "Why should we adopt the use of ladders. You know, ladders don't get the house painted - brushes do."
I'm really sorry but if you actually have to argue for [the formalization of] source control in a development environment, you're in a hopeless situation. If your boss actually needs to be convinced that source control is a worthwhile endeavor, your boss is simply not suitable to be a manager of a group of software developers. In order for someone to effectively manage, they really need at the very least a basic understanding of the landscape. I can't even imagine what's going to happen when you actually need to argue for something that's worth having an argument and doing a presentation over.
Developing without source control is like driving a car without breaks. You lose the ability to do seamless concurrent development, you lose your code getting backed up in working copies, you lose the ability to do historic research via code annotations, you lose the benefit of seeing the context and comments that accompany discrete changes, you just lose, period. Using source control is so obvious and has so many benefits, it's shocking that you'd have to justify it.
At work, we use subversion, but some developers (myself included) use Git locally via the git-svn bridge. For personal work, I use Git.
Because:
It will reduce costs - Developers will have to spend less time checking an item in/out of a real VCS than their current ad-hoc approach.
It will protect the organization's intellectual property - this should be the most important consideration for any software company (other than data...). You are payed to create software - shouldn't it be accessible in its entirety?
It will provide quicker, more reliable and straightforward backup mechanisms - all VCSs have built in dumping capabilities. These tend to be more mature than a simple file copy.
It will act as a communication mechanism between developers - depending on the version control system you may use comments/labels/checkout status to determine if someone else has worked on a file, if it has been promoted to production, if it has a corresponding support ticket number etc.
It streamlines development - the ability to compare versions of files as well as the other mechanisms will be beneficial to your company period.
The main reason we use version control is consistentency.
If the projects are not consistent then problems are going to occur and code is going to be lost.
Make sure you have buy in for the rest of the team. Maybe you can test your presentation on them? Hopefully, they see the need as well.
Nice to see good practices being initiated from the bottom up. Maybe everyone will be more likely to adopt the practice if it comes from one of their own instead of some management mandate.
To avoid things like
"Hey! What happens ? It worked yesterday."
The easiest way to convince management to invest Time in a SCCS is focus on backup and archival. By utilizing something like Subversion (SVN), you can restore any project to any point in time instantly. There is no need to have someone look through backup tapes or worry about tracking multiple versions in an obtuse directory structure.
There are obviously many other advantages (i.e. 2 people working on the same file at the same time), but backups are what quickly sold my company many years ago.
Others have mentioned the specific benefits of source control elsewhere, but I wanted to explicitly address the "VSS" portion of the question.
If your boss wants to use a Microsoft tool, Team Foundation Server with Team Suite is a very nice combination. It also has other tools included, such as bug tracking, documents, and reporting capabilities, which makes a nice platform on which to later improve your process. We are quite happy with it where I work, and my coworkers have told me horror stories about VSS.
Keep TFS in mind as a response to the 'Microsoft Tools' question.