[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: auto branch propagation

From: Arthur Barrett
Subject: RE: auto branch propagation
Date: Sun, 16 Apr 2006 19:06:03 +1000


I think that what you are asking for is actually a part of a CM
strategy, and as such is best implemented with a wider focus - and there
are several organisations (including the one I work for) that can assist
with this.

For instance doing what you ask also requires that you have a defect
tracking system and automated techniques for identifying what changes a
developer makes is a part of which defect.

As Jim said - automating the distribution of fixes to different streams
of code is fraught with danger - but good CM process can reduce that
danger.  However a goal of "re-merge fix and deliver" is probably not
achieveable - the results of the merge and build certainly both need to
be checked, but also the test results (functional and integration) and
perhaps even manual intervention (code review).

March Hare Software can certainly assist with CVS integrations and
training in Europe, North America or Aisa Pacific (and there are other
organisations that can also help).  

>From an open source software perspective though I think that there is no
"feature" that anyone can add to CVS to pull this off for you - it's CM
process design.


Arthur Barrett

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Kesavan T.S
Sent: Sunday, 16 April 2006 2:32 PM
To: address@hidden
Cc: address@hidden; address@hidden
Subject: Re: auto branch propagation

Hi Jim,
Is this an issue with cvs merge in a particular version is this by
design. I 
have been cvs user for about 2 years and I have not seen an issue with
merging. However the problem I am facing is we have like 4 releases in a

year and if a developer fixes and issue in production now he/she will be

forced to merge the changes in 4 branches. It would be a great help  to
this feature.  I was also thinking about it sometimes the fix may be
only in current release (like may be a temporary fix) so we might need a

option to not propagate the changes. I would really appreciate any tips
implementing this. I am proposing to use cvs over the existing sccs and
would be  an added point that can convince management.

>From: Jim Hyslop <address@hidden>
>To: "Kesavan T.S" <address@hidden>
>CC: address@hidden,  address@hidden
>Subject: Re: auto branch propagation
>Date: Fri, 14 Apr 2006 23:35:55 -0400
>Hash: SHA1
>Kesavan T.S wrote:
> > Hi Mark,
> > Thanks a lot for your response.I would really appreciate any tips 
> > for writing a script for auto propagation of a fix in prod level 
> > branch to future releases. When ever a commit is made I want to look

> > up upstream branches for these files  and in a temp directory do a 
> > update -j  if the merge is successful commit it on the branch 
> > otherwise lookup users email and send a notification for merge.
>I think this is a bad idea. Just because a merge does not produce 
>conflicts does *not* mean that the merge was successful. I have seen, 
>for example, a new function added to source code on both the branch and

>the trunk. For various reasons, the new function was not merged, but 
>copied-and-pasted from the branch to the trunk. Unfortunately, in the 
>branch the function appeared at the beginning of the file, and on the 
>trunk, it appeared at the end of the file. CVS merged the files without

>complaint, but compiling it (it was C++, not Java) produced errors.
>This is only one small example of the kind of thing that can go wrong 
>with a merge, which CVS cannot detect.
>- --
>Jim Hyslop
>Dreampossible: Better software. Simply.
>                  Consulting * Mentoring * Training in
>     C/C++ * OOD * SW Development & Practices * Version Management 
>Version: GnuPG v1.4.2 (MingW32)
>Comment: Using GnuPG with Thunderbird -

info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]