![]() |
|
![]() | ||
|
Subject:
revision control - guidelines
Category: Computers Asked by: mickr-ga List Price: $20.00 |
Posted:
28 Jul 2005 09:13 PDT
Expires: 27 Aug 2005 09:13 PDT Question ID: 548982 |
Hi, I am looking for some offical guidelines about revision control. Two people are having an arguement about how to best use revision control first person - does not want people to be able to have local files so that their file cannot become out of date with other modifications second person - you have to have local files so you can make local changes without killing everyone else on the project I would like some guidelines from an offical source such as the IEEE or someone so I can go look this is what we are going to do and why it is the best practice. Thanks, | |
| |
| |
| |
|
![]() | ||
|
There is no answer at this time. |
![]() | ||
|
Subject:
Re: revision control - guidelines
From: eudean-ga on 28 Jul 2005 11:29 PDT |
Well, I don't know about any IEEE revision control standard, but a pretty well-known and widely used automated revision control program is called "CVS", or Concurrent Versions System. I was coincidentally just reading about this the other day and it is an interesting implementation of revision control. Here are two good readings: http://www.nongnu.org/cvs/ http://en.wikipedia.org/wiki/Cvs A google search of CVS or Concurrent Versions System should produce a lot of valid results. |
Subject:
Re: revision control - guidelines
From: ducman-ga on 28 Jul 2005 11:37 PDT |
I don't know the standard either but I have use sourceforge CVS and that goes through the "second person" method. You will have local files and everyone can work on any file and on commit the cvs will merge the work. With an update everyone get teh same latest version. Having the "first person" method really limits other people from working on a certain file if that file is current been worked on (the fly) by someone else. I prefer the "second person" method but that's just me. Maybe a pro can answer this one. |
Subject:
Re: revision control - guidelines
From: eudean-ga on 28 Jul 2005 14:14 PDT |
I still haven't found exactly what you're looking for, but more useful links anyway: http://zooko.com/revision_control_quick_ref.html (Overview of FSF revision control systems. I'd recommend looking at how each handles revision control. That would give you an idea of the "standard", since any organization that needs revision control probably uses one of these types of programs). http://en.wikipedia.org/wiki/Revision_control (More general discussion on Revision control from Wikipedia. I think the most important portion is as follows: "Traditionally, revision control systems have used a centralized model, where all changes to a project are submitted to a single, central server. A few years ago, systems like TeamWare, BitKeeper, SVK, and GNU arch began using a distributed model, where each developer works directly with their own local repository, and changes are shared between repositories as a separate step. This mode of operation allows developers to work without a network connection, and it also allows developers full revision control capabilities without requiring permissions to be granted by a central authority. One of the leading proponents of distributed revision control is Linus Torvalds, inventor of the Linux kernel. At the simplest level, users can simply retain multiple copies of the different versions of the program, and number them appropriately. This simple approach has been used on many large software projects. Whilst this method can work, it is inefficient (as many near-identical copies of the program will be kept around), requires a lot of self-discipline on the part of developers, and often leads to mistakes. Consequently, systems to automate some or all of the revision control process have been developed. Most revision control software use delta compression, which retains only the differences between successive versions of files. This allows more efficient storage of many different versions of files.") In general, it appears that both methods would work--local files and centralized files. It all depends on how they are handled after the fact. There needs to be some of merging of changes in the end, and whether that occurs in a centralized fashion or between local repositories doesn't matter as much. |
Subject:
Re: revision control - guidelines
From: matthelliwell-ga on 14 Aug 2005 00:50 PDT |
If you allow changes to files without having to check them out of source control, then people will lose changes, so don't do it. The answer to the second person's issue is to use a source control system that allows branching. This allows people to work on the same file and then merge the changes together when they are ready. This works unless people are changing binary files, such as word documents, or they are changing the same lines of code, which should be pretty rare unless you've got other problems with your development process. So the process normally goes something like this: 1. Have a main branch which is tightly controlled. You do your release builds from here and you add labels here to allow you to reproduce previous releases. 2. You have an integration branch. You use this for overnight builds and tests. A specific person is reasonsible for merging from integration to main when your are ready to build you first release candidate. 3. You have a branch for each developer so they can change and check in code to their heart's content. When they are ready to deliver a piece of functionality, they first merge from the integration branch to their development branch. They can then fix any problems with merging without breaking the integration branch. When all the appropriate tests pass with the code on their development branch, they merge from their development branch to the integration branch. This then gets picked up in the overnight build and test. Any developers who break the overnight tests get to buy the rest of the team doughnuts. There are lots of variations on this and you need to adjust the process depending on the size and complexity of your project. eg * Most teams won't bother with the integration branch, it is only worth while if you have a seperate integration effort in your project. * You can trust your developers to merge code to integration when they are ready or you can force them to provide evidence of testing before you allow the merge. Branching is easier with tools such as CVS and Clearcase but if you are using Microsoft Visual Source Safe you've got no chance. As for IEEE revision control standard, I've never seen one. However, I work for a large investment bank and have developed several source control processes for different projects over the years so I do have some clue what I'm talking about. |
If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you. |
Search Google Answers for |
Google Home - Answers FAQ - Terms of Service - Privacy Policy |