Chris wrote:
> I don't think that the best answer is to implement a delete function in
> a repository. A better answer is to have a decent workflow system so
> that changes can get reviewed before they get committed.
I think that there are reasons to delete things from a repository, but
coding mistakes or differences in design decisions aren't among them.
> There are probably multiple good ways to implement this. One that I have
> in mind is to have three repositories. The first is for rough drafts:
> developers should check their code into it frequently whether the code
> works or not. Developers promote code from the first to the second when
> they think their code is ready for review. A team lead promotes the code
> from the second to the third "production" repository only after it has
> gone through review and all unit tests.
Why can't you do this with branches? If you have multiple competing
designs in phase one, start them on separate branches, for phase 2, move
one to the trunk for more development, then start cutting release-track
branches when something is close to a release and you want to freeze its
features.
> All of this has to be enabled by a decent user interface that will let
> you see what needs to be reviewed, and will let you promote code simply.
Can't you do that now, merging between branches?
> I spent quite a bit of time with other open-source version control
> systems before picking Subversion. One in particular, Mercurial, seemed
> much superior to Subversion, but lacked a decent UI or Eclipse plugin.
> From an architectural standpoint, though, it was a much better fit for
> what I've described above.
Did you look at svk or similar systems that let you mirror an svn
project, work with a local branch, then eventually commit the changes
back? There may a similar operation with mercurial. Personally I think
it is better to keep everything visible to all developers so they can
take advantage of each other's work concurrently instead of being
surprised by large changes, though.
> > However, at some you're going to have to trust your developers, and if
> > you can't do that, I'm sorry to say this, but there isn't much a source
> > control system will do to help that problem.
>
> I've heard this frequently, but it's unrealistic. This simply does not
> work in the real world. People make mistakes, huge ones, inevitably.
> Even me. In a professional software organization you must put in
> controls and enforce reviews if you want to have a quality product.
You need the ability to manage revisions, but only rarely do you need to
pretend they never happened. Your 'quality product' is most likely
going to be built from the head of a release branch or a tag copy of it.
It won't matter at all if there are mistakes in the trunk or even that
branch if they were reverted or subsequently replaced with better versions.
--
Les Mikesell
lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-15 23:10:39 CET