[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Comparing Activity on Branches

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2007-03-15 15:59:07 CET

On 3/15/2007 10:52 AM, Brad Harper wrote:
> Hello:
> I'm fairly new to Subversion, so apologies in advance if the
> answer should be obvious.
> We have a /dev branch for day-to-day commits.
> At the beginning of a testing cycle, we create a /QA branch to
> isolate a release candidate's code from that of daily development.
> If a bug is corrected on the /QA branch, it needs to be
> synch'ed with /dev so that the error doesn't re-occur in a
> later release.
> Our QA manager is seeking some sort of assurance that this
> synchronization has been performed. How would this information
> be gleaned from the repository?

I don't think svn currently provides a way to do this. Our practice is
as follows:

  - do the bug fix on the trunk.
  - port it from there to the QA branch, with a log message saying what
revision just got ported.

This way the log for the QA branch is almost all messages of the form
"port of r12345 from trunk (fix for PR#21212)". Manual checking of
other messages would be feasible.

This doesn't guarantee that bug fixes ever do get ported to the QA
branch, but presumably you have testing procedures in place that can
check for that.

We used to follow your practice (fix on the branch, port to the trunk),
but the strategy above doesn't work nearly as well there: there are too
many "other messages" on the trunk.

"Merge tracking" is one of the promised features that will eventually
come. In the meantime, the svnmerge.py script may be able to help (but
I have never used it).

Duncan Murdoch

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 15 15:59:31 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.