Quantcast

New changesets on a closed branch that must make it to default

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

New changesets on a closed branch that must make it to default

wujek
Hi. We have the following case today: we have a (named) feature branch, and one of us merged some changes from default:
(on 'feature_x')
hg merge default
hg ci -m 'Merges default'
hg push

Meanwhile, someone else closed and merged 'feature_x' into default (locally):
(on 'feature_x')
hg ci --close-branch -m 'Closing feature branch'
hg up default
hg merge feature_x
hg ci -m 'Merges feature x'
hg push

push fails. So, the 'closing person' pulls, and now has a new changeset (the merge with default) on the branch he closed already, and didn't know what to do. What we did was that we closed the 'feature_x' branch again, merged it into default, and pushed. hg then issued a warning that we are pushing a new commit to an already closed branch, which we fixed with the -f switch. The repository looks good afterwards.

The question is: how does one deal with such use cases? Is what we did right in these circumstances? Agreed, we failed at communication at some point, but this happens.

Regards,
wujek

_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New changesets on a closed branch that must make it to default

Martin Geisler-2
Wujek Srujek <[hidden email]> writes:

> Hi. We have the following case today: we have a (named) feature
> branch, and one of us merged some changes from default:
> (on 'feature_x')
> hg merge default
> hg ci -m 'Merges default'
> hg push
>
> Meanwhile, someone else closed and merged 'feature_x' into default
> (locally):
> (on 'feature_x')
> hg ci --close-branch -m 'Closing feature branch'
> hg up default
> hg merge feature_x
> hg ci -m 'Merges feature x'
> hg push
>
> push fails. So, the 'closing person' pulls, and now has a new
> changeset (the merge with default) on the branch he closed already,
> and didn't know what to do. What we did was that we closed the
> 'feature_x' branch again, merged it into default, and pushed. hg then
> issued a warning that we are pushing a new commit to an already closed
> branch, which we fixed with the -f switch. The repository looks good
> afterwards.
>
> The question is: how does one deal with such use cases? Is what we did
> right in these circumstances? Agreed, we failed at communication at
> some point, but this happens.

What you did is absolutely fine and no harm was done to your repository.
The concept of an open or closed branch is something that's built on top
of the normal changeset graph. When you do

  hg commit --close-branch -m "Closing"

then you're creating a normal changeset with a little bit of meta data
that says "I'm now closed". If all heads on a given branch carry this
meta data, then the branch itself is considered to be closed. It will
then disappear from 'hg branches'. This is all something that's computed
later when 'hg branches' is invoked.

It's thus fine to close and reopen branches -- the end result is what
you would expect, module warnings like you saw above. The warnings are
just there to guide you and work well for most use cases. Above you had
an slightly unusual race condition where the warning seems unnecessary.
But it's harmless to override it here.

--
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New changesets on a closed branch that must make it to default

wujek
Hi Martin,
thanks for the explanation, I never actually new what an empty commit with --close-branch does. I think it used to be different in the older days of mercurial? I mean, you had to actually commit some changes apart from closing the branch? Or am I completely wrong on this one?

Anyways, thank.
wujek

On Fri, Feb 24, 2012 at 11:58 AM, Martin Geisler <[hidden email]> wrote:
Wujek Srujek <[hidden email]> writes:

> Hi. We have the following case today: we have a (named) feature
> branch, and one of us merged some changes from default:
> (on 'feature_x')
> hg merge default
> hg ci -m 'Merges default'
> hg push
>
> Meanwhile, someone else closed and merged 'feature_x' into default
> (locally):
> (on 'feature_x')
> hg ci --close-branch -m 'Closing feature branch'
> hg up default
> hg merge feature_x
> hg ci -m 'Merges feature x'
> hg push
>
> push fails. So, the 'closing person' pulls, and now has a new
> changeset (the merge with default) on the branch he closed already,
> and didn't know what to do. What we did was that we closed the
> 'feature_x' branch again, merged it into default, and pushed. hg then
> issued a warning that we are pushing a new commit to an already closed
> branch, which we fixed with the -f switch. The repository looks good
> afterwards.
>
> The question is: how does one deal with such use cases? Is what we did
> right in these circumstances? Agreed, we failed at communication at
> some point, but this happens.

What you did is absolutely fine and no harm was done to your repository.
The concept of an open or closed branch is something that's built on top
of the normal changeset graph. When you do

 hg commit --close-branch -m "Closing"

then you're creating a normal changeset with a little bit of meta data
that says "I'm now closed". If all heads on a given branch carry this
meta data, then the branch itself is considered to be closed. It will
then disappear from 'hg branches'. This is all something that's computed
later when 'hg branches' is invoked.

It's thus fine to close and reopen branches -- the end result is what
you would expect, module warnings like you saw above. The warnings are
just there to guide you and work well for most use cases. Above you had
an slightly unusual race condition where the warning seems unnecessary.
But it's harmless to override it here.

--
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/


_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New changesets on a closed branch that must make it to default

Martin Geisler-2
Wujek Srujek <[hidden email]> writes:

Hi Wujek

> thanks for the explanation, I never actually new what an empty commit
> with --close-branch does. I think it used to be different in the older
> days of mercurial? I mean, you had to actually commit some changes
> apart from closing the branch? Or am I completely wrong on this one?

This hasn't changed, but you're correct that you normally have to make a
change in order to commit: Mercurial only allows "empty" changesets when
they carry some extra meta data. That either be a changed branch name or
a branch close marker.

--
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/
_______________________________________________
Mercurial mailing list
[hidden email]
http://selenic.com/mailman/listinfo/mercurial
Loading...