[Top][All Lists]

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

Re: Knowing that a merge has happened

From: Jesus Manuel NAVARRO LOPEZ
Subject: Re: Knowing that a merge has happened
Date: Mon, 03 Sep 2001 19:17:29 +0200

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).

reply via email to

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