Chris wrote:
> Some of our developers are unclear on the concept of version control,
> and tend to upload a lot of junk in the system -- entire directories of
> third-party code, for example, that they wanted to show other people.
I feel your pain. I don't know why this is such a hard concept for
many people to understand.
> How can I set things up so I can review developer commits, and back out
> any mistakes?
Using subversion in the model that all developers have commit access
this cannot be done. Because subversion tries really hard to preserve
data. Once committed it is committed. It is possible to svnadmin
dump, filter and load the repos but this is not done casually. There
is the "obliterate" command on the roadmap but I am not clear how the
workflow will work with it. This makes it very hard to undo commits
in subversion. Not something you can do as a casual part of the daily
work flow.
In FLOSS development it is rare for everyone to have commit access to
a project. Typically a maintainer or maintainer team are the only
ones allowed to commit changes. All others must submit their changes
as patches. These changes are reviewed and only committed after being
found acceptable. Often there is an interative process involved as
patches are rejected with requests for this or that improvement. The
submitter turns the patch and repeats until it is found acceptable.
Submitters are by this process mentored up the learning curve. Code
reviews pass on learning and knowledge. They learn what are good
practices and are bad. Usually people who have proved that they have
the skills and disposition are given direct commit access to the
repository.
This model works well. But this is very time consuming for the people
doing the patch review. They are by design a bottleneck to getting
changes put into the project. That is their job. To be the
gatekeeper. In concept this process is a centralized merge system
because they are the ones who end up merging changes.
However, implementing this type of a gatekeeper process in a corporate
business world may be unpalatable. It is often hard to explain to
management that while you are paying people these big salaries that
they are not trusted to commit changes without review. It may be true
but still unpalatable.
> What I need is some kind of workflow system, akin to the ones found in
> content management systems, that allow a manager to review changes
> before documents get posted to the next level.
I suggest that you look into a distributed version control system.
Let users commit to their local repository whatever trash they feel
like commiting. Then have your review board pull those changes into
the main repository.
Two systems come to mind. SVK works with subversion. I would
definitely take a look at it and gain some experience with it. It may
be well suited to your task. The other is git used by the linux
kernel development which was designed from the start to be a fully
distributed version control system. Both of these support a process
model where users have their own repository with full local commit
access then support pulling those changes into the main repository
after a review.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 19 21:19:25 2006