Restricting or Auditing "get" function in PVCS

[Walter Ariel Risi]

Hi all,

I´ve been working with PVCS for a while and find the following
problem. Although PVCS prevents users from checking-out an already
checked-out file (thus serializing work), I´ve seen that programmers
keep doing a "get" operation to retrieve the locked source file. The
problem of course is that when the latter programmers´ file is
checked-in, he may have forgotten to conciliate its code with the one
the former programmer included when he released the checked-out file.

In other words, the problem is the following.

1 A checks out F1, rev X.
2 B needs F1, but it is checked out. B "gets F1", rev X.
3 A works on F1, rev X.
4 B works on F1, rev X.
5 A checks-in F1, generating X+1.
6 B check-out F1, rev X+1.
7 B overwrites F1 with its own copy of the file, as he generated it on
step 4.
8 B checks-in F1, rev X+2.

The problem is that revision X+2 generated by B does not include the
fixes done by programmer A in revision X+1.

So far, the only solution is to perform code reviews to ensure that
every fix is included given a version X. However, I would like to
discourage this "get instead of check-out" practice either by:

- restricting the get function (i.e. allowing check-out only), or...
- auditing the get function (i.e. is there a log file where usage of
the "get" function is restricted?).

Has anybody been through something like this?
Cheers,
Walter.

[David Gillon]

Walter Ariel Risi <walter_ariel_risi@hotmail.com> wrote in message
news:12f398a4.0307210551.1074f295@posting.google.com...

[SNIP]
So far, the only solution is to perform code reviews to ensure that every fix is included given a version X. However, I would like to discourage this "get instead of check-out" practice either by: - restricting the get function (i.e. allowing check-out only), or... - auditing the get function (i.e. is there a log file where usage of the "get" function is restricted?).

Essentially you're saying that your programmers are violating their own
software standards (if your operation has a PVCS based config management
system in place then I'm going to assume that the rest of your processes are
mature enough to be written down and enforced, at the very least you defined
the project config management process when you created the PVCS lifecycle
you're using). If someone is repeatedly, as opposed to occasionally and
accidentally, violating standards, then depending on your particular project
structure either you, their team leader or the project quality rep needs to
tell them (_NOT_ ask them) to stop. If they refuse it becomes a disciplinary
issue. If your procedures don't explicitly forbid it -- 'changes must only
be made to files checked-out for the purpose of the specific change' -- then
they should be changed to do so.