[Top][All Lists]

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

Re: Knowing that a merge has happened

From: John Minnihan
Subject: Re: Knowing that a merge has happened
Date: Mon, 03 Sep 2001 15:36:46 -0700
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010628

Actually, Yes it is necesary in all but the most casual uses of merging. In my case, I happen to manage a repository which has multiple branches [ some branches are baselined off other branches ] that requires frequent joins to branches that are often other than that branch's own root.

Tagging in the manner described below facilitates these joins, such that artificial merge-conflicts are reduced nearly to zero (often-times there are NO artificial conflicts).

I have learned this technique the hard way - many, many, many joins over the past several years. I can now conduct what *LOOKS* like an extremely complex join of disparate branches in minutes, flagging *ONLY* the actual conflicts (if any) and *ONLY* the actual deltas. This was impossible w/o the technique below.

address@hidden wrote:

Hi, John:

John Minnihan wrote:

address@hidden wrote:

Steve Bement wrote:

I'm struggling with one point regarding merging.  I understand the
mechanics/commands of how to do the merge, but once the merge is done, I
can see know way of knowing that it happened.

You could mention it in the commit message after the merge.

The appropriate way to handle this is to pre-tag the contributor &
target and post-tag the target.  Beware of the race condition though;
freeze your repository (using whatever technique works for you) during
the tag ops and the join.

Is it really needed (it is not a rethoric question, I *am* interested on
this issue)?
If you tag on a file by file basis, it will be told to you that your
version is not current for any file updated from your last commit.  This
way you will be able to look at the changes and opt tagging the updated
version (if you're sure the changes don't collide with your development)
or tag a previous version (the one you really want to).

Then you'll branch from the tag (I mean, instead from just HEAD),
whichever version it points to.
Obviously it is not the cleaner/easier way to manage this, but I *think*
it should work with no problems (unless that branching/labelling is not
an atomic operation when applied to a single file, in which case is true
that you could send a tag command for, let's say version of file
foo.c and end up at version, if updated from the time the
command is entered and the time is really applied).

John Minnihan

reply via email to

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