Safety issues

Welding, without the proper precautions, can be a dangerous and unhealthy practice. However, with the use of new technology and proper protection, risks of injury and death associated with welding can be greatly reduced. Because many common welding procedures involve an open electric arc or flame, the risk of burns is significant. To prevent them, welders wear personal protective equipment in the form of heavy leather gloves and protective long sleeve jackets to avoid exposure to extreme heat and flames. Additionally, the brightness of the weld area leads to a condition called arc eye in which ultraviolet light causes inflammation of the cornea and can burn the retinas of the eyes. Goggles and welding helmets with dark face plates are worn to prevent this exposure, and in recent years, new helmet models have been produced that feature a face plate that self-darkens upon exposure to high amounts of UV light. To protect bystanders, translucent welding curtains often surround the welding area. These curtains, made of a polyvinyl chloride plastic film, shield nearby workers from exposure to the UV light from the electric arc, but should not be used to replace the filter glass used in helmets.^[40]

Arc welding with a welding helmet, gloves, and other protective clothing.

Welders are also often exposed to dangerous gases and particulate matter. Processes like flux-cored arc welding and shielded metal arc welding produce smoke containing particles of various types of oxides, which in some cases can lead to medical conditions like metal fume fever. The size of the particles in question tends to influence the toxicity of the fumes, with smaller particles presenting a greater danger. Additionally, many processes produce fumes and various gases, most commonly carbon dioxide, ozone and heavy metals, that can prove dangerous without proper ventilation and training. Furthermore, because the use of compressed gases and flames in many welding processes poses an explosion and fire risk, some common precautions include limiting the amount of oxygen in the air and keeping combustible materials away from the workplace.^[41] Welding fume extractors are often used to remove the fume from the source and filter the fumes through a HEPA filter.

Costs and trends

As an industrial process, the cost of welding plays a crucial role in manufacturing decisions. Many different variables affect the total cost, including equipment cost, labor cost, material cost, and energy cost. Depending on the process, equipment cost can vary, from inexpensive for methods like shielded metal arc welding and oxyfuel welding, to extremely expensive for methods like laser beam welding and electron beam welding. Because of their high cost, they are only used in high production operations. Similarly, because automation and robots increase equipment costs, they are only implemented when high production is necessary. Labor cost depends on the deposition rate (the rate of welding), the hourly wage, and the total operation time, including both time welding and handling the part. The cost of materials includes the cost of the base and filler material, and the cost of shielding gases. Finally, energy cost depends on arc time and welding power demand.

For manual welding methods, labor costs generally make up the vast majority of the total cost. As a result, many cost-savings measures are focused on minimizing the operation time. To do this, welding procedures with high deposition rates can be selected, and weld parameters can be fine-tuned to increase welding speed. Also, removal of welding spatters generated during welding process is highly labor intensive and time consuming. Implementation of Welding Anti Spatter & Flux which is safe & non-polluting is considered as a welcome change in cost cutting & weld joint quality improvement measures.^[42] Mechanization and automatization are often implemented to reduce labor costs, but this frequently increases the cost of equipment and creates additional setup time. Material costs tend to increase when special properties are necessary, and energy costs normally do not amount to more than several percent of the total welding cost.^[43]

In recent years, in order to minimize labor costs in high production manufacturing, industrial welding has become increasingly more automated, most notably with the use of robots in resistance spot welding (especially in the automotive industry) and in arc welding. In robot welding, mechanized devices both hold the material and perform the weld,^[44] and at first, spot welding was its most common application. But robotic arc welding has been increasing in popularity as technology has advanced. Other key areas of research and development include the welding of dissimilar materials (such as steel and aluminum, for example) and new welding processes, such as friction stir, magnetic pulse, conductive heat seam, and laser-hybrid welding. Furthermore, progress is desired in making more specialized methods like laser beam welding practical for more applications, such as in the aerospace and automotive industries. Researchers also hope to better understand the often unpredictable properties of welds, especially microstructure, residual stresses, and a weld's tendency to crack or deform.^[45]

Concurrent Versions System

Features

CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.

If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format.

Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow "anonymous read access", a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.

Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.

CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.

CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.

In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive modus operandi and support for networked operation – which allow dozens of geographically dispersed programmers to share their work – fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.

– Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005

Terminology

CVS labels a single project (set of related files) which it manages a module. A CVS server stores the modules it manages in its repository. Programmers acquire copies of modules by checking out. The checked-out files serve as a working copy, sandbox or workspace. Changes to the working copy will be reflected in the repository by committing them. To update is to acquire or merge the changes in the repository with the working copy.

History and status

CVS developed from an earlier versioning-system called Revision Control System (RCS), still in use, which manages individual files but not whole projects. Dick Grune has provided some brief historical notes about CVS on his site. To quote:

I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.

– Dick Grune, Dick Grune's website

Grune publicly released the code to mod.sources on June 23, 1986: Google Groups continues to archive and serve the original usenet post.

The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote a paper introducing his improvements to the CVS program which describes how the tool was extended and used internally by Prisma, a third-party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL.

CVS introduced the implementation of branching into version-control systems: the branching techniques in other systems all derive from the CVS implementation.

CVS has always solidly supported distributed, multi-site and offline operations due to the unreliability of the few computer-networks that existed at the time CVS evolved.

A group of volunteers currently maintains the CVS code. Notably, the development of the Microsoft Windows version of CVS has split off into a separate project named CVSNT and has been more active in extending the feature set of the system, even porting the changes back to the UNIX platform under the name CVSNT.

Relationship with GNU

Historically, the relationship between CVS and the GNU project could appear somewhat ambiguous: the GNU Web site distributed the program, labelling it "GNU package" on one page and "other GPL-licensed project" on another. Clarification came recently when CVS development moved from cvshome.org to savannah.nongnu.org, with CVS officially assigned to the non-gnu category. On the FTP site, the program has traditionally resided in the /non-gnu/ directory and still does.

Limitations

For each commonly listed limitation of CVS there exists a commonly listed reason. The developers of CVS insist that the following properties of CVS are not shortcomings, but features that were carefully planned, designed and implemented into CVS:

• CVS does not version the moving or renaming of files and directories. It was implemented this way because in the past Refactoring was avoided in development processes. More recently the thinking has changed and refactoring can be managed by an administrator (by directly moving the RCS file in the repository, provided that the administrator knows what he or she is doing) as it is required. If you develop in Oracle Forms, Cobol, Fortran or even C++ then the CVS reasoning is quite commonly accepted; if you develop with Java then the CVS reasoning may seem counterintuitive.
• No versioning of symbolic links. Symbolic links stored in a version control system can pose a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute.
• Limited support for Unicode text-files and non-ASCII filenames. Many Unix systems run in UTF-8 and so CVS on such systems handles UTF-8 filenames and files natively. For programmers working on Unix systems all with the same encoding then this response seems reasonable; but it causes problems when multiple encodings are used, perhaps because clients are running another OS, such as AS/400 or Windows). Care must also be taken when using CVS to store text or XML files that contain Unicode.
• No atomic commit. The network and server used should have sufficient resilience that a commit can complete without either crashing. In many code management processes, development work is performed on branches (for example, add feature A1234), and then merged into the trunk after code review - that final merge is 'atomic' and performed in the data center by QA. The term atomic is sometimes referred to in the transactional database sense where a commit will automatically roll back should it fail for any reason, and sometimes referred to in the sense that each commit can be uniquely identified. If each commit needs to be tracked then this can be handled by modifying the correct trigger.
• Expensive branch operations. CVS assumes that the majority of work will take place on the trunk — branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.
• CVS treats files as textual by default. Text files should be the primary file type stored in the CVS repository. Binary files are supported and files with a particular file extension can automatically be recognised as being binary.
• No support for distributed revision control or unpublished changes. Programmers should commit changes to the files often for frequent merging and rapid publication to all users.

Over time, developers have wanted to change the CVS code significantly to add new features, refactor the code, alter the operational model and improve developers' productivity. This has led to the phrase YACC: "Yet Another CVS Clone" (itself a play on the Unix command named, yacc, which stands for "yet another compiler compiler"). CVS replacement projects include CVSNT (first released 1998), EVS (currently in beta as of 31 August 2007), OpenCVS (not released as of 27 August 2008) and Subversion (initially released in 2000) and numerous systems to support distributed revision control.

Concurrent Versions System

Features

CVS uses a client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server supports various flavors of Microsoft Windows and Linux), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file.

If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format.

Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number. Many open-source projects allow "anonymous read access", a feature pioneered by OpenBSD. This means that clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios.

Clients can also use the "update" command in order to bring their local copies up-to-date with the newest version on the server. This eliminates the need for repeated downloading of the whole project.

CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch.

CVS uses delta compression for efficient storage of different versions of the same file. The implementation favors files with many lines (usually text files) - in extreme cases the system may store individual copies of each version rather than deltas.

In the world of open source software, the Concurrent Version System (CVS) has long been the tool of choice for version control. And rightly so. CVS itself is free software, and its non-restrictive modus operandi and support for networked operation – which allow dozens of geographically dispersed programmers to share their work – fits the collaborative nature of the open-source world very well. CVS and its semi-chaotic development model have become cornerstones of open-source.

– Collins-Sussman, Version Control with Subversion For Subversion 1.1, 2005

Terminology

CVS labels a single project (set of related files) which it manages a module. A CVS server stores the modules it manages in its repository. Programmers acquire copies of modules by checking out. The checked-out files serve as a working copy, sandbox or workspace. Changes to the working copy will be reflected in the repository by committing them. To update is to acquire or merge the changes in the repository with the working copy.

History and status

CVS developed from an earlier versioning-system called Revision Control System (RCS), still in use, which manages individual files but not whole projects. Dick Grune has provided some brief historical notes about CVS on his site. To quote:

I created CVS to be able to cooperate with my students, Erik Baalbergen and Maarten Waage, on the ACK (Amsterdam Compiler Kit) C compiler. The three of us had vastly different schedules (one student was a steady 9-5 worker, the other was irregular, and I could work on the project only in the evenings). Their project ran from July 1984 to August 1985. CVS was initially called cmt, for the obvious reason that it allowed us to commit versions independently.

– Dick Grune, Dick Grune's website

Grune publicly released the code to mod.sources on June 23, 1986: Google Groups continues to archive and serve the original usenet post.

The code that eventually evolved into the current version of CVS started with Brian Berliner in April 1989, with later input from Jeff Polk and many other contributors. Brian Berliner wrote a paper introducing his improvements to the CVS program which describes how the tool was extended and used internally by Prisma, a third-party developer working on the SunOS kernel, and was released for the benefit of the community under the GPL.

CVS introduced the implementation of branching into version-control systems: the branching techniques in other systems all derive from the CVS implementation.

CVS has always solidly supported distributed, multi-site and offline operations due to the unreliability of the few computer-networks that existed at the time CVS evolved.

A group of volunteers currently maintains the CVS code. Notably, the development of the Microsoft Windows version of CVS has split off into a separate project named CVSNT and has been more active in extending the feature set of the system, even porting the changes back to the UNIX platform under the name CVSNT.

Relationship with GNU

Historically, the relationship between CVS and the GNU project could appear somewhat ambiguous: the GNU Web site distributed the program, labelling it "GNU package" on one page and "other GPL-licensed project" on another. Clarification came recently when CVS development moved from cvshome.org to savannah.nongnu.org, with CVS officially assigned to the non-gnu category. On the FTP site, the program has traditionally resided in the /non-gnu/ directory and still does.

Limitations

For each commonly listed limitation of CVS there exists a commonly listed reason. The developers of CVS insist that the following properties of CVS are not shortcomings, but features that were carefully planned, designed and implemented into CVS:

• CVS does not version the moving or renaming of files and directories. It was implemented this way because in the past Refactoring was avoided in development processes. More recently the thinking has changed and refactoring can be managed by an administrator (by directly moving the RCS file in the repository, provided that the administrator knows what he or she is doing) as it is required. If you develop in Oracle Forms, Cobol, Fortran or even C++ then the CVS reasoning is quite commonly accepted; if you develop with Java then the CVS reasoning may seem counterintuitive.
• No versioning of symbolic links. Symbolic links stored in a version control system can pose a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute.
• Limited support for Unicode text-files and non-ASCII filenames. Many Unix systems run in UTF-8 and so CVS on such systems handles UTF-8 filenames and files natively. For programmers working on Unix systems all with the same encoding then this response seems reasonable; but it causes problems when multiple encodings are used, perhaps because clients are running another OS, such as AS/400 or Windows). Care must also be taken when using CVS to store text or XML files that contain Unicode.
• No atomic commit. The network and server used should have sufficient resilience that a commit can complete without either crashing. In many code management processes, development work is performed on branches (for example, add feature A1234), and then merged into the trunk after code review - that final merge is 'atomic' and performed in the data center by QA. The term atomic is sometimes referred to in the transactional database sense where a commit will automatically roll back should it fail for any reason, and sometimes referred to in the sense that each commit can be uniquely identified. If each commit needs to be tracked then this can be handled by modifying the correct trigger.
• Expensive branch operations. CVS assumes that the majority of work will take place on the trunk — branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.
• CVS treats files as textual by default. Text files should be the primary file type stored in the CVS repository. Binary files are supported and files with a particular file extension can automatically be recognised as being binary.
• No support for distributed revision control or unpublished changes. Programmers should commit changes to the files often for frequent merging and rapid publication to all users.

Over time, developers have wanted to change the CVS code significantly to add new features, refactor the code, alter the operational model and improve developers' productivity. This has led to the phrase YACC: "Yet Another CVS Clone" (itself a play on the Unix command named, yacc, which stands for "yet another compiler compiler"). CVS replacement projects include CVSNT (first released 1998), EVS (currently in beta as of 31 August 2007), OpenCVS (not released as of 27 August 2008) and Subversion (initially released in 2000) and numerous systems to support distributed revision control.

Car maintenance

Car maintenance means to inspect the condition of car components and add (or change) expendable parts (or materials). Regular maintenance is critical to ensures the longevity and safety of a car.

The actual schedule of car maintenance varies depending on the type of a car and driving condition. Even a dealership often has a different recommended schedule from the manufacturer service manual for the same car.

Common car maintenance tasks include:

• Car wash
• check or change the engine oil and fuel filters
• inspect or replace windshield wipers
• check or refill windshield washer fluid
• inspect tires for pressure and wear.
• Tire balancing
• Tire rotation
• Wheel alignment
• check or clean battery terminals
• inspect or replace brake pads
• check or refill brake fluid
• check or refill transmission fluid
• check or refill power steering fluid
• check and refill engine coolant
• flush radiators
• inspect or replace spark plugs
• inspect or replace air filters
• inspect timing belts
• clean and adjust throttle body
• lubricate locks, latches, hinges
• check all lights and horns

Some tasks that have equivalent service intervals are combined into one single service known as a tune up

Software maintenance

In software engineering, software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”(ISO/IEC 14764). This international standard describes the 6 software maintenance processes as:

1. The implementation processes contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management.
2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications.
3. The process considering the implementation of the modification itself.
4. The process acceptance of the modification, by checking it with the individual who submitted the request in order to make sure the modification provided a solution.
5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task.
6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.

There are a number of processes, activities and practices that are unique to maintainers, for example:

• Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer;
• Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers;
• Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive;
• Modification Request acceptance/rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.

A common perception of maintenance is that it is merely fixing bugs. However, studies and surveys over the years have indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.

Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of eight Laws of Evolution (Lehman 1997). Key findings of his research include that maintenance is really evolutionary developments and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action is taken to reduce the complexity.

The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, maintainability measurement.

Software Maintenance Capability Maturity Models which address the unique processes of the software maintainers are described in the corrective maintenance maturity model (Kajko-Mattsson 2001), the IT Service CMM and to be released CMMi for Services (SEI 2008)

Software maintainer

In free and open source software, a software maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in an source repository (SVN or CVS).^[1]