[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mercurial
Subject:    Betr: Betr: Re: What is going on with our default branch?!?
From:       Alban Hertroys <alban.hertroys () apollovredestein ! com>
Date:       2018-03-14 14:24:58
Message-ID: OFB74963D7.BA428A89-ONC1258250.004D94EE-C1258250.004F3059 () apollotyres ! com
[Download RAW message or body]

"Mercurial" <mercurial-bounces@mercurial-scm.org> wrote on 2018-03-14 
12:32:15:

> David Demelier <markand@malikania.fr> wrote on 2018-03-14 12:00:19:
> 
Alban  Hertroys     
D: +31 (0)53 4 888 888  | T: +31 (0)53 4888 888 | E: \
alban.hertroys@apollovredestein.com Apollo Vredestein B.V.| Ir. E.L.C. Schiffstraat \
370, 7547 RD Enschede, The  Netherlands
Chamber of Commerce number: 34223268


 		 
The information contained in this e-mail is intended solely for the use of the 
individual or entity to whom it is addressed. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution 
or action in relation to the contents of this information is strictly 
prohibited and may be unlawful and request you to delete this message and any 
attachments and advise the sender by return e-mail. The confidentiality of this 
message is not warranted. Apollo Vredestein and its subsidiaries rule out any 
and every liability resulting from this or any other electronic transmission

																																																																																						 \
Please consider the environment before printing this e-mail On Wed, 2018-03-14 at \
11:17 +0100, Alban Hertroys wrote:
> > > Now we somehow ended up in this situation:
> > > T:\ibi\apps>hg log -l 10 -G -T Compact
> > > @  4802[tip]   bc7dbfed431a   2018-03-14 10:19 +0100   hertroys_a
> > > > Refuse to continue if dependencies are not met.
> > > > 
> > > 
> > > o  4801:-1   96f30f2f6a95   2018-03-14 10:19 +0100   Ruud
> > > production version of xxxxxxxx
> > > 
> > > o  4800:-1   25da197772b7   2018-03-14 10:19 +0100   Ruud
> > > Weight sometimes not ok
> > > 
> > > o  4799   99039b406de3   2018-03-14 10:19 +0100   Ruud
> > > > renewed
> > > > 
> > > 
> > > o  4798   1ba5dcdafeb9   2018-03-14 10:15 +0100   hertroys_a
> > > > Freshly generated documentation.
> > > > 
> > > 
> > > o  4797:4794   b405ac515445   2018-03-14 10:14 +0100   Ruud
> > > > new or changed
> > > > 
> > > > o  4796   2b1190f60c4c   2018-03-13 11:36 +0100   hertroys_a
> > > > > Revert changes to single spec for targeted spec.
> > > > > 
> > > > 
> > > > o  4795:4793   fbf2554a048b   2018-03-13 11:02 +0100   hertroys_a
> > > > > Fix calculation of UoM column width.
> > > > > 
> > > 
> > > o |  4794   6b24cad95229   2018-03-13 15:53 +0100   Ruud
> > > > /     ...
> > > > 
> > > 
> > > o  4793   5e8a6eeb9172   2018-03-12 17:45 +0100   hertroys_a
> > > > Remove development masks from list.
> > > 
> > > ~
> > > 
> > > 
> > > Notice that there are gaps. What does that mean?
> > > How do we recover from this situation?
> > > 
> > > 4796 is the changeset I need to merge eventually. Changesets 4800 
and
> > > 4801 
> > > 
> > 
> > This means that these changesets have been created from the null 
parent
> > revision. It's easy to reproduce, see:
> > 
> > $ hg init foo
> > $ cd foo
> > $ touch a && hg ci -Am "a"
> > adding a
> > $ hg up null
> > 0 files updated, 0 files merged, 1 files removed, 0 files unresolved
> > $ touch b && hg ci -Am "b"
> > adding b
> > created new head
> > $ hg log -G -T compact
> > @  1[tip]:-1   79efc2ff950c   2018-03-14 11:57 +0100   markand
> > b
> > 
> > o  0   3097b9f04d7b   2018-03-14 11:56 +0100   markand
> > a
> 
> 
> That's not quite our scenario though. This repo was initialised in 2010 
> and has seen a steady flow of commits ever since.
> 
> 
> > > and up somehow seem to have lost their connection with the default
> > > branch.
> > > 
> > > I already ran a hg verify, but apart from a few warnings about files
> > > not 
> > > found in parents, nothing appears to be actually wrong...
> > > 
> > 
> > Just update to the 4999 revision and merge 4802 and 4800 revisions :)
> 
> 
> Update... Oh dear. That means we first need to get all changes 
committed, 
> right? Some of those changes are detected incorrectly now though, 
because 
> the working directory apparently descends from the null parent now.
> 
> 
> > The very weird thing, is how thoses revisions went here. It could be
> > from erroneous rebase or graft?
> 
> Just commits. I don't think any of us even know how (or when) to rebase 
or 
> graft.

Okay, I think I got this resolved without too much trouble. Took the 
better part of the day though...

I created a clone of the broken repository, updated that to rev 4799 (not 
4999) and merged 4796, 4800 & 4802 onto that. Commit.
Next I pushed these changes to our master report (after editing the repo 
away from the broken repo) and updated it.
The next step was pulling the changes into the broken repo, which re-added 
almost files (a little over 15,000) back in and resulted in a bunch of 
merge conflicts (~25) for recently changed files (which confirmed that 
local changes were not lost - phew!). The local files were the right ones, 
so I picked those. Commit.

This seems to have done the right thing, as far as I can tell.

Thanks for the pointers.

Alban.

_______________________________________________
Mercurial mailing list
Mercurial@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial


[prev in list] [next in list] [prev in thread] [next in thread]