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,

---

Clarification of Question by mickr-ga on 28 Jul 2005 11:53 PDT

Hi,

Thanks for your comments, I agree that the second person is probably
right. I suppose I am looking for some offical recomendations so that
I can back up the statement and try and get closure between these two.

I would still be interested if someone could point me to some best
practices which deal with this.

Thanks,

---

Request for Question Clarification by hedgie-ga on 03 Aug 2005 06:23 PDT

There is not one 'prefferred method'.

It depends on number of people, making how frequent mods.

In the development mode, when you are debugging new code,
 you are better of with local files.

In maintenance phase, when changes made independetly may interfere, 
it may be preferrable for all to work with 'fresh copy'.

---

Request for Question Clarification by maniac-ga on 14 Aug 2005 21:11 PDT

Hello Mickr,

Could you answer a few questions to allow us to provide some more
specific guidance?

For example:
How many people [actively updating files] are you talking about?
Will the people updating files be working on different areas (no
overlap of responsibility)?
How much dependency will there be between different people's work?

The "first person" view would basically be preferred with
 - few people
 - no overlap of responsibility
 - little or no dependency between people's work
where the "second person" view is preferred with
 - few to many people (scales to hundreds)
 - some to significant overlap of responsibility
 - some to significant dependency betwen people's work

Both the "out of date" and "killing everyone" problems are real - but
there are techniques you can use to mitigate them.

  --Maniac

---

Clarification of Question by mickr-ga on 14 Aug 2005 23:40 PDT

Hi,

To answer your questions

How many people [actively updating files] are you talking about?
- Typical project 5 people

Will the people updating files be working on different areas (no
overlap of responsibility)?
- Mainly but not totally. However, conflicts should be easy enough to resolve.
It will be based on text files and if there is a conflict that is not
so easy to resolve then we need to get together as a team anyway.

How much dependency will there be between different people's work?
- Lots any change will efect everyones elses results.

To me it seems the most benifical way of doing things would be to
ensure team updates before they change any file (so update often) and
then checkin when the are OK with the results.

Typically I would say we are in development mode if we are in
maintance mode then there should only be very small changes with only
one person doing the change. This is under control now. What is not is
our development mode where several people are changing the file at one
time.

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.

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.

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.

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.