Re: Knowing that a merge has happened

[Jesus Manuel NAVARRO LOPEZ]

Hi, John:

John Minnihan wrote:
> 
> 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.
> 

Note me, I *do* use it, though in a sligthly different manner.  Probably
my environment is simpler: I don't post-tag the target, but once
conflicts are resolved, so in contributor I have a label as
merge_to_branchX and at target pre_merge_from_branch_Y, and
post_merge_from_branch_Y (well, actually, the sintactics are not exactly
this, but the meaning it is); post_merge_from_branch_Y it's only applied
when there're no more conflicts from the merge process (note that
someone can, and usually do add new versions to some of the files in the
middle of the process).  Indeed once or twice I made an intermediate
branch just for the resolving conflicts purpouses, because they affected
too many files (part of an API did change in the middle, so I wanted to
look deeply at the code).

Now, I re-read my previous post, and I see I wasn't saying what I wanted
to.  The question I wanted to ask was not if that labelling schema *is
needed* but if *really* can appear a race condition if labels are
applied on a file by file basis.

> 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 1.2.3.4 of file
> > foo.c and end up at version 1.2.3.5, if updated from the time the
> > command is entered and the time is really applied).
> >

-- 
SALUD,
Jesús
***
address@hidden
***