In addition to using Subversion, you might look into the addition of
Trac - it is a very handy addition to the development environment and
has plugins for some pretty sophisticated workflow.
http://trac.edgewall.org/
On Mon, Jun 29, 2009 at 7:55 PM, Ryan
Schmidt<subversion-2009b_at_ryandesign.com> wrote:
> On Jun 29, 2009, at 10:38, Brian FitzGerald wrote:
>
>> One solution I have heard of large shops using is to have each
>>
>> developer have their own branch in the repository, so that once their
>> coding is complete, they would commit to their personal branch. Then,
>> the code reviewer would perform a commit from the developers branch to
>> the (and I get hazy about the specifics here) main development branch
>> (would this need to be a separate repository?).
>
> My case against a branch per developer is that there's no reason why
> a developer would be working on only one task. I was usually working
> on several tasks for each project, at the last web development
> company where I worked. I didn't use separate branches, but I did use
> multiple working copies of each project's trunk. But then we didn't
> have restrictions on who could commit to trunk. Once I was done
> working on one task I could commit it and move to another one. If,
> after finishing a task, I had to send it off to someone for a lengthy
> approval process, I wouldn't want to have to sit around waiting for
> their response. I'd want to be able to work on a new task, which
> should then be in a different branch to not muck up the reviewers.
> Hence a branch per feature as already suggested.
>
>
> I also wanted to point out there's no reason why you can't continue
> to do exactly what you do now, only with Subversion. Set up a
> repository but only give commit access to your reviewers. The
> developers continue to develop and send patches or whatever to the
> reviewers, and only they would commit it, once they've reviewed it.
> I'm not saying this is a great way to set up Subversion, but it is a
> way to use it that would not differ much from what you do now, thus
> might be easier to get approved by the powers that be. Then once
> that's in place, you can start suggesting small ways the workflow can
> be changed to make it more better, e.g. showing how allowing commit
> access to non-reviewers to non-trunk areas like branches would allow
> developers to be more productive while not impacting your review
> mechanism for trunk.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2366579
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2366631
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-30 09:02:44 CEST