Re: source code libraries
Re: source code libraries
- Subject: Re: source code libraries
- From: Jeffrey Oleander <email@hidden>
- Date: Mon, 19 Feb 2007 22:03:28 -0800 (PST)
> David Dunham <email@hidden> wrote:
>> On 2007 Feb 19, at 10:00, Jeffrey Oleander wrote:
>> The mechanism to check out code to work on it and
>> submit new and changed code, and check-in after
>> code review, leaves a lot to be desired
> FWIW, neither CVS nor Subversion require you to
> check out code.
Exactly. I'd much rather have a source code unit locked as
"checked out by another developer" and hence inaccessible
until he checks it back in, than have to struggle with the
likes of diff to reconcile multiple sets of mods.
What I liked was the 3-level structure and process of the
individual developer checking out units from the master
library into his working library, doing development on
them, doing unit testing, then submitting them to the
work-group or pre-integration library for review, then the
work-group leader submitting them back for integration into
the master library, after which the integration & QA folks
could do the integration and then run their whole library
of tests. We even kept the test scripts in a similar
3-layered source library so that everyone only had to learn
one set of tools; new and modified tests were submitted for
check-in just as new and modified code units were.
The one part that was as kludgey as the current tools were
tests that relied on pre-existing files that the apps used
which had structural features that did not allow them to be
kept in the source library proper, but in a set of
directories. That shouldn't be a problem now, with XML
serving much the same purpose as those file structures.
It did the equivalent of incremental builds, substituting
the object code from checked out units in an individual
developer's library for chunks of object code in the master
and/or pre-integration library as requested.
You could also check out units read-only, which didn't
allow you to check them back in and didn't prevent others
from checking them out, but only so that you could
experiment, and the developer could flush those and clear
the checked-out-but-not-reserved status. The docs say that
the current source library systems sometimes get their
files locked up when they should not be, and we did not
have that problem. (Well, I take that back. We had one
developer who had developed the operating system and
another quirky one who each managed to get the unit locks
set incorrectly once each, but it was a very simple thing
for the lead QA person to clear within the development
environment and didn't require fishing around and using
command line tools, as I recall.)
It worked well with over a hundred developers in a dozen or
so work-groups working on the same projects, and decreased
the ego-wars ("artistic differences", conflicting "best
practices").
The one complaint was from some of the QA group, who were
used to an older set-up that had more limited application
test scripts such that they couldn't even put tests in the
library that required those structured files. This one
required the equivalent of a shell script plus an
application script (both of which, today, could probably be
taken care of by Applescript) and they didn't like having
to even tell it to include the default boiler-plate shell
script that worked for the vast majority of the simple
app-script-only tests; most of them didn't want anything to
do with the shell scripts, for that matter, but then they
were mostly mechanical engineers with just a little
computer training.
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden