Re: Test case review

On Wed, May 11, 2011 at 12:02 PM, Linss, Peter <peter.linss@hp.com> wrote:
> One of the issues that I'm dealing with here, however, is that many of our test contributors are simply not engineers, they don't use vcs (let alone dvcs) on a daily basis, and don't fully grok how those systems work. Forcing them to learn these systems is an unacceptable barrier to entry. I'd rather deal with tool issues on my end than lose their oh so valuable contributions. I also don't know how many other potential contributors are out there, and I don't want a complicated set of tools to scare them away before they even try.

It's not complicated at all.  We can provide step-by-step instructions
on how to do all the important tasks.  The advantage of using built-in
VCS features instead of a home-grown tool (even one that already
exists) is that more people will already be familiar with the existing
tool, and the existing tool will have much more development effort put
into it.  I don't know so much about hg, but in git, the way to apply
a commit from one branch to another is just

git checkout branch-to-change
git cherry-pick commit-id


I'm not sure how well this would work in the long term without
occasionally rebasing the unstable branch on the stable branch,
though.  Would mq work for that, in Mercurial?  For the Linux kernel,
the way it works is that -stable is regularly rebased on Linus' tree,
as are individual development trees, but that complicates pulls (and
we're not using git anyway).  If you don't do any kind of rebasing,
won't you have a hard time keeping track of which revisions were
actually merged and which need to be merged, as opposed to
branch-specific commits or reverted commits or such?  Or is the review
tool meant to solve that?  If so, is there some specific tool that
people have in mind?

Received on Wednesday, 11 May 2011 22:19:34 UTC