[evs] Branching on commit, merge documentation

Gerhard Fiedler lists at connectionbrazil.com
Fri Sep 14 15:56:52 BST 2007

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Arthur Barrett wrote:

> From every company I teach this stuff at I learn new things - however
> most of our customers approach us for our commercial software and
> training because they also have a CM manager/QA manager that already
> "knows" all this stuff, and they are (in essence) picking our software
> and services because we think like them.  For me - learning how to
> communicate this stuff effectively to people who don't live an breath CM
> and CM best practice is the challenge, and discussions like this help me
> a lot.

I put this on top, because I think I see a part of why we seem to be
talking of different situations. Most of my CM experience with bigger teams
is in initial software development phase (working with a software
development company that often got brought in when things were already much
too late or burning hell), the phase where big changes are the norm, not so
much in production development, where small incremental changes probably
are more frequent. I think the probabilities for conflicts in changes may
be different in these situations.

>> I understand the purpose of item 2, but I don't understand how you would
>> (easily) "back out" a change set and put it into a later revision.
>> That's the part with the actual commands I asked you to provide earlier
>> in this message.
> There are many ways, here is an example from the eBook:

I think there is a market for the eBook alone (supposedly cheaper than the
full licensed package). Of course, I don't know how much of the eBook is
about general use of the tools and how much is about the specific tool set
and integration you're selling -- and I also don't know how many of those
who would buy the eBook are people who otherwise would buy the whole
package :)

> For example, to rollback a commit that you just performed:
> cvs update -j @commitid -j "<@commitid" filename or modulename
> "<@commitid" revision before that commit
> @commitid                   revision of that commit

I figured something like this, but then it seems that the whole process has
a good potential to become quite a bit contrived. 

(BTW, isn't that a double j merge -- the one you said "stop using double j
merges (just stop, no if's but's or maybe's - they are not needed)"? :)

You wrote earlier:
>>> you back out the 3335 change (one line command) and "fix" 3334 and
>>> commit, then re-add the 3335 change (another 1 line command) and
>>> re-commit 3335 

This is how the 'back out the 3335 change' looks to me: Determine which
commitids belong to that change. It may be one or several, but I don't know
(in the general case, where it wasn't me who made that change), so I have
to find out. AIUI I have to run a cvs log, search the output for "bugid:
3335" and collect all revisions that belong to that bugid. That gives me
the one or more commitids associated with the bugid. Then I run one or more
(depending on how many contiguous sequences of commits were) of the double
j merges to 'merge out' the 3335 commits. This probably works reasonably
well if these commits are in one block, but I imagine that this may not be
that simple if they are not. Similarly for re-adding 3335.

If 3334 were on a branch, there would be no need to back out 3335: just fix
it on branch dev_twinkie_3334 and merge the fix back to dev_twinkie. So I
guess in such a scenario, deciding whether or not to put a change on a
branch depends on the need to have the change accessible separately (if
that's not necessary, we can use a non-reserved process), the probability
of something like this happening, and the amount of effort involved of
performing the above -- all that weighted against the effort of creating
(and managing) a branch.

I guess when you are in a situation of working with some ten developers on
maintaining software with hundreds of modules that is already reasonably
settled, the odds of overlapping changes are indeed low. But there are
other scenarios where these odds are not negligible, and branches become
more attractive.


More information about the evs mailing list