Source control question

As we’re talking about trying to know “who has file X checked
out”, be aware that the phrase “checked out” has multiple
meanings. In a single-editor system like Visual SourceSafe or CMS, it’s
like a library book: I “check out” a file when I want to edit it,
and the system allows only one person to have a file checked out at a time. I
then “check it in” when I’m done editing it, which puts my
changes into the system.

In CVS (and I believe in SubVersion), the act of “checking something
out” is generally done on a group of files, such as a whole application,
and all it means is that I have a copy of those files on my hard disk. With that
meaning, of course every developer will have every file in the application
“checked out” all the time.

What you really want to know is not: “who has file X checked out”
but “who is editing file X.” At least in CVS, and probably in SVN,
that can be done a different way, with the “edit” command. When I
want to edit a file, I tell CVS that I am “editing” the file; until
I do that, the file on my hard disk is set to read-only, which helps remind me
to do that. CVS still lets any number of people be “editing” the
file at the same time, but I can always ask CVS “who is editing file
X” and it will tell me. When I am done, I have two things to do: Commit,
which puts my changes into the repository, and Unedit, which removes the flag
that says I’m editing the file (and sets my local copy read-only again).

In a wild west setting, of course, people will reset the local read-only flags
on the files any time they please, and never tell the system they’re
editing a file; or they will edit a file and never unedit it, even after they
commit. But at least it’s another mechanism to attempt to use.

Nate Schroeder

IT Commercial Technical Services - Data Management Team

Monsanto Company

800 N. Lindbergh Blvd. G3WI - Saint Louis, MO - 63167

314-694-2592

This e-mail message may contain privileged and/or confidential information, and
is intended to be received only by persons entitled to receive such information.
If you have received this e-mail in error, please notify the sender immediately.
Please delete it and all attachments from any servers, hard drives or any other
media. Other use of this e-mail by you is strictly prohibited.

All e-mails and attachments sent and received are subject to monitoring, reading
and archival by Monsanto, including its subsidiaries. The recipient of this
e-mail is solely responsible for checking for the presence of “Viruses” or other
“Malware”. Monsanto, along with its subsidiaries, accepts no liability for any
damage caused by any such code transmitted by or accompanying this e-mail or any
attachment.

Exactly, that’s why I originally spoke in terms of
“concurrency” control. Source control is a no-brainer and Subversion
is perfect for that.

I don’t really care who has it “checked out” since in my
experience we generally “check out” the entire source trunk, but
that was when we were working on independent development environments and
check-in conflicts were extremely rare and easily resolved. If we were working
in separate schemas or instances then it would be the same and there would be no
problem, but that isn’t reality and hasn’t been reality anywhere
I’ve worked.

In this case, everyone is working in one schema, so the probability of two
people editing and compiling any of the “core” packages is fairly
high. That’s what I’m trying to address. Most packages are single
purpose and only one person is working on them at a time and that’s not a
problem. It’s when we need to add something to a more generic API package
that the problem comes in.

That’s when something like ClearCase or StarTeams file locking comes in
handy. I know exactly who is working on it because they have it locked.
It’s a technological solution to a human problem. I hate it, but it does
solve certain problems in a shared environment.