.hgsubstate not updated on "pull -u" or "update"

[wrmarvin]

Using HG version 2.4 on windows XP.

I have a "Master" repository of source code on a server at a company's site.
I am the only programmer currently working on their software.  The master
repositories do not have working directories. I work on this software from 2
locations, my office (I am a consultant with VPN access to their server),
and on a workstation at their office. They have multiple VB6 projects (52
projects) that create .exe or .dll executables that share source code (both
.frm and .bas files).

There are repositories for shared code (40 repositories) and a project
repository for each project (52 repositories).  The project repository for
each project contains subrepos for the shared code modules that it needs (0
to 10 subrepos in each project).  The 40 shared code repos and the 52
project repos are all directories located at the same level in the directory
tree, so the .hgsub file in the project repo uses relative referencing like
"SubSharedCodeRepo1 = ..\SharedCodeRepo1".

I use the following workflow:
1a) clone a project (Project1) to be working on at location A (e.g. my
office) from the "Master"
1b) make changes in primary repository files and/or shared code files in
subrepos locally.
1c) commit any subrepos with changes
1d) commit primary project repo
1e) push primary repository back to the "Master" (this pushes any modified
and commited subrepos)
1f) Note: project repository (Project1) at location A site is not deleted
after push.

2a) Go to location B (company office)
2b) clone the project (Project1) from "Master" on the server to a
development computer.
2c) make changes in shared code in 1 or more subrepos.
2d) commit all changed subrepos
2e) commit primary project repo (this changes .hgsubstate to the just
commited subrepo(s))
2f) push the primary project repo (Project1) back to "Master" while at
location B.

3a) Go back to location A
3b) cd to be within the local existing project repository (Project1).
3c) "pull -u" all subrepos used by the project from "Master" (pull will not
recurse subrepos, so subrepos must be pulled first individually) (TortoiseHG
will recurse pull of subrepos during a synchronize, but for this test I only
used mercurial hg commands.  The same problem happens when using TortoiseHG
synchronize)
3d) "pull -u" primary project repo.
3e) AT THIS POINT: .hgsubstate did not get updated from what is in the tip
of the primary repository.
3f) If you try a manual "update -rtip" it still does not update the
.hgsubstate file.
3g) If you do a kdiff between the working directory .hgsubstate and the
repository tip .hgsubstate it will show that the files are different.

I would expect the "pull with update" action in 3d to put the project
working directory files to be the same as the files in the tip of the
project repository. Doing a kdiff on any tracked file in the updated working
directory should show no differences to the files in tip and that includes
the .hgsubstate file. If I do a full clone, the .hgsubstate file DOES become
the same as the file in tip.

There could be a problem if you do not pull all the subrepos before pulling
the primary repository. If you pulled the primary repository first and the
.hgsubstate was updated to what is in tip, the .hgsubstate could refer to a
subrepository that does not yet contain the referenced changeset in the
updated .hgsubstate.

If you do the "pull -u" commands in the correct order, the .hgsubstate
SHOULD get updated in the working directory for the project.

For the pull -u command on the primary to work correctly, a check of the
.hgsubstate in the tip would have to be made to make sure that the
changesets referenced in the .hgsubstate do actually exist in the local
subrepos.  If all changeset references for the subrepos are valid, then the
.hgsubstate should be update in the working directory of the project. If
there is a changeset reference error, then the .hgsubstate should not be
updated and an error message created.

Even if all all the references are valid, the .hgsubstate from the project
tip could reference a changeset that is not the tip in the just pulled
subrepo.  If that is the case, then the working directory of the subrepo now
contains code that was not used for this project when the last push for this
project was done.  This can happen because the shared code was changed,
committed, and pushed from another project that uses this shared code.
Usually in ongoing development, I would want to use the newest shared code
for a new build and this is OK. If this situation is detected during a pull
of the project repository, a warning message would be nice so I can then
decide to either use the newer code or revert back to the changeset that was
last used by this project. If I am trying to look at code from an older
version, I would do a full clone of that project version so that I would get
the code in the subrepos that existed at the time of the project build.
 
After doing the pulls in the correct order, I have to do a "hg revert -rtip
.hgsubstate" in the primary project directory to make the project files the
same as those contained in the tip.

The reason I want to do the pulls instead of a new clone is because location
A and B could be "out of sync".  If I delete the project repository at
Location A and clone during section 3 above, I could loose file
modifications or changes at location A (commited) that I failed to push
before going to location B.  By pulling, I can then fix things and merge the
heads.

I did not create this mess of projects and shared code, I just now try to
maintain it.  The original programmer is gone from the company.  I have been
supporting it and using these mercurial repositories for about the last 2
years. I have not had an issue with the .hgsubstate not getting updated on a
pull or update, but it seems that mercurial is not handling this situation
as it should.




--
View this message in context: http://mercurial.808500.n3.nabble.com/hgsubstate-not-updated-on-pull-u-or-update-tp3995591.html
Sent from the General mailing list archive at Nabble.com.