How to track a file (in various versions) used by several projects

Thu Oct 19 17:53:10 UTC 2023

Hi Steve,

A few points that came to mind, for your case:

> ... in the library repository, it would be useful to have some
> history that tells me where changes came from.

In addition to the "named branches" approach (which seems fine for
your case), you can also have different usernames for the different
repos.
You can do this by modifying the .hg/hgrc file for a given repo,
changing the ui.username config entry. I have used this approach with
some success sharing code between systems, having names like
"me-laptop at example.com" on one and "me-server at example.com" on another.
You can see this easily when looking at the commits.

You also originally asked:

> Will I have problems if I make a repository in a subdirectory
> of another repository? Can a single driver.au3 file be part of
> both the systemA repository (in the sub-directory) and also be
> the sole file tracked in the subdirectory repository?

Having a repo-inside-a-repo is supported. The sub-repo's files will be
ignored by the parent repo.
Note: this is entirely separate from Mercurial's "subrepos"
extension[1], which make the parent repo aware of the sub-repos, and
lets you operate on them as a group. If you simply do nothing but make
a repo-inside-a-repo, it will be auto-ignored by the parent repo. In
that simple case, if you want to make changes in the sub-repo, you
would change dir to be inside there, and work normally.

Just to be explicit, I think one good way to organize things would be like so:

shared/
  driver.au3

sysA/
  shared-clone/   # cloned from top-level shared/ dir
    driver.au3    #   modify ui.username to be unique to sysA
  ... # other files for sysA

sysB/
  shared-clone/   # cloned from top-level shared/ dir
    driver.au3    #   modify ui.username to be unique to sysB
  ... # other files for sysB

If you make a change in sysA/shared-clone/driver.au3, it will only be
visible to sysA.
You could also independently make changes to
sysB/shared-clone/driver.au3 with no conflicts.

When you want to merge and get things synchronized, you would:

1. pull both sysA and sysB's version of the shared repo into the
   top-level one. You can make convenience aliases in the top-level
   shared repo so you can write "hg pull sysA" (no idea what this
   looks like in Tortoise though).
   Aside: if you use push instead, Mercurial will warn you if a new
   head is introduced, which might be something you want.

2. Now, the top-level repo should have multiple heads - one for each
   sysX repo that had an independent modification.

3. Merge them, however you like, to produce a driver.au3 file that
   will work on all systems.

4. Go to each of sysA/shared-clone and sysB/shared-clone, and
   pull (and update!) the latest. Confirm the new code is working.

This is a little bit of a process, but lets you confirm things are
working each step of the way.

Note: this all assumes everything is on one system. If you have
multiple machines, the approach still works, but you will need to
transfer repos across machines (I use 'hg bundle' for this) rather
than simply pushing/pulling directly.

I hope it helps
-John

[1] https://wiki.mercurial-scm.org/Subrepository

On 10/19/23, Steve Mullock <sjm at kore.co.uk> wrote:
> Dear Norman
>
> Thanks for clarifying. I think I understand now.
>
> In the heat of the moment I don't entirely trust myself to always remember
> to edit a MODIFIED
> line. Also in the library repository, it would be useful to have some
> history that tells me
> where changes came from. So I think I pursue the named branches route for a
> bit, in the hope
> Mercurial will help keep track of things for me. After a few drift apart and
> merge events, I
> should have a clearer idea how this will work out.
>
> Thanks again
>
> Steve
>
> From:           	Norman Gray <gray at nxg.name>
> Date sent:      	Thu, 19 Oct 2023 17:18:42 +0100
>
>>
>> Ah, no, I wasn't thinking about compiled code.  The specific case here is
>> a local, but quite
>> intricate, LaTeX class file, and some associated other files (images, and
>> XSLT scripts).  Once
>> they're in place in the 'client' repo, they're included from there by
>> LaTeX documents in that repo.
>>
>> Thus the client repo remains standalone, but I have a mechanism for bugs
>> which emerge in the class
>> file, to be fixed in one client tree, and then be coped back to the
>> 'library' repo, where they can
>> be bundled into a 'distribution' (strictly in scare-quotes), ready to be
>> copied into other
>> 'clients', when that becomes convenient.
>>
>> There's a few by-hand steps in the workflow (if feels dodgy even
>> dignifying it with 'workflow'!),
>> and there might be a way which uses more Mercurial cleverness, but the
>> process is fundamentally
>> simple enough that this works for me.
>>
>> Best wishes,
>>
>> Norman
>>
>>
>> --
>> Norman Gray  :  https://nxg.me.uk
>
> --
> Dr. S.J. Mullock
> http://www.kore.co.uk
> Kore Technology Ltd
> Cambridgeshire Business Park
> Ely, Cambs.
> CB7 4EA, UK
> Tel. (Int.+ 44) (0) 1353 653030
> Fax. (Int.+ 44) (0) 1353 653031
> Registered in England, No. 2643175
>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial
>