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

Sat Dec 8 02:42:41 UTC 2012

Do you mean 
subrepo = ../subrepo

Using a forward slash atypical of URLs and most operating systems, not the backwards Windows slash. I think I read in the subrepo docs that the standard forward slashes must be used as the .hgsub file needs to work everywhere.

Scott

On 2012-12-07, at 1:15 PM, wrmarvin <bill_marvin at hotmail.com> wrote:

> 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.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial