At Apple, I implemented this with CVS using branches, and it works rather well.
I wrote some shell scripts to ease the process. The pain was in large projects
because branching, tagging, and merging take so long. With SVN, this would be a
lot smoother. The process is:
- cvs co proj; cd proj
- <edit away>
- <file a big describing your fix, if it's not in response to an existing bug>
- cvs-make-branch PR-<bug#>
(this tags the wc at PR-xxx-base, makes a branch PR-xxx, updates to that branch)
- cvs add/remove as needed
(this should work before the cvs-make-branch, but CVS ends up adding on the
mainline even though we think we're committing on the branch if you do it in
the wrong order)
- cvs commit, note the branch name in the bug's diagnosis
- Set the bug's state to Fixed (goes to review)
If the bug fix gets nixed, the bug goes back to the Analyze state. The developer
edits the branch to try again, or starts a new one PR-xxxA.
Then the branch noted in the bug gets merged in. Note that the person doing the
merge may not be the developer who made the fix. In fact, in the case of large
projects with many developers, one person merges all the bugs, coordinates with
developers in case of conflicts, and does a compile and test before committing the
merged branches to the mainline. Source gets tagged with a new version number....
All Darwin systems and Mac OS X with dev tools have the scripts in /usr/bin:
cvs-make-branch # Mark foo-base, make and update to new branch foo
cvs-merge-branch # Merge -j foo-base -j foo
cvs-diff-branch # Diff -r foo-base -r foo
cvs-view-diffs # Show diffs in FileMerge
Writing these with SVN may actually be harder, though, since branches are
not really an SVN mechanism, and the scripts would have to figure out what your
branching tree structure (/branches/XXX or /project/branches/XXX ...?) is
before proceeding to make/find a branch by name. I guess it may have to take
full paths to branches.
The problem with the idea of using transactions is that it's not at all clear
how you'd deal with the case where the code is denied pending some changes.
The developer then needs to edit the transanction (probably not feasible) or
create a new one. And what happens to the working copy when a transaction is
accepted but not commited? If it is edited further and another commit comes
along but the first txn is still in limbo?
-wsv
On Friday, August 2, 2002, at 06:52 PM, Blair Zajac wrote:
> 1) Developer does work.
> 2) Developer commits.
> 3) Commit system notes that developer's commit needs review and
> a) Keeps the txn in the database and quits.
> b) Runs a modified commit-email.pl on the txn to send out a review
> request.
> c) Quits without deleting txn.
> 4) Somebody reviews the changes and say OKs it.
> 5) The manager goes to a CGI interface to the repos which lists all
> the outstanding txn's and selects the txn to apply.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 19:36:35 2002