Doug,
If you're using a scc tool like subversion or cvs, you don't need to use
locking. You don't want to use locking.
The concern that I hear from most "pickies" is: How do I keep my
developers from stepping on each others changes? And inevitably they
come to the conclusion that the only way to do that is by locking others
out while they make changes -- hey, that's what you do with database
records, right?
Subversion and CVS don't use a locking model; they use a merge model.
Instead of a single BP file that gets locked, the programs are stored in
a repository. Developers "checkout" or "update" their personal program
copy from the repository and proceed to slice and dice it. Now here's
where the magic happens: when the developer "commits" his changes, the
scc tool *merges* the lines of code changed back into the repository.
When the commit process detects a conflict, it let's the developer know
so he can fix it.
This dynamic works well for 1 to 1,000 developers working on a single
application. There are some implications that are typically different
from a "locking model" pick shop:
(1) Every developer has his own development area (directory).
Developers typically don't share a single account. Pickies tend to have
a single development area for everybody.
(2) Every developer "updates" his own development area on a regular
basic, usually every morning. This one-line command grabs all the
recent changes to the repository and updates the programs. If a change
was made to a program that the developer was working on, the change is
seemlessly merged in. Any conflicts are reported and the developer is
expected to resolve it.
(3) When the developer has completed and tested his mods, he "commits"
them to the repository (again a one-line command). Again, any
conflicting changes are reported for the developer to resolve.
How often do conflicting changes occur? Rarely, because seldom do two
developers work on the same exact lines of code at the exact same time.
As soon as one developer makes his change and commits it, the other
developer's update automagically merges it into his version. As long
as all developers do updates before they change code, nobody gets hurt.
With these tools and procedures, you don't really gain anything by
"locking". Like Ian mentioned, your developers are more likely to
forget to unlock a program.
rex
doug chanco wrote:
hey all,
we are beginning to use subversion for version control and I was
wondering if there was "good" way to lock code besides the usual READU
in a program or AE/EDing the record.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
